etherboot-developers — Discussion of developer issues

RE: [Etherboot-developers] Q: TODO list for 5.2

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

> > I was not able to get past the autonegotiation stage on my OC2336
even
> > though the lights on the hub seem to indicate the hub is happy with
> the
> > speed. You have some recursive calls in TLan_FinishAutoNeg, those
> can't
> > be right.
> 
> The Linux driver does some strange things in the auto-negotiation.  I
> will review my changes.  I may be able to get my hands on another tlan
> car to test with also.

If I remember correctly and I think I do.  The Linux driver sets up an
interrupt based timer to allow it to restart parts of the auto
negotiation if it need more time.  Since eb lacks an interrupt handler I
improvised by calling the function that the linux driver would have when
the interrupt kicked in.  

If you can think of a better way let me know.  Also, where exactly in
the negotiation does it fail?  Can you attach a serial debug?

Also, as far as I can tell using one transmit buffer with the tlan is
not possible.  I believe that the minimum is two because unlike some
cards where you simply write the address of the ring again it depends on
the forward pointer of the previous tx buffer pointing to the next tx
buffer.  There may be a way in the doc to prevent it from continuing to
transmit the wrapped ring I am not aware of it...

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 

RE: [Etherboot-developers] Q: TODO list for 5.2

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

> You didn't leave the number of Rx and Tx buffers at the Linux default
> did you? That would blow up the footprint. I usually bring the number
of
> Rx buffers down to 2 or 4 and the Tx buffer to 1 for Etherboot. The
> protocols used are stop and wait anyway, and don't need to transmit
back
> to back.

You may be right, I will have to check that...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 

RE: [Etherboot-developers] Q: TODO list for 5.2

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

> I was not able to get past the autonegotiation stage on my OC2336 even
> though the lights on the hub seem to indicate the hub is happy with
the
> speed. You have some recursive calls in TLan_FinishAutoNeg, those
can't
> be right.

The Linux driver does some strange things in the auto-negotiation.  I
will review my changes.  I may be able to get my hands on another tlan
car to test with also.
 
> You don't need ISA support in the driver, it's a PCI only card.  I've
> reduced the number of Rx and Tx buffers and checked the changes in.

Yeah, I left it in because the Linux driver mentioned ISA versions.
Obviously it should have been taken out.

I am not sure whether the Tx buffer can be set to 1.  The card requires
the forward pointer of the ring to point to the next buffer.  If it sees
a zero it ends the channel.  (Which could be Ok, I have tried to make it
do that to no avail.)  If you point the forward pointer to itself it
keeps transmitting the same thing...
  
Thanks

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 

Re[2]: [Etherboot-developers] Q: TODO list for 5.2

[Anselm M. H. <an...@ho...>]

Hello Timothy,

> I also started some detailed linux driver to Etherboot driver porting
> documentation when I started the pcnet driver.  I should be able to
> finish that up after the tlan.  Since it is not really version specific
> it should not be a dependency for 5.2.  Also, since we now have the
> majority of the linux drivers supported there may be limited value in
> proceeding...

One of my long-term-projects ;-) is to port the Realtek 8169 driver.
It seems similar to 8139, with some not-so-nice (and not well
documented, I think) changes. It is a gigabit NIC, and having my
workstation boot an LTSP for the occasional mail check instead of a
full-blown Debian would be way cool.
My time is limited though, as the usual exams are approaching.
Perhaps your docs would give me at least a good starting point. Could
you mail them (incomplete if they are, no problem)?

Regards,
  Anselm

[Etherboot-developers] Re: Etherboot 5.0.10 problem + solution

[David A. <da...@xd...>]

>You should be trying 5.1, it works better with linuxbios.

I looked at this, it's too different from earlier versions. No mention of
the .ebi file needed by 5.0.10. Too alien.

However I fixed the rtl8139 network problem and it turned out to be a very
subtle problem in the driver, and it is present in every version of linux
that I've checked. However the circumstances that demonstrate this problem
only seem to appear when linuxbios is doing the booting.

