[U-Boot-Users] using a flat device tree to drive u-boot config

[U-Boot-Users] using a flat device tree to drive u-boot config

[Kumar Gala]

One topic that come up during OLS in discussions and u-boot BOF was  
the idea of driving u-boot configuration from a device tree instead of  
from "config.h".  I was wondering if anyone has actually looked at  
doing this.

One question I have is how does (or should) u-boot identify where to  
find the device tree.  I think the idea would be that this "area"  
could be easily reflashed with a new blob to get a new configuration.

- k

[U-Boot-Users] using a flat device tree to drive u-boot config

[Ben Warren]

On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> One topic that come up during OLS in discussions and u-boot BOF was
> the idea of driving u-boot configuration from a device tree instead of
> from "config.h".  I was wondering if anyone has actually looked at
> doing this.
>
This sounds like an interesting idea, having a central repo for all
hardware information.  A big problem I see is that while device-tree
syntax may make sense to Linux kernel propellerheads, to the average
Joe it's mind-numbing.  Config files are ugly, but at least IMHO are
easy to figure out.  User-friendly editing tools would be a necessity.
 Maybe something already exists?

> One question I have is how does (or should) u-boot identify where to
> find the device tree.  I think the idea would be that this "area"
> could be easily reflashed with a new blob to get a new configuration.
>
This should be fun considering the plethora of architectures that
U-boot supports.

cheers,
Ben

[U-Boot-Users] using a flat device tree to drive u-boot config

[Scott Wood]

Ben Warren wrote:
> On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> One topic that come up during OLS in discussions and u-boot BOF was
>> the idea of driving u-boot configuration from a device tree instead of
>> from "config.h".  I was wondering if anyone has actually looked at
>> doing this.
>>
> This sounds like an interesting idea, having a central repo for all
> hardware information.  A big problem I see is that while device-tree
> syntax may make sense to Linux kernel propellerheads, to the average
> Joe it's mind-numbing.  Config files are ugly, but at least IMHO are
> easy to figure out.

I find a device tree much easier to figure out than a tangled mess of 
header files, #defines, and #ifdefs...

-Scott

[U-Boot-Users] using a flat device tree to drive u-boot config

[Ben Warren]

On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com> wrote:
> Ben Warren wrote:
>>
>> On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>>>
>>> One topic that come up during OLS in discussions and u-boot BOF was
>>> the idea of driving u-boot configuration from a device tree instead of
>>> from "config.h".  I was wondering if anyone has actually looked at
>>> doing this.
>>>
>> This sounds like an interesting idea, having a central repo for all
>> hardware information.  A big problem I see is that while device-tree
>> syntax may make sense to Linux kernel propellerheads, to the average
>> Joe it's mind-numbing.  Config files are ugly, but at least IMHO are
>> easy to figure out.
>
> I find a device tree much easier to figure out than a tangled mess of header
> files, #defines, and #ifdefs...
>
> -Scott
>

In many ways, yes.  But are you an average Joe or a Linux kernel propellerhead?

B-)

[U-Boot-Users] using a flat device tree to drive u-boot config

[Grant Likely]

On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote:
> One topic that come up during OLS in discussions and u-boot BOF was  
> the idea of driving u-boot configuration from a device tree instead of  
> from "config.h".  I was wondering if anyone has actually looked at  
> doing this.
> 
> One question I have is how does (or should) u-boot identify where to  
> find the device tree.  I think the idea would be that this "area"  
> could be easily reflashed with a new blob to get a new configuration.

In principle I like the idea of having configuration retrieved from the
device tree blob, but the idea of reflashing the blob in the context of
u-boot scares me.  In particular, if u-boot depends too much on the
presence of the blob, then it becomes a method of bricking a board if
users are able/expected to reflash the blob.

g.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Scott Wood]

Ben Warren wrote:
> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com> wrote:
>> I find a device tree much easier to figure out than a tangled mess of header
>> files, #defines, and #ifdefs...
> 
> In many ways, yes.  But are you an average Joe or a Linux kernel propellerhead?

Is u-boot work normally done by average Joes, and does the average Joe 
really find the preprocessor mess more intuitive than a "propellerhead"?

While we're at it, let's re-write u-boot in Visual Basic. :-)

-Scott

[U-Boot-Users] using a flat device tree to drive u-boot config

[Ben Warren]

On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood <scottwood@freescale.com> wrote:
> Ben Warren wrote:
>>
>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com>
>> wrote:
>>>
>>> I find a device tree much easier to figure out than a tangled mess of
>>> header
>>> files, #defines, and #ifdefs...
>>
>> In many ways, yes.  But are you an average Joe or a Linux kernel
>> propellerhead?
>
> Is u-boot work normally done by average Joes, and does the average Joe
> really find the preprocessor mess more intuitive than a "propellerhead"?
>
You know what I mean.  Some people like yourself do this for a living,
and are involved day-to-day in its specification.  Of course it's
intuitive to you.  For most people, getting U-boot going is one stage
in the development process of software for an embedded device.  They
work on it for a few weeks or months, then on something completely
different.  A few months or years later, they come back to it.
> While we're at it, let's re-write u-boot in Visual Basic. :-)
Uh, yeah.  I like the idea of a central repo for hardware info, and
the device tree concept is good.  My point is that the syntax, while
concise and exact, can be intimidating.  Just look at the amount of
traffic on the mailing lists of people that don't understand what all
the fields mean when specifying IRQs etc.  Anything we can do to make
it less so for noobies is a good thing for everybody.

cheers,
Ben

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Grandegger]

Kumar Gala wrote:
> One topic that come up during OLS in discussions and u-boot BOF was  
> the idea of driving u-boot configuration from a device tree instead of  
> from "config.h".  I was wondering if anyone has actually looked at  
> doing this.

Last year I brought up the topic twice:

http://sourceforge.net/mailarchive/message.php?msg_name=46F384E6.5030603%40grandegger.com

> One question I have is how does (or should) u-boot identify where to  
> find the device tree.  I think the idea would be that this "area"  
> could be easily reflashed with a new blob to get a new configuration.

Yep, it's even feasible to flash more than one blob and select one 
somehow in the early boot phase.

Our main interest in using FDT for U-Boot is to make it dynamically 
configurable having just one image for various variants of the 
hardware. Replacing config.h completely seems overkill to me (and will 
not even be possible).

Wolfgang.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Kumar Gala]

On Jul 28, 2008, at 12:40 PM, Grant Likely wrote:

> On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote:
>> One topic that come up during OLS in discussions and u-boot BOF was
>> the idea of driving u-boot configuration from a device tree instead  
>> of
>> from "config.h".  I was wondering if anyone has actually looked at
>> doing this.
>>
>> One question I have is how does (or should) u-boot identify where to
>> find the device tree.  I think the idea would be that this "area"
>> could be easily reflashed with a new blob to get a new configuration.
>
> In principle I like the idea of having configuration retrieved from  
> the
> device tree blob, but the idea of reflashing the blob in the context  
> of
> u-boot scares me.  In particular, if u-boot depends too much on the
> presence of the blob, then it becomes a method of bricking a board if
> users are able/expected to reflash the blob.

I dont see reflashing the blob as any different than reflashing u-boot  
itself w/respect to bricking a board.

But I agree, in general I would hope u-boot would be able to still  
boot w/o the device tree information (might be crippled, but you could  
recover).

- k

[U-Boot-Users] using a flat device tree to drive u-boot config

[Kumar Gala]

On Jul 28, 2008, at 1:13 PM, Wolfgang Grandegger wrote:

> Kumar Gala wrote:
>> One topic that come up during OLS in discussions and u-boot BOF  
>> was  the idea of driving u-boot configuration from a device tree  
>> instead of  from "config.h".  I was wondering if anyone has  
>> actually looked at  doing this.
>
> Last year I brought up the topic twice:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=46F384E6.5030603%40grandegger.com
>
>> One question I have is how does (or should) u-boot identify where  
>> to  find the device tree.  I think the idea would be that this  
>> "area"  could be easily reflashed with a new blob to get a new  
>> configuration.
>
> Yep, it's even feasible to flash more than one blob and select one  
> somehow in the early boot phase.
>
> Our main interest in using FDT for U-Boot is to make it dynamically  
> configurable having just one image for various variants of the  
> hardware. Replacing config.h completely seems overkill to me (and  
> will not even be possible).

Agreed.  I'm not suggesting replacing config.h, but removing bits and  
pieces of it.

- k

[U-Boot-Users] using a flat device tree to drive u-boot config

[Scott Wood]

Ben Warren wrote:
> Uh, yeah.  I like the idea of a central repo for hardware info, and
> the device tree concept is good.  My point is that the syntax, while
> concise and exact, can be intimidating.  Just look at the amount of
> traffic on the mailing lists of people that don't understand what all
> the fields mean when specifying IRQs etc.  Anything we can do to make
> it less so for noobies is a good thing for everybody.

Sure, no argument there -- enhancing the dts syntax with symbolic 
constants, computational expressions, and macros should make things like 
interrupt specifiers and maps a lot clearer.

-Scott

[U-Boot-Users] using a flat device tree to drive u-boot config

[Scott Wood]

Kumar Gala wrote:
> On Jul 28, 2008, at 12:40 PM, Grant Likely wrote:
>> In principle I like the idea of having configuration retrieved from
>>  the device tree blob, but the idea of reflashing the blob in the
>> context of u-boot scares me.  In particular, if u-boot depends too
>> much on the presence of the blob, then it becomes a method of
>> bricking a board if users are able/expected to reflash the blob.
> 
> I dont see reflashing the blob as any different than reflashing
> u-boot itself w/respect to bricking a board.

But currently it *is* different, so user expectations might need adjusting.

> But I agree, in general I would hope u-boot would be able to still 
> boot w/o the device tree information (might be crippled, but you
> could recover).

That'd mean that we'd still have to have serial, memory controller (at 
least to a functional level, not necessarily with performance settings), 
i2c (if used for memory init), ethernet (unless you accept needing to 
use serial to load a new image), etc. described in config.h.  It's not 
too unreasonable, especially during an interim period where people get 
used to the device tree being an integral part of u-boot, but it does 
limit the scope of what we use the tree for.

-Scott

[U-Boot-Users] using a flat device tree to drive u-boot config

[Haavard Skinnemoen]

Kumar Gala <galak@kernel.crashing.org> wrote:
> But I agree, in general I would hope u-boot would be able to still  
> boot w/o the device tree information (might be crippled, but you could  
> recover).

How about keeping a "fail-safe" blob around somewhere?

Haavard

[U-Boot-Users] using a flat device tree to drive u-boot config

[André Schwarz]

Ben Warren schrieb:
> On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood <scottwood@freescale.com> wrote:
>> Ben Warren wrote:
>>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com>
>>> wrote:
>>>> I find a device tree much easier to figure out than a tangled mess of
>>>> header
>>>> files, #defines, and #ifdefs...
>>> In many ways, yes.  But are you an average Joe or a Linux kernel
>>> propellerhead?
>> Is u-boot work normally done by average Joes, and does the average Joe
>> really find the preprocessor mess more intuitive than a "propellerhead"?
>>
> You know what I mean.  Some people like yourself do this for a living,
> and are involved day-to-day in its specification.  Of course it's
> intuitive to you.  For most people, getting U-boot going is one stage
> in the development process of software for an embedded device.  They
> work on it for a few weeks or months, then on something completely
> different.  A few months or years later, they come back to it.

You're absolutely right - just have a look at the vast lists of 
maintainers/contributors ... they are "average Joes" like myself. 
Realizing 2-3 projects each year should be possible without having to 
re-learn from scratch.

>> While we're at it, let's re-write u-boot in Visual Basic. :-)
> Uh, yeah.  I like the idea of a central repo for hardware info, and
> the device tree concept is good.  My point is that the syntax, while
> concise and exact, can be intimidating.  Just look at the amount of
> traffic on the mailing lists of people that don't understand what all
> the fields mean when specifying IRQs etc.  Anything we can do to make
> it less so for noobies is a good thing for everybody.
> 

Please keep in mind that WDenk is always watching if code is slowing 
things down or increasing size significantly. Improving things is very 
good - but not at the cost of size and/or speed. Configuring a board 
using a dtb usually needs far more code being present than needed.
After all it's a bootloader and not another pseudo OS.

But don't get me wrong ! The device tree is a very nice and usefuly 
thing ... for an OS.

regards,
Andr?

> cheers,
> Ben
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Grandegger]

Andr? Schwarz wrote:
> Ben Warren schrieb:
>> On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood <scottwood@freescale.com> wrote:
>>> Ben Warren wrote:
>>>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com>
>>>> wrote:
>>>>> I find a device tree much easier to figure out than a tangled mess of
>>>>> header
>>>>> files, #defines, and #ifdefs...
>>>> In many ways, yes.  But are you an average Joe or a Linux kernel
>>>> propellerhead?
>>> Is u-boot work normally done by average Joes, and does the average Joe
>>> really find the preprocessor mess more intuitive than a "propellerhead"?
>>>
>> You know what I mean.  Some people like yourself do this for a living,
>> and are involved day-to-day in its specification.  Of course it's
>> intuitive to you.  For most people, getting U-boot going is one stage
>> in the development process of software for an embedded device.  They
>> work on it for a few weeks or months, then on something completely
>> different.  A few months or years later, they come back to it.
> 
> You're absolutely right - just have a look at the vast lists of 
> maintainers/contributors ... they are "average Joes" like myself. 
> Realizing 2-3 projects each year should be possible without having to 
> re-learn from scratch.
> 
>>> While we're at it, let's re-write u-boot in Visual Basic. :-)
>> Uh, yeah.  I like the idea of a central repo for hardware info, and
>> the device tree concept is good.  My point is that the syntax, while
>> concise and exact, can be intimidating.  Just look at the amount of
>> traffic on the mailing lists of people that don't understand what all
>> the fields mean when specifying IRQs etc.  Anything we can do to make
>> it less so for noobies is a good thing for everybody.
>>
> 
> Please keep in mind that WDenk is always watching if code is slowing 
> things down or increasing size significantly. Improving things is very 
> good - but not at the cost of size and/or speed. Configuring a board 
> using a dtb usually needs far more code being present than needed.
> After all it's a bootloader and not another pseudo OS.
> 
> But don't get me wrong ! The device tree is a very nice and usefuly 
> thing ... for an OS.

There are customer request for a dynamically configurable U-Boot and the 
FDT is the right tool to provide the functionality. It has its price but 
U-Boot using a FDT blob for booting would also save some fixup code 
(required to boot Linux) and furthermore it would resolves some 
dependencies between hardcoded U-Boot and FDT defined addresses and ranges.

Wolfgang.

[U-Boot-Users] using a flat device tree to drive u-boot config

[André Schwarz]

Wolfgang Grandegger schrieb:
> Andr? Schwarz wrote:
>> Ben Warren schrieb:
>>> On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood 
>>> <scottwood@freescale.com> wrote:
>>>> Ben Warren wrote:
>>>>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com>
>>>>> wrote:
>>>>>> I find a device tree much easier to figure out than a tangled mess of
>>>>>> header
>>>>>> files, #defines, and #ifdefs...
>>>>> In many ways, yes.  But are you an average Joe or a Linux kernel
>>>>> propellerhead?
>>>> Is u-boot work normally done by average Joes, and does the average Joe
>>>> really find the preprocessor mess more intuitive than a 
>>>> "propellerhead"?
>>>>
>>> You know what I mean.  Some people like yourself do this for a living,
>>> and are involved day-to-day in its specification.  Of course it's
>>> intuitive to you.  For most people, getting U-boot going is one stage
>>> in the development process of software for an embedded device.  They
>>> work on it for a few weeks or months, then on something completely
>>> different.  A few months or years later, they come back to it.
>>
>> You're absolutely right - just have a look at the vast lists of 
>> maintainers/contributors ... they are "average Joes" like myself. 
>> Realizing 2-3 projects each year should be possible without having to 
>> re-learn from scratch.
>>
>>>> While we're at it, let's re-write u-boot in Visual Basic. :-)
>>> Uh, yeah.  I like the idea of a central repo for hardware info, and
>>> the device tree concept is good.  My point is that the syntax, while
>>> concise and exact, can be intimidating.  Just look at the amount of
>>> traffic on the mailing lists of people that don't understand what all
>>> the fields mean when specifying IRQs etc.  Anything we can do to make
>>> it less so for noobies is a good thing for everybody.
>>>
>>
>> Please keep in mind that WDenk is always watching if code is slowing 
>> things down or increasing size significantly. Improving things is very 
>> good - but not at the cost of size and/or speed. Configuring a board 
>> using a dtb usually needs far more code being present than needed.
>> After all it's a bootloader and not another pseudo OS.
>>
>> But don't get me wrong ! The device tree is a very nice and usefuly 
>> thing ... for an OS.
> 
> There are customer request for a dynamically configurable U-Boot and the 
> FDT is the right tool to provide the functionality. It has its price but 
> U-Boot using a FDT blob for booting would also save some fixup code 
> (required to boot Linux) and furthermore it would resolves some 
> dependencies between hardcoded U-Boot and FDT defined addresses and ranges.
> 

