etherboot-developers — Discussion of developer issues

[Etherboot-developers] VT6102 support

[Ken Y. <ke...@nl...>]

Jean-Jacques Michel will be sending me some patches for this via-rhine
chip, found on some DFE-530TX Rev A3 NICs.

Just to let you know I'll have enough excuses to release .22 (5.0RC2)
very soon, with all the other bugs being found by sharp users. Keep
sending those bug fixes in!

Re: [Etherboot-developers] Problem found + Bug Fix *** More analysis to the old problem with etherboot+GRUB(diskless/disk)

[Ken Y. <ke...@nl...>]

|The problem for the crashing kernel was the CPU detection in the start
|code
|of the etherboot (start32.S). The CPU detection is done via checking,
|which
|bits of the FLAGS CPU register ar stucky or not (see comment in
|start32.S).

Great. Thanks for the patch. Will put in next release.

Re: [Etherboot-developers] Fwd: Error in make

[Ken Y. <ke...@nl...>]

|later on we get:
|
|     gcc -O2 -o bin/makerom makerom.c
|     ld -N -Ttext 0x94000 -e _start -o bin32/3c90x.tmp bin32/start32.o
|bin32/config-3c90x.o bin32/3c90x.o bin32/pci.o bin32/bootlib.a
|     bin32/bootlib.a(ansiesc.o): In function `docommand':
|     /tmp/ROM12QbeH/ansiesc.c:172: undefined reference to `tftp'
|     make: *** [bin32/3c90x.tmp] Error 1
|     make: Leaving directory `/tmp/ROM12QbeH'
|
|One structural thought I had was to perhaps put the tftp code that is 
|currently in main.c into its own file "tftp.c"  much like the nfs code is 
|in "nfs.c", for modularity.  We'd still need function prototypes, of 
|course.
|
|Anyway, the option "-DANSIESC" seemed to trigger the problem.  Before I 
|get too deep into debugging it, does anybody else want to give it a go?

This looks like my booboo, being too zealous in making functions static.
In main.c, remove static from the tftp function. Add a function
prototype for tftp() to etherboot.h. nfs() looks ok. If you want to go
ahead and hack, send me the patches, or I'll do it tonight for the next
release.

[Etherboot-developers] Problem found + Bug Fix *** More analysis to the old problem with etherboot+GRUB(diskless/disk)

[Christoph P. <chr...@do...>]

The problem for the crashing kernel was the CPU detection in the start
code
of the etherboot (start32.S). The CPU detection is done via checking,
which
bits of the FLAGS CPU register ar stucky or not (see comment in
start32.S).

The problem here is, that the flag registers are not restored again.
Of course the problem can also be in our kernel, that it does not
completely setup the initial flags state, but the CPU detection code
must not destroy the FLAGS register.

Below I send a patch of a working start32.S, based on 4.7.20.

With friendly regards

	Christoph Plattner

--- /home/plattner/tmp/etherboot-4.7.20/src/start32.S   Sun Feb 11
02:44:31 2001
+++ start32.S   Wed Mar  7 00:12:54 2001
@@ -51,6 +51,7 @@
 are either all stuck at 1 (8086/8088) or all stuck at 0 (286 in real
mode), if
 not it is a 386 or higher.  A 186/188 behaves like a 8086/8088 in this
check.

**************************************************************************/
+       pushf                           /* backup flags */
        pushf                           /* Get flags */
        popw    %ax
        andw    $0x0fff,%ax             /* Clear top 4 bits */
@@ -80,8 +81,10 @@
        lodsb
        int     $0x10
        loop    err_prloop
+       popf                            /* restore flags */
        lret
 is_386:
+       popf                            /* restore flags */
        movw    %ss,initss-_start
        movw    %sp,initsp-_start
 /*


------------------------------------------------------------------------------------
> Subject: Re: More analysis to the old problem with etherboot+GRUB (diskless/disk)
> Date: Tue, 06 Mar 2001 01:10:45 +0100
> From: Christoph Plattner <chr...@do...>
> Organization: private
> To: Christoph Plattner <chr...@al...>
> CC: GRUB mailing list <bug...@gn...>,
>      eth...@li...
> References: <3A9...@al...> <200...@pc...> <3A9...@al...>
> 
> Further tested leads to following result in the problem described in the
> following lines.
> 
> If you all remember, I had the problem (and I already have it) that a
> multiboot kernel loaded at 0x00100000 and above crashes, if I boot GRUB
> itself via etherboot but booting GRUB from floppy, the kernel works
> well.
> 
> New experiments leads to following details:
> (1)     GRUB is NOT the problem
> (2)     Etherboot OR Netboot (Kuhlman) together with our kernel consequneces
>         in a crash.
> 
> Following experiment shows this:
> If I run etherboot (from ROM or floppy) and I select to load from local
> (L)
> disk, the GRUB is loaded locally from floppy and the kernel crashes.
> If I removed the boot rom (or boot floppy for etherboot) and boot GRUB
> again
> from the local floppy, the kernel boots.
> If I use netboot-0.9 by Kuhlman, I see the same effect like in
> etherboot.
> 
> Again. The problem is NOT the ethernet driver in etherboot/netboot. Our
> kernel
> does not access network at this time and not the here used NICs.
> Furhter the experiements are done with two different cards. I se
> etherboot via
> NE2000/ISA and GRUB via eepro100 (I also have the same effect using only
> one NIC).
> 
> The problem is a consequence of any setup of memory/BIOS stuff or
> whatever.
> There must be a initialization in the package (I don't mean init of NICs
> here),
> which is incomaptibe with this kernel (delivered from a known company
> ...) ...
> 
> Please etherboot developers and Netboot developers, help me here in
> finding a
> point of CPU/memory/Chipset/Bios initialization (I also will read
> sources),
> which can produce the problem.
> 
> And again. The problem also exists (!) if I use the option `L' for
> loading local
> from disk, so I do not use functionality of etherboot, only the fact,
> that it is
> started, the kernel crashes !!!
> 
> With friendly regards
> 
>         Christoph Plattner
> 
> Christoph Plattner wrote:
> >
> > Yes, a Linux kernel works, or seems to work. We don't know, if
> > there is a wrong byte in the code.....
> >
> > GRUB loads out multiboot kernel at 1MB and beyond.
> >
> >         Christoph P.
> >
> > -----------------------------------------------------------------
> > private:        chr...@do...
> > company:        chr...@al...
> >
> > Thierry Laronde wrote:
> > >
> > > On Thu, Feb 22, 2001 at 09:45:55AM +0100, Christoph Plattner wrote:
> > > > Hello GRUB and Etherboot people,
> > > >
> > > >       finally I had some time to further analysing the
> > > > problem, I describer a week ago.
> > > >
> > > > The problem was: I can boot our (company's) OS (multiboot,
> > > > loaded at 1MB) with a GRUB booted by floppy, kernel and
> > > > modules loaded via tftp (plus bootp before...)
> > >
> > > IIRC, you said that the problem doesn't appear with non multiboot kernels ?
> > > When you say "loaded at 1MB" you mean loaded in protected mode beyond 1MB ?
> > >
> > > Cheers,
> > > --
> > > Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
> > > http://www.cri74.org
> > > PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org
> > >
> > > _______________________________________________



-------------------------------------------------------------------------
private:	chr...@do...
company:	chr...@al...

Re: [Etherboot-developers] [Fwd: More analysis to the old problem with etherboot+GRUB (diskless/disk)]

[Ken Y. <ke...@nl...>]

|It seems, that I lost the mailing list registration.
|So I renewed it ans I resend the mail (see below) !

It's ok, we got it the first time.

Another thing you should check is whether the multiboot code enables the
A20 line when you jump to addresses > 1M. If not, it won't work.  The
code that jumps to Linux (first32.c) starts below 1M, and enables A20 so
it will work.

Crash course in A20: This is a awful compatibility hack in ATs and above
to do with the address line 20. Without enabling it, addresses above 1M
will not appear properly. Actually every alternate M will be mapped
wrong, IIRC.

Re: [Etherboot-developers] image file format and BIOS use

[Ken Y. <ke...@nl...>]

|I have another question - what is the purpose of the option manipulation
|done on nfsroot and ip options in the subst_value() code in
|mknbi-1.1/first32.c?

The simplistic answer is because that's how it was done in the original
mknbi (courtesy Markus and Gero).

The real answer is that it fills a need. If you look at the mknbi man
page, you can see three ways of filling the ip option: 1. Let the kernel
do another BOOTP/DHCP query (ip=dhcp) (my preferred way). 2. Inherit the
values from the Etherboot code (ip=rom). 3. Hardwire them (ip=....). A
similar argument applies to nfsroot. So depending on what your
infrastructure is like you can pick the appropriate way for the kernel
to get an identity.

It should be noted that ip= is a valid kernel parameter and independent
of network booting. mknbi only adds ip=rom.

[Etherboot-developers] (no subject)

[Eno C. <Eno...@Mi...>]

Dear List

Have built a kernel and got it to load. During init, it says, 

Looking up port of RPC 100003/2 on 192.168.1.1 
Root-NFS: Unable to get nfsd port number from server, using default


