etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[<ke...@et...>]

>I tried the lance driver in 5.2.1 obviously with RELOCATE defined it
>produces an error.  Ken, I thought you removed lance from the build
>rules.  Was that after 5.2.1?

I think it is changed in 5.2.2.

>Also, with 5.2.2 release is their any thought of skipping 5.2.1...

Probably should, I hope to release 5.2.2 within a week.

RE: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

>     http://www.rom-o-matic.net/5.2.1/
> 
> They seem to work, but I'd really appreciate it if folks would run a
> few tests before we make them public, and let me know.
> 

I tried the lance driver in 5.2.1 obviously with RELOCATE defined it
produces an error.  Ken, I thought you removed lance from the build
rules.  Was that after 5.2.1?

Also, with 5.2.2 release is their any thought of skipping 5.2.1...

Tim

RE: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

> You can get to them directly with:
> 
>     http://www.rom-o-matic.net/5.3.2/

I gave 5.3.2 a quick go generating floppys with multicast enabled.  I
will test them, but the only thing I noticed is that the title bar of
the window displays:

ROM-o-matic configuration for Etherboot version 5.3.2 (i386) <br>
for <red>pcnetfastiii.zdsk</red> 

That is, it has the html tags in the title.  No big deal just cosmetics.
Are their any specific areas you would like tested?

Tim

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

On Thursday, September 25, 2003, at 01:26  AM, Ken Yap wrote:
>> I have released Etherboot 5.3.2 at http://www.etherboot.org
> BTW, I intend 5.2.2 to have all the changes in 5.3.2 so please give
> 5.3.2 a good workout so that we will have a nice stable 5.2.2.
> Marty, any chance of getting 5.3.2 on rom-o-matic?

OK, I've put 5.2.1 and 5.3.2 up on rom-o-matic.net, but haven't linked 
them to the home page yet because I haven't had a chance to test them 
yet, and I made some changes in the way the rom-o-matic PHP code is 
integrated with the etherboot distribution so it is easier to make new 
releases.

You can get to them directly with:

    http://www.rom-o-matic.net/5.3.2/

or

    http://www.rom-o-matic.net/5.2.1/

They seem to work, but I'd really appreciate it if folks would run a 
few tests before we make them public, and let me know.

Thanks,

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: md...@et...
     Web: http://www.etherboot.org/

[Etherboot-developers] ns8390 has Multicast Support

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

Hi

I added multicast support to the ns8390 driver.  I tested it on a
dfe-520 (ne) and a generic RealTec 8029 based pci card.  

It seems that my asante NIC goes deaf trying to run dhcp client after
loading and booting an ltsp kernel.  However, since it acts that way
without multicast support, I don't seem to have introduced any new
issues (or fixed any for that matter).

The change is in the 5.2 and 5.3 cvs

Tim

RE: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

> Not a too serious problem, at the moment I'll put it as the LAST
driver
> in the auto-probing image, just please write " (Press ESC to skip)"
> after "Probing/configuring ...".
> 
> And the second time the card is probed, the text "0 3c515 cards found"
> is not needed...can it be suppressed?

The first probing is to ISAPNP, if ISAPNP was more fully implemented, it
would enable all pnp devices.  However, in this case it stops when a
3c515 card is found.  I believe I can exit the probe function if ISAPNP
does not find the card because PNP is required.

Tim

RE: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

> After sending that I thought better of what I wrote, so unprompted I'm
> say: Let it not be misunderstood that Timothy's work is not
appreciated.
> My apologies to Timothy if it looked that way.

Mo misunderstanding here, I do know that a Brent Norris was using some
3c515's but I like to look on the 3c515 as the nasty beast that started
me on the road to writing Etherboot drivers (I may need therapy for
that).  None of the drivers I have written are in high demand (with the
possible exception of the pcnet32 for vmware users).

