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

[Nicolas Pitre]

On Mon, 3 Jun 2013, 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.
> 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 :-(

Those MAC addresses must exist somewhere before they're wrapped into 
some special ATAG.  They're certainly not hardcoded into the u-boot 
binary.


Nicolas