recommended action for bootloaders regarding modifying device-tree nodes

recommended action for bootloaders regarding modifying device-tree nodes

[Tim Harvey]

Greetings,

I develop the boot-loader and kernel for a family of boards that have
an on-board EEPROM which contains information as to what options are
physically loaded on the board such as memory size/config, and
peripheral IC's.  We allow customers to create special builds of our
standard products with sub-loaded components and while each
combination of options ends up with a unique model number, it seems
silly to create a different static device-trees for each possible
option (not to mention we don't create the unique model number until
an order is placed).

My approach has been to define a per-baseboard device-tree in Linux
for a 'fully loaded' board, then remove nodes which the EEPROM claims
are not present in the bootloader before it passes the DTB to the
kernel.  I do this by defining aliases in the device-tree for the
peripherals that are 'optional' so that the bootloader itself does not
need to know the details about how the device is connected.

Is it more appropriate for the bootloader to 'remove' nodes for
devices that are not physically present or should I be setting their
status property to 'disabled' instead?  I'm not clear if either option
really has any pros or cons.

Thanks for any suggestions or comments,

Tim

Tim Harvey - Principal Software Engineer
Gateworks Corporation
3026 S. Higuera St. San Luis Obispo CA 93401
805-781-2000

[U-Boot] recommended action for bootloaders regarding modifying device-tree nodes

[Michal Suchanek]

Hello,

On 30 January 2014 10:11, Tim Harvey <tharvey@gateworks.com> wrote:
> Greetings,
>
>
> Is it more appropriate for the bootloader to 'remove' nodes for
> devices that are not physically present or should I be setting their
> status property to 'disabled' instead?  I'm not clear if either option
> really has any pros or cons.
>

I am not a DT or u-boot developer but I observe these things:

1) DT include for a SoC has all supported devices. Some which require
external parts (eg. physical connectors, extra PHY, ...) are listed as
disabled and particular board DT enables them.

2) there is code for setting mac address on ethernet nodes with a
specific alias so you could perhaps reuse this code to set disabled
option on particular nodes.

Thanks

Michal

recommended action for bootloaders regarding modifying device-tree nodes

[Jason Cooper]

Hi Tim,

On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
> My approach has been to define a per-baseboard device-tree in Linux
> for a 'fully loaded' board, then remove nodes which the EEPROM claims
> are not present in the bootloader before it passes the DTB to the
> kernel.  I do this by defining aliases in the device-tree for the
> peripherals that are 'optional' so that the bootloader itself does not
> need to know the details about how the device is connected.

This is more of a process question:  Is there any information captured
in your EEPROM that can't be represented in the dtb?  iow, at the point
when you write the EEPROM, why not write the dtb to it as configured?

You could have pre-configured dtsi fragments for each config option, and
then dynamically create the board dts from the order.

I only ask because it would solve the problem below.  However, there's a
lot more to changing a manufacturing process than meets the eye. :)

> Is it more appropriate for the bootloader to 'remove' nodes for
> devices that are not physically present or should I be setting their
> status property to 'disabled' instead?  I'm not clear if either option
> really has any pros or cons.

That depends on how you have it structured.  Is it a valid dtb?
Meaning, do you have four nodes all at the same register address?
Perhaps you could provide an example dts?

thx,

Jason.

> Tim Harvey - Principal Software Engineer
> Gateworks Corporation

btw - one of my first embedded projects was on one of your boards. An
ixp425 with 4 mini-pci slots.

recommended action for bootloaders regarding modifying device-tree nodes

[Jason Gunthorpe]

On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:

> This is more of a process question:  Is there any information captured
> in your EEPROM that can't be represented in the dtb?  iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?

I can share what we do here.. In our systems the serial EEPROM is only
256 bytes, so storing things in DT format would be challenging.

What we do is have a master DTB that has the union of all our
configurations. The boot process has a very simple bit of code that
runs down the DTB in binary format and replaces entire
OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.

The NOP approach is very simple, no other changes (eg offset
recalculation) needs to be done to the DT, so we can do this process
with a very small code footprint and without libfdt.

Choosing which sections to drop is done with some combination of
hardwired code and searching for specific property patterns. There are
also a few places where placeholder sections are directly fixed up, eg
a mac address is written into a placeholder of 0s, etc.

So an example might be

   optional_peripheral at 10000 {
      orc,board-style = <1>;
      [..]
   }

Eg The board-style number comes from the EEPROM and if board-style !=
1 then the entire stanza is replaced with NOP.

Jason

recommended action for bootloaders regarding modifying device-tree nodes

[Tim Harvey]

On Thu, Jan 30, 2014 at 1:15 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
>
> On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:
>
> > This is more of a process question:  Is there any information captured
> > in your EEPROM that can't be represented in the dtb?  iow, at the point
> > when you write the EEPROM, why not write the dtb to it as configured?
>
> I can share what we do here.. In our systems the serial EEPROM is only
> 256 bytes, so storing things in DT format would be challenging.
>
> What we do is have a master DTB that has the union of all our
> configurations. The boot process has a very simple bit of code that
> runs down the DTB in binary format and replaces entire
> OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.
>
> The NOP approach is very simple, no other changes (eg offset
> recalculation) needs to be done to the DT, so we can do this process
> with a very small code footprint and without libfdt.
>
> Choosing which sections to drop is done with some combination of
> hardwired code and searching for specific property patterns. There are
> also a few places where placeholder sections are directly fixed up, eg
> a mac address is written into a placeholder of 0s, etc.
>
> So an example might be
>
>    optional_peripheral at 10000 {
>       orc,board-style = <1>;
>       [..]
>    }
>
> Eg The board-style number comes from the EEPROM and if board-style !=
> 1 then the entire stanza is replaced with NOP.
>
> Jason

Jason,

Sounds pretty much like what we are doing.  I am using u-boot and my
current code looks like this:

        /*
         * Peripheral Config:
         *  remove nodes by alias path if EEPROM config tells us the
         *  peripheral is not loaded on the board.
         */
        if (!test_bit(EECONFIG_ETH0, info->config))
                fdt_del_node_and_alias(blob, "ethernet0");
        if (!test_bit(EECONFIG_ETH1, info->config))
                fdt_del_node_and_alias(blob, "ethernet1");
        if (!test_bit(EECONFIG_HDMI_OUT, info->config))
                fdt_del_node_and_alias(blob, "hdmi_out");
        if (!test_bit(EECONFIG_SATA, info->config))
                fdt_del_node_and_alias(blob, "ahci0");
        if (!test_bit(EECONFIG_PCIE, info->config))
                fdt_del_node_and_alias(blob, "pcie");
        if (!test_bit(EECONFIG_SSI0, info->config))
                fdt_del_node_and_alias(blob, "ssi0");
        if (!test_bit(EECONFIG_SSI1, info->config))
                fdt_del_node_and_alias(blob, "ssi1");
...

I've submitted my code to u-boot and have been asked if its more
appropriate to remove nodes as I'm doing above or to mark them as
'disabled'.  From what I can tell there really isn't a rule or
recommendation for this so I think I'll keep doing what I'm doing
above.

Thanks!

Tim

recommended action for bootloaders regarding modifying device-tree nodes

[Tim Harvey]

On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> Hi Tim,
>
> On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
>> My approach has been to define a per-baseboard device-tree in Linux
>> for a 'fully loaded' board, then remove nodes which the EEPROM claims
>> are not present in the bootloader before it passes the DTB to the
>> kernel.  I do this by defining aliases in the device-tree for the
>> peripherals that are 'optional' so that the bootloader itself does not
>> need to know the details about how the device is connected.
>
> This is more of a process question:  Is there any information captured
> in your EEPROM that can't be represented in the dtb?  iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?
>
> You could have pre-configured dtsi fragments for each config option, and
> then dynamically create the board dts from the order.
>
> I only ask because it would solve the problem below.  However, there's a
> lot more to changing a manufacturing process than meets the eye. :)
>

