etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] UNDI driver

[H. P. A. <hp...@zy...>]

Michael Brown wrote:
>>>Question 1: Is there currently any method for allocating base memory?  I
>>>need space for three structures:
>>
>>Memory should be taken off of the TOP of the 640K chunk of memory.
>>That is the only way ancient DOS memory reporting APIs can cope.
>>And in etherboot that should not be hard to report.  We might want to
>>think of bounce buffers to hold data that will eventually go there.
> 
> 
> OK, but am I right in thinking that there is currently no mechanism for 
> doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
> could be ripped out for this purpose.
> 

There are two things: reserving low (DOS) memory, which is just a matter 
of poking a variable in low memory, and reserving high memory, which is 
a matter of hooking INT 15h and and intercepting the AX=88h, AX=E801h, 
AX=E881h and AX=E820h calls.  The latter is quite complex, especially 
since the E820h memory map is frequently insane in various ways.

MEMDISK contains code to read out the memory map, canonicalize it, and 
provide the INT 15h hooks.

	-hpa

Re: [Etherboot-developers] UNDI driver

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

> > Question 1: Is there currently any method for allocating base memory?  I
> > need space for three structures:
> Memory should be taken off of the TOP of the 640K chunk of memory.
> That is the only way ancient DOS memory reporting APIs can cope.
> And in etherboot that should not be hard to report.  We might want to
> think of bounce buffers to hold data that will eventually go there.

OK, but am I right in thinking that there is currently no mechanism for 
doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
could be ripped out for this purpose.

> Losing 128K of memory will have some interesting affects on mknbi and
> friends.

It won't always be 128K; the UNDI driver specifies how much space it needs 
for its code and data segments, so we can allocate only what's necessary.

> For the temporary can you just use real_call and a buffer allocated on
> the stack?  It has provisions for coping with data left on the return
> stack.   This does not solve the issue but it means we only need the
> temporary stack.

The largest chunk of data I need is the whole transmit buffer; I need to 
make this available to the real-mode UNDI API transmit call, which AFAIK 
means copying it into base memory.  Is there enough room for this on the 
stack and, if so, can you give me some pointers on how it works?  I'll 
need to know the addresses of the structures before going into the 
assembler code, otherwise my assembler wrappers will have to be 
significantly more complex.

> > Question 2: I have an assembly routine _undi_call that is a wrapper around 
> > the real-mode UNDI API calls.  
> Does _undi_call use real_call?

Yes.  I've checked in the code to pcbios.S temporarily, so that (a) people 
can build and test the driver and (b) you can see exactly what the wrapper 
currently does.

Please note that I've basically learnt x86 assembler over the past four 
days, so there's bound to be a much simpler way of doing it.

> The big question is how small is undi_call?  If it is small enough
> placing it pcbios.S may make sense.  As it could be packed into some
> of the space usually used for alignment or what not.  But I do see
> the point, if it has size putting it in every driver is probably
> worse.

It's tiny; just a small wrapper around real_call.  I pass in a structure
that contains the address of the UNDI API routine and 3 words to push onto
the stack before making the API call.  _undi_call just switches to real 
mode, pushes the parameters onto the stack, jumps to the specified 
address, cleans up the stack and returns.  It's not far away from being a 
generic "call any real-mode routine" wrapper.  (It might be handy to have 
one of these, thinking about it.)

Michael

Re: [Etherboot-developers] UNDI driver

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

> But as there's a common context for all these initialisations, the
> upshot is that though we actually find nic 0, but we use the context
> (MAC address etc) from the LAST nic in the search order (or rather, the
> last nic that initialised).

This doesn't make a lot of sense; only one UNDI driver should ever get 
initialised (unless it fails to boot and another one is given a chance), 
and the BIOS should pass the PCI bus, device and function number in AX 
when it calls the first two initialisation routines.  The UNDI driver 
should then use this information to locate its hardware, from which it can 
extract its MAC address.

Not that it matters, given that Etherboot doesn't suffer from this 
particular problem, but it's a curiosity.

Incidentally, the interaction between multiple UNDI ROMs and multiple NICs 
is not well defined in Etherboot at the moment.  UNDI ROMs will be tried 
sequentially; if one fails to boot then the next will be tried the next 
time probe() is called.  However, if we have two NICs and two UNDI ROMs, 
this means that they will be tried in the following combination:

  NIC 1, UNDI ROM A
  NIC 2, UNDI ROM B

where there is no necessary connection between NIC 1 and UNDI ROM A other 
than that NIC 1 is the first NIC found in the system and UNDI ROM A is the 
first UNDI ROM found in the system (which won't necessarily belong to NIC 
1).

Theoretically, it's possible to use romaddr from the PCI device to locate 
the ROM, but I always seem to get a zero in romaddr, even when the ROM can 
be detected by scanning.

