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 = <ð0_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
> ð1 {
> 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
