etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

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

>Ken could you kill.
>
>ube.c ube_start32.S uniform_boot.h
>At this point they only get in the way.  And I suspect my patches
>would be smaller if I didn't keep killing them.

Er, I did. They don't appear in the patch. They're still in CVS but
inactive. I could put them in the attic I suppose, is that what you have
in mind?

Re: [Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

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

ke...@us... writes:

> Thanks to Eric, Christopher, Jean-Jacques, Rohit, Yedidyah, Gergely,
> Chien-Yu, Doug, Marty, and anybody who has contributed bug reports or
> suggestions, we have a large number of bug fixes and enhancements and we
> are one step closer to 5.0.6. The details and patch are here:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=529343&group_id=4233&atid=304233
> 
> 
> Please bash the release around a bit to shake out bugs and let the
> developer list know about both successes and failures.

Ken could you kill.

ube.c ube_start32.S uniform_boot.h
At this point they only get in the way.  And I suspect my patches
would be smaller if I didn't keep killing them.

Eric

[Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

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

Thanks to Eric, Christopher, Jean-Jacques, Rohit, Yedidyah, Gergely,
Chien-Yu, Doug, Marty, and anybody who has contributed bug reports or
suggestions, we have a large number of bug fixes and enhancements and we
are one step closer to 5.0.6. The details and patch are here:

http://sourceforge.net/tracker/index.php?func=detail&aid=529343&group_id=4233&atid=304233

Please bash the release around a bit to shake out bugs and let the
developer list know about both successes and failures.

Re: [Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

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

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

> Thanks very much for that cleanup, Eric. I'll commit to CVS and put out
> a new megapatch for rc3 in a moment.

Cool.  I have just tested the e1000 and the eepro100 under LinuxBIOS
and everything is working just fine there as well.

Eric

Re: [Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

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

Thanks very much for that cleanup, Eric. I'll commit to CVS and put out
a new megapatch for rc3 in a moment.

[Etherboot-developers] [PATCH] fix the e1000 mac address display

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

In further testing when I have the final patch to start32.S
applied I don't have any problems.  So my problems look like a fluke.
Or possibly just the result of a partial set of patches.

I have succesfully netbooted off of the e1000 and the eepro100 to work
from the same source.  Built with the same configuration.

The following patch was needed to keep me from getting confused about
the mac address.

Eric

--- etherboot-5.0.6rc3.e1000/src/e1000.c        Tue Mar 12 23:40:41 2002
+++ etherboot-5.0.6rc3.test2/src/e1000.c        Wed Mar 13 02:20:34 2002
@@ -403,7 +403,7 @@
        ReadNodeAddress (mac_addr);
        memcpy (nic->node_addr, mac_addr, ETH_ALEN);

-       printf("MAC address %!\n",nic);
+       printf("MAC address %!\n", mac_addr);

        if (!InitializeHardware ()) {
                E1000_ERR ("Hardware Initialization Failed\n");

[Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

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

I just had a good hard look at the pci initialization code and there
are bad comments and strage behaviors.  And a lot of code
that looks like it should be doing one thing but it is really doing something
else.

Towards making this all work I have rewritten how pci devices are probed,
and the code now should actually support attempting to boot off of the next
pci device.

The big changes are:
We always return if we find a matching pci device
regardless of weather an ``ioaddr'' is valid.

We walk the list of drivers, and then the list of their devices.
Instead of walking the list of possible devices, followed by the
list of drivers.

The pci_ioaddrs is now a local variable in eth_probe to show their
is no magic going on.

We can now restart a scan through the pci devices to find the next
one.

Only the sis900 and e1000 drivers were touched.

For the e1000 I have it read the information it needs directly
from pci configuration space.  

The sis900 driver needed an update to handle the saner pci scanning.

ftp://download.lnxi.com/pub/src/etherboot/etherboot-5.0.6rc3.e1000.diff

I was having a problem with the eepro100 when testing this patch,
where it was locking up halfway through loading an image.  
I can reproduce the problem without this patch.  So that is my
next thing to investigage.  

Eric

Re: [Etherboot-developers] [PATCH] Fix CVS linuxbios support

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

>There are 2 big differences from the previous patch:
>1) I had 
>-movl initial_regs+24, %esp

Ah $initial_regs+24 you mean. Yes, that would confuse the CPU ok.

>+movl initial_regs+24, %esp
>in exit.
>2) I have moved all of the code that requires a pcbios to make
>   sense from start32.S into pcbios.S.
>   That requires many fewer ifdefs.
>   It is easy to verify exactly what I changed with diff
>   And it allows the makefile to do the conditional building.
>
>With these changes the LinuxBIOS support should stay clean
>and be easy to maintain for the forseeable future.

Thanks, that works fine for PCBIOS Network and Local booting now. Will
commit to Sourceforce CVS now.

[Etherboot-developers] [PATCH] Fix CVS linuxbios support

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

This isn't up at sourceforge as sourceforge is AWOL at the moment.

There are 2 big differences from the previous patch:
1) I had 
-movl initial_regs+24, %esp
+movl initial_regs+24, %esp
in exit.
2) I have moved all of the code that requires a pcbios to make
   sense from start32.S into pcbios.S.
   That requires many fewer ifdefs.
   It is easy to verify exactly what I changed with diff
   And it allows the makefile to do the conditional building.

With these changes the LinuxBIOS support should stay clean
and be easy to maintain for the forseeable future.

ftp://download.lnxi.com/pub/src/etherboot/etherboot-5.0.6rc3.lb.diff

Now I'm going to see if I can get the e1000 driver going as I found
an e1000 nic buried on my desk.

Eric

Re: [Etherboot-developers] [PATCH] initial support for loading images over etherboot...

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

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

> Hi Eric,
> 
> Just to let you know what's happening.
> 
> The first set of patches for ifdefing out gateA20, are ok, except for
> the patch to start32.S.  The patch to start32.S doesn't work for
> returning from Etherboot to the BIOS by pressing L. I think you missed
> restoring the registers after exit(). There was a typo there: entry32
> should be start32 in the other ifdef branch, so it must never have been
> assembled.

Sorry I tested that branch under LinuxBIOS I forgot the normal case.
I'll see if I can debug the return to the pcbios.

> The second set of patches are ok for tagged images, but break ELF images
> (mkelf format, not yours).  The program goes into hyperspace after
> loading the image and attempting to run it.  There were some typos which
> showed that the other ifdef branch had never been compiled.  I'll have
> to look at it later.

O.k. The second set was more a proof of concept than a serious
submission at this point.   Showing that everything could pretty
much be consolidated into a single common function was the interesting
and tricky thing there.


There is major bug in that I forgot to copy images that would
overwrite  etherboot into the buffer I reserved for them.   So the
major emphasis doesn't work.  But it at least shows how it 
could work.

I'm seriously puzzled that tagged images work and mknbi ELF images
don't.  What is passed is almost identical.  And the register and
stack contents must have been correct, if tagged images worked.  The
code is almost identical in mknbi for tagged and ELF images.  Perhaps
I missed an embedded pointer.

> The current state of the source files are in CVS.

Thanks I guess I'll have to do a cvs checkout and see what is going
on.

Especially with start32.S I really want to stay on the same track
as much as possible. 

Eric

Re: [Etherboot-developers] [PATCH] initial support for loading images over etherboot...

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

Hi Eric,

Just to let you know what's happening.

The first set of patches for ifdefing out gateA20, are ok, except for
the patch to start32.S.  The patch to start32.S doesn't work for
returning from Etherboot to the BIOS by pressing L. I think you missed
restoring the registers after exit(). There was a typo there: entry32
should be start32 in the other ifdef branch, so it must never have been
assembled.

The second set of patches are ok for tagged images, but break ELF images
(mkelf format, not yours).  The program goes into hyperspace after
loading the image and attempting to run it.  There were some typos which
showed that the other ifdef branch had never been compiled.  I'll have
to look at it later.

The current state of the source files are in CVS.

Re: [Etherboot-developers] proposed patch to speedup image loading

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

>I'd like to suggest a patch for nfs (and maybe tftp as well) downloads
>for etherboot.
>
>...
>
>I am planning to commit this as a patch to the FreeBSD port
>of etherboot, but maybe it could be interesting to integrate
>it into the standard etherboot sources.

If you wish I can add you to the developer list, then you can post
patches or check in versions into CVS. Send me your Sourceforge
username.

[Etherboot-developers] proposed patch to speedup image loading

[Luigi R. <ri...@ic...>]

Hi,
I'd like to suggest a patch for nfs (and maybe tftp as well) downloads
for etherboot.

As it is now, both protocols only allow one packet in flight, and
in case of a loss there is a long timeout (exponential backoff with
a base interval of 10 seconds). On paths where there is even some
small percentage of random loss (as it often happens in presence
of mixed 10/100 networks with underbuffered switches, and/or coax/utp
converters), booting is deadly slow.

I have been looking at a way to implement a window scheme similar
to TCP, but it would request too much restructuring of the code,
especially because the *download() routines assume in-order reception
of packets.

So i came up with a very simple change (attached) which should be
network-safe, yet quite effective and simple to implement.

The idea is to interpret previous successes in receiving a packet
as a 'right' to reduce the timeout for the next attempt to a small
value, whereas the expiration of a timeout drastically reduces our
right to do so. So, an occasional loss after a bunch of successes
will only stall the connection for a few ticks, but repeated losses
will quickly revert the behaviour to the standard exponential
backoff.

This way you partially compensate the fact that having only one
packet in flight the protocol is quite subject to timeouts.

Implementationwise, the whole code is basically four lines of C code: 
a static variable (tokens) in nfs.c::nfs_read() is incremented
on each success (up to some upper bound, say 256), and halved
on timeouts. The actual timeout value passed to await_reply()
is then shortened to 1/2s (or something short) whenever tokens >= 2.
By playing with the constants you can make the scheme more or
less aggressive, you get the idea...

Ideally, one could also try to add an RTT estimator in nfs_read()
so both the "short" timeout and the base timeout for the exponential
backoff are adaptive. That might take another 10-20 lines of
code i guess, probably with reasonably good benefits.

I am planning to commit this as a patch to the FreeBSD port
of etherboot, but maybe it could be interesting to integrate
it into the standard etherboot sources.

	cheers
	luigi

-----------------------------------+-------------------------------------
  Luigi RIZZO, lu...@ie...  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------


--- nfs.c.orig	Tue Mar 12 21:44:19 2002
+++ nfs.c	Tue Mar 12 23:07:32 2002
@@ -321,6 +321,14 @@
 	int retries;
 	long *p;
 
+	static int tokens=0;
+	/*
+	 * Try to implement some kind of window protocol in terms of
+	 * response to losses. On success receive, increment number of
+	 * tokens by 1 (top at 256). On failure, halve it.
+	 * When the number of tokens is > 2, use a very short timeout
+	 */
+
 	id = rpc_id++;
 	buf.u.call.id = htonl(id);
 	buf.u.call.type = htonl(MSG_CALL);
@@ -336,9 +344,14 @@
 	*p++ = 0;		/* unused parameter */
 	for (retries = 0; retries < MAX_RPC_RETRIES; retries++) {
 		long timeout = rfc2131_sleep_interval(TIMEOUT, retries);
+		if (tokens >= 2)
+			timeout = TICKS_PER_SEC/2;
+
 		udp_transmit(arptable[server].ipaddr.s_addr, sport, port,
 			(char *)p - (char *)&buf, &buf);
 		if (await_reply(AWAIT_RPC, sport, &id, timeout)) {
+			if (tokens < 256)
+				tokens++;
 			rpc = (struct rpc_t *)&nic.packet[ETH_HLEN];
 			if (rpc->u.reply.rstatus || rpc->u.reply.verifier ||
 			    rpc->u.reply.astatus || rpc->u.reply.data[0]) {
@@ -355,7 +368,8 @@
 			} else {
 				return 0;
 			}
-		}
+		} else
+			tokens >>= 1;
 	}
 	return -1;
 }

[Etherboot-developers] Automatically select the .rom file at boot time from a floppy : patch to Grub

[Jean-Jacques M. <jjm...@li...>]

Hello,

I am doing quite a number of tests on Etherboot these days, and
I have made a small patch to Grub (0.5.96.1) so that it selects
automatically the .rom file to load&boot from the devices that
are seen on the PCI bus.
As 1.44M is large enough to put several rom files, I can make
my tests on diverse NIC with only one floppy...

You can find the patch & a small Readme on : 

ftp://ftp.linbox.com/pub/lbs/src/patch_grub_etherboot

Hope it can help,

Regards,

-- 
Jean-Jacques Michel mailto:jjm...@li... 
Hardware Engineer - Linbox http://www.linbox.com
Technopôle Metz 2000 - 152 rue de Grigy - 57070 Metz - France
Tel : +33 (0)3 87 75 55 21 - Fax : +33 (0)3 87 75 19 26

Re: [Etherboot-developers] On-board eepro100

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

As described in the problem report of Yedidyah Bar-David, DHCP
request is not working, and the first DHCP request is done
in Etherboot, before GRUB can be loaded.

I often see the described effect, when the interrupt is not 
working, but etherboot does not use interrupts ...

But IMO it is a problem special to this one board. Check the
BIOS setup, PCI settings, etc, etc.....