Here's the problem:

The 8139 IntrStatus register (word at offset $3e) is read only, writes have
no effect. The act of reading the register *CLEARS* every interrupt request.
The drivers all assume they need to write 1 bits back to this register to
clear the appropriate interrupt request bits, and leave the other ones
untouched. So what was happening with my setup was network traffic was flaky,
it might send a packet but then miss the response, if the response came back
fast enough (which it usually does).

I fixed it by changing the rtl8139.c file so IntrStatus isn't directly accessed
by the code, but instead goes through some helper functions:
static unsigned short cintr=0;
static unsigned short getstatus(void)
{
	return cintr|=inw(ioaddr + IntrStatus);
}
static void setstatus(unsigned short val)
{
	cintr&=~val;
}

So all times where inw(ioaddr+IntrStatus) is used, use getstatus() instead,
and instead of using outw(val, ioaddr+IntrStatus) use setstatus() instead.

After this it works perfectly.

Re: [Etherboot-developers] Q: TODO list for 5.2

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

>I started pcnet32 a while back, but without a hardware nic, it became
>difficult.  For some reason I hit a size issue in 5.0 and I did not seem
>to be able to get 5.1 to boot via vmware.  I would add fixing vmware
>support to the list, but I don't know where to start.  I am however
>looking to purchase a pcnet based NIC if I can find one.  They seem to
>be fairly rare...

You didn't leave the number of Rx and Tx buffers at the Linux default
did you? That would blow up the footprint. I usually bring the number of
Rx buffers down to 2 or 4 and the Tx buffer to 1 for Etherboot. The
protocols used are stop and wait anyway, and don't need to transmit back
to back.

Re: [Etherboot-developers] Q: TODO list for 5.2

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

On Fri, 11 Jul 2003, Marty Connor wrote:
> 
> Then there's the LTSP issue. I've had a message on the rom-o-matic.net 
> site, warning LTSP users not to use 5.1.x because of incompatible 
> changes.  Jim, if you're listening, could you suggest alternative 
> wording, now that the new kernel package is out?  I'm sure we'd get a 
> lot of LTSP users testing 5.1.x is we said something like:
> 
>      LTSP users must upgrade to the latest ltsp-kernel package  
> (currently ltsp_kernel-3.0.10) available at:
> 
>           http://www.ltsp.org/instructions-3.0.html
> 
>      in order to use Etherboot 5.1.x
> 
> Can you let me know if this is correct, or suggest an alternative. We 
> value feedback from LTSP users, and want to make sure we keep them 
> happy and don't disappoint them with booting problems.

Marty,  I think you've said it perfectly.

Also, looking forward to another great Linux World.  Make sure
you keep Wednesday evening free for the traditional LTSP dinner.

Jim.

Re: [Etherboot-developers] Q: TODO list for 5.2

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

>The cvs includes my tlan attempt that is able to poll correctly and
>transmit once.  I suspect that a review of the documentation would point
>out the issue.

I was not able to get past the autonegotiation stage on my OC2336 even
though the lights on the hub seem to indicate the hub is happy with the
speed. You have some recursive calls in TLan_FinishAutoNeg, those can't
be right.

You don't need ISA support in the driver, it's a PCI only card.  I've
reduced the number of Rx and Tx buffers and checked the changes in.

RE: [Etherboot-developers] Q: TODO list for 5.2

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

> Other than that, I agree with Ken's list. I'd love to take a crack at
> the TLAN driver. I have a card here somewhere, and it would be fun. It
> would take two solid days of work to do it, though, and I'm not sure I
> can commit that with my current workload.

The cvs includes my tlan attempt that is able to poll correctly and
transmit once.  I suspect that a review of the documentation would point
out the issue.

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 

Re: [Etherboot-developers] Q: TODO list for 5.2

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

