Thread: Re: [Etherboot-developers] NBP Help
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Peter L. <P.L...@sy...> - 2002-06-12 16:50:58
|
> 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 |
|
From: Peter L. <P.L...@sy...> - 2002-06-13 11:46:01
|
> "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! |
|
From: Rajesh S. P. <raj...@ta...> - 2002-06-13 12:39:46
|
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 |
|
From: <ebi...@ln...> - 2002-06-14 18:57:30
|
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 |
|
From: Peter L. <P.L...@sy...> - 2002-06-13 11:49:47
|
> 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. |
|
From: <ebi...@ln...> - 2002-06-12 23:02:16
|
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 |
|
From: Rajesh S. P. <raj...@ta...> - 2002-06-13 05:28:25
|
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
|
|
From: <ebi...@ln...> - 2002-06-13 06:28:07
|
"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 |
|
From: Rajesh S. P. <raj...@ta...> - 2002-06-13 09:36:39
|
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 |
|
From: <ebi...@ln...> - 2002-06-13 09:55:32
|
"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 |
|
From: Rajesh S. P. <raj...@ta...> - 2002-06-13 10:43:25
|
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
|
