AoE - questions needing answers

"James Harper" <[email protected]> Tue, 13 Dec 2005 20:31:57 +1100
Newsgroups gmane.network.etherboot.devel
Message-ID <[email protected]>
I think I've now got a vague grasp on the asm code and the concepts of
16 bit mode and 32 bit protected mode, but need some more information...

Ideally, imho, the AoE code would replace the ROM on an existing network
adapter and turn it into an AoE initiator as far as the boot process is
concerned. I have an intel gigabit card with a boot rom on it, and the
boot rom can configure a few things, like how long to present the 'press
ctrl-S to configure' message for, etc, which indicates some extra
configuration space which could be used for AoE specific config... Or
maybe it is using a block of flash for that...

It might be nice if the individual network code could provide a routine
to store and retrieve configuration data, but I fear that that sort of
stuff is not chipset specific but rather implementation specific (eg
three different cards with an eepro100 chipset might be completely
different in all other respects).

Anyway, the boot process on x86 should look like:
Rom Init:
. Do the copy to ram and setup 32 bit stuff*
. Display some version information.
. Probe C: (and D:?) and display details on screen.
. Prompt user for key combination to enter configuration screen
. Clean up allocated ram and 32 bit stuff*
. Legacy: Assuming that the AoE initiator is to be active, install a
handler for int19 to start the boot
. PNP/PCI: Assuming that the AoE initiator is to be active, return to
the BIOS indicating that we can be booted from

Config Menu Options:
. Enable/Disable
. Show all AoE targets found on the network
. Select targets for C: and D:
. Configure geometry/translation (defaults will be provided based on
standard translations)

Boot:
. Install int13 handler in memory and protect so it won't be
overwritten*
. Do the normal boot stuff (load the first sector of C: into memory and
boot it)

* I'm a bit vague on why the 32 bit code needs to be allocated to such a
high area of memory, and once there, how to stop it being overwritten by
something else. Why couldn't the rom be not compressed, and copied to
ram which is then mapped over the rom, at the same address? In 32 bit
mode, we can pretend the virtual address is anything without worrying
about the physical address yes? Or is this too system dependant? Or does
going from a 32k rom to a 64k rom make this too hard?

With the code I've got, GRUB loads the kernel and initrd, but then
crashes. My best guess is that GRUB tries to issue an int13h reset as
the last thing it does once the operating system is loaded into memory,
before jumping into the operating system. But at the time this happens,
my int13 aoe code has been clobbered. I haven't yet had a close enough
look to see if this is the case though. How does the PXE EXPORT code get
around this?

Any and all information you can give me will be much appreciated!

Thanks

James


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click