RE: [Etherboot-developers] Development directions (AoE)

[James H. <jam...@be...>]

> On Dec 22, 2005, at 6:09 PM, James Harper wrote:
> > I'm (slowly) working on AoE (ATA over Ethernet) support, using
> > Etherboot
> > as a base.
>=20
> Neat.  I hope it's something we can integrate into Etherboot.

Yes. That's the idea :)

>=20
> > The idea is that when the rom executes first, it gives a 'hit ctrl-a
> > (?)
> > for setup' message and if the key combination is hit, enters into a
> > setup screen. Assuming that it is set to be active, it installs the
> > int19 handler and returns control to the O/S. (PnP obviously behaves
a
> > bit differently but same sort of thing)
>=20
> The 3C905x with a LanWorks boot ROM does something like this (I think
> it's a different key combination).
>=20
> I think they must save some information to the Flash EEPROM BOOTROM,
> unless they are actually writing to the tiny serial EEPROM on card.
> Does anyone know for sure?  Not all cards have this, and some (the
> Intel EEPRO100 comes to mind) might need extra help to do this.

I think I mentioned in a previous email that to be AoE compatible, maybe
we add a function to each driver to get and set config space. It would
be nice to have a way of doing auto-configuration, but I can't yet
imagine how. Maybe an extension to the AoE spec is in order...

> > The int19 handler then probes drives and assuming a drive is found
for
> > this machine, installs an int13 handler and then boots.
>=20
> Sounds plausible.

Good :)

> > At the moment I'm stuck in that when the rom vector is called, I
> > want to
> > call 32 bit code to run the setup etc (setup will need to be able to
> > probe drives etc so it needs to pretty much have the whole show
> > running). This much works, but I can't get it to return properly to
> > the
> > operating system... things hang at this point :(
>=20
> Michael Brown is head hacker, and he's distracted by other work right
> now.  There are probably other folks on the list who can answer the
> question better than I can.
>=20
> Michael highly recommends the use of Bochs, and Open Source x86
> emulator which he has used extensively for the development of
> Etherboot.  I have also used it, and it is impressive.
>=20
> It might make it easier for your to develop and test things.  The
> hardest part is getting it set up, since you have to do some
> networking magic to get the routing right, since it's a virtual
> machine.  I'm sure we can help you with that, though.

I'm already using Bochs for testing, that is the environment that I have
linux almost booting, and yes I agree that it makes testing _so_ much
easier. The network setup is actually much easier than you might think,
at least for the boot process, as all I have to do is run vblade
(virtual AoE device) against the tun/tap device, which keeps it off the
real network for testing.

I run Debian, and Bochs as packaged isn't compiled with the debugger
option. I recompiled it with the debugger option and it makes life so
much easier. The debugger is pretty primitive but I can still set
breakpoints and inspect memory etc so it does the job.

>=20
> We're gearing up for some serious Etherboot hacking in the next few
> months, so I hope you (and anyone else interested) will stick around.
>=20
> It's a funny analogy, but Open Source hacking is a little like
> surfing.  We wait for a wave, and we come out and ride it as long as
> we can.
>=20
> Right now, there are a number of us gearing up to hack.  We all have
> day jobs, and have to honor our other obligations, but it's great
> when we can work together on something that brings us joy and the
> satisfaction of doing.  I live for these times, and I work and save
> for them too.

I have 4 kids, 3 of them under 5. Not so much time to spend on such
things, so it makes sense to have a worthwhile project :)

> > <offtopic> Once I have an AoE int13 driver, which will be enough to
> > boot
> > DOS and bootstrap any O/S with a native AoE driver,
>=20
> I'm wondering if you could use Etherboot to boot PXELINUX, which
> would load MEMDISK (a DOS disk emulator), which would then load a DOS
> AoE driver?  You might want to check out:
>=20
>      http://wiki.etherboot.org/pmwiki.php/Main/BootingMemdisk
>=20
> I think you can ignore all the mknbi stuff.  I you just want to get
> PXELINUX up and running, and let it load your floppy image.

This has been mentioned before, but I don't like it. In the environment
I am thinking of, it would be pure SAN. You would have an AoE hardware
storage device from coraid (http://coraid.org), and all servers would
use that. Using PXE would rely on a server already being up, which means
it would have to have its own disks.

> > I might take a deep
> > breath and have a crack at a Windows driver (the Linux driver
already
> > exists and is more than stable). There is a windows driver in the
> > pipeline, but I've had a look at a beta and it seems to come with a
> > huge
> > amount of overhead, and is almost certainly proprietry. I'm sure it
> > will
> > work great and probably perform a lot better than anything I can
> > come up
> > with, but I don't think is something that could be used as the
second
> > stage windows bootloader. </offtopic>
>=20
> Hopefully you'll have so much fun hacking Etherboot that you'll
> forget such thoughts ;-)
>=20
> I find hacking closed-source stuff to be much less interesting than
> in the old days.  It's neat to figure out what's going on inside the
> box and interface with it, but it often seems a hollow victory, since
> I am often operating one step removed from definitive information.

The windows driver would still be open sourced. The Microsoft driver
interface stuff is well documented, so it's not quite the reverse
engineering job you make out. But I see your point. I am writing
something that will interface to Etherboot. If there is something I need
changed in Etherboot to make it work for me I can suggest the change and
submit a patch. And (absolute worse case), if nobody likes my patch and
I can't work around it, I can take a copy of the Etherboot source and
fork it. With a closed source infrastructure you are pretty much stuck
with it.

>=20
> And thank you for your message.  I hope you keep going.  The next
> wave will be coming, and I hope you're riding it with us.
>

Thanks for the words of encouragement. Now that Christmas is behind us I
might have some time to get back into it.

James