etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

Zameer Ahmed <za...@sy...> writes:

> Hi Eric,
> 
> >But you say it appears to lock up?  Hmm....
> >Confirmation that etherboot actually locks up, (no response to esc)
> >as opposed to something else would be interesting.
> 
> I meant unresponsive. Pardon my English. When I press Esc, the etherboot
> fires again and probes the card successfully and prints the following message.
> 
> {Start of messages}
<snip> 
> {End of Messages}

So the driver finds the link, and it thinks everything is fine.

> >Which version of the linux driver work?
> I installed RH8.0 and the default kernel seems to work.
> ver 2.4.18-14
> 
> <snip>
> [root@lion root]# lsmod | grep e1000
> e1000                  55916   1
> [root@lion root]# uname -a
> Linux lion 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
> </snip>
> 
> >What is the PCI ID?  i.e. the very specific model.
> Here it is ..

lspci -n gives the information I was looking for.
I expect it is 8086:100e, but I am not certain.

> >What kind of switch are you plugged into, and how fast is it?
> Its a small home style brewed network. Only Linksys hubs in the picture.

I wonder if there are some problems working with hubs.  I haven't
tried it on anything less than a 10/100 switch.   Is this a 10Mbit hub
or a 100Mbit hub?

> 
> Summarizing.
> As a standalone Linux clien, the machine has no problems getting its DHCP
> address of the server. It fails when booted via etherboot. 
> 
> Method of booting Etherboot : CD Image (These dells lack a floppy drive)

No big deal except it makes changes a little harder to test.

There is a
#define DEBUG 0
at the top of file.  Could you change that to 
#define DEBUG 3

And then send the output?

I don't know that the debugging information would help but since it is not obvious
what is wrong that is all there is to debug with at the moment.

Eric

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

[Zameer A. <za...@sy...>]

Hi Eric,

>But you say it appears to lock up?  Hmm....
>Confirmation that etherboot actually locks up, (no response to esc)
>as opposed to something else would be interesting.

I meant unresponsive. Pardon my English. When I press Esc, the etherboot
fires again and probes the card successfully and prints the following message.

{Start of messages}

Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[E1000]Ethernet addr: 00:08:74:A3:D2:B3

Searching for server (DHCP)...
{Pressing Esc}
<abort>
Probing pci nic...

Probing isa nic...

No adapter found
<sleep>
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[E1000]Ethernet addr: 00:08:74:A3:D2:B3

Searching for server (DHCP)...


{End of Messages}

>Which version of the linux driver work?
I installed RH8.0 and the default kernel seems to work.
ver 2.4.18-14

<snip>
[root@lion root]# lsmod | grep e1000
e1000                  55916   1
[root@lion root]# uname -a
Linux lion 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
</snip>

>What is the PCI ID?  i.e. the very specific model.
Here it is ...
01:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller
(rev 02)

The full listing is here....
<snip>
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge
(rev 01)
00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G]
Chipset Integrated Graphics Device (rev 01)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 01)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 01)
01:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller
(rev 02)
</snip>

>Is this copper or fiber?
Normal RJ45 connector so its copper.

>What kind of switch are you plugged into, and how fast is it?
Its a small home style brewed network. Only Linksys hubs in the picture.


Summarizing.
As a standalone Linux clien, the machine has no problems getting its DHCP
address of the server. It fails when booted via etherboot. 

Method of booting Etherboot : CD Image (These dells lack a floppy drive)

Re: [Etherboot-developers] [Q] How do we pass options to the DHCP server, are we failing?

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

> I am currently trying to get a grip on how we are passing options
> to the DHCP server, and I think there are some problems, but I don't
> quite get how we are encoding the options.
> 1) We do not pass the NIC vendor and device id in the DHCP discover,
>    only in the DHCP request.  If anything it should be the other way
>    around.
> 2) I need pass the architecture etherboot is running on so I can
>    magically serve up an image that will boot.  The plan is to extend
>    how we are passing the NIC id's, add another tag type, and pass
>    the ELF architecture type, we need it anyway for other reasons.
>    But the code is a little convoluted, and a first glance I don't get
>    how we are passing the NIC vendor and device ids.
>    Could someone give me a quick synopsis, of how we intend to be passing
>    the NIC vendor and device ids?