With friendly regards
Christoph Plattner


Ken Yap wrote:
> 
> >Thanks, but sadly :-(, I just got a new machine, with the same STL2
> >board, which for some reason doesn't work with neither 4000 nor 10000.
> >It does hang much later, though - it manages to get the conf file
> >and open the menu, but hangs when doing dhcp (it does send dhcpdiscover,
> >but doesn't receive the servers dhcpoffer). Really weird. 2 others
> >with STL2 boards worked well.
> 
> Did you also remember to fix the same bug in the eepro100 driver in GRUB
> that comes from Etherboot?
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [Etherboot-developers] On-board eepro100

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

>Thanks, but sadly :-(, I just got a new machine, with the same STL2
>board, which for some reason doesn't work with neither 4000 nor 10000.
>It does hang much later, though - it manages to get the conf file
>and open the menu, but hangs when doing dhcp (it does send dhcpdiscover,
>but doesn't receive the servers dhcpoffer). Really weird. 2 others
>with STL2 boards worked well.

Did you also remember to fix the same bug in the eepro100 driver in GRUB
that comes from Etherboot?

[Etherboot-developers] Re: [Etherboot-users] On-board eepro100

[Yedidyah Bar-D. <di...@po...>]

Hi,

On Wed, Mar 06, 2002 at 11:41:09AM +1100, Ken Yap wrote:
> >Today I decided enough is enough, and after many hours of testing,
> >managed to boot both etherboot 5.0.5 and grub 0.91 on my on-board
> >eepro100.
> >
> >The only fix I made, in the end, was to add a 'udelay(4000)' just
> >before 'whereami ("set stats addr.");' in eepro100.c (line 533).
> 
> Ok, have changed it to udelay(10000). Evidently 10 us is not enough.
> Maybe someone miswrote or misread a data sheet. Nobody will notice 10
> ms during initialisation.  Thanks very much for the detective work.

Thanks, but sadly :-(, I just got a new machine, with the same STL2
board, which for some reason doesn't work with neither 4000 nor 10000.
It does hang much later, though - it manages to get the conf file
and open the menu, but hangs when doing dhcp (it does send dhcpdiscover,
but doesn't receive the servers dhcpoffer). Really weird. 2 others
with STL2 boards worked well.
This machine will only run Linux, so grub is not very important to me
(because I will boot it with pxelinux). I also won't have much time
to play with it, since it's being used most of the time (Actually,
if it will work well, it will be the server for http://www.cs.tau.ac.il,
with all of it on NFS). If I will have problems with other machines, I
will try to further investigate.

Anyway, thanks.

> 
> >BTW: the etherboot-5.0.5+megapatch (5.0.6 rc 2) didn't work at all.
> >The machine has frozen during boot with a cleared screen.
> 
> The problem seems to have been found, hopefully.
:-)
> 
> _______________________________________________
> Etherboot-users mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-users

	Didi

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

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

> >> Yes, that's how it works. Marty is also a list admin and he must have
> >> approved the posting, as I was busy today.
> >
> >Given the size restrictions is there another form you would
> >rather I send patches in?
> 
> For large postings, Markus's idea of putting it on a web site and
> posting the URL is a good one. In fact the web site could be the
> patch area of the Etherboot Sourceforge site if you prefer. I've just
> added you as a developer.

Given the one place to look nature of that idea it sounds good.
Next time I have a moment I'll take a look.

Eric

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

>> Yes, that's how it works. Marty is also a list admin and he must have
>> approved the posting, as I was busy today.
>
>Given the size restrictions is there another form you would
>rather I send patches in?

For large postings, Markus's idea of putting it on a web site and
posting the URL is a good one. In fact the web site could be the
patch area of the Etherboot Sourceforge site if you prefer. I've just
added you as a developer.

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

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

> Yes, that's how it works. Marty is also a list admin and he must have
> approved the posting, as I was busy today.


Given the size restrictions is there another form you would
rather I send patches in?

Eric

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

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

> >This looks like a typical message generated by the MailMan mailing list 
> >processor. It tells you that your message is currently frozen until the mailing
> 
> >list administrator (Ken?) either approves or denies it. I am not quite sure how
> 
> >Sourceforge runs its mailing lists, so I do not know if it is possible to raise
> 
> >the message size limit, but a limit of 40kB (or even less) tends to work well
> to
> 
> >keep bogus posts and viruses from getting onto the list. I usually suggest that
> 
> >rather than posting the entire patch you should just send a link to some places
> 
> >where you made the patch available. If you don't want to do this, then I guess
> 
> >you'll have to wait for the administrator to approve your posting.
> 
> Yes, that's how it works. Marty is also a list admin and he must have
> approved the posting, as I was busy today.

OK I was just very suprised that my small patches were bouncing.

At 40K that means a dense 500 line post gets bounced, and I was
very suprised as I have sent bigger stuff before.

Normally I'm not that verbose but I have seen people who could be.

Eric

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

>This looks like a typical message generated by the MailMan mailing list 
>processor. It tells you that your message is currently frozen until the mailing 
>list administrator (Ken?) either approves or denies it. I am not quite sure how 
>Sourceforge runs its mailing lists, so I do not know if it is possible to raise 
>the message size limit, but a limit of 40kB (or even less) tends to work well to 
>keep bogus posts and viruses from getting onto the list. I usually suggest that 
>rather than posting the entire patch you should just send a link to some places 
>where you made the patch available. If you don't want to do this, then I guess 
>you'll have to wait for the administrator to approve your posting.

Yes, that's how it works. Marty is also a list admin and he must have
approved the posting, as I was busy today.

Re: [Etherboot-developers] Re: Your message to Etherboot-developers awaits moderator approval

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

This looks like a typical message generated by the MailMan mailing list 
processor. It tells you that your message is currently frozen until the mailing 
list administrator (Ken?) either approves or denies it. I am not quite sure how 
Sourceforge runs its mailing lists, so I do not know if it is possible to raise 
the message size limit, but a limit of 40kB (or even less) tends to work well to 
keep bogus posts and viruses from getting onto the list. I usually suggest that 
rather than posting the entire patch you should just send a link to some places 
where you made the patch available. If you don't want to do this, then I guess 
you'll have to wait for the administrator to approve your posting.


Markus

Eric W. Biederman wrote:
> eth...@li... writes:
> 
> 
>>Your mail to 'Etherboot-developers' with the subject
>>
>>    [PATCH] initial support for loading images over etherboot...
>>
>>Is being held until the list moderator can review it for approval.
>>
>>The reason it is being held:
>>
>>    Message body is too big: 44353 bytes but there's a limit of 40 KB
>>
>>Either the message will get posted to the list, or you will receive
>>notification of the moderator's decision.
>>
> 
> Does anyone understand this 40K message size limit?
> I don't seem to be able to generate a patch smaller than this.
> 
> Eric
> 
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 


-- 
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] Re: Your message to Etherboot-developers awaits moderator approval

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

eth...@li... writes:

> Your mail to 'Etherboot-developers' with the subject
> 
>     [PATCH] initial support for loading images over etherboot...
> 
> Is being held until the list moderator can review it for approval.
> 
> The reason it is being held:
> 
>     Message body is too big: 44353 bytes but there's a limit of 40 KB
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

Does anyone understand this 40K message size limit?
I don't seem to be able to generate a patch smaller than this.

Eric

Re: [Etherboot-developers] megapatch from 5.0.5 to 5.0.6rc2

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

ebi...@ln... (Eric W. Biederman) writes:

> ke...@us... (Ken Yap) writes:
> 
> > >Ken I finally had a chance to look at this patch.  The updated
> > >support code for LinuxBIOS didn't make it in.  Do you need
> > >me to resend the patch?.   The code presently in etherboot no longer
> > >works so this is important.
> > 
> > Yes, please.
> 
> OK it is sent. I sent it directly because the list message
> filter didn't like it.  Too many ifdefs..

Grr that patch had one minor bug.

I called entry32 instead of start32 from the 16bit startup code.

Eric