Hi Nico,
I have tested both patches, and both work and reproduce exactly the BIOS image that the BMC reads. Thanks for taking this on!
Keno
On Sun, Oct 31, 2021 at 11:25 AM Nico Huber nico.h@gmx.de wrote:
Hi Keno,
On 29.10.21 22:08, Keno Fischer wrote:
On Fri, Oct 29, 2021 at 9:15 AM Nico Huber nico.h@gmx.de wrote:
If you want, I could write a patch that you could test? I'd simply remove the inexplicable code. Worth a shot, IMO.
Happy to test a patch for the read path. I did put the machine into production now, so I would prefer to avoid accidentally erasing the BIOS again. I did put in a request with the vendor to send me a dev board for testing, so I may have that in a few weeks, but until then, I'll play it a little more carefully.
I eventually wrote two patches. The first [2] just removes the inex- plicable kludge. However, looking into the code I found a possible explanation why it might have been necessary: The chipset might allow to restrict the set of SPI commands that can be sent. It's possible that the command flashrom uses for reading is not always allowed. As the code is written without any error checking, that might lead to the conclusion that no reading command is supported.
The second patch [3] would change the set of commands used to access a
16MiB chip. I think (but can't give any guarantee) that read testing
should be safe. So it would be nice if you could give a checkout of each patch a try. Even when it works, you might still see some differences compared to a dump done with your BMC, as the firmware may write some things on each boot.
However, without risking to break somebody else's use case there is not much that can be done upstream as AMD doesn't publish datasheets for their chips (better to avoid AMD if one wants free software, IMHO; they release some code from time to time, but they don't support free software developers with the necessary documentation).
Is there a particular document that you know that you need? I've sometimes had luck getting these kinds of things released. Unfortunately, I don't have very many contacts at AMD, but it helps to know what to ask for. Particularly for things like the SPI controllers, that doesn't feel like it should be especially sensitive.
I don't have an NDA with AMD, so I don't know what documents they have available. I found some pieces in a public BKDG [4] now, but it's very thin. There are register descriptions, but nothing about how the whole thing works together. For instance, there is support to read/write protect arbitrary address ranges, but no hint when the addresses of SPI commands are matched. Shouldn't hurt to ask for the BKDG (bios and kernel developers guide) for your particular (or any current) SoC. One where the SPI parts weren't scrubbed ofc. Judging from what I heard about AMD, they won't publish it, though.
Technically, there is nothing sensitive in their docs. They just like to stay in control of every bit, it seems. Even if that makes their customers suffer.
Anyway, even with the thin documentation, one could already write three times as much code as is currently present in flashrom. Some error checking and reporting the configuration of the chipset could already shed some light on how it works. But one needs the hardware at hand to test it...
Nico
[1] https://review.coreboot.org/c/flashrom/+/44073/comment/98f16693_5ef6976a/
[2] https://review.coreboot.org/c/flashrom/+/58776 checkout with: git fetch https://review.coreboot.org/flashrom refs/changes/76/58776/1 && git checkout FETCH_HEAD [3] https://review.coreboot.org/c/flashrom/+/58777 checkout with: git fetch https://review.coreboot.org/flashrom refs/changes/77/58777/1 && git checkout FETCH_HEAD [4] https://www.amd.com/system/files/TechDocs/55570-B1-PUB.zip