The original code was cleaner but apparently took up more space.  It's
fairly straightforward: the DHCP request packet includes an option 175
which is a binary option with the structure:

  Bus type (1 byte) : 1=PCI, 2=ISA
  Vendor id (2 bytes)
  Device id (2 bytes)

This is enclosed within an Etherboot encapsulated options field (i.e. an
option 150) in order to avoid pollution of the DHCP option namespace.

This data must be present in the DHCP request.  It could be included in
the DHCP discover as well with no ill effects.  It must be in the DHCP
request because the contents of the DHCP acknowledge will be derived from
the DHCP request (since DHCP is a stateless protocol).  Since the DHCP
acknowledge includes the TFTP filename, which is the part most likely to
depend upon the PCI IDs, it is mandatory for the PCI IDs to be included in
the DHCP request.

Feel free to tidy up the code but please don't change the data structures;
there are by now plenty of production systems that rely on it.  You can
add other Etherboot-specific DHCP options within the encapsulated options
field, but if you change the structure of option 150 then you will be
breaking things.

Michael

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

[Peter L. <P.L...@sy...>]

Congratulations Matthew.

> Great. If you like reading the PXE spec, maybe you can do Etherboot on top of
> PXE's UNDI without using an Etherboot's native network driver :).

The Etherboot driver would in fact be written for PXE's *UDP* interface,
not UNDI. Eric B pointed out my loose terminology: no-one needs UNDI per
se unless genuinely implementing a new network protocol (not UDP/IP). We
want the PXE driver abstraction, but we don't have to use it directly.

> This, of course, is an option in addition to using the native driver.

A generic image with multiple drivers could use PXE as a default: it is
fine for simple cases and new hardware; anyone who finds it restrictive
(e.g. by having multiple NICs or wanting better multicast) can load the
native driver for the nic(s) via tftp. That way everyone is happy. :)

[Etherboot-developers] [Q] How do we pass options to the DHCP server, are we failing?

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

I am currently trying to get a grip on how we are passing options
to the DHCP server, and I think there are some problems, but I don't
quite get how we are encoding the options.

1) We do not pass the NIC vendor and device id in the DHCP discover,
   only in the DHCP request.  If anything it should be the other way
   around.

2) I need pass the architecture etherboot is running on so I can
   magically serve up an image that will boot.  The plan is to extend
   how we are passing the NIC id's, add another tag type, and pass
   the ELF architecture type, we need it anyway for other reasons.
   But the code is a little convoluted, and a first glance I don't get
   how we are passing the NIC vendor and device ids.  

   Could someone give me a quick synopsis, of how we intend to be passing
   the NIC vendor and device ids?


   

[Etherboot-developers] [COMMIT] More portability changes...

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

Except for osloader.c I think I have all of the major portability
changes made.  Small tweaks will still be needed for the itanium, but
that is another matter...

And it is time I call it enough for a night.

Eric

[Etherboot-developers] [COMMIT] More portability changes...

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

Except for osloader.OS loader I think I have all of the major portability
changes made.  Small tweaks will still be needed for the itanium.

[Etherboot-developers] [COMMIT] Timer generalization

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

The x86 specific bits of the timer code are now split out into
their own seperate file...

Eric

[Etherboot-developers] [COMMIT] itanium build changes...

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

So far no code changes, just build changes but I have now checked in
the new directory structure for etherboot.

At a quick glance everything appears to be building correctly, though
I think I may have mangled the default configuration a little bit...

The next couple of changes will be walking through and removing 
x86 assumptions from some of the generic code, but etherboot should
continue to work.  

I have added the tag Eb_5_1_4pre1 so if someone needs to see if
my further changes broke their code they can.

As an interesting note the etherboot build system has now been flipped
inside out:  With the Config file including the Makefile...
It now goes:

Makefile -> arch/i386/Config -> Config -> Makefile.main -> arch/i386/Makfile

With the top level makefile just auto detecting the architecture and including
the appropriate makefile.

The change in compile defaults when we are on FreeBSD has moved into arch/i386/Config
instead of being in the Makefile proper.

Eric

[Etherboot-developers] [COMMIT] Add directories...

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

The first stage of the itanium port is now comitted all of the files
have been moved to their new homes.

The next step is to get the code to compile again, which entails
some changes to the build process.

Eric

[Etherboot-developers] Intanium changes coming....

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

Source forge appears terribly overloaded at the moment,
but I have started the processes of checking in my itanium changes.