I am suspicious of this because my sniffer reports the rpc request and
response as follows

 002584            0.000.155.040  102 Linux Server     TNS-4 Front
Portmapper Procedure Name - 3 ( PMAPPROC_GETPORT ) Call
 002585            0.001.892.120   74 TNS-4 Front      Linux Server
Portmapper Procedure Name - 3 ( PMAPPROC_GETPORT ) Reply

which seems to indicate the server did as it was requested.

Can anyone tell me what this means and how I might proceed to overcome this
embarrassment?

thanks

Eno Compton

[Etherboot-developers] Fwd: Error in make

[Marty C. <md...@th...>]

Here's an interesting bug detected by rom-o-matic.net.

It appears this fellow is trying to generate a ROM image with -DANSIESC 
turned on.  All goes well until:

     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/ansiesc.o -c ansiesc.c
     ansiesc.c: In function `docommand':
     ansiesc.c:172: warning: implicit declaration of function `tftp'

which is here:

static void docommand(unsigned char ch)
{
  if (ch == '#') {      /* include file */
    if (!in_download) {
      in_download = 1;
      download(args[0],downloadmotd);  /* line 172 */
      in_download = 0; } }

now "download" is defined in etherboot.h as:

#ifndef DOWNLOAD_PROTO_NFS
#undef DOWNLOAD_PROTO_TFTP
#define DOWNLOAD_PROTO_TFTP     /* default booting protocol */
#endif

#ifdef  DOWNLOAD_PROTO_TFTP
#define download(fname,loader) tftp((fname),(loader))
#endif
#ifdef  DOWNLOAD_PROTO_NFS
#define download(fname,loader) nfs((fname),(loader))
#endif

unfortunately, there is no function prototype for tftp anywhere in sight, 
so we get the "implicit declaration error" noted above.  I'm guessing we 
need function prototypes for tftp() and nfs() in ansiesc.c.

later on we get:

     gcc -O2 -o bin/makerom makerom.c
     ld -N -Ttext 0x94000 -e _start -o bin32/3c90x.tmp bin32/start32.o
bin32/config-3c90x.o bin32/3c90x.o bin32/pci.o bin32/bootlib.a
     bin32/bootlib.a(ansiesc.o): In function `docommand':
     /tmp/ROM12QbeH/ansiesc.c:172: undefined reference to `tftp'
     make: *** [bin32/3c90x.tmp] Error 1
     make: Leaving directory `/tmp/ROM12QbeH'

One structural thought I had was to perhaps put the tftp code that is 
currently in main.c into its own file "tftp.c"  much like the nfs code is 
in "nfs.c", for modularity.  We'd still need function prototypes, of 
course.

Anyway, the option "-DANSIESC" seemed to trigger the problem.  Before I 
get too deep into debugging it, does anybody else want to give it a go?

Marty

---------------- Begin Forwarded Message ----------------
Date:        3/6/2001 2:40 AM
Received:    3/6/2001 2:52 AM
From:        pau...@sv...
To:          web...@en...

Build failed. Status = 2. 

Following is the output from make: 

     make: Entering directory `/tmp/ROM12QbeH'
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -DINCLUDE_3C90X -o bin32/3c90x.o
-c 3c90x.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -DINCLUDE_3C90X -o
bin32/config-3c90x.o -c config.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/pci.o -c pci.c
     /tmp/ccudNRVk.s: Assembler messages:
     /tmp/ccudNRVk.s:140: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:244: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:312: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:379: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:448: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:516: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:584: Warning: indirect lcall without `*'
     /tmp/ccudNRVk.s:656: Warning: indirect lcall without `*'
     gcc -E -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  start32.S | as  -o bin32/start32.o
     {standard input}: Assembler messages:
     {standard input}:360: Warning: indirect ljmp without `*'
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/main.o -c main.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/osloader.o -c osloader.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/nfs.o -c nfs.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/misc.o -c misc.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/ansiesc.o -c ansiesc.c
     ansiesc.c: In function `docommand':
     ansiesc.c:172: warning: implicit declaration of function `tftp'
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/bootmenu.o -c bootmenu.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/md5.o -c md5.c
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/floppy.o -c floppy.c
     gcc -E -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  serial.S | as  -o bin32/serial.o
     gcc -DIMAGE_MENU -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK
-DEMERGENCYDISKBOOT -DSIZEINDICATOR -DBACKOFF_LIMIT=7 -DELF_IMAGE
-DIMAGE_MULTIBOOT -DCONSOLE_CRT -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
-DCOMPARM=0x03 -DANSIESC -DGFX -DTRY_FLOPPY_FIRST=0
-DUSE_INTERNAL_BUFFER -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7
-DVERSION=\"4.7.21\" -DRELOC=0x94000  -o bin32/timer.o -c timer.c
     ar rv bin32/bootlib.a bin32/main.o bin32/osloader.o bin32/nfs.o
bin32/misc.o bin32/ansiesc.o bin32/bootmenu.o bin32/md5.o bin32/floppy.o
bin32/serial.o bin32/timer.o
     a - bin32/main.o
     a - bin32/osloader.o
     a - bin32/nfs.o
     a - bin32/misc.o
     a - bin32/ansiesc.o
     a - bin32/bootmenu.o
     a - bin32/md5.o
     a - bin32/floppy.o
     a - bin32/serial.o
     a - bin32/timer.o
     ranlib bin32/bootlib.a
     gcc -O2 -o bin/makerom makerom.c
     ld -N -Ttext 0x94000 -e _start -o bin32/3c90x.tmp bin32/start32.o
bin32/config-3c90x.o bin32/3c90x.o bin32/pci.o bin32/bootlib.a
     bin32/bootlib.a(ansiesc.o): In function `docommand':
     /tmp/ROM12QbeH/ansiesc.c:172: undefined reference to `tftp'
     make: *** [bin32/3c90x.tmp] Error 1
     make: Leaving directory `/tmp/ROM12QbeH'

Please let us know that this happened.

----------------- End Forwarded Message -----------------

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

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] [Fwd: More analysis to the old problem with etherboot+GRUB (diskless/disk)]

