etherboot-developers — Discussion of developer issues

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

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

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

> Eric, I think you forgot to check in the latest tg3.h. I'm getting
> compile errors on tg3.c.

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

I have added one definition to etherboot.h as well.
VALID_LINK_TIMEOUT.  The amount of time a NIC driver should wait 
for a link to establish with a switch.  The timeout is set at 10
seconds, which is should be excessive.

I had to up a timeout of 3 seconds after I ran into a switch that
was overloaded when I had 256 machines talking to it at once.  And
so it would not complete link autonegotiation, in a timely manner.

More later but I figured I should get the compile errors corrected.
My apologies.

Eric

[Etherboot-developers] Wiki contributions

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

If you've been looking for some way to contribute to Etherboot...

It would be useful if people could take interesting information that
flows past in mailings and fill up the Wiki pages. This would benefit
everyone.  Have a look at

http://etherboot.augustinnetz.de/

Wiki pages are dead easy to edit.  It's informal, no need to wait for
somebody official to do it. Just jump in and file something you have
that you think is useful, whether it's from this list or tips you have.
Here's a suggestion: if you have some tips to share in reply to a
question, put it into the Wiki first, then post the URL. Or both.  For
example I just added a link on the home page and then pasted the text of
my reply in the new page:

http://etherboot.augustinnetz.de/wiki.pl?ROMsFor8139

Eventually I'll grab the best information and incorporate them into the
official documentation.

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...

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

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

Checked into 5.3. Will appear in 5.3.2, then maybe 5.2.2.

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

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

|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).
|
|Best Regards!
|
|    CaiQiang

Thanks, I will merge that and check it into CVS.

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

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

>The drivers that write noise on the screen are:
>------------------
>3c529.o: writes repeatedly:
>
>    3c509: eeprom busy.
>    (probe fail)
>    Warning assuming presence of MCA bus
>    MCA card not found
>
>...and require ESC to continue
>------------------
>3c515.o writes repeatedly dots ".........................."
>
>The second time is is probed, writes instead:
>
>    0 3c515 cards found
>
>...and require ESC to continue   
>------------------
>3c509.o writes repeatedly:
>
>    3c509: eeprom busy.
>    (probe fail)
>
>...and require ESC to continue
>------------------
>smc9000.o: no real problems.... simply writes a "...driver
>version....\ncopyright...\nNo SMC9000 Adapter found" after writing his
>name, not coherent with other drivers...
>------------------
>sk_g16: no real problems.... simply writes a "\n" after writing his
>name, not coherent with other drivers...

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

>> >No problem... the big problem was WHERE to put my hand to prevent this
>> >file to be included in etherboot.zdsk; at the end I changed genrules.pl,
>> >but I'm not really sure it is the right place...
>> 
>> It's already commented out in the 5.2.1 I believe.
>
>No....it wasn't...   :o(

It's checked in now.

[Etherboot-developers] tg3.h old?

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

Eric, I think you forgot to check in the latest tg3.h. I'm getting
compile errors on tg3.c.

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

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

Hi!

Ken Yap ha scritto:
> 
> >Ok, if needed I can do it.... but the simplest and fastest way is
> >building the etherboot.zdsk image, make the floppy, and try it on a PC
> >without network card (so it will probe everything....): the main target
> >is having no driver probing infinite times the same network card (so no
> >ESC will be required...); the second target is having coherent and
> >limited output from each driver probing...
> 
> Please take a few moments to document the behaviour and post to this
> list.

Ok....done!

I've added in the makefile this section:

-----
# Rule for the NIC-autoprobing image. (by Paolo Salvan)
NETOBJS:=
NETOBJS+=		$(BIN)/3c595.o $(BIN)/3c90x.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)/rtl8139.o
# These drivers show "noise" on the screen, will be probed last
#NETOBJS+=		$(BIN)/3c529.o $(BIN)/3c515.o $(BIN)/3c509.o
$(BIN)/smc9000.o

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

Consider including it (or something similar, easier to mantain) in the
makefile...

This is similar to the etherboot.o image, but I've excluded:
- disk/ drivers, I think they are not needed (is this right?)
- skel.o driver, I think it is not needed (is this right?)
- duplicated drivers (some drivers were included two times)

I've reordered the drivers, so the ones writing on the screen or
requiring an ESC to be pressed in order to skip his probing are probed
last...

The drivers that write noise on the screen are:
------------------
3c529.o: writes repeatedly:

    3c509: eeprom busy.
    (probe fail)
    Warning assuming presence of MCA bus
    MCA card not found

...and require ESC to continue
------------------
3c515.o writes repeatedly dots ".........................."