The first step is to add the new directory structure and move the files to
where the belong in it.

Eric

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

Zameer Ahmed <za...@sy...> writes:

> The following is my dhcp entry for the card.
> 
>  host ws001 {
>          hardware ethernet     00:08:74:a3:d2:b3;
> 	         fixed-address         192.168.128.200;
> 		         filename "/tftpboot/lts/vmlinuz-2.4.19-ltsp-1";
> 
> 			         #option option-128     e4:45:74:68:00:00;
> #This is NOT a MAC address
>         #option option-129     "NIC=eepro100";
> 	
> I ran a tcp dump as well. There seems to be no request, ALso if teh client
> doesn't find a IP giver, it should  loop no? Here it just gets stuck, after
> identiying the card and the MAC address of it.
> 
> Does anything else nneds to be checked?

O.k. So this is more than the just a simple misconfiguration.

What I would expect is something like:
Searching for server (DHCP)...

With the number of dots going up on attempted retransmits.
pressing escape tends to restart the process.

But you say it appears to lock up?  Hmm....
Confirmation that etherboot actually locks up, (no response to esc)
as opposed to something else would be interesting.

Which version of the linux driver works?
What is the PCI ID?  i.e. the very specific model.

Is this copper or fiber?

What kind of switch are you plugged into, and how fast is it? 

I seem to remember 1 success report and 1 failure, on this board.

Eric

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

Zameer Ahmed <za...@sy...> writes:

> Hi, 
>  I tried the e1000-82540em driver with the one bundled with 5.1.3 from
> www.rom-o-matic.com. The card is detected, but there is no DHCP requesp from
> the client. I confirmed this by intalling a Linux install on the hardisk on
> the machine and then DHCPing for the address. It succeded as expected. 
> 
> Is there any way I can get the etherboot to work properly for this card?
> This card comes with Dell Optiplex SX260 and lspci gives the following
> listing :
> 
> 01:0c:0 Ethernet Controller: Intel Corp, 82540EM Gigabit Ethernet Controller
> (rev 02)
> 
> Any help/suggestions will be highy appertiated.

The driver setup is almost exactly from the current intel driver.
If you could do a tcpdump, or use a similar network sniffer and confirm
the dhcp packet is not actually sent that would say something.

My best hunch is that you are not specifying a filename in the dhcp response.

Until I have evidence to the contrary I believe you have not properly configured your
server.

Eric

[Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

[Zameer A. <za...@sy...>]

Hi, 
 I tried the e1000-82540em driver with the one bundled with 5.1.3 from
www.rom-o-matic.com. The card is detected, but there is no DHCP requesp from
the client. I confirmed this by intalling a Linux install on the hardisk on
the machine and then DHCPing for the address. It succeded as expected. 

Is there any way I can get the etherboot to work properly for this card?
This card comes with Dell Optiplex SX260 and lspci gives the following
listing :

01:0c:0 Ethernet Controller: Intel Corp, 82540EM Gigabit Ethernet Controller
(rev 02)

Any help/suggestions will be highy appertiated.

Thanks,
Zameer A.

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

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

Vasil Vasilev <vas...@sy...> writes:

> Great. I knew about the problem, but couldn't find the way to fix, PXE spec
> being a bit patchy.
> 
> On Wed, 11 Dec 2002, Matthew Stapleton wrote:
> 
> > Hi all,
> >   I just fixed the problem where trying to boot dos by chaining from PXE to
> > EtherBoot to dos crashes the system in EtherBoot 5.0.8.  Also, on my system
> > once PXE had loaded EtherBoot, going to local boot to load dos would crash
> > during dos loading as well.
> >
> >   In version 2.1 of the PXE Specification, in the UNDI_STARTUP service
> > description, it says that 'PXENV_UNDI_STARTUP and PXENV_UNDI_SHUTDOWN are no
> > longer responsible for chaining interrupt 1Ah.  This must be done by the
> > PXENV_START_UNDI and PXENV_STOP_UNDI calls.'  Since loader.S only uses
> > PXENV_UNDI_SHUTDOWN and PXENV_UNLOAD_STACK, the interrupt doesn't get
> > unhooked.  If dos or EtherBoot or any other images load over the PXE
> > interrupt handler, then when int 1Ah gets called, the system will crash.
> 
> Yes, this is indeed the problem. Well spotted in the PXE spec as well. The
> first implementation wasn't releasing part of the UNDI memory of PXE to get
> round this, but then DOS apps were running out of memory.
> 
> > The way I fixed this was to add a call to PXENV_STOP_UNDI.  Other ways to
> 
> This sounds the right way.
> 
> > fix this would be to relocate EtherBoot code to other areas or not release
> > the PXE memory to the system.
> 
> Could do, but see above. Still if any part of PXE refuses to unload, the
> memory shouldn't be released...

With respect to relocating etherboot it should work much more easily on
the development branch.

> > How should I submit the changes to the code or has this problem already been
> > fixed?
> >
> > I also rewrote the hex to ascii routines that display the amount of free
> > memory in the PXE loader.  The current routines don't seem to work properly.
> 
> The idea here was debugging, but the pretier the better as long it doesn't
> much memory and fits within the memory model.
> 
> > I tested this fix with EtherBoot 5.0.7 and EtherBoot 5.0.8.
> > The network card used is an Intel EtherExpress PRO/100+ Management Adapter
> > using the eepro100 driver.
> > The versions of dos tested were Windows 98 SE MS-DOS and FreeDOS Kernel
> > 2.0.27.
> > Both doses crashed before the fix.  Now they work!!! :)
> 
> Great. If you like reading the PXE spec, maybe you can do Etherboot on top of
> PXE's UNDI without using an Etherboot's native network driver :). This, of
> course, is an option in addition to using the native driver.