[Christoph P. <chr...@do...>]

It seems, that I lost the mailing list registration.
So I renewed it ans I resend the mail (see below) !

With friendly regards
	Christoph P.



-------------------------------------------------------------------------
private:	chr...@do...
company:	chr...@al...

[Etherboot-developers] Re: [Ltsp-discuss] Neighbour table overflow and 3com cards

[Marty C. <md...@th...>]

On 3/6/2001 9:48 AM Jim McQuillan ja...@Mc... wrote:
>It appears that the workstation is doing an arp request
>to get the mac address of the server.  

Sounds like the card is going deaf.  

I guess if I were going to debug this, I'd first ask questions like:

- Does it happen with just this card, or with all 3C905Cxxxxx cards?

- Does it happen when you switch CAT 5 cables?

- Does it happen when you switch hubs?

- Have you power-cycled the hub/switch in between tests?

- Is loopback properly configured in the kernel?

I'm sure you've probably checked those things already.

What I find interesting here is that the kernel loads properly, which 
suggests that Etherboot managed to get the information it needed.  It 
sounds like the kernel is having trouble either initializing the card or 
talking to it afterwards.

This somewhat begs the question of whether the kernel code is fresh and 
wholesome.  I know for example that the vmlinuz.all kernel on ltsp.org 
fails to boot my rtl8139 card, but the vmlinuz.rtl8139 works.

So I guess I'd try another version of the kernel to see if that helps.

Now turning to the possibility that Etherboot is leaving the card in a 
state that makes the kernel unable to hear, I'd also ponder the 
consequences of this code (or lack thereof) in 3c90x.c in the Etherboot 
code:

/*** a3c90x_disable: exported routine to disable the card.  What's this 
for?
 *** the eepro100.c driver didn't have one, so I just left this one empty 
too.
 *** Ideas anyone?
 ***/
static void
a3c90x_disable(struct nic *nic)
    {
    }

Note that since that comment was written, eepro100.c has been changed:

static void eepro100_disable(struct nic *nic)
{
    /* See if this PartialReset solves the problem with interfering with
       kernel operation after Etherboot hands over. - Ken 20001102 */
    outl(2, ioaddr + SCBPort);
}

and tulip.c does:

static void tulip_disable(struct nic *nic)
{
  whereami("tulip_disable\n");

  /* disable interrupts */
  outl(0x00000000, ioaddr + CSR7);

  /* Stop the chip's Tx and Rx processes. */
  outl(inl(ioaddr + CSR6) & ~0x00002002, ioaddr + CSR6);

  /* Clear the missed-packet counter. */
  (volatile unsigned long)inl(ioaddr + CSR8);
}

Which suggests that in 3c90x.c something like:

static void
a3c90x_disable(struct nic *nic)
    {
    /** Send the reset command to the card **/
    a3c90x_internal_IssueCommand(INF_3C90X.IOAddr, cmdGlobalReset, 0);
    /** wait for reset command to complete **/
    while (inw(INF_3C90X.IOAddr + regCommandIntStatus_w) & 
INT_CMDINPROGRESS);
    }

might just help things along.  It's probably overkill, since other 
drivers seem to just disable RX and TX and clear interrupt masks, but 
worth a shot.