yes of course ... if you're thinking about paying customers.

What I can _definitely_ say is that we had to change flash layout twice 
on *existing* products simply because bootloader and kernel are 
constantly growing. It's nearly impossible to keep it small ... even 
with same core functionality.

Only way out would be to freeze versions. That's what lots of companies 
are doing ... and this is why so many out-of-tree branches exist. But 
that's another topic ;-)

regards,
Andr?

> Wolfgang.


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jon Loeliger]

Kumar Gala wrote:
>> Our main interest in using FDT for U-Boot is to make it dynamically  
>> configurable having just one image for various variants of the  
>> hardware. Replacing config.h completely seems overkill to me (and  
>> will not even be possible).
> 
> Agreed.  I'm not suggesting replacing config.h, but removing bits and  
> pieces of it.
> 
> - k

I think we should first spend more serious effort towards
installing Konfig structure and building into the config mix.

jdl

[U-Boot-Users] using a flat device tree to drive u-boot config

[Robert Schwebel]

On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote:
> One topic that come up during OLS in discussions and u-boot BOF was
> the idea of driving u-boot configuration from a device tree instead of
> from "config.h".  I was wondering if anyone has actually looked at
> doing this.
>
> One question I have is how does (or should) u-boot identify where to
> find the device tree.  I think the idea would be that this "area"
> could be easily reflashed with a new blob to get a new configuration.

The idea is interesting; we have already thought about generating device
trees in u-boot-v2 from the driver model.

As u-boot-v2 has a module concept (think of it as in linux -> insmod
plus EXPORT_SYMBOL), it would even be possible to change the driver
model to device tree transformation by uploading a new module; this is
necessary, as upstream maintainers tend to break oftree semantics with
almost every kernel release - seems to be part of the design :-)

However, no time to investigate this further atm.

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] using a flat device tree to drive u-boot config

[Robert Schwebel]

On Tue, Jul 29, 2008 at 09:30:21AM -0500, Jon Loeliger wrote:
> I think we should first spend more serious effort towards installing
> Konfig structure and building into the config mix.

Already there in u-boot-v2. Might be worth a deeper look.

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

On Mon, Jul 28, 2008 at 12:32 PM, Scott Wood <scottwood@freescale.com> wrote:


> I find a device tree much easier to figure out than a tangled mess of
> header files, #defines, and #ifdefs...

Especially since the various config files

1) often define the CONFIG_ and CFG_ options is different order
2) are usually not designed to be flexible.  That is, if you undefine
a certain option, instead of handling it gracefully, U-Boot will just
break.

The device trees are heirarchal, organized, and well defined.  I would
not apply those attributes to the config files.

Just the fact that we have CONFIG_ and CFG_ makes it too confusing.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

On Mon, Jul 28, 2008 at 10:07 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> One topic that come up during OLS in discussions and u-boot BOF was
> the idea of driving u-boot configuration from a device tree instead of
> from "config.h".  I was wondering if anyone has actually looked at
> doing this.

What about creating a tool that parses a device tree and creates (or
updates) the board header file?  This will retain compatibility with
other platforms, clean up the existing header files (they won't need
to contain as much information), and reduce the amount of changes to
U-Boot itself.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jerry Van Baren]

Scott Wood wrote:
> Ben Warren wrote:
>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com> wrote:
>>> I find a device tree much easier to figure out than a tangled mess of header
>>> files, #defines, and #ifdefs...
>> In many ways, yes.  But are you an average Joe or a Linux kernel propellerhead?
> 
> Is u-boot work normally done by average Joes, and does the average Joe 
> really find the preprocessor mess more intuitive than a "propellerhead"?
> 
> While we're at it, let's re-write u-boot in Visual Basic. :-)

