bios asus P3V4x or P6VBX2

[bertrandbd]

A friend of mine gave me 2 motherboards & a PIII (450) after of bad flash on each mobo.

As I didn't know if the processor worked, I made a little program to generate a beep that use only registers. As it was working (config: no ram, no video), I concluded that the processor works even it does not proove that address or data buses are good.

I've graved with a flash programmer (Data IO), the bios of asus board P3V4X (256 Ko) and the bios of lucky board P6VBX2 (128 Ko). For the last one, I've filled the 128 Ko with FF value (copy/b file_FF + LFA3-0-3.bin). I don't any doubt on the flash operation that I have made successfully with a K6-2 on gigabyte Mobo (GA 5SG 100)

I've tried to boot with both motherboards with no success. I made it either with minimun configuration (no ram no video) either with a consistency configuration (Ram and Isa video board).

Of course, I made also a shortcut between A17 and A16 pins but it did not change anything.

Currently, I have no idea of what I can do to recover the boards even if to boot on block boot bios seems the best solution.

In others woords, what can I do?????????

Thank you for your help


Configuration details
PIII 450
Asus P3V4X, Via 82C694X & Via VT82C596B, Flash ATM 49F002T (256 Ko), award bios (files P3V4X105.AWD, 1006.003)
Lucky P6VBX2, Via 82C596B 82C693, Flash ATM 49F002T, award bios (AF2-7.bin, LFA3-0-3.bin)
Gigabyte 5SG 100 Sis 5595 & 5591, award bios, Flash winbond 128 KO

I have made some hot flashs with uniflash, aflash, awdxx but with GA mobo but I did not work (Pb of flash size)

I can patch the bios and flash it.

question about bios:
- To boot on bootblock what is the minimum configuration needed? (Ram & video are there mandatory?)
- If the boot block makes the CRC of bios, a byte modification in main bios leads to boot on blockboot due to a CS error?
- Is it possible to set the reset vector with the address of bootblock that makes a recovery procedure?

[ruelnov]

If /wb switch is not used in all previous flashes, then bootblock is still intact and recovery is possible.

RAM is mandatory in bootblock recovery. Video is not needed if your floppy diskette contains the autoexec.bat file for automatic flashing.

AFAIK, shorting 2 high address pins doesn't work on all Flash ROM's. But you can try shorting the #WE pin with the highest-numbered address pin (you would need the datasheet for each Flash ROM to locate these pins). This worked on my system which refused to wake up using the 2 high address pins.

[bertrandbd]

Thank you for your information

First of all, bios has been graved with Data IO and not by award flash routine, so the bootblock has been superseed.

I try to shortcut the Write Enable pin with A17 on asus and lucky bords but unfortunately it does not work (no beep, no access to floppy disk, no video message). Just a precision there is no keybord connected

[ruelnov]

If your bootblock has been overwritten (as you wrote), it might have become corrupted and that's why your boards refused to wake up.

[bertrandbd]

Ok, it might be an explaination but do you think that when I flash the new asus bios including bootblock with data IO, the bootblock is not consistency with the old bios?

That could let say, that different versions of asus bios for a same board have no the same blockboot?

[ruelnov]

You could try it and see if it works.

But in my preliminary analysis of various bootblocks for the same motherboard, I noticed that there are significant differences in code content. Which means that every bootblock is fine-tuned to be compatible with the included decompression block, original.bin, etc.

[bertrandbd]

I compare the 3 bootblocks of asus board (P3V4x) and I find always the same five bytes that are differents

Comparaison des fichiers boot105.001 et boot1006.003
000000C5: 86 B6
00000102: 1A 48
000001C1: BC EA
00000256: 34 64
000014D2: 01 31

Comparaison des fichiers boot1006.003 et boot1006.004
000000C5: B6 C2
00000102: 48 54
000001C1: EA F6
00000256: 64 70
000014D2: 31 3D

As these bytes are data bytes may be they set the bios version ? ???

Who can help me or answer to the question of first message. I would like to be sure that only bootblock is in charge of crc computation. So it will ne possible for me to flash only bootblock

Thank you

[ruelnov]