Let us know if this does anything interesting.

Marty

P.S.  We might want to check all drivers for this, since it has now been 
added to tulip and eepro100, and I am wondering if the leaving the 
receiver on after Etherboot is gone could lead to a card randomly writing 
in memory that doesn't belong to it, possibly corrupting a loaded OS or 
loader.  

The rtl8139 driver for example still does:

static void rtl_disable(struct nic *nic)
{
}

I suspect as a rule we should really reset cards before handing control 
over to another program.  Seems only fair :-)


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

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] image file format and BIOS use

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

> Thanks very much to Ken and Markus for the replies, they were a big help.
> 
> I have another question - what is the purpose of the option manipulation
> done on nfsroot and ip options in the subst_value() code in
> mknbi-1.1/first32.c?

This probably makes more sense after having a look at the manual
page mknbi.1. You see that for both of these options you can 
pass in the value "rom". If you do, then the parameters received
by DHCP will be passed on to the kernel. As these values are not
known at the time when the image is built, we have to substitute
the neccessary data at run time.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

[Etherboot-developers] Neighbour table overflow and 3com cards

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

I've seen many messages about 'Neighbour Table Overflow'
on this list.

I did just a very little bit of testing, but I have found
the following:

1) The 3c905b-tx-nm works fine.

2) The 3c905cx-txm has the 'Neighbour' problem.

3) The kernel loads fine, initializes the card and
   then when it goes to find the RPC port for 'nfsd'
   it can't get a response. 

4) If you run tcpdump on the server, you will see:

      arp who-has server.mimss.com tell ws002.mimss.com
      arp reply server.mimss.com is-at 0:60:8:bf:e6:2e
      arp who-has server.mimss.com tell ws002.mimss.com
      arp reply server.mimss.com is-at 0:60:8:bf:e6:2e
      arp who-has server.mimss.com tell ws002.mimss.com
      arp reply server.mimss.com is-at 0:60:8:bf:e6:2e

It appears that the workstation is doing an arp request
to get the mac address of the server.  The server is replying,
but the workstation isn't receiving or processing the reply
properly.  So, it sends the request again, for a total of
3 times.  Then when it fails, you see a 
'neighbour table overflow' message on the screen of the
workstation.

So, any network driver hackers out there have any ideas?

Thanks,
Jim McQuillan
ja...@lt...

Re: [Etherboot-developers] image file format and BIOS use

[Robb M. <ma...@ac...>]

(This is closely enough related it might be of interest...)

I just got the following link from slashdot.  It describes the LinuxBIOS
project, which aims to replace the PC BIOS with a minimal configuration for
booting a Linux kernel from NVRAM. It then relies on the Linux Kernel for
"proper" configuration of the hardware.

See: http://www.acl.lanl.gov/linuxbios/

Good Luck,
Robb Main.

----- Original Message -----
From: "Tania Oka" <ta...@ce...>
To: <eth...@li...>
Sent: Tuesday, March 06, 2001 7:14 AM
Subject: Re: [Etherboot-developers] image file format and BIOS use


> Thanks very much to Ken and Markus for the replies, they were a big help.
>
> I have another question - what is the purpose of the option manipulation
> done on nfsroot and ip options in the subst_value() code in
> mknbi-1.1/first32.c?
>
>
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] image file format and BIOS use

[Tania O. <ta...@ce...>]

Thanks very much to Ken and Markus for the replies, they were a big help.

I have another question - what is the purpose of the option manipulation
done on nfsroot and ip options in the subst_value() code in
mknbi-1.1/first32.c?

Re: [Etherboot-developers] image file format and BIOS use

[Ken Y. <ke...@nl...>]

|If I remember correctly, there really shouldn't be that many BIOS
|calls in that code. Off the top of my head you have:
|
| - calls to output messages to the screen; you can probably remove
|   those.
|
| - calls to determine the maximum memory size. Since you know your
|   hardware, you can either hardcode this value or you can provide
|   your own code to determine the memory size.
|
| - code to move the ramdisk image around in extended memory. Since
|   the code executes in real mode, we have to ask the BIOS to do this
|   for us. You can either remove support for ramdisks, or you can
|   manipulate the memory descriptors yourself and then write your
|   own code for moving the image.
|
|I believe, that's it. I am sure, somebody will correct me if I am
|wrong.

Yes, that's about it. Except in mknbi-1.1 ramdisk copying is no longer
done by a BIOS call, it's done by longword copying since first32.c
executes in protected mode. It also allows ramdisks to be above 16MB,
one reason for using mknbi-1.1.

Re: [Etherboot-developers] image file format and BIOS use

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