What we probably want to do is try combinations in the following order:

  NIC 1, UNDI ROM A
  NIC 2, UNDI ROM A
  NIC 1, UNDI ROM B
  NIC 2, UNDI ROM B

which could be achieved by judicious use of a few static variables.  
However, in the case when NICs 1 and 2 are of different types, we could 
have problems: the UNDI ROMs may not bother to check that the hardware 
device specified by AX is of the correct type before they start setting 
registers etc...

Michael

Re: [Etherboot-developers] UNDI driver

[<prl...@sy...>]

> > I like the fact we can unload and reload the PXE stack.  The only dow=
nside
> > of this is that we don't know what NIC we booted off of.  Oh well.
> =

> You do; when you initialise a PXE stack you have to pass in the PCI bus=
,
> device and function.  The structure is "take this PCI device, try to
> locate and initialise an UNDI driver for it", rather than "try to locat=
e
> and initialise an UNDI driver, let it find its own NIC".

Eric, if I understand Michael right, the issue I'm griping about is more
how BIOSen interacts with the PXE code. The dumb BIOS action we've seen
is to initialise everything (in PCI scan order) and then try to boot off
the first nic (in PCI scan order).

But as there's a common context for all these initialisations, the
upshot is that though we actually find nic 0, but we use the context
(MAC address etc) from the LAST nic in the search order (or rather, the
last nic that initialised). D'oh... where are 2 nics embedded on a mobo,
this may work more sanely because the BIOS hopefully knows exactly what
is in there. Our local workround was to scrunge the 3Com nic rom for all
everything except the first NIC.

Michael's code use the normal Etherboot search order, initialises each
NIC and then immediately tries to use the NIS; only if it fails and
needs to try the next nic will it go on and initialise *that*.  So the
context we use is always the right one for the nic.

Vasil pointed out to me recently that Etherboot is a very effective way
of getting round buggy BIOSen. :) Here is another example.

Re: [Etherboot-developers] UNDI driver

[<prl...@sy...>]

> > Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE
> > initialisation (and therefore probably everyone else's, though I haven't
> > tried) with multiple NICs that the MAC address used is that of the
> > *last* NIC to initialise? This confuses people because it almost always
> > means that it never uses the one that Linux calls eth0.
> 
> MAC address used is the MAC address stored on the NIC EEPROM; the one 
> known to UNDI as the "Permanent Node Address".
> 
> We will use PCI cards in the same order that Etherboot normally finds 
> them.  If Etherboot uses the same scanning order as Linux, then we should 
> end up using the one that Linux calls eth0.  This is independent of the 
> Etherboot UNDI driver; it's determined by pci.c.

The order is "normal Etherboot order, whatever that is". Good, this is a
definite win.

> The UNDI driver will therefore consist of  two files: undi.c and
> undi_wrapper.S (plus the headers); most drivers consist only of a single
> C file.  The Makefile will, I think, have to be altered to allow drivers
> to consist of more than just the one file.

Oh, I see. I suppose you could munge the assembler into the C (if it's
GNU friendly, but it's a good thing to have drivers be >1 C file.

Re: [Etherboot-developers] UNDI driver

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

Michael Brown <mb...@fe...> writes:

> > > Another small difference is that the UNDI driver claims to be able to
> > > handle any NIC, whereas most drivers specify a list of PCI IDs.  If the
> > > UNDI driver can't find an UNDI ROM for the card, it will give up.  We may
> > > therefore need to change the core driver scanning code to try multiple
> > > drivers for a specific PCI vendor:device ID, if people are going to want 
> > > to build images that contain UNDI and other drivers.
> > Actually I am pretty certain that functionality is already present.
> 
> There's a comment in pci.c that says 
>   /* Assume there is only one match of the correct type */
> 
> I haven't checked the actual code, so it might be a leftover comment.

It needs a close look but it appears to be a left over comment.
 
> > I had a few bug fixes sitting in my tree with respect to pci scanning
> > and I have just commited them.
> 
> I'm not seeing anything appearing in CVS.  Can you check that the commit 
> worked ok?

I put everything in the tree and then for got the all important
cvs commit .

The code should show up now.  The changes were very tiny but there
was an obscure bug that etherboot would miss the second NIC in a multi-NIC
configuration.  If one nic was a subfunction.  That should be cleared up
now.

Eric

Re: [Etherboot-developers] UNDI driver

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

Michael Brown <mb...@fe...> writes:

> There is now a very-nearly working UNDI driver in 5.1 CVS under
> arch/i386/drivers/net.  This driver allows Etherboot to work with any NIC
> for which an UNDI option ROM is provided.
> 
> The driver does not require Etherboot to be started by chaining from PXE;  
> it will scan for an UNDI ROM and initialise it fully from scratch.  I have
> been testing by booting from floppy, which works fine.  I imagine that 
> PXE-chaining would also work, although I haven't tested it yet.
> 
> Note that you cannot yet use the Etherboot UNDI driver to actually boot a
> kernel;  although all the routines are working and the driver can get a
> DHCP lease and start downloading a file, it dies instantly because the
> downloaded file stomps right over the PXE UNDI driver.  In order to fix 
> this, I need to sort out a method for allocating base memory in Etherboot.
> 
> Question 1: Is there currently any method for allocating base memory?  I
> need space for three structures:

Memory should be taken off of the TOP of the 640K chunk of memory.
That is the only way ancient DOS memory reporting APIs can cope.

And in etherboot that should not be hard to report.  We might want to
think of bounce buffers to hold data that will eventually go there.

Losing 128K of memory will have some interesting affects on mknbi and
friends.

> 1. The PXE UNDI driver code segment (up to 64K, probably 16K)
> 2. The PXE UNDI driver data segment (up to 64K, probably 16K)
> 3. Temporary buffers that I can stick data into while calling the 
>    real-mode UNDI API (about 2-3K).

Plan on the UNDI drivers taking 64K the ones for at least
Broadcom's gigabit NIC almost certainly will.

For the temporary can you just use real_call and a buffer allocated on
the stack?  It has provisions for coping with data left on the return
stack.   This does not solve the issue but it means we only need the
temporary stack.

> I'm currently (as a quick "test-the-driver" method) dumping these at
> pseudo-random places in base memory, which works fine up to the point that
> a kernel image loads...  :-)
> 
> 
> Question 2: I have an assembly routine _undi_call that is a wrapper around 
> the real-mode UNDI API calls.  