our eeprom config section is only 40 bytes.  It contains a SKU string,
mac addrs, and some bitwise fields for the various optional components
that we can subload.

>> Is it more appropriate for the bootloader to 'remove' nodes for
>> devices that are not physically present or should I be setting their
>> status property to 'disabled' instead?  I'm not clear if either option
>> really has any pros or cons.
>
> That depends on how you have it structured.  Is it a valid dtb?
> Meaning, do you have four nodes all at the same register address?
> Perhaps you could provide an example dts?

yes its a valid dtb - it is just the superset of everything the
baseboard (ie schematic design) can support.

A good example is a custom SKU of a baseboard with ethernet subloaded.
 If the EEPROM says there is no ethernet mac or phy, I would want to
remove or disable the ethernet node from the devicetree.

Another example would be a node for 'gpio-pps' (GPIO based
pulse-per-second) support.  A baseboard design that has a GPS with its
PPS signal tied to a GPIO would define this in the device-tree, but if
the EEPROM says the GPS isn't loaded, I would want to remove or
disable the gps-pps node.

Tim

>
> thx,
>
> Jason.
>
>> Tim Harvey - Principal Software Engineer
>> Gateworks Corporation
>
> btw - one of my first embedded projects was on one of your boards. An
> ixp425 with 4 mini-pci slots.
>

recommended action for bootloaders regarding modifying device-tree nodes

[Jason Cooper]

On Thu, Jan 30, 2014 at 08:39:00PM -0800, Tim Harvey wrote:
> On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Hi Tim,
> >
> > On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
> >> My approach has been to define a per-baseboard device-tree in Linux
> >> for a 'fully loaded' board, then remove nodes which the EEPROM claims
> >> are not present in the bootloader before it passes the DTB to the
> >> kernel.  I do this by defining aliases in the device-tree for the
> >> peripherals that are 'optional' so that the bootloader itself does not
> >> need to know the details about how the device is connected.
> >
> > This is more of a process question:  Is there any information captured
> > in your EEPROM that can't be represented in the dtb?  iow, at the point
> > when you write the EEPROM, why not write the dtb to it as configured?
> >
> > You could have pre-configured dtsi fragments for each config option, and
> > then dynamically create the board dts from the order.
> >
> > I only ask because it would solve the problem below.  However, there's a
> > lot more to changing a manufacturing process than meets the eye. :)
> >
> 
> our eeprom config section is only 40 bytes.  It contains a SKU string,
> mac addrs, and some bitwise fields for the various optional components
> that we can subload.

Ok.

> >> Is it more appropriate for the bootloader to 'remove' nodes for
> >> devices that are not physically present or should I be setting their
> >> status property to 'disabled' instead?  I'm not clear if either option
> >> really has any pros or cons.
> >
> > That depends on how you have it structured.  Is it a valid dtb?
> > Meaning, do you have four nodes all at the same register address?
> > Perhaps you could provide an example dts?
> 
> yes its a valid dtb - it is just the superset of everything the
> baseboard (ie schematic design) can support.
> 
> A good example is a custom SKU of a baseboard with ethernet subloaded.
>  If the EEPROM says there is no ethernet mac or phy, I would want to
> remove or disable the ethernet node from the devicetree.
> 
> Another example would be a node for 'gpio-pps' (GPIO based
> pulse-per-second) support.  A baseboard design that has a GPS with its
> PPS signal tied to a GPIO would define this in the device-tree, but if
> the EEPROM says the GPS isn't loaded, I would want to remove or
> disable the gps-pps node.

I think JasonG's approach is the way to go (inserting nops).  But it's a
matter of preference as long as the output is a valid dtb.

on a side note:  Do you still have to tie your dtb to a version of the
kernel?

thx,

Jason.