NO, No, no!  In FORTH. :-P

> -Scott

gvb %;-)

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jon Smirl]

On 7/29/08, Timur Tabi <timur@freescale.com> wrote:
> On Mon, Jul 28, 2008 at 10:07 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>  > One topic that come up during OLS in discussions and u-boot BOF was
>  > the idea of driving u-boot configuration from a device tree instead of
>  > from "config.h".  I was wondering if anyone has actually looked at
>  > doing this.
>
>
> What about creating a tool that parses a device tree and creates (or
>  updates) the board header file?  This will retain compatibility with
>  other platforms, clean up the existing header files (they won't need
>  to contain as much information), and reduce the amount of changes to
>  U-Boot itself.

That's a good idea. I have used variation on this concept in the past
and they have worked out well.

A perfect tool would take a fully populated DTS file and use it to
dynamically generate all of the needed header files to build uboot.
More info would need to be added to the DTS file like DRAM timings,
etc. But a DTS file is good place to track all of that info. The
generated uboot image could contain a copy of the DTB and feed it to
Linux. Allow the user to override the embedded DTB if necessary.

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Denk]

In message <9e4733910808021858i766307b1q45b5bace59996d03@mail.gmail.com> you wrote:
>
> > What about creating a tool that parses a device tree and creates (or
> >  updates) the board header file?  This will retain compatibility with
> >  other platforms, clean up the existing header files (they won't need
> >  to contain as much information), and reduce the amount of changes to
> >  U-Boot itself.
> 
> That's a good idea. I have used variation on this concept in the past
> and they have worked out well.

A much more powerful concept is to have U-Boot read and interpret the
DT dynamically - only then can you use the same U-Boot  binary  image
on  different board configurations, which is an important feature for
many board vendors.

> A perfect tool would take a fully populated DTS file and use it to
> dynamically generate all of the needed header files to build uboot.
> More info would need to be added to the DTS file like DRAM timings,
> etc. But a DTS file is good place to track all of that info. The
> generated uboot image could contain a copy of the DTB and feed it to
> Linux. Allow the user to override the embedded DTB if necessary.

No, no, no. The DTB *must not* be included with the U-Boot image.  It
shall  always  be  kept  separate  so we canupdate it independently -
otherwise you lose a lot of advantages.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Unsichtbar macht sich die Dummheit, indem sie immer  gr??ere  Ausma?e
annimmt.                             -- Bertold Brecht: Der Tui-Roman

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jon Smirl]

On 8/3/08, Wolfgang Denk <wd@denx.de> wrote:
> In message <9e4733910808021858i766307b1q45b5bace59996d03@mail.gmail.com> you wrote:
>  >
>  > > What about creating a tool that parses a device tree and creates (or
>  > >  updates) the board header file?  This will retain compatibility with
>  > >  other platforms, clean up the existing header files (they won't need
>  > >  to contain as much information), and reduce the amount of changes to
>  > >  U-Boot itself.
>  >
>  > That's a good idea. I have used variation on this concept in the past
>  > and they have worked out well.
>
>
> A much more powerful concept is to have U-Boot read and interpret the
>  DT dynamically - only then can you use the same U-Boot  binary  image
>  on  different board configurations, which is an important feature for
>  many board vendors.

I don't disagree with this but it is a lot more work.

>
>  > A perfect tool would take a fully populated DTS file and use it to
>  > dynamically generate all of the needed header files to build uboot.
>  > More info would need to be added to the DTS file like DRAM timings,
>  > etc. But a DTS file is good place to track all of that info. The
>  > generated uboot image could contain a copy of the DTB and feed it to
>  > Linux. Allow the user to override the embedded DTB if necessary.
>
>
> No, no, no. The DTB *must not* be included with the U-Boot image.  It
>  shall  always  be  kept  separate  so we canupdate it independently -
>  otherwise you lose a lot of advantages.

A DTB is only about 8K. I was thinking that a user supplied one would
override the one contained inside uboot.

>
>  Best regards,
>
>  Wolfgang Denk
>
>
>  --
>  DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>  HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>  Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>  Unsichtbar macht sich die Dummheit, indem sie immer  gr??ere  Ausma?e
>  annimmt.                             -- Bertold Brecht: Der Tui-Roman
>


