Thank you for your quick reply!
On 12/10/07, Tom Sylla tsylla@gmail.com wrote:
On Dec 9, 2007 4:15 PM, Martin-Éric Racine q-funk@iki.fi wrote:
As far as I can tell, 'flashrom' would need to read some register (DIVIL_BALLS - see AMD document 3328G_cs5536_db.pdf page 365) to learn what is the primary boot device configured by the bootstrap resistors and then try to find the NOR chip used for storing the BIOS there at that location.
It is not necessarily *required* for flashrom to do that. The PRI_BOOT_LOC bits of that MSR say where the transactions go, that is all. If they are set to 0'b10, transactions above 0xf0000000 go to the flash controller. When flashrom does the ID sequence, things should just work.
Unfortunately, they don't.
One complication is that the flash controller has a "write enable" bit for each of its chip selects. You will find them in the "NOR Flash Control" MSR. If writes are not enabled, the ID won't even work. (LB flashrom only comprehends the CPU RCONF write protection disabling, and does not comprehend the flash controller write enables)
Would this be difficult to implement? It seems likely that this is the only show stopper left.
If you are having some sort of specific problem, please give some detail. My guess is that no ROM is identified on your flash interface platform, but it does get detected on the LPC platform.
Neither work out of the box.
Right now, we're forced to use a deprecated hack from AMD called gx_util.c (a non-free kernel module whose only purpose is to play with the MSR) to flip the register. We even ended up having to hack a slightly different version of this module to work with the new platform featuring the NOR on the LPC hub.
Best Regards,