Thank you for your quick reply! On 12/10/07, Tom Sylla <[EMAIL PROTECTED]> wrote: > On Dec 9, 2007 4:15 PM, Martin-Éric Racine <[EMAIL PROTECTED]> 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, -- Martin-Éric Racine http://q-funk.iki.fi -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
