Re: [Etherboot-developers] Wake-on-LAN patch

[Jim M. <ja...@Mc...>]

Ken,

I'm not sure I understand what you've said.

Let me explain the boot process, maybe you didn't understand
me.

The flash disk appears as a ide disk.  I've loaded freedos on
it.

So,

1) Freedos boots up.
2) It runs the autoexec.bat file.
3) The autoexec.bat file runs my ipconf.exe program.
4) The ipconf.exe program looks for the data file containing
   the config info.
5) If it finds the config file, it reads the config info and
   constructs a block in memory. then calls the etherboot
   module.  Such as 'tulip.com' (depending on chipset).
6) tulip.com is an etherboot .com file patched to search
   ram for the block of memory placed there by the ipconf program.
   Once it finds it, it constructs a dhcp reply packet in memory
   and continues on, just as if it had received the packet from
   the network server.

If the config file isn't found, or if the user presses a key
sequence, they can get into the configuration screen, where they
can enter/edit any of the config info.

This would work exactly the same way, whether they used
a flash disk, hard disk, floppy disk, or presumably a DOC.

It's basically just a dos program (ipconf.exe) that executes
another dos program (tulip.com) which takes total control
of the system and sucks a kernel from the server.

Jim.

Ken Yap wrote:
> 
> |The patch to etherboot is a change only to main.c, to make it search
> |through ram, looking for the magic number and construct
> |the dhcp reply, rather than send a query.  I'll send you the patch
> |as soon as I get a chance to clean it up a little more.  I'd like for
> |it to be included in etherboot as a compile time option, but obviously,
> |that is up to you.
> 
> Excellent. One thing I would suggest is that rather than patch Etherboot
> to look for this ROM, this flash register itself as an extension BIOS
> and provide its services via BIOS calls (I'm sure you can find some
> suitable numbers). Etherboot (and any other software for that matter,
> can then test the existence of and access these services via BIOS calls,
> rather than hardwiring knowledge of this flash into the software. Then
> this BIOS call can be generalised for other non-volatile devices instead
> of having device specific code in every piece of software.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers