etherboot-developers — Discussion of developer issues

[Etherboot-developers] Etherboot 5.3.3 (development) released

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

I have released Etherboot 5.3.3 at www.etherboot.org This is a catch up
release, but also to put the UNDI driver into testing.

Changes from 5.3.2:

+ Multicast support for the ns8390 (NE, WD, etc) added by Timothy
Legge.
                                                                               
+ Provide config access to alternate DHCP/BOOTP ports. The macro
ALTERNATE_DHCP_PORTS_1067_1068 switches to ports 1067 and 1068.
                                                                               
+ UNDI driver by Michael Brown.

MD5 sum:

2120669ae010bb2503e544dfc90f3bfc  etherboot-5.3.3.tar.bz2

SHA1 sum:

d0a7725d5d5236afefcdb72dd3ddf1c54f0a272d  etherboot-5.3.3.tar.bz2

Re: [Etherboot-developers] Open issues...

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

Dear Eric,

>I disagree.  Except in some small details I think the current make
>files do a good job of modeling the actual problem, and the problem is
>complex.  If you have specific complaints we can look at them.
>  
>
I absolutly agree with you. My problem is that I need a lot of time to 
understand the Makefiles. Thus, I can see that you create a lot of 
different type of files (compressed, e.t.c) which are useless in my 
case. What I was thinking is to create a Makefile.e1 and the user can 
compile/link by just invoking "make -f Makefile.e1".  I do *not* propose 
to overcome your implementation which is more integrated, just to give 
an alternative way to build etherboot when one targets to Hyperstone.

In any case I will try again to examine thoroughly the Makefiles to see 
if I can follow your path.

>#ifdef EMBEDDED is a good start.  My hunch is that unless every embedded device
>implements the functionality in the same way something a little more specific
>would be appropriate.
>
Sorry, but I am not familiar with other device drivers. The problem in 
the cs89x0 driver is that some data are stored in an external EEPROM 
attached to the NIC. In the case of an embedded system (so far I have 
met a lot of different development boards with the same design) the 
designer usually does not equip the board with such an EEPROM. Thus, you 
have to setup the MAC address manually. In the case of this device 
driver, things are easy. You can comment-out some lines where accesses 
to the EEPROM are performed and add a few lines to copy from a static 
array the MAC address.

>>3)In core/main.c the following appears:
>>    console_init();
>>   arch_main(ptr);
>>Is there any problem to reverse the order of those function calls ?
>>    
>>
Actually, in my arch_main() I mainly configure the I/O ports. This has 
to be performed prior to accessing the UART device.
No need for further investigation, I will move this functionality into 
the start.S file so you do not have to permutate the function calls.

>The for loop is appropriate. 
>isa_drivers is the first item in the array.
>isa_drivers_end is the last item in the array.
>The linker builds this for us automatically, does your link have a
>problem with etherboot.lds
>  
>
Ok, this is also soved. I have modified the sources and the linker 
scripts and now it is ok.

Regards

Yannis

Re: [Etherboot-developers] Etherboot chaining

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

>I manually edited the header of the NBI file in Emacs:
>
>   Type: NBI
>   Header location:        93e0:0000
>   Start address:          00060000 (flat)
>
>After making this change, chaining works just fine for my eepro100 images.
>
>My Perl skills are a little rusty. I can probably fix the code in 
>mknbi.pl, but I'd prefer if somebody else (Ken?) volunteered. I consider 
>Perl to be a write-only language ;-)

Actually you should be running mknbi-rom on the .z?rom file, like the
man page says, but it's made me realise that a mkelf-img program is
useful and trivial to do. Here's the patch to apply to mknbi sources
until the next mknbi release.

--- Makefile.old	2003-08-19 17:47:13.000000000 +1000
+++ Makefile	2003-10-10 17:32:15.000000000 +1000
@@ -232,7 +232,7 @@
 	do \
 		ln -sf ../lib/mknbi/mknbi mknbi-$$i; \
 	done; \
-	for i in linux menu nfl lua; \
+	for i in linux img menu nfl lua; \
 	do \
 		ln -sf ../lib/mknbi/mknbi mkelf-$$i; \
 	done
@@ -243,7 +243,7 @@
 	-mkdir -p $(MANDIR)
 	$(INSTALL) -m 644 mknbi.1 disnbi.1 $(MANDIR)/
 	cd $(MANDIR); \
-	for i in mknbi-linux mkelf-linux mknbi-rom mknbi-menu mkelf-menu mknbi-nfl mkelf-nfl mknbi-dos mknbi-fdos; \
+	for i in mknbi-linux mkelf-linux mknbi-rom mkelf-img mknbi-menu mkelf-menu mknbi-nfl mkelf-nfl mknbi-dos mknbi-fdos; \
 	do \
 		ln -sf mknbi.1 $$i.1; \
 	done
--- mknbi.pl.old	2003-10-09 01:00:30.000000000 +1000
+++ mknbi.pl	2003-10-10 17:33:05.000000000 +1000
@@ -67,6 +67,24 @@
 	$module->copy_file($romdesc);
 }
 
+sub mkelf_img ($)
+{
+	my ($module) = @_;
+	my ($romdesc);
+
+	$#ARGV >= 0 or die "Usage: $0 .img-file\n";
+	return unless check_file($ARGV[0]);
+	$module->add_pm_header("mkelf-img-$version", $relocseg + 0x3E0, 0x60000, 0);
+	$romdesc = { file => $ARGV[0],
+		segment => 0x6000,
+		maxlen => 0x10000,
+		id => 16,
+		end => 1 };
+	$module->add_segment($romdesc);
+	$module->dump_segments();
+	$module->copy_file($romdesc);
+}
+
 sub inet_aton_warn
 {
 	my ($ip);
@@ -597,6 +615,8 @@
 }
 if ($target eq 'rom') {
 	&mknbi_rom($module);
+} elsif ($target eq 'img') {
+	&mkelf_img($module);
 } elsif ($target eq 'linux') {
 	&mknbi_linux($module);
 } elsif ($target eq 'fdos') {
@@ -639,7 +659,9 @@
 
 B<mknbi-linux> [--output=I<outputfile>] I<kernelimage> [I<ramdisk>]
 
-B<mknbi-rom> [--output=I<outputfile>] I<ROM-image>
+B<mknbi-rom> [--output=I<outputfile>] I<.z?rom-file>
+
+B<mkelf-img> [--output=I<outputfile>] I<.z?img-file>
 
 B<mkelf-menu> [--output=I<outputfile>] [I<dataimage>]
 
@@ -860,7 +882,7 @@
 ROM. This is useful for developing Etherboot drivers or to load a newer
 version of Etherboot with an older one.
 
-Run mknbi like this:
+Run mknbi-rom like this:
 
 mknbi-rom nic.zrom > nic.nb
 
@@ -868,6 +890,24 @@
 The boot ROM will load this as the I<operating system> and execute the
 ROM image.
 
+=head1 MKELF-IMG
+
+B<mkelf-img> makes a boot image from an Etherboot C<.img> or C<.zimg>
+image.  This allows it to be netbooted using an existing ROM. This is
+useful for developing Etherboot drivers or to load a newer version of
+Etherboot with an older one.
+
+Run mkelf-img like this:
+
+mkelf-img nic.zimg > nic.nb
+
+Move F<nic.nb> to where the network booting process expects to find it.
+The boot ROM will load this as the I<operating system> and execute the
+image.
+
+Note that this does not test the ROM loader portion that's in a C<.z?rom>
+image, but not in a C<.z?img>.
+
 =head1 MKELF-MENU
 
 B<mkelf-menu> and B<mknbi-menu> make a boot image from an auxiliary menu

Re: [Etherboot-developers] UNDI driver

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

>I have checked the UNDI driver from 5.1 in to 5.3 CVS.  It compiles 
>without problems, but I haven't yet tested it.  I have some new PXE NICs 
>with which to test it and I'm expecting to make some changes over the next 
>few days.
>
>Not sure whether to add it to 5.2 or wait until it's working with a wider 
>variety of cards.

Great, thanks.  I'd be happy to release 5.3.3 now or in a few days time
so that Marty can put it on rom-o-matic for wider testing. Which would
you prefer?

Re: [Etherboot-developers] UNDI driver

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

On Thursday, October 9, 2003, at 12:56  PM, Michael Brown wrote:
> I have checked the UNDI driver from 5.1 in to 5.3 CVS.  It compiles
> without problems, but I haven't yet tested it.  I have some new PXE 
> NICs
> with which to test it and I'm expecting to make some changes over the 
> next
> few days.

Many thanks, Michael. I'll plan to try it this weekend, along with a 
rom-o-matic.net update.

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] UNDI driver

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

