etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER

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

>Dig all you want, but I still like my HTTP idea :)

So do I but I think it should be done by writing a server side TFTP to
HTTP proxy. I might knock up a Perl version sometime. That might scare
some of you into doing it first with a more readable language. :-)

Re: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER

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

On Fri, 1 Aug 2003, Ken Yap wrote:

> >>     DHCP response received from xx.xx.xx.xx but no filename specified, igno
> >red.
> >> 
> >> I have a feeling this would help people debug more efficiently. In the olde
> >r
> >> versions, I'm guessing there was a default filename that would then fail to
> >> load, and which would leave some trace in the logs.
> >> 
> >> What say you?
> >
> >Sure.  The only question I have is do we want to rate limit the message,
> >in case we get a lot of them.
> >
> >The only bad side effect I can see is the possibility that printing the
> >message would cause us to drop the valid response we are looking for.
> 
> Ok how about in 5.3 or 5.2.1, put it in as a compile option
> WARN_NO_TFTP_FILENAME, default on for newbies and document that it
> should be turned off in production.
> 
> Are Eric and I the only people who understand that Etherboot doesn't
> have deep latency or memory resources? All these things such as
> suggestions of HTTP, use of recursive routines, etc. Sorry can't resist
> a dig. :-)

Dig all you want, but I still like my HTTP idea :)

Jim.


> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

-- 

Re: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER

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

>>     DHCP response received from xx.xx.xx.xx but no filename specified, igno
>red.
>> 
>> I have a feeling this would help people debug more efficiently. In the olde
>r
>> versions, I'm guessing there was a default filename that would then fail to
>> load, and which would leave some trace in the logs.
>> 
>> What say you?
>
>Sure.  The only question I have is do we want to rate limit the message,
>in case we get a lot of them.
>
>The only bad side effect I can see is the possibility that printing the
>message would cause us to drop the valid response we are looking for.

Ok how about in 5.3 or 5.2.1, put it in as a compile option
WARN_NO_TFTP_FILENAME, default on for newbies and document that it
should be turned off in production.

Are Eric and I the only people who understand that Etherboot doesn't
have deep latency or memory resources? All these things such as
suggestions of HTTP, use of recursive routines, etc. Sorry can't resist
a dig. :-)

Re: [Etherboot-developers] Re: 3c900-tpo hang after DHCPOFFER

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

>Is anyone else getting the feeling we might want to output a message 
>saying:
>
>    DHCP response received from xx.xx.xx.xx but no filename specified, 
>ignored.

I'm in two minds about this. On one hand it might help show the problem,
but on the other hand it might take Etherboot's attention away from an
offer which is usable, plus it might get annoying in networks where it's
expected that there will be bogus offers. There are a whole bunch of
difficulties that must be overcome in setting up a diskless boot, such
as getting DHCP right, TFTP right, etc and this is only one problem. I'm
inclined to think a better newbie document would do more good. Perhaps
we should collaborate with LTSP in writing such a document which can be
published by both projects.

Re: [Etherboot-developers] Re: [Etherboot-users] 3c900-tpo hang after DHCPOFFER

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

Hello Marty,

>>> Searching for server (DHCP)...
>>> ..
>> Please specify a "filename" in dhcpd.conf.

> Is anyone else getting the feeling we might want to output a message 
> saying:

>     DHCP response received from xx.xx.xx.xx but no filename specified, 
> ignored.

> I have a feeling this would help people debug more efficiently. In the 
> older versions, I'm guessing there was a default filename that would 
> then fail to load, and which would leave some trace in the logs.

> What say you?

Put it like
    Received offer from 192.168.1.1 for 192.168.1.5 without filename
and also a similar statement
    Received offer from 192.168.1.1 for 192.168.1.5 with filename "/foo"
and it's ok for me. It shall not look like a permanent error, as there
is more than one multi-dhcpd-setup out there. Admins however should be
able to manage that problem with this information on screen.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: [Etherboot-developers] Re: [Etherboot-users] 3c900-tpo hang after DHCPOFFER

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

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

