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