etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] etherboot Ver. 4.7.23

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

|I'd like to know why Etherboot 4.7.23 obviously is the only version
|which is working fine on MachZ together with an Intel EtherCard. When

Do you mean it works with both the eepro100 and the 82559er or that it
works with the eepro100 only.

In other words, please fill in this table:

		<4.7.23		4.7.23		4.7.24
eepro100	no		yes		?
82559er		no		?		?

|using an eepro100 I got full functionality but using a 82559er (onboard)
|I just got a prompt and the hardware was not working.
|While working on this problem 2 questions did arise:
|
|1. What is the the difference in the software between 82559er and 82559?

None in Etherboot at least, the driver detects both hardware equally
well. But perhaps it doesn't handle the 82559er quite as well as hoped.
Does it wait for a DHCP server reply? That sounds like a media detection
problem.

|2. What could be the reason that 4.7.23 is the only version which is
|'more or less' working on my board?

When you say it's the only version working, I take it you have also
tried 4.7.24? Because I have a report that 4.7.24 is very PnP comformant
now and fixed a serious bug in 4.7.23.

[Etherboot-developers] etherboot Ver. 4.7.23

[Volker S. <Vol...@da...>]

Hi

I'd like to know why Etherboot 4.7.23 obviously is the only version
which is working fine on MachZ together with an Intel EtherCard. When
using an eepro100 I got full functionality but using a 82559er (onboard)
I just got a prompt and the hardware was not working.
While working on this problem 2 questions did arise:

1. What is the the difference in the software between 82559er and 82559?
2. What could be the reason that 4.7.23 is the only version which is
'more or less' working on my board?

Volker Stark
Research & Development
DaTARIUS Technologies GmbH
Tel: +43 5672 206 614
Fax: +43 5672 206 8 614
http://www.datarius.com

Re: [Etherboot-developers] Gotcha in 4.7.24

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

|I just compiled 4.7.24 and at first it hiccuped because I had 
| -DEMERGENCYDISKBOOT
|and not
| -DTAGGED_IMAGE
|
|The problem is that void gateA20_unset(void) only depends on -DTAGGED_IMAGE.

Thanks, my oversight. It now depends on defined(TAGGED_IMAGE) ||
defined(FLOPPY).

[Etherboot-developers] Re: [Etherboot-users] Award rom lister

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

|Here is a cleaned up version of my award rom decoder, now that I have
|used this reverse engineering to get etherboot into the curdls
|motherboard. 
|
|If someone wants they can build now take lharc and my program
|and build an opensource version of cbrom...

Thanks, I'll put that in contrib/. Any preferred name for it?

[Etherboot-developers] Gotcha in 4.7.24

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

I just compiled 4.7.24 and at first it hiccuped because I had 
 -DEMERGENCYDISKBOOT
and not
 -DTAGGED_IMAGE

The problem is that void gateA20_unset(void) only depends on -DTAGGED_IMAGE.

Eric

[Etherboot-developers] patch for scriptable tftp

[David L. P. <pa...@li...>]

Mark,

Sorry the turnaround on this was so bad, I was in the middle of
upgrading to a new laptop.

This patch applies to netkit-tftp-0.17, which is what you'll find in
recent redhat.  It adds a new executable, 'ptftp' (Put tftp).  You then
create a link to it with the name 'gtftp' (Get).  I haven't written a
manpage, but it prints a usage message and it's pretty trivial.  Note
that it does NOT take an argument for the local filename, so it always
uses stdin/stdout.  Also, if you specify the port as the last arg, it
won't try to look for /etc/services.

As I said, the 'tftp' included w/ busybox seems to fall down from time
to time on large transfers (at least on my network).  This one has been
reliable for me so far, and is still pretty small.

Another note: 'gtftp .... | tar xzv' was unreliable for me with the
busybox implementation of 'tar xzv'.  My workaround was just to download
the file then untar it.

have fun,
	David

