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

From: Willy Tarreau <[email protected]>

Marvell uses a specific atag in its u-boot which includes among other information the MAC addresses for up to 4 network interfaces. This atag is parsed, and if found the MAC addresses are extracted there and assigned to node aliases eth0..3 with the name "mac-address".

This allows, with the non-DT capable bootloaders currently used on most Marvell platforms, to get a proper MAC address for the different interfaces.

Signed-off-by Willy Tarreau <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

---
 arch/arm/boot/compressed/atags_to_fdt.c |  8 +++++++-
 arch/arm/include/uapi/asm/setup.h       | 18 ++++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

arch/arm/boot/compressed/atags_to_fdt.c +1 -1

index aabc02a..7f405ed 100644
@@ -16,7 +16,7 @@ static int node_offset(void *fdt, const char *node_path)
 }
 
 static int setprop(void *fdt, const char *node_path, const char *property,
-		   uint32_t *val_array, int size)
+		   void *val_array, int size)
 {
 	int offset = node_offset(fdt, node_path);
 	if (offset < 0)

Won't this override a user editing the 'local-mac-address' property in the dts? Since we're dealing with appended dtbs, there's a higher probability of the user doing such a thing.

I'll admit it's a corner case, but I'd like to make sure we've thought through the use cases and aren't making things more complicated than necessary.

Dear Jason Cooper,

Quoted 4 lines · Jason Cooper

Won't this override a user editing the 'local-mac-address' property in the dts? Since we're dealing with appended dtbs, there's a higher probability of the user doing such a thing.

Quoted 3 lines

I'll admit it's a corner case, but I'd like to make sure we've thought through the use cases and aren't making things more complicated than necessary.

I don't have a strong opinion about this one, so if it's seen as being necessary to preserve a potentially existing 'local-mac-address', then I'll add the necessary checks to only update the property if it doesn't already exist.

From: Willy Tarreau <[email protected]>

Marvell uses a specific atag in its u-boot which includes among other information the MAC addresses for up to 4 network interfaces. This atag is parsed, and if found the MAC addresses are extracted there and assigned to node aliases eth0..3 with the name "mac-address".

This allows, with the non-DT capable bootloaders currently used on most Marvell platforms, to get a proper MAC address for the different interfaces.

Signed-off-by Willy Tarreau <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

You know, my reaction to this is to nack it because:

(a) Marvell didn't talk to me about adding a new tag.
(b) There is an established precident that we do not pass MAC addresses to the kernel in this way (such attempts have been rejected in the past.)
(c) It goes completely against the design spirit of ATAGs by combining many different types and instances of information into one tag.
(d) It picks a tag ID without understanding how tag IDs are allocated.

    (the idea is 0x41NNNNVV where NNNN = machine ID for machine specific
    tags.)

Everyone who has gone around extending ATAG stuff has made exactly the same mistakes time and time again - mostly stemming from the fact that no one wants to talk to me up front.

So, this is another NACK.

Hi Russell,

Quoted 9 lines · Russell King - ARM Linux

You know, my reaction to this is to nack it because:

(a) Marvell didn't talk to me about adding a new tag.
(b) There is an established precident that we do not pass MAC addresses to the kernel in this way (such attempts have been rejected in the past.)
(c) It goes completely against the design spirit of ATAGs by combining many different types and instances of information into one tag.
(d) It picks a tag ID without understanding how tag IDs are allocated.

Quoted 8 lines

    (the idea is 0x41NNNNVV where NNNN = machine ID for machine specific
    tags.)

Everyone who has gone around extending ATAG stuff has made exactly the same mistakes time and time again - mostly stemming from the fact that no one wants to talk to me up front.

So, this is another NACK.

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 :-(

Quoted 32 lines · Willy Tarreau

Hi Russell,

Quoted 9 lines · Russell King - ARM Linux

You know, my reaction to this is to nack it because:

(a) Marvell didn't talk to me about adding a new tag.
(b) There is an established precident that we do not pass MAC addresses to the kernel in this way (such attempts have been rejected in the past.)
(c) It goes completely against the design spirit of ATAGs by combining many different types and instances of information into one tag.
(d) It picks a tag ID without understanding how tag IDs are allocated.

Quoted 8 lines

    (the idea is 0x41NNNNVV where NNNN = machine ID for machine specific
    tags.)

Everyone who has gone around extending ATAG stuff has made exactly the same mistakes time and time again - mostly stemming from the fact that no one wants to talk to me up front.

So, this is another NACK.

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).

Quoted 2 lines

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.

Quoted 11 lines

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).

