3C905B-TX Boot Prom Mapping?

Oscar Stiffelman stiffelman@cs.stanford.edu
Sun Feb 28 13:56:10 1999


Hi,

I am working on getting a diskless beowulf with bootp/tftp running Linux
(Redhat for Intel).  I recently set up a diskless node using the 3c905B-TX-M
(the MBA card).  I used an intermediate boot loader,
http://cuiwww.unige.ch/info/pc/remote-boot/ and PXE.  I was not able to boot
directly to the linux kernel (without using the intermediate boot loader).

-- Oscar Stiffelman

> -----Original Message-----
> From: owner-linux-vortex@beowulf.gsfc.nasa.gov
> [mailto:owner-linux-vortex@beowulf.gsfc.nasa.gov]On Behalf Of Dan Marks
> Sent: Sunday, February 28, 1999 7:51 AM
> To: linux-vortex@beowulf.gsfc.nasa.gov
> Subject: 3C905B-TX Boot Prom Mapping?
>
>
>
> I am interested in using the NetBoot package to create a BOOTP/TFTP image
> for my 3Com 3C905B-TX ethernet card.  However, it seems that the
> "standard"
> type ROM images do not work.  I have the version of the card that has the
> vertical ROM socket, not the horizontal one.  What I am calling
> the "standard"
> ROM type is the type that maps the entire ROM contents (usually
> 16k or 32k)
> into the upper conventional memory area.  It appears that this version of
> the 3C905B I have does not do this.  The 3C905B takes either a 64k or 128k
> part (the ATMEL 29C512 or 29C010).  It seems that in order to
> avoid mapping
> in such a large ROM in its entirety, 3Com decided to have only the first
> 2 kilobytes of the ROM visible in the conventional memory area.  The code
> in this 2K copies the remaining 62K off of the ROM into
> conventional memory
> (I think) where it is executed and the actual boot loader code runs.
>
> This means that the conventional boot ROMs that can be built by
> the NetBoot
> package (http://www.han.de/~gero/netboot/) won't work because they expect
> to be mapped in their entirety into conventional memory.  I do not have
> the 3C905B-TX technical (register level type) documentation.  But if there
> were a register on the 3Com board that controls how much of the ROM is
> mapped into conventional memory (such as in the EEPROM), then perhaps it
> could be set to allow the entire memory to be mapped.
>
> Alternatively, if the registers on the 3C905B-TX were known that controls
> the memory mapping into extended memory of the ROM, then a similar boot
> loader snippet could be written for the visible 2K of the 3C905B boot ROM
> that would similarly copy the Netboot code into conventional memory and
> allow it to function normally.
>
> Another snag I've found is that it seems there may be a special
> "signature"
> needed to make the ROM visible that I do not know.  This "signature" if it
> existed would be above and beyond the "55AA" signature for any ROM in the
> PC architecture, and is also not the "$Pnp" or "PCIR" signature
> blocks that
> are present in the ROMS for PNP and PCI cards (or perhaps it may be a
> nonstandard version of these signature blocks).  I have attempted to build
> a NetBoot ROM on a 29C512 part with the PCIR and $Pnp signatures that
> signify a network bootable ROM, but the 3Com card refuses to even map it
> at all and does not allocate any conventional memory space for
> it.  I think
> the 3C905B may be looking for this signature and not mapping the card at
> all if it does not find it.  All I can really find out about the signature
> from 3Com is that, because they have acquired a company called Lanworks
> to write their boot roms for them, they have decided to make all of the
> boot ROMs proprietary and the information about such a signature would not
> be available from 3Com.  This is especially disappointing because it would
> probably mean that future 3Com cards would require proprietary boot PROMs.
>
> This new ROM format is part of the 3Com "Tri-ROM" MBA ROM format (I guess
> so named because it supports TCP/IP, Netware, and PXI), which is what
> necessitated such a large ROM part to be used.
>
> So far this is what I know.  If someone knows any technical information
> about the ROMs or their mapping registers it would be much appreciated.
>
> Dan Marks
> dmarks@uiuc.edu
>