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

Willy Tarreau w at 1wt.eu
Mon Jun 3 17:04:17 EDT 2013


On Mon, Jun 03, 2013 at 03:01:42PM -0400, Nicolas Pitre wrote:
> 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.

Indeed, they're on the u-boot environment. But I don't think that it
really helps, because the variables in RAM are most likely lost and
anyway not well structured, and the ones on the flash require a
properly working flash driver before being extracted (not to mention
that they're the stored ones, not the active ones, but that's just
nitpicking).

Best regards,
Willy




More information about the linux-arm-kernel mailing list