Thread: Re: [Etherboot-developers] pxe
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <prl...@sy...> - 2003-05-21 14:45:08
|
> From the docs it's not clear, and from the sources, im still trying > to compile under FreeBSD, I have some way to go :-), so before I loose > myself, the short Q: > can/could etherboot be used to boot pxeboot? > the long way: > I have this Matchbox PC that someone dropped on my table, and > it runs Linux, and im trying to make it boot over the network, but > the NIC (Network Interface Chip :-), does not have PXE boot, it'a a CS89x0. > I see some emulate pxe for freebsd stuff but there seems to be > some parts missing. I don't know pxeboot (do you mean pxelinux?) The direct answer for almost any PXE Network Boostrap Program (NBP) on top of Etherboot is "not yet". Someone contributed code for a specific FreeBSD case, so don't waste your time unless you are also using FreeBSD. There is considerable motivation for completing enough PXE support for common NBPs (NTLOADER, pxelinux, bpbatch), so it seems likely to happen soon. If you'd like to help, that would be great. Note that Etherboot-on-PXE is being completed just now - don't confuse this with PXE-on-Etherboot. But you don't need to bother with PXE if the only OS you need is Linux. Etherboot is designed to boot Linux directly; PXE is NOT required as long as you have something to boot Etherboot from, such as a NIC ROM, a modular BIOS, a disk (or disk like entity). So, if you plan to getting this PC to network boot at all (PXE or not) you need some way to get Etherboot on it; get an image with the cs89x0.o driver from rom-o-matic in whatever form suits you. |
|
From: <prl...@sy...> - 2003-05-21 18:44:32
|
> ahh, but i did mean pxeboot :-) > I'm very much interested in booting via PXE, and FreeBSD specially > (hence pxeboot), and could put in some time, but my x86 assembly > skils are close do zero, but i have some resources at my disposal. OK - it seemed you were talking about a machine that ran Linux, which is the main focus of Etherboot. Just bear in mind that the initial target for development of PXE on Etherboot will probably be pxelinux. If you have a real need for PXE, that's fine, but there is a common misconception that "PXE" is another term for "network boot". Not so - if you just want Linux, PXE is just unnecessary complication. > im interesetd in etherboot setting the env. so that the loaded > program thinks it got loaded by a pxe boot-rom, actualy a minimum > pxe emulation is great - just open/close/udpread/uptwrite - not all > the jazz of wfm. The "E" in PXE means Environment; it is an execution environment defined by Intel's spec. When Etherboot provides a PXE environment, it really will BE a PXE implementation - not an "emulation". Code really will have been booted by a "PXE boot-rom", namely Etherboot; it does not have to be written by Intel to be PXE. I was trying to make the point that in addition to the desirable feature of supporting NBPs on top of Etherboot, a PXE boot rom can invoke Etherboot as an NBP (and soon use UNDI - note the separate thread on Michael Brown's progress). Just be aware that references to PXE in the context of Etherboot may not be want you want. I *believe* that the existing code for FreeBSD was designed to do exactly what you are describing, but it may have degraded in recent versions if no-one has stressed it. If you have having problems, consider reverting to an earlier version of Etherboot at the point where the FreeBSD stuff was added, since I believe that was reported as working: look through list archives to track what happened. I don't know if the original contributor of that code is still on the list, but you could try contacting him. > i can put the etherboot image on it's root partition (it has a micro > disc + some flash memory), or it can boot from a floppy, i'll check > that asap, just to make sure it's loaded ok. btw, how - if at all - > can i use lilo to boot etherboot? Get a LILO Etherboot image from rom-o-matic, put it somewhere on a partition LILO where can see it and add an entry in lilo.conf. It's a very convenient way to prototype boot environments. |
|
From: <ebi...@ln...> - 2003-05-21 19:00:41
|
prl...@sy... writes: > If you have a real need for PXE, that's fine, but there is a common > misconception that "PXE" is another term for "network boot". Not so - > if you just want Linux, PXE is just unnecessary complication. I believe that is also the case for FreeBSD. Though I am not terribly fond of the way FreeBSD support is currently built. There is no future proofing in there. > > im interesetd in etherboot setting the env. so that the loaded > > program thinks it got loaded by a pxe boot-rom, actualy a minimum > > pxe emulation is great - just open/close/udpread/uptwrite - not all > > the jazz of wfm. > > The "E" in PXE means Environment; it is an execution environment > defined by Intel's spec. When Etherboot provides a PXE environment, it > really will BE a PXE implementation - not an "emulation". Code really > will have been booted by a "PXE boot-rom", namely Etherboot; it does > not have to be written by Intel to be PXE. Given the holes in the implementation calling it emulation is probably a fair description. But then again given the holes in the PXE spec/practice we might qualify as implementing it. > I was trying to make the point that in addition to the desirable > feature of supporting NBPs on top of Etherboot, a PXE boot rom can > invoke Etherboot as an NBP (and soon use UNDI - note the separate > thread on Michael Brown's progress). Just be aware that references to > PXE in the context of Etherboot may not be want you want. > > I *believe* that the existing code for FreeBSD was designed to do > exactly what you are describing, but it may have degraded in recent > versions if no-one has stressed it. The code degraded before it made it into a production release. There may be a point in the cvs archive where the code works though. The core of the code looks o.k. but there are a few places where the code is likely to still have issues. The biggest problem is that the code depends on bsd specific headers and will never compile under anything else. If you could fix that the code is more likely to be maintained. Eric |
|
From: Michael B. <mb...@fe...> - 2003-05-22 11:28:34
|
> > The "E" in PXE means Environment; it is an execution environment > > defined by Intel's spec. When Etherboot provides a PXE environment, it > > really will BE a PXE implementation - not an "emulation". Code really > > will have been booted by a "PXE boot-rom", namely Etherboot; it does > > not have to be written by Intel to be PXE. > Given the holes in the implementation calling it emulation is > probably a fair description. But then again given the holes > in the PXE spec/practice we might qualify as implementing it. It's unlikely that Etherboot will ever implement the full PXE API. Implementing the TFTP and UDP layer calls would be relatively straightforward, but implementing the UNDI API calls would require a significant restructuring of the internal Etherboot driver API. This would offer *no* benefits other than being able to implement the full PXE API, and would have significant downsides in that Etherboot drivers would have to become a lot more complicated. (For a start, they'd have to use interrupts instead of polling.) PXE emulation, in the sense of implementing part of the PXE API, is probably a better goal than a full PXE implementation. > The code degraded before it made it into a production release. > There may be a point in the cvs archive where the code works though. > The core of the code looks o.k. but there are a few places where > the code is likely to still have issues. > The biggest problem is that the code depends on bsd specific headers > and will never compile under anything else. If you could fix > that the code is more likely to be maintained. There is now a copy of pxe.h from FreeBSD in Etherboot CVS, under arch/i386/include. I used it when writing the Etherboot UNDI driver. It's been edited slightly; I corrected several typos and one alignment bug. If this is the only header required, then we've now got it. Michael |
|
From: <prl...@sy...> - 2003-05-21 21:21:29
|
> I believe that is also the case for FreeBSD. Though I am not > terribly fond of the way FreeBSD support is currently built. There > is no future proofing in there. Open source should not depend on PXE. > Given the holes in the implementation calling it emulation is > probably a fair description. But then again given the holes > in the PXE spec/practice we might qualify as implementing it. The implementation may be incomplete - but one *emulates* something else. My point was that Etherboot would not "emulate" PXE or be somehow "artifical" or suboptimal - quite the opposite... Bochs, for instance, does not "emulate" BIOS calls - it implements them, just as Award does. It may frequently sit on top of emulated "hardware", but that's different - put it on ADLO and LinuxBIOS and I think it is fair to say that there is no "emulation" going on, or at least no more than a "normal" BIOS on the mobo. |
|
From: H. P. A. <hp...@zy...> - 2003-05-22 05:03:37
|
prl...@sy... wrote: >>I believe that is also the case for FreeBSD. Though I am not >>terribly fond of the way FreeBSD support is currently built. There >>is no future proofing in there. > > > Open source should not depend on PXE. > > >>Given the holes in the implementation calling it emulation is >>probably a fair description. But then again given the holes >>in the PXE spec/practice we might qualify as implementing it. > > > The implementation may be incomplete - but one *emulates* something > else. My point was that Etherboot would not "emulate" PXE or be somehow > "artifical" or suboptimal - quite the opposite... > > Bochs, for instance, does not "emulate" BIOS calls - it implements them, > just as Award does. It may frequently sit on top of emulated "hardware", > but that's different - put it on ADLO and LinuxBIOS and I think it is > fair to say that there is no "emulation" going on, or at least no more > than a "normal" BIOS on the mobo. > The best phrasing would be that Etherboot would implement a PXE subset. Eventually it might implement the full spec, but that is a large effort. -hpa |
|
From: Michael B. <mb...@fe...> - 2003-05-22 16:37:51
|
On Thu, 22 May 2003, Danny Braniss wrote: > > There is now a copy of pxe.h from FreeBSD in Etherboot CVS, under > > arch/i386/include. I used it when writing the Etherboot UNDI driver. > > It's been edited slightly; I corrected several typos and one alignment > > bug. If this is the only header required, then we've now got it. > hum, i think i sent out a message this morning, but it could have been > before coffee, so if this is a repost - sorry Did you send it to etherboot-developers-admin instead of etherboot-developers? > whith some minor twiks i managed to compile under FreeBSD, but there is > a minor unresolved: > main.o(.text+0x1459): undefined reference to `initsp' > and i found: > ./src/pcbios.S:.globl initsp > i think some initialization is missing, but since my knowledeg of x86 > assembler is zero, i have no idea how to fix this You seem to be using the 5.0 branch - is this deliberate? (The BSD header I was referring to has been placed into the 5.1 branch.) Michael |
|
From: <ebi...@ln...> - 2003-05-23 07:49:18
|
Michael Brown <mb...@fe...> writes:
> On Thu, 22 May 2003, Danny Braniss wrote:
> > > There is now a copy of pxe.h from FreeBSD in Etherboot CVS, under
> > > arch/i386/include. I used it when writing the Etherboot UNDI driver.
> > > It's been edited slightly; I corrected several typos and one alignment
> > > bug. If this is the only header required, then we've now got it.
> > hum, i think i sent out a message this morning, but it could have been
> > before coffee, so if this is a repost - sorry
>
> Did you send it to etherboot-developers-admin instead of
> etherboot-developers?
>
> > whith some minor twiks i managed to compile under FreeBSD, but there is
> > a minor unresolved:
> > main.o(.text+0x1459): undefined reference to `initsp'
> > and i found:
> > ./src/pcbios.S:.globl initsp
> > i think some initialization is missing, but since my knowledeg of x86
> > assembler is zero, i have no idea how to fix this
Wrong track. initsp was deleted. How the .globl initsp survived
is beyond me.
> You seem to be using the 5.0 branch - is this deliberate? (The BSD header
> I was referring to has been placed into the 5.1 branch.)
One branch or the other should not matter too much, in this
regard.
The two pieces of inline assembly in the pxe code in 5.1 are
both incorrect. For an old enough version of 5.0 the code
works. In particular 5.0.x one version before the inclusion
of the code.
Etherboot does not use inline assembly for this kind of thing
and that is what is causing the problem. Instead these hooks
are abstracted into subroutines, and just written in assembler.
The important part being the code is written as separate subroutines
with a clearly defined purpose.
So two things are needed.
1) A routine that will start a pxe image with the proper arguments.
To replace this junk of assembly:
Something similar to xstart16 is needed,
or possibly xstart16 can be generalized.
__asm__ __volatile__ (
"movb $1, pxeemu_nbp_active\n"
"call _prot_to_real\n"
".code16\n"
"movw %0, %%ax\n"
"movw %%ax, %%es\n"
"movl %1, %%ebx\n"
"ljmp $0x0,$0x7c00\n"
".code32\n"
: : "i" (RELOC >> 4),
"g" (((vm_offset_t)&pxenv) - RELOC));
2) A routine to generate a thunk that can be used to
reenter etherboot in 32bit mode, and transfer
control to the pxeemu handler. And eventually we will
need code to generate 16bit thunks as well. That
will allow us to replace this bit of assembly.
/* Switch Stacks */
__asm__("xorl %%eax, %%eax\n"
"movw initsp, %%ax\n"
"addl %0, %%eax\n"
"movl %%eax, %%esp\n"
: : "i" (RELOC));
Basically those two pieces of inline assembly are a maintenance
disaster because:
- What they are trying to do is not well abstracted.
- They are not doing things in the usual etherboot style.
- The code cannot even be compiled on anything except FreeBSD.
With the appropriate magic headers.
For 5.1 2 additional pieces need to happen:
- The pxenv structure needs to moved lower in memory if
it is to work with -DRELOCATE enabled.
- Etherboot needs to hook int 0x15 and reserve the memory
etherboot is living in. This may just be a cleanliness
issue.
Eric
|
|
From: <prl...@sy...> - 2003-05-22 19:57:35
|
> It's unlikely that Etherboot will ever implement the full PXE API. > Implementing the TFTP and UDP layer calls would be relatively > straightforward, but implementing the UNDI API calls would require a > significant restructuring of the internal Etherboot driver API. This > would offer *no* benefits other than being able to implement the full PXE > API, and would have significant downsides in that Etherboot drivers would > have to become a lot more complicated. (For a start, they'd have to use > interrupts instead of polling.) > PXE emulation, in the sense of implementing part of the PXE API, is > probably a better goal than a full PXE implementation. You guys seem to use the word "emulate" in an odd way. http://dictionary.reference.com/search?q=emulate I agree with the logic of what you are saying, Michael, just noting that "emulation" seems like the wrong word for "partial implementation". A partial implementation would be fine, I'm sure: NBPs are likely use the higher level APIs, as Eric pointed out in an earlier thread. Almost anyone else will be using the "features" of PXE (unlike Etherboot with a UNDI driver, which is trying to *replace* them). Intel might take a dim view of using "PXE" for something incomplete, though, even if it is effective. How about PSKE? Or POXE? PIKI? Thinking aloud, how feasible would it be to make a quasi interrupt driven driver, on top of the (existing) polling drivers, which could be exported as UNDI? I can't help noting that this *would* be emulation as I understand the term. :-) I do realise that this would be an extremely pointless project if NBP actually needs it - it is not a practical suggestion, but once the PXE skeleton is in place and stable I can imagine that someone might try. |
|
From: Michael B. <mb...@fe...> - 2003-05-22 20:47:20
|
On Thu, 22 May 2003 prl...@sy... wrote:
> Thinking aloud, how feasible would it be to make a quasi interrupt
> driven driver, on top of the (existing) polling drivers, which could be
> exported as UNDI? I can't help noting that this *would* be emulation as
> I understand the term. :-) I do realise that this would be an extremely
> pointless project if NBP actually needs it - it is not a practical
> suggestion, but once the PXE skeleton is in place and stable I can
> imagine that someone might try.
Two main obstacles that I can see:
1. The hardware interrupts need to be enabled. This requires all the
drivers to be modified.
2. poll() needs to be capable of being called as part of an interrupt
service routine.
We don't actually need to implement ISRs, 8259A-handling code etc.; under
the UNDI model the responsibilities are divided as follows:
UNDI driver: enable the interrupt on the NIC, pass back the IRQ number to
the protocol driver ("protocol driver" in PXE terminology meaning the
program that is using the UNDI driver).
Protocol driver: install an ISR for the specified IRQ and enable it.
Protocol driver: handle interrupts. Call the UNDI driver's "ISR"
routine to determine whether or not this interrupt has originated from our
NIC. If so, set a flag and exit the interrupt handler.
Protocol driver: notice the flag set by the interrupt handler, call the
UNDI driver's "ISR" routine again to read out the actual data.
In practice, we might be able to get away with the following modifications
to all drivers:
1. In probe(): enable interrupts on the NIC, pass back the IRQ (probably
via an extra member in the "dev" structure).
2. Split poll() into two routines:
a) poll(); a routine that *very quickly* determines whether or not there
is a packet waiting and does nothing else. Must be able to be called
as part of an interrupt service routine.
b) receive(): receive the actual data.
This wouldn't allow us to implement the full UNDI API (with calls like
"set MAC address", "get link speed" etc.), but it would be enough to cover
all the calls that are essential for initialisation and transmitting /
receiving data. We could always hack round the other ones (e.g. return
success for "set MAC address" as long as it's being set to it's current
value anyway).
It's starting to look easier each time I think about it.
One interesting case would be PXEAPI on top of Etherboot on top of UNDI.
This would involve having two !PXE structures in memory, which could
really confuse a NBP. I imagine we'd have to corrupt the UNDI driver's
!PXE structure so that it still functioned but wouldn't be detected.
Michael
|
