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