> I was just making light of what few people know---generally those who
> have read the Linux Ethernet HOWTO---the 3c515 is rare bird and quite
a
> curiosity (being one of a couple ISA NICs that were designed for 100
> Mb/s (but not actually achievable in practice with the ISA bus). I've

Something I didn't know till after I finished the driver :-(

> never seen one, but if you see one at a swap meet going for pennies,
> grab it and hang it on your wall and you can have a oddity to intrigue
> your geek visitors. :-)

They are a great little card if you have a rare 486 with only isa ports
and they are quite cheap now but although they can talk to a 100mbs
network, they are not 100Mbs (a lot like the Pegasus based USB NIC)...

> just fine, unfortunately I was not able to figure out how to activate
> the controller in short time so I had stop there.  The surplus
machines

It shouldn't be that hard, I think the code only enables the card if a
3c515 is found, so that might have been the issue.

> other ISA NICs like the DLink DE220 are also ISAPNP and it would be
nice
> (but low priority) if the PnP didn't have to be turned off to use
them.

I happen to have a couple of those (yes Eric some people still have ISA
cards ;-)) but I am giving some consideration to porting USB or PCMCIA
support to Etherboot.  I think I have settled on USB at the moment
because of the availability of documentation.  However, it is probably
less useful than PCMCIA support.  

Tim

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[Paolo S. <al...@io...>]

Ken Yap ha scritto:
> 
> >Not a too serious problem, at the moment I'll put it as the LAST driver
> >in the auto-probing image, just please write " (Press ESC to skip)"
> >after "Probing/configuring ...".
> 
> It will timeout eventually.
> 
> Or just leave that driver out. Timothy has probably got one of the two
> last 515s in the world, the other being in the 3com museum. :-)

Ok, I'll probably leave it out!

Btw, some ideas about the 3c90x.o vs 3c595.o problem?
(the 3c90x.o needs to be linked before 3c595.o,
otherwise 3c905b cards will be (badly) handled by the 3c595 driver as a
3c900b cards, because they have same IDs....)

bye!

Paolo

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

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

On Thursday, September 25, 2003, at 01:26  AM, Ken Yap wrote:
>> I have released Etherboot 5.3.2 at http://www.etherboot.org
> Marty, any chance of getting 5.3.2 on rom-o-matic?

Yes, I should get to it shortly.  Apologies for the latency.
My clients just keep wanting things, but I think I'll have some time in 
the next few days ;)

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: md...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[<ke...@et...>]

>Or just leave that driver out. Timothy has probably got one of the two
>last 515s in the world, the other being in the 3com museum. :-)

After sending that I thought better of what I wrote, so unprompted I'm
say: Let it not be misunderstood that Timothy's work is not appreciated.
My apologies to Timothy if it looked that way.

I was just making light of what few people know---generally those who
have read the Linux Ethernet HOWTO---the 3c515 is rare bird and quite a
curiosity (being one of a couple ISA NICs that were designed for 100
Mb/s (but not actually achievable in practice with the ISA bus). I've
never seen one, but if you see one at a swap meet going for pennies,
grab it and hang it on your wall and you can have a oddity to intrigue
your geek visitors. :-)

Timothy's ISAPNP code is quite useful for other purposes. There are
other NICs with ISAPNP.  I used the code to detect an onboard PnP CS8920
just fine, unfortunately I was not able to figure out how to activate
the controller in short time so I had stop there.  The surplus machines
in question had EEPRO100s too, so it was not worth my while to pursue
the matter.  But if someone is hungry for a spare time project, some
other ISA NICs like the DLink DE220 are also ISAPNP and it would be nice
(but low priority) if the PnP didn't have to be turned off to use them.

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[<ke...@et...>]

>Not a too serious problem, at the moment I'll put it as the LAST driver
>in the auto-probing image, just please write " (Press ESC to skip)"
>after "Probing/configuring ...".

It will timeout eventually.

Or just leave that driver out. Timothy has probably got one of the two
last 515s in the world, the other being in the 3com museum. :-)

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[Paolo S. <al...@io...>]

Just tested the multiboot image with 5.3.2, now works really better!