I have checked the UNDI driver from 5.1 in to 5.3 CVS.  It compiles 
without problems, but I haven't yet tested it.  I have some new PXE NICs 
with which to test it and I'm expecting to make some changes over the next 
few days.

Not sure whether to add it to 5.2 or wait until it's working with a wider 
variety of cards.

Michael

Re: [Etherboot-developers] Boot PROM limited to 32 KBytes

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

>In the compression algorithm appendix of the developers manual
>(http://etherboot.sourceforge.net/doc/html/devman/compressor.html), it
>is said that "the BOOT Prom does not support uncompressed data of more
>then 32kB."

It comes from the assembly language implementation of the decompressor.
However I think this doesn't not apply anymore to 5.2+, where the
decompressor has been reimplemented in C, i.e. executing in 32-bit PM
mode.

[Etherboot-developers] Boot PROM limited to 32 KBytes

[Marc T. <mt...@si...>]

In the compression algorithm appendix of the developers manual
(http://etherboot.sourceforge.net/doc/html/devman/compressor.html), it
is said that "the BOOT Prom does not support uncompressed data of more
then 32kB."

I understand the boot PROM itself might be limited to almost 128 KBytes
because the 3rd byte must contain the size of the PROM in blocks of 512
bytes, so 255 * 512 == 128 KBytes - 512. However, where does the
limitation of the uncompressed boot PROM come from?

-- 
Marc Tardif
Sitepak
(514) 866-8883

Re: [Etherboot-developers] Etherboot chaining

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

>OK, I believe I found it. It appears to be a bug in mknbi-rom. The 
>generated NBI image starts with the code from start32.S. The code does 
>not include any ROM headers, and it assumes that it has already been 
>switched to protected mode. The generated NBI header advertises that 
>there is a 6 byte header, and the code should run in real mode:
>
>   Type: NBI
>   Header location:        93e0:0000
>   Start address:          6000:0006
>
>I manually edited the header of the NBI file in Emacs:
>
>   Type: NBI
>   Header location:        93e0:0000
>   Start address:          00060000 (flat)
>
>After making this change, chaining works just fine for my eepro100 images.

Hmm? Are you applying mknbi-rom to eepro100.img or eepro100.zrom? The
.zrom image certainly expects to start in real mode since it's a BIOS
extension.

Re: [Etherboot-developers] Open issues...

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

>1)The current Makefiles are too complex and include a lot of different 
>configurations that are not valid in an embedded system.  Instead I use 
>a small "Makefile.e1" file

Hmm? You don't have to support all the options.

>2)The cs89x0 driver implies the existance of an external ROM. This is 
>not a common practice in the design of embedded systems. I have put some 
>#ifdef EMBEDDED statements which exclude references and accesses to the 
>external ROM

Which ROM is this, the EEPROM?

>3)In core/main.c the following appears:
>    console_init();
>   arch_main(ptr);
>Is there any problem to reverse the order of those function calls ?

It's possible that arch_main will display some output and then the
console will not be ready. Can you explain why you need to reverse the
order?

>4)there are a few places where the following line appears:
>for(driver = isa_drivers; driver < isa_drivers_end; driver++) {
>In my architecture there is only one nic driver available, so the for 
>statement should be something like:
>for(driver = isa_drivers; driver <= isa_drivers_end; driver++) {

If you have only one driver linked in (which is the normal case for
Etherboot images) then it will do the right thing so I don't see why you
need to touch it.

Re: [Etherboot-developers] Etherboot chaining

[Markus G. <ma...@gu...>]

Ken Yap wrote:
> I have seen something similar happen and I don't know why. Here's what I
> wrote in mknbi-1.4.3/TODO. This was on an old Pentium mobo, no PXE or
> anything like that. Any light you could throw on the matter would be
> appreciated.

OK, I believe I found it. It appears to be a bug in mknbi-rom. The 
generated NBI image starts with the code from start32.S. The code does 
not include any ROM headers, and it assumes that it has already been 
switched to protected mode. The generated NBI header advertises that 
there is a 6 byte header, and the code should run in real mode:

   Type: NBI
   Header location:        93e0:0000
   Start address:          6000:0006

I manually edited the header of the NBI file in Emacs:

   Type: NBI
   Header location:        93e0:0000
   Start address:          00060000 (flat)

After making this change, chaining works just fine for my eepro100 images.

My Perl skills are a little rusty. I can probably fix the code in 
mknbi.pl, but I'd prefer if somebody else (Ken?) volunteered. I consider 
Perl to be a write-only language ;-)


Markus

Re: [Etherboot-developers] Open issues...

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

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

> Hi,
> 
> I still have some minor open issues that have to be resolved before trying to
> merge the new aervhitecture (Hypersone E1) with the sources of the CVS.
> 
> Except the architecture dependent parts that are finished I have some comments
> on the architecture independent parts. Namely,
> 
> 1)The current Makefiles are too complex and include a lot of different
> configurations that are not valid in an embedded system.  Instead I use a small
> "Makefile.e1" file

