Re: 3C90B 3C90C 8k MII Bug

[Greg Beeley <Greg.Beeley@LightSys.org>]

Hi all,

> The bug was that the 3C905B with the Lucent chipset and some early prototypes
> ofthe 3C905C didn't map contents of the ROM properly - the ROM was remapped to
> the shadow memory after every 4K, not 8K as is commonly thought. Even the  ROM
> couldn't be properly read directly using ASIC I/O access to the ROM - it
> produced the same remapping problem. Forcing the ASIC into MII mode solved the
> problem, but it was required that one restored the ASIC to  its original setup
> afterwards.

That sounds like the issue :)  Thanks for the additional info.  Sounds like
some ROM authors had to go to extensive lengths to get this to work right....

When faced with finding a workaround, I considered quite a number of 
possible alternatives.  Something similar to what you suggested was one
of the alternatives.  The way that Etherboot works around the issue is the
following:

1.  The serial EEPROM is reprogrammed for MII mode, with autoselect bit
    still set.
2.  Machine is turned on, card enters MII mode, and everything works fine
    with the Etherboot image being copied into RAM and executed.
3.  Drivers for all OS's I've tested so far (including Etherboot to some
    degree) boot the card, see the autoselect bit, and thus ignore the
    MII setting (per 3com documentation), and reset the XcvrSelect value
    to the right one automatically, per standard procedures.  The new
    XcvrSelect setting is in the register, not the EEPROM, so it is not
    permanent.
4.  If the user wants to pre-program an XcvrSelect value in etherboot,
    etherboot stores the desired XcvrSelect value in the "Reserved for
    LanWorks ROM" area in the serial EEPROM, and uses that to program
    the XcvrSelect when etherboot comes up.

There are some minor caveats with this approach, but it seemed easiest,
most compatible with the existing Etherboot structure, and it works.  To
implement a bootblock-mainblock type of structure that would be more
compatible with the ROM mapping problem would have required a major
overhaul of some of the internal etherboot modularity, and a lot of code
re-writing.  So, path of least resistance :)

(the main caveat of this approach is that when the remote-booted O/S 
autoselects the Xcvr, it may not choose the one you want.  For instance,
if you are connected to a 10/100 unmanaged hub over low-end cabling, you
might want to go 10mbit not 100mbit, and will need to tell the OS to use
a different Xcvr.  We had to do that here with Linux.  But since we're
network-booting, we just had to make the change in *ONE* place <grin>)

Greg.

------------------------------------------------------------------------
Greg.Beeley@LightSys.org        LightSys - Redeeming Technology...
http://www.LightSys.org                    For God's Kingdom.
------------------------------------------------------------------------
===========================================================================
This Mail was sent to netboot mailing list by:
Greg Beeley <Greg.Beeley@LightSys.org>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.