etherboot-developers — Discussion of developer issues

[Etherboot-developers] COMMIT: New device model...

[Eric W B. <ebi...@ln...>]

O.k. My changes to remove the device list from config.c and
to not have the probe routines be NIC specific are committed.
At the same time I have merged the reset and disable functions.

I have updated skel.c with what I hope are good examples of the
new interface.

For about half the nics that do setup code in their reset routines,
this reset and disable merge means the disable routines can now be
stream lined, some more.  (see skel.c and main.c for what is expected
of the disable routine).

Eric

Re: [Etherboot-developers] All pci drivers in 1 rom image.

[Eric W B. <ebi...@ln...>]

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

> On 15 Aug 2002, Eric W Biederman wrote:
> > O.k. playing with drivers I have just built an etherboot romimage, with
> > all of the pci drivers compiled in.  As you can see below the text
> > comes to 81K for a total image size of 188K.  The compressed romimage
> > probably comes to 40K but lzhuf is haning on such a large file so I don't
> > have good numbers.  This does mean there are a few nics with ROMs that
> > could have an everything, test.
> 
> Excellent - I can provide clients with a "will boot anything" disk so they
> can check to see if Etherboot supports their NICs.  Now, if only the PCI
> spec could change so that the same ROM image can work when placed in any
> NIC...

Right that should be possible.  At least for pci nics.  We could probably
do this with pnpisa nics as well, (because the probe routines are
reliable enough).  But I don't have the cards, or the slots to test
the code.  My current test machine only has 64bit PCI-X 133Mhz slots,
It can do 32bit 33Mhz PCI in there.
 
> > With a few more tweaks it finally looks like I have a good base for adding
> > all kinds of drivers.  I have moved all of table entries from config.c
> > into the drivers themselves, and added CONFIG_ISA and CONFIG_PCI
> > options, to specify what kind of drivers can be supported.
> > Using the filename to specify which drivers to compile is beginning to
> > look like a problem.  In particular we are half way to ext2 filename
> > size limit already.  So I will probably add a target for all pci
> > drivers, to avoid this problem.
> > size
> bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp
> 
> >    text	   data	    bss	    dec	    hex	filename
> > 83156 2856 106076 192088 2ee58
> bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp
> 
> 
> I assume you'll be keeping the current scheme as well - the most usual
> number of drivers in a ROM will probably be 1, 2 or all of them.

Right.  I still haven't written the all of them case.  But I have
extended the current scheme to be fully recursive as above, so you
can include all of the drivers you want.

Eric

Re: [Etherboot-developers] SMC 1211 vendor id correction

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

>Some versions of the smc1211tx card use 0x1112 and others use 0x1113.
>And, they didn't change the version number on the card !

Ok, put both entries in. I hate these manafacturer shenanigans.

Re: [Etherboot-developers] SMC 1211 vendor id correction

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

>The Vendor ID for the SMC 1211 card is incorrect in the NIC file,
>which keeps etherboot from working with this card.  The value in the
>NIC file is 0x1112, but it should be 0x1113.  The value in pci.h is
>correct.

Thanks, fixed. Hmm, wonder how the ROM worked on my SMC1211 though.

Re: [Etherboot-developers] SMC 1211 vendor id correction

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

Preston,

Some versions of the smc1211tx card use 0x1112 and others use 0x1113.
And, they didn't change the version number on the card !

Jim McQuillan
ja...@Lt...



On Fri, 16 Aug 2002, Preston Wilson wrote:

> The Vendor ID for the SMC 1211 card is incorrect in the NIC file,
> which keeps etherboot from working with this card.  The value in the
> NIC file is 0x1112, but it should be 0x1113.  The value in pci.h is
> correct.
> 
> I did a quick search via google to see if the card might have used the
> vendor ID 0x1112 in the past, but that does not look it is the case
> here.
> 
> After changing the vendor ID, my SMC 1211 worked like it should with
> etherboot.
> 
> -Preston
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

-- 