Mark Atwood wrote:
> 
> "David L. Parsley" <pa...@li...> writes:
> > Mark Atwood wrote:
> >
> > > And isn't the kernel still in "initrd mode", wanting to do a
> > > pivot/init instead of halting the system as soon as that "initial
> > > process" dies?
> >
> > No, by supplying a root device of /dev/ram, the kernel assumes that the
> > initrd ramdisk is the true root filesystem, and either uses the
> > command-line supplied init or looks for /sbin/init.  Then, using
> > pivot_root, you can change the root filesystem whenever you like - but
> > usually just once during boot.
> 
> Excellent. This needs to be documented somewhere better. (Well, with
> mailling list archives, I guess it just was!)
> 
> >
> > Let me know if you want my tftp patches.  It makes about a 10k
> > dynamically-linked binary, but that's not too bad.
> 
> Please.
> 
> --
> Mark Atwood   | I'm wearing black only until I find something darker.
> mr...@po... | http://www.pobox.com/~mra

Re: [Etherboot-developers] 4.7.2x Failed to boot local

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

> It's an oversight. I know they exist but haven't come across any ISA PNP
> NICs myself, and these can be set to non-PNP mode and use legacy ROMs
> anyway. If you wish to fix this please go ahead.

I'll look into it.  My concern here was more that anyone using an ISA card
(or a dumbed-down PNP ISA) card is currently shut out of using the BIOS boot
spec hook.  That means that they would have to rely on chaining into INT19H,
which is comparatively inflexible, and has it's own set of problems.

I will have to see if I can kludge a flash device onto an ISA card I have so
I can test this.

Robb.

[Etherboot-developers] Mknbi 1.2-0 (production) released

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

I have released mknbi 1.2-0 at http://etherboot.sourceforge.net/
and soon in the download areas. It's available as a tarball, RPMs and
DEBs.

This is the same as mknbi-1.1-1, I'm just formally making it a
production release. So you don't have to update if you are already using
1.1-1.

Re: [Etherboot-developers] 4.7.2x Failed to boot local

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

>I have the following additional comments:
>1) Boot failure recovery should _NOT_ invoke INT 19h if "NOINT19H" was
>defined (this code is at line 397 in v4.7.23 loader.S).  It should instead
>return to the system BIOS via "retf", since it will have grabbed control via
>the option ROM init entry at offset 3.

Thanks, will fix. However very few people use NOINT19H as it's not
recommended, it bypasses BIOS initialisation of other devices. Only
people with weird BIOSes (e.g. SBCs) need this.

>2) Current structure does not allow for building non-PCI ROMs, but with PNP
>enabled (i.e., ISA PNP).  Is this an oversight, or is it assumed that
>etherboot ROMs for an ISA PNP card would simply ignore the PCI links?

It's an oversight. I know they exist but haven't come across any ISA PNP
NICs myself, and these can be set to non-PNP mode and use legacy ROMs
anyway. If you wish to fix this please go ahead.

Re: [Etherboot-developers] 4.7.2x Failed to boot local

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

Further to previous email (with wrong subject "Re: [Etherboot-developers]
rtl_disable and random kernel crash. "),  I have been digging further into
boot local failures.

I have the following additional comments:
1) Boot failure recovery should _NOT_ invoke INT 19h if "NOINT19H" was
defined (this code is at line 397 in v4.7.23 loader.S).  It should instead
return to the system BIOS via "retf", since it will have grabbed control via
the option ROM init entry at offset 3.
2) Current structure does not allow for building non-PCI ROMs, but with PNP
enabled (i.e., ISA PNP).  Is this an oversight, or is it assumed that
etherboot ROMs for an ISA PNP card would simply ignore the PCI links?

Robb Main.

----- Original Message -----
From: "Ken Yap" <ke...@nl...>
To: <eth...@li...>
Sent: Saturday, April 07, 2001 9:17 AM
Subject: Re: [Etherboot-developers] 4.7.2x Failed to boot local