-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Denk]

In message <9e4733910808030557t269eb1fye375d66f8bb7f200@mail.gmail.com> you wrote:
>
> > No, no, no. The DTB *must not* be included with the U-Boot image.  It
> >  shall  always  be  kept  separate  so we canupdate it independently -
> >  otherwise you lose a lot of advantages.
> 
> A DTB is only about 8K. I was thinking that a user supplied one would
> override the one contained inside uboot.

Then you have to take special care  that  the  DTB  is  flash  sector
aligned  and sufficiently padded - this extra effort and introduces a
new, avoidable single point of failure. If the  DTB  can  be  at  any
flash location, you can for example have a fall-back version which is
used  to bring up U-Boot in a minimal configuration for recovery mode
if the new DTB fails to work.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Space is big. You just won't believe how vastly, hugely, mind-
bogglingly big it is. I mean, you may think it's a long way down the
road to the drug store, but that's just peanuts to space.
                              -- The Hitchhiker's Guide to the Galaxy

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <wd@denx.de> wrote:

> If the  DTB  can  be  at  any
> flash location, you can for example have a fall-back version which is
> used  to bring up U-Boot in a minimal configuration for recovery mode
> if the new DTB fails to work.

I think that a "recovery DTB" would have to be part of U-Boot itself
to be effective.  If the normal DTB is not available, then it's likely
the backup one would also be unavailable.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Grant Likely]

On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi <timur@freescale.com> wrote:
> On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <wd@denx.de> wrote:
>
>> If the  DTB  can  be  at  any
>> flash location, you can for example have a fall-back version which is
>> used  to bring up U-Boot in a minimal configuration for recovery mode
>> if the new DTB fails to work.
>
> I think that a "recovery DTB" would have to be part of U-Boot itself
> to be effective.  If the normal DTB is not available, then it's likely
> the backup one would also be unavailable.

Better to just not depend on the DTB at all for basic operation.  ie.
don't brick the board if the DTB is unavailable.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Denk]

In message <ed82fe3e0808031049t1440ac74ga6153f349c85be5e@mail.gmail.com> you wrote:
> 
> > If the  DTB  can  be  at  any
> > flash location, you can for example have a fall-back version which is
> > used  to bring up U-Boot in a minimal configuration for recovery mode
> > if the new DTB fails to work.
> 
> I think that a "recovery DTB" would have to be part of U-Boot itself

Why? One address is as good as any other.

> to be effective.  If the normal DTB is not available, then it's likely
> the backup one would also be unavailable.

Then this makes no differnce if it's embedded in the U=Boot image  or
prepended or appended or at any other location in memory.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A supercomputer is a machine that runs an endless loop in 2 seconds.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely <grant.likely@secretlab.ca> wrote:

> Better to just not depend on the DTB at all for basic operation.  ie.
> don't brick the board if the DTB is unavailable.

Is it even possible to have a "recovery mode U-Boot" that is not tied
to the specific board it's built for?  Either U-Boot is reliable, or
it's generic (i.e. uses the DTB for configuration).  I just don't see
how it can be both.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Andrew Dyer]

On Sun, Aug 3, 2008 at 7:57 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> A DTB is only about 8K. I was thinking that a user supplied one would
> override the one contained inside uboot.

How big is the code that parses the FDT right now?  I mostly deal with
MIPS and ARM, and haven't used this stuff before.


-- 
Hardware, n.:
 The parts of a computer system that can be kicked.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jens Gehrlein]

Grant Likely schrieb:
> On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi <timur@freescale.com> wrote:
>> On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <wd@denx.de> wrote:
>>
>>> If the  DTB  can  be  at  any
>>> flash location, you can for example have a fall-back version which is
>>> used  to bring up U-Boot in a minimal configuration for recovery mode
>>> if the new DTB fails to work.
>> I think that a "recovery DTB" would have to be part of U-Boot itself
>> to be effective.  If the normal DTB is not available, then it's likely
>> the backup one would also be unavailable.
> 
> Better to just not depend on the DTB at all for basic operation.  ie.
> don't brick the board if the DTB is unavailable.

If the DTB is not available or invalid, the settings in the config 
header file could be used as default values. At least, U-Boot should 
start with a limited function volume to be able to load valid DTB.