The second time is is probed, writes instead:

    0 3c515 cards found

...and require ESC to continue   
------------------
3c509.o writes repeatedly:

    3c509: eeprom busy.
    (probe fail)

...and require ESC to continue
------------------
smc9000.o: no real problems.... simply writes a "...driver
version....\ncopyright...\nNo SMC9000 Adapter found" after writing his
name, not coherent with other drivers...
------------------
sk_g16: no real problems.... simply writes a "\n" after writing his
name, not coherent with other drivers...
------------------
> >No problem... the big problem was WHERE to put my hand to prevent this
> >file to be included in etherboot.zdsk; at the end I changed genrules.pl,
> >but I'm not really sure it is the right place...
> 
> It's already commented out in the 5.2.1 I believe.

No....it wasn't...   :o(

> >I think we should provide a simple way to build custom "50 driver in a
> >single image" image: ie, providing a file with the driver list somone
> >want to include...
> >This file could be auto generated during the build process, and the user
> >can comment/uncomment the drivers he want to include in the final
> >image...
> 
> If you would like to look at this and send in some software that would
> be good. However a multidriver image is only a medium priority item
> because it would be useful only as a probe floppy, it would be slow as a
> production floppy.

Just tested... a multi-driver floppy is slower than a single-driver
floppy of a trascurable time (about 2-3 seconds...); his size is 80kb in
place of 32kb, and autodetecting overhead is 0 for pci card, minimal for
the ISA one... (excluding the forementioned drivers...)

And I don't need to list the advantages of having a single disk type for
every NIC! ;o)

bye!

Paolo

[Etherboot-developers] CONSOLE_DIRECT_VGA: direct video output support

[rimy2000 <rim...@ho...>]

SGksDQogIEkgaGF2ZSByZXdvcmtlZCBpdCBhY2NvcmRpbmcgS2VuIGFuZCBFcmljJ3MgY29tbWVu
dHMuDQoNCkkgYW0gYm9vdGluZyBMaW51eEJJT1MgYW5kIGxvYWRpbmcgbGludXgvV2luQ0UgdXNp
bmcgYSBzZXJpYWwgY29uc29sZS4gTGludXhCSU9TIGFscmVhZHkgc3VwcG9ydHMgZGlyZWN0IHZp
ZGVvIG91dHB1dCwgYnV0IHdoZW4gc3lzdGVtIGdvdG8gZXRoZXJib290LCB2aWRlbyBwYXVzZSwg
dW50aWwgc3lzdGVtIGdvdG8ga2VybmVsLiBTbyBJIHRoaW5rIGl0J2xsIGJlIGJldHRlciB0byBs
ZXQgZWIgc3VwcG9ydCBkaXJlY3QgdmlkZW8gY29uc29sZSB3aGVuIGJvb3RpbmcgZnJvbSBsaW51
eGJpb3MuDQoNCkkgY29weWVkIHZpZGVvX3N1YnIuYyBhbmQgdmdhLmggZnJvbSBsaW51eGJpb3Mg
dG8gYXJjaC9pMzg2IGFuZCBtb2RpZnkgdmlkZW9fc3Vici5jLCBtYWluLmMsbWlzYy5jIHRvIHN1
cHBvcnQgZGlyZWN0IHZpZGVvIG91dHB1dCB1bmRlciBDT05TT0xFX0RJUkVDVF9WR0EuIA0KDQog
ICAgQXR0YWNobWVudCBpcyB0aGUgZGlmZiBmaWxlKHZzIDUuMy4xLCBzbyBpbmNsdWRlIG15IHBy
ZXZpb3VzIHdpbmNlX2xvYWRlciBwYXRjaCkuDQoNCkJlc3QgUmVnYXJkcyENCg0KICAgIENhaVFp
YW5nDQoNCg==

Re: [Etherboot-developers] CVS of 5.2 and 5.3 brought up to date

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

>I have an updated tg3 driver that makes it work much better, that
>I should be pushing back soon.
>
>I also have a small question.  I realized just a little bit ago
>that we never added dhcp options to inform the dhcp server which kinds
>of transports we can support.
>
>ftp://
>nfs://
>x-slam://
>etc.
>
>To be able to write code that can automatically select protocols we need
>to report what is compiled in.  Is it ok if I implement that against 5.2?

I'd be more comfortable if you did it against 5.3 and then we back
propagate but you're the most experienced developer so I don't think you
will break anything.

However I'm planning to push out 5.3.2 just as soon as I get this latest
toy of mine sorta working. It's a tftp to http proxy. So you can hitch
the latest tg3 and your DHCP options onto that release if you want.