As far as I know, the BIOS ROM Checksum Calculation (you call it crc) is done by the decompression block which is separate from bootblock. But flashing bootblock usually also updates the decompresion block (if you use /wb switch in award flash utility), because these 2 blocks have to be compatible (they call each other during POST).

If you flash bootblock by some other utility, you just have to find a way to update the decompression block as well.

But you cannot just flash bootblock using bootblock from another board (I have tried this and my system failed to boot) because the hardware initialization routines initiated by bootblock and decompression block have to be compatible with the system chipset and other peripherals.

Regarding the bootblock comparison that you posted, the bios version is not set by either bootblock or decompression block. But you can tell if that bootblock is intended for your board by looking at the last few lines in Hex Editor (like this one for my system which tells me that it's for the board with a BIOS ID of 6A6IRZ19):

seg000:1FE8 db 36h ; 6
seg000:1FE9 db 41h ; A
seg000:1FEA db 36h ; 6
seg000:1FEB db 49h ; I
seg000:1FEC db 52h ; R
seg000:1FED db 5Ah ; Z
seg000:1FEE db 31h ; 1
seg000:1FEF db 39h ; 9
seg000:1FF0 db 0EAh ; O
seg000:1FF1 db 5Bh ; [
seg000:1FF2 db 0E0h ; a
seg000:1FF3 db 0 ;
seg000:1FF4 db 0F0h ; =
seg000:1FF5 db 2Ah ; *
seg000:1FF6 db 4Dh ; M
seg000:1FF7 db 52h ; R
seg000:1FF8 db 42h ; B
seg000:1FF9 db 2Ah ; *
seg000:1FFA db 2 ;
seg000:1FFB db 0 ;
seg000:1FFC db 0 ;
seg000:1FFD db 0 ;
seg000:1FFE db 60h ; `
seg000:1FFF db 54h ; T
seg000:1FFF seg000 ends
seg000:1FFF
seg000:1FFF
seg000:1FFF end

[bertrandbd]

Thank you first for your reply

As the bootblock alone can not run properly, it discard my first idea to grave only bootblock to recover the mobo.

Normaly, I flash the totality of the bios binary file with Data IO. Do you think that flash utilities make something else? If flash utilities make some code modification or mapping modification on bios binary file, all the bios that I flash can not run. I'm interrested by information on this topic.


Unfortunatly, I'm not able to use uniflash or award flash because the mobo that I use to do it are only 128 Kb flash prom. So, I never do a success hot flashing for 256 kb flash. May be I dont use it correctely or address bus (A17 line) is not wired ?


The mobo are:
GAbyte mobo described in my first message
Spacewalker mainboard Chipset Intel 82438vx, 82437vx, 82371sb

[ruelnov]

The flash utilities do some mapping of the bios so that each module (bootblock, decompression block, main bios file, etc.) are written to their corresponding blocks in the flash rom, or else the CPU could not read the bootblock at boot time if it's not in its proper location (usually at the far end of the flash rom block).

As far as I know, 8086-based processors are directed at boot time to read the instruction located at F000:FFF0 in the bootlock area of the flash rom. This is the first instruction executed by the CPU which branches to a number of instructions within the bootblock and decompression block, the purpose of which is to initialize/wake up your system. That is why bootblock has to be in its right location in the flash rom.

[bertrandbd]

When I grave the flash with DATA IO, the location of the bootblock is on the low level of the flash (@ range: 3E0000 - 3FFFF for a 256 kb flash). This address should match with the reset vector of 80x86 which is FFFF0 (F000:FF00). In the bootblock, the reset vector is set with @FE05B (F000:E05B) address. After that, it is not obvious to disassemble the code.

Nevertheless, I will make a test with the gigabyte bios that runs correctely. For this bios I will use the binary file supplies by Gigabyte and normaly used with flasher utility.
This test will check that the Data IO is able to grave correctely the bios.

I need a couple of days but I'll give you the result

[Denniss]

Do I understand this correct :
- Both corrupted Bios are 256KB ones
- The GA-586SG-100 uses 128KB Bios and is not able to flash 256KB ones
- The even older Soyo mainboard has the same problem like the Gigabyte

Have you tried to flash the Bios on the older boards ?
-> At least half of the chip should be rewritten - maybe the bootblock part is inside this half so a reflash via bootblock Bios on the correct board might be possible

Don't you have a friend with a spare board using 256KB Flashroms

[bertrandbd]

Do I understand this correct :
- Both corrupted Bios are 256KB ones
ans: Yes the both are corrupted

- The GA-586SG-100 uses 128KB Bios and is not able to flash 256KB ones
ans: that's right but I dont know if it is a bus address problem or an incompatibility between chipset and falsh programm
- The even older Soyo mainboard has the same problem like the Gigabyte
ans : yes

Have you tried to flash the Bios on the older boards ?
Ans: no sorry I haven't

-> At least half of the chip should be rewritten - maybe the bootblock part is inside this half so a reflash via bootblock Bios on the correct board might be possible
Ans: No even if theorically it should possible, when I grave flash with uniflash or award with these two old boards, all memory areas are corrupted even the bootblock. I understand that you recommend me to flash a half bios to have the opportunity to reboot on bootblock due to a CS error?
May be I don't launch uniflah or award routine with the good options?

Don't you have a friend with a spare board using 256KB Flashroms
Ans: Most of my friends have recent motherboards and the flash proms have PLCC package so ...
Nevermind, I make several tests using the data IO mean with gigabyte board and may be I will have a better idea of the problem with asus board

Thank you for your reply

[bertrandbd]

First, thanks to Ruelnov and deniss for their help. I hope that message can help someone.


I burned two flashes with Data IO tool, the first on with the bios and the second on with the bootblock only
To avoid some addressing problem, I burned the same bios in the top (0--1ffffh) and the bottom (20000--3ffff).
For the bootblock, I grave only one image in the bottom of the flash (20000h - 3ffffh). I used the gigabyte motherboard (see first message)


Tests with Bios
----------------
First test: configuration: Ram, keyboard, Isa video board, floppy disk
I plug the new flash and the bios started correctly (one beep).
The is only one alert message " unknown flash"

2 test:
Same as test 1, but without keyboard. No error beep and same message that in case 1

3 test:
Same as 2 with different locations of SDRam Dimms: no sensitive

4 test:
Remove the Ram, then continuous beeps, no more video message and no access to floppy disk

5 test:
Replace SDRAM but remove video board: one long beep and 3 shorts. Access to the floppy disk

6 test:
Remove the battery (from 5s to 30s): no losses of cmos parameters but date & time have been erased


Test with bootblock
--------------------
1 test: dump memory flash with uniflash. The dump file shows two bootblocks instead of one
The explanation is that the A17 line is not connected to the flash but certainly takes part of chip select logic.

2 test: Attempt to start with the bootblock. No beep, no video signal, no access to the floppy disk.

3 test: Attempt to use uniflash to grave 2 bootblocks in the flash
Error during the flash procedure and mobo didn't started

4 test: Attempt to grave the same binary file that I use with data IO tool
Error during flashing and mobo didn't start

I will try to flash with data IO 2 bootblocks to test if recovery procedure can be launch only by the bootblock

Conclusion: - Data IO tool is an efficient mean to grave Bios
- When the flash size is 256 kb it doesn't imply that the bios size is the same than flash component.
In that case, the memory location of bios starts to 20000h when A17 is used for chip select logic
- The minimum configuration to recover the bios needs SDRAM and floppy disk
- There is some problem with uniflash to grave a 256 kb memory with a mobo that addresses 128 kb bios flash.
An improvement of uniflash will be to be able to specify the location of bios in the flash

Now, I can use the 128 kb flash of the gibabyte motherboard to make few tests with asus and lucky motherboard

I yo have any comments or questio on the tests, I'll try to answer you

[bertrandbd]

I have graved the bootblock only in the flash. The bootblock has launched with CS error message so only bootblock integrity is necessary to recover a bas flash bios.
===============================================
I follow the same procedures with the lucky & asus board and it didn't work.

Anyone have an idea? Is it possible that it runs for the award bios on gigabyte and not on award bios of asus & lucky borad?
Is there a routine that checks the minimum hardware configuration (sdram) and flashable instead of bios flash?

Thank you for your answer