We should certainly verify the code still works on the development branch.
There have been a number of changes in how all of the pieces fit together.
It should not be to hard, but it does take a little bit of work.

Eric

Re: [Etherboot-developers] Re: LinuxBIOS ROM Image problem..

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

Marty Connor <md...@et...> writes:

> Vladimir,
> 
> Thanks for your report. We are looking into how to set options appropriately for
> 
> LinuxBIOS and ELF format builds, while still allowing customization. We hope to
> have a fix soon. We apologize for the inconvenience.
> 
> Developers: Has anyone successfully generated a LinuxBIOS format ROM image from
> rom-o-matic.net? What options did you use?

Looking at the options:

-DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK 
-DMOTD 
-DIMAGE_MENU 
-DCONGESTED
-DBACKOFF_LIMIT=7 
-DTRY_FLOPPY_FIRST=0 
-DTAGGED_IMAGE 
-DELF_IMAGE
-DDOWNLOAD_PROTO_TFTP 
-DCOMCONSOLE=0x3F8 
-DCONSPEED=9600 
-DCOMPARM=0x03
-DPCBIOS


This is a request for an ELF format etherboot that has PCBIOS support.
This should work on the development branch.  But it does not/can not
work on the stable branch.

Something like:

-DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK 
-DCONGESTED
-DBACKOFF_LIMIT=7 
-DELF_IMAGE
-DDOWNLOAD_PROTO_TFTP 
-DCONSOLE_SERIAL
-DCOMCONSOLE=0x3F8 
-DCONSPEED=9600 
-DCOMPARM=0x03
-DCONFIG_TSC_CURRTICKS  
-DCONFIG_PCI_DIRECT
-DLINUXBIOS

Should work,  I have not tested this configuration but it should
be quite close.

I am about to go break the developer version again....

Eric

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

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

Great. I knew about the problem, but couldn't find the way to fix, PXE spec
being a bit patchy.

On Wed, 11 Dec 2002, Matthew Stapleton wrote:

> Hi all,
>   I just fixed the problem where trying to boot dos by chaining from PXE to
> EtherBoot to dos crashes the system in EtherBoot 5.0.8.  Also, on my system
> once PXE had loaded EtherBoot, going to local boot to load dos would crash
> during dos loading as well.
>
>   In version 2.1 of the PXE Specification, in the UNDI_STARTUP service
> description, it says that 'PXENV_UNDI_STARTUP and PXENV_UNDI_SHUTDOWN are no
> longer responsible for chaining interrupt 1Ah.  This must be done by the
> PXENV_START_UNDI and PXENV_STOP_UNDI calls.'  Since loader.S only uses
> PXENV_UNDI_SHUTDOWN and PXENV_UNLOAD_STACK, the interrupt doesn't get
> unhooked.  If dos or EtherBoot or any other images load over the PXE
> interrupt handler, then when int 1Ah gets called, the system will crash.