> >Since I have point out the problem months ago, the Etherboot 4.7.2x
> >failed to boot locally after selecting (L) at the prompt. The problem
> >still exist in 4.7.23 ... I concluded that if people burn a eprom to
> >test the system will find very inconvinient during testing, since  you
> >have to take off the eprom everytime you want to boot back to the disk.
>
> Has it ever worked in any previous release with that BIOS? If not then
> the problem remains unsolved.
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] Etherboot 4.7.24 (5.0RC4) released

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

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

Changes in this release:

+ Rename nepci entry in file NIC to rtl8029 to avoid giving the
impression that nepci will work for all PCI NE2000 clones. Make the
issue of PCI IDs in ROMs clearer in documentation, both in the
configuration and troubleshooting sections.

+ Tania Oka and Hyun-Joon Cha at about the same time found that
implementing the rtl_disable() routine in rtl8139.c stopped random
crashes in Linux later. It is important to disable the NIC after network
loading.

+ Implemented _disable() routine in w89c840, 3c90x and via-rhine drivers
too. Don't know how to do it for epic100.

+ p910nd-0.4 in contrib/ has -f device option now to specify other
printer ports, e.g.  USB.

+ Robb Main found a bug with the #ifdef logic in loader.S. This may fix
problems with BIOS detection.

MD5 sums:

58f234c8ab460ad8bddc857ebfb64532  etherboot-4.7.24.tar.bz2
49fdfad222cd8b3504e273ee88781da4  etherboot-4.7.24.tar.gz

Re: [Etherboot-developers] rtl_disable and random kernel crash.

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

>I think the source of the problems with local booting and 4.7.23 is the
>PCI_PNP_HEADER patch.  If you look closely at the code below the "over:"
>label at line 138, the "#ifdef - #endif" labels for PCI_PNP_HEADER and
>NOINT19H are mismatched (i.e., "#endif /* PCI_PNP_HEADER */" appears
>_between_ the "#ifdef NOINT19H" conditional and its associated "#endif").

You're right. The wrong comments are attached to the #endifs, but
nonetheless the code is also not what was intended. That's what happens
when your brain gets mushed by trying to save lines and looking at
inverse logic.

>I think the original intention was:
>1. If compiled for PCI_PNP, the system BIOS will invoke the "blockmove"
>entrypoint defined in the "$PnP" structure, so there is no need to do _any_
>initialization via the option ROM entry at offset 3 in the code (which jumps
>to label "over:").  I'm not sure of the significance of returning 0x20 in ax
>at this point, so I left it there.

The initialisation has to return 0x20 in %ax to indicate a bootable
device.

>2. If the ROM is not PCI_PNP, you have two options: trap INT19, or not.
>2a. INT19 trapped: patch the INT19 vector, and return to the system BIOS,
>which will invoke INT19 when initialization is complete and it is ready to
>boot.
>2b. No INT19 trap: assume no further initialization by the system BIOS is
>necessary - simply grab control and don't give it back.
>
>I submit the code below is more correct than that currently in 4.7.23.
>This may (or may not) resolve some of the issues with inability to "local"
>boot after the etherboot ROM is invoked.

Thanks, you found the problem. I'll fix this now.

Re: [Etherboot-developers] rtl_disable and random kernel crash.

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

I think the source of the problems with local booting and 4.7.23 is the
PCI_PNP_HEADER patch.  If you look closely at the code below the "over:"
label at line 138, the "#ifdef - #endif" labels for PCI_PNP_HEADER and
NOINT19H are mismatched (i.e., "#endif /* PCI_PNP_HEADER */" appears
_between_ the "#ifdef NOINT19H" conditional and its associated "#endif").