Re: [Etherboot-developers] All pci drivers in 1 rom image.

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

On 15 Aug 2002, Eric W Biederman wrote:
> O.k. playing with drivers I have just built an etherboot romimage, with
> all of the pci drivers compiled in.  As you can see below the text
> comes to 81K for a total image size of 188K.  The compressed romimage
> probably comes to 40K but lzhuf is haning on such a large file so I don't
> have good numbers.  This does mean there are a few nics with ROMs that
> could have an everything, test.

Excellent - I can provide clients with a "will boot anything" disk so they
can check to see if Etherboot supports their NICs.  Now, if only the PCI
spec could change so that the same ROM image can work when placed in any
NIC...

> With a few more tweaks it finally looks like I have a good base for adding
> all kinds of drivers.  I have moved all of table entries from config.c
> into the drivers themselves, and added CONFIG_ISA and CONFIG_PCI
> options, to specify what kind of drivers can be supported.
> Using the filename to specify which drivers to compile is beginning to
> look like a problem.  In particular we are half way to ext2 filename
> size limit already.  So I will probably add a target for all pci
> drivers, to avoid this problem.
> size bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp
>    text	   data	    bss	    dec	    hex	filename
>   83156	   2856	 106076	 192088	  2ee58	bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp

I assume you'll be keeping the current scheme as well - the most usual
number of drivers in a ROM will probably be 1, 2 or all of them.

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

[Etherboot-developers] SMC 1211 vendor id correction

[Preston W. <pw...@ra...>]

The Vendor ID for the SMC 1211 card is incorrect in the NIC file,
which keeps etherboot from working with this card.  The value in the
NIC file is 0x1112, but it should be 0x1113.  The value in pci.h is
correct.

I did a quick search via google to see if the card might have used the
vendor ID 0x1112 in the past, but that does not look it is the case
here.

After changing the vendor ID, my SMC 1211 worked like it should with
etherboot.

-Preston

Re: [Etherboot-developers] [Patch] vt6103 PHYceiver for SIS900

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

>	This patch supports linuxbios + etherboot on=20
>http://www.pcchips.com.tw/M810Lv71c.html.  Comments are welcome.
>
>-Andrew

Thanks very much. I've included it into the 5.1.2 and 5.0.8 trees and
also put it into the patch area at the web site.

[Etherboot-developers] [Patch] vt6103 PHYceiver for SIS900

[Andrew Ip <ai...@cw...>]

Hi,

	This patch supports linuxbios + etherboot on 
http://www.pcchips.com.tw/M810Lv71c.html.  Comments are welcome.

-Andrew

-- 
Andrew Ip
Email:  ai...@cw...
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road, Lai Chi Kok,
Kowloon, Hong Kong(SAR),
China.
Tel: (852)2542 2046
Fax: (852)2542 2036

For public pgp key, please obtain it from http://www.keyserver.net/en.

Re: [Etherboot-developers] Etherboot works again!

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

>One other detail that deserves considertation is the etherboot directory
>structure.  Currently for source files it is totally flat.
>
>As support for multiple architectures, multiple types of firmware,
>and multiple kinds of drivers are added it looks increasingly like
>we should have some subdirectories.  Ollie Lho pointed this out
>a while ago, and it has finally sunk into my brain.

Yes, that makes sense. Etherboot is growing up and is pushing out in all
directions. Propose something. We'll probably need multiple target
directories too.

Re: [Etherboot-developers] new CVS branch etherboot-doc-5.2 created

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

>> Eric, let me know when you think a 5.1 RC tarball can be created for
>> testers.
>
>If you don't mind creating another tarball in about a week, do it now.

Ok, testers can find it at

http://www.etherboot.org/etherboot-5.1.2rc2.tar.bz2

There was a missing #endif in memsizes.c which I've fixed and checked
in.

>My primary target is a clean model that allows booting off of multiple
>kinds of devices.  I think I have one, but it requires quite a bit of
>manual shifting of code around.  Clean implies less code duplication,
>better maintenance and a smaller final result.

