5 ms·
Intel is equally blobby (FSP, ME).
by hlandau 7y ago
Intel is equally blobby (FSP, ME).
- shmerl 7y agoWorks with coreboot though somehow. AGESA prevents it as far as I know, since it does some stuff that coreboot has to be doing. I'm not that familiar with details, may be some coreboot experts can comment.
- hlandau 7y agoCoreboot integrates plenty of blobs via its blobs repository, so "Coreboot builds" does not imply "blob-free".
- shmerl 7y agoThen AGESA must be posing some problem for it.
- tpearson-raptor 7y agoThe ancient AGESA open sourced well over a decade ago, then closed down a few years later right about when the PSP started to appear on AMD platforms? Or do you mean the modern AGESA binary that has zero support whatsoever in coreboot right now?
- shmerl 7y agoI mean AGESA that's used for new AMD CPUs.
- tpearson-raptor 7y agoOK, that makes sense. And yes, it causes problems for coreboot -- AIUI there are no modern AMD systems supported, because AMD has not allowed use of the AGESA blob in that way.
- pgeorgi 7y agocoreboot on modern Intel requires (some amount of) ME firmware (without which the x86 core wouldn't even turn on) + some parts of the Intel FSP binaries. coreboot on modern AMD requires (some amount of) PSP firmware (without which the x86 core wouldn't even turn on) + some parts of AGESA which were most recently shipped as "BinaryPI". The situation is comparable, just that Intel has ~7 years of dealing with coreboot through Chromebooks now, while AMD dropped the ball after a great start and only picked it up again recently. If AMD sticks to the current trajectory, Intel and AMD would be similarly well supported in coreboot (with a similar amount of blobs required) at some point in the near future. If you're aiming for fully blob-free operations, look for chips not newer than the early 90s. If you can live with not having loadable blobs (while boot ROMs on the CPU die are acceptable), that extends into the late 2000's, but requires some care when selecting your gear. I wouldn't put any hopes on RISC-V when it comes to avoiding blobs because all higher performance variants will use the same "strings attached" high performance memory and bus controller function blocks whose developers will mandate a certain level of blobbiness.
- floatboth 7y ago> requires some care when selecting your gear Doesn't that mostly boil down to "avoid anything newer than Ivy Bridge/Bulldozer"? > high performance memory […] controller function blocks There are DDR4 controllers with FOSS training code out there :) https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/tree/mv_ddr-armada-atf-mainline https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/...
- tpearson-raptor 7y agoHere's POWER's training code for DDR4: https://git.raptorcs.com/git/talos-hostboot/tree/src/import/chips/p9/procedures/hwp/memory https://git.raptorcs.com/git/talos-hostboot/tree/src/import/... pgeorgi has a valid point in that if you go for the cheapest off the shelf building block type DDR4 solution for your silicon design (won't name names here, but it's a widely known vendor in the silicon block space), those controllers come with mandated binary-only firmware. IBM (and apparently Marvell?) both didn't use that cheap off the shelf solution and also decided to release their training code. Kudos to both companies for bucking the trend here!
- wtallis 7y agoYou might be mistaking coreboot for libreboot, the coreboot fork that rejects all proprietary blobs.