It's also possible to have no DTB at all for platforms not (or not yet) 
supporting the flat device tree.

Kind regards,
Jens

[U-Boot-Users] using a flat device tree to drive u-boot config

[Albert ARIBAUD]

Timur Tabi a ?crit :
> On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> 
>> Better to just not depend on the DTB at all for basic operation.  ie.
>> don't brick the board if the DTB is unavailable.
> 
> Is it even possible to have a "recovery mode U-Boot" that is not tied
> to the specific board it's built for?  Either U-Boot is reliable, or
> it's generic (i.e. uses the DTB for configuration).  I just don't see
> how it can be both.

A recovery U-boot would only need to be generic enough to provide a console 
and means to upload and run code through that console. If that works well, 
then you have a reliable and (as) generic (as it gets) recovery u-boot 
(granted, it would still depend on the console working out-of-the-boot 
without any HW tricks like enabling voltage converters and such).

Amicalement,
-- 
Albert.

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

Wolfgang Denk wrote:

> Why? One address is as good as any other.

I think statistically you'll find that that isn't true.  A built-in DTB is more
likely to be present on the flash than an external DTB would be.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Jon Smirl]

On 8/3/08, Wolfgang Denk <wd@denx.de> wrote:
> In message <9e4733910808021858i766307b1q45b5bace59996d03@mail.gmail.com> you wrote:
>  >
>  > > What about creating a tool that parses a device tree and creates (or
>  > >  updates) the board header file?  This will retain compatibility with
>  > >  other platforms, clean up the existing header files (they won't need
>  > >  to contain as much information), and reduce the amount of changes to
>  > >  U-Boot itself.
>  >
>  > That's a good idea. I have used variation on this concept in the past
>  > and they have worked out well.
>
>
> A much more powerful concept is to have U-Boot read and interpret the
>  DT dynamically - only then can you use the same U-Boot  binary  image
>  on  different board configurations, which is an important feature for
>  many board vendors.

A combination of the two approaches may be best.

During the build process feed uboot all of the DTS files you want it
to be able to handle. That will let it figure out the right config
flags to set when building the image.  This will allow uboot to
compile with the minimal set of needed features and make it much
easier to get started with. Of course current DTS file will need some
more info added like DRAM timings.

Sybase uses this process for cell phone databases. You start with a
full feature db engine and develop your code against it. When your
code is finished you run all of the commands and the engine tracks
which SQL features you used. It then generates a new, smaller db
engine that only supports those features.

BTW, how do know which DT to dynamically interpret? If you are
installing a universal uboot you still are going to have to install a
different DT in each model. If you're installing a different DT you
might as well install a different uboot. I guess the intention is to
have three pieces - uboot, DT, kernel.

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

Jon Smirl wrote:

> BTW, how do know which DT to dynamically interpret? If you are
> installing a universal uboot you still are going to have to install a
> different DT in each model. If you're installing a different DT you
> might as well install a different uboot. 

That's what I was thinking, too.

Maybe on some boards, the DTB can be stored on some other type of memory that is
easier to update during the manufacturing process.  In that case, I can see how
some vendors would like on u-boot.bin for all boards.

Other than that, I don't see the point of having a generic u-boot.bin.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Denk]

In message <48971322.7000305@freescale.com> you wrote:
> 
> > Why? One address is as good as any other.
> 
> I think statistically you'll find that that isn't true.  A built-in DTB is more
> likely to be present on the flash than an external DTB would be.

Please present the data your statistics is based on.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Superior ability breeds superior ambition.
	-- Spock, "Space Seed", stardate 3141.9

[U-Boot-Users] using a flat device tree to drive u-boot config

[Timur Tabi]

Wolfgang Denk wrote:
> In message <48971322.7000305@freescale.com> you wrote:
>>> Why? One address is as good as any other.
>> I think statistically you'll find that that isn't true.  A built-in DTB is more
>> likely to be present on the flash than an external DTB would be.
> 
> Please present the data your statistics is based on.

Give me a break, Wolfgang.  I don't have any data, but what I'm saying makes
sense.  A system is more likely to have one binary blob present than two bloba.
 That has to be obvious.

-- 
Timur Tabi
Linux kernel developer at Freescale