I think the original intention was:
1. If compiled for PCI_PNP, the system BIOS will invoke the "blockmove"
entrypoint defined in the "$PnP" structure, so there is no need to do _any_
initialization via the option ROM entry at offset 3 in the code (which jumps
to label "over:").  I'm not sure of the significance of returning 0x20 in ax
at this point, so I left it there.
2. If the ROM is not PCI_PNP, you have two options: trap INT19, or not.
2a. INT19 trapped: patch the INT19 vector, and return to the system BIOS,
which will invoke INT19 when initialization is complete and it is ready to
boot.
2b. No INT19 trap: assume no further initialization by the system BIOS is
necessary - simply grab control and don't give it back.

I submit the code below is more correct than that currently in 4.7.23.
This may (or may not) resolve some of the issues with inability to "local"
boot after the etherboot ROM is invoked.
==============================================
over:
#ifdef PCI_PNP_HEADER
        movw    $0x20,%ax
        lret
#else /* PCI_PNP_HEADER */
#ifndef NOINT19H
        pushw   %ax
        pushw   %ds
        xorw    %ax,%ax
        movw    %ax,%ds                 /* access first 64kB segment */
        movw    SCRATCHVEC+4, %ax       /* check if already installed */
        cmpw    $MAGIC, %ax             /* check magic word */
        jz      installed
        movw    INT19VEC, %ax           /* hook into INT19h */
        movw    %ax, SCRATCHVEC
        movw    INT19VEC+2, %ax
        movw    %ax, SCRATCHVEC+2
        movw    $start19h, %ax
        movw    %ax, INT19VEC
        movw    %cs,%ax
        movw    %ax, INT19VEC+2
        movw    $MAGIC, %ax             /* set magic word */
        movw    %ax, SCRATCHVEC+4
installed:
        popw    %ds
        popw    %ax
        movw    $0x20,%ax
        lret

start19h:                               /* clobber magic id, so that we will
*/
        xorw    %ax,%ax                 /* not inadvertendly end up in an */
        movw    %ax,%ds                 /* endless loop */
        movw    %ax, SCRATCHVEC+4
        movw    SCRATCHVEC+2, %ax       /* restore original INT19h handler
*/
        movw    %ax, INT19VEC+2
        movw    SCRATCHVEC, %ax
        movw    %ax, INT19VEC

        /* fall thru */

#endif  /* NOINT19H */
#endif /* PCI_PNP_HEADER */
==========================================

Re: [Etherboot-developers] rtl_disable and random kernel crash.

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

>with (4.7.22). But with both of them I'm not able to boot from floppy
>after selection local boot via menu (options: CFLAGS32+=      -DASK_BOOT=3
>-DANS_DEFAULT=ANS_NETWORK) I get the message from the computer: PRESS ANY
>KEY FOR REBOOT :-(

>Since I have point out the problem months ago, the Etherboot 4.7.2x
>failed to boot locally after selecting (L) at the prompt. The problem
>still exist in 4.7.23 ... I concluded that if people burn a eprom to
>test the system will find very inconvinient during testing, since  you
>have to take off the eprom everytime you want to boot back to the disk.

Hmm, just looked through the BIOS Boot Spec again. Do you have any
further devices defined in the BIOS setup for the BIOS to try when the
network boot fails, e.g. "NET, A, C". Because if you don't then the BIOS
is doing the right thing according to the spec.

Re: [Etherboot-developers] 4.7.2x Failed to boot local

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

>Since I have point out the problem months ago, the Etherboot 4.7.2x
>failed to boot locally after selecting (L) at the prompt. The problem
>still exist in 4.7.23 ... I concluded that if people burn a eprom to
>test the system will find very inconvinient during testing, since  you
>have to take off the eprom everytime you want to boot back to the disk.

>Because I patched the code into mainboard bios I'm in a bit of trouble
>now :-))

The other thing you can do is go to the BIOS setup and choose not to
boot from the net. The boot ROM's supposed be a selectable boot device
now.

Re: [Etherboot-developers] Re: [Etherboot-users] Re: rtl_disable and random kernel crash.

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

