[En-Nut-Discussion] FW: AVR32 / ARM support

[Bernd Walter]

On Tue, Sep 28, 2010 at 11:43:07AM -0300, Thiago A. Corrêa wrote:
> Hi Johan,
> 
> 
> 
> On Tue, Sep 28, 2010 at 9:34 AM, Johan van der Stoel <johan at streamit.eu> wrote:
> > 2.       We want to have more advanced support of Ethernet devices and
> > networking; currently we use RTL8019, but in our new platform we want to be
> > able to support devices with MII / RMII interfaces and also switches with
> > this kind of interfaces, like the Micrel KS8993 and KS8995. In the postings
> > I have read about some limitations; is someone able to comment on the
> > complexity once we decide to proceed with this?
> 
> I don't have too much experience with this, except from what I learned
> porting the MAC driver for the AVR32. But it looks like those switches
> behave just like a normal PHY when using the MII/RMII interface. I
> have only briefely looked at the datasheets though.
> PHY devices seems to implement a common command interface. The only
> part of Nut/OS that I'm aware that prevents from using a different phy
> is the initialization. It queries the device ID to make sure it's what
> it expects. The expected value can be configured with nutconf, or the
> verification can be disabled entierely (for AVR32 and some ARMs).

I have no expirience with the Micrel, but I'm running AT91SAM7X256 with
RTL8305SC.
The RTL8305SC - and I think the Micrel too - uses multiple PHY addressings
for the ports and additional for further VLAN registers.
PHY0 contains link speed/duplex information for port0, PHY1 for port1, ...
When negotiating link specification for MII you need to hardcode the
values to 100M-FDX instead of using the unrelated port0 negotiation.
Getting the MII wiring right is by far more difficult than to do the
software part - nothing to worry about.
My local patch is available under http://www.cicely.de/~ticso/at91_emac.c

> > 3.       IPv6 support.

Unfortunately there is a lot of work to be done.
- we need sypport for multiple IPs per interface.
  IPv6 without multiple addresses is very restricted.
- we need multicast
  IPv6 uses multicast for neigbor discovery (see next point)
  local LAN only multicast support is basicly just adding addresses
  with accoring multicast filters.
- we need IPv6 neighbor discovery, which is based on multicast and is
  the IPv6 replacement for IPv4 broadcast based ARP.
  There is no basic requirement for multicast over routers, since it
  is only important on the local LAN.
- we need IPv6 IP layer itself.
  The new IP headers are not so much a big deal, but might be some
  challenging points to get dual stack working.
  TCP for example must know if the socket is for v4 or v6.
  I think a few places assume that IP addresses can be passed using int32
  instead of v4/6 independed socket address structs as done in BSD sockets.
- we need at least lazy DAD for stateless link local autoconfiguration.
  This shouldn't be a big deal, since it is based on neighbor discovery,
  which is alreasy a basicl requirement.
- we need to extend name resolution including parsing IPv6 string
  addresses into binary IPv6 addresses.
- we should have router discovery support for stateless unicast address
  configuration.
  This is another multicast usecase.
- we might want to extend DHCP client to IPv6, but using stateless
  autoconfiguration is good enough dynamic configuration in most networks.
- whatever I might have missed...

> I would like to see that as well :)

We should start with multiple address support and then do multicast.
Although multicast isn't that important for IPv4 it is a basic
IPv6 requirement and it needs multiple addresses first, since we need
to maintain a list of participated multicast groups.
Each NIC driver should to be extended for multicast to setup multicast
hashes - as a bad workaround activating promiscuous will do, but that
way the CPU will have to parse several unrelated packets even in a
switched network.
I know how to calculate the hash tables with AT91 ATE interfaces, since
I recently fixed the hash calculation in the FreeBSD driver - to get
IPv6 working on AT91RM9200...

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.