I disagree.  Except in some small details I think the current make
files do a good job of modeling the actual problem, and the problem is
complex.  If you have specific complaints we can look at them.

src/Makefile
   is designed to provide a default interface that will work out of
   the box for the general case.


src/Config
   holds the architecture independent default configuration. 

src/arch/.../Config
   holds the architecture dependent default configuration.

The above 3 are designed to be replaced for a specific build
environment.  Replacing them with a single file is fine.

src/Makfile.main
   holds the generic rules for build code.

src/arch/.../Makefile
   holds the architecture specific rules to build the code.

- If the problem is the default set of targets replaces src/Makfile is
  a good way to go.

- If the problem is way to many arch specific rules
  srch/arch/.../Makfile only needs to support the targets that can be
  built for your architecture.


Having rules that support all of the drivers that could ever possibly
be used on a given architecture is important, so that you don't need
to do a completely new port for each new board.
 
> 2)The cs89x0 driver implies the existance of an external ROM. This is not a
> common practice in the design of embedded systems. I have put some #ifdef
> EMBEDDED statements which exclude references and accesses to the external ROM

#ifdef EMBEDDED is a good start.  My hunch is that unless every embedded device
implements the functionality in the same way something a little more specific
would be appropriate.

> 3)In core/main.c the following appears:
>     console_init();
>    arch_main(ptr);
> Is there any problem to reverse the order of those function calls ?

Maybe.  If you can hardcode your console driver at compile time
there is certainly value in doing it this way.  If you don't use the
generic serial driver console_init() does nothing.  So you can put
all of the work into arch_main();  The Itanium port does this for the
efi console drivers.

Essentially what this documents is that the arch generic code can assume
it can always use the generic console services.  They might not do anything
but the code is safe to call.

Essentially this is what the Linux kernel does as well.

> 4)there are a few places where the following line appears:
> for(driver = isa_drivers; driver < isa_drivers_end; driver++) {
> In my architecture there is only one nic driver available, so the for statement
> should be something like:
> for(driver = isa_drivers; driver <= isa_drivers_end; driver++) {

The for loop is appropriate. 
isa_drivers is the first item in the array.
isa_drivers_end is the last item in the array.
The linker builds this for us automatically, does your link have a
problem with etherboot.lds

Eric

[Etherboot-developers] Open issues...

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

Hi,

I still have some minor open issues that have to be resolved before 
trying to merge the new aervhitecture (Hypersone E1) with the sources of 
the CVS.

Except the architecture dependent parts that are finished I have some 
comments on the architecture independent parts. Namely,

1)The current Makefiles are too complex and include a lot of different 
configurations that are not valid in an embedded system.  Instead I use 
a small "Makefile.e1" file

2)The cs89x0 driver implies the existance of an external ROM. This is 
not a common practice in the design of embedded systems. I have put some 
#ifdef EMBEDDED statements which exclude references and accesses to the 
external ROM

3)In core/main.c the following appears:
    console_init();
   arch_main(ptr);
Is there any problem to reverse the order of those function calls ?

