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...
Hrm.
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.
Facts:
- 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: http://www.ami.com/support/doc/AMIBIOS8-Flash-Recovery-Whitepaper.pdf 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 crashfree :)
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 southbridge specific.
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 at all?
Luc Verhaegen.