[PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info)

[Luka Kovacic]

Hello Marek,

> These differences between Marvell's version and U-Boot's standard
> environment version can be specified in device-tree (via compatible or
> other properties) and handled by one driver.
>
> A driver for nvmem provider of standard U-Boot env could have this
> binding (with "denx,u-boot-env" as compatible, changing it to
> "marvell,hw-info" would make it work with spaces instead of '=' as
> separator):

An nvmem provider would be an interesting approach to read U-Boot
environment parameters from Linux and to maybe even get the U-Boot env
partition location in U-Boot (like DM for the env).

A single driver would work, maybe support for the checksum would get more
difficult to integrate.

>
>   spi-flash {
>     blah blah blah;
>
>     partitions {
>       compatible = "fixed-partitions";
>       #address-cells = <1>;
>       #size-cells = <1>;
>
>       hw-info at 18000 {
>         compatible = "denx,u-boot-env";
>         reg = <0x18000 0x1000>;
>         label = "hw-info";
>
>         eth0_mac_addr: ethaddr {
>           compatible = "mac-address-string";
>           name = "ethaddr";
>         };
>
>         eth1_mac_addr: eth1addr {
>           compatible = "mac-address-string";
>           name = "eth1addr";
>         };

I don't see any better approach than just matching strings to retrieve
values for specific keys (for MACs), so this looks good to me.

>       };
>     };
>   };
>
>   ethernet at 30000 {
>     nvmem-cells = <&eth0_mac_addr>;
>     nvmem-cell-names = "mac-address";
>   };
>
>
> On Turris MOX, we have the MAC address of the device stored in
> One-Time-Programmable memory accesible only by the secure coprocessor,
> which Linux communicates with via the turris-mox-rwtm kernel driver.
>
> Currently this driver does not register itself as a nvmem provider, and
> so isn't use by the ethernet controller driver to get MAC addresses.
> MAC addresses are currently read by U-Boot board code and the
> controller keeps these to Linux.
>
> But I plan to extend the turris-mox-rwtm driver to also provide MAC
> addresses via nvmem API, and then specify in device-tree
>   &eth1 {
>     nvmem-cells = <&rwtm_eth1_mac>;
>     nvmem-cell-names = "address";
>   };
>
> Maybe in the future you will also want to implement this in Linux.
> It could be done simply by adding a new type of nvmem provider, with
> compatible = "marvell,hw-info".
>
> Luka, what do you think?

> Also we need to add nvmem API into U-Boot and get rid of the ad-hoc
> efuse/mac/hw_mac nonsense.

I agree, a real nvmem API would be much cleaner than the current U-Boot
implementation, as there is currently no way to programmatically access
these parameters and the implementations have different user interfaces.

As there is currently no nvmem framework, I recommend that the basic,
futureproof DT bindings are defined and DT parsing is temporarily
implemented in the hw_info mac command. What do you think?

Is anyone already working on a nvmem framework to support nvmem
providers in U-Boot?

Kind regards,
Luka