[LinuxBIOS] CrashFree, Virtual DualBIOS, etc.OA
libv at skynet.be
Sun Mar 4 14:49:27 CET 2007
On Sat, Mar 03, 2007 at 08:26:07AM +0100, Luc Verhaegen wrote:
> On Fri, Mar 02, 2007 at 05:22:57PM +0100, Uwe Hermann wrote:
> > I think we should have a section in the FAQ/wiki about all these
> > CrashFree, Virtual DualBIOS and whatnot features...
> First of all, let me assert that i have absolutely no clue about
> flashroms, so i might be talking pure rubbish here. But let me line up
> some facts, and what i think might be going on here.
> * The part itself is an SST39SF020A, a well known 256kB part.
> * flashrom is reading: id1 0x25, id2 0x1e with probe_jedec at 256kB.
> * Asus provides a 256kB (exactly) BIOS Image for this board, so it will
> be filling this rom completely.
Google turned the following AMI document:
where the use of a boot block is somewhat explained.
This looks like this just is about reserving part of the rom for an
image that's just enough to recover from a broken/failed main image.
AMIs own utilities give one the option to also overwrite this area, so
it seems like it is all in these utilities, and that there's no extra
hardware involved at all.
So flashrom should probably see no difference at all.
My guess is that the crashfree award BIOS on that Asus board of mine is
nothing different from AMIs boot block. Looking closely at the manual,
looking for some "BIOS protect" option, there was a section about
Crashfree there. It does allow you to recover from a failed flash.
I did find the following excerpt quite amusing:
"To use the CrashFree BIOS feature on this motherboard, install a VGA
card into one of the expansion slots before rebooting the computer. On
motherboards with onboard VGA, you will not see the screen display when
the BIOS crashes even if you reboot the computer."
On VIAs IGP chips (unichrome/chrome), in the not too distant future,
this (amongst other things) is where linuxbios will be bettering Asus's
Anyway, i'm now more convinced that flashrom failing to ID the rom is
probably not due to Asus's crashfree. I should probably go and poke
those io lines again and see if anything changes.
uniflash knows about an asus board with a KT400 (a close relation of the
OAKM400, but lacking the IGP) board. And it seems to enable a different
io line (through a different mechanism), even though it uses the exact
same southbridge. It seems that the io line used is board and not
Stefan, do you have some recollection what board, specifically, that io
line change in flash_enable_VT823x is/was for?
Also, if the chip is still locked down, would it be returning a bogus ID
or would it be returning 0xFFFF as when you try to access it at
512/1024kB? Does the fact that it returns 0x1E25 have any significance
More information about the coreboot