Re: Newbie looking to figure out how to do a port!
[email protected] (Peter Seebach) Fri, 17 Feb 2006 12:09:02 -0600
| Newsgroups | gmane.os.netbsd.devel.ports |
|---|---|
| Message-ID | <[email protected]> |
In message <[email protected]>, 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