Yes, this is indeed the problem. Well spotted in the PXE spec as well. The
first implementation wasn't releasing part of the UNDI memory of PXE to get
round this, but then DOS apps were running out of memory.

> The way I fixed this was to add a call to PXENV_STOP_UNDI.  Other ways to

This sounds the right way.

> fix this would be to relocate EtherBoot code to other areas or not release
> the PXE memory to the system.

Could do, but see above. Still if any part of PXE refuses to unload, the
memory shouldn't be released...

> How should I submit the changes to the code or has this problem already been
> fixed?
>
> I also rewrote the hex to ascii routines that display the amount of free
> memory in the PXE loader.  The current routines don't seem to work properly.

The idea here was debugging, but the pretier the better as long it doesn't
much memory and fits within the memory model.

> I tested this fix with EtherBoot 5.0.7 and EtherBoot 5.0.8.
> The network card used is an Intel EtherExpress PRO/100+ Management Adapter
> using the eepro100 driver.
> The versions of dos tested were Windows 98 SE MS-DOS and FreeDOS Kernel
> 2.0.27.
> Both doses crashed before the fix.  Now they work!!! :)

Great. If you like reading the PXE spec, maybe you can do Etherboot on top of
PXE's UNDI without using an Etherboot's native network driver :). This, of
course, is an option in addition to using the native driver.

Vasil

[Etherboot-developers] Re: LinuxBIOS ROM Image problem..

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

Vladimir,

Thanks for your report. We are looking into how to set options 
appropriately for LinuxBIOS and ELF format builds, while still allowing 
customization. We hope to have a fix soon. We apologize for the 
inconvenience.

Developers: Has anyone successfully generated a LinuxBIOS format ROM 
image from rom-o-matic.net? What options did you use?

Marty

On Tuesday, December 10, 2002, at 06:38  PM, Vladimir Poliakov wrote:

