RFC of_boardconfig

RFC of_boardconfig

[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.

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>;
        };

Re: RFC of_boardconfig

[Rob Herring]

On 11/25/2011 07:52 AM, John Crispin wrote:
> 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 -->
> 

Sounds like a generic, undefined use name, but your use is specific.

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

magic values do what?

> - 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";

How is label used?

>                         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 ];

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

>                 mac-boardconf = <&eep lanmac>;
>         };
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: RFC of_boardconfig

[John Crispin]

> 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


>>                         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 ];
> 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