etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: [Etherboot-users] tulip driver problems? (clone FA310TX)

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

On 5/25/01 10:15 PM Michael Stein ma...@uc... wrote:
>tulip driver problems? (clone FA310TX)
>I'm trying etherboot for the first time, I've been using netboot
>before this.
>I've fetched the etherboot-5.0.1 source and built it as is.  I built a
>floppy with the tulip driver.  I tried to boot this in a machine with
>a clone chip Netgear FA310TX.  Upon booting I can see that etherboot
>finds the network card.  It says (retyped, approx):
>FA310TX: Chip Lite-On 82c168 Pnic rev 32 at e400
>        vendor = 11ad device 0002
>        mii transceiver 1 config 3000 status 7829 advertising 01e1
>Searching for sever (DHCP)
><sleep>
>The <sleep> keeps repeating...
>I tried using tcpdump to see if packets were visible on the dhcp/tftp
>server and don't believe any are appearing.

This has been reported before, and I am at a loss to explain it.  I have 
been unable to reproduce this failure.  I'm going to look at the 2.4 
Kernel sources to see if there have been any changes that could possibly 
account for this behaviour.

>Switching to a netboot floppy results in a complete boot (same machine,
>same dhcp/tftp server).

Sounds like an initialization problem.  I'm looking into it, and since 
you have a clear test case, perhaps you can test it.

>Trying the etherboot floppy in a different machine which has an
>Netgear FA310TX with the original Dec tulip chip (21140) results in
>it booting. This machine uses a different dhcp/tftp server but I don't
>believe that that is related.

Yes, that would exercise a different code path than than PNIC.

>Reconnecting the failing machine with the PNIC from the existing
>Cisco-4000 100 Mbit port to an old Cisco switch with 10 Mbit ports
>results in the PNIC machine booting using etherboot too...
>Sounds like the tulip driver MII/speed code has a problem.
>All the above machines are on the same subnet.

This does point to the autonegotiation/MII code as a possible culprit.

>I've been using netboot for a few years but am thinking of switching
>to etherboot as it is built with "normal" tools and would allow the
>easy(?) addition of 32 bit C code.  I want to have a floppy based fast
>boot over the network which is secure and not restricted to the local
>subnet.  I figure that reading up to 10% of a floppy is ok, reading more
>is too slow.  I have some ideas on how this could work but am interested
>in hearing others. 

Alright, having looked at the latest kernel code for a few minutes, I 
think I have a theory about what is happening.  This will require 
testing, but I think we might be onto something.