> I think I can handle the needs of the Etherboot code itself, but it
> looks like the mknbi-linux program prepends code which uses BIOS calls
> to the linux kernel image.  (Please correct me if I'm wrong, I haven't
> studied it thoroughly yet.)  I would prefer to avoid the extra BIOS
> support if possible.

If I remember correctly, there really shouldn't be that many BIOS
calls in that code. Off the top of my head you have:

 - calls to output messages to the screen; you can probably remove
   those.

 - calls to determine the maximum memory size. Since you know your
   hardware, you can either hardcode this value or you can provide
   your own code to determine the memory size.

 - code to move the ramdisk image around in extended memory. Since
   the code executes in real mode, we have to ask the BIOS to do this
   for us. You can either remove support for ramdisks, or you can
   manipulate the memory descriptors yourself and then write your
   own code for moving the image.

I believe, that's it. I am sure, somebody will correct me if I am
wrong.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

Re: [Etherboot-developers] image file format and BIOS use

[Ken Y. <ke...@nl...>]

|Isn't there another one called multiboot?  As for ELF, I will look for the

Multiboot is just a variant of ELF or a.out.

|documentation, but could anyone give me a brief description how it works
|regarding specifying parameters to be passed to the kernel (i.e. command
|line, initrd parameters)?

This explanation is valid for both ELF and tagged images, the only
difference between the types is the structure of the directory and the
segments:

The initial kernel parameters are specified to mknbi or mkelf. This is
stored in a segment of the image and loaded to 0x93400 (check first32.c
or mknbi for exact address). Etherboot then passes control to first32.c.
first32.c adds any string in tag 129 of the BOOTP/DHCP structure
(provided tag 128 is present and correct). It then scans the string for
special parameters: vga=, nfsroot=, and ip= then does the appropriate
substitution if it finds these. Other parameters are passed unchanged.
It then writes the offset of the parameter block from the floppy boot
sector (loaded at 0x90000) i.e. a 16 bit value, into a field inside the
floppy boot sector. This is the standard way the Linux kernel finds the
parameters. Finally first32.c relocates the ramdisk image, if any,
to the top of memory, and tells the kernel where this is by writing a
longword inside the setup segment of the Linux kernel.

The code you should read is, of course, first32.c. The low level
functions are in start32.S. Of course, you should start with mknbi-1.1,
not mknbi-1.0.

|Do you mean mkbni-linux adds code which calls the PCI BIOS?  (As opposed to
|BIOS calls in the Etherboot code.)

No, PCI BIOS support is only needed in Etherboot, not in first32.c.

|kernel.  But am I correct in assuming that mknbi-linux adds code which
|contains calls to the BIOS which is NOT part of the kernel image but which
|is expected to be executed at the time Etherboot passes control to the code
|in the file it downloaded?  Sorry for the long sentence :)

Yes, that's how it happens. first32.c does a bit of housekeeping before
chaining to Linux.

You might want to read the developers manual, link is from the Etherboot
home page. It's still work in progress and if there is anything you
don't understand, tell me and I know what more to write about.

Re: [Etherboot-developers] image file format and BIOS use

[Tania O. <ta...@ce...>]

Hi again

Thanks for the reply.

> Etherboot supports three loading formats, tagged, ELF and a.out. I'd
> forget about a.out. Tagged is specified in the documentation, ELF in a
> standards document from somewhere. Either one will fit your needs. Your

Isn't there another one called multiboot?  As for ELF, I will look for the
documentation, but could anyone give me a brief description how it works
regarding specifying parameters to be passed to the kernel (i.e. command
line, initrd parameters)?

> time of day, and sizing memory, if I recall correctly. You'll also need
> PCI BIOS support if you have PCI Ethernet controllers.

Do you mean mkbni-linux adds code which calls the PCI BIOS?  (As opposed to
BIOS calls in the Etherboot code.)

> BTW, the BIOS calls are not *to* to the Linux kernel as you assume. The
> Linux kernel is not executing yet at that point. The BIOS calls are to
> the BIOS ROM.

I certainly didn't mean to imply that I thought BIOS calls were to the linux
kernel.  But am I correct in assuming that mknbi-linux adds code which
contains calls to the BIOS which is NOT part of the kernel image but which
is expected to be executed at the time Etherboot passes control to the code
in the file it downloaded?  Sorry for the long sentence :)

Thanks again.

Re: [Etherboot-developers] image file format and BIOS use

[Ken Y. <ke...@nl...>]

|I see there are a lot of different image formats supported by the

More correctly, different target OSes.