Great. Looking forward to it. EB'll really rock by 5.2.

Re: [Etherboot-developers] new CVS branch etherboot-doc-5.2 created

[Eric W B. <ebi...@ln...>]

ke...@us... writes:

> Eric, let me know when you think a 5.1 RC tarball can be created for
> testers.

If you don't mind creating another tarball in about a week, do it now.
I have a huge pile of changes going in to clean up config.c and make
the probe functions not nic device specific, and kill nic_reset.  I
have recently tested the code in the repository and it should be in a
functional state. 

The goal is to haven an easily access intermediate version between all
of my changes. 

My primary target is a clean model that allows booting off of multiple
kinds of devices.  I think I have one, but it requires quite a bit of
manual shifting of code around.  Clean implies less code duplication,
better maintenance and a smaller final result.

Unless I hear otherwise I will check in my next pile of changes in
another 12, or 13 hours.  And then I will start work on getting
the boot from disk code integrated in cleanly, including the ability
to boot from the disk first.  So this may be the quite before the
storm.  With a little luck the storm should be over by this time next
week, and the major work will be stabalizing 5.1.x for 5.2.

Eric

[Etherboot-developers] new CVS branch etherboot-doc-5.2 created

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

Eric, let me know when you think a 5.1 RC tarball can be created for
testers.

[Etherboot-developers] All pci drivers in 1 rom image.

[Eric W B. <ebi...@ln...>]

O.k. playing with drivers I have just built an etherboot romimage, with
all of the pci drivers compiled in.  As you can see below the text
comes to 81K for a total image size of 188K.  The compressed romimage
probably comes to 40K but lzhuf is haning on such a large file so I don't
have good numbers.  This does mean there are a few nics with ROMs that
could have an everything, test.

With a few more tweaks it finally looks like I have a good base for adding
all kinds of drivers.  I have moved all of table entries from config.c
into the drivers themselves, and added CONFIG_ISA and CONFIG_PCI
options, to specify what kind of drivers can be supported.

Using the filename to specify which drivers to compile is beginning to
look like a problem.  In particular we are half way to ext2 filename
size limit already.  So I will probably add a target for all pci
drivers, to avoid this problem.

size bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp

   text	   data	    bss	    dec	    hex	filename
  83156	   2856	 106076	 192088	  2ee58	bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp

Eric

[Etherboot-developers] mknbi-1.2-9 (production) released

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

I have released mknbi-1.2-9 at
http://www.etherboot.org/distribution.html

The main change in this version from -8 is an external menu program
contributed by Robb Main that displays a light bar and uses cursor keys
to select entries. See mkelf-nfl and mknbi-elf in the man page for more
details.

Alternate implementations or enhancements to menu programs are highly
encouraged.

[Etherboot-developers] LinuxWorld Expo rolls on

[Marty C. <ma...@et...>]

The second day of LinuxWorld Expo was even better than the first.  We did
several ROM burning demos, including burning a ROM for an rtl8139 card
containing code for a wireless card, which allowed us to demo wireless
booting using a ROM.

The internet deities were merciful and we had uninterrupted access to our
servers for demoing rom-o-matic.net.  We even downloaded some ROM images
and burned them live.

I took a walk around the show floor, and enjoyed visiting some of the
smaller vendors at the show.  Microsoft even has a modest booth, showing
off Services for Unix. Interesting group of folks. They didn't seem to
have much of an idea of how bizarre they were at a Linux show. Which come
to think about it is probably how they chose folks to attend :)

There are at least a dozen wireless networks on the show floor, and
people are just walking around with laptops and PDAs surfing away.

The show is smaller, but in some ways it's a nice size.  People are
starting to recognize us and ask about the new equipment and features. It
give a sense of community.  I'm interested in checking out a few places,
and will be staying in the area for a bit to actually see some of the city.

Tomorrow is the last day of the show, and we look forward to more demos,
more conversation, and enjoying the pleasure of hanging with people who
actually understand the words that are coming out of our mouths :)