I got a private email asking about the Broadcom 5782. Is that related to
the tg3 and supported?

Re: [Etherboot-developers] Re: Fw: CONSOLE_FIRMWARE: video output suppprt

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

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

> |Hi,
> |  In 5.3.1, if -DCONSOLE_FIRMWARE, will compile error:
> |bin/bootlib.a(misc.o)(.text+0x267): In function `putchar':
> |: undefined reference to `console_putc'
> |bin/bootlib.a(misc.o)(.text+0x27d): In function `getchar':
> |: undefined reference to `console_ischar'
> |bin/bootlib.a(misc.o)(.text+0x286): In function `getchar':
> |: undefined reference to `console_getc'
> |bin/bootlib.a(misc.o)(.text+0x2b3): In function `iskey':
> |: undefined reference to `console_ischar'
> |make: *** [bin/via-rhine.tmp] Error 1
> | 
> |  I copyed video_subr.c and vga.h from linuxbios and modify
> |video_subr.c, main.c to support video output under CONSOLE_FIRMWARE.
> 
> I think this patch is wrong for several reasons.
> 
> CONSOLE_FIRMWARE is for display using the PCBIOS. It's not an error in
> the PCBIOS build because those routines are supplied by an assembly code
> interface to the PCBIOS.

CONSOLE_FIRMWARE also works under EFI with a different implementation.
It is totally inappropriate under LinuxBIOS as LinuxBIOS will _never_
provide callbacks.

> I'm not sure what you are booting. It sounds like you are booting
> LinuxBIOS and loading WinCE but not using a serial console. Then I think
> you should:
> 
> 1. First try to hook into the LinuxBIOS routines for console I/O if
> possible. (Is it? I don't know whether LinuxBIOS provides entry points
> for console I/O.)

It does not, nor will it.  At best it will provide a temple entry saying
use this piece of hardware for your console.

> 2. Otherwise, the files video_subr.c and vga.h should definitely go
> under arch/i386/ (you put them in core/) because the code are specific
> to i386 and won't work for other architectures. Then you need to make
> the code conditional on CONSOLE_FIRMWARE if you want to reuse that
> symbol.  Question to the list: should these files be classified as
> CONSOLE_FIRMWARE or should another symbol be invented?

Another symbol say CONSOLE_DIRECT_VGA or something like that.  These
routines are analogous to the serial port support.   Possibly we
should create a drivers/console?  

So moving serial.c is probably appropriate as well.
 
> 3. For a similar reason, your previous patch to the top level
> Makefile.main to make osloader.c depend on wince_loader is also wrong
> because the top level Makefile.main should be architecture independent.

That dependency is in some sense correct.  Since all of the loaders
are included into one file for size reasons.  But except in the most
peculiar circumstances I don't think it comes up as a problem.
 
> So this patch is not accepted as it is because it breaks the separation
> between the arch-independent and arch-specific parts of the source tree.
> It needs rework.

Sounds correct.

> Please monitor the etherboot-devel list for answers from Eric on the
> best way to proceed.

Ken you did a pretty decent job.  I have not seen the patch so I can't
really comment on it beyond what I have done.

Eric

Re: [Etherboot-developers] CVS of 5.2 and 5.3 brought up to date

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

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

> I've back propagated the 5.3 improvements to 5.2, so they are almost
> similar. Now we need to restore the files I missed when cutting 5.2 and
> I'll have an excuse to put out 5.2.2.

Ok.  I have just committed the new version of tg3.c so that should
work much better now.  If you run the chip too stupidly it gets very grumpy.

Eric

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

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

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

> I'm not a developer, so I can only provide more informations... ;o(
> 
> I think we should provide a simple way to build custom "50 driver in a
> single image" image: ie, providing a file with the driver list somone
> want to include...
> This file could be auto generated during the build process, and the user
> can comment/uncomment the drivers he want to include in the final
> image...
> 
> Ok... this is all!

For a more general selection you can do:
make driver1--driver2--driver3-- .... -- driverN.zdsk or
whatever to build a binary with custom selection of multiple drivers.

etherboot.zdsk and etherboot-pci.zdsk are just short cuts for common cases.

Eric

Re: [Etherboot-developers] CVS of 5.2 and 5.3 brought up to date

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

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

> I've back propagated the 5.3 improvements to 5.2, so they are almost
> similar. Now we need to restore the files I missed when cutting 5.2 and
> I'll have an excuse to put out 5.2.2.

I have an updated tg3 driver that makes it work much better, that
I should be pushing back soon.

I also have a small question.  I realized just a little bit ago
that we never added dhcp options to inform the dhcp server which kinds
of transports we can support.