On Friday, July 11, 2003, at 04:31  AM, Ken Yap wrote:
>> Do we have a TODO list of what needs to happen before 5.2 is released?
>
> Mea culpa, I should really make this list. Marty and others, please 
> post
> your lists. For me:
>
> pcnet32 support
> tlan support (if possible)
> UNDI (ready when you are Michael)
> documentation
>
> I'd like to get 5.2 out in time for LWE SF.

I think 5.2 for LWE might be a little ambitious, though possibly doable.

My ToDo list is mainly a testing one. I'd like to create a matrix 
something like:

Etherboot Driver         .zrom         .zdsk        .zpxe       .zlilo
tulip                      OK            OK           OK         Failed
rtl8139                    OK            OK           OK         OK
3C905B                     OK            OK           OK         OK

You get the idea. I'd just like to have confidence before we release 
that the basic functionality and traditional robustness is there. I 
have a fair number of cards here, and a testing setup, ROM burner, etc. 
So I can help with this. Of course, many people pitching in would be a 
real help!

5.1.x has some fairly drastic changes (for the better!) to the code, 
and so I'd like to take a little extra time testing before releasing as 
production quality.

It's been a busy summer for me, and it will likely remain so, but I'd 
also really like get 5.2 out, but not at cost of stability.  Of course, 
as usual, until we release, we won't get the quality and quantity of 
bug messages that we so much enjoy ;)

Then there's the LTSP issue. I've had a message on the rom-o-matic.net 
site, warning LTSP users not to use 5.1.x because of incompatible 
changes.  Jim, if you're listening, could you suggest alternative 
wording, now that the new kernel package is out?  I'm sure we'd get a 
lot of LTSP users testing 5.1.x is we said something like:

     LTSP users must upgrade to the latest ltsp-kernel package  
(currently ltsp_kernel-3.0.10) available at:

          http://www.ltsp.org/instructions-3.0.html

     in order to use Etherboot 5.1.x

Can you let me know if this is correct, or suggest an alternative. We 
value feedback from LTSP users, and want to make sure we keep them 
happy and don't disappoint them with booting problems.

Other than that, I agree with Ken's list. I'd love to take a crack at 
the TLAN driver. I have a card here somewhere, and it would be fun. It 
would take two solid days of work to do it, though, and I'm not sure I 
can commit that with my current workload.

So that's my view of things. I'm excited by the possibility of getting 
5.2 out. If everyone pitches in with some testing and we do a bug hunt, 
I'll feel better about putting it out there.

Marty

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

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

Re: [Etherboot-developers] Q: TODO list for 5.2

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

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

> >Do we have a TODO list of what needs to happen before 5.2 is released?
> 
> Mea culpa, I should really make this list. Marty and others, please post
> your lists. For me:
> 
> pcnet32 support
> tlan support (if possible)
> UNDI (ready when you are Michael)
> documentation
> 
> I'd like to get 5.2 out in time for LWE SF.

Multicast reception support in most of the drivers.  Besides being
cool on large clusters.  We will probably need it if we ever support IPv6,
as a lot of broadcast traffic has been replaced with multicast traffic.

Eric

RE: [Etherboot-developers] Q: TODO list for 5.2

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

> pcnet32 support
> tlan support (if possible)
> UNDI (ready when you are Michael)
> documentation

I started pcnet32 a while back, but without a hardware nic, it became
difficult.  For some reason I hit a size issue in 5.0 and I did not seem
to be able to get 5.1 to boot via vmware.  I would add fixing vmware
support to the list, but I don't know where to start.  I am however
looking to purchase a pcnet based NIC if I can find one.  They seem to
be fairly rare...

As for the tlan, I am attaching a minicom.cap file with hex dumps of
what the poll received.  It looks fine to me, but I am not sure.  I
suspect that there is something very small in the transmit function that
I am overlooking.  I would really like to get it in 5.2 but I will
certainly back-port it when it works.

I also started some detailed linux driver to Etherboot driver porting
documentation when I started the pcnet driver.  I should be able to
finish that up after the tlan.  Since it is not really version specific
it should not be a dependency for 5.2.  Also, since we now have the
majority of the linux drivers supported there may be limited value in
proceeding...

Tim