Don't forget to check out the webcam at http://www.thinguin.org/

Marty

-- 
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; 
         Cambridge, MA 02139; USA
  Voice: (617) 491-6935; Fax: (617) 491-7046 
  Email: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] Etherboot works again!

[Eric W B. <ebi...@ln...>]

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

> >And I should probably add updating the documentation as well.  But
> >there isn't a 5.1.x documentation branch yet...
> 
> I'll open up a 5.2 documentation branch sometime. It can be stated in
> the doco that it is preliminary.

Sounds good.

One other detail that deserves considertation is the etherboot directory
structure.  Currently for source files it is totally flat.

As support for multiple architectures, multiple types of firmware,
and multiple kinds of drivers are added it looks increasingly like
we should have some subdirectories.  Ollie Lho pointed this out
a while ago, and it has finally sunk into my brain.

Eric

Re: [Etherboot-developers] Etherboot works again!

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

>And I should probably add updating the documentation as well.  But
>there isn't a 5.1.x documentation branch yet...

I'll open up a 5.2 documentation branch sometime. It can be stated in
the doco that it is preliminary.

Re: [Etherboot-developers] Etherboot works again!

[Eric W B. <ebi...@ln...>]

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

> >My 5.1.x todo list looks like:
> >- Finish boot from disk support.
> >- Get a multicast test server.
> >- Generate the list of NIC from a special section in the etherboot
> >  image so config.c only needs to be compiled once.
> >- Remove the redundancy of having both eth_reset && eth_disable.
> >- And finally update the drivers after the core has settled down.
> 
> Fantastic. At this rate well have to name the release EricBiederman 6.0,
> er, I mean Etherboot 6.0. :-)

Well at least you can understand why I complained about the
list bouncing my small patches :)

Oh, and now that etherboot should work for everyone I'll take
all the testers I can get.  I'm certain I have missed something.

And I should probably add updating the documentation as well.  But
there isn't a 5.1.x documentation branch yet...

Eric

Re: [Etherboot-developers] Etherboot works again!

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

>My 5.1.x todo list looks like:
>- Finish boot from disk support.
>- Get a multicast test server.
>- Generate the list of NIC from a special section in the etherboot
>  image so config.c only needs to be compiled once.
>- Remove the redundancy of having both eth_reset && eth_disable.
>- And finally update the drivers after the core has settled down.

Fantastic. At this rate well have to name the release EricBiederman 6.0,
er, I mean Etherboot 6.0. :-)

[Etherboot-developers] Etherboot works again!

[Eric W B. <ebi...@ln...>]

After a torturous debugging cycle, I have etherboot working again 
under the pcbios.  The build is much more modular, and genrules.pl
in particular is now much simpler.  Both etherboot ELF images, and PXE
images are standard prefixes now so they do not need special cases
in genrules.pl.  loader.S is now a readable file of 230 lines!


IMPORTANT
- Do not use compressed images
- Do not use relocation

UNTIL
- The driver you want to use has had been fixed.

Except for ROM chips there are essentially no etherboot size
limitations, and the code is now mostly PIC throughout.  It will only
run at RELOCADDR iff the code is not compressed, and you do not use
relocation.

I have moved the decompressor to 32bit code made it PIC and called
it unhuf.S.  This has increased it's size by about 200 bytes.  Plus
the code to switch to protected mode is another extra 100 bytes.  So
there is some significant size growth in the uncompressed code.  The
long term removal of size restrictions make this a path worth going
down.  

There is a very good decompressor fix.  Grab the decompressor out of
upx.  The decompressor is roughly 200 bytes, and the it compresses
etherboot better than lzhuf does as well.  So once I get the code
untangled upx code adapted we will get a small overhead reduction in
the 5.1.x tree over the 5.0 tree.


My 5.1.x todo list looks like:
- Finish boot from disk support.
- Get a multicast test server.
- Generate the list of NIC from a special section in the etherboot
  image so config.c only needs to be compiled once.