ftp://
nfs://
x-slam://
etc.

To be able to write code that can automatically select protocols we need
to report what is compiled in.  Is it ok if I implement that against 5.2?




One other thing.  We are quickly reaching the point that anything etherboot
can reasonably download can be download in a second when the network is working
properly and everything is GigE.  The bottleneck starts to become the dots
etherboot is printing out.

I have been playing with a version of the progress bar that as we print more
packets per second does exponential backoff in printing characters.
Where the first 10 characters per second are dots, the next 90 are represented
by underscores, the next 900 are represented by dashes, and the next 9000 are
represented by pluses.

So fare I have not quite gotten a plus out of it yet but I have gotten close.

Does this sounds like a sane idea?

Eric



void twiddle(void)
{
	static int count=0;
	static unsigned long lastticks = 0;
	static const char dots[]="._-+*@";
	unsigned long ticks;
	int index, limit;

	/* Limit the maximum rate at which characters are printed */
	ticks = currticks()/TICKS_PER_SEC;
	if (ticks != lastticks) {
		lastticks = ticks;
		count = 0;
	}
	limit = 1;
	index = 0;
	while((index < (sizeof(dots) - 1)) && (count > (limit *10))) {
		limit *= 10;
		index++;
	}
	if ((count % limit) == 0) {
		putchar(dots[index]);
	}
	count++;
}

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

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

Yannis Mitsos <gm...@te...> writes:

> Dear all,
> 
> In the near-past I have attempted to port Etherboot (ver. 5.0.8) for a RISC
> processor (Hyperstone E132-XS) to leverage our project that target at porting
> uClinux to the aforementioned processor. Although the effort was succesful, it
> was "brutal" port that could not be merged with the CVS sources.
> 
> Now, I am working back on this issue. I am doing pretty well. Actually, the
> whole think is working. I have to remind you that our toolchain is GNU
> gcc-2.95.2 and the object format is COFF. The coff-loader is prety much like the
> 
> ELF loader and it is working.
> Still, I have some problems with my compiler with the generic declerations. For
> example, the pre-processor complains with an error with the following two lines:
> 
> 
> typedef sector_t (*os_download_t)(unsigned char *data, unsigned int len, int
> eof);
> static inline os_dowload_t coff_probe(unsigned char *data, unsigned int len)

Is it possible you don't have a uint64_t? Or for some other reason your
sector_t has problems?

> I will try to resolve all those small issues. I have to admit with the current
> structure the poritng to a new architecture is a straight-forward process
> ... Great work ...

Thanks. I'm glad you appreciate it.

Eric

[Etherboot-developers] Re: Fw: CONSOLE_FIRMWARE: video output suppprt

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

|Hi,
|  In 5.3.1, if -DCONSOLE_FIRMWARE, will compile error:
|bin/bootlib.a(misc.o)(.text+0x267): In function `putchar':
|: undefined reference to `console_putc'
|bin/bootlib.a(misc.o)(.text+0x27d): In function `getchar':
|: undefined reference to `console_ischar'
|bin/bootlib.a(misc.o)(.text+0x286): In function `getchar':
|: undefined reference to `console_getc'
|bin/bootlib.a(misc.o)(.text+0x2b3): In function `iskey':
|: undefined reference to `console_ischar'
|make: *** [bin/via-rhine.tmp] Error 1
| 
|  I copyed video_subr.c and vga.h from linuxbios and modify
|video_subr.c, main.c to support video output under CONSOLE_FIRMWARE.

I think this patch is wrong for several reasons.

CONSOLE_FIRMWARE is for display using the PCBIOS. It's not an error in
the PCBIOS build because those routines are supplied by an assembly code
interface to the PCBIOS.

I'm not sure what you are booting. It sounds like you are booting
LinuxBIOS and loading WinCE but not using a serial console. Then I think
you should:

1. First try to hook into the LinuxBIOS routines for console I/O if
possible. (Is it? I don't know whether LinuxBIOS provides entry points
for console I/O.)

2. Otherwise, the files video_subr.c and vga.h should definitely go
under arch/i386/ (you put them in core/) because the code are specific
to i386 and won't work for other architectures. Then you need to make
the code conditional on CONSOLE_FIRMWARE if you want to reuse that
symbol.  Question to the list: should these files be classified as
CONSOLE_FIRMWARE or should another symbol be invented?

3. For a similar reason, your previous patch to the top level
Makefile.main to make osloader.c depend on wince_loader is also wrong
because the top level Makefile.main should be architecture independent.

So this patch is not accepted as it is because it breaks the separation
between the arch-independent and arch-specific parts of the source tree.
It needs rework.

