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

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> 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.

Since this code used to work it sounds reasonable, that the BIOS is the
culprit.

Is this one of those BIOSes that allow you to specify etherboot in
the boot order?

> 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.

If you have an eepro100 plugin NIC I have an mtd driver that allows it
to be written/erased in software...

Eric