RFC of_boardconfig
Hi All,
before starting to implement the following proposed wrappers, i wanted to get some more views on the feasibility of these wrappers.
On most routers that OpenWRT supports, we will find a sector within a MTD device that holds the board specific info like MAC, wifi calibration data ...
These wrappers try to provide a generic representation of these board configuration sectors.
Thank you,
John
Documentation/devicetree/bindings/boardconfig.txt -->
The boardconfig master node requires the following properties:
- compatible - should be set to "boardconfig"
- partition - the partition that the data is stored in
"<&partition offset size>"
boardconfig slave nodes require the following properties:
- label - the name that the config element gets exported by
- data - information describing the actual data
"<offset size validator>"
both node types allow to set the following optional properties
- magic - check for magic sequence at correct offset
<offset byte1 byte2 ... byteN>
- no-export - if this property is set the data will *not* be
exported via sysfs
It is possible to define N of these sections within the device tree.
Boardconfig example for a device with 2 macs and a wmac eeprom:
eep: boardconfig {
compatible = "boarconfig";
partition = <&boardconfpart 0x0 0x100>;
magic = <0x0 0x11 0x22>;
lanmac {
label = "LAN";
data = <0x100 0x6>;
};
wanmac {
label = "WAN";
data = <0x106 0x6>;
};
ath9keeprom {
label = "eeprom";
partition = <0x200 0x200>;
magic = <0x0 0x55 0xaa 0xaa 0x55>;
no-export;
};
};you can are then able to reference these properties from other nodes:
ethernet {
compatible = "ethernet";
phy-mode = "mii";
//mac-address = [ 00 11 22 33 44 55 ];
mac-boardconf = <&eep lanmac>;
};A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · John Crispin
Hi All,
before starting to implement the following proposed wrappers, i wanted to get some more views on the feasibility of these wrappers.
On most routers that OpenWRT supports, we will find a sector within a MTD device that holds the board specific info like MAC, wifi calibration data ...
These wrappers try to provide a generic representation of these board configuration sectors.
Quoted 7 lines
Thank you,
John
Documentation/devicetree/bindings/boardconfig.txt-->
Sounds like a generic, undefined use name, but your use is specific.
Quoted 5 lines
The boardconfig master node requires the following properties:
- compatible - should be set to "boardconfig"
- partition - the partition that the data is stored in
"<&partition offset size>"
Quoted 8 lines
boardconfig slave nodes require the following properties:
- label - the name that the config element gets exported by
- data - information describing the actual data
"<offset size validator>"both node types allow to set the following optional properties
- magic - check for magic sequence at correct offset
<offset byte1 byte2 ... byteN>
magic values do what?
Quoted 5 lines
- no-export - if this property is set the data will *not* be
exported via sysfsIt is possible to define N of these sections within the device tree.
Quoted 7 lines
Boardconfig example for a device with 2 macs and a wmac eeprom:
eep: boardconfig { compatible = "boarconfig"; partition = <&boardconfpart 0x0 0x100>; magic = <0x0 0x11 0x22>; lanmac { label = "LAN";
How is label used?
Quoted 16 lines
data = <0x100 0x6>;
};
wanmac {
label = "WAN";
data = <0x106 0x6>;
};
ath9keeprom {
label = "eeprom";
partition = <0x200 0x200>;
magic = <0x0 0x55 0xaa 0xaa 0x55>;
no-export;
};
};Quoted 5 lines
you can are then able to reference these properties from other nodes:
ethernet { compatible = "ethernet"; phy-mode = "mii"; //mac-address = [ 00 11 22 33 44 55 ];
Why throw out the defined way to set a MAC addr and invent something new. If it's separating out some of the properties you want, you can have multiple "ethernet" nodes with some properties in each node and it all gets combined together at dtb compile time. I think the Tegra and other ARM dts files have examples of this.
Rob
Quoted 8 lines
mac-boardconf = <&eep lanmac>; };_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
How is label used?
this would be used as a name when exporting the data, however you are right and the property name lanmac could be used here
Quoted 21 lines
Quoted 16 lines
data = <0x100 0x6>; }; wanmac { label = "WAN"; data = <0x106 0x6>; }; ath9keeprom { label = "eeprom"; partition = <0x200 0x200>; magic = <0x0 0x55 0xaa 0xaa 0x55>; no-export; }; };Quoted 5 lines
you can are then able to reference these properties from other nodes:
ethernet { compatible = "ethernet"; phy-mode = "mii"; //mac-address = [ 00 11 22 33 44 55 ];
Quoted 8 lines
Why throw out the defined way to set a MAC addr and invent something new. If it's separating out some of the properties you want, you can have multiple "ethernet" nodes with some properties in each node and it all gets combined together at dtb compile time. I think the Tegra and other ARM dts files have examples of this.
Rob
in my usecase there will be only 1 ethernet device. the mac is stored inside the devices flash and will not be passed as a parameter by the bootloader. We need to have some means to load things like mac addresses from memory mapped flash devices. This is the reasoning behind this wrapper