Greetings,
I was wondering if anybody ever managed to get the current LinuxBIOS 'flashrom' utility to correctly detect the location of the BIOS chip with a Geode LX and CS5536?
Here, I have two platforms with slightly different settings:
platform 1: NOR chip on the flash controller. platform 2: NOR chip on the LPC hub.
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.
Is the LinuxBIOS 'flashrom' currently incapable of doing this or am I missing something?
To answer an obvious question, yes, the kernel's 'msr' module is loaded before launching 'flashrom', so it's probably something else.
Best Regards,
On Sun, Dec 09, 2007 at 11:15:45PM +0200, Martin-Éric Racine 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)
..
Is the LinuxBIOS 'flashrom' currently incapable of doing this
Well, it doesn't do it. But it does have msr read/write functions, so it should not be too difficult to add.
I don't know what is needed when flash is not on LPC though.
Does flashrom have to care where it is?
//Peter
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.
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)
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.
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,
I use a script to set DIVIL_BALLS FWIW.
but auto sensing? Never worked for me. Is it really possible?
ron
On 12/11/07, ron minnich rminnich@gmail.com wrote:
I use a script to set DIVIL_BALLS FWIW.
but auto sensing? Never worked for me. Is it really possible?
Dave Frodin of AMD replied on the Geode mailing list (talking about how their non-free gx_util.c and closed-source AMD flashrom work):
In regards to gx_util usage, /dev/mem will not work for accesses to the very top of memory. I believe it will not allow access to the top 64k bytes of memory. Which is fine unless you want to modify the system BIOS.
In regards to the DIVIL_BALL settings. FlashROM checks to see what device was booted from (i.e. LPC, flash controller) before the flash device is identified. If the boot device is the flash controller, FlashROM has to flip the IDE/flash switch before any accesses to the flash device since the IDE interface is most likely where FlashROM and any BIOS images exist.
Which, if I'm not mistaken, is actually the opposite, since IDE and NAND controllers are mutually exclusive, while NOR flash used for system BIOS sits somewhere else?
Anyhow, beyond scanning DIVIL_BALLS, it appears that if something *other* than the LPC hub is found as the primary device, a bit must be switched to actually be able to access the chip.
On Dec 11, 2007 2:42 PM, Martin-Éric Racine q-funk@iki.fi wrote:
In regards to gx_util usage, /dev/mem will not work for accesses to the very top of memory. I believe it will not allow access to the top 64k bytes of memory. Which is fine unless you want to modify the system BIOS.
I don't understand this comment. Can somebody clarify this a bit?
In regards to the DIVIL_BALL settings. FlashROM checks to see what device was booted from (i.e. LPC, flash controller) before the flash device is identified. If the boot device is the flash controller, FlashROM has to flip the IDE/flash switch before any accesses to the flash device since the IDE interface is most likely where FlashROM and any BIOS images exist.
I don't get this one either. What does the IDE/FLASH switch have to do with BIOS?
I think there is more confusion going around, certainly in my case, than I know what to do with :-)
thanks
ron
ron minnich wrote:
On Dec 11, 2007 2:42 PM, Martin-Éric Racine q-funk@iki.fi wrote:
In regards to the DIVIL_BALL settings. FlashROM checks to see what device was booted from (i.e. LPC, flash controller) before the flash device is identified. If the boot device is the flash controller, FlashROM has to flip the IDE/flash switch before any accesses to the flash device since the IDE interface is most likely where FlashROM and any BIOS images exist.
I don't get this one either. What does the IDE/FLASH switch have to do with BIOS?
If the system uses flash storage instead of IDE it could also use flash for the BIOS. The above comments are correct about doing the switch but why boot from flash and switch to IDE? If it is an IDE based storage system put the BIOS on LPC like normal.
A way to work around the image source problem is to use a USB drive.
Marc
On 12/13/07, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
On Dec 11, 2007 2:42 PM, Martin-Éric Racine q-funk@iki.fi wrote:
In regards to the DIVIL_BALL settings. FlashROM checks to see what device was booted from (i.e. LPC, flash controller) before the flash device is identified. If the boot device is the flash controller, FlashROM has to flip the IDE/flash switch before any accesses to the flash device since the IDE interface is most likely where FlashROM and any BIOS images exist.
I don't get this one either. What does the IDE/FLASH switch have to do with BIOS?
If the system uses flash storage instead of IDE it could also use flash for the BIOS. The above comments are correct about doing the switch but why boot from flash and switch to IDE? If it is an IDE based storage system put the BIOS on LPC like normal.
A way to work around the image source problem is to use a USB drive.
I think that one misunderstood piece of info is what the different combinations of boot devices are possible on the LX, how this affects where the BIOS chip can end up in the food chain and how the bootstrap settings can affect this. Perhaps a recap would be in order for everyone's benefit?
On Dec 12, 2007 6:01 PM, Martin-Éric Racine q-funk@iki.fi wrote:
I think that one misunderstood piece of info is what the different combinations of boot devices are possible on the LX, how this affects where the BIOS chip can end up in the food chain and how the bootstrap settings can affect this. Perhaps a recap would be in order for everyone's benefit?
It is all in the datasheet (Table 3-5. Boot Options Selection), but here is a description:
First of all, you really mean "boot devices on 553x", not "boot devices on LX".
There are 3 supported locations for a boot ROM on 553x: LPC ROMs on the LPC pins, FWH ROMs on the LPC pins, and parallel NOR ROMs on the flash pins. Your platform picks one of the 3 locations by using strap pins on 553x.
At reset, those straps are sampled, determine where the first fetches go, and are also latched into the DIVIL_BALL_OPT MSR in two locations, one set of read-only bits (BOOT_OP_LATCHED), and one set of bits that can be modified (PRI_BOOT_LOC).
There are several different configurations possible with these options. The common and simple one is to boot from an LPC ROM and PRI_BOOT_LOC is never changed. Flash programs don't have to do anything special (except the CPU-level un-write-protecting).
One slightly more complicated setup is for a platform to boot from a parallel NOR device on the flash pins. After shadowing, the firmware changes the pins to IDE mode (the parallel flash and IDE pins are muxed on 553x). The system can boot from IDE. You might think this is a silly configuration, and you could just use an LPC or FHW ROM, but there is one advantage. GPIOs are always at a premium in embedded-land. All of the LPC signals can also be GPIOs on 553x, so you can get 7 more GPIOs if you never have to use LPC. It is probably uncommon, but you may encounter a platform that does this. (the IDE/flash muxing and LPC/GPIO muxing is also done with bits in DIVIL_BALL_OPT)
The flash-to-IDE switch is pretty simple, the firmware is in control, and it flips the pins when it is sure that it does not need to access the ROM any more. Switching back is a little bit harder. The "flashrom" and xxx.rom files are probably on IDE, so the AMD flashrom is very careful about how it handles this case. As Marc said, doing this while booted from USB is an easy way to make things less complicated.
Basically, a flash program can just look at the latched boot options to know where the ROM is. The flash program then needs to modify the muxing and PRI_BOOT_LOC bits to put things back as it was at boot, and then re-flash. There are various complications if your goal is to do this in Linux (IDE drivers don't like their pins being taken away from them, etc)
On 10/12/07 16:45 +0200, Martin-Éric Racine wrote:
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.
Then you already know what you need to do. I have said this numerous times, but I'll say it again. I've seen the gx_util code - all it does is access MSRs, access memory, and access I/O ports, all of which can be done easily with existing interfaces.
To read (or write) a MSR:
open /dev/cpu/0/msr fseek to the MSR address (i.e. fseek(fd, 0x1808);) read or write 8 bytes from the file (read(fd, msr, 8))
to read (or write) to memory: open /dev/mem mmap the range of memory that interests you (i.e base 0xfe00000, length 0x10000 or whatever you need) Read and write to that memory as usual
to read (or write) to memory:
set permissions (iopl(3);) Use userspace versions of inX and outX functions as required
Thats it - if you do these three things then you have successfully emulated the behavior of gx_util with community friendly interfaces. Some combination of these will get you to where you want to be.
Jordan
-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
-
Jordan Crouse -
Marc Jones -
Martin-Éric Racine -
Peter Stuge -
ron minnich -
Tom Sylla