Please monitor the etherboot-devel list for answers from Eric on the
best way to proceed.

[Etherboot-developers] CVS of 5.2 and 5.3 brought up to date

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

I've back propagated the 5.3 improvements to 5.2, so they are almost
similar. Now we need to restore the files I missed when cutting 5.2 and
I'll have an excuse to put out 5.2.2.

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

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

>> Ah, maybe it should use the 18Hz timer for delay?
>> 
>Which one is that?

The one that currticks() uses.

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

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

> 
> Ah, maybe it should use the 18Hz timer for delay?
> 
Which one is that?

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

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

Ken Yap wrote:

> Ok, I take it you are working on the 5.2 structure. 

Actually, it is 5.3.0.

> Looking forward to
>
>seeing a new architecture on the list. Good work and keep us informed
>about your efforts towards world domination. :-)
>  
>
Definately I will keep you informed, thus I will ask for you opinion for 
some patches that may be needed in the architecture independent code.

Yannis

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

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

>Still, I have some problems with my compiler with the generic 
>declerations. For example, the pre-processor complains with an error 
>with the following two lines:
>
>typedef sector_t (*os_download_t)(unsigned char *data, unsigned int len, 
>int eof);
>static inline os_dowload_t coff_probe(unsigned char *data, unsigned int len)
>
>I will try to resolve all those small issues. I have to admit with the 
>current structure the poritng to a new architecture is a 
>straight-forward process ... Great work ...

Ok, I take it you are working on the 5.2 structure. Looking forward to
seeing a new architecture on the list. Good work and keep us informed
about your efforts towards world domination. :-)

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

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

>> I think the probe failed message is only in the 3c509 and should be
>> suppressed. I can't think offhand where the dots come from since no
>> packets are sent out at that point yet.
>> 
>The 3c515 uses the evil delay because of issues I encountered in my old
>486.  Since it starts probing for ISA_PNP it can easily fill the screen
>with dots.  Really, the dots could be suppressed by defining the bar
>instead (I forget the option).

Ah, maybe it should use the 18Hz timer for delay?

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

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

> I think the probe failed message is only in the 3c509 and should be
> suppressed. I can't think offhand where the dots come from since no
> packets are sent out at that point yet.
> 
The 3c515 uses the evil delay because of issues I encountered in my old
486.  Since it starts probing for ISA_PNP it can easily fill the screen
with dots.  Really, the dots could be suppressed by defining the bar
instead (I forget the option).

Tim

[Etherboot-developers] Porting stories...

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

Dear all,

In the near-past I have attempted to port Etherboot (ver. 5.0.8) for a 
RISC processor (Hyperstone E132-XS) to leverage our project that target 
at porting uClinux to the aforementioned processor. Although the effort 
was succesful, it was "brutal" port that could not be merged with the 
CVS sources.

Now, I am working back on this issue. I am doing pretty well. Actually, 
the whole think is working. I have to remind you that our toolchain is 
GNU gcc-2.95.2 and the object format is COFF. The coff-loader is prety 
much like the ELF loader and it is working.
Still, I have some problems with my compiler with the generic 
declerations. For example, the pre-processor complains with an error 
with the following two lines:

typedef sector_t (*os_download_t)(unsigned char *data, unsigned int len, 
int eof);
static inline os_dowload_t coff_probe(unsigned char *data, unsigned int len)

I will try to resolve all those small issues. I have to admit with the 
current structure the poritng to a new architecture is a 
straight-forward process ... Great work ...

Regards

Yannis

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

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

>Ok, if needed I can do it.... but the simplest and fastest way is
>building the etherboot.zdsk image, make the floppy, and try it on a PC
>without network card (so it will probe everything....): the main target
>is having no driver probing infinite times the same network card (so no
>ESC will be required...); the second target is having coherent and
>limited output from each driver probing...

Please take a few moments to document the behaviour and post to this
list.

>Is it influenced by the order of the object files passed to the
>compiler?

By the order the object files are specified to the linker.

>No problem... the big problem was WHERE to put my hand to prevent this
>file to be included in etherboot.zdsk; at the end I changed genrules.pl,
>but I'm not really sure it is the right place...

It's already commented out in the 5.2.1 I believe.

>I think we should provide a simple way to build custom "50 driver in a
>single image" image: ie, providing a file with the driver list somone
>want to include...
>This file could be auto generated during the build process, and the user
>can comment/uncomment the drivers he want to include in the final
>image...

If you would like to look at this and send in some software that would
be good. However a multidriver image is only a medium priority item
because it would be useful only as a probe floppy, it would be slow as a
production floppy.