[coreboot] Binary situation
david.c.hubbard+coreboot at gmail.com
Tue Dec 24 02:56:31 CET 2013
On Mon, Dec 23, 2013 at 3:21 PM, Rudolf Marek <r.marek at assembler.cz> wrote:
> Hi all
> Some time ago Patrick started a https://www.coreboot.org/Binary_situationpage which I updated in the past days. It monitors the various blobs and
> firmwares in the Intel and AMD systems. Good news is that Roxfan and I
> managed to get some ideas about AMD XHCI firmware and I added also some
> information about SMU, GEC and IMC firmwares. The page has some links were
> you can get more detailed information. As for now it looks we now know all
> processors types for each firmware :)
> Please don't expect more about that, it could be small step for some
> future "free" firmwares, but for me it current state enough.
> As for the AMD systems, XHCI firmware "bad" intentions can be most likely
> stopped by IOMMU, same is valid for "GEC". IMC can be safely left unused.
> This leaves only the SMU firmware which may or may not have some DMA
It might be helpful to document the intended use case for each device.
Basically, the industry has started using overloaded meanings for words
that a newcomer might find hard to decipher.
This is going to show some holes in my knowledge, but here's an example:
XHCI: USB3 controller. Firmware is needed because USB3 designs try to
operate without touching system RAM when not doing anything useful, so they
need an embedded CPU. (This helps because the main CPU may be asleep, but
if RAM changes it can trigger cache invalidation, leading to worse battery
IMC: the AMD version of the EC (Embedded Controller). This handles system
management such as: system power on/off and the sequence of events required
to bring the system up and run the BIOS. Temperature and fans, emergency
shutdown in case of overheat or fan failure. Battery level and emergency
events when the battery gets too low or fails.
SMU: the explanation on https://www.coreboot.org/Binary_situation is good,
in my opinion
> As for the Intel systems, my biggest fear is ME firmware, which is even
> designed to do things sideways.
> From all above think best would be to concentrate on VGA BIOS replacements
> and possibly a MRC.bin replacement, which runs on x86 CPU. I'm considering
> the rest of the firmwares as part of the hardware although it would be
> nice to audit at least the function which could be now possible even it
> will take long time.
> Please try not to start any flamewar about "firmwares should be free"
> instead please help and audit the firmwares or write a replacements.
> Please note that even devices without any loadable firmware may do bad
> things. Don't forget about that. Firmwares just gives us good opportunity
> to see things otherwise impossible to see (chip mask rom for example).
I have been making slow progress on an AMD native VGA init. To anyone
interested in working on it: please email me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot