etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [COMMIT] Multicast & more.

[<ebi...@ln...>]

> > FILE:
> > TFTP:
> > NFS:
> > X-SLAM: probably for the moment only
> > TFTM:

One thing we need to do is to advertise in a dhcp option which protocols
we support.  This way someone with an ISC dhcp v3 server or equivalent
can automatically take advantage of the other protocols.

Eric

Re: [Etherboot-developers] [COMMIT] Multicast & more.

[<ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> On Wednesday, 12. June 2002 05:02, Eric W. Biederman wrote:
> > I have committed my first first round of changes to be a productive
> > bootloader for LinuxBIOS, into the etherboot-5.1 tree.  I believe I
> > have only included the good bits but I have only tested the merge with
> > my tree to see if it compiles.  Holler if it breaks, something for you/
> 
> Image_menu cannot compile, complains about something double defined.... Just 
> saw it, I will hunt for mknbi-menu instead :-)

Oops. 
 
> > Included.
> > - Added multicast support
> 
> which I steal code from. Thanks so far.

Note the memory allocate should be done more cleanly.  I just hacked
together a working solution.

> > - Added a pc floppy driver
> 
> which seems to be commented out ?

Right.  I didn't have the parsing code in a sane form.
 
> > - added an experimental multicast download protocol
> 
> Is there a server for it?

Yes.  But at the moment I can't release it.
 
> I used the chance of the moment and changed the code to accept the following 
> URIs:
> 
> "file:"  (0,1 or 3 times "/")  "disk/" (devicenumber, 0..3 allowed only)
> to boot the MBR of a harddrive
> 
> append "/" (partitionnumber, 0..8 allowed, 0=MBR) to explicitely boot a 
> partition.

Hmm.  0=MBR I don't like...  If you can just avoid giving a partition number
to indicate the MBR it is better.
 
> "file:" (0,1 or 3 times "/") "floppy/" (devicenumber, 0..3 allowed only)
> to boot a floppy device.
> 
> In plain language, you can enter into your dhcp "filename" parameter
> 
> file:disk/0
> file:/disk/0/0
> file:///disk/0/0

Sounds like good work I will inspect it later.
 
>  I would like to 
> have the URI scheme "tftm:" (Trivial File Transfer protocol, Multicast mode) 
> officially assigned.

I would like to use an ``x-'' prefix until the appropriate IETF commitee
assigns an official prefix.  Experimental protocols you are allowed to
change as needed, the rest are a little more fixed.

> While improving URI support, it would not be too much a hassle to implement 
> the ability to have both TFTP and NFS at hand, so filenames beginning with 
> one of the following should be treated "reserved" from now on:
> (only the lowercase needs to be reserved for *n*x filenames, but written 
> uppercase to increase readability):

Right.  I was thinking along similiar lines.
 
> FILE:
> TFTP:
> NFS:
> X-SLAM: probably for the moment only
> SLAM: probably in the near future, when it's no longer experimental
> TFTM:
> 
> Anselm
> 
> Attachment: mainc-fileurl.diff. To be applied to main.c to have file: URI 
> support.

A good step forward.

Eric

Re: [Etherboot-developers] NBP Help

[<ebi...@ln...>]

Peter Lister <P.L...@sy...> writes:
> Ever tried getting a bugfix to your system BIOS or nic firmware?

Yes, and succeeded.  But the process was unpleasant enough I have
strong company support for working on LinuxBIOS.

Eric

Re: [Etherboot-developers] [COMMIT] Multicast & more.

[Anselm M. H. <an...@ho...>]

On Wednesday, 12. June 2002 05:02, Eric W. Biederman wrote:
> I have committed my first first round of changes to be a productive
> bootloader for LinuxBIOS, into the etherboot-5.1 tree.  I believe I
> have only included the good bits but I have only tested the merge with
> my tree to see if it compiles.  Holler if it breaks, something for you/

Image_menu cannot compile, complains about something double defined.... Just 
saw it, I will hunt for mknbi-menu instead :-)

> Included.
> - Added multicast support

which I steal code from. Thanks so far.

> - Added a pc floppy driver

which seems to be commented out ?

> - added an experimental multicast download protocol

Is there a server for it?

I used the chance of the moment and changed the code to accept the following 
URIs:

"file:"  (0,1 or 3 times "/")  "disk/" (devicenumber, 0..3 allowed only)
to boot the MBR of a harddrive

append "/" (partitionnumber, 0..8 allowed, 0=MBR) to explicitely boot a 
partition.

"file:" (0,1 or 3 times "/") "floppy/" (devicenumber, 0..3 allowed only)
to boot a floppy device.

In plain language, you can enter into your dhcp "filename" parameter

file:disk/0
file:/disk/0/0
file:///disk/0/0

which would just boot MBR of first hard drive.

It is dependend from CAN_BOOT_DISK as the traditional "/dev/"... method, and 
it does nothing else then parse the line, so I meant not to make an 
additional compile-time option for it. It is not very likely that names like 
"file:vmlinuz" are used yet.

As I started implementing a tftp-mcast client (just for interest, and 
stealing most of the basic code from Eric's slam protocol) I would like to 
have the URI scheme "tftm:" (Trivial File Transfer protocol, Multicast mode) 
officially assigned.

While improving URI support, it would not be too much a hassle to implement 
the ability to have both TFTP and NFS at hand, so filenames beginning with 
one of the following should be treated "reserved" from now on:
(only the lowercase needs to be reserved for *n*x filenames, but written 
uppercase to increase readability):

FILE:
TFTP:
NFS:
X-SLAM: probably for the moment only
SLAM: probably in the near future, when it's no longer experimental
TFTM:

Anselm

Attachment: mainc-fileurl.diff. To be applied to main.c to have file: URI 
support.

Re: [Etherboot-developers] NBP Help

[Rajesh S. P. <raj...@ta...>]

Hi,

Thank you for the detailed explanation. It was infact very useful. However I was looking into
something very specific to NBP and PXE interaction..any links..any documentation explaining
about that part of the PXE process .....

I have thoroughly gone through Intel PXE specs...PXE  Version 2.1 from intel site. but the
specifications doesnot clearly explain the interaction and the process after the downloading
of NBP.

Thank you.
Regards,
rajesh

Re: [Etherboot-developers] NBP Help

[Peter L. <P.L...@sy...>]

> Can anybody tell me how the PXE specific boot image(NBP) interacts with PXE
> stack How it gets loaded. Basically the interaction between PXE and NBP, till
> NBP loads the operating system or it retuens control back.

Read pxespec.pdf. Look at Etherboot and pxelinux source.

Please do not ask us to read them for you.

Re: [Etherboot-developers] NBP Help

[Peter L. <P.L...@sy...>]

> "Rajesh Shantaram Patharkar" <raj...@ta...> writes:
> >    I have gone through some part of this Etherboot docs. For me it seems
> > that(Looking at documents) etherboot and PXE are same.
> >    Is it true? if not what are the difference between Etherboot and PXE.

Rajesh, could you tell us what you are trying to achieve? Your questions
imply that you are interested in working on PXE, but you don't have a
great deal of experience. It would help a great deal if you could give
us background - I am certainly happy to help with pointers to
information if that result will be a contribution to Etherboot or
another open source package which can help.

When you refer to "PXE", do you mean specifically Intel's PXE spec, or
network booting in general? I have heard people say "PXE" when they just
mean network booting via DHCP / TFTP.

PXE is Intel's specification of an environment which provides network
support in a way somewhat resembling "traditional" BIOS functions. It
uses the existing DHCP and TFTP protocols. The design is, by common
consent, clunky, but then it was intended to retrofit network booting
for the benefit of firmware vendors used to writing a traditional BIOS
and to support of operating systems which used a traditional BIOS.

I cannot imagine anyone *wanting* to use PXE where a better alternative
exists, just in the same way that Linux is a better alternative to
Windows. In the open source community, Etherboot is that better
alternative for firmware and Linux is the better alternative OS. But
most of the world's network boot firmware is PXE, and Microsoft OSs boot
via PXE, so in practise Etherboot must play nicely to gain wider
acceptance. It turned out to be fairly easy for PXE firmware to chain
Etherboot - there has been some progress in getting Etherboot to provide
a PXE environment to an NBP.

To expand on Eric's comments...

> Mostly etherboot implements  standard DHCP and TFTP and handles any
> image size.  In particular I can load a whole image in one pass.
> Resulting in subsecond boot times.  

It's worth pointing out that PXE, and it's uses of NBPs *requires* a 2
stage boot. You'd have to ask Intel why they decided on this.

> PXE has some embrace and extend going on, above standard DHCP && TFTP,
> as well as complicated a set of API for the NBP.  etherboot doesn't
> limit the initial image.  

Etherboot's hardware driver library is used by other code (e.g. GRUB);
the rest of it is the network support, the front end and the loader
which actually starts the new OS (much of this code is embodied in NBI).
A PXE implementation does all this - but in the PXE way.

> Extending etherboot to be a PXE a server would be o.k. as long as it
> didn't mess up the code.  

I see no reason why it would - pxe support should sit on top of the
Etherboot code as a thin compatibility layer, and might be loaded as
part of an NBI image or another chainable module.

> That is the other big difference etherboot as an open source project
> and be extended and fixed, and is generally not buggy.

Most commercial PXE firmware seems to be based on a buggy Intel
implementation. My biggest problem with pxelinux is not of Peter Anvin's
good work in extending syslinux to use PXE, but in the fact that it
relies on PXE, and PXE is usually broken. Actually, it's not just PXE -
recent syslinux work unrelated to network booting has had many problems,
due to broken commercial firmware. Ever tried getting a bugfix to your
system BIOS or nic firmware?

Bugs in Etherboot are rare, and are quickly fixed. Etherboot is an
active project and functionality is being extended. A PXE layer based on
Etherboot would *be* PXE - remember that PXE is an environment, not a
specific vendor's firmware. When Etherboot fully supports PXE it will
without doubt be *better* than any of the commercial vendors!

Re: [Etherboot-developers] NBP Help

[Rajesh S. P. <raj...@ta...>]

Hi,
      This means that boot images are different for PXE and Etherboot.
Can anybody tell me how the PXE specific boot image(NBP) interacts with PXE
stack How it gets loaded. Basically the interaction between PXE and NBP, till
NBP loads the operating system or it retuens control back.
      I got idea of how etherboot image works, its interaction and other
details. But if would be very nice, if I get similar
/information/documents/links for PXE boot mage.

Looking forward to receive replies.
Thanks in advance.
regards,
Rajesh

Eric W. Biederman" wrote:

> "Rajesh Shantaram Patharkar" <raj...@ta...> writes:
>
> > Hi,
> >    I have gone through some part of this Etherboot docs. For me it seems
> > that(Looking at documents) etherboot and PXE are same.
> >    Is it true? if not what are the difference between Etherboot and PXE.
>
> Mostly etherboot implements  standard DHCP and TFTP and handles any
> image size.  In particular I can load a whole image in one pass.
> Resulting in subsecond boot times.
>
> PXE has some embrace and extend going on, above standard DHCP && TFTP,
> as well as complicated a set of API for the NBP.  etherboot doesn't
> limit the initial image.
>
> Extending etherboot to be a PXE a server would be o.k. as long as it
> didn't mess up the code.
>
> That is the other big difference etherboot as an open source project
> and be extended and fixed, and is generally not buggy.
>
> Eric

Re: [Etherboot-developers] NBP Help

[<ebi...@ln...>]

"Rajesh Shantaram Patharkar" <raj...@ta...> writes:

> Hi,
>    I have gone through some part of this Etherboot docs. For me it seems
> that(Looking at documents) etherboot and PXE are same.
>    Is it true? if not what are the difference between Etherboot and PXE.

Mostly etherboot implements  standard DHCP and TFTP and handles any
image size.  In particular I can load a whole image in one pass.
Resulting in subsecond boot times.  

PXE has some embrace and extend going on, above standard DHCP && TFTP,
as well as complicated a set of API for the NBP.  etherboot doesn't
limit the initial image.  

Extending etherboot to be a PXE a server would be o.k. as long as it
didn't mess up the code.  

That is the other big difference etherboot as an open source project
and be extended and fixed, and is generally not buggy.

Eric

Re: [Etherboot-developers] NBP Help

[Rajesh S. P. <raj...@ta...>]

Hi,
   I have gone through some part of this Etherboot docs. For me it seems
that(Looking at documents) etherboot and PXE are same.
   Is it true? if not what are the difference between Etherboot and PXE.

Looking forward to receive replies.
Thanks in advance.
Regards,
Rajesh

"Eric W. Biederman" wrote:

> "Rajesh Shantaram Patharkar" <raj...@ta...> writes:
>
> > Hello All,
> >      Thank you very much for your replies. I think this is the first mailling
> > list where i got proper replies.
> >      I am not going to develop any NBP, But will be developing PXE stack. So
> > wanted to know when NBP it is downloaded at 0:7C00 addr, how it goes, what it
> > lokks for execution. Is there any standard of flow of execution for NBP? how
> > does it executes and all that.
>
> Almost by definition there is no standard flow.
>
> But since you are limited to 32KB, generally the next step is to download
> a kernel.
>
> If you want to look at the open source implmentations there is:
> etherboot,
> syslinux,
> and a few others.
>
> >
> >    As you mentioned, it unloads what not needed.
> > >NBPs can use as much PXE as they need to. The UNDI network driver is
> > available to NBP. So is DHCP/TFTP but
> > >it's normally broken; use the etherboot code.
> > Also you have talked about Etherboot PXE Loader which unloads all PXE stack
> > takes the control and executes, loads everything of its own (own stack) and
> > suppose that it should use driver that is already present.
> >     So as mentioned in the PXE specs, when NBP is downloaded it checks the
> > environment needed and if REQUIRED environment is not there it should return
> > control back to BIOS.
> >    Now I would like to know what is this REQUIRED environment, what exactly it
> >
> > looks for to executes, From your mail, for etherboot it seems that NBP has its
> >
> > own stack (DHCP, TFTP/MTFTP, etc) which it uses to download remaining things.
> > Is it same for all others.
> >
>
> Etherboot is probably unique in that regard.  As the usuall use for etherboot
> is not being loaded from a boot rom but instead being the boot rom
> and loading other programs.  Etherboots success is a direct reflection
> of what a poor job PXE has done in developing a useable standard.
>
> Eric

Re: [Etherboot-developers] NBP Help

[<ebi...@ln...>]

"Rajesh Shantaram Patharkar" <raj...@ta...> writes:

> Hello All,
>      Thank you very much for your replies. I think this is the first mailling
> list where i got proper replies.
>      I am not going to develop any NBP, But will be developing PXE stack. So
> wanted to know when NBP it is downloaded at 0:7C00 addr, how it goes, what it
> lokks for execution. Is there any standard of flow of execution for NBP? how
> does it executes and all that.

Almost by definition there is no standard flow. 

But since you are limited to 32KB, generally the next step is to download
a kernel.

If you want to look at the open source implmentations there is:
etherboot,
syslinux,
and a few others.

> 
>    As you mentioned, it unloads what not needed.
> >NBPs can use as much PXE as they need to. The UNDI network driver is
> available to NBP. So is DHCP/TFTP but
> >it's normally broken; use the etherboot code.
> Also you have talked about Etherboot PXE Loader which unloads all PXE stack
> takes the control and executes, loads everything of its own (own stack) and
> suppose that it should use driver that is already present.
>     So as mentioned in the PXE specs, when NBP is downloaded it checks the
> environment needed and if REQUIRED environment is not there it should return
> control back to BIOS.
>    Now I would like to know what is this REQUIRED environment, what exactly it
> 
> looks for to executes, From your mail, for etherboot it seems that NBP has its
> 
> own stack (DHCP, TFTP/MTFTP, etc) which it uses to download remaining things.
> Is it same for all others.
> 

Etherboot is probably unique in that regard.  As the usuall use for etherboot
is not being loaded from a boot rom but instead being the boot rom
and loading other programs.  Etherboots success is a direct reflection
of what a poor job PXE has done in developing a useable standard.

Eric

Re: [Etherboot-developers] NBP Help

[Rajesh S. P. <raj...@ta...>]

Hello All,
     Thank you very much for your replies. I think this is the first mailling
list where i got proper replies.
     I am not going to develop any NBP, But will be developing PXE stack. So
wanted to know when NBP it is downloaded at 0:7C00 addr, how it goes, what it
lokks for execution. Is there any standard of flow of execution for NBP? how
does it executes and all that.

   As you mentioned, it unloads what not needed.
>NBPs can use as much PXE as they need to. The UNDI network driver is
available to NBP. So is DHCP/TFTP but
>it's normally broken; use the etherboot code.
Also you have talked about Etherboot PXE Loader which unloads all PXE stack
takes the control and executes, loads everything of its own (own stack) and
suppose that it should use driver that is already present.
    So as mentioned in the PXE specs, when NBP is downloaded it checks the
environment needed and if REQUIRED environment is not there it should return
control back to BIOS.
   Now I would like to know what is this REQUIRED environment, what exactly it

looks for to executes, From your mail, for etherboot it seems that NBP has its

own stack (DHCP, TFTP/MTFTP, etc) which it uses to download remaining things.
Is it same for all others.

Looking forward to receive replies.
Thanks in advance.
Regards
Rajesh



Peter Lister wrote:

> >      I am working on PXE. I would like to know how NBP interacts with
> > PXE? do they use PXE stack Or they are OS loaders and so they install OS
> > first and use the OS stack?
>
> Read the PXE spec.
>
> NBPs can use as much PXE as they need to (and unload what they don't
> need). The UNDI network driver is available to NBP. So is DHCP/TFTP but
> it's normally broken; use the etherboot code.
>
> Look at Etherboot's PXELOADER code in loader.S to see a minimal NBP. It
> just unloads the whole of PXE and then proceeds as if loaded from rom,
> using it's own driver. There is a placeholder compile flag to leave UNDI
> loaded for anyone interested in getting Etherboot to use it. Compare
> with pxelinux, which uses UNDI, DHCP and TFTP.
>
> I hope it's obvious that Etherboot must use either UNDI or a native
> driver, or there's no way to load the OS. :)
>
> Out of interest what are you doing with PXE? If all you need to do is
> boot Linux, Etherboot or pxelinux will do this now. Writing a new NBP
> just for fun seems pointless. Unless you have an odd idea of "fun".
>
> Adding UNDI support as an Etherboot driver would be a good NBP project
> and could form the basis of a useful open source NBP toolkit. It would
> be useful to quite a few people because it would make Etherboot via PXE
> easier to set up for sites which have many hardware types.
>
> You could also improve Etherboot's PXE support (i.e. so that Etherboot
> can provide PXE to other NBPs), maybe merging the existing the NILO code
> so that Etherboot can run any NBP. The standard of the Intel PXE code
> library (used in most vendor's NIC firmware) is - er - low. Look at
> HPA's pxelinux pages or read the syslinux list to see just how low. Even
> devoted PXE users would like better open source PXE firmware; Etherboot
> (and it's driver library) is the obvious platform and has had skeleton
> PXE support added already (which, I note, Eric B just migrated to its
> very own pxe.c). This could be chainable (a "menu module"?) from a
> "vanilla Etherboot" in turn loading a "real" NBP like NTLOADER. Or even
> be statically linked with an existing binary NBP...
>
> mknbi-pxe closedOS.pxe closedOS.nbi
>
> ...to turn it into something which can be loaded directly by Etherboot!
>
> >    Can anybody tell me links those will give me more deatiled
> > information on NBPs
>
> Intel changed the URL, but kept no placeholder; even their own URLs have
> not been updated, so you can be forgiven for not finding it...
>
> http://www.intel.com/labs/manage/wfm/wfmspecs.htm

Re: [Etherboot-developers] [RFC] Booting from disk....

[<ebi...@ln...>]

I've got to go and I won't be back until friday but a quick update.

ke...@us... (Ken Yap) writes:

> >To make this work under LinuxBIOS I need to do the following things.
> >1) Move the code for booting an x86 bootsector into osloader.c
> >   So I can boot ELF image directly from disk.
> >
> >2) Modify bootdisk to take a download_kernel parameter.  If
> >   only a stock x86 bootsector is present it will be used see 1.
> >
> >3) Modify bootdisk to call my polled drivers.
> 
> Should be ok. I've had a look and the code around loadkernel is a bit of
> a mess.  Probably what should be done is:
> 
> 1. downloadkernel is misnamed. It probably did the downloading ages ago,
> but really it should be called handleblock. In fact I've just done that
> name change in my version. The symbol's static and so has no ripple on
> effects.

O.k.  I've merged this with os_loader, and called it load_block.

> 2. loadkernel is either a macro or a routine depending on whether
> CAN_BOOT_DISK is defined. It should be taken out and shot.  Ok, ok, just
> taken out. Into another file. Say it's called load.c. It should handle
> the sequencing of bootable devices. It would also separate the kernel
> name from the device name, which I assume is what you mean in 2.

The reference wasn't right but I was thinking along those kind of lines.
I have a first prototype of this currently working.

> 3. floppy.c is also misnamed since it also handles hard disks now. The
> code there should be integrated into some disk driving routines, which
> is what I assume you are creating. I would like to see the disk modules
> optional so that those who don't use them don't have to pay for it.

Agreed.  I'd like to make them as optional as the NIC drivers.
One of the great things with etherboot is that it is small and while I
want to enhance it, I don't want to loose that property.
 
> 3. Not sure how osloader comes into this. os_download is called from
> handleblock (formerly downloadkernel). Does it have to be involved?

If I push the functionality for handling an x86 bootsector into
os_download, I can load either an ELF image a tagged image or
an x86 bootsector from a raw partition with the same code. 
 
> The convention for specifying the driver type, partition and filename is
> another can of worms. However, it's delegated to the disk driver. All
> load.c has to know is which driver to call and to pass the tail of the
> path to it.

To some extent I agree.  But mostly I prefer to keep policy issues out
of the drivers.  But since I don't plan on implmenting partition,
and fs handling just yet I'm o.k.

There are lots of bits of etherboot that are a slightly of a messy,
and that makes it harder to enhance.  So while I walk through making
some enhancements.  I'm going to be cleaning up things as I go along.

One big thing I want to see is having drivers be fully self contained
so that to add a new driver consists solely of writing a driver file,
and adding an entry to the list of drivers.

Recently I worked with memtest86 and picked at all of the things
that irritated me with it, and then released it.  That turned out
fairly well.  My goal is to do something similiar with etherboot.

Lots of small changes but a big end result.  So for the moment at
least I'm actively developing it.

Eric

Re: [Etherboot-developers] NBP Help

[<ebi...@ln...>]

Peter Lister <P.L...@sy...> writes:

> Adding UNDI support as an Etherboot driver would be a good NBP project
> and could form the basis of a useful open source NBP toolkit. It would
> be useful to quite a few people because it would make Etherboot via PXE
> easier to set up for sites which have many hardware types.

I will agree it has potential.  As long as we prefer the internal
etherboot driver we should be fine.
 
> You could also improve Etherboot's PXE support (i.e. so that Etherboot
> can provide PXE to other NBPs), maybe merging the existing the NILO code
> so that Etherboot can run any NBP. The standard of the Intel PXE code
> library (used in most vendor's NIC firmware) is - er - low. Look at
> HPA's pxelinux pages or read the syslinux list to see just how low. Even
> devoted PXE users would like better open source PXE firmware; Etherboot
> (and it's driver library) is the obvious platform and has had skeleton
> PXE support added already (which, I note, Eric B just migrated to its
> very own pxe.c). This could be chainable (a "menu module"?) from a
> "vanilla Etherboot" in turn loading a "real" NBP like NTLOADER. Or even
> be statically linked with an existing binary NBP...

Note currently this code does not compile on non-freebsd, because it depends
on freebsd headers.   And I have broken the freebsd compile by
placing an #if 0 #endif pair around those include to encourage someone
to fix this.

Eric

Re: [Etherboot-developers] NBP Help

[Peter L. <P.L...@sy...>]

>      I am working on PXE. I would like to know how NBP interacts with
> PXE? do they use PXE stack Or they are OS loaders and so they install OS
> first and use the OS stack?

Read the PXE spec.

NBPs can use as much PXE as they need to (and unload what they don't
need). The UNDI network driver is available to NBP. So is DHCP/TFTP but
it's normally broken; use the etherboot code.

Look at Etherboot's PXELOADER code in loader.S to see a minimal NBP. It
just unloads the whole of PXE and then proceeds as if loaded from rom,
using it's own driver. There is a placeholder compile flag to leave UNDI
loaded for anyone interested in getting Etherboot to use it. Compare
with pxelinux, which uses UNDI, DHCP and TFTP.

I hope it's obvious that Etherboot must use either UNDI or a native
driver, or there's no way to load the OS. :)

Out of interest what are you doing with PXE? If all you need to do is
boot Linux, Etherboot or pxelinux will do this now. Writing a new NBP
just for fun seems pointless. Unless you have an odd idea of "fun".

Adding UNDI support as an Etherboot driver would be a good NBP project
and could form the basis of a useful open source NBP toolkit. It would
be useful to quite a few people because it would make Etherboot via PXE
easier to set up for sites which have many hardware types.

You could also improve Etherboot's PXE support (i.e. so that Etherboot
can provide PXE to other NBPs), maybe merging the existing the NILO code
so that Etherboot can run any NBP. The standard of the Intel PXE code
library (used in most vendor's NIC firmware) is - er - low. Look at
HPA's pxelinux pages or read the syslinux list to see just how low. Even
devoted PXE users would like better open source PXE firmware; Etherboot
(and it's driver library) is the obvious platform and has had skeleton
PXE support added already (which, I note, Eric B just migrated to its
very own pxe.c). This could be chainable (a "menu module"?) from a
"vanilla Etherboot" in turn loading a "real" NBP like NTLOADER. Or even
be statically linked with an existing binary NBP...

mknbi-pxe closedOS.pxe closedOS.nbi

...to turn it into something which can be loaded directly by Etherboot!

>    Can anybody tell me links those will give me more deatiled
> information on NBPs

Intel changed the URL, but kept no placeholder; even their own URLs have
not been updated, so you can be forgiven for not finding it...

http://www.intel.com/labs/manage/wfm/wfmspecs.htm

Re: [Etherboot-developers] pcmcia cardbus development

[Michael B. <mb...@fe...>]

On Wed, 12 Jun 2002, Ken Yap wrote:
> >I am new to the list and just found the etherboot program. I would like to
> >make it work through a pcmcia nic. I saw there is no support for it in the
> >program now but is on the to-do list.
> >I want to make a start on this development but I have no idea where to
> >start. Do anyone have an idea where to start ? documentation etc.
> Start with the Developers Manual. Depending on what kind of card it is,
> it might be easy. I believe compact PCI cards look like PCI devices.
> You could look at the Prism drivers which have support for a PCMCIA
> controller. Michael Brown did that one.

Actually, I ripped out the PCMCIA support from the Linux drivers during
the porting, since there wasn't a PCMCIA subsystem for Etherboot.  The PLX
support is still present; PLX is a PCI-to-PCMCIA bridge that works like a
very, very dumb PCMCIA controller.  If you buy a wireless PCI adaptor for
a PCMCIA card, it's probably based around the PLX.

I've designed bits of PCMCIA hardware before so I have a hazy recollection
of how the bus works.  Feel free to e-mail me to discuss things if you
want.  The hard work will be just in the initialisation stages:
enumerating, detecting and enabling the cards.  Once this stage is
complete, CardBus cards will appear to be PCI devices and PC Card cards
will appear to be ISA devices.

Detection will have to be a two-stage process; the PCMCIA controller will
need to be located by (probably) its PCI vendor and device IDs, then
you'll need to parse the CIS of any inserted PCMCIA cards to get the
network card IDs.

I suggest completely ignoring any hot-swapping issues.  If Etherboot can't
find a card it will abort and restart after a few seconds, so you'll pick
up a newly-inserted card anyway without having to explicitly code for it.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] [RFC] Multicast reception....

[<ebi...@ln...>]

Other points, that occur to me.

On testing.  I have already tested on a 15 node test cluster, and the
code will be regularly tested, and used on this cluster.  In
production it will be regularly used for installs on various small
(4-64) node clusters.  And in a month I can start testing on a 1000
node cluster as it is built up. 

Currently the protocol is going by the name SLAM.
Scalable Local Area Multicast.  Plus that is what it does to your
network when it is transmitting data :)

Slam seems to be close to one of those simple points where you gain
power because you are so simple.

The biggest advantage of the unicast channel for the clients is a
sysadmin only has to worry about a bad server going crazy with
multicast data, not the clients.

The biggest downside at the moment is there is only a GPL'd client and
not an open source server for SLAM.  (The best I could arrange).  But
with the protocol details out there and a relatively simple protocol I
can't imagine writing a server will be too hard.

Eric

[Etherboot-developers] NBP Help

[Rajesh S. P. <raj...@ta...>]

Hello,
     I am working on PXE. I would like to know how NBP interacts with
PXE? do they use PXE stack Or they are OS loaders and so they install OS
first and use the OS stack?
   Can anybody tell me links those will give me more deatiled
information on NBPs
Looking forward for replies.

Thanks in advance.
Regards,
Rajesh

Re: [Etherboot-developers] [RFC] Multicast reception....

[<ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> What about the standard protocol (or less-standard?) you want to have for 
> multicast? Do you have documentation at hand? 

You can scan the code for some more details but here is the basic protocol I
am using.  The target is multicast data on local networks.  So I have ttl set
to 1 on all of my nodes.  The security is approxiametly equal to tftp.

There are 3 types of packets (DATA, NACK, REQ).
There are 2 channels multicast and unicast.
There are 2 kinds of clients master/non-master.
The protocol handles both small and terabyte sized files,
a variable length binary encoding is used for the numbers to keep the
overhead down.

The DATA packet is transmitted over the multicast channel, it contains:
transaction number,
total file size,
block size,
packet number,
block size bytes worth of data

The NACK pact is transfered unicast to the server.
It contains from the begining of the file, pairs of.
received packets, requested packets

The REQ packet is transfered unicast to the clients, it contains.
transaction number,
total file size,
block size,

Unicast is used for the NACK and REQ packets because they aren't
broadcast to everyone on a pure layer 2 switch, and are a little
more likely to get through.  Additionally in any direction now there
is only one type of packet per ip address, port number pair.

server->REQ->client  unicast
server<-NACK<-client unicast
server->DATA->client multicast

The client:

At startup it first listens on the multicast channel and if it
finds data it downloads it, otherwise after a timeout the client
sends a NACK from the server to get the download started.

After receiving data if the client has not received everything
it waits for the transmission to restart, after the appropriate
timeout it sends a NACK doubles the possible timeout interal, and
waits again.  The exponential backoff of the clients should keep the
network quiet when the clients are running and the network is busy.

When all of the data has been received, if the client has transmitted
a NACK, it should transmit an additional NACK to the master consisting
of just the byte 0, to indicate it is going away.   

The final empty nack is an optimization to tell the server the client
is gone.  If the packet doesn't make it oh well.

Another optimization involves the server sending a REQ to the client.
In which case the client forgets it's timeout and sends a NACK
immediately to the server.  This allows the server to pick a
``master'' client and pick on it until that client has all of it's
data, ensuring some level of fairness.

The server:

Starts up and listens for nacks.

For every NACK it gets it adds the sending machine to it's
list of known clients.  Unless it is the special disconnect
NACK in which case it removes the client.

Looking at the data from the NACKs the server decides to send
some data.  Generally all the clients requested data is sent
but on large files it can be beneficial to send only as much as the
server can easily cache.

After the data is transmitted the server picks on a known client
and sends a REQ.  If the client doesn't respond within the servers
timeout it picks on another client and sends a REQ, and forgets the
previous client even existed.


Comments:

By doing all of the control packets over udp, and having no explicit
acknowledgement that the data even arived, some interesting things
result.

1) Minimum network packet count.  (except in the case of a slow
   server, whom all of the clients NACK)

2) Multiple policies can be implemented by both the client and the
   server.

3) By tracking which packets of the entire transmission have arrived,
   and delaying the NACKs full network bandwidth can be achieved.  As
   opposed to TFTP which is limited by the round trip time.

>Else I would like to start 
> adding tftp-mcast support as my quickly hacked daemon for that protocol at 
> least runs, on low-load-testing with two clients stably. Perhaps if ready I 
> could have a mass-test (ok, 15 clients is not much, but better that nothing) 
> the after-next weekend at my "private testing laboratory", until then I 
> should have made a release out of it, announce will follow. But of course, if 
> you have a better protocol at hand, please let me know.

Everything is now in CVS.  Take whichever one you prefer.  It wouldn't
be evil to have both in etherboot, but I would be surprised if the
experimental multicast tftp had any advantages except better
documentation.

Eric

[Etherboot-developers] Multicast && ALLMULTI

[<ebi...@ln...>]

All drivers in the cvs 5.1 tree have now had the code 
#ifdef ALLMULTI
#error multicast support is not yet implemented
#endif

Added so they will complain at compile time if someone hasn't added multicast
support to them yet.

Eric

Re: [Etherboot-developers] [COMMIT] Multicast & more.

[<ke...@us...>]

>I have committed my first first round of changes to be a productive
>bootloader for LinuxBIOS, into the etherboot-5.1 tree.  I believe I
>have only included the good bits but I have only tested the merge with
>my tree to see if it compiles.  Holler if it breaks, something for you/

Great. I'll see I can build it and put a rc1 tarball at the site.

[Etherboot-developers] [COMMIT] Multicast & more.

[<ebi...@ln...>]

I have committed my first first round of changes to be a productive
bootloader for LinuxBIOS, into the etherboot-5.1 tree.  I believe I
have only included the good bits but I have only tested the merge with
my tree to see if it compiles.  Holler if it breaks, something for you/

Included.
- Added multicast support
- Added a pc floppy driver
- reorganized osloader so the code is more local for the various file
formats
- rewrote the network stack filter functions so they are supplied explicitly the protocols
- made ipchksum handle odd lengths
- added an experimental multicast download protocol
- moved pxe support into it's own file.  Too many nasty ifdefs in the code otherwise


Eric

Re: [Etherboot-developers] pcmcia cardbus development

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >I am new to the list and just found the etherboot program. I would like to 
> >make it work through a pcmcia nic. I saw there is no support for it in the 
> >program now but is on the to-do list. 
> >
> >I want to make a start on this development but I have no idea where to 
> >start. Do anyone have an idea where to start ? documentation etc.
> 
> Start with the Developers Manual. Depending on what kind of card it is,
> it might be easy. I believe compact PCI cards look like PCI devices.
> You could look at the Prism drivers which have support for a PCMCIA
> controller. Michael Brown did that one.

As I understand it except for hotplug issues cardbus should pretty
much be pci.  Eventually etherboot might need some resource assignment
code so you can get at pci devices but otherwise it should be pretty
straight forward.  Actually handling card insert/removal while we
are trying to network boot could be a challenge.

Eric

Re: [Etherboot-developers] pcmcia cardbus development

[<ke...@us...>]

>I am new to the list and just found the etherboot program. I would like to 
>make it work through a pcmcia nic. I saw there is no support for it in the 
>program now but is on the to-do list. 
>
>I want to make a start on this development but I have no idea where to 
>start. Do anyone have an idea where to start ? documentation etc.

Start with the Developers Manual. Depending on what kind of card it is,
it might be easy. I believe compact PCI cards look like PCI devices.
You could look at the Prism drivers which have support for a PCMCIA
controller. Michael Brown did that one.

[Etherboot-developers] pcmcia cardbus development

[<ka...@mi...>]

Hello,

I am new to the list and just found the etherboot program. I would like to 
make it work through a pcmcia nic. I saw there is no support for it in the 
program now but is on the to-do list. 

I want to make a start on this development but I have no idea where to 
start. Do anyone have an idea where to start ? documentation etc.

Patrick