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

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@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@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