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)