Does _undi_call use real_call?

> I've placed this in pcbios.S but haven't 
> yet checked it in because it seems like a bad place to put it; it would 
> end up being compiled in to every Etherboot image, not just the UNDI one.  
> Ideally, I'd like to create a file undi_wrapper.S in 
> arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> have to edit genrules.pl to achieve this, unless anyone can suggest a 
> quick and easy method?

The big question is how small is undi_call?  If it is small enough
placing it pcbios.S may make sense.  As it could be packed into some
of the space usually used for alignment or what not.  But I do see
the point, if it has size putting it in every driver is probably
worse.

Eric

Re: [Etherboot-developers] UNDI driver

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

> > You can happily unload the PXE stack; the UNDI driver will simply 
> > reinstall it from the UNDI ROM.  It searches for a PXE stack in memory 
> > before looking for ROMs, so a loaded PXE stack should work.
> > If the PXE stack has been left in a "running" state then it will fail to
> > initialise, ignore the loaded stack and try to load a new one from ROM.  
> > There is *no* clean way to tell whether or not a PXE stack is running or
> > not; the API call for "get current state" has the same number as the API
> > call for "shutdown stack"...
> I like the fact we can unload and reload the PXE stack.  The only downside
> of this is that we don't know what NIC we booted off of.  Oh well.

You do; when you initialise a PXE stack you have to pass in the PCI bus,
device and function.  The structure is "take this PCI device, try to
locate and initialise an UNDI driver for it", rather than "try to locate
and initialise an UNDI driver, let it find its own NIC".

> > No; except that it requires an assembler stub because the UNDI API calls 
> > (at least some of them) have to be executed in real mode.  This assembler 
> > stub should ideally be present only in the UNDI driver, which means that 
> > it shouldn't go in pcbios.S.  The UNDI driver will therefore consist of 
> > two files: undi.c and undi_wrapper.S (plus the headers); most drivers 
> > consist only of a single C file.  The Makefile will, I think, have to be 
> > altered to allow drivers to consist of more than just the one file.
> Or we can have a special case in the makefile, for the supporting code.

OK.  As mentioned in another message, I'm planning on tidying up the 
Makefiles a bit; there are various other problems like drivers not being 
recompiled when the header files change.  If it's easy to slot in 
undi_wrapper.S in a generic way then I'll do so, otherwise I'll just add a 
special case in arch/i386/Makefile.

> > Another small difference is that the UNDI driver claims to be able to
> > handle any NIC, whereas most drivers specify a list of PCI IDs.  If the
> > UNDI driver can't find an UNDI ROM for the card, it will give up.  We may
> > therefore need to change the core driver scanning code to try multiple
> > drivers for a specific PCI vendor:device ID, if people are going to want 
> > to build images that contain UNDI and other drivers.
> Actually I am pretty certain that functionality is already present.

There's a comment in pci.c that says 
  /* Assume there is only one match of the correct type */

I haven't checked the actual code, so it might be a leftover comment.

> I had a few bug fixes sitting in my tree with respect to pci scanning
> and I have just commited them.

I'm not seeing anything appearing in CVS.  Can you check that the commit 
worked ok?

Michael

