<div dir="ltr">Hi Rudolf,<br><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 23, 2013 at 3:21 PM, Rudolf Marek <span dir="ltr"><<a href="mailto:r.marek@assembler.cz" target="_blank">r.marek@assembler.cz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all<br>
<br>
<a href="https://www.coreboot.org/Binary_situation" target="_blank">https://www.coreboot.org/<u></u>Binary_situation</a><br>
<br>
Some time ago Patrick started a <a href="https://www.coreboot.org/Binary_situation" target="_blank">https://www.coreboot.org/<u></u>Binary_situation</a> page 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 :)<br>
<br>
Please don't expect more about that, it could be small step for some future "free" firmwares, but for me it current state enough.<br>
<br>
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 capability.<br>
</blockquote><div><br></div><div>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.<br>
<br>This is going to show some holes in my knowledge, but here's an example:<br><br>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 life.)<br>
<br></div><div>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.<br>
<br></div><div>SMU: the explanation on <a href="https://www.coreboot.org/Binary_situation">https://www.coreboot.org/Binary_situation</a> is good, in my opinion<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for the Intel systems, my biggest fear is ME firmware, which is even designed to do things sideways.<br>
<br>
>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.<br>
<br>
Please try not to start any flamewar about "firmwares should be free" instead please help and audit the firmwares or write a replacements.<br>
<br>
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).<br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
Rudolf</font></span><br></blockquote><div><br></div><div>I have been making slow progress on an AMD native VGA init. To anyone interested in working on it: please email me.<br><br></div><div>Thanks,<br>David<br></div></div>
</div></div>