In the past I've done lots of embedded flash programming at work, so
decided to have a muck about with the flash BIOS in an old Pentium II
I've got.

The flash is a 1 Mbit (128k x 8) device and I can see a hunk of it in
memory at segment F000, but I can't find the other 64K (it's not at
E000), which means I can't get the flash ident commands to work
because I don't know the device base address.

I've tried hunting for the BIOS sig of the missing missing 64k
(0x55AA) at 64k intervals from 1Meg right up to the top of the address
space at 4G but with no joy. I've tried this using unreal mode under
DOS and also booting straight into a little bare bones protected mode
shell I wrote but still can't find the bugger.

And yes - I have enabled the A20 line.

The last BIOS team I worked on was for a 286 many years ago so I'm
probably missing something that's been introduced for later processors
but no amount of Googling has given me a clue.

So....... any clues?

Regards,
Alfie.

On Fri, 27 Apr 2007 09:08:01 GMT, Alfie Noakes
<(E-Mail Removed)> put finger to keyboard and composed:

>
>In the past I've done lots of embedded flash programming at work, so
>decided to have a muck about with the flash BIOS in an old Pentium II
>I've got.
>
>The flash is a 1 Mbit (128k x 8) device and I can see a hunk of it in
>memory at segment F000, but I can't find the other 64K (it's not at
>E000), which means I can't get the flash ident commands to work
>because I don't know the device base address.
>
>I've tried hunting for the BIOS sig of the missing missing 64k
>(0x55AA) at 64k intervals from 1Meg right up to the top of the address
>space at 4G but with no joy. I've tried this using unreal mode under
>DOS and also booting straight into a little bare bones protected mode
>shell I wrote but still can't find the bugger.
>
>And yes - I have enabled the A20 line.
>
>The last BIOS team I worked on was for a 286 many years ago so I'm
>probably missing something that's been introduced for later processors
>but no amount of Googling has given me a clue.

>So....... any clues?
>
>Regards,
>Alfie.

The BIOS address space usually remaps to the top of memory, ie
FFFE0000 - FFFFFFFF. Windows users can see this area identified in the
memory resources of Device Manager.

What you are seeing at F000 is the runtime portion of the decompressed
BIOS code. Unlike 286 BIOSes, newer BIOSes decompress various modules,
eg POST routines, on an as-needed basis. After the POST completes,
then the runtime code can replace it in memory. At least that's how I
think it works.

Uniflash is a program that does what you want. It is also able to make
use of NICs to program suitable EEPROM devices.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

Thanks for the info. I had already been steered to UniFlash thanks to
these two excellent links someone had posted in another newsgroup

http://www.geocities.com/mamanzip/Ar..._RE_guide.html

http://www.geocities.com/mamanzip/Ar...hing_Tool.html

Looking through the source for UniFlash I can see it has all the info
I need to do the mapping.

Thanks for the help,
Long live USENET!

Alfie.



On Sat, 28 Apr 2007 08:35:11 +1000, Franc Zabkar
<(E-Mail Removed)> wrote:


>
>The BIOS address space usually remaps to the top of memory, ie
>FFFE0000 - FFFFFFFF. Windows users can see this area identified in the
>memory resources of Device Manager.
>
>What you are seeing at F000 is the runtime portion of the decompressed
>BIOS code. Unlike 286 BIOSes, newer BIOSes decompress various modules,
>eg POST routines, on an as-needed basis. After the POST completes,
>then the runtime code can replace it in memory. At least that's how I
>think it works.
>
>Uniflash is a program that does what you want. It is also able to make
>use of NICs to program suitable EEPROM devices.
>
>- Franc Zabkar