> ROM-o-matic: for Etherboot version 5.0.6
>
> LinuxBIOS ROM Image (.ebi) FOR EXPERTS ONLY!
>
>
> =======================
> 3c590 Build Failed
>  Build failed. Status = 2.
>
>  Following is the output from make:
>
>
>
>
> make: Entering directory `/tmp/ROMXDM2PO'
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -DINCLUDE_3C595 -o bin32/3c595.o -c 3c595.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -DINCLUDE_3C595 -o bin32/config-3c595.o -c config.c
> config.c: In function `eth_probe':
> config.c:495: warning: passing arg 2 from incompatible pointer type
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/pci.o -c pci.c
> /tmp/cc4xREzm.s: Assembler messages:
> /tmp/cc4xREzm.s:43: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:105: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:144: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:183: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:223: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:262: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:301: Warning: indirect lcall without `*'
> /tmp/cc4xREzm.s:347: Warning: indirect lcall without `*'
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD 
> -DIMAGE_MENU
> -DCONGESTED -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE 
> -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  start32.S | as  -o bin32/start32.o
> {standard input}: Assembler messages:
> {standard input}:141: Warning: indirect ljmp without `*'
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/linuxbios.o -c linuxbios.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/main.o -c main.c
> main.c: In function `tftp':
> main.c:624: warning: `oport' might be used uninitialized in this 
> function
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/osloader.o -c osloader.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/nfs.o -c nfs.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/misc.o -c misc.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/ansiesc.o -c ansiesc.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/bootmenu.o -c bootmenu.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/md5.o -c md5.c
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  -o bin32/floppy.o -c floppy.c
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD 
> -DIMAGE_MENU
> -DCONGESTED -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE 
> -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000  serial.S | as  -o bin32/serial.o
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU 
> -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03
> -DPCBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer 
> -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -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
> ld -N -Ttext 0x94000 -e _start -o bin32/3c595.elf bin32/start32.o
> bin32/linuxbios.o bin32/config-3c595.o bin32/3c595.o bin32/pci.o
> bin32/bootlib.a
> bin32/bootlib.a(main.o): In function `main':
> main.o(.text+0x7b): undefined reference to `currticks'
> main.o(.text+0x89): undefined reference to `currticks'
> bin32/bootlib.a(main.o): In function `bootp':
> main.o(.text+0x8b6): undefined reference to `currticks'
> main.o(.text+0xa2a): undefined reference to `currticks'
> bin32/bootlib.a(main.o): In function `await_reply':
> main.o(.text+0xab8): undefined reference to `currticks'
> bin32/bootlib.a(main.o)(.text+0xe1c): more undefined references to
> `currticks' follow
> bin32/bootlib.a(misc.o): In function `gateA20_set':
> misc.o(.text+0x46e): undefined reference to `int15'
> bin32/bootlib.a(misc.o): In function `gateA20_unset':
> misc.o(.text+0x4a6): undefined reference to `int15'
> bin32/bootlib.a(misc.o): In function `putchar':
> misc.o(.text+0x4ee): undefined reference to `console_putc'
> bin32/bootlib.a(misc.o): In function `getchar':
> misc.o(.text+0x4ff): undefined reference to `console_ischar'
> misc.o(.text+0x508): undefined reference to `console_getc'
> bin32/bootlib.a(misc.o): In function `iskey':
> misc.o(.text+0x525): undefined reference to `console_ischar'
> bin32/bootlib.a(bootmenu.o): In function `selectImage':
> bootmenu.o(.text+0x264): undefined reference to `currticks'
> bootmenu.o(.text+0x2bf): undefined reference to `currticks'
> make: *** [bin32/3c595.elf] Error 1
> make: Leaving directory `/tmp/ROMXDM2PO' Please let us know that this
> happened.
>
>  Rom-o-matic.net works best with Netscape or lynx browsers. If you're 
> using
> MIE 5.5 or are having problems downloading a ROM image, please read 
> this. For
> more information about Etherboot and network booting in general, see:
>
>
>
> Rom-o-matic.net Home http://rom-o-matic.net/
>
>
> Etherboot Home Site http:/www.etherboot.org/
>
> Source code for Etherboot ROMs is available at
> http://www.etherboot.org/distribution.html
>
>  A database of Etherboot-compatible ethernet cards is available at
> http://www.etherboot.org/db/
>
>
>
> Linux Terminal Server Project makes it easy to create a server for thin
> clients. See: http://www.ltsp.org/
>
>
>
> Thinguin Thin Client Resources http://www.thinguin.org/
>
>
>  Please email web...@en... with questions or comments about 
> this
> website.
>

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

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

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

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

>Hi all,
>  I just fixed the problem where trying to boot dos by chaining from PXE to 
>EtherBoot to dos crashes the system in EtherBoot 5.0.8.  Also, on my system 
>once PXE had loaded EtherBoot, going to local boot to load dos would crash 
>during dos loading as well.
>
>  In version 2.1 of the PXE Specification, in the UNDI_STARTUP service 
>description, it says that 'PXENV_UNDI_STARTUP and PXENV_UNDI_SHUTDOWN are no 
>longer responsible for chaining interrupt 1Ah.  This must be done by the 
>PXENV_START_UNDI and PXENV_STOP_UNDI calls.'  Since loader.S only uses 
>PXENV_UNDI_SHUTDOWN and PXENV_UNLOAD_STACK, the interrupt doesn't get 
>unhooked.  If dos or EtherBoot or any other images load over the PXE 
>interrupt handler, then when int 1Ah gets called, the system will crash.  
>The way I fixed this was to add a call to PXENV_STOP_UNDI.  Other ways to 
>fix this would be to relocate EtherBoot code to other areas or not release 
>the PXE memory to the system.
>
>How should I submit the changes to the code or has this problem already been 
>fixed?
>
>I also rewrote the hex to ascii routines that display the amount of free 
>memory in the PXE loader.  The current routines don't seem to work properly.

That's wonderful, you've finally fixed a long standing bug. If the fixes
aren't too large, say > 10kB, just post them to this developer list so
that Peter and Vasil can give a second opinion. If there are no
corrections, I will issue a patch on the web site, and also queue this
up for 5.0.9 (and also fix it in 5.1.x). And your name gets inscribed in
the change log, naturally.

	Thanks, Ken

[Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

[Matthew S. <sta...@ho...>]

Hi all,
  I just fixed the problem where trying to boot dos by chaining from PXE to 
EtherBoot to dos crashes the system in EtherBoot 5.0.8.  Also, on my system 
once PXE had loaded EtherBoot, going to local boot to load dos would crash 
during dos loading as well.

  In version 2.1 of the PXE Specification, in the UNDI_STARTUP service 
description, it says that 'PXENV_UNDI_STARTUP and PXENV_UNDI_SHUTDOWN are no 
longer responsible for chaining interrupt 1Ah.  This must be done by the 
PXENV_START_UNDI and PXENV_STOP_UNDI calls.'  Since loader.S only uses 
PXENV_UNDI_SHUTDOWN and PXENV_UNLOAD_STACK, the interrupt doesn't get 
unhooked.  If dos or EtherBoot or any other images load over the PXE 
interrupt handler, then when int 1Ah gets called, the system will crash.  
The way I fixed this was to add a call to PXENV_STOP_UNDI.  Other ways to 
fix this would be to relocate EtherBoot code to other areas or not release 
the PXE memory to the system.

How should I submit the changes to the code or has this problem already been 
fixed?

I also rewrote the hex to ascii routines that display the amount of free 
memory in the PXE loader.  The current routines don't seem to work properly.

I tested this fix with EtherBoot 5.0.7 and EtherBoot 5.0.8.
The network card used is an Intel EtherExpress PRO/100+ Management Adapter 
using the eepro100 driver.
The versions of dos tested were Windows 98 SE MS-DOS and FreeDOS Kernel 
2.0.27.
Both doses crashed before the fix.  Now they work!!! :)

Matthew Stapleton
Email: sta...@ho...


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Etherboot-developers] 5.1.x: nrv2b.c

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

ke...@us... writes:

> Got these warnings from gcc 3.2:
> 
> nrv2b.c:790:48: warning: multi-line string literals are deprecated
> nrv2b.c:1452:34: warning: multi-line string literals are deprecated
> nrv2b.c:1455:25: warning: multi-line string literals are deprecated
> 
> They seem to be unintentional, printf lines broken inside the format
> string.


Right.  There is some unintentional breakage of long lines.
I don't know where that came from...

That is currently fixed in my tree, feel free to put those lines back together
if you get to it before I commit.

Eric

[Etherboot-developers] 5.1.x: nrv2b.c

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

Got these warnings from gcc 3.2:

nrv2b.c:790:48: warning: multi-line string literals are deprecated
nrv2b.c:1452:34: warning: multi-line string literals are deprecated
nrv2b.c:1455:25: warning: multi-line string literals are deprecated

They seem to be unintentional, printf lines broken inside the format
string.

Re: [Etherboot-developers] Fwd: Rom-o-matic build failed for 3c980

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

On Friday, December 6, 2002, at 04:36  AM, Marty Connor wrote:
> Any ideas?
> From: Marcel Brouillet <mbr...@qu...>
>> Date: Fri Dec 6, 2002  4:31:44  AM US/Eastern
>> To: web...@en...
>> Subject: Rom-o-matic build failed for 3c980
>> as suggested on the error page that I got, I let you know the 
>> following
>> problem has occured when trying to build a floppy for 3c980 using 
>> 5.1.3
>> development release (and no special other fiddling).
>> make: Entering directory `/tmp/ROMPNFWrD'
>> make: *** No rule to make target `bin32/3c980.lzdsk'.  Stop.
>> make: Leaving directory `/tmp/ROMPNFWrD'