---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 
  

Re: [Etherboot-developers] Q: TODO list for 5.2

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

>Do we have a TODO list of what needs to happen before 5.2 is released?

Mea culpa, I should really make this list. Marty and others, please post
your lists. For me:

pcnet32 support
tlan support (if possible)
UNDI (ready when you are Michael)
documentation

I'd like to get 5.2 out in time for LWE SF.

[Etherboot-developers] Q: TODO list for 5.2

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

Do we have a TODO list of what needs to happen before 5.2 is released?

I am getting increasingly close to wanting to do things like
Myrinet, and Infiniband support.  Or at least look to see if it is
reasonable to support those interconnects.  But I would rather do that
in 5.3 than in 5.1 because a non Ethernet interconnect would likely
require some sizeable changes to the code.

Eric

Re: [Etherboot-developers] Etherboot 5.0.10 problem + solution

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

>I'm trying to use rtl8139.ebi with linuxbios and etherboot is crashing with
>a divide by 0 error (I think). The problem can be fixed if in the function
>currticks() in timer.c it just calls setup_timers() at the top of the
>function. I think somewhere currticks() is being called before setup_timers()

You should be trying 5.1, it works better with linuxbios.

RE: [Etherboot-developers] TLAN Driver

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

> Sure check it in and I'll give it a whirl.
> 

I have checked in the tlan.c and tlan.h driver files with the supporting
changes to Makefile.main and genrules.pl.  

I had hoped to clean it up and I had intended on merging the h and c
files prior to committing it.  However at the moment I am going around
in circles.

I strove to keep it close to the Linux driver.  I realized that the
interrupts are enabled (could that be causing issues?) but on my last
kick at it, I was debugging an adapter check issue (condition that
required a reset of the card).  Any help would be much appreciated.

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
 

[Etherboot-developers] Etherboot 5.0.10 problem + solution

[David A. <da...@xd...>]

I'm trying to use rtl8139.ebi with linuxbios and etherboot is crashing with
a divide by 0 error (I think). The problem can be fixed if in the function
currticks() in timer.c it just calls setup_timers() at the top of the
function. I think somewhere currticks() is being called before setup_timers().

Aside from that the rtl8139 code doesn't seem to be initializing something
properly, because sending + receiving packets is spotty at best. Here is
some of the console data:
Welcome to elfboot, the open sourced starter.                                   
January 2002, Eric Biederman.                                                   
Version 1.2                                                                     
                                                                                
    34:init_bytes() - zkernel_start:0xfff00000  zkernel_mask:0x0000ffff         
Found ELF candiate at offset 0                                                  
New segment addr 0x94000 size 0x7e08 offset 0x60 filesize 0x35c0                
(cleaned up) New segment addr 0x94000 size 0x7e08 offset 0x60 filesize 0x35c0   
Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000007e08 filesz: 0x00
Clearing Segment: addr: 0x00000000000975c0 memsz: 0x0000000000004848            
Jumping to boot code at 0x94000                                                 
ROM segment 0x0000 length 0x0000 reloc 0x9400                                   
Etherboot 5.0.10 (GPL) ELF for [RTL8139]                                        
Boot from (N)etwork or from (L)ocal? CPU 616 Mhz                                
N                                                                               
Probing...[RTL8139]Found Realtek 8139 ROM address 0x2100                        
 - The PCI BIOS has not enabled this device!                                    
Updating PCI command 0003->0007. pci_bus 00 pci_device_fn A0                    
ioaddr 0X1800, addr 00:03:70:00:10:5B 100Mbps full-duplex                       
Searching for server (BOOTP)...                                                 
.....

Etherboot thinks it is sending out bootp requests but they almost never
get received by the bootp server. It seems to be a transmission problem
since it always receives the bootp response when it is able to send a
packet out.

Any advice/help appreciated.

Thanks--
Dave

Re: [Etherboot-developers] TLAN Driver

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

