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