[PATCH] ARM: atags: add support for Marvell's u-boot

[Nicolas Pitre]

On Mon, 3 Jun 2013, Jason Cooper wrote:

> On Mon, Jun 03, 2013 at 08:30:57PM +0200, Willy Tarreau wrote:
> > Hi Jason,
> > 
> > On Mon, Jun 03, 2013 at 02:14:37PM -0400, Jason Cooper wrote:
> > > > I understand your points, but then what could we do to get our devices
> > > > to have properly working ethernet interfaces ? These devices have already
> > > > been sold, and from what I've seen they've been using this ID since at
> > > > least the Kirkwood devices.
> > > > 
> > > > I found no other way to get the MAC address once the system is booted.
> > > > I would have no problem having some board-spec code locate the atags
> > > > and set the MAC, but it looks like the information is lost very early
> > > > and is not available anymore soon after the boot (or at least I couldn't
> > > > find it anywhere else).
> > > > 
> > > > It's really not with happiness that I had to add this part to the ATAGs,
> > > > but because I didn't find another solution :-(
> > > 
> > > Please take a look at Sebastian's approach, it's currently a wip:
> > > 
> > >   ARM: kirkwood: proper retain MAC address workaround on DT ethernet
> > > 
> > > The discussion following that patch should give you some good ideas.
> > 
> > I remember this discussion, but it is different and does not apply here.
> > Sebastian fixed an issue with a properly configured NIC which used to
> > lose its MAC, so the solution consisted in saving it early in the DT.
> > 
> > In the mv_neta case, the NICs are not configured yet and we need to
> > find the MAC somewhere. I only found it in the ATAGs and nowhere else.
> 
> ahhh, that's annoying.  :-(
> 
> > Well, in fact u-boot sets it on the MAC used to boot from the network
> > if such a boot is performed, but that's all. So in practice you boot
> > without the MAC address anywhere but in the ATAGs. I'd be happy to
> > find a way to parse non-standard atags in a board-specific file but
> > they're lost early it seems :-(
> 
> I assume they are in the u-boot environment.  As such, the only answer
> may be to have user space utilities like flash-kernel parse the
> environment and then customize the appended DT for the specific board.

Or some board specific code could dig them out of the flash.  That at 
least would make this hack localized while keeping the common code 
clean.

Isn't upstream U-Boot supporting Marvell devices properly these days?  
If so maybe considering a U-Boot upgrade would be the best way forward?


Nicolas