>Hi, all is working fine now with this patch applied to the rtl8139.c file.
>But I got some other problems: With the newest etherboot (4.7.23) it takes
>a long time to decompress kernel image (ca. 30 seconds). It's much faster
>with (4.7.22). But with both of them I'm not able to boot from floppy
>after selection local boot via menu (options: CFLAGS32+=      -DASK_BOOT=3
>-DANS_DEFAULT=ANS_NETWORK) I get the message from the computer: PRESS ANY
>KEY FOR REBOOT :-(

I'm not sure the decompression is an Etherboot problem, at that point
only the kernel is running.

>Because I patched the code into mainboard bios I'm in a bit of trouble now
>:-))

Boot DOS diskless and then restore the BIOS.

Re: [Etherboot-developers] 4.7.2x Failed to boot local

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

>Since I have point out the problem months ago, the Etherboot 4.7.2x
>failed to boot locally after selecting (L) at the prompt. The problem
>still exist in 4.7.23 ... I concluded that if people burn a eprom to
>test the system will find very inconvinient during testing, since  you
>have to take off the eprom everytime you want to boot back to the disk.

Has it ever worked in any previous release with that BIOS? If not then
the problem remains unsolved.

[Etherboot-developers] Re: [Etherboot-users] Re: rtl_disable and random kernel crash.

[Dirk v. S. <di...@go...>]

> |Now, all SBCs boot well with rtl_disable and I thought that I have to report 
> >this. If you add a few lines of code - copied ;) - about  rtl_disable at next
> > release there will be no people meet the danger.
> |
> |
> |-------------------------------------------
> |static void rtl_disable(struct nic *nic)
> |{
> |        int i;
> |
> |        /* reset the chip */
> |        outb(CmdReset, ioaddr + ChipCmd);
> |
> |        /* Check that the chip has finished the reset. */
> |        for (i = 1000; i > 0; i--)
> |                if ((inb(ioaddr + ChipCmd) & CmdReset) == 0)
> |                        break;
> |}

Hi, all is working fine now with this patch applied to the rtl8139.c file.
But I got some other problems: With the newest etherboot (4.7.23) it takes
a long time to decompress kernel image (ca. 30 seconds). It's much faster
with (4.7.22). But with both of them I'm not able to boot from floppy
after selection local boot via menu (options: CFLAGS32+=      -DASK_BOOT=3
-DANS_DEFAULT=ANS_NETWORK) I get the message from the computer: PRESS ANY
KEY FOR REBOOT :-(

Because I patched the code into mainboard bios I'm in a bit of trouble now
:-))

So long,
	   Dirk

[Etherboot-developers] 4.7.2x Failed to boot local

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

Since I have point out the problem months ago, the Etherboot 4.7.2x
failed to boot locally after selecting (L) at the prompt. The problem
still exist in 4.7.23 ... I concluded that if people burn a eprom to
test the system will find very inconvinient during testing, since  you
have to take off the eprom everytime you want to boot back to the disk.

David Chow

Re: [Etherboot-developers] 4.7.23 problems

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

>4.7.22 does not crash.
>It is also not recognized on the Tyan S2510 motherboard with AMI BIOS.
>In other words: Etherboot 4.7.22 flashed on Intel Pro100+ card is not
>called from BIOS at boot time on this motherboard.
>Flashed eepro100 4.7.22 Etherboot is recognized and runs fine on Intel
>L440GX+ motherboard.
>Also, 4.7.23 runs fine on Tyan motherboard when run from a boot floppy.

Actually I would say that 4.7.23 is more correct than 4.7.22. At least
it is recognised by the main BIOS. Nothing interesting can be said about
version that isn't even recognised. The freezes you are having after
loading with 4.7.23 are another issue that is yet to be understood.

Re: [Etherboot-developers] 4.7.23 problems

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