>I have a tlan driver that is almost complete but I am having issues transmitt
>ing more than once.  So I have a couple of questions:
>
>1) Do I have a poll issue not a transmit problem.  The dhcp server replies an
>d the driver polls and gets the packet length.  If the poll does not get the 
>packet correctly will etherboot retransmit?  I have been assuming yes.

If there is not a complete packet collected yet, then the poll
will/ought to succeed on a later call when the whole packet has arrived,
provided you haven't removed any partial data.

>2) Does anyone have a tlan NIC who would like to hack at it a bit?  Right now
>, other than not haveing the disable function implemented, and the transmit i
>ssue it is pretty complete but needs some work.  At 2:45 am the other night I
> decided I need help (and not necessarly development help) ;-).

Sure check it in and I'll give it a whirl.

>3) Is there any way to parse/print out the packet that the poll function is g
>etting to ensure that it is properly received?

Sure, just print out the bytes with the function Michael mentioned.

Re: [Etherboot-developers] TLAN Driver

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

> 1) Do I have a poll issue not a transmit problem.  The dhcp server
> replies and the driver polls and gets the packet length.  If the poll
> does not get the packet correctly will etherboot retransmit?  I have
> been assuming yes.

Yes, as far as I am aware.

> 3) Is there any way to parse/print out the packet that the poll function
> is getting to ensure that it is properly received?

There's a function in misc.c called hex_dump() that will produce a paged, 
nicely formatted hex dump of any given buffer; this may be handy.  You 
need to change 
  #define DEBUG_UTILS 0
to 
  #define DEBUG_UTILS 1
in misc.c, otherwise it won't be compiled.

HTH,

Michael

[Etherboot-developers] TLAN Driver

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

Hi

I have a tlan driver that is almost complete but I am having issues transmitting more than once.  So I have a couple of questions:

1) Do I have a poll issue not a transmit problem.  The dhcp server replies and the driver polls and gets the packet length.  If the poll does not get the packet correctly will etherboot retransmit?  I have been assuming yes.

2) Does anyone have a tlan NIC who would like to hack at it a bit?  Right now, other than not haveing the disable function implemented, and the transmit issue it is pretty complete but needs some work.  At 2:45 am the other night I decided I need help (and not necessarly development help) ;-).

3) Is there any way to parse/print out the packet that the poll function is getting to ensure that it is properly received?

Regards

Tim

Re: [Etherboot-developers] centaur-p tulip[0x1317,0x0985] Build Failed

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

