AMD Zen-Derived Hygon Dhyana Appears To Be Working On Coreboot Support

[madscientist159]

Adarion thank you for very nice explanation. if i understand correctly this in theory should work on current motherboards as long as the necessary documentation is available.

No, unfortunately modern x86 also implements signature checks in hardware. Even with documentation and firmware source, you can't compile and install your own firmware without the vendor's signing key, which they won't give out. That being said, bugs in the signed firmware are leveraged routinely by bad actors, and it's suspected that high level agencies in various countries also have access to those keys.

If you want open firmware that you can install on hardware you control, you'll have to look somewhere other than Intel and AMD.

[Nille_kungen]

About AMD and coreboot didn't it all slow down when that man (can't remember his name right now) who had that company that used to do that work retired?
Not very surprising since the reason for Hygon Dhyana was about ensuring that there are no backdoors and that surely should include the bios/EFI.

[michaelb1]

coreboot supports really old motherboards only. https://coreboot.org/status/board-status.html

For devices coreboot built in, see: https://www.coreboot.org/users.html

Sorry, I disagree that i.e. 2014 year motherboards (some AMD motherboards, without PSP by the way) could be considered as "really old motherboards". 5 years old is still relatively new, especially regarding the total performance which is still very comparable to the new ones and hardware capabilities like able to have a 16 GB of RAM. And still able to find them in a lightly used condition from time to time

[michaelb1]

And so does AMD with their PSP. If your chip is newer than Core 2 Duo for Intel, or ~2013 for AMD, you're screwed, and your chip has backdoors that can't be fully removed. me_cleaner and similar tools can only partially neuter these anti-features.

this PSP crap has been introduced gradually to different AMD processor types - so it's a bit confusing - but at least I could tell you that e.g. the APUs of early 16h "Jaguar" architecture do not have it, while the APUs of late 16h "Puma" architecture already have. As you could see from this page - https://en.wikipedia.org/wiki/Jaguar...oarchitecture) - there are some relatively new APUs, including my Athlon 5370 for AM1I-A coreboot-supported AMD board, which luckily still don't have a PSP . So it's impossible to simply say that " all CPUs / APUs released after X year are infested with PSP " like some wikis say, e.g. libreboot wiki tells "basically anything post-2013" but this is incorrect info! Closer look is usually required, and if you have a question about any other AMD CPUs - maybe could try to help you.

[Guest]

this PSP crap has been introduced gradually to different AMD processor types - so it's a bit confusing - but at least I could tell you that e.g. the APUs of early 16h "Jaguar" architecture do not have it, while the APUs of late 16h "Puma" architecture already have. As you could see from this page - https://en.wikipedia.org/wiki/Jaguar...oarchitecture) - there are some relatively new APUs, including my Athlon 5370 for AM1I-A coreboot-supported AMD board, which luckily still don't have a PSP . So it's impossible to simply say that " all CPUs / APUs released after X year are infested with PSP " like some wikis say, e.g. libreboot wiki tells "basically anything post-2013" but this is incorrect info! Closer look is usually required, and if you have a question about any other AMD CPUs - maybe could try to help you.

Thanks for clearing that up. I don't deal that much with AMD hardware, so I've never looked into how PSP situation is like on AMD chips.

[michaelb1]

Thanks for clearing that up. I don't deal that much with AMD hardware, so I've never looked into how PSP situation is like on AMD chips.

Luckily the latest AMD-without-PSP is much more powerful than the latest Intel-without-ME , and - if some not-PSP AMD motherboard is coreboot-supported - usually it has a really good freedom status ! Not everything there is blob-free, but the few blobs required for some coreboot'ed AMD boards - like the AtomBIOS VGA blobs - have been researched relatively well and nothing suspicious found so far.

[Guest]

Luckily the latest AMD-without-PSP is much more powerful than the latest Intel-without-ME , and - if some not-PSP AMD motherboard is coreboot-supported - usually it has a really good freedom status ! Not everything there is blob-free, but the few blobs required for some coreboot'ed AMD boards - like the AtomBIOS VGA blobs - have been researched relatively well and nothing suspicious found so far.