4)there are a few places where the following line appears:
for(driver = isa_drivers; driver < isa_drivers_end; driver++) {
In my architecture there is only one nic driver available, so the for 
statement should be something like:
for(driver = isa_drivers; driver <= isa_drivers_end; driver++) {

Comments please ?

Yannis

Re: [Etherboot-developers] Etherboot chaining

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

>Is this a known problem? Could this be related to the bugs that 
>prevented PXE chaining (as reported last July)? Should I try to track 
>this down, or does somebody else already have a handle on it?

I have seen something similar happen and I don't know why. Here's what I
wrote in mknbi-1.4.3/TODO. This was on an old Pentium mobo, no PXE or
anything like that. Any light you could throw on the matter would be
appreciated.

When Etherboot 5.0 in ROM loads a mknbi-rom made 5.2 image for the 3c509
NIC, this image executes but is not able to load a NFL menu. If the
3c509 is booted from 5.2 floppy it has no problems loading a NFL menu.
If the NFL menu is replaced with a DOS image or a tomsrtbt image just
before chaining, there is no problem either.  So it seems that 5.2
Etherboot has problems loading NFL images when it's chained to from 5.0.
Bizarre.

[Etherboot-developers] Etherboot chaining

[Markus G. <ma...@gu...>]

Hi,

I finally got a few hours time to play with Etherboot again at work 
(maybe, I'll even get my TCP/IP code finalized at some time -- knock on 
wood). And the first problem I ran into was my inability to chain 
current (i.e.  >= 5.2.x) Etherboot images.

In order to simplify the development cycle, I set up a machine that 
boots into Etherboot 5.3.2 and then subsequently loads another ROM image 
using TFTP. I used mknbi-rom to build the latter. Whenever I try to load 
a second-stage image that is newer than 5.2.x, the system freezes. Older 
images work just fine.

Is this a known problem? Could this be related to the bugs that 
prevented PXE chaining (as reported last July)? Should I try to track 
this down, or does somebody else already have a handle on it?

I probably won't have more than at most a few hours a week that I can 
spend on Etherboot, but I would like to get these issues resolved -- and 
implement a few features that my employer asked for (but which might be 
too specific for Ken to admit into the official tree).


Markus

P.S.: Marty, what do you think about having rom-o-matic offer ISO images 
in addition to floppy images? This is pretty easy to do with a loopback 
mount, syslinux and mkisofs; the "normal" floppy images unfortunately do 
not work when booted from CD.

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

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

Hi!

> > ...A question: could it be useful for .zpxe image also?
> 
> PXE on i386 can't load larger than 32K images, but if you mean selecting the
> right .zpxe image, yes, it will be useful.
> 
> > Waiting for a UNDI driver, it could be a temporary solution to use NBI
> > image with PXE...
> 
> Are you volunteering? There are at least two drivers here: etherboot providing
> an UNDI driver so that PXE images can be loaded, or etherboot's network driver
> using the PXE API provided by the UNDI driver already there. Which one are you
> interested in? My understanding is that you want to load .zpxe image without
> specifying what network card you have, that is the second one above.

I'm a developer of thinstation (look at thinstation.sf.net); my simple
needs is to permit hybrid etherboot/pxe tinclient networks.... without
strange DHCP settings.

As you said, the solution could be:
- etherboot exposing a UNDI interface for using the PXE loader
or
- an etherboot.zpxe loader using the underlying UNDI driver to load the
final bootimage.NBI

I prefer the second solution (for no particular technical reason...)

A nice feature for this loader would be something like:

"if tftp file name match *.zpxe, then download *.nbi instead..."

...this to simplify DHCP configuration...

Ok.... I've said what I'd like to see... but no, I can't volunteer to do
this; not enought knowledge, but mainly not enought time to do it....
:o(

bye!

Paolo

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

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

On Tue, 7 Oct 2003, Paolo Salvan wrote:

> Ken Yap ha scritto:
> >
> > ># Rule for the all-NIC-autoprobing image. (by Paolo Salvan)
> > >NETOBJS:=
> >
> > The easiest solution may be to put your rules in a wrapper
> > Makefile.etherboot which includes the main Makefile at the end. Since
> > the ISA objects are i386 specific, maybe something like
> >
> >         make -f arch/i386/Makefile.etherboot
> >
> > Since the autoprobing image mostly makes sense in .zdsk form (too large
> > for .com) and once you have found what NIC it is, you can make a
> > targetted image, maybe all rom-o-matic.net needs is a link to a
> > ready-made image for downloading.
>
> Marty, what do you think? This solution seems simple and nice!
>
> You can propose it as a nice "what driver does I need?" tool also...
>
> It will say the .rom image you need...nice for later selecting the right
> .zrom image!
>
>
> ...A question: could it be useful for .zpxe image also?

PXE on i386 can't load larger than 32K images, but if you mean selecting the
right .zpxe image, yes, it will be useful.

> Waiting for a UNDI driver, it could be a temporary solution to use NBI
> image with PXE...

Are you volunteering? There are at least two drivers here: etherboot providing
an UNDI driver so that PXE images can be loaded, or etherboot's network driver
using the PXE API provided by the UNDI driver already there. Which one are you
interested in? My understanding is that you want to load .zpxe image without
specifying what network card you have, that is the second one above.

> (btw, are there works going on about an etherboot UNDI driver?)

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

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

Hi!

Ken Yap ha scritto:
> 
> ># Rule for the all-NIC-autoprobing image. (by Paolo Salvan)
> >NETOBJS:=
> 
> The easiest solution may be to put your rules in a wrapper
> Makefile.etherboot which includes the main Makefile at the end. Since
> the ISA objects are i386 specific, maybe something like
> 
>         make -f arch/i386/Makefile.etherboot
> 
> Since the autoprobing image mostly makes sense in .zdsk form (too large
> for .com) and once you have found what NIC it is, you can make a
> targetted image, maybe all rom-o-matic.net needs is a link to a
> ready-made image for downloading.

Marty, what do you think? This solution seems simple and nice!

You can propose it as a nice "what driver does I need?" tool also...

It will say the .rom image you need...nice for later selecting the right
.zrom image!


...A question: could it be useful for .zpxe image also?
Waiting for a UNDI driver, it could be a temporary solution to use NBI
image with PXE...
(btw, are there works going on about an etherboot UNDI driver?)

bye!

Paolo

RE: [Etherboot-developers] RFC: Standardized Driver Debugging

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

> Yes, that's a good idea too. It might be regarded as debug level 0,
> which cannot be disabled :-). The driver should display its name, its
> version and the MAC address at the very least. Some drivers might want
> to display memory regions used, etc, but this arguably is debugging

I would also suggest the vendor id and device id.  When someone boots
with a floppy, it would help ensure they choose the correct rom file
from romomatic.

I will probably throw some of this in the Wiki over the next few days.

Tim

Re: [Etherboot-developers] RFC: Standardized Driver Debugging

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

>Also, I would like to see the non debug output from the drivers
>standardized as well.  Any thoughts?

Yes, that's a good idea too. It might be regarded as debug level 0,
which cannot be disabled :-). The driver should display its name, its
version and the MAC address at the very least. Some drivers might want
to display memory regions used, etc, but this arguably is debugging
output not of concern to the end user, who needs the MAC address for
setting up DHCP config files, and the name and version to report
problems. I suggest a last-worked-on date string for the version number.
Not sure about media settings, i.e. full/half duplex, speed.  I think
they should be displayed too, they help with link level diagnosis.

[Etherboot-developers] RFC: Standardized Driver Debugging

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

Hi All

I decided to take a stab at outlining a driver debugging model.  Since
there is a ToDo in Ken's list for volunteers I figure we may be able to
help it along by documenting a preferred model.  Then when someone is
looking for something quick and easy to do (like my project to enable
multicast in all the drivers) they will have all the information they
need.

I ran this by Ken and nothing seemed to be too out there.  He suggested
replacing the replacing the levels with orthogonal set of bit flags
which would allow any combination of debug output.  Regardless of
method, I would like to ensure that we have captured all the types of
debugging information and that the breaks I outlined below are valid.

Ken also suggested a debug printf macro that can be left in all the time
and only generates code when the symbol is activated. As he said, this
has been done before in C, the trick is to use double parens so that the
whole arg list becomes a single argument, getting around the varargs
aspect of a printf. Something like this:

#define	DPRINTF(x)	printf x

DPRINTF(("I am here"))

I believe I saw this model in some Linux code I was reviewing recently.
I am open to any suggestions as I would like to see a target model
documented that we could begin implementing.  

Also, I would like to see the non debug output from the drivers
standardized as well.  Any thoughts?

First Attempt:

#define DEBUG_LEVEL_1 | DEBUG_WHEREAMI

This would be basic where am I functionality.  Each function should have
call a whereami function.  Whereami would print out the function name
and an incremented integer.  The incremented integer would allow you to
verify the order driver functions are called and which time caused the
problem.

#define DEBUG_LEVEL_2 | DEBUG_FUNCTION

This would be used for debugging the does not include the results of
communication with the hardware (i.e. not interrupt based or read
statements).  This is for printing out information about the
functionality of the code.

#define DEBUG_LEVEL_3 | DEBUG_HARDWARE

This would print out the results of communicating with the hardware.
Where interesting information is read from the hardware print out the
results of the read will be printed and interpreted (if the result means
something in English (0x20 might be interpreted as Full Duplex).

#define DEBUG_LEVEL_4 | DEBUG_PACKETS

This would be basic packet printing (hexdump) for the poll and transmit
functions or anywhere the use of hexdump would be warranted.

Regards

Tim

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

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

># Rule for the all-NIC-autoprobing image. (by Paolo Salvan)
>NETOBJS:=

The easiest solution may be to put your rules in a wrapper
Makefile.etherboot which includes the main Makefile at the end. Since
the ISA objects are i386 specific, maybe something like

	make -f arch/i386/Makefile.etherboot

Since the autoprobing image mostly makes sense in .zdsk form (too large
for .com) and once you have found what NIC it is, you can make a
targetted image, maybe all rom-o-matic.net needs is a link to a
ready-made image for downloading.

[Etherboot-developers] Etherboot 5.2.2 (production) released

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

Ok we have accumulated enough goodies after the previous version so h=
ere
goes another production release. You will find it in the usual place:

+ Break out etherboot.h into multiple files along protocol lines.

+ Georg Baum's conversion of a more recent version of the Linux e1000
driver.

+ Add mini-slamd to contrib/, it was missed during 5.2 release.

+ Timothy Legge enabled multicast for a bunch of drivers. Tested with
mini-slamd.

+ Timothy Legge rewrite proto_tftm.c, got multicast working with atft=
p
and enabled multicast for the Tulip.

+ 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/. Usab=
le
Java version now also available.

+ Multicast support for the ns8390 (NE, WD, etc) added by Timothy Leg=
ge.

+ Provide config access to alternate DHCP/BOOTP ports. The macro
ALTERNATE_DHCP_PORTS_1067_1068 switches to ports 1067 and 1068.

MD5 sums:

5763687321bbc089c290d88ae32e7bcc  etherboot-5.2.2.tar.bz2
04800be635a59b75453d634d96b79b5b  etherboot-5.2.2.tar.gz

SHA1 sums:

518fb36a5980b0ca1dbed14bf10b71a175e65095  etherboot-5.2.2.tar.bz2
2552542e4f6cd7931075256231fb45e143286bec  etherboot-5.2.2.tar.gz

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

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

Hi!

This is my "prototype":

# Rule for the all-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
3c900b cards
NETOBJS+=		$(BIN)/3c90x.o
# PCI cards....
NETOBJS+=		$(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)/rtl8139.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
# ISA cards...
NETOBJS+=		$(BIN)/3c503.o $(BIN)/ne.o $(BIN)/wd.o $(BIN)/3c529.o
$(BIN)/3c509.o $(BIN)/smc9000.o
# This driver has slow autoprobing and is rarely used, so it is better
to exclude it...
#NETOBJS+=		$(BIN)/3c515.o

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

Then, i use "make etherboot-net.zdsk" to build my floppy...

...bye!

Paolo

"Eric W. Biederman" ha scritto:
> 
> 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.

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

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

On Tuesday, September 30, 2003, at 05:56  AM, Timothy Legge wrote:
> 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.

I'm not sure what is going on with this. It works with my browsers.

> Are their any specific areas you would like tested?

I'm just looking for sanity checking. My favorite test machine is 
disassembled at the moment, and I just wanted to make sure I'm 
generating something usable.

I've put 5.3.2 up in the Development Releases section on 
rom-o-matic.net, and will hold off until 5.2.2 for the  production 
section update. I've also made some changes in the rom-o-matic code 
structure that should make it easier to put up new releases in the 
future. It's not automatic yet, but it's pretty easy, depending on 
changes to the Config files in src and src/arch/i386.

Anyway, enjoy. As a point of information, we're generating about 5000 
ROM images a week now. I'd be fascinated to know how and where they're 
being used. I like to think people are setting up lots of LTSP and 
cluster installations, and people in colleges and universities and 
businesses are using them for all sorts of cool stuff.  I sometimes 
think it would be neat to travel around and journal the interesting 
uses for network booting. Maybe I yet will.

Rom-o-matic.net will celebrate its 3rd birthday the end of October, and 
maybe we'll have a little party in the basement for it :)

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/