I do not think there is a list in the BIOS (have hexed many and never saw one), if it is newer PnP board and writes ESCD then BIOS expects a specific BIOS chip model or equal to write to, which usually can be obtained from the the original flash utility for the specific board. Will post an example asap.....but narrowing down to the exact chip may be near impossible....
added: maybe a newer BIOS on a 2mbit chip could have a table/list but know the Pentiums, SocA, P2 etc I messed with do not. BIOS attempts to write ESCD and checks and if not you get a Update failure (same can happen with bad bios chip though)

Believe it or not I was looking at this yesterday. Here is part of one such BIOS. The "unknown flash type" seems tied to whether f000:ea5a holds an FF byte or not which in turn may have something to do with whether we are talking about offset 1ea5a in the raw ROM, or after the LHA-compressed portion has been decompressed. The address may have significance as f000:ea5b, by convention, is the start of the POST routine. What this has to do with the ID value returned by the EEPROM or Flash chip is beyond me. This check seems to be tied to 4.51PG vs. 4.50PG. 4.50PG might just hang at Updating ESCD... instead of giving Unknown Flash Type as the check wasn't there in the 4.50PG I examined,

Good work jake, just a quick check of 4.51PG from a 8500tec it has only Updating ESCD ... .Success...Fail (around 9E80*) and AWDFLASH* (around 15500*) so Award def installs a micro flasher for the ESCD update in the bios file.
Sorry is all I got 😁 is beyond my capabilites ;p I can't single step through it with what I got....

watz wrote on 2023-09-02, 22:37:

Hi!

I like to get and fix junk boards. So far when they arrived with missing BIOS flash chips, I was lucky enough to find hires pictures of the board that show the installed flash chip. I knew it was kind of important to get a type supported by the BIOS so writing ESCD works. A couple days ago I got this nice i815 based SBC model "NexCom PEAK 650VL2". The flash chip was missing. After some trial and error I figured it needs a 4mbit FWH flash. I robbed a W39V040FC from some other board and it works fine in this SBC. However, when it tries to write ESCD data to the flash at the end of POST the Award BIOS spits out "Unknown flash type". Not a huge deal, but annoying. I am unable to find any info on the original flash chip type other than it's probably a Winbond one.

So here is the question: The Award BIOS obviously has a list of supported flash IDs stored somewhere to be able to spit out this "Unknown flash type" message. It would be nice to know which IDs are supported, and of course even nicer if that list could be extended. Is there maybe a tool to dump that list from a BIOS image?

Can you link to the BIOS images you want to use? I made some progress with this and may be able to dump the list of acceptable Flash Vendor & Device IDs for you.

I found a NexCom PEAK 650VL2 BIOS (T1.3a) from https://theretroweb.com/motherboards/s/nexcom … 50vl2#downloads

Here is how you can find the list of chip IDs from an Award BIOS, assuming you are on a Linux platform and have awardeco installed. You could substitute your own Award BIOS dumping utility.

1. Dump the components of the BIOS, we need awardext.rom:
$ awardeco P650T13a.BIN -x

2. Disassemble the awardext.rom to a text file for later use:
$ objdump -b binary -m i8086 -D awardext.rom > awardext.txt

3. The read identifier command is 0x90. Award sets up the ES: segment register to point to the location of the Flash chip. Find the instruction sending this command to the chip:

$ grep 'mov.*\$0x90,%es:0x0' awardext.txt
d9e1: 26 c6 06 00 00 90 movb $0x90,%es:0x0

4. Figure out where that function is being called. The last call before the first ret is a call to the function that looks up the ID in the known ID table:
$ grep --after-context=9 0xd9e1 awardext.txt
...
d9c7: e8 17 00 call 0xd9e1
d9ca: 26 8a 26 01 00 mov %es:0x1,%ah
d9cf: e8 04 00 call 0xd9d6
d9d2: e8 ff 00 call 0xdad4
d9d5: c3 ret
...

5. Looking at the known ID lookup function, the address of the known ID table gets loaded into si, the number of entries in cx, and in the body of the loop the size of each entry gets added to si:
$ grep --after-context=10 dad4: awardext.txt
dad4: 1e push %ds
dad5: 06 push %es
dad6: 0e push %cs
dad7: 1f pop %ds
dad8: be d8 d8 mov $0xd8d8,%si
dadb: b9 0d 00 mov $0xd,%cx
dade: 3b 04 cmp (%si),%ax
dae0: 74 08 je 0xdaea
dae2: 83 c6 0a add $0xa,%si
dae5: e2 f7 loop 0xdade
dae7: f9 stc

