RE: Etherboot as backend of INT13h AoE driver

"James Harper" <[email protected]> Tue, 6 Dec 2005 09:03:05 +1100
Newsgroups gmane.network.etherboot.devel
Message-ID <[email protected]>
> On Dec 3, 2005, at 11:35 PM, James Harper wrote:
> > Thinking about what it would take to write a BIOS driver for the AoE
> > (ATA over Ethernet) protocol, it occurred to me that Etherboot
already
> > contains the code to read and write frames from a large variety of
> > different network cards, and that it might work as the backend of
> > an AoE
> > INT13h driver.
> 
> This sounds like an interesting idea.  I've thought more than once
> that having an AOE driver for Etherboot would be very cool.
> 
> Linux Journal has a nice article on the technology here:
> 
>      http://www.linuxjournal.com/article/8149
> 

Glad someone else thinks it might be interesting. I'm already using AoE
via initramfs for Linux, which works great, but for Windows or dos Int13
would be required (and then you'd need a Windows driver which would work
as part of the windows boot).

> > For this to work, Etherboot would need to be able to receive
> > interrupts
> > from the card (eg not be polled), and would need to able to stay
> > resident in high memory until another OS took over.
> 
> This sounds like something we could do with our PXE support.  I'm
> guessing that AOE code could be a protocol:
> 
>     aoe://xxxx/foo.bin
> 
> or something like that.

Somewhere along the way we'd need to designate the 'boot drive' to
select which AoE shelf/slot is used for C:, could that sort of protocol
specification be used for that?

> We have interrupt support in a number of drivers, and more can be
> added.  PXE requires INT support for UNDI, I believe.

After I posted that I got to thinking, and am now not completely sure
that Int13 is actually asynchronous, so maybe interrupt support is not
really required afterall. This would simplify things immensely. It's
been too long since I've had to deal with the bios stuff directly, and
even longer since I've written any sort of driver for dos.

> > I think it might
> > also need to be 16 bit code too... is Etherboot 16 bit, or is it
only
> > the init code which runs as 16 bit?
> 
> I'll defer to Michael on this, but I believe we already have to deal
> with this at startup, and he has added trampoline code to deal with
> 16 bit code sections.

How fast is trampoline code these days? I know the 32bit to 16bit
transition used to involve a (partial?) processor reset, which was slow.
Because we are talking DOS, or windows bootstrap, maybe it doesn't
really matter. It amazes me that x86 based machines still boot up in 16
bit mode :)

> Thanks for suggesting this.  I think it would be an interesting
> addition to Etherboot.
> 
> If it's something you're interested in helping with, let us know.
> I'm sure others will have some thoughts.
> How would you like to proceed?  I think sample hardware is
> inexpensive, and I believe there is GPL-compatible code out support
AOE.
> 
> Please let us know what you have in mind in terms of development.

Just an idea at the moment, although the more I think about it the
easier it sounds. If the driver can run in 32 bit mode then some
butchering of the Linux AoE driver might do nicely. But even if it has
to be written from scratch, the AoE protocol is mind bogglingly simple,
and afaicr, so are the functions of Int13. Also, if someone here
(etherboot-developers) said it just won't work, then I guess I'd be
wasting my time.

Any pointers to some online BIOS Int13h documentation? Most of that sort
of stuff pre-dates the web so I'm finding it a bit hard to find... i
might have to resort to (*gasp*) reading a book!

With virtual machines etc this stuff becomes amazing simple to test and
to debug!

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