Duh. I've been up too long.  This was just caused by the broken .lzdsk 
rule that Ken sent a patch about days ago. I patched it on 
rom-o-matic.net.

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] Fwd: Rom-o-matic build failed for 3c980

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

Any ideas?

Begin forwarded message:

> From: Marcel Brouillet <mbr...@qu...>
> Date: Fri Dec 6, 2002  4:31:44  AM US/Eastern
> To: web...@en...
> Subject: Rom-o-matic build failed for 3c980
>
> Hello,
> as suggested on the error page that I got, I let you know the following
> problem has occured when trying to build a floppy for 3c980 using 5.1.3
> development release (and no special other fiddling).
>
> Cheers,
> Marcel.
>
> -----------------------------------
> Build failed. Status = 2.
>
> Following is the output from make:
>
> make: Entering directory `/tmp/ROMPNFWrD'
> make: *** No rule to make target `bin32/3c980.lzdsk'.  Stop.
> make: Leaving directory `/tmp/ROMPNFWrD'
>
> Please let us know that this happened.
>
>

-- 
     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] 5.1.3 on rom-o-matic

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

Thanks to Marty Connor this is up on rom-o-matic.net now. Have at it and
please report bugs to this mailing list. Please remember that Linux
images must be tagged with mknbi-1.2-10 or later.