>> What happens with 4.7.22? If that also crashes in the same way then it's
>> not a .23 problem per se but something else unresolved.  I know this
>> doesn't help you much but it at least narrows down the problem.  If .22
>> works (the EEPRO100 driver didn't change in between) then I want to know
>> about it.
>
>4.7.22 does not crash.
>It is also not recognized on the Tyan S2510 motherboard with AMI BIOS.
>In other words: Etherboot 4.7.22 flashed on Intel Pro100+ card is not
>called from BIOS at boot time on this motherboard.
>Flashed eepro100 4.7.22 Etherboot is recognized and runs fine on Intel
>L440GX+ motherboard.
>Also, 4.7.23 runs fine on Tyan motherboard when run from a boot floppy.

Grr, BIOS issues again. I wish there was an easy way to determine
conformance or not of a BIOS to the standard.

Re: [Etherboot-developers] 4.7.23 problems

[Tomasz B. <to...@Za...>]

> What happens with 4.7.22? If that also crashes in the same way then it's
> not a .23 problem per se but something else unresolved.  I know this
> doesn't help you much but it at least narrows down the problem.  If .22
> works (the EEPRO100 driver didn't change in between) then I want to know
> about it.

4.7.22 does not crash.
It is also not recognized on the Tyan S2510 motherboard with AMI BIOS.
In other words: Etherboot 4.7.22 flashed on Intel Pro100+ card is not
called from BIOS at boot time on this motherboard.
Flashed eepro100 4.7.22 Etherboot is recognized and runs fine on Intel
L440GX+ motherboard.
Also, 4.7.23 runs fine on Tyan motherboard when run from a boot floppy.

Tomasz.

Re: [Etherboot-developers] Hardware database pointers to rom-o-matic.net

[Georg B. <Geo...@po...>]

Am Freitag,  6. April 2001 15:45 schrieb Marty Connor:
> I just noticed that the Etherboot hardware database is pointing to 4.7.21
> on rom-o-matic.net.  I made the rtl_disable() change to that version as
> well, to make sure it is fixed there as well.  I have created a couple of
> sym-links on rom-o-matic.net so that Georg can maybe point to
>
>    http://rom-o-matic.net/latest-production-release/
>
> and
>
>    http://rom-o-matic.net/latest-development-release/
>
> instead of explicit version numbers.  I can use other names - these are
> just the first ones I thought of.

Hi Marty,

good idea. I am a bit short on time these days, so the database was a bit 
behind, but I updated it a few hours ago.

I will point it to the above names soon.


Georg

[Etherboot-developers] Hardware database pointers to rom-o-matic.net

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

I just noticed that the Etherboot hardware database is pointing to 4.7.21 
on rom-o-matic.net.  I made the rtl_disable() change to that version as 
well, to make sure it is fixed there as well.  I have created a couple of 
sym-links on rom-o-matic.net so that Georg can maybe point to 

   http://rom-o-matic.net/latest-production-release/

and 

   http://rom-o-matic.net/latest-development-release/

instead of explicit version numbers.  I can use other names - these are 
just the first ones I thought of.

I will attempt to keep these updated when updating the site.  I'm sure 
someone will let me know if I forget :-)


---
    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...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] Re: rtl_disable and random kernel crash.

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

On 4/5/01 11:45 PM Ken Yap ke...@nl... wrote:
>static void rtl_disable(struct nic *nic)
>{
>	/* reset the chip */
>	outb(CmdReset, ioaddr + ChipCmd);
>
>	/* 10 ms timeout */
>	load_timer2(10*TICKS_PER_MS);
>	while ((inb(ioaddr + ChipCmd) & CmdReset) != 0 && timer2_running())
>		/* wait */;
>}
>
>and add #include "timer.h" near the top. The hardware timer is more
>consistent than a counting loop.

Thanks Ken!  I just changed rom-o-matic.net to include this code in 
4.6.12 and 4.7.23. I also made floppies and booted my test station, and 
the code seems to function properly. 

Many thanks to Mr. Hyun-Joon Cha for this contribution.  We should 
probably go through each driver to make sure that we are disabling the 
NIC's receive and transmit engines either by explicitly turning them off 
or resetting the NIC as is done here.


---
    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...@th...
    Web: http://www.thinguin.org/