Commit Graph

2 Commits

Author SHA1 Message Date
Adrian Chadd
b7d7ad0b90 Begin moving support for board MAC addresses over to being explicitly defined.
A lot of these dinky atheros based MIPS boards don't have a nice, well,
anything consistent defining their MAC addresses for things.

The Atheros reference design boards will happily put MAC addresses
into the wifi module calibration data like they should, and individual
ethernet MAC addresses into the calibration area in flash.
That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from
that flash address to extract a MAC, and everything works fine.

However, aside from some very well behaved vendors (eg the Carambola 2
board), everyone else does something odd.

eg:

* a MAC address in the environment (eg ubiquiti routerstation/RSPRO)
   that you derive arge0/arge1 MAC addresses from.
* a MAC address in flash that you derive arge0/arge1 MAC addresses from.
* The wifi devices having their own MAC addresses in calibration data,
  like normal.
* The wifi devices having a fixed, default or garbage value for a MAC
  address in calibration data, and it has to be derived from the
  system MAC.

So to support this complete nonsense of a situation, there needs to be
a few hacks:

* The "board" MAC address needs to be derived from somewhere and squirreled
  away.  For now it's either redboot or a MAC address stored in calibration
  flash.

* Then, a "map" set of hints to populate kenv with some MAC addresses
  that are derived/local, based on the board address.  Each board has
  a totally different idea of what you do to derive things, so each
  map entry has an "offset" (+ve or -ve) that's added to the board
  MAC address.

* Then if_arge (and later, if_ath) should check kenv for said hint and
  if it's found, use that rather than the EEPROM MAC address - which may
  be totally garbage and not actually work right.

In order to do this, I've undone some of the custom redboot expecting
hacks in if_arge and the stuff that magically adds one to the MAC
address supplied by the board - instead, as I continue to test this
out on more hardware, I'll update the hints file with a map explaining
(a) where the board MAC should come from, and (b) what offsets to use
for each device.

The aim is to have all of the tplink, dlink and other random hardware
we run on have valid MAC addresses at boot, so (a) people don't get
random B:S:Dx:x ethernet MACs, and (b) the wifi MAC is valid
so it works rather than trying to use an invalid address that
actually upsets systems (think: multicast bit set in BSSID.)

Tested:

* TP-Link TL_WDR3600 - subsequent commits will add the hints map
  and the if_ath support.

TODO:

* Since this is -HEAD, and I'm all for debugging, there's a lot of
  printf()s in here.  They'll eventually go under bootverbose.
* I'd like to turn the macaddr routines into something available
  to all drivers - too many places hand-roll random MAC addresses
  and parser stuff.  I'd rather it just be shared code.
  However, that'll require more formal review.
* More boards.
2015-03-28 23:40:29 +00:00
Adrian Chadd
3bd3e39e1a Start fleshing out some MAC address helper functions.
A lot of these embedded boards don't have a unique MAC address per
device stored somewhere unique - sometimes they'll have one MAC
for both arge NICs; someties they'll have one MAC for both arge NICs
/and/ the ath NICs.  In these instances, we need to derive device
specific MAC addresses from the base MAC address.

These functions will be used by some follow-up code that'll slot
into if_arge and if_ath.
2015-03-15 21:56:12 +00:00