In message <20060217180019.GA5434@nbholecek.uamt.feec.vutbr.cz>, Jachym Holecek
 writes:
>  1. config_defer() the part of emac(4) initialization that _really_
>     needs to know MAC address -- this would be the address filter
>     setup and ethar_ifattach() I think -- and make gpiic fill in
>     the MAC into property database for emac(4) to pick up.
>
>     [Note that my knowledge of the emac(4) is superficial -- just
>      took a peek at it this week when working on TEMAC for
>      evbppc/virtex (TBD RSN ;)]
>
>  2. the IIC seems to bitbanged over a few OPB registers, so cover
>     them with initial TLB mapping and modify gpiic so that it
>     provides inippc() with a way to get at the bus. Then, from
>     initppc() load the MAC address to property database and have
>     emac(4) pick it up later.
>
>I'm not sure either of these is exactly nice though...

I found something which is either much better, or much worse:

In emac_reset, store the values of EMAC_IAHR and EMAC_IALR, then restore them
after the reset.

Then, if the emac0-mac-addr isn't set, just use those values.  Since the boot
loader has already correctly configured the chip anyway, I don't need to do
anything clever at all.

Note that, at least in Linux-land, the relevant stuff is already mapped very
early on.

But hey, this hacky solution is probably good enough for now, and I can't
think of a system being broken by it, so...  Good enough.

Now I probably just need to fix interrupt tables and TLB mapping.
Unfortunately, the only real source I have is the Linux source, which is
written for a totally different API.  I am pretty sure something is wrong,
because the dp83815 (secondary ethernet) is coming up with a MAC address
of ff:ff:ff:ff:ff:ff.  However, I don't know what I'm doing at all on this
part.  It appears to involve disabling regions, programming values into
registers, and reenabling regions.

-s