>> Every time I pick centaur-p tulip[0x1317,0x0985]
>> and click configure
>> I then click on
>> MOTD
>> IMAGE_MENU
>> PASSWD
>> ANSIESC
>> GFX
>> I then get this nasty message
>>...
>> bin32/pci.o bin32/bootlib.a
>> ERROR: code size exceeds limit!
>> make: *** [bin32/tulip.tmp] Error 1
>> make: Leaving directory `/tmp/ROM8aF2iW'

Take less options or try 5.1 where images can be larger.

BTW this should be a -users posting, not a -developers posting.

[Etherboot-developers] centaur-p tulip[0x1317,0x0985] Build Failed

[Samuel D. <sam...@st...>]

> Every time I pick centaur-p tulip[0x1317,0x0985]
> and click configure
> I then click on
> MOTD
> IMAGE_MENU
> PASSWD
> ANSIESC
> GFX
> I then get this nasty message
>
>
> centaur-p.lzdsk Build Failed
>
>  Build failed. Status = 2.
>
>  Following is the output from make:
>
>
> make: Entering directory `/tmp/ROM8aF2iW'
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -DINCLUDE_TULIP -o bin32/tulip.o -c tulip.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -DINCLUDE_TULIP  -o bin32/config-tulip.o -c config.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/pci.o -c pci.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> pci.c: In function `scan_bus':
> pci.c:407: warning: comparison is always true due to limited range of
> data
> type
> /tmp/ccu6kKp7.s: Assembler messages:
> /tmp/ccu6kKp7.s:43: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:101: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:137: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:173: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:209: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:241: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:273: Warning: indirect lcall without `*'
> /tmp/ccu6kKp7.s:310: Warning: indirect lcall without `*'
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD
> -DIMAGE_MENU -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000  start32.S | as  -o bin32/start32.o
> {standard input}: Assembler messages:
> {standard input}:99: Warning: indirect ljmp without `*'
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD
> -DIMAGE_MENU -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000  pcbios.S | as  -o bin32/pcbios.o
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/memsizes.o -c memsizes.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/main.o -c main.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> main.c: In function `load':
> main.c:415: warning: passing arg 1 of `selectImage' from incompatible
> pointer type
> main.c: In function `tftp':
> main.c:643: warning: `oport' might be used uninitialized in this
> function
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/osloader.o -c osloader.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/nfs.o -c nfs.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/misc.o -c misc.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/ansiesc.o -c ansiesc.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> ansiesc.c: In function `ansi_putc':
> ansiesc.c:338: warning: signed and unsigned type in conditional
> expression
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/bootmenu.o -c bootmenu.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> bootmenu.c: In function `getoptvalue':
> bootmenu.c:45: warning: passing arg 1 of `getdec' from incompatible
> pointer type
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/md5.o -c md5.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/floppy.o -c floppy.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/serial.o -c serial.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions gcc
> -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DPASSWD
> -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/timer.o -c timer.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> timer.c: In function `mdelay':
> timer.c:195: warning: comparison between signed and unsigned
> timer.c:197: warning: implicit declaration of function
> `poll_interruptions'
> gcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DPASSWD -DANSIESC -DGFX -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.10\"
> -DRELOC=0x94000
> -o bin32/isapnp.o -c isapnp.c
> cc1: warning: -malign-loops is obsolete, use -falign-loops
> cc1: warning: -malign-jumps is obsolete, use -falign-jumps
> cc1: warning: -malign-functions is obsolete, use -falign-functions 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 bin32/isapnp.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
> a - bin32/isapnp.o
> ranlib bin32/bootlib.a
> gcc -O2 -o bin/makerom makerom.c
> gcc -O2 -DENCODE -DDECODE -DMAIN -DVERBOSE -o bin/lzhuf lzhuf.c
> ld -N -Ttext 0x94000 -e _start -o bin32/tulip.tmp bin32/start32.o
> bin32/pcbios.o bin32/memsizes.o bin32/config-tulip.o bin32/tulip.o
> bin32/pci.o bin32/bootlib.a
> ERROR: code size exceeds limit!
> make: *** [bin32/tulip.tmp] Error 1
> make: Leaving directory `/tmp/ROM8aF2iW'

[Etherboot-developers] [PATCH] backport of e1000 driver from 5.1.8 to 5.0.10

[Axel D. <axe...@ag...>]

Hallo,

this answer is especially for Hans-Peter Jansen (see archive 2003-06-17 09:25)

I'm not a member of this list but have done a e1000 driver backport from
5.1.8 to 5.0.10.

It works very well for me with e new 82540EM (PCI ID: 0x8086/0x100E) , so
have a look on it.
You can get the patch, if you email me directly.

I tried to send the patch to the list, but forgot to compress the patch :-(
Now it's waiting for a moderator review.

I also sent the patch already to Ken Yap.

Axel

[Etherboot-developers] [PATCH] backport of e1000 driver from 5.1.8 to 5.0.10

[Axel D. <axe...@ag...>]

Hallo,

this answer is especially for Hans-Peter Jansen (see archive 2003-06-17 09:25)

I'm not a member of this list but have done a e1000 driver backport from
5.1.8 to 5.0.10.

It works very well for me with e new 82540EM (PCI ID: 0x8086/0x100E) , so
have a look on it:

For comments please write to me directly.

Axel

(See attached file: etherboot-5.0.10.e1000-patch)

Re: [Etherboot-developers] Multiboot Information structure is not correct

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

>OK, the patch is attached.
>This code is confirmed to give the same memory map as GRUB.
>If Multiboot header is not found, it switches to ELFboot.

Committed to CVS, thanks.