> On Thursday, July 31, 2003, at 11:41  AM, Anselm Martin Hoffmeister wrote:
> >> Searching for server (DHCP)...
> >> ..
> > Please specify a "filename" in dhcpd.conf.
> 
> Is anyone else getting the feeling we might want to output a message saying:
> 
>     DHCP response received from xx.xx.xx.xx but no filename specified, ignored.
> 
> I have a feeling this would help people debug more efficiently. In the older
> versions, I'm guessing there was a default filename that would then fail to
> load, and which would leave some trace in the logs.
> 
> What say you?

Sure.  The only question I have is do we want to rate limit the message,
in case we get a lot of them.

The only bad side effect I can see is the possibility that printing the
message would cause us to drop the valid response we are looking for.

Eric

Re: [Etherboot-developers] stumbling block for 5.2

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

On Wednesday, July 30, 2003, at 11:12  AM, Ken Yap wrote:
> ... Marty and anybody else with a moment to spare, could you please
> check out the latest changes and test the ROM version (really burn it 
> on
> an EPROM or EEPROM, not the floppy simulation) and check that the Quit
> command returns control to the BIOS to boot the next device in the BIOS
> list? It works for this ISA NIC of mine but I'd like confirmation with
> PCI NICs.

I would, except I just shipped all my ROM burning stuff to LinuxWorld 
Expo :):)

I'll be in SF Sunday night, and I can probably test it then. I spoke to 
Markus, and he'll be around. It's been a year since we got excellent 
German food!

Sounds like we're getting closer. I may have some hacking time Sunday 
and Monday. Tuesday morning is when the exhibits start. I'll send out a 
message when I get the webcam up.

Speaking of which, anybody who wants to wander by LinuxWorld Expo next 
week in San Francisco ( http://www.linuxworldexpo.com ), we're in the 
.ORG Pavilion, booth #2. We have some free exhibit hall passes, and it 
should be fun as always.

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] Re: [Etherboot-users] 3c900-tpo hang after DHCPOFFER

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

On Thu, 31 Jul 2003, Marty Connor wrote:

> On Thursday, July 31, 2003, at 11:41  AM, Anselm Martin Hoffmeister 
> wrote:
> >> Searching for server (DHCP)...
> >> ..
> > Please specify a "filename" in dhcpd.conf.
> 
> Is anyone else getting the feeling we might want to output a message 
> saying:
> 
>     DHCP response received from xx.xx.xx.xx but no filename specified, 
> ignored.
> 
> I have a feeling this would help people debug more efficiently. In the 
> older versions, I'm guessing there was a default filename that would 
> then fail to load, and which would leave some trace in the logs.
> 
> What say you?

I say "yes".

Jim McQuillan
ja...@Lt...




> 
> Marty
> 
> 

-- 

[Etherboot-developers] Re: [Etherboot-users] 3c900-tpo hang after DHCPOFFER

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

On Thursday, July 31, 2003, at 11:41  AM, Anselm Martin Hoffmeister 
wrote:
>> Searching for server (DHCP)...
>> ..
> Please specify a "filename" in dhcpd.conf.

Is anyone else getting the feeling we might want to output a message 
saying:

    DHCP response received from xx.xx.xx.xx but no filename specified, 
ignored.

I have a feeling this would help people debug more efficiently. In the 
older versions, I'm guessing there was a default filename that would 
then fail to load, and which would leave some trace in the logs.

What say you?

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] etherboot

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

Hello Peter,

> Dear etherboot-developers

>         I am a fan of Disk-less system on Linux. I download the 'etherboot 5.0.6' 

Do yourself a favor and download the latest 5.0.11 release from
http://www.etherboot.org/distribution.html

If you intend to do changes that are "experimental" or so, you should
do them to etherboot 5.1 (the development branch), as 5.0 is in
"stable, only bugfixes allowed" mode - it means there are no new
features expected for 5.0

> source codeform www.etherboot.org and try to do some modify. Would you mind 
> to tell 
> me some useful information about what I concern: I want to know where the 
> sources
> are 'load the boot-image and try to boot it on client side' , that's which 
> file 
> and subroutine?

That differs between 5.0 and 5.1, and then you should know that these
'load file & boot' make up most of the sense of etherboot! It is split
over several files, depending on which part. There is ae.g. a file
nfs.c for downloading via NFS.

Perhaps you can tell us what your plans are, so we can help you more
specifically.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

[Etherboot-developers] etherboot

[liu p. <pen...@ho...>]