Re: [Etherboot-developers] UNDI driver

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

Michael Brown <mb...@fe...> writes:

> > Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE
> > initialisation (and therefore probably everyone else's, though I haven't
> > tried) with multiple NICs that the MAC address used is that of the
> > *last* NIC to initialise? This confuses people because it almost always
> > means that it never uses the one that Linux calls eth0.
> 
> MAC address used is the MAC address stored on the NIC EEPROM; the one 
> known to UNDI as the "Permanent Node Address".
> 
> We will use PCI cards in the same order that Etherboot normally finds 
> them.  If Etherboot uses the same scanning order as Linux, then we should 
> end up using the one that Linux calls eth0.  This is independent of the 
> Etherboot UNDI driver; it's determined by pci.c.
> 
> > > I imagine that PXE-chaining would also work, although I haven't tested
> > > it yet.
> > PXE chaining is, of course, what lots of people want so that they don't
> > have to worry about loading the right driver. Just remember to leave PXE
> > loaded, since by default the first act of PXE-chaining to is to unload
> > PXE.  :)
> 
> You can happily unload the PXE stack; the UNDI driver will simply 
> reinstall it from the UNDI ROM.  It searches for a PXE stack in memory 
> before looking for ROMs, so a loaded PXE stack should work.
> 
> If the PXE stack has been left in a "running" state then it will fail to
> initialise, ignore the loaded stack and try to load a new one from ROM.  
> There is *no* clean way to tell whether or not a PXE stack is running or
> not; the API call for "get current state" has the same number as the API
> call for "shutdown stack"...

I like the fact we can unload and reload the PXE stack.  The only downside
of this is that we don't know what NIC we booted off of.  Oh well.


> > > Ideally, I'd like to create a file undi_wrapper.S in 
> > > arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> > > have to edit genrules.pl to achieve this, unless anyone can suggest a 
> > > quick and easy method?
> > Dumb question - does anything make UNDI fundamentally different from a
> > nic driver? That's how people will want to treat it, so I say treat it
> > exactly like a driver, with the possible exception that UNDI is included
> > by default as a last resort driver for PXE images but not others.
> 
> No; except that it requires an assembler stub because the UNDI API calls 
> (at least some of them) have to be executed in real mode.  This assembler 
> stub should ideally be present only in the UNDI driver, which means that 
> it shouldn't go in pcbios.S.  The UNDI driver will therefore consist of 
> two files: undi.c and undi_wrapper.S (plus the headers); most drivers 
> consist only of a single C file.  The Makefile will, I think, have to be 
> altered to allow drivers to consist of more than just the one file.

Or we can have a special case in the makefile, for the supporting code.
 
> Another small difference is that the UNDI driver claims to be able to
> handle any NIC, whereas most drivers specify a list of PCI IDs.  If the
> UNDI driver can't find an UNDI ROM for the card, it will give up.  We may
> therefore need to change the core driver scanning code to try multiple
> drivers for a specific PCI vendor:device ID, if people are going to want 
> to build images that contain UNDI and other drivers.

Actually I am pretty certain that functionality is already present.

I had a few bug fixes sitting in my tree with respect to pci scanning
and I have just commited them.

Eric

Re: [Etherboot-developers] UNDI driver

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

> Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE
> initialisation (and therefore probably everyone else's, though I haven't
> tried) with multiple NICs that the MAC address used is that of the
> *last* NIC to initialise? This confuses people because it almost always
> means that it never uses the one that Linux calls eth0.

MAC address used is the MAC address stored on the NIC EEPROM; the one 
known to UNDI as the "Permanent Node Address".

We will use PCI cards in the same order that Etherboot normally finds 
them.  If Etherboot uses the same scanning order as Linux, then we should 
end up using the one that Linux calls eth0.  This is independent of the 
Etherboot UNDI driver; it's determined by pci.c.

> > I imagine that PXE-chaining would also work, although I haven't tested
> > it yet.
> PXE chaining is, of course, what lots of people want so that they don't
> have to worry about loading the right driver. Just remember to leave PXE
> loaded, since by default the first act of PXE-chaining to is to unload
> PXE.  :)

You can happily unload the PXE stack; the UNDI driver will simply 
reinstall it from the UNDI ROM.  It searches for a PXE stack in memory 
before looking for ROMs, so a loaded PXE stack should work.

If the PXE stack has been left in a "running" state then it will fail to
initialise, ignore the loaded stack and try to load a new one from ROM.  
There is *no* clean way to tell whether or not a PXE stack is running or
not; the API call for "get current state" has the same number as the API
call for "shutdown stack"...

> > Ideally, I'd like to create a file undi_wrapper.S in 
> > arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> > have to edit genrules.pl to achieve this, unless anyone can suggest a 
> > quick and easy method?
> Dumb question - does anything make UNDI fundamentally different from a
> nic driver? That's how people will want to treat it, so I say treat it
> exactly like a driver, with the possible exception that UNDI is included
> by default as a last resort driver for PXE images but not others.