Quoted 2 lines

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.

Hi Jason,

Quoted 18 lines · Jason Cooper

Quoted 5 lines

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.

Quoted 8 lines

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

Quoted 1 line

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 :-(

Quoted 21 lines · Willy Tarreau

Hi Jason,

Quoted 18 lines · Jason Cooper

Quoted 5 lines

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.

Quoted 8 lines

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

Quoted 8 lines

Quoted 1 line

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. :-(

Quoted 5 lines

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.

Quoted 39 lines · Jason Cooper

Quoted 21 lines · Willy Tarreau

Hi Jason,

Quoted 18 lines · Jason Cooper

Quoted 5 lines

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.

Quoted 8 lines

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

Quoted 8 lines

Quoted 1 line

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. :-(

Quoted 5 lines

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 :-(

Quoted 3 lines

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?

Quoted 13 lines · Nicolas Pitre

Quoted 10 lines · Jason Cooper

Quoted 5 lines · Willy Tarreau

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.

Quoted 3 lines

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.

If it comes to that, I think I would rather tell users to put the mac address on the commandline.

Quoted 3 lines

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.

If it comes to that, I think I would rather tell users to put the mac address on the commandline.

Quoted 2 lines

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?

Yes, both u-boot and barebox are supporting Marvell devices,

Quoted 3 lines · Jason Cooper

Quoted 2 lines

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?

Quoted 1 line

Yes, both u-boot and barebox are supporting Marvell devices,

Sorry Jason, but you're overstating the status of this support:

* Barebox has only *minimal* support for Marvell SoCs, i.e only the serial console and timers are supported. There is no support for network, NAND, SPI or anything that even allows to load a kernel and boot it.

* U-Boot has zero support for Armada 370 and Armada XP, and Sebastian has tried for several months to push support for Marvell Dove, without success (lack of review/interest from the U-Boot maintainers, if I remember correctly).

So as of today, the Marvell-specific U-Boot is the /only/ working solution for Armada 370 and Armada XP based platforms, and it will remain this way at least for several months, until we've pushed enough work into Barebox. And even at that time, as you say, users may not necessarily be willing to upgrade their bootloader.

Quoted 7 lines · Thomas Petazzoni

Quoted 4 lines · Jason Cooper

Quoted 2 lines

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?

Yes, both u-boot and barebox are supporting Marvell devices,

Sorry Jason, but you're overstating the status of this support:

Quoted 5 lines

* Barebox has only *minimal* support for Marvell SoCs, i.e only the serial console and timers are supported. There is no support for network, NAND, SPI or anything that even allows to load a kernel and boot it.

That remembers me that I wanted to make it boot from DT so we don't start adding drivers and add DT later on.

Quoted 4 lines

* U-Boot has zero support for Armada 370 and Armada XP, and Sebastian has tried for several months to push support for Marvell Dove, without success (lack of review/interest from the U-Boot maintainers, if I remember correctly).

True. It took about 2 month for a useful review and then the discussion was only about naming it orion-something or mv-something. Recently, someone picked up that patches and reposted them.. but don't expect them to get in quickly.

Quoted 5 lines

So as of today, the Marvell-specific U-Boot is the /only/ working solution for Armada 370 and Armada XP based platforms, and it will remain this way at least for several months, until we've pushed enough work into Barebox. And even at that time, as you say, users may not necessarily be willing to upgrade their bootloader.

Well, there is still the possibility to have board-specific dts files. If you are stuck for whatever reason with an old boot loader, append a dtb with MAC addresses set for your board. IMHO, adding workarounds for every single boot loader just because we don't want anybody to either update or manually patch the dts is ridiculous.

Isn't upstream U-Boot supporting Marvell devices properly these days?

Quoted 1 line · Nicolas Pitre

Isn't upstream U-Boot supporting Marvell devices properly these days?

And as Jason said, even though Armada 370 and Armada XP have a working UART-based recovery method, users are also scared of doing bootloader updates, and on some consumer products, the UART is not necessarily easily available to the average users (may need some soldering skills, a level-shifter to use the TTL UART of the board, etc.).

Hi Jason,

Quoted 11 lines · Jason Cooper

Quoted 11 lines

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).

Quoted 8 lines

Quoted 2 lines

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 :-(

Quoted 27 lines · Willy Tarreau

Hi Jason,

Quoted 11 lines · Jason Cooper

Quoted 11 lines

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).

Quoted 8 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

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 :-(