Dear etherboot-developers，

	I am a fan of Disk-less system on Linux. I download the 'etherboot 5.0.6' 
source codeform www.etherboot.org and try to do some modify. Would you mind 
to tell 
me some useful information about what I concern: I want to know where the 
sources
are 'load the boot-image and try to boot it on client side' , that's which 
file 
and subroutine?

Thanks a lot!

Best regards to you and your family!
  
                                yours truly Peter Roc
                                      07.31.2003

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  

Re[2]: [Etherboot-developers] PCMCIA

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

Hello Timothy,

>> This is not just a status announcement. I'd like advice on some points
>> in integration. Up to now, I defined CONFIG_PCMCIA (like CONFIG_ISA),
>> but propably the latter is needed for PCMCIA anyway. Not talking about
>> CARDBUS of course, but I don't have a CARDBUS card neither compatible

> Any idea how much work is left to implement cardbus?

Not too much, I think. It seems to be very PCI like, so you usually
activate the cardbus chip and the devices behind behave quite like PCI
hotplug'ed devices. They won't be configured (BIOS-side) probably, but
etherboot seems to be able to handle that (see VMware amd lance card,
which is not activated either and works fine).

>> Is there any sense in activating more than the first found PCMCIA NIC?

> Maybe, but I believe Etherboot just uses the first NIC it finds anyway.

Just the case you own one NE2k based and one 3com like board and
switch them between slots (e.g. NE2k has BNC transceiver, 3com board
is TP-only modem combo, which is quite realistic) - you only want to
use the ne2k board, but it is once the first, once the second board...
OK, this is constructed. For simplicitie's reasons, I'll only
implement activation of the first NIC-like board found (which is
stored inside the CIS area on the board; there are NIC-like,
modem-like, VGA-like...)

>> Is there any reason to use non-NIC PCMCIA devices in etherboot?

> Possibly, but I would concentrate on the stuff required for NICs.  It
> will be very cool if we can finally bring the PCMCIA NICs into the
> fold...

That's what I though too :-)

>> Does someone know about special requirements to PCMCIA enabler stuff,
>> except giving a NIC the right power & io address? Can I skip the work

> In the ISA_PNP support that I brought in for the 3c515 NIC, I ignore the
> Interrupt activation.  The NIC did not seem to mind and neither did
> Etherboot.

Fine. I'll just give it a try.

>> I'll surely release to CVS before leaving for a 6-day-holiday this
>> friday, so perhaps (well, it depends :-) you will have some working
>> demo stuff on LWE, but I cannot guarantee.

> Sounds like a lot of work.  I can't wait to see it hit the cvs.  