No; except that it requires an assembler stub because the UNDI API calls 
(at least some of them) have to be executed in real mode.  This assembler 
stub should ideally be present only in the UNDI driver, which means that 
it shouldn't go in pcbios.S.  The UNDI driver will therefore consist of 
two files: undi.c and undi_wrapper.S (plus the headers); most drivers 
consist only of a single C file.  The Makefile will, I think, have to be 
altered to allow drivers to consist of more than just the one file.

Another small difference is that the UNDI driver claims to be able to
handle any NIC, whereas most drivers specify a list of PCI IDs.  If the
UNDI driver can't find an UNDI ROM for the card, it will give up.  We may
therefore need to change the core driver scanning code to try multiple
drivers for a specific PCI vendor:device ID, if people are going to want 
to build images that contain UNDI and other drivers.

Michael

Re: [Etherboot-developers] UNDI driver

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

> There is now a very-nearly working UNDI driver in 5.1 CVS under
> arch/i386/drivers/net.  This driver allows Etherboot to work with any N=
IC
> for which an UNDI option ROM is provided.

It's annoying that neither Vasil nor I will get the glory, but I'm
pleased that someone has finally worked up the steam. Well done,
Michael.

> The driver does not require Etherboot to be started by chaining from PX=
E;  =

> it will scan for an UNDI ROM and initialise it fully from scratch.  I h=
ave
> been testing by booting from floppy, which works fine. =


Nice.... we can have driver specific builds with a PXE "last resort"
driver regardless of the mechanism.

Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE
initialisation (and therefore probably everyone else's, though I haven't
tried) with multiple NICs that the MAC address used is that of the
*last* NIC to initialise? This confuses people because it almost always
means that it never uses the one that Linux calls eth0.

> I imagine that PXE-chaining would also work, although I haven't tested
> it yet.

PXE chaining is, of course, what lots of people want so that they don't
have to worry about loading the right driver. Just remember to leave PXE
loaded, since by default the first act of PXE-chaining to is to unload
PXE.  :)

Most people just pick up pxelinux as a compiled image and have no reason
to build. I'll be interested to see how many people want a no-brainer
PXE/UNDI image, as opposed to driver-specific, from rom-o-matic.

> Ideally, I'd like to create a file undi_wrapper.S in =

> arch/i386/drivers/net and have this linked in.  I suspect I'm going to =

> have to edit genrules.pl to achieve this, unless anyone can suggest a =

> quick and easy method?

Dumb question - does anything make UNDI fundamentally different from a
nic driver? That's how people will want to treat it, so I say treat it
exactly like a driver, with the possible exception that UNDI is included
by default as a last resort driver for PXE images but not others.

[Etherboot-developers] manufacturer of garments and bags in China

[Rachel <se...@pu...>]

Dear Sir,  

I have the pleasure to know your esteemed corp. 

We are a manufacturer & exporter of garments and bags in Quanzhou, China.

I think we can cooperate and supply you with garments as you need.  

The following is some introductions about our company.

       Set up: 1988

       Type: manufacturer & exporter

       Product: knitted garments and bags

       Employees: 1300 persons ( garments factory: 500      bags factory: 800)

       Product data:       

                                  product (main items)                      capacity(/year)

                                  brief                                    2,000,000dzs    

                                  baby body                                1,800,000dzs

                                  boxer short                                200,000dzs

                                  pajama                                      50,000dzs

                                  soft bag                                 1,500,000pcs

                                  hard bag                                   500,000pcs

Mimn order:  300dzs for garments

Payment:  irrevocable L/C at sight

Bank: BANK OF CHINA


Our garment factory mainly specialize in Lady's and men's underwear,

children's wear, baby's wear, pajama, boxer shorts, T-shirt, etc. 

The materials we often use are cotton, T/C, Polyester, Polyamide, 

Elasthan, and Polyamide. Our products are design with PAD system, 

produced with advanced equipment, processed in highly quality control 

system with seasoned workmanship and high efficiency. Our main market 

is Europe, Australia, Japan and America. We also accept the orders designed 

and required by costumers. You can see some pictures of our samples through 

our web http://www.senwer.com. (For more pictures in your interesting, 

pls kindly contact us directly). 
 

Our bag factory was founded in 1988, too. We produce all kinds of bags, 

including suitcase, backpack, travel bag, shoulder bag, sport bag, trolley, 

camera bag, tote bag, school bag, computer case, luggage,waist bag, notecase, etc. 

And the goods have met a great favor in the Europe countries, Australia 

and America because of their good quality, beautiful design and competitive price.


Thank you very much. Hope you will give us an opportunity to do 

business together and we will try our level best to fulfill your present 

