Announcement

Collapse
No announcement yet.

Coreboot Issues Rebuttal To Recent Laptop Vendor Controversy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by r_a_trip View Post

    When did they become singular?
    Around 2017

    Comment


    • #42
      Originally posted by back2未來 View Post
      [ Why is it that difficult porting coreboot to another board (laptop, desktop, workstation mainboard) with staying on same ISA like x86, riscV (firmware being 16bit executables for 32&64bit mode bios and uefi fw drivers and binaries) for just having a basic bootcode, initializing voltage levels, power sources for the cpu, initilize memory and a serial(/usb) terminal for then loading a capable 2nd stage bootloader, e.g. grub2, (lilo,) syslinux, u-boot or bootmgfw.efi? (thx) ]
      The ISA may be trivial, but everything around isn't. One of the lessons the RISC-V folks had to re-learn the hard way after they refused to listen.

      "Initializing memory" (that you mention) these days is a trial and error procedure where you configure the memory controller to set a memory configuration, send a few signals, then ask what comes back. From that, you derive which of the many parameters need to be tweaked. You do and retry until it's good enough. Same for PCIe. Same for HDMI. Same for USB4. Sounds simple enough, right? Sadly, no:

      With every chip generation (that is, every 12-24 months) the hardware folks rewire half of that to get 3% more efficiency or whatever, and usually put another 10% complexity on top of things. And because they think that they're smart and everybody else is stupid, they're hesitant to share what they did, lest their competitors pick up these tweaks without putting in the brain work. If you miss _one_ step of this intricate back and forth, all kinds of things might happen. From simple "doesn't boot at all" to "Everything seems to work, but if you touch a certain 64k section of RAM, the system has a 95% chance to get stuck, but only after the fourth suspend&resume cycle since cold boot".

      Now, in modern devices, laptops in pretty much all cases, but also many desktop or server boards, you have additional processors on the chip that provide runtime management of various things on the board: voltages and fan speeds (based on temperature and CPU performance needs), battery charging (for laptops), enabling or disabling PCIe ports as needed, ... Every board by every vendor does things ever so slightly different, with different requirements. Every couple of years they switch the controller firmware and redo the protocol to communicate with it. Of course that's also some super secret trade secret juice, so they're hesitant to give out specifications. "Just use our CPU firmware" they say.
      IMNSHO they simply don't have a specification for the protocol themselves because there are often 2-3 different vendors messing with the code, each thinking that maintaining documentation is a job "the others" should do.

      So, every board port starts with an assessment of how much you can reuse, hoping that you don't miss anything. If the chipset is already supported, you usually get to _some_ result quickly (can be booting into Linux after one day if you're lucky). And then the real work starts, working out all those tiny tweaks. Providing incomplete firmware might be good enough for hobbyists porting coreboot to their old devices (they know what they're doing, and they know how to recover), but Malibal isn't targeting that audience. As such, they'd require something better.

      Their code that was "80% there" (but that they couldn't get onto the flash, so who knows if it actually boots)? That was probably a 10% solution, if that.
      Last edited by pgeorgi; 30 October 2024, 12:45 PM.

      Comment


      • #43
        Originally posted by skeevy420 View Post
        Around 2017
        I will not let you drag me down and then beat me with experience. We both know who is the more credible one here.

        Comment


        • #44
          [
          Originally posted by pgeorgi View Post

          The ISA may be trivial, but everything around isn't. One of the lessons the RISC-V folks had to re-learn the hard way after they refused to listen.

          "Initializing memory" (that you mention) these days is a trial and error procedure where you configure the memory controller to set a memory configuration, send a few signals, then ask what comes back. From that, you derive which of the many parameters need to be tweaked. You do and retry until it's good enough. Same for PCIe. Same for HDMI. Same for USB4. Sounds simple enough, right? Sadly, no:

          With every chip generation (that is, every 12-24 months) the hardware folks rewire half of that to get 3% more efficiency or whatever, and usually put another 10% complexity on top of things. And because they think that they're smart and everybody else is stupid, they're hesitant to share what they did, lest their competitors pick up these tweaks without putting in the brain work. If you miss _one_ step of this intricate back and forth, all kinds of things might happen. From simple "doesn't boot at all" to "Everything seems to work, but if you touch a certain 64k section of RAM, the system has a 95% chance to get stuck, but only after the fourth suspend&resume cycle since cold boot".

          Now, in modern devices, laptops in pretty much all cases, but also many desktop or server boards, you have additional processors on the chip that provide runtime management of various things on the board: voltages and fan speeds (based on temperature and CPU performance needs), battery charging (for laptops), enabling or disabling PCIe ports as needed, ... Every board by every vendor does things ever so slightly different, with different requirements. Every couple of years they switch the controller firmware and redo the protocol to communicate with it. Of course that's also some super secret trade secret juice, so they're hesitant to give out specifications. "Just use our CPU firmware" they say.
          IMNSHO they simply don't have a specification for the protocol themselves because there are often 2-3 different vendors messing with the code, each thinking that maintaining documentation is a job "the others" should do.

          So, every board port starts with an assessment of how much you can reuse, hoping that you don't miss anything. If the chipset is already supported, you usually get to _some_ result quickly (can be booting into Linux after one day if you're lucky). And then the real work starts, working out all those tiny tweaks. Providing incomplete firmware might be good enough for hobbyists porting coreboot to their old devices (they know what they're doing, and they know how to recover), but Malibal isn't targeting that audience. As such, they'd require something better.

          Their code that was "80% there" (but that they couldn't get onto the flash, so who knows if it actually boots)? That was probably a 10% solution, if that.
          Thanks for the summary.
          Learning with few simple actions (just a/some kernel module loaded, possibly changed a flag for flash partition for readable, meant probably writable also, maybe a read command for the flash part and an early reboot cycle, without having a backup from fw flash) done wrong by 'chance', on an embedded x86 (dated) Intel hardware, me recognized there's a lack for a generic repair firmware for getting basic access to all soldered storage again. (With recognizing read&write accesses from `iostat` overview, me should have done a backup of that readable part of fw, but that was already accessed by the OS, anyway, before reboot.)
          Since being for an older platform, fw binary packages for cpu platform from vendor are probably no more available on (public) company support webpages and limited success came with flashing fw from a comparable platform (same cpu, chipset, comparable memory size and nand vendor/size) and even some of the peripherals got initialized, but that's from a very close 'copy' of the original device.

          Newer platforms might include slimbootloader and an approach like ubrx (being a generic x86 serial console from cold boot and without remaining/available fw backups) might enable basic access to a platform hardware. Another option might be openbios (but maybe also relies on coreboot for initializing hardware)?

          Even transferring drivers from one firmware on an UEFI fw towards a corrupted fw part seems 'difficult' enough for being a repair option (a bit flip, on decades of utilization, might be enough for a blocked boot-up?) for interested users and at least public, fw documentation for uefi is a 2145 pages, only, in addition to all hardware registers and maybe programming instructions (from an embedded hw POV).

          Seems there was a fw binary at some point and a provided laptop by Malibal booted(?) with coreboot towards or through an 'FSP' stage related debug/information output.

          Edit: oiaohm, Thanks for the update, i see. ]
          Last edited by back2未來; 03 November 2024, 08:14 AM.

          Comment


          • #45
            Originally posted by r_a_trip View Post

            I will not let you drag me down and then beat me with experience. We both know who is the more credible one here.
            Whoops, I meant to write that as "Around 2017 " since that's when I noticed the hate rhetoric becoming a lot worse than the norm.

            ...

            "the hate rhetoric becoming a lot worse than the norm."

            ...

            That's a damn depressing thing to say.

            Comment


            • #46
              Originally posted by back2未來 View Post
              [Newer platforms might include slimbootloader and an approach like ubrx (being a generic x86 serial console from cold boot and without remaining/available fw backups) might enable basic access to a platform hardware. Another option might be openbios (but maybe also relies on coreboot for initializing hardware)?
              What you listed has limitations.


              Items like above is the problem.

              From the OpenBIOS site.
              While far not all possible applications of OpenBIOS are implemented yet,
              a lot of functionality is already there. OpenBIOS can be used as a payload
              for coreboot (http://www.coreboot.org), or be booted from any multiboot
              capable bootloader to bring Open Firmware to your machine. OpenBIOS can
              also be used when an operating system is already running. It provides
              the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS
              9 and X on PPC machines, as well as Linux (all supported platforms)​
              OpenBIOS only works after the hardware has been started by coreboot or something else. OpenBIOS has no where to plug in the Intel and AMD hardware startup software.

              Slimbootloader is maintained by Intel not certified to work with AMD agesa or opensil and no where to plug the AMD bits in..
              https://slimbootloader.github.io/sup...are/index.html yes the supported platforms bit.

              Ubrx does not work with modern hardware. Ubrx is for systems before the modern PCIe and memory training.... problems.

              Yes not working with coreboot for open source solution that can boot on modern X86 you are forced to slimbootloader that only works on Intel.

              Tianocore website. Contribute to tianocore/tianocore.github.io development by creating an account on GitHub.

              Yes the tianocore that is the reference implementation of UEFI has a even shorter list of supported CPUs than Slimbootloader and is not current ones.

              When it comes to open source system starting firmware there really is not that many options.

              Comment


              • #47
                Originally posted by BesiegedAce View Post

                Language evolves and changes.
                Originally posted by r_a_trip View Post

                When did they become singular?

                1375

                The singular they isn't actually new. According to The Oxford English Dictionary, the singular they showed up in writing in 1375—over 600 years ago! The OED also suggests the usage is even older since written language usually reflects trends already present in spoken language.

                https://www.scu.edu/media/offices/provost/writing-center/resources/Tips-Singular-Pronoun-They.pdf​

                didn't I say exactly that?
                Last edited by lowflyer; 31 October 2024, 03:27 AM.

                Comment


                • #48
                  Originally posted by Quackdoc View Post
                  Someone help me get Canada banned too
                  What about Mali?

                  Comment

                  Working...
                  X