[Etherboot-developers] Award BIOS and int 18h problems

[Michael B. <mb...@fe...>]

I'm having major problems with Award Modular BIOS v6.00PG and the latest
Etherboot 5.0.8.  Booting from the network works fine; the problem is when
you choose "(L)ocal" and attempt to boot from the hard disk instead.  It
displays the message "PRESS A KEY TO REBOOT" and stops.

This occurs only when booting from a real EPROM (.lzrom).  Booting the
exact same code from a floppy (.lzfd0) has no problems.

I've been working back through the code, adding exit points at various
stages.  I'm now at the stage that loader.S executes an int 0x18 as soon
as the BIOS calls its Boot Execution Vector.  This was achieved with the
following modification to loader.S:

        .word 0x0000                    /* boot connection vector */
        .word 0x0000                    /* disconnect vector */
-       .word pnpentry
+/*     .word pnpentry */
+       .word pnpreturn
        .word 0x0000                    /* reserved */

i.e. the BEV points to pnpreturn instead of pnpentry.  pnpreturn contains
simply:

pnpreturn:
	int	$0x18			/* As per BIOS Boot Spec, next dev */


Even with this modification, the machine *STILL* fails with the "PRESS A
KEY TO REBOOT" message.

"Aha," I thought.  Maybe the implementation of int 0x18 is screwed in this
BIOS.  So I tried adding a second HDD.  Both HDDs have a standard DOS MBR
and DOS partition tables.  By deactivating the boot partition on one
drive, I can make the BIOS fall through and try the next drive.  This, as
far as I am aware without disassembling the MBR, involves the same int
0x18 mechanism.


As far as I can tell from reading around, there are no preconditions on
calling int 0x18 other than that "data areas such as the interrupt vector
table, the BDA, and the Extended BIOS Data Area must remain unchanged
[from when the BEV was called]".  Since by BEV is currently pointing
straight to an int 0x18 instruction, it's hard to see where I might be
violating this requirement.

The most annoying aspect of this is that the only to test code changes is
to burn them into silicon, and I don't have an EPROM eraser...

Any ideas are more than welcome.

Michael