requirement. Should you therefore need any more details for your 

clarification, pls do not hesitate to contact us. And you are welcome 

to visit our factories.


With best regards


Rachel Wang

Mob:0086-13960286700
E-mail:ra...@se...


Jason Chen

Mob:0086-13959893400
E-mail: jas...@se...


Vicki Wang

Mob:0086-13960228599
E-mail: vi...@se...


-----------------------------------------------------------------------------

SENWER GARMENTS CO., LTD.

ADD: Room F202, Fugui Renjia Building, Liuguan Road, Quanzhou, Fujian, China.

Tel: 0086-595-2506700    Fax: 0086-595-2563400    P.C.:362000

Http://www.senwer.com    E-mail: se...@pu...

-----------------------------------------------------------------------------

[Etherboot-developers] UNDI driver

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

There is now a very-nearly working UNDI driver in 5.1 CVS under
arch/i386/drivers/net.  This driver allows Etherboot to work with any NIC
for which an UNDI option ROM is provided.

The driver does not require Etherboot to be started by chaining from PXE;  
it will scan for an UNDI ROM and initialise it fully from scratch.  I have
been testing by booting from floppy, which works fine.  I imagine that 
PXE-chaining would also work, although I haven't tested it yet.

Note that you cannot yet use the Etherboot UNDI driver to actually boot a
kernel;  although all the routines are working and the driver can get a
DHCP lease and start downloading a file, it dies instantly because the
downloaded file stomps right over the PXE UNDI driver.  In order to fix 
this, I need to sort out a method for allocating base memory in Etherboot.

Question 1: Is there currently any method for allocating base memory?  I
need space for three structures:

1. The PXE UNDI driver code segment (up to 64K, probably 16K)
2. The PXE UNDI driver data segment (up to 64K, probably 16K)
3. Temporary buffers that I can stick data into while calling the 
   real-mode UNDI API (about 2-3K).

I'm currently (as a quick "test-the-driver" method) dumping these at
pseudo-random places in base memory, which works fine up to the point that
a kernel image loads...  :-)


Question 2: I have an assembly routine _undi_call that is a wrapper around 
the real-mode UNDI API calls.  I've placed this in pcbios.S but haven't 
yet checked it in because it seems like a bad place to put it; it would 
end up being compiled in to every Etherboot image, not just the UNDI one.  
Ideally, I'd like to create a file undi_wrapper.S in 
arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
have to edit genrules.pl to achieve this, unless anyone can suggest a 
quick and easy method?


Michael

[Etherboot-developers] Makefile - advance warning of changes

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

While hacking on the UNDI driver, I've noticed that quite a few of the 
dependencies within the Makefiles are incorrect.  I'm planning to hack 
around with genrules.pl etc. to fix this either today or tomorrow.  If 
you've got any pending changes to

  genrules.pl
  Makefile
  Makefile.main
  Makefile-i386
  Makefile-ia64

then please check them in asap, or post a message and I'll hold off my 
changes.

Michael

Re: [Etherboot-developers] No simple loading from IDE...

[Michael G. <mge...@so...>]

On 13 May 2003, Eric W. Biederman wrote:

> Michael Gentili <mge...@so...> writes:
> 
> > On Fri, 9 May 2003, Timothy Legge wrote:
> > 
> > > > What were the issues (so I don't repeat any mistakes)?
> > > 
> > > I only know my issues.  Ken pulled out boot1a.s so I assume that he had more
> > issues than just mine.
> 
> boot1a.S could not handler large etherboot images so:
> etherboot.lzdsk would not work because it was not loaded
> properly and the code was not easily repairable, or even traceable.

Yes, we've encountered this problem too.  It looks like my boss may 
give me some time to figure out something from scratch that does 
support larger etherboot images as we have a need for multiple 
drivers in one image.

> > ----------------------------IMPORTANT NOTICE----------------------------
> > 
> > This message, and its attachments if any, is intended only for the use of
> > the individual or entity to which it is addressed, and contains information
> > that is Valuable, Proprietary and Confidential to SOMA Networks, Inc. If the
> > reader of this message is not the intended recipient, or an employee or agent
> > authorized and responsible for delivering the message to the intended
> > recipient, you are hereby notified that any dissemination, distribution or
> > copying of this communication is strictly prohibited. If you have received
> > this communication in error, please immediately notify SOMA Networks, Inc.
> > by email at le...@so... and delete all copies of the message.
> 
> Um..  That suffix does not sound correct for a public mailing list.

Oops, you're right; my apologies.  I'm not supposed to attach it to 
Public/Open Source discussions as it's not really in the spirit of 
things :)

Re: [Etherboot-developers] No simple loading from IDE...

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

Michael Gentili <mge...@so...> writes:

> On Fri, 9 May 2003, Timothy Legge wrote:
> 
> > > What were the issues (so I don't repeat any mistakes)?
> > 
> > I only know my issues.  Ken pulled out boot1a.s so I assume that he had more
> issues than just mine.

boot1a.S could not handler large etherboot images so:
etherboot.lzdsk would not work because it was not loaded
properly and the code was not easily repairable, or even traceable.

> ----------------------------IMPORTANT NOTICE----------------------------
> 
> This message, and its attachments if any, is intended only for the use of
> the individual or entity to which it is addressed, and contains information
> that is Valuable, Proprietary and Confidential to SOMA Networks, Inc. If the
> reader of this message is not the intended recipient, or an employee or agent
> authorized and responsible for delivering the message to the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this communication in error, please immediately notify SOMA Networks, Inc.
> by email at le...@so... and delete all copies of the message.

Um..  That suffix does not sound correct for a public mailing list.

Eric

RE: [Etherboot-developers] No simple loading from IDE...

[Michael G. <mge...@so...>]

On Fri, 9 May 2003, Timothy Legge wrote:

> > What were the issues (so I don't repeat any mistakes)?
> 
> I only know my issues.  Ken pulled out boot1a.s so I assume that he had more issues than just mine.  
> 
> When I created a boot floppy, a setting in boot1a.S was not getting updated.  Apparently, the code was susposed to create the floppy image calculate the size update boot1a.S and recompile and write to the floppy.
> 
> If you can find a way to fix that on my systems, I would be happy enough to go back to boot1a.S.  However, I don't know what other issues existed in that implamentation.  Although I seem to remember that Ken mentioned that it depended on BIOS calls that may not be implemented everwhere.

OK, thanks.  I'll take a look at the code, but I think it might be worth 
while to ditch the hybrid solution that boot1a.S presents and keep the 
floppy and HD prefixs seperate.

-- 
----------------------------IMPORTANT NOTICE----------------------------

This message, and its attachments if any, is intended only for the use of
the individual or entity to which it is addressed, and contains information
that is Valuable, Proprietary and Confidential to SOMA Networks, Inc. If the
reader of this message is not the intended recipient, or an employee or agent
authorized and responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify SOMA Networks, Inc.
by email at le...@so... and delete all copies of the message.

Re: RE: [Etherboot-developers] No simple loading from IDE...

[Timothy L. <tl...@ro...>]

> What were the issues (so I don't repeat any mistakes)?

I only know my issues.  Ken pulled out boot1a.s so I assume that he had more issues than just mine.  

When I created a boot floppy, a setting in boot1a.S was not getting updated.  Apparently, the code was susposed to create the floppy image calculate the size update boot1a.S and recompile and write to the floppy.

If you can find a way to fix that on my systems, I would be happy enough to go back to boot1a.S.  However, I don't know what other issues existed in that implamentation.  Although I seem to remember that Ken mentioned that it depended on BIOS calls that may not be implemented everwhere.

Tim

RE: [Etherboot-developers] No simple loading from IDE...

[Michael G. <mge...@so...>]

On Fri, 9 May 2003, Timothy Legge wrote:

> > If I were to produce a hard drive boot prefix without the size
> limitations
> > of boot1a.s, would there be any interest in having another target for
> hard
> > drive bootable etherboot images (ie. ethdrv.zhd or something)?
> 
> Boot1a.s was tossed because of multiple problems that were encountered.
> At the time, we knew there would be issues with HDs.

What were the issues (so I don't repeat any mistakes)?

> I would say that if you could find a method of booting from the HD
> without the problems encountered with boot1a.s it would be accepted.

OK.  I'll see what I can do.

-- 
----------------------------IMPORTANT NOTICE----------------------------

This message, and its attachments if any, is intended only for the use of
the individual or entity to which it is addressed, and contains information
that is Valuable, Proprietary and Confidential to SOMA Networks, Inc. If the
reader of this message is not the intended recipient, or an employee or agent
authorized and responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify SOMA Networks, Inc.
by email at le...@so... and delete all copies of the message.

RE: [Etherboot-developers] No simple loading from IDE...

[Timothy L. <tl...@ro...>]

> If I were to produce a hard drive boot prefix without the size
limitations
> of boot1a.s, would there be any interest in having another target for
hard
> drive bootable etherboot images (ie. ethdrv.zhd or something)?

Boot1a.s was tossed because of multiple problems that were encountered.
At the time, we knew there would be issues with HDs.

I would say that if you could find a method of booting from the HD
without the problems encountered with boot1a.s it would be accepted.

Tim

[Etherboot-developers] No simple loading from IDE...

[Michael G. <mge...@so...>]

OK, so we've been using etherboot to boot our CPU cards by placing it on 
small/cheap compact flash cards which show up as IDE devices.  The change 
which removed boot1a.s has therefore introduced a bit of a problem for me.
The lilo option is rather convoluted and a simple "make 1, dd the rest" 
solution isn't an option as the flash cards we use may have an arbitrary 
disk geometry.

If I were to produce a hard drive boot prefix without the size limitations 
of boot1a.s, would there be any interest in having another target for hard 
drive bootable etherboot images (ie. ethdrv.zhd or something)?

RE: [Etherboot-developers] Sundance Driver and LTSP

[Timothy L. <tl...@ro...>]

> I should confirm today that the cvs version will correctly load my
ltsp
> kernel and thats one less thing before 5.1 gets blessed...
> 

I have confirmed that the current cvs sundance driver version works fine
in 5.0 and 5.1 to boot an ltsp kernel.

[Etherboot-developers] Sundance Driver and LTSP

[Timothy L. <tl...@ro...>]

Hi

Last night, I was able to confirm that the Sundance driver works correctly.  I applied the nfs-swap patch to a vanilla kernel 2.4.19 and compiled with the config file that Jim McQuillan used.  I used ltsp_initrd_kit to build my ltsp kernel and the sundance driver downloaded and correctly started ltsp (to the bash shell anyway).

I just have to confirm that there are no differnces between my driver version and the cvs but I am pretty sure there are no differences.  

I am not sure why I am unable to boot the ltsp kernel that Jim sent me a couple of weeks ago, but I will work with Jim in the next couple of weeks to ensure that the next ltsp kernel release works with the sundance card.

I should confirm today that the cvs version will correctly load my ltsp kernel and thats one less thing before 5.1 gets blessed...

Tim

Re: [Etherboot-developers] World domination, anyone?

[Vasil V. <vas...@sy...>]

On Fri, 25 Apr 2003, Ken Yap wrote:

> >The UNDI driver discussion seemed interesting as
> >well, though I need Peter or Vasil to explain how it works -- one more
> >time :)
>
> I like the sound of this one actually.  My impression is that the idea
> is that the driver calls UNDI software interrupts. In Etherboot this
> would require a bunch of stub routines in asm callable from C. I don't
> know what the UNDI entry points are like? Are they low level, like
> read/write a network packet, or high level, like get a file by TFTP?
> Where are the readable specs? Ok, maybe just some specs? :-) What
> revision level of the specs should we be aiming for? Peter or Vasil?

I am actually interested into getting a driver that will use UNDI. Erik has
done quite a lot of the hard work implementing this on the IA64. I am not
quite sure at this stage how much of the specs are common, though. Anyone else
keen on doing this in the near future (month or so)?

I don't know whether I will get round to doing it soon but it looks like a
good idea unless someone is likely to get NIC manifucturers to put etherboot
on their NIC ROMs.

> >But what do you think?  If we went for PXE or UNDI, where are the big
> >wins? I'm always thinking about ways Etherboot could be used by more
> >people, and how we could become even more useful as a component
> >technology.
>
> Supporting UNDI would allow Etherboot to run on NICs to which Etherboot
> has not been ported but UNDI is available in the PXE code.

Great benefit here -- don't care which NIC you are being loaded to and still
can use the flexibility of etherboot. If the UNDI is buggy, then use
etherboot's driver.

> Supporting PXE would be another step and would allow Etherboot to be
> plugged into existing PXE infrastructure.

This will be most useful to NIC manufacturers and could be used to convince
them to use etherboot instead of just PXE. Then open sourcing their driver
will give them better support in the long run.

> Apropos of something else, does anybody know if recent BIOSes support
> booting from USB flash, or is that regarded as too prone to abuse? If
> USB booting is supported, does it work like a floppy disk?

How is this different in terms of abuse from booting off USB floppy, which
some BIOSes now support?

--
Vasil

Re[2]: [Etherboot-developers] CVS COMMIT: Safe booting concept

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

Hello Eric,

Tuesday, May 06, 2003, 1:42:57 PM, you wrote:

> The next question is do we want to look at using IKE
> the internet key exchange defined for IPsec.  This would
> allow us to switch keys with which we verify the image.

> Currently since we don't have a private location to store
> a key we cannot participate in a protocol that requires
> us to have a well known private/public key pair.

I think that's not to difficult: Generate ourselves a private key
(random data required, and computing time** of course), send the
public key to the server (encrypted with its public key) and now we
have a complete double pub/sec keypair. Problem would be: How to
authenticate client (from server's view)? Anyone could pretend to be
"client" - even forging MAC should not be to difficult.

> For other things it could be interesting.

ACK

**: It seems as if download is about 2secs slower on 1MB (for md5) on
my emulated 1GHz AMD, and additional 2 secs are taken to decrypt the
signature. Perfomance could probably be increased, but I have more to
do (get some money, and so, right now), so someone else might have a
look. However, the concept is proven to work, and my name is in the
code :-)

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>