I tried to update the BIOS firmware on this board (the GIGABYTE MZ242-G20 in a G292-Z40 chassis) using `flashrom -pinternal`. This did not work, as it failed to find an appropriate erase function. I subsequently re-flashed using the BMC, which recovered the machine. Investigating the .bin files at the various stages, it appears that the erase did actually work, except that regions below 0x01000000 always read back as 0xFF under flashrom (while a proper SPI readback over the BMC shows this not to be the case). This board is an AMD Zen3 mainboard so the flasher in question is sb600. Looking at the image, I believe the regions above and below 0x01000000 are used as part of a dual bios setup, as they are substantially identical. Perhaps there are some protection registers in the SPI bus master that flashrom needs to be aware of in order to properly read this SPI flash?
Keno
Hello Keno,
On 27.10.21 20:59, Keno Fischer wrote:
I tried to update the BIOS firmware on this board (the GIGABYTE MZ242-G20 in a G292-Z40 chassis) using `flashrom -pinternal`. This did not work, as it failed to find an appropriate erase function. I subsequently re-flashed using the BMC, which recovered the machine. Investigating the .bin files at the various stages, it appears that the erase did actually work, except that regions below 0x01000000
I guess there's the issue, your flash chip is bigger than 16MiB, right? Support for >16MiB is known broken for Zen systems. The review for the commit that added the Zen support[1] mentions low quality of downstream commit messages that led to not knowing why the code was written as it is. So it can't be fixed without the original author looking into it. IMO, it looks borked. Why it was merged in this state is a mystery to me. I tried to get the submitter to look into it without success.
If you want, I could write a patch that you could test? I'd simply remove the inexplicable code. Worth a shot, IMO.
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).
Nico
[1] https://review.coreboot.org/c/flashrom/+/44073/comment/98f16693_5ef6976a/
Hi Nico,
Thanks for looking into it.
On Fri, Oct 29, 2021 at 9:15 AM Nico Huber nico.h@gmx.de wrote:
I guess there's the issue, your flash chip is bigger than 16MiB, right?
Yes, the BIOS flash chip on these boards is 32MiB.
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.
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.
Nico
[1] https://review.coreboot.org/c/flashrom/+/44073/comment/98f16693_5ef6976a/
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
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
Hi Keno,
On 03.11.21 03:22, Keno Fischer wrote:
I have tested both patches, and both work and reproduce exactly the BIOS image that the BMC reads. Thanks for taking this on!
thanks for testing! If you ever get the chance to test write support, some verbose logs would be nice. Best when writing random data, e.g. created with
$ dd bs=1M count=32 if=/dev/urandom >random_32mib.rom
Nico
[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
-
Keno Fischer -
Nico Huber