|Etherboot code.  So far I have only seen the documentation for the
|tagged image format (mknbi) available via the Etherboot home page.  Can
|anyone give me suggestions/ideas on the best file format to use or the
|best way to go about this?  Basically the kernel file I want to boot is
|a plain vmlinux, except I need a way to specify kernel parameters (i.e.
|command line).  Also if you could point me to any links which describe
|the other file formats I would appreciate it.

Etherboot supports three loading formats, tagged, ELF and a.out. I'd
forget about a.out. Tagged is specified in the documentation, ELF in a
standards document from somewhere. Either one will fit your needs. Your
problem is really to change the startup routines to avoid/replace the
BIOS calls you don't have. For this look in mknbi/first32.C and the
assembler routines it calls. The BIOS calls used are for console I/O,
time of day, and sizing memory, if I recall correctly. You'll also need
PCI BIOS support if you have PCI Ethernet controllers.

BTW, the BIOS calls are not *to* to the Linux kernel as you assume. The
Linux kernel is not executing yet at that point. The BIOS calls are to
the BIOS ROM.

[Etherboot-developers] image file format and BIOS use

[Tania O. <ta...@ce...>]

Hi

I need some advice.  I want to use Etherboot to boot linux on a custom
board which does not have a standard BIOS.  Basically I have to write
those portions of the BIOS needed.  If the arch/i386/boot code is
omitted from the linux kernel, the BIOS needs of linux are minimal, and
I think I can handle the needs of the Etherboot code itself, but it
looks like the mknbi-linux program prepends code which uses BIOS calls
to the linux kernel image.  (Please correct me if I'm wrong, I haven't
studied it thoroughly yet.)  I would prefer to avoid the extra BIOS
support if possible.

I see there are a lot of different image formats supported by the
Etherboot code.  So far I have only seen the documentation for the
tagged image format (mknbi) available via the Etherboot home page.  Can
anyone give me suggestions/ideas on the best file format to use or the
best way to go about this?  Basically the kernel file I want to boot is
a plain vmlinux, except I need a way to specify kernel parameters (i.e.
command line).  Also if you could point me to any links which describe
the other file formats I would appreciate it.

Thanks for your time,
Tania

Re: [Etherboot-developers] Re: More analysis to the old problem with etherboot+GRUB (diskless/disk)

[Ken Y. <ke...@nl...>]

|Please etherboot developers and Netboot developers, help me here in
|finding a
|point of CPU/memory/Chipset/Bios initialization (I also will read
|sources),
|which can produce the problem.
|
|And again. The problem also exists (!) if I use the option `L' for
|loading local
|from disk, so I do not use functionality of etherboot, only the fact,
|that it is
|started, the kernel crashes !!!

Does your kernel set up its own GDT and IDT immediately?

[Etherboot-developers] Re: More analysis to the old problem with etherboot+GRUB (diskless/disk)

[Christoph P. <chr...@do...>]

Further tested leads to following result in the problem described in the 
following lines.

If you all remember, I had the problem (and I already have it) that a
multiboot kernel loaded at 0x00100000 and above crashes, if I boot GRUB
itself via etherboot but booting GRUB from floppy, the kernel works
well.

New experiments leads to following details:
(1)	GRUB is NOT the problem
(2)	Etherboot OR Netboot (Kuhlman) together with our kernel consequneces
	in a crash.

Following experiment shows this:
If I run etherboot (from ROM or floppy) and I select to load from local
(L)
disk, the GRUB is loaded locally from floppy and the kernel crashes.
If I removed the boot rom (or boot floppy for etherboot) and boot GRUB
again
from the local floppy, the kernel boots.
If I use netboot-0.9 by Kuhlman, I see the same effect like in
etherboot.

Again. The problem is NOT the ethernet driver in etherboot/netboot. Our
kernel
does not access network at this time and not the here used NICs. 
Furhter the experiements are done with two different cards. I se
etherboot via
NE2000/ISA and GRUB via eepro100 (I also have the same effect using only
one NIC).

The problem is a consequence of any setup of memory/BIOS stuff or
whatever. 
There must be a initialization in the package (I don't mean init of NICs
here), 
which is incomaptibe with this kernel (delivered from a known company
...) ...

Please etherboot developers and Netboot developers, help me here in
finding a
point of CPU/memory/Chipset/Bios initialization (I also will read
sources),
which can produce the problem.

And again. The problem also exists (!) if I use the option `L' for
loading local
from disk, so I do not use functionality of etherboot, only the fact,
that it is
started, the kernel crashes !!!

With friendly regards

	Christoph Plattner