The only problem (as  Timothy already said...) is the 3c515 driver....
it says "Probing/configuring ISAPNP devices"...and stay there for a lot
of time.

Not a too serious problem, at the moment I'll put it as the LAST driver
in the auto-probing image, just please write " (Press ESC to skip)"
after "Probing/configuring ...".

And the second time the card is probed, the text "0 3c515 cards found"
is not needed...can it be suppressed?

bye!

Paolo


Ken Yap ha scritto:
> 
> >I have released Etherboot 5.3.2 at http://www.etherboot.org
> 
> BTW, I intend 5.2.2 to have all the changes in 5.3.2 so please give
> 5.3.2 a good workout so that we will have a nice stable 5.2.2.
> 
> Marty, any chance of getting 5.3.2 on rom-o-matic?
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Etherboot 5.3.2 (development) released

[<ke...@et...>]

>I have released Etherboot 5.3.2 at http://www.etherboot.org

BTW, I intend 5.2.2 to have all the changes in 5.3.2 so please give
5.3.2 a good workout so that we will have a nice stable 5.2.2.

Marty, any chance of getting 5.3.2 on rom-o-matic?

Re: [Etherboot-developers] Universal auto-probing driver

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

Paolo Salvan <al...@io...> writes:

> Hi Eric!
> 
> Ok for etherboot.o and for etherboot-pci.o, my simply question is:
> perhaps it is worth doing a third image, with all NIC drivers, optimized
> for the building of an all-NIC-driver auto-probing image...
> It should include ISA-card also, because (at least in Thinclients
> world...and this is where I come from) there are a lot of ISA
> ne2000-compatible card going around...
> 
> A "make bin/driver--driver--driver.ext" surely works pretty well, but it
> is not so immediate as a "make bin/etherboot-XXX"...
> 
> Ok... all these lines to say that I think such an image would be useful
> not only for me (I posted an email in the thinstation-general ML about
> the auto-probing disk, and there were people interested...), perhaps it
> is worth considering it...

Sounds reasonable.  

What I would suggest is that you prototype a thin client probing driver
using the existing mechanism.  And once it works post the make line
and the developers can tweak the makefile for that case.

What is worth noting for this case is that etherboot actually prints
the driver it uses so if someone wants to create a specific etherboot
driver they already know the make target they need.

Eric

[Etherboot-developers] Etherboot 5.3.2 (development) released

[<ke...@et...>]

I have released Etherboot 5.3.2 at http://www.etherboot.org

Changes from 5.3.1:

+ G=FCnter Knauf sent in a new version of romid that handles the new
and old IDENT format.

+ Cai Qiang fixed the WINCE loader. It needs to handle > 512 byte pac=
kets
and also the buffer has to be static. Also submitted a driver for VGA
which can be activated by CONSOLE_DIRECT_VGA.

+ Improved tg3 driver by Eric Biederman. New define in etherboot.h:
VALID_LINK_TIMEOUT.

+ Timothy Legge and I fixed up various ISA drivers to be less noisy
when probing, from information provided by Paolo Salvan, so that the
super etherboot image is more useful.

+ Proof of concept of a TFTP to HTTP proxy in contrib/t2hproxy/.

MD5 sum:

eb7b7aa91d8070df5f89146947072079  etherboot-5.3.2.tar.bz2

Re: [Etherboot-developers] Etherboot.zdsk suggestions...

[<ke...@et...>]

>Also, since a number of drivers and files use their own version of a
>delay using currticks is there some merit in creating cdelay() with the
>rest of the delay functions and update the drivers accordingly?

You would have to write it to take into account the typical usage:

	later = currticks() + timeout;
	while (some hardware condition && currticks() < later)
		;

That hardware condition differs from driver to driver. That is to say,
currticks() is not being used to create a sleep but rather a timeout.

I'll release 5.3.2 with the updated drivers within a day or two.

RE: [Etherboot-developers] Etherboot.zdsk suggestions...

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

