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 <[email protected]> wrote: > > Hi Keno, > > On 29.10.21 22:08, Keno Fischer wrote: > > On Fri, Oct 29, 2021 at 9:15 AM Nico Huber <[email protected]> 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 _______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