- Remove the redundancy of having both eth_reset && eth_disable.
- And finally update the drivers after the core has settled down.

Have fun at Linux World.

Eric

[Etherboot-developers] more fun from LinuxWorld Expo

[Marty C. <ma...@et...>]

Sorry not to write again sooner...  The first show day was pretty good.  
Tomorrow will be even better.

We had a little bit of network difficulty, owing to a power failure in
Cambridge, so rom-o-matic.net went offline for several hours.  There was
also a rogue DHCP server on the linuxworld expo lan that baffled me for a
while.  I got static IPs for the router to get around that one.

So, check out:

    http://www.thinguin.org/ 

for the beginnings of a show report with webcam ;)

Right now it's pointing out the hotel window, but tomorrow we will return
to the show and set it up there, and hopefully my T1 at the office will
stay up! although I guess a power failure is a good excuse... :)

Markus got the DWL-520 to work with Etherboot. So we are demoing wireless
Etherboot.  It's pretty nice, and people are fascinated by it.  Overall,
the show is quite interesting.  We found a vendor using Etherboot in an
embedded application.  Lots of people came by to visit us that had been
at eariler shows also.

Enjoy the web site.  I'll add more soon.

Marty

 

-- 
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; 
         Cambridge, MA 02139; USA
  Voice: (617) 491-6935; Fax: (617) 491-7046 
  Email: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] Etherboot over wireless

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

On Tue, 13 Aug 2002, Jean-Michel POURE wrote:
> I would like to kwnow in what extent it it is possible to etherboot over a
> wireless card. The boot shall support Orinoco and Prism2 wireless drivers.

At the moment only Prism2 drivers exist in Etherboot.

> Can the boot code be stored in the network card and used for wireless booting.
> Or shall I use a small flash card? I am completely new to etherboot and need
> some help.

I don't know of any wireless network cards that have BootRom sockets.
Using a flash card is one option.  Another, probably cheaper, option is to
buy a cheap wired network card with a BootRom socket and to use a BootRom
containing drivers for both the wired and wireless cards.  We have used
this solution successfully on a moderate scale (120 workstations).

I don't think that the rom-o-matic interface allows you to build
multiple-driver Rom images (although I may be wrong), but it's very easy
to do if you download the Etherboot source code.  For example, if you have
a D-Link DFE-538 (wired) card with BootRom socket and a Prism2.5 PCI
wireless card, then you can build the ROM image with

  make bin32/dfe538--prism2_pci.lzrom

Adjust "dfe538" and "prism2_pci" to fit your particular cards.

Hope that helps,

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] Etherboot over wireless

[Jean-Michel P. <jm....@fr...>]

Dear all,

I would like to kwnow in what extent it it is possible to etherboot over =
a=20
wireless card. The boot shall support Orinoco and Prism2 wireless drivers=
=2E

Can the boot code be stored in the network card and used for wireless boo=
ting.=20
Or shall I use a small flash card? I am completely new to etherboot and n=
eed=20
some help.

Best regards,
Jean-Michel POURE

Re: [Etherboot-developers] Getting the non LinuxBIOS case to work again...

[Eric W B. <ebi...@ln...>]

More headway today.  I have made a start16.S which contains the
trampoline into 16bit mode.  And loader.S just contains the code
specific to loading from a pcbios rom chip. 

An interesting part of all of the refactoring is that now I have
elf images working for the pcbios etherboot case as well.   Yah,
mode code isn't LinuxBIOS specific anymore...

The 64k etherboot limit is gone.

The big todo items left are:
- test non elf etherboot images, in pcbios mode.
- clean up allocation of the real mode stack.  I initially
  set it to 64k, and then move it to just below meminfo.basememsize 
  (the top of available real mode memory) after get_memsizes() is
  called.
- make the pcbios exit function work again.

Hopefully in the next couple days I can get this checked in and
people not running LinuxBIOS can try this.  

What do you think, etherboot recursively booting etherboot at
LinuxWorld?

Eric