It *is* a lot of work. Mainly porting the pcmcia-cs stuff from the
linux kernel, stripping unused stuff, but there is so much nesting
(it's a three-layer-system, reducing it to one!) and
kernel-function-calls that it yet started costing me some hairs.

> Ken, as 5.2 is getting close will this be 5.3 code?

Will be 5.3 definitively. I delayed it to after my holidays as I got a
"reminder" from taxes to hand in my 2002 tax sheets till tomorrow :-(. So
it will not be ready for LWE, but as I expect 5.3 to be open by then,
I can just commit it freshly into 5.3 CVS when back, in a week or so.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

RE: [Etherboot-developers] PCMCIA

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

> This is not just a status announcement. I'd like advice on some points
> in integration. Up to now, I defined CONFIG_PCMCIA (like CONFIG_ISA),
> but propably the latter is needed for PCMCIA anyway. Not talking about
> CARDBUS of course, but I don't have a CARDBUS card neither compatible

Any idea how much work is left to implement cardbus?

> Is there any sense in activating more than the first found PCMCIA NIC?

Maybe, but I believe Etherboot just uses the first NIC it finds anyway.

> Is there any reason to use non-NIC PCMCIA devices in etherboot?

Possibly, but I would concentrate on the stuff required for NICs.  It
will be very cool if we can finally bring the PCMCIA NICs into the
fold...

> Does someone know about special requirements to PCMCIA enabler stuff,
> except giving a NIC the right power & io address? Can I skip the work

In the ISA_PNP support that I brought in for the 3c515 NIC, I ignore the
Interrupt activation.  The NIC did not seem to mind and neither did
Etherboot.

> I'll surely release to CVS before leaving for a 6-day-holiday this
> friday, so perhaps (well, it depends :-) you will have some working
> demo stuff on LWE, but I cannot guarantee.

Sounds like a lot of work.  I can't wait to see it hit the cvs.  

Ken, as 5.2 is getting close will this be 5.3 code?

Tim

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

[Etherboot-developers] PCMCIA

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

Hi list,

nearing LWE, I had planned to release PCMCIA support for i82365
chipset, but I'm not sure if I will do this in time. It's not in CVS
(yet) as there's more than one design issue to be handled, which I'd
prefer to have done before "public" (you :-) work on it.

This is not just a status announcement. I'd like advice on some points
in integration. Up to now, I defined CONFIG_PCMCIA (like CONFIG_ISA),
but propably the latter is needed for PCMCIA anyway. Not talking about
CARDBUS of course, but I don't have a CARDBUS card neither compatible
laptop anyway, I'm working on a 486 with some 10M really old NICs.
Where in code should I best place the pcmcia_init() call (which loads
support for the mainboard part of PCMCIA, configures and activates the
first found PCMCIA NIC)? Where best to place the pcmcia_deinit() that
puts everything in status 'off'? - Perhaps there should also be an
option to not deinit the pcmcia device. My laptop for example has no
DOS "point enabler" software, so that NICs cannot be used with DOS,
only with winblows (which knows about enabling PCMCIA). They seem -
except that PCMCIA stuff - to be NE2000 compatible. I'm quite sure
they will interface seemlessly to the etherboot NE2000 module, but am
not far enough to test this. And DOS could work after having them
point-enabled...

Is there any sense in activating more than the first found PCMCIA NIC?
Is there any reason to use non-NIC PCMCIA devices in etherboot?
Does someone know about special requirements to PCMCIA enabler stuff,
except giving a NIC the right power & io address? Can I skip the work
for interrupt activation or is there any NIC out there that needs it
(and is available as PCMCIA)? Do we need an option to configure cards
other than to their standard configuration*?

*Inside most (compliant PCMCIA2.x) card there is a Card Information
Structure holding several (at least 1) possible ioport/irq/... tuples
one of which can be selected. I'd like to just activate the first one,
without too cmplicated (or without any at all) checking for
plausibility - I expect the first tuple to be 0x300/irq5 or similar in
NE2000 clones anyway. However having written that config to console
would clarify this point. Is there any chance to detect which ports
could be used yet? I don't expect a laptop to use e.g. ports 0x300;
0x320; 0x240.

FYI - what is working yet:
o Detection of motherboard chipset (Intel 82365, compatible CIRRUS and
  VADEM chipsets, mainly those boards supported by the same linux kernel
  driver) - only tested with my laptop's VADEM VG-468 chip.
o Detection of "used" aka "card-inside" slots
o The logic behind CIS, tuple reading and so on

What needs work - and that probably is all:
o Write and read accesses to CIS

A pity that CIS is so f**ine complicated. I'm still investigating
where between all this multiplexing stuff the CIS hides, but I hope to
catch it this evening.

I'll surely release to CVS before leaving for a 6-day-holiday this
friday, so perhaps (well, it depends :-) you will have some working
demo stuff on LWE, but I cannot guarantee.

Best regards,
  Anselm Martin Hoffmeister
  Stockholm Projekt Computer-Service
  <an...@ho...>

Re: [Etherboot-developers] stumbling block for 5.2

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

>The reason zeroing BSS wipes out the return path is simple: BSS contains
>the 32 bit stack with the return address on it! Now to figure out what
>to do about this.

Ok, I've fixed this. I put the protected mode stack in its own segment
between _ebss and _end, so that it isn't zeroed at the beginning of
main.

But that's not all that was needed. At the start of comprefix.S I
changed %ss to somewhere out of Etherboot's way since the real mode
stack with the return address was being clobbered by Etherboot too.

So now it returns to the DOS prompt ok, but DOS doesn't quite work right
after that, I don't know if this is because of the old FreeDOS I'm using
or Etherboot is messing up FreeDOS another way, possibly via the GDT. If
somebody could try .com images with another DOS it would be appreciated.
The latest sources are in CVS.

And now the ROM version exits to the BIOS ok too after the stack segment
fix. Marty and anybody else with a moment to spare, could you please
check out the latest changes and test the ROM version (really burn it on
an EPROM or EEPROM, not the floppy simulation) and check that the Quit
command returns control to the BIOS to boot the next device in the BIOS
list? It works for this ISA NIC of mine but I'd like confirmation with
PCI NICs.

I will release 5.1.10 (release candidate 2) in a day or two.

RE: [Etherboot-developers] tlan driver - Working in 5.1

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

> I updated my CVS this morning to the latest, and tested a version 48
> TLAN card.
> 
> I was able to boot intermittently, but not reliably in 5.1.9. I set

I assume that you mean that you used the most recent cvs, not the 5.1.9
tarball.

> debug to 1, and did some more testing, but a 5am power failure
> interrupted my train of thought. When it failed, it seemed to die
> trying to do a transmit. I am wondering if it needs a little more time
> after reset() to settle down. I need to look at the kernel driver to
> see how they handle it. Since they use interrupts, they often set an

That could be the reason I needed the udelay in the transmit.

> alarm clock for a second in the future and relinquish control for a
> second or two. We might need to just put a little wait in there. Just
> thinking out loud...

You may be right on that.  Maybe I need to move the delay from the
transmit to the reset.  You do have the version with udelay(5) in the
transmit correct?

> I'll give it a another try soon. I appreciate your effort in writing
it.

No problem, I am please to offer what little I can.

Tim

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

Re: [Etherboot-developers] tlan driver - Working in 5.1

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

On Sunday, July 27, 2003, at 09:23  AM, Timothy Legge wrote:
> Ken and Marty, can you do a quick test with you cards?  Marty, please
> note the revision number of the chip as displayed on screen.  If it is
> something different than 35 or 48 please let men know.
> Tim

I updated my CVS this morning to the latest, and tested a version 48 
TLAN card.

I was able to boot intermittently, but not reliably in 5.1.9. I set 
debug to 1, and did some more testing, but a 5am power failure 
interrupted my train of thought. When it failed, it seemed to die 
trying to do a transmit. I am wondering if it needs a little more time 
after reset() to settle down. I need to look at the kernel driver to 
see how they handle it. Since they use interrupts, they often set an 
alarm clock for a second in the future and relinquish control for a 
second or two. We might need to just put a little wait in there. Just 
thinking out loud...

I'll give it a another try soon. I appreciate your effort in writing it.

Marty

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

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

Re: [Etherboot-developers] stumbling block for 5.2

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

>>Ok, I've found what was killing the Quit from Etherboot. It was the
>>zeroing of the BSS in main. Now I have to work out what it was zeroing
>>and why it was zeroing too much.
>
>Hmm, I run a .com image and print out _bss and _ebss and they are:
>0002593C and 0002E5B0 but when Etherboot relocates itself, it says _text
>is from 000280A0 to 00036650. So BSS is partly below and partly within
>_text? What does that mean? You there Eric?

Ah ok, got it now. 2593C and 2E5B0 are the virtual addresses since
Etherboot is linked to start at 20000. 280A0 and 36650 are the physical
locations where Etherboot lives. 36650-280A0=E5B0.

The reason zeroing BSS wipes out the return path is simple: BSS contains
the 32 bit stack with the return address on it! Now to figure out what
to do about this.

Re: [Etherboot-developers] stumbling block for 5.2

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

>Ok, I've found what was killing the Quit from Etherboot. It was the
>zeroing of the BSS in main. Now I have to work out what it was zeroing
>and why it was zeroing too much.

Hmm, I run a .com image and print out _bss and _ebss and they are:
0002593C and 0002E5B0 but when Etherboot relocates itself, it says _text
is from 000280A0 to 00036650. So BSS is partly below and partly within
_text? What does that mean? You there Eric?

Re: [Etherboot-developers] stumbling block for 5.2

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

>The problem I'm facing now is that the Quit function of Etherboot
>(formerly called Local) doesn't return control to the caller, which is
>DOS in the case of .com images, and the BIOS in the case of .zrom
>images. It jumps off into hyperspace and often reboots the machine.
>.zdsk images don't really have an environment to return to so Quit is
>arguably undefined. This needs to be fixed before release, otherwise
>Etherboot doesn't follow the BIOS boot order, which means one cannot
>quit Etherboot to let the BIOS boot from floppy or disk.

Ok, I've found what was killing the Quit from Etherboot. It was the
zeroing of the BSS in main. Now I have to work out what it was zeroing
and why it was zeroing too much.

[Etherboot-developers] Etherboot 5.0.11 (production) released

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

I have released Etherboot 5.0.11 at http://www.etherboot.org/

This is the last planned release of the 5.0 series. There may be bug fix
releases in the future, but no further development will be done on 5.0.
Bug fixes, and backports that don't disrupt the structure of the code
will be accepted. They might be provided in the form of patches via the
patch manager area on Sourceforge, and the EXTRAVERSION macro might be
used for identifying patched versions instead of bumping up the minor
version; it depends.

There is also an accompanying Etherboot-doc 5.0.11 at Sourceforge.

Changes since 5.0.10:

+ Fix for correct SMC8416 detection.

+ Alignment bug fix for the 3c90x contributed by Neil Newell.

+ Timothy Legge (I think) fixed up PCNET32 IDs.

+ Patch from Axel Dittrich to allow timeout to be changed to a fixed
value for peer-to-peer setups where the exponential backoff is not
suitable.

+ Backport of tlan driver from 5.1 by Timothy Legge.

+ Support for symlinks on NFS mounts by Anselm Martin Hoffmeister.

+ 82562EZ ID provided by Samuel Clements.

MD5 sums:

f23e90c9e33916fb1f0298ef67810b05  etherboot-5.0.11.tar.bz2
979d96e1678c535fa2ead5a02a93e662  etherboot-5.0.11.tar.gz

SHA1 sums:

b7ec25ea6895ae33aba673d9be95c23202e536ff  etherboot-5.0.11.tar.bz2
ca530a03a6addcd2e81b492780122bc4933ad2cb  etherboot-5.0.11.tar.gz

[Etherboot-developers] First cut on limited tagged image support for grub (0.93)

[Hans-Peter J. <hp...@ur...>]

[just want to let you know here, too]

with the attached patch, grub is able to load tagged images (at least 
those created with mknbi-dos). Tagged linux images aren't supported 
yet. Also some error handling is missing. grub is a real replacement 
for etherboot menus for me now.

Cheers,
Pete

[Etherboot-developers] stumbling block for 5.2

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

Ok, I've fixed up a few more errors in the build rules. The .com rule
was missing a start16.bin. Now I can run a .com Etherboot from DOS.

The problem I'm facing now is that the Quit function of Etherboot
(formerly called Local) doesn't return control to the caller, which is
DOS in the case of .com images, and the BIOS in the case of .zrom
images. It jumps off into hyperspace and often reboots the machine.
.zdsk images don't really have an environment to return to so Quit is
arguably undefined. This needs to be fixed before release, otherwise
Etherboot doesn't follow the BIOS boot order, which means one cannot
quit Etherboot to let the BIOS boot from floppy or disk.

Somewhere in start16 or start32, the return path is botched. The C main
seems ok, I've printf'ed it to the point of returning from main. Does
vmware allow one to trace what's happening in machine code after that?

I'm testing with a PCI/PnP BIOS but booting an ISA card if that makes
any difference.

I'd appreciate some help with this, while I edit the 5.2 docs some more.
If somebody wants to get their teeth into this, you'll need the latest
from CVS, which has several bug fixes already.

RE: [Etherboot-developers] tlan driver - Working in 5.0

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

> Ok, it'll be in about 8 hours time, I don't have the hardware in front
> of me now. If it works are you happy to let me release 5.0.11 and put
> 5.0 into maintenance mode?

No objections, the sooner it gets in a release version the sooner I may
get bug reports...

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

Re: [Etherboot-developers] tlan driver - Working in 5.0

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

>I committed another change to the 5.0 (and 5.1) drivers.  They now work
>in both versions.  I had to add a udelay(5) to the Transmit for the
>revision 48 card that I have.  It only seemed to be required for 5.0 but
>I did not bother making it revision or version specific.
>
>Ken, if you could test the card you have, I would be interested in
>knowing whether your card requires the delay in 5.0.

Works fine. I didn't test it without the delay. I have no objections to
leaving the delay in, just in case; it's not a noticeable delay.

Will release 5.0.11 tomorrow. Any developers with other concerns, speak
now or hold your peace. The CVS version can be viewed for the current
state.