> > Ok thanks very much for your work. We'll fix these 4 drivers and
leave
> > it at that. Timothy, can you do the 3c515?
> 
> I will take a look...

I have updated the 3c515.c driver and isapnp.c to use currticks where
required.  It seems to work fine but takes approximately 250 ticks to
enable/configure the ISAPNP but no linger fills the screen with dots.

I can take another look at it some time to see if I can reduce the time
required.  However, it would probably be better to look at a Config
option for isapnp.  I believe that most Pentium class machines enable
ISAPNP devices automatically so it should only be required when someone
is trying to use the 3c515 on a 486 class client.

Also, since a number of drivers and files use their own version of a
delay using currticks is there some merit in creating cdelay() with the
rest of the delay functions and update the drivers accordingly?

Tim

Re: [Etherboot-developers] Universal auto-probing driver

[Paolo S. <al...@io...>]

Hi Eric!

Ok for etherboot.o and for etherboot-pci.o, my simply question is:
perhaps it is worth doing a third image, with all NIC drivers, optimized
for the building of an all-NIC-driver auto-probing image...
It should include ISA-card also, because (at least in Thinclients
world...and this is where I come from) there are a lot of ISA
ne2000-compatible card going around...

A "make bin/driver--driver--driver.ext" surely works pretty well, but it
is not so immediate as a "make bin/etherboot-XXX"...

Ok... all these lines to say that I think such an image would be useful
not only for me (I posted an email in the thinstation-general ML about
the auto-probing disk, and there were people interested...), perhaps it
is worth considering it...

Bye!   ;o)

Paolo