Christoph Plattner wrote:
> 
> Yes, a Linux kernel works, or seems to work. We don't know, if
> there is a wrong byte in the code.....
> 
> GRUB loads out multiboot kernel at 1MB and beyond.
> 
>         Christoph P.
> 
> -----------------------------------------------------------------
> private:        chr...@do...
> company:        chr...@al...
> 
> Thierry Laronde wrote:
> >
> > On Thu, Feb 22, 2001 at 09:45:55AM +0100, Christoph Plattner wrote:
> > > Hello GRUB and Etherboot people,
> > >
> > >       finally I had some time to further analysing the
> > > problem, I describer a week ago.
> > >
> > > The problem was: I can boot our (company's) OS (multiboot,
> > > loaded at 1MB) with a GRUB booted by floppy, kernel and
> > > modules loaded via tftp (plus bootp before...)
> >
> > IIRC, you said that the problem doesn't appear with non multiboot kernels ?
> > When you say "loaded at 1MB" you mean loaded in protected mode beyond 1MB ?
> >
> > Cheers,
> > --
> > Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
> > http://www.cri74.org
> > PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org
> >
> > _______________________________________________
> > Bug-grub mailing list
> > Bug...@gn...
> > http://mail.gnu.org/mailman/listinfo/bug-grub
> 
> --
>   +--------V--------+   Chr...@al...
>   |  A L C A T E L  |   -----------------------------
>   +-----------------+   Phone: +43 1 27722 3706
>          T A S          Fax:   +43 1 27722 3955
> 
> _______________________________________________
> Bug-grub mailing list
> Bug...@gn...
> http://mail.gnu.org/mailman/listinfo/bug-grub

-- 
-------------------------------------------------------------------------
private:	chr...@do...
company:	chr...@al...

[Etherboot-developers] rom-o-matic.net updated with Etherboot 4.7.21

[Marty C. <md...@en...>]

I have updated http://rom-o-matic.net/ with Etherboot 4.7.21 (5.0RC1).

As this is a release candidate for a major new version, we are asking 
everyone who is able to download a ROM image and test it for us.

Using the rom-o-matic, you can simply select your ROM, download it, and 
then do:

   cat eb-4.7.21-yournic.lzdsk > /dev/fd0

which will make you a bootable floppy with the etherboot driver for your 
card on it.

Every report is appreciated.

Marty


---
      Martin D. Connor, CEO & President, Entity Cyber, Inc.
       US Mail: P.O. Box 391827, Cambridge, MA 02139  USA
   Voice: (617) 491-6935, Fax: (617) 491-7046, Net: md...@en...
                     Web: http://www.entity.com/

[Etherboot-developers] Etherboot 4.7.21 (5.0RC1) released

[Ken Y. <ke...@nl...>]

I have released Etherboot 4.7.21 at http://etherboot.sourceforge.net

Changes in this release:

+ I changed my mind. I think the format in disrom.pl should be Z32,
otherwise it displays binary characters after the valid part of the
string. For people with Perl < 5.005, please upgrade.

+ Moved RELOC down to 0x94000. Turned on USE_INTERNAL_BUFFER by default.
Unless BOOTP_DATA_AT_0x93C00 is defined, use internal bootp strucutre.
This gets Etherboot out of the area just below 0x10000 and the area from
0x93C00-0x93FFF. DHCP packets can now be as large as the Ethernet
payload. Later on, first32.c and the parameter area could expand a bit.
In lance.c had to reduce RX_RING_SIZE (by reducing LANCE_LOG_RX_BUFFERS)
from 16 to 4 to fit the driver. I'd like to hear feedback from lance
users. Is 24kB of receive buffers really needed given that Etherboot
uses stop-wait protocols?

+ Doug Ambrisko sent in some patches for FreeBSD: a correction for one
typo I missed and changes to make compilation under FreeBSD easier.

+ Michael Sinz contributed patches to allow the FreeBSD loading code to
load debugging symbols also.

+ Marty Connor contributed a SiS900 driver. Also pointed out that if
ASK_BOOT <= 0, the prompt and read shouldn't even happen. Conditional
code reworked.

+ Split documentation into user manual and developer manual. Added
material.

MD5 sums:

83278b41f8d20404a71b4e91c2f2440a  etherboot-4.7.21.tar.bz2
04d5da6ec2fc8f5ea0d188752e1624b7  etherboot-4.7.21.tar.gz

[Etherboot-developers] SIS900 etherboot driver

[David C. <dav...@rc...>]

Dear all,

I am about to start my development on sis900 etherboot driver. Just want =
to
ask did any one already have the bootrom for sis900? I heard Andrew =
Gillham
<gi...@va...> developing his own driver for the sis900 I am
wondering did anybody finally get through? I am looking for guys who =
wish to
join development on the driver together so that we can discuss and find
something cool. Thanks for reading.

David