6. In this BIOS the table is at 0xd8d8 and there are 0xd (13) entries in the table and each entry is 0xa (10) bytes long and the first two bytes of each entry are the chip vendor and device ID.
$ od -A n -j 0xd8d8 -N 130 -t x1 awardext.rom | tr -d '\n' | awk '{ for (i = 1; i <= NF; i += 10) print $i, $(i+1) }'
01 a4
97 94
c2 a4
1c 04
37 86
dc 04
ad 40
89 ad
89 ac
20 2c
bf 58
bf 60
bf 51

7. Looking up the device/vendor IDs here (https://ctrl-alt-rees.com/2022-07-03-eprom-de … ce-id-list.html), they seem plausible.

01A4 - AM29F040B
9794 - ?
C2A4 - MX29F040
1C04 - M5M27256
3786 - A29040
DC04 - ?
AD40 - ?
89AD - 82802AB
89AC - 82802AC
202C - M50FW040
BF58 - SST49LF004
BF60 - SST49LF004A/B
BF51 - SST49LF040*PLCC32

jakethompson1 wrote on 2023-09-04, 03:40:

Can you link to the BIOS images you want to use? I made some progress with this and may be able to dump the list of acceptable Flash Vendor & Device IDs for you.

What a coincidence! I'm blown away by your answers. Thanks!
I've attached the bios I'm currently using.

The lowres pictures of this board in the datasheet clearly show a Winbond flash installed. There seem to be very few Winbond FWH flashes of the required size:

Winbond W39V040FA 512k FWH 0xDA 0x34
Winbond W39V040FB 512k FWH 0xDA 0x54
Winbond W39V040FC 512k FWH 0xDA 0x50

Interesting that the acceptable list contains a mix of plain 5V flash and 3.3V/FWH chips, guess that's somewhere in the remaining 8 bytes of data for each entry.

jakethompson1 wrote on 2023-09-04, 04:41:

01A4 - AM29F040B 9794 - ? C2A4 - MX29F040 1C04 - M5M27256 3786 - A29040 DC04 - ? AD40 - ? 89AD - 82802AB 89AC - 82802AC 202C - M […]
Show full quote

01A4 - AM29F040B
9794 - ?
C2A4 - MX29F040
1C04 - M5M27256
3786 - A29040
DC04 - ?
AD40 - ?
89AD - 82802AB
89AC - 82802AC
202C - M50FW040
BF58 - SST49LF004
BF60 - SST49LF004A/B
BF51 - SST49LF040*PLCC32

As this board requires a low voltage (3.3V) 4mbit FWH flash, most of these would be a match. The other IDs like the A29040 may just be wrongly identified. And there's no Winbond amongst them. So I'm not surprised I get that error. Shouldn't have trusted that silly datasheet picture of the board 😉
I think I might have one of the MX or SST ones sitting in some unused P4 or 775 board. Maybe I could also modify this list to include my flash chip, if I figure out what needs to be done to swap out that modified awardext.rom.

Also, a tool to dump this list would be quite handy, wouldn't it? Retroweb's mainboard chip list unfortunately doesn't contain the type of flash chip installed. So there should be quite a few people having the same problem as I did.

jmarsh wrote on 2023-09-04, 13:07:

Interesting that the acceptable list contains a mix of plain 5V flash and 3.3V/FWH chips, guess that's somewhere in the remaining 8 bytes of data for each entry.

Yes a few don't make sense. Maybe orphaned data or ambigous IDs. But that list is a big help if you don't know what's needed.

This is very interesting. Worked on a dual BIOS setup a while ago, where I replaced a 1 Mbit EEPROM with the 2 Mbit version of the same chip, and access either half of it by manually controlling the highest addressing bit. Everything worked, except that the Award BIOS corrupted itself at first boot. Got the "Unknown flash type" message, assumed the message had to do with the chip ID. Guess the builtin flasher/ESCD thing and bad handling of the exception could explain the corruption.

Worked around it by isolating the /WE pin. Figuring out where the check is done on my own is beyond my skills, but the information here might be enough to help me patch the BIOS to accept the 2 Mbit chip, or even remove the check entirely at some point 😀

Edit: seems like this check isn't in all Award BIOSes from that era? Attached the Gigabyte GA-586HX BIOS discussed above, in case it's useful for your research.

jakethompson1 wrote on 2023-09-04, 04:41:

I found a NexCom PEAK 650VL2 BIOS (T1.3a) from https://theretroweb.com/motherboards/s/nexcom … 50vl2#downloads […]
Show full quote

I found a NexCom PEAK 650VL2 BIOS (T1.3a) from https://theretroweb.com/motherboards/s/nexcom … 50vl2#downloads

Here is how you can find the list of chip IDs from an Award BIOS, assuming you are on a Linux platform and have awardeco installed. You could substitute your own Award BIOS dumping utility.

7. Looking up the device/vendor IDs here (https://ctrl-alt-rees.com/2022-07-03-eprom-de … ce-id-list.html), they seem plausible.

01A4 - AM29F040B
9794 - ?
C2A4 - MX29F040
1C04 - M5M27256
3786 - A29040
DC04 - ?
AD40 - ?
89AD - 82802AB
89AC - 82802AC
202C - M50FW040
BF58 - SST49LF004
BF60 - SST49LF004A/B
BF51 - SST49LF040*PLCC32

Great work ! I assumed there would be pointers/code for maybe a few nearly identical eeprom types, not a list with so many.

kaputnik wrote on 2023-09-04, 15:09:

This is very interesting. Worked on a dual BIOS setup a while ago, where I replaced a 1 Mbit EEPROM with the 2 Mbit version of the same chip, and access either half of it by manually controlling the highest addressing bit. Everything worked, except that the Award BIOS corrupted itself at first boot. Got the "Unknown flash type" message, assumed the message had to do with the chip ID. Guess the builtin flasher/ESCD thing and bad handling of the exception could explain the corruption.

Worked around it by isolating the /WE pin. Figuring out where the check is done on my own is beyond my skills, but the information here might be enough to help me patch the BIOS to accept the 2 Mbit chip, or even remove the check entirely at some point 😀

Edit: seems like this check isn't in all Award BIOSes from that era? Attached the Gigabyte GA-586HX BIOS discussed above, in case it's useful for your research.

Yours has a check but it does not have a table, instead it appears a few device/vendor IDs are hardcoded. That there's already one variation discovered in how they manage this list really impedes building a tool to extract the list.

89 94 - N(P)28F001BX-T
31 94 - CAT28F001xI-xxT
C2 1A - MX28F1000P

Also, (http://www.osdever.net/documents/PNPBIOSSpeci … ation-v1.0a.pdf page 44) describes what an ESCD is for. It isn't that relevant to the retro community, partly because we aren't trying to attach and detach to docking stations or insert and remove PCMCIA cards and have ISA PnP resources automagically work, and for the most part the only ISA PnP devices we use are sound cards, and often prefer to control the I/O/IRQ/DMA/etc. by hand since you have to be involved in that anyway for DOS gaming. Personally I always found ISA PnP to just be an annoyance, changing things underneath you behind the scenes when it was better to assign sensible resources to devices yourself rather than ISA PnP do something silly like bump the sound card from IRQ 5 to 7 so that the newly installed ISAPnP ethernet card can use 5.

jakethompson1 wrote on 2023-09-06, 03:56:

Yours has a check but it does not have a table, instead it appears a few device/vendor IDs are hardcoded. That there's already o […]
Show full quote

kaputnik wrote on 2023-09-04, 15:09:

This is very interesting. Worked on a dual BIOS setup a while ago, where I replaced a 1 Mbit EEPROM with the 2 Mbit version of the same chip, and access either half of it by manually controlling the highest addressing bit. Everything worked, except that the Award BIOS corrupted itself at first boot. Got the "Unknown flash type" message, assumed the message had to do with the chip ID. Guess the builtin flasher/ESCD thing and bad handling of the exception could explain the corruption.

Worked around it by isolating the /WE pin. Figuring out where the check is done on my own is beyond my skills, but the information here might be enough to help me patch the BIOS to accept the 2 Mbit chip, or even remove the check entirely at some point 😀

Edit: seems like this check isn't in all Award BIOSes from that era? Attached the Gigabyte GA-586HX BIOS discussed above, in case it's useful for your research.

Yours has a check but it does not have a table, instead it appears a few device/vendor IDs are hardcoded. That there's already one variation discovered in how they manage this list really impedes building a tool to extract the list.

89 94 - N(P)28F001BX-T
31 94 - CAT28F001xI-xxT
C2 1A - MX28F1000P

Also, (http://www.osdever.net/documents/PNPBIOSSpeci … ation-v1.0a.pdf page 44) describes what an ESCD is for. It isn't that relevant to the retro community, partly because we aren't trying to attach and detach to docking stations or insert and remove PCMCIA cards and have ISA PnP resources automagically work, and for the most part the only ISA PnP devices we use are sound cards, and often prefer to control the I/O/IRQ/DMA/etc. by hand since you have to be involved in that anyway for DOS gaming. Personally I always found ISA PnP to just be an annoyance, changing things underneath you behind the scenes when it was better to assign sensible resources to devices yourself rather than ISA PnP do something silly like bump the sound card from IRQ 5 to 7 so that the newly installed ISAPnP ethernet card can use 5.

Hm, that's strange. The original chip in my board, that passes the check, is a SST29EE010, chip ID BF07. It's not in your list. Maybe you've missed something? Could there perhaps be another check routine somewhere?

For the record, the replacement chip that wouldn't pass the check is a SST29EE020, ID BF10.

Googling "unknown flash type" site:vogons.org renders quite a few hits by the way, if you're interested in more potential research material 😀

No, our systems usually are more static in that aspect. Never had any problems with the dual bios mod either, even though the isolated /WE pin effectively disables ESCD updating.