Coreboot by itself is mostly a convienience, Libreboot is where it's at if you want freedom. Your average Coreboot box will have blobs neutered with tools like me_cleaner at best, it's not that much different from proprietary firmware. Still, I don't think I'd be happy to come back to a machine that doesn't go directly into GNU GRUB from init code, and one without libgfxinit, which is like KMS (including multiple outputs with different resolutions) before you even run your bootloader. If it wasn't for the backlight helper process, I'd have a completely flicker free boot on my machine (without garbage like plymouth, the TTY stays at the same resolution at all times, and X runs at the same resolution).

[michaelb1]

Coreboot by itself is mostly a convienience, Libreboot is where it's at if you want freedom. Your average Coreboot box will have blobs neutered with tools like me_cleaner at best, it's not that much different from proprietary firmware.

Different blobs have a different potential danger, e.g. there are much more security concerns about the closed source Intel FSP or leftovers of cleaned Intel ME firmware - than for the AtomBIOS blobs, especially considering you could enable YABEL to run these blobs on top of the emulation layer (and block the suspicious graphics-unrelated activities) and even could throw them away, running in a headless mode.

Still, I don't think I'd be happy to come back to a machine that doesn't go directly into GNU GRUB from init code, and one without libgfxinit, which is like KMS (including multiple outputs with different resolutions) before you even run your bootloader. If it wasn't for the backlight helper process, I'd have a completely flicker free boot on my machine (without garbage like plymouth, the TTY stays at the same resolution at all times, and X runs at the same resolution).

Indeed, coreboot is providing a lot of features that a proprietary UEFI can't deliver. For example: with one simple command its possible to add any floppy to coreboot BIOS build - and then you see it as a boot entry! Multiple floppies could be added this way (as long as you have enough space left inside the BIOS flash chip, luckily LZMA compression could be used for the stored floppies to reduce their occupied size) . So you can add a KolibriOS - wonderful x86 assembly OS with GUI and some networking drivers - FreeDOS / memtest / and many other useful floppies to your coreboot.rom, and still have some free space left

[michaelb1]

on my machine

Sorry, I almost forgot to tell what this floppy-adding command is:

./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f ./your_floppy_image.img -n floppyimg/your_floppy_name.lzma -t raw -c lzma

Where after -f is a path to your floppy image and after -n floppyimg/ there's a floppy name inside the CBFS.

Actually this floppy loading feature is provided by SeaBIOS rather than a coreboot, but since a SeaBIOS seems to be the most popular coreboot payload based on .config stats - almost everyone could use this feature. After following the example above, this floppy will be displayed at SeaBIOS boot menu as:

[number] your_floppy_name [ramdisk]

I see that you'd like to have a GRUB at coreboot as well, luckily it's possible to have GRUB as a SeaBIOS secondary payload - adding manually after the coreboot build completion - and the SeaBIOS itself occupies less than 100 KB if I remember correctly

[Guest]

Sorry, I almost forgot to tell what this floppy-adding command is:

./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f ./your_floppy_image.img -n floppyimg/your_floppy_name.lzma -t raw -c lzma

Where after -f is a path to your floppy image and after -n floppyimg/ there's a floppy name inside the CBFS.

Actually this floppy loading feature is provided by SeaBIOS rather than a coreboot, but since a SeaBIOS seems to be the most popular coreboot payload based on .config stats - almost everyone could use this feature. After following the example above, this floppy will be displayed at SeaBIOS boot menu as:

[number] your_floppy_name [ramdisk]

I see that you'd like to have a GRUB at coreboot as well, luckily it's possible to have GRUB as a SeaBIOS secondary payload - adding manually after the coreboot build completion - and the SeaBIOS itself occupies less than 100 KB if I remember correctly

IIRC you can do it the other way as well and run SeaBIOS from GRUB if you need it. For me, there's no need for a BIOS or UEFI implementation, as it's just a waste of time on each boot. It might matter to some if they wan to use operating systems that won't boot with bare GRUB. I'd be almost fine with a way to just go straight to the kernel, but that throws the posibility of disaster recovery out the window, and you can't easily change kernel parameters (especially when your motherboard doesn't seem to work with internal flashing and trying to do so causes it to brick itself).