"Eric W. Biederman" ha scritto:
> 
> Paolo Salvan <al...@io...> writes:
> 
> > Hi!
> >
> > ....This is an answer to a mail from Febrary, but I think there is
> > something to comment, now that the etherboot.zdsk is going to be quite
> > usable (BTW, I've seen that in CVS there are all the fix I asked two day
> > ago reguarding "noisy" drivers! Congratulation for the efficiency!):
> >
> > "Eric W. Biederman" ha scritto:
> > [etherboot.o]
> > > In addition I have now added a rule for etherboot-pci.o which
> > > is just the pci drivers.  It does not add a lot but it does mean
> > > you don't get caught in the 3c509 drivers 4000 attempts to probe the
> > > card, nor any other bad pci probe.
> >
> > Perhaps at the moment the distinction etherboot.o vs etherboot-pci.o is
> > not really useful; as seen here:
> >
> > > etherboot.zimg     is  84581 bytes
> > > etherboot-pci.zimg is  75420 bytes
> >
> > ...super-driver sizes are similar, the 3c509 driver now do only 100
> > probing, without filling the screen of output, idem for other drivers...
> >
> > In my opinion, priority now is to give a GOOD list of driver, and in a
> > GOOD order, to the linker; current etherboot.o image have the following
> > problems:
> 
> etherboot-pci is a good list of drivers.  When you get into ISA devices
> you have heuristics, some of which work better than others.  There is no
> perfect order.  etherboot-pci should never have problems on hardware it
> was not built for.  etherboot all should have problems.
> 
> I disagree.  Of the selected images. etherboot.zimg should include all
> of the drivers regardless of their usefulness, so we can easily test to
> see if there are compile conflicts.
> > - some drivers are included two times
> > - some unusefull drivers are included (disk/*.c)
> > - a wrong driver is included (lance.c), preventing the image to compile
> > - there is no precise order in which drivers are linked
> >
> > WRT the last point, these are the troubles I had:
> > - the 3c90x.o driver should be linked BEFORE the 3c595.o, otherwise
> > 3c905b cards will be (badly) handled by the 3c595 driver as a 3c900b
> > cards (they have same IDs... :o( ...is there some other way to
> > distinguish these two NICs?)
> > - ISA cards with noisy/long/unsafe probing should be probed after ISA
> > cards with better probing
> >
> > At the moment, my solution is adding these line to the Makefile.main:
> >
> > ---
> > # Rule for the NIC-autoprobing image. (by Paolo Salvan)
> > NETOBJS:=
> > # Note: the 3c90x.o driver should be linked BEFORE the 3c595.o
> > # otherwise 3c905b cards will be (badly) handled by the 3c595 driver as
> > a 3c900b cards
> > NETOBJS+=             $(BIN)/3c90x.o $(BIN)/3c595.o $(BIN)/cs89x0.o
> > $(BIN)/davicom.o $(BIN)/depca.o $(BIN)/e1000.o $(BIN)/eepro.o
> > $(BIN)/eepro100.o $(BIN)/epic100.o $(BIN)/fa311.o $(BIN)/natsemi.o
> > $(BIN)/ns8390.o $(BIN)/pcnet32.o $(BIN)/prism2_pci.o $(BIN)/prism2_plx.o
> > $(BIN)/sis900.o $(BIN)/sk_g16.o $(BIN)/sundance.o $(BIN)/tg3.o
> > $(BIN)/tlan.o $(BIN)/tulip.o $(BIN)/via-rhine.o $(BIN)/w89c840.o
> > $(BIN)/3c503.o $(BIN)/ne.o $(BIN)/wd.o $(BIN)/ne.o
> > NETOBJS+=             $(BIN)/rtl8139.o
> > # These drivers show "noise" on the screen, at the moment I'm excluding
> > them...
> > # will be fixed in next eb version
> > #NETOBJS+=            $(BIN)/3c529.o $(BIN)/3c515.o $(BIN)/3c509.o
> > $(BIN)/smc9000.o
> >
> > $(BIN)/etherboot-net.o: $(NETOBJS)
> >       $(LD) -r $(NETOBJS) -o $@
> > ---
> >
> > ...But it is little mantainable... :-(
> >
> > Some idea for petter solutions????
> 
> Are ISA devices really that common?  I am about ready to start replacing
> PCI devices with PCI express versions.
> 
> You can make any image you want by:
> 
> make bin/driver--driver--driver.ext
> 
> And this gets the link order in the order you specify.
> 
> Eric

Re: [Etherboot-developers] Porting stories...

[Yannis M. <gm...@te...>]

Eric W. Biederman wrote:

>Is it possible you don't have a uint64_t? Or for some other reason your
>sector_t has problems?
>
>
>  
>
The problem with the os_download_t type is solved.
I am cleanng the code a little bit (the architecture dependent parts) 
and I will try to setup the Makefile and Config files. Currently I am 
working with a shell script.

After that we have to discuss some issues on how to merge the code. I 
have also some minor modifications in the architecture independent parts 
(the cs89x0 driver and the core/main.c file)

Regards

Yannis

Re: [Etherboot-developers] CONSOLE_DIRECT_VGA: direct video output support

[<ke...@et...>]

>One small nit with this.  The subroutine needs to be called 
>vga_putc or video_putc.  And all but the init and putc routines need
>to be static in that file.

Ok, I made diff wrt the current code for double checking, rather than
wait for a patch which will be cumulative, and contain lots of
irrelevant diffs. I've committed this to CVS.

diff -ur ../../cvsroot/etherboot/etherboot-5.3/src/arch/i386/core/video_subr.c ./arch/i386/core/video_subr.c
--- ../../cvsroot/etherboot/etherboot-5.3/src/arch/i386/core/video_subr.c	2003-09-21 11:12:49.000000000 +1000
+++ ./arch/i386/core/video_subr.c	2003-09-23 11:45:22.000000000 +1000
@@ -10,14 +10,12 @@
 #include <etherboot.h>
 #include <vga.h>
 
-void beep(int ms);
-
 static char *vidmem;		/* The video buffer */
 static int video_line, video_col;
 
 #define VIDBUFFER 0xB8000	
 
-void memsetw(void *s, int c, unsigned int n)
+static void memsetw(void *s, int c, unsigned int n)
 {
 	int i;
 	u16 *ss = (u16 *) s;
@@ -52,7 +50,7 @@
 		vidmem[i] = ' ';
 }
 
-void video_tx_byte(unsigned char byte)
+void vga_putc(unsigned char byte)
 {
 	if (byte == '\n') {
 		video_line++;
@@ -69,7 +67,7 @@
 
 	} else if (byte == '\a') {
 		//beep
-		beep(500);
+		//beep(500);
 
 	} else {
 		vidmem[((video_col + (video_line *COLS)) * 2)] = byte;
@@ -92,13 +90,5 @@
 	write_crtc((video_col + (video_line *COLS)) & 0x0ff, CRTC_CURSOR_LO);
 }
 
-void console_putc(int b)
-{
-	video_tx_byte(b);
-}
-void beep(int ms)	/* not supported yet */
-{
-}
-
 #endif
 
diff -ur ../../cvsroot/etherboot/etherboot-5.3/src/core/misc.c ./core/misc.c
--- ../../cvsroot/etherboot/etherboot-5.3/src/core/misc.c	2003-09-21 11:12:49.000000000 +1000
+++ ./core/misc.c	2003-09-23 11:42:50.000000000 +1000
@@ -303,9 +303,12 @@
 {
 	if (c == '\n')
 		putchar('\r');
-#if	defined(CONSOLE_FIRMWARE) || defined(CONSOLE_DIRECT_VGA)
+#ifdef	CONSOLE_FIRMWARE
 	console_putc(c);
 #endif
+#ifdef	CONSOLE_DIRECT_VGA
+	vga_putc(c);
+#endif
 #ifdef	CONSOLE_SERIAL
 	serial_putc(c);
 #endif

Re: [Etherboot-developers] CONSOLE_DIRECT_VGA: direct video output support

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

"rimy2000" <rim...@ho...> writes:

> Hi,
>   I have reworked it according Ken and Eric's comments.
> 
> I am booting LinuxBIOS and loading linux/WinCE using a serial console. LinuxBIOS
> already supports direct video output, but when system goto etherboot, video
> pause, until system goto kernel. So I think it'll be better to let eb support
> direct video console when booting from linuxbios.
> 
> 
> I copyed video_subr.c and vga.h from linuxbios to arch/i386 and modify
> video_subr.c, main.c,misc.c to support direct video output under
> CONSOLE_DIRECT_VGA.
> 
> 
>     Attachment is the diff file(vs 5.3.1, so include my previous wince_loader
> patch).

One small nit with this.  The subroutine needs to be called 
vga_putc or video_putc.  And all but the init and putc routines need
to be static in that file.

Off the top of my head I can't think of a reason why you would want to mix
and match drivers.  But it is good to write them so we can.

Eric

Re: [Etherboot-developers] Universal auto-probing driver

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

Paolo Salvan <al...@io...> writes:

> Hi!
> 
> ....This is an answer to a mail from Febrary, but I think there is
> something to comment, now that the etherboot.zdsk is going to be quite
> usable (BTW, I've seen that in CVS there are all the fix I asked two day
> ago reguarding "noisy" drivers! Congratulation for the efficiency!):
> 
> "Eric W. Biederman" ha scritto:
> [etherboot.o]
> > In addition I have now added a rule for etherboot-pci.o which
> > is just the pci drivers.  It does not add a lot but it does mean
> > you don't get caught in the 3c509 drivers 4000 attempts to probe the
> > card, nor any other bad pci probe.
> 
> Perhaps at the moment the distinction etherboot.o vs etherboot-pci.o is
> not really useful; as seen here:
> 
> > etherboot.zimg     is  84581 bytes
> > etherboot-pci.zimg is  75420 bytes
> 
> ...super-driver sizes are similar, the 3c509 driver now do only 100
> probing, without filling the screen of output, idem for other drivers...
> 
> In my opinion, priority now is to give a GOOD list of driver, and in a
> GOOD order, to the linker; current etherboot.o image have the following
> problems:

etherboot-pci is a good list of drivers.  When you get into ISA devices
you have heuristics, some of which work better than others.  There is no
perfect order.  etherboot-pci should never have problems on hardware it
was not built for.  etherboot all should have problems.

I disagree.  Of the selected images. etherboot.zimg should include all
of the drivers regardless of their usefulness, so we can easily test to
see if there are compile conflicts.

> - some drivers are included two times
> - some unusefull drivers are included (disk/*.c)
> - a wrong driver is included (lance.c), preventing the image to compile
> - there is no precise order in which drivers are linked
> 
> WRT the last point, these are the troubles I had:
> - the 3c90x.o driver should be linked BEFORE the 3c595.o, otherwise
> 3c905b cards will be (badly) handled by the 3c595 driver as a 3c900b
> cards (they have same IDs... :o( ...is there some other way to
> distinguish these two NICs?)
> - ISA cards with noisy/long/unsafe probing should be probed after ISA
> cards with better probing
> 
> At the moment, my solution is adding these line to the Makefile.main:
> 
> ---
> # Rule for the NIC-autoprobing image. (by Paolo Salvan)
> NETOBJS:=
> # Note: the 3c90x.o driver should be linked BEFORE the 3c595.o
> # otherwise 3c905b cards will be (badly) handled by the 3c595 driver as
> a 3c900b cards
> NETOBJS+=		$(BIN)/3c90x.o $(BIN)/3c595.o $(BIN)/cs89x0.o
> $(BIN)/davicom.o $(BIN)/depca.o $(BIN)/e1000.o $(BIN)/eepro.o
> $(BIN)/eepro100.o $(BIN)/epic100.o $(BIN)/fa311.o $(BIN)/natsemi.o
> $(BIN)/ns8390.o $(BIN)/pcnet32.o $(BIN)/prism2_pci.o $(BIN)/prism2_plx.o
> $(BIN)/sis900.o $(BIN)/sk_g16.o $(BIN)/sundance.o $(BIN)/tg3.o
> $(BIN)/tlan.o $(BIN)/tulip.o $(BIN)/via-rhine.o $(BIN)/w89c840.o
> $(BIN)/3c503.o $(BIN)/ne.o $(BIN)/wd.o $(BIN)/ne.o
> NETOBJS+=		$(BIN)/rtl8139.o
> # These drivers show "noise" on the screen, at the moment I'm excluding
> them...
> # will be fixed in next eb version
> #NETOBJS+=		$(BIN)/3c529.o $(BIN)/3c515.o $(BIN)/3c509.o
> $(BIN)/smc9000.o
> 
> $(BIN)/etherboot-net.o: $(NETOBJS)
> 	$(LD) -r $(NETOBJS) -o $@
> ---
> 
> ...But it is little mantainable... :-(
> 
> Some idea for petter solutions????

Are ISA devices really that common?  I am about ready to start replacing
PCI devices with PCI express versions.

You can make any image you want by:

make bin/driver--driver--driver.ext  

And this gets the link order in the order you specify.

Eric

Re: [Etherboot-developers] Universal auto-probing driver

[Paolo S. <al...@io...>]

Hi!

....This is an answer to a mail from Febrary, but I think there is
something to comment, now that the etherboot.zdsk is going to be quite
usable (BTW, I've seen that in CVS there are all the fix I asked two day
ago reguarding "noisy" drivers! Congratulation for the efficiency!):

"Eric W. Biederman" ha scritto:
[etherboot.o]
> In addition I have now added a rule for etherboot-pci.o which
> is just the pci drivers.  It does not add a lot but it does mean
> you don't get caught in the 3c509 drivers 4000 attempts to probe the
> card, nor any other bad pci probe.

Perhaps at the moment the distinction etherboot.o vs etherboot-pci.o is
not really useful; as seen here:

> etherboot.zimg     is  84581 bytes
> etherboot-pci.zimg is  75420 bytes

...super-driver sizes are similar, the 3c509 driver now do only 100
probing, without filling the screen of output, idem for other drivers...

In my opinion, priority now is to give a GOOD list of driver, and in a
GOOD order, to the linker; current etherboot.o image have the following
problems:
- some drivers are included two times
- some unusefull drivers are included (disk/*.c)
- a wrong driver is included (lance.c), preventing the image to compile
- there is no precise order in which drivers are linked

WRT the last point, these are the troubles I had:
- the 3c90x.o driver should be linked BEFORE the 3c595.o, otherwise
3c905b cards will be (badly) handled by the 3c595 driver as a 3c900b
cards (they have same IDs... :o( ...is there some other way to
distinguish these two NICs?)
- ISA cards with noisy/long/unsafe probing should be probed after ISA
cards with better probing

At the moment, my solution is adding these line to the Makefile.main:

---
# Rule for the NIC-autoprobing image. (by Paolo Salvan)
NETOBJS:=
# Note: the 3c90x.o driver should be linked BEFORE the 3c595.o
# otherwise 3c905b cards will be (badly) handled by the 3c595 driver as
a 3c900b cards
NETOBJS+=		$(BIN)/3c90x.o $(BIN)/3c595.o $(BIN)/cs89x0.o
$(BIN)/davicom.o $(BIN)/depca.o $(BIN)/e1000.o $(BIN)/eepro.o
$(BIN)/eepro100.o $(BIN)/epic100.o $(BIN)/fa311.o $(BIN)/natsemi.o
$(BIN)/ns8390.o $(BIN)/pcnet32.o $(BIN)/prism2_pci.o $(BIN)/prism2_plx.o
$(BIN)/sis900.o $(BIN)/sk_g16.o $(BIN)/sundance.o $(BIN)/tg3.o
$(BIN)/tlan.o $(BIN)/tulip.o $(BIN)/via-rhine.o $(BIN)/w89c840.o
$(BIN)/3c503.o $(BIN)/ne.o $(BIN)/wd.o $(BIN)/ne.o
NETOBJS+=		$(BIN)/rtl8139.o
# These drivers show "noise" on the screen, at the moment I'm excluding
them...
# will be fixed in next eb version
#NETOBJS+=		$(BIN)/3c529.o $(BIN)/3c515.o $(BIN)/3c509.o
$(BIN)/smc9000.o

$(BIN)/etherboot-net.o: $(NETOBJS)
	$(LD) -r $(NETOBJS) -o $@
---

...But it is little mantainable... :-(

Some idea for petter solutions????

Bye!

Paolo

Re: [Etherboot-developers] tg3.h old?

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

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

> >Oh, sorry.  I'm definitely going to many directions at once.
> >I should have the rest of the pieces committed now.
> 
> Hi Eric,
> 
> I think include/pci_ids.h is still not up to date.
> 
> drivers/net/tg3.c: In function `tg3_get_invariants':
> drivers/net/tg3.c:2762: error: `PCI_DEVICE_ID_TIGON3_5901' undeclared (first use
> in this function)
> 
> drivers/net/tg3.c:2762: error: (Each undeclared identifier is reported only once
> 
> drivers/net/tg3.c:2762: error: for each function it appears in.)
> drivers/net/tg3.c:2763: error: `PCI_DEVICE_ID_TIGON3_5901_2' undeclared (first
> use in this function)

Yep.  I missed that.  I have committed that and actually tested it this
time.  My apologies.

Eric

Re: [Etherboot-developers] tg3.h old?

[<ke...@et...>]

>Oh, sorry.  I'm definitely going to many directions at once.
>I should have the rest of the pieces committed now.

Hi Eric,

I think include/pci_ids.h is still not up to date.

drivers/net/tg3.c: In function `tg3_get_invariants':
drivers/net/tg3.c:2762: error: `PCI_DEVICE_ID_TIGON3_5901' undeclared (first use in this function)
drivers/net/tg3.c:2762: error: (Each undeclared identifier is reported only once
drivers/net/tg3.c:2762: error: for each function it appears in.)
drivers/net/tg3.c:2763: error: `PCI_DEVICE_ID_TIGON3_5901_2' undeclared (first use in this function)