Coreboot Issues Rebuttal To Recent Laptop Vendor Controversy

[cthart]

Someone help me get Canada banned too

What about Mali?

[lowflyer]

Language evolves and changes.

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?

[oiaohm]

[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.

https://www.anandtech.com/show/18853/amd-opensil-planned-to-replace-agesa-firmware-in-client-and-server-in-2026

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.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Platforms

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.

[skeevy420]

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.

[back2未來]

[

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. ]

[r_a_trip]

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.

[pgeorgi]

[ 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.

[skeevy420]

When did they become singular?

Around 2017

[skeevy420]

Where the goose's shadow falls? Don't quite grok that. A Canadian or Québécois thing?

AFAIK, I made it up from a loose combination of "anywhere under the sun" and "as the crow files" with added Canadian stereotypes.

I hadn't encountered emmerder - sheltered life I guess - Oddly I guessed it was a compound of ex + merde (ie to defæcate) but apparently not quite but the sense is not far from that.

I was taking the word of translation programs. Google's and some other random service gave me the same answer so I went with it.

[TheMightyBuzzard]

All true. Enough confusion arises when you is used in contexts where the distinction between singular and plural is important or requires a periphrastic decoration (as in you all) without encouraging the replication of the same ambiguity by revitalising a historical usage of the third person just to conceal natural gender. English already has ungendered one and it.

Old English still (just) had the dual wit (we two), unser (us two) which was only used by Beowulf when talking to a dragon so we might revive that usage too.

The primary function of language is communication and any syntactic change which reduces the accuracy and efficacy of that communication by introducing unintended ambiguity is not actually progress. As always usage and time are the ultimate arbitrator in these matters.

Easy solution there, don't use naked pronouns. Instead of "you", use "you assholes" or "you asshole". Instead of "they", use "those assholes" or "that asshole".