Here is some MDIO read code from the kernel relating to the LC82168 (the 
chip you have on your FA310TX card:

        if (tp->chip_id == LC82C168) {
                int i = 1000;
                outl(0x60020000 + (phy_id<<23) + (location<<18), ioaddr + 
0xA0);
                inl(ioaddr + 0xA0);
                inl(ioaddr + 0xA0);
                while (--i > 0) {
                        barrier();
                        if ( ! ((retval = inl(ioaddr + 0xA0)) & 
0x80000000))
                                break;
                }
                return retval & 0xffff;
        }

Here is the equivalent etherboot code:

    if (tp->chip_id == LC82C168) {
        int i = 1000;
        outl(0x60020000 + (phy_id<<23) + (location<<18), ioaddr + 0xA0);
        inl(ioaddr + 0xA0);
        inl(ioaddr + 0xA0);
        while (--i > 0)
            if ( ! ((retval = inl(ioaddr + 0xA0)) & 0x80000000))
                return retval & 0xffff;
        return 0xffff;
    }

Now, ignoring the stylistic differences, I notice a call to "barrier()".
I haven't ever heard of that function before.  What could it be for?

So I grepped through the 2.4 kernel sources trying to see where it was 
used and what it was for:

here is an example:

in dgrs.c:

        for (i = jiffies + 8 * HZ; time_after(i, jiffies); )
        {
                barrier();              /* Gcc 2.95 needs this */
                if (priv0->bcomm->bc_status >= BC_RUN)
                        break;
        }

Oh my god.  GCC needs something to protect volatile memory.  Time to find 
the definition of barrier(). 

In the file linux-2.4.5/include/linux/kernel.h we find:

/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

Oh this is ugly.  But it could explain a lot.  Let's see where else in 
the tulip code this call is used:

mdc@ll:~/linux-2.4.5/drivers/net/tulip$ grep barrier *
ChangeLog:      * media.c: Add barrier() to mdio_read/write's PNIC status 
check
media.c:                        barrier();
media.c:                        barrier();

Hmmm, in exactly 2 places.  Now obviously the one above is the first.  
Let's see what the second is:

        if (tp->chip_id == LC82C168) {
                int i = 1000;
                outl(cmd, ioaddr + 0xA0);
                do {
                        barrier();
                        if ( ! (inl(ioaddr + 0xA0) & 0x80000000))
                                break;
                } while (--i > 0);
                return;
        }

Now, I'm not a gambling man.  But, one might say "a subtle pattern begins 
to emerge...".  The only two places in the tulip code that use this call 
are in code specific to the LC82C168. Hmmmmmmm.

So the first thing I'd try is putting the definition of barrier() in the 
tulip.c file after the other #includes:

/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

then add the barrier() calls to functions mdio_read:

    if (tp->chip_id == LC82C168) {
        int i = 1000;
        outl(0x60020000 + (phy_id<<23) + (location<<18), ioaddr + 0xA0);
        inl(ioaddr + 0xA0);
        inl(ioaddr + 0xA0);
        while (--i > 0) {
            barrier();
            if ( ! ((retval = inl(ioaddr + 0xA0)) & 0x80000000))
                return retval & 0xffff;
        }
        return 0xffff;
    }

and to its sibling mdio_write:

    if (tp->chip_id == LC82C168) {
        int i = 1000;
        outl(cmd, ioaddr + 0xA0);
        do {
            barrier();
            if ( ! (inl(ioaddr + 0xA0) & 0x80000000))
                break;
        } while (--i > 0);
        return;
    }

Don't forget to add the "{" and "}" inside the do and while loops.

Now it is possible that this is not the problem at all, but it the 
evidence does strongly point to some sort of subtle thing, and we have 
certainly seen compiler, um, "eccentricities" when dealing with this code 
before.

Could someone with a non-working FA310TX try these changes?  I note that 
the barrier() call  is also used (at least) in these kernel drivers:

3c527.c
7990.c
8139too.c
a2065.c
acenic.c
de4x5.c
dgrs.c
epic100.c
ioc3-eth.c
sk_g16.c
sunhme.c
sunlance.c
sunqe.c
winbond-840.c

And I would not be at all surprised if the eepro100 problems we have been 
seeing might be related.

So, there are my initial quick thoughts on the long-running FA310TX saga. 
 

Michael, thank you very much for your debugging information and the time 
you took in doing it. Please let us know if the changes I suggest make a 
difference or not.  If you're not comfortable making the changes, I can 
send you an edited tulip.c file to try.

I hope this helps,

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

[Etherboot-developers] Re: [Etherboot-users] Intel CA810eal and difference between 3c905b-tx and 3c905b-tx-nm

[Jim M. <ja...@mc...>]

Marty,

I actually managed to figure it out.

There is a new config option (I'm still trying to figure out how new)

   CFG_3C90X_BOOTROM_FIX

I took an old floppy with floppyload and 3c90x.rom on it.
The floppy was based on 4.2.10 (really old).

I booted with that, and then inserted the eprom and presto!  it worked.

I then compared the source for 3c90x.c and the code that works around
the bug in the 3c905b is now conditional based on the above variable.

Looking at all of the versions of Etherboot that I have, it looks like
that change was introduced on or before 4.5.8.  It's documented in
the 3c90x.txt file, but I didn't see it in any of the release notes.

Anyway, the card is working great now, thanks for your help.

Jim McQuillan
ja...@Di...


Marty Connor wrote:
> 
> On 5/21/01 1:53 PM Jim McQuillan ja...@mc... wrote:
> >We sent them updated chips with 5.0.1 on them, and still
> >it didn't work.
> >So, the customer sent the whole machine to me, to try to
> >figure it out.
> >It boils down to this:
> >The 3c905b-tx doesn't like the bootrom.  In ANY machine,
> >even my test machine that seems to always work.
> >I tried one of my 3c905b-tx-nm (notice the -nm).  That card
> >works just fine in the Intel machine.
> 
> Interesting.  It sounds like there are subtle differences between the TX
> and TX-NM boards.
> 
> >I know that with the 3c905 cards, you need to first boot off of
> >a floppy, to work around an 8k bug in the chipset.  We did that,
> >a couple of times.  When we boot off the floppy, it boots up
> >just fine.
> 
> The fact that there has to be a workaround using a floppy suggests that
> the TX cards are quirky.
> 
> >When we insert the bootrom chip, it stops after the bios hardware
> >list shows up on the screen.
> >The hardware list does show the network card, with a PCI vendor
> >ID of 10b7 and a device id of 9055, which exactly matches the
> >905b-tx-nm.
> >So, the 905b-tx and the 905b-tx-nm both have the same PCI Vendor/device
> >ids.
> >I don't have another non -nm card to try, so I can't totally rule out
> >the health of the card I have.  Although it does work with a floppy.
> >Any ideas?
> 
> Well, I don't have a quick answer, but I'll make a few suggestions:
> 
> There are other boot ROM vendors, who presumably have ROMs that are
> supposed to work with this card.  I'd suggest you buy one.  See if it
> works with this card (in any machine).
> 
> If it works, there are two obvious possibilities:
> 
>   - The code contained in it is somehow different than Etherboot, and
> thus works with this card (or the code is in a different location in the
> chip).
> 
>   or
> 
>   - The ROM itself is electrically different than the EEPROM you are
> using.
> 
> This is from the 3c90x.txt file in the Etherboot distribution:
> 
>     II  FLASH PROMS
> 
>     The 3c90xB cards, according to the 3Com documentation, only accept the
>     following flash memory chips:
> 
>         Atmel AT29C512 (64 kilobyte)
>         Atmel AT29C010 (128 kilobyte)
> 
>     The 3c90x cards, according to the 3Com documentation, accept the
>     following flash memory chips capacities:
> 
>         64  kb (8 kB)
>         128 kb (16 kB)
>         256 kb (32 kB) and
>         512 kb (64 kB)
> 
>     Atmel AT29C512 (64 kilobyte) chips are specifically listed for both
>     adapters, but flashing on the 3c905b cards would only be supported
>     through the Atmel parts.  Any device, of the supported size, should
>     be supported when programmed by a dedicated PROM programmer (e.g.
>     not the card).
> 
> So, have you tried a genuine AT29C512 part on this card?  It just might
> make a difference.
> 
> I'd also suggest that you get another card, just to make very sure it
> isn't something specific to this card.
> 
> Second, get a ROM from LANWorks or Bootix, and see if they work.
> 
> If they do, use your EPROM burner or the Etherboot utility bromutil to
> suck the code out of their EPROM, and put it in one of yours.  If it
> works, we can be fairly sure that it has something to do with the
> Etherboot code.
> 
> If it doesn't work, then get the same kind of chip that they are using,
> and put the Etherboot code in it.  If that works, then you know that
> whatever part they are using is subtly different enough to make a
> difference.
> 
> Hmm, let's see, just as a thought, once upon a time I remember reading
> about having to put multiple copies of a ROM image in a chip because you
> couldn't be sure where the ROM image was going to be mapped into memory.
> Could it be that you should burn the code in several places in the chip?
> This is a 16K image, being burned into a 64K chip, I suspect.  Try
> burning it 4 times on your ROM burner.  Let's see if we can at least get
> it detected in memory.
> I have this feeling some random part of the chip is being mapped in, but
> not the part we expect. Executing a lot of 0xFF's may be the hang we see.
> 
> Also, the output of disrom.pl from the Etherboot distribution would be
> helpful for the Etherboot image.
> 
> So there is some free debugging advice.  Do let us know how it goes.
> 
> I hope this helps 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...@th...
>     Web: http://www.thinguin.org/

[Etherboot-developers] Re: [Etherboot-users] Intel CA810eal and difference between 3c905b-tx and 3c905b-tx-nm

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

On 5/21/01 1:53 PM Jim McQuillan ja...@mc... wrote:
>We sent them updated chips with 5.0.1 on them, and still
>it didn't work.
>So, the customer sent the whole machine to me, to try to
>figure it out.
>It boils down to this:
>The 3c905b-tx doesn't like the bootrom.  In ANY machine,
>even my test machine that seems to always work.
>I tried one of my 3c905b-tx-nm (notice the -nm).  That card
>works just fine in the Intel machine.

Interesting.  It sounds like there are subtle differences between the TX 
and TX-NM boards.

>I know that with the 3c905 cards, you need to first boot off of
>a floppy, to work around an 8k bug in the chipset.  We did that,
>a couple of times.  When we boot off the floppy, it boots up
>just fine.

The fact that there has to be a workaround using a floppy suggests that 
the TX cards are quirky.

>When we insert the bootrom chip, it stops after the bios hardware
>list shows up on the screen.
>The hardware list does show the network card, with a PCI vendor
>ID of 10b7 and a device id of 9055, which exactly matches the
>905b-tx-nm.
>So, the 905b-tx and the 905b-tx-nm both have the same PCI Vendor/device
>ids.
>I don't have another non -nm card to try, so I can't totally rule out
>the health of the card I have.  Although it does work with a floppy.
>Any ideas?

Well, I don't have a quick answer, but I'll make a few suggestions:

There are other boot ROM vendors, who presumably have ROMs that are 
supposed to work with this card.  I'd suggest you buy one.  See if it 
works with this card (in any machine).

If it works, there are two obvious possibilities:

  - The code contained in it is somehow different than Etherboot, and 
thus works with this card (or the code is in a different location in the 
chip).

  or

  - The ROM itself is electrically different than the EEPROM you are 
using.

This is from the 3c90x.txt file in the Etherboot distribution:

    II  FLASH PROMS

    The 3c90xB cards, according to the 3Com documentation, only accept the
    following flash memory chips:

        Atmel AT29C512 (64 kilobyte)
        Atmel AT29C010 (128 kilobyte)

    The 3c90x cards, according to the 3Com documentation, accept the
    following flash memory chips capacities:

        64  kb (8 kB)
        128 kb (16 kB)
        256 kb (32 kB) and
        512 kb (64 kB)

    Atmel AT29C512 (64 kilobyte) chips are specifically listed for both
    adapters, but flashing on the 3c905b cards would only be supported
    through the Atmel parts.  Any device, of the supported size, should
    be supported when programmed by a dedicated PROM programmer (e.g.
    not the card).

So, have you tried a genuine AT29C512 part on this card?  It just might 
make a difference.

I'd also suggest that you get another card, just to make very sure it 
isn't something specific to this card.

Second, get a ROM from LANWorks or Bootix, and see if they work.

If they do, use your EPROM burner or the Etherboot utility bromutil to 
suck the code out of their EPROM, and put it in one of yours.  If it 
works, we can be fairly sure that it has something to do with the 
Etherboot code.

If it doesn't work, then get the same kind of chip that they are using, 
and put the Etherboot code in it.  If that works, then you know that 
whatever part they are using is subtly different enough to make a 
difference.

Hmm, let's see, just as a thought, once upon a time I remember reading 
about having to put multiple copies of a ROM image in a chip because you 
couldn't be sure where the ROM image was going to be mapped into memory.  
Could it be that you should burn the code in several places in the chip?  
This is a 16K image, being burned into a 64K chip, I suspect.  Try 
burning it 4 times on your ROM burner.  Let's see if we can at least get 
it detected in memory.
I have this feeling some random part of the chip is being mapped in, but 
not the part we expect. Executing a lot of 0xFF's may be the hang we see.

Also, the output of disrom.pl from the Etherboot distribution would be 
helpful for the Etherboot image.

So there is some free debugging advice.  Do let us know how it goes.

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

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On 18 May 2001, Eric W. Biederman wrote:

> Take a look at what I did.  At any rate the transformation from an ELF
> image to a tagged should be a simple 1-1 transformation.  If the
> tagged image needs a 16 bit entry point (I don't remember) you might
> need a bit of stub code but otherwise all is well.

What I like to do is to bypass the ELF part and use a 16 bit entry point.
Also, I _have_ converted the original memtest.bin binary to a tagged image
which goes direcly to setup.S code, everything in 16 bit real mode.

There is a very good reason change only bootsect.S and setup.S. These
files are not likely to change in the near future, unless they are
rewritten based on the corresponding files of a modern Linux source tree,
but this will rather _solve_ things out. So, a patch I create is likely to
apply cleanly on future versions of memtest86 too. Also, one of us likes
to try changes to the memory test part which I am _not_ interested in. So
we can keep our development seperate and neat.

However, bypassing of bootsect.S seem to be a problem (thanks Ken for
pointing this out), because some register values are not properly set,
notably ss:si. So I am now trying to do one of

1. add few lines to the beginning of setup.S to initialize necessary
   registers.

2. move the "jmp" line in bootsect.S which transfers control to setup.S
   to a place _before_ loading the rest from the floppy and use
   bootsect.S as entry point.

I have to do the testing somewhere else, so have to wait until my next
visit there to try these possibilities out. Will keep you updated about
the progress.

Thanks.

Regards and greetings,

Anuradha

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On 18 May 2001, Eric W. Biederman wrote:

> Anuradha Ratnaweera <anu...@gn...> writes:
> 
> > BTW, I never saw an updated patch.
> 
> Hmm.  It was hooked on as an attachment, to the message you replied
> to. All it does is fix the name of a couple of symbols so ld doesn't
> get confused.

Sorry about not noticing it. I checked all the previous mails but not
_that_ one itself ;)

Changing head and relo to _head and _relo solved the problem with ld-2.9.

Thanks.

Anuradha

[Etherboot-developers] more stats

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

For all you statistics fans :-)

I reduced the 2001-05-13 weekly rom-o-matic.net stats by driver so one 
can tell easily which drivers are used the most often.

Enjoy,

Marty

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Week of 2001-05-13  rom-o-matic stats by driver

Driver         Count    Comments

ns8390           294    (ne, rtl8029, nepci, etc.)
                        (includes the 3c503, which also
                         happens to be the default ROM on the 
rom-o-matic, 
                         so some of this is curious users clicking "Get 
ROM") 
rtl8139          186    makes sense
3c90x            116    3Com
tulip            108    and lots of clones
3c509            106    3Com (oldie but goodie)
eepro100          99    Intel
sis900            51    Popular newcomer
lance             43
3c595             30    3Com
via-rhine         27
davicom           24    (tulip clone)
eepro             12
otulip             9    (tulip)
w89c840            7
smc9000            5
cs89x0             4
epic100            3
i82586             3
depca              2
ni5010             1
sk_g16             1
tiara              1

Total           1132



---
    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/

[Etherboot-developers] more than one DHCP on the net ?

[dinesh I. a. <dk...@ic...>]

Dear sir ,=20
            Is there any patch available , by which we can specify a =
DHCP to use , if we have more than one DHCP servers to use . I have =
downloaded the etherboot-5 and there is a patch under contrib/dhcpid =
directory but it does not patch this version of etherboot . Is there a =
version of etherboot available with facility . Any pointers will be =
appreceated .=20

Thanks in advcane=20
Dinesh       =20

Re: [Etherboot-developers] booting non linux images

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

Anuradha Ratnaweera <anu...@gn...> writes:

> On 16 May 2001, Eric W. Biederman wrote:
> 
> > Anuradha Ratnaweera <anu...@gn...> writes:
> > 
> > Please try my updated patch to memtest86, over the last patch it simply
> > has a trivial change to work around the linker bug in ld-2.9.5.
> 
> Memtest86 was compiled (with your patch) using ld-2.10.x. It works great!
> Thanks. BTW, I never saw an updated patch.

Hmm.  It was hooked on as an attachment, to the message you replied to.
All it does is fix the name of a couple of symbols so ld doesn't
get confused.

> At any rate I _do_ need to convert memtest.bin to a tagged image.

Take a look at what I did.  At any rate the transformation from an ELF
image to a tagged should be a simple 1-1 transformation.   If the
tagged image needs a 16 bit entry point (I don't remember) you might
need a bit of stub code but otherwise all is well. 

Eric

Re: [Etherboot-developers] booting non linux images

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

>I wonder how lilo happily boots memtest86. Is it correct to say that it
>also jumps directly to setup.S code?

At any rate LILO would have to skip bootsect.S because that reads the
floppy. LILO may do some adjustments before jumping into setup.S to make
it look like execution came from bootsect.S.

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On 16 May 2001, Eric W. Biederman wrote:

> Anuradha Ratnaweera <anu...@gn...> writes:
> 
> Please try my updated patch to memtest86, over the last patch it simply
> has a trivial change to work around the linker bug in ld-2.9.5.

Memtest86 was compiled (with your patch) using ld-2.10.x. It works great!
Thanks. BTW, I never saw an updated patch.

At any rate I _do_ need to convert memtest.bin to a tagged image.

Anuradha

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On Wed, 16 May 2001, Ken Yap wrote:

> There is some tricky stuff in bootsect.S that doesn't get done because
> you jump directly to setup.S. For example ss is set to INITSEG and sp
> to about 0x4000. When you are coming direct from Etherboot, ss is
> 0x9400 and sp a bit less than 0xc000 (= linear address of just below
> 0xa0000). It doesn't matter in the case of booting Linux, because
> first-linux.S takes care of this before calling setup.S. But you don't
> have your equivalent of first-linux.S.  So you'd have to read setup.S
> very carefully, bearing in mind the initial conditions of entry to see
> if anything untoward will happen.

I am now in the process of changing setup.S, so that it initializes the
necessary registers and the stack as done in bootsect.S.

I wonder how lilo happily boots memtest86. Is it correct to say that it
also jumps directly to setup.S code?

Anuradha

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On Wed, 16 May 2001, Ken Yap wrote:

> >The total size of precomp.bin is 512+2048+65020=67580 and the tagged image
> >is 512 bytes larger.
> 
> Show me the output of disnbi on the image. Also have you checked that
> removing the first 512 bytes of the image gives you the original?

Removing the first 512 _does_ give the original, because the program (very
crude at this stage) I wrote to generate the tagged image creates only the
first 512 bytes of the image and the original image is appended to it (cat
tmpfile memtest.bin > memtest.tagged).

Here is the output of disnbi

$ disnbi memtest.tagged
Type: NBI
Header location:	9320:0000
Start address:		9000:0200
Flags:

Segment number 1
Load address:		00090000
Image length:		512
Memory length:		512
Position:		Absolute
Vendor tag:		16

Segment number 2
Load address:		00090200
Image length:		2048
Memory length:		2048
Position:		Absolute
Vendor tag:		17

Segment number 3
Load address:		00010000
Image length:		65020
Memory length:		65020
Position:		Absolute
Vendor tag:		18


Regards,

Anuradha

[Etherboot-developers] tftp-hpa 0.17 RPMs available

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

In the interest of helping stress test TFTP servers, I have made RPMs of
H. Peter Anvin's tftp-hpa package available at
http://etherboot.sf.net/distribution.html This also has a pre-emptive
FAQ re comparing the two packages.

You can get DEBs for this package and the ATFTP package from the Debian
Project (www.debian.org) so that saves me work.

Re: [Etherboot-developers] Re: [Etherboot-users] pci.c patch

[Donald J C. <dj...@ci...>]

"Eric W. Biederman" wrote:
> 
> Ken Yap <ke...@bi...> writes:
> 
> > >For the last case reported on this list, this code won't solve it.
> > >The problem there was serverworks has 2 parrallel pci buses.  I'm
> > >not certain if they are even bridged.
> > >
> > >Unless there is a performace problem setting busses = 256, and
> > >scanning all potential PCI busses should be much more reliable.
> >
> > Do you know how Linux does it?
...
> Seriously if we make scan bus have busses = 256.  And then never
> increment the bus count we will be fine, and the code will be simple.
> 
> 255 is the maximum possible bus number, and etherboot already tests
> for the presence of a pci device in the slot, so it should ignore an
> unused bus pretty quickly.  It already correctly ignores an unused
> bus or the previous patch wouldn't have worked.  Plus etherboot has an
> early out mechanism, so we shouldn't even get past the first pci bus
> on most machines.

Maybe this should be a Config option.  Since only a very few people
seem to run into it, leave the default as is and allow a simple change
to Config to select whatever number of busses the user wants to examine.
rom-o-matic could offer the option, as well (although I don't want to
speak for Marty, he is about the most helpful person I've come across
recently.)

Of course, if there is no problem with the above analysis, then just
checking all possible busses might be fine.  I am a little leary that
some machine somewhere will puke if you go poking around for busses
that aren't there (but then I know about as much about PCI as I know
about quantum physics.)

-Don

--
Don Christensen    Senior Software Development Engineer
  dj...@ci...    MMABU - Mid-Market Access Business Unit
  Cisco Systems    ComLOB - Commercial Line of Business
   San Jose, CA    "So much relies on the course that you take
                   The fool and the wise man both burn at the stake"

Re: [Etherboot-developers] booting non linux images

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

>What I did was to create a tagged image such that
>
>1. The loading address of first 512 bytes of the image itself is 9320:0000
>2. Start address is 9000:0200
>3. Bootsector is loaded at 00090000 (512/512 - memory / image length)
>4. Setup is loaded at 00090200 (2048/2048)
>5. The rest is loaded at 00010000 (65020/65020 as of precomp.bin -precompiled
>   image)
>
>The total size of precomp.bin is 512+2048+65020=67580 and the tagged image
>is 512 bytes larger.
>
>Any suggessions would be highly appreciated.

There is some tricky stuff in bootsect.S that doesn't get done because
you jump directly to setup.S. For example ss is set to INITSEG and sp to
about 0x4000. When you are coming direct from Etherboot, ss is 0x9400
and sp a bit less than 0xc000 (= linear address of just below 0xa0000).
It doesn't matter in the case of booting Linux, because first-linux.S
takes care of this before calling setup.S. But you don't have your
equivalent of first-linux.S.  So you'd have to read setup.S very
carefully, bearing in mind the initial conditions of entry to see if
anything untoward will happen.

Re: [Etherboot-developers] booting non linux images

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

>What I did was to create a tagged image such that
>
>1. The loading address of first 512 bytes of the image itself is 9320:0000
>2. Start address is 9000:0200
>3. Bootsector is loaded at 00090000 (512/512 - memory / image length)
>4. Setup is loaded at 00090200 (2048/2048)
>5. The rest is loaded at 00010000 (65020/65020 as of precomp.bin -precompiled
>   image)
>
>The total size of precomp.bin is 512+2048+65020=67580 and the tagged image
>is 512 bytes larger.

Show me the output of disnbi on the image. Also have you checked that
removing the first 512 bytes of the image gives you the original?

Re: [Etherboot-developers] Re: [Etherboot-users] pci.c patch

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

Ken Yap <ke...@bi...> writes:

> >For the last case reported on this list, this code won't solve it.
> >The problem there was serverworks has 2 parrallel pci buses.  I'm
> >not certain if they are even bridged.
> >
> >Unless there is a performace problem setting busses = 256, and
> >scanning all potential PCI busses should be much more reliable.
> 
> Do you know how Linux does it?

I know some of it I haven't been over the entire code.  What I don't
know is how linux finds multiple host bridges.  It might just
recognize a wider class of devices as bridges then  etherboot. What it
does is that it starts with the first bus, and recurses into buses
when it finds a different bus number.  linux also knows about a lot of
different hardware, so it can reconfigure it correctly.  

But linux is trying for a lot more than etherboot.  Etherboot already
makes the assumption that BIOS has setup the PCI bus (at least enough
for it's uses).  So it doesn't need to be half as thorough.

Seriously if we make scan bus have busses = 256.  And then never
increment the bus count we will be fine, and the code will be simple.

255 is the maximum possible bus number, and etherboot already tests
for the presence of a pci device in the slot, so it should ignore an
unused bus pretty quickly.  It already correctly ignores an unused
bus or the previous patch wouldn't have worked.  Plus etherboot has an
early out mechanism, so we shouldn't even get past the first pci bus
on most machines. 

Eric

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

Dear Ken,

I got the tagged image completed, but it didn't boot. Rather it rebooted!

What I did was to create a tagged image such that

1. The loading address of first 512 bytes of the image itself is 9320:0000
2. Start address is 9000:0200
3. Bootsector is loaded at 00090000 (512/512 - memory / image length)
4. Setup is loaded at 00090200 (2048/2048)
5. The rest is loaded at 00010000 (65020/65020 as of precomp.bin -precompiled
   image)

The total size of precomp.bin is 512+2048+65020=67580 and the tagged image
is 512 bytes larger.

Any suggessions would be highly appreciated.

Anuradha

PS: Yes. I checked the tagged image with both disnbi and hexdump. The rest
of the first 512 bytes were padded with zeros.

On Wed, 16 May 2001, Ken Yap wrote:

> >See if this two line change to mknbi.pl makes it work on memtest86.bin
> 
> Actually on looking at memtest86/setup.S, it won't work, because
> first32.c writes to various locations in the setup segment, and will
> overwrite valid code because memtest86/setup.S doesn't have those memory
> areas reserved. So yes, you need to make a tagged image builder for it.
> Pity you didn't write an function in mknbi.pl to do it.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

Re: [Etherboot-developers] booting non linux images

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

>See if this two line change to mknbi.pl makes it work on memtest86.bin

Actually on looking at memtest86/setup.S, it won't work, because
first32.c writes to various locations in the setup segment, and will
overwrite valid code because memtest86/setup.S doesn't have those memory
areas reserved. So yes, you need to make a tagged image builder for it.
Pity you didn't write an function in mknbi.pl to do it.

Re: [Etherboot-developers] booting non linux images

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

>Finally wrote a small C program to convert memtest86.bin to a tagged
>image. It

See if this two line change to mknbi.pl makes it work on memtest86.bin

--- mknbi.pl.orig	Sat May  5 05:21:39 2001
+++ mknbi.pl	Wed May 16 16:19:12 2001
@@ -186,8 +186,8 @@
 	print STDERR 'sig ver flags', "\n" if (DEBUG);
 	print STDERR "$sig $ver $flags\n" if (DEBUG);
 	if ($sig ne 'HdrS' or $ver < 0x201) {
-		print STDERR "$kernelfile: not a Linux kernel image\n";
-		return;
+		print STDERR "Warning: $kernelfile: not a Linux kernel image, maybe it's memtest86.bin?\n";
+		# return;
 	}
 	$bigker = ($flags & 0x1);
 	$kernelseg = { file => $ARGV[0],

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On Tue, 15 May 2001, Ken Yap wrote:

> >BTW, please let me know if the documentation regarding a tagged images
> >_with_ a first magic number is correct and whether etherboot handles them
> >(unlike the ones with a second magic number)?
> 
> Yes, it is correct.

Finally wrote a small C program to convert memtest86.bin to a tagged
image. It

1. Loads the first 512 bytes of the tagged image to 9320:0000 (arbitrary)
2. Start address is 9000:02000
3. The first 512 bytes (boot sector) is loaded to 0x00090000 - probably
   superfluous
4. Next 2048 bytes are loaded to 0x00090200 (starting point)
5. The "kernel" part is loaded to 0x00010000

I checked this image with disnbi and it reports correct values. Didn't
test it yet. Will let you all know the progress once I test it in the
evening.

Thanks for all who helped me this out.

Regards,

Anuradha

Re: [Etherboot-developers] Re: [Etherboot-users] pci.c patch

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

>For the last case reported on this list, this code won't solve it.
>The problem there was serverworks has 2 parrallel pci buses.  I'm
>not certain if they are even bridged.
>
>Unless there is a performace problem setting busses = 256, and
>scanning all potential PCI busses should be much more reliable.

Do you know how Linux does it?

[Etherboot-developers] Re: [Etherboot-users] pci.c patch

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

Ken Yap <ke...@bi...> writes:

> Finally I got around to looking at Steve Smith's patch for PCI-PCI
> bridges. Here's the patch. Could people who are having problems with
> NICs not on PCI bus 0 please try this to see if it helps?

For the last case reported on this list, this code won't solve it.
The problem there was serverworks has 2 parrallel pci buses.  I'm
not certain if they are even bridged.

Unless there is a performace problem setting busses = 256, and
scanning all potential PCI busses should be much more reliable.

I wish I had the time at the moment to test it...

Eric


> 
> --- etherboot-5.0.1/src/pci.c	Mon Apr  2 19:00:04 2001
> +++ etherboot-5.0.2/src/pci.c	Wed May 16 02:19:17 2001
> @@ -385,7 +385,16 @@
>  			pcibios_read_config_byte(bus, devfn, PCI_CLASS_CODE,
> &class);
> 
>  			pcibios_read_config_byte(bus, devfn, PCI_SUBCLASS_CODE,
> &subclass);
> 
>  			if (class == 0x06 && subclass == 0x04)
> +			{
>  				buses++;
> + /* Some BIOS's seem to configure the bridge with a gap in PCI bus numbers */
> 
> +				if (hdr_type == 0x01) /* PCI-PCI Bridge 1.1 */
> +				{
> + pcibios_read_config_dword(bus, devfn, PCI_BASE_ADDRESS_2, &ioaddr);
> 
> +					if (((ioaddr>>16) & 0xff) > buses)
> +						buses = (ioaddr>>16) & 0xff;
> +				}
> +			}
>  
>  #if	DEBUG
>  			printf("bus %x, function %x, vendor %x, device %x\n",
> 
> _______________________________________________
> Etherboot-users mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-users

[Etherboot-developers] pci.c patch

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

Finally I got around to looking at Steve Smith's patch for PCI-PCI
bridges. Here's the patch. Could people who are having problems with
NICs not on PCI bus 0 please try this to see if it helps?

--- etherboot-5.0.1/src/pci.c	Mon Apr  2 19:00:04 2001
+++ etherboot-5.0.2/src/pci.c	Wed May 16 02:19:17 2001
@@ -385,7 +385,16 @@
 			pcibios_read_config_byte(bus, devfn, PCI_CLASS_CODE, &class);
 			pcibios_read_config_byte(bus, devfn, PCI_SUBCLASS_CODE, &subclass);
 			if (class == 0x06 && subclass == 0x04)
+			{
 				buses++;
+				/* Some BIOS's seem to configure the bridge with a gap in PCI bus numbers */
+				if (hdr_type == 0x01) /* PCI-PCI Bridge 1.1 */
+				{
+					pcibios_read_config_dword(bus, devfn, PCI_BASE_ADDRESS_2, &ioaddr);
+					if (((ioaddr>>16) & 0xff) > buses)
+						buses = (ioaddr>>16) & 0xff;
+				}
+			}
 
 #if	DEBUG
 			printf("bus %x, function %x, vendor %x, device %x\n",

[Etherboot-developers] some rom-o-matic.net stats

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

[resent -- please pardon if duplicate]

I thought it might be interesting to take a week of ROM-o-matic.net data 
and do a simple count of what ROMs were requested. Below is a simple 
count of each ROM image type requested sorted in reverse order by 
frequency.

This will give you a rough idea of what kinds of Etherboot images people 
are generating.  With a little more work (and using the table in the NIC 
file in the Etherboot distribution) one could reduce the data further by 
the actual driver that is being used.  For example, the tulip driver 
handles lots of different ROM images, as does the 3C90x driver.  I can 
hear some enterprising perl hackers in the background already getting 
their associative arrays going right now... :-)

Anyway, this was just for curiosity's sake.  The rom-o-matic has been 
doing about 1000 ROM images a week for the last month:

access_log.20010422: 951
access_log.20010429: 1160
access_log.20010506: 1080
access_log.20010513: 1132

So here's the data.  It's nice to see that people are making use of the 
service.

Enjoy :-)

Marty

http://rom-o-matic.net/ 
ROM images generated for the period 
Sunday, May 6, 2001 04:00 to Sunday, May 13, 2001 04:00

Total                    1132

rtl8139                   176
ne                        157
3c509                     105
eepro100                   86
rtl8029                    60
3c503                      49
sis900                     43
3c905c-tpo                 41
tulip                      35
3c905b-tpo100              25
davicom9102                21
wd                         19
lancepci                   17
ne2100                     15
3c905b-fx                  14
3c590                      12
3c905b-tpo                 12
eepro                      12
intel21145                 12
dlink-530tx                11
82559er                    10
via-rhine                  10
otulip                      9
sis7016                     8
3c900b-combo                7
dc21041                     7
mx98715                     7
amdhomepna                  6
kne110tx                    6
smc1211                     6
3c905b-combo                5
compexrl100atx              5
dlink-530tx-old             5
lc82c115                    5
rl100tx                     5
smc9000                     5
3c905-tpo                   4
3c905-tpo100                4
3c905b-t4                   4
cs89x0                      4
dfe530tx%2B                 4
mx98713                     4
pcnetfastiii                4
3c595                       3
3c905-t4                    3
davicom9009                 3
ds21140                     3
ds21142                     3
ds21143                     3
epic100                     3
ktiet32p2                   3
mx98725                     3
mxic-98715                  3
3c900b-tpo                  2
3c905-combo                 2
depca                       2
nepci                       2
winbond840                  2
winbond940                  2
3c507                       1
3c529                       1
3c595-1                     1
3c595-2                     1
3c900-t4                    1
3c900-tpo                   1
3c900b-fl                   1
3c900b-tpb2                 1
3c905b-fl                   1
3c905b-tpb2                 1
82562em                     1
82c168                      1
an981                       1
ax88140                     1
ax88141                     1
centaur-c                   1
centaur-p                   1
compexrl2000                1
dc21040                     1
dm9100                      1
dm9102                      1
ds21140a                    1
exos205                     1
id1029                      1
id1030                      1
ni5010                      1
ni5210                      1
ni6510                      1
nv5000sc                    1
sk_g16                      1
tiara                       1
tulip21142                  1
via-rhine-old               1
xircomtulip                 1


---
    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/