[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

[Ben Warren]

Post by 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.

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?

Post by Kumar Gala
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

[Scott Wood]

Post by Ben Warren

Post by 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.

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

[Ben Warren]

Post by Ben Warren

Post by 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.

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

[Scott Wood]

Post by Ben Warren

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

[Ben Warren]

Post by Scott Wood

Post by Ben Warren

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.

Post by Scott Wood
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

[Scott Wood]

Post by Ben Warren
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

[André Schwarz]

Post by Ben Warren

Post by Scott Wood

Post by Ben Warren

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.

Post by Ben Warren

Post by Scott Wood
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?

Post by Ben Warren
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

[Wolfgang Grandegger]

Post by André Schwarz

Post by Ben Warren

Post by Scott Wood

Post by Ben Warren

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.

Post by Ben Warren

Post by Scott Wood
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.

[André Schwarz]

Post by Wolfgang Grandegger

Post by André Schwarz

On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood

Post by Scott Wood

Post by Ben Warren

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.

Post by Scott Wood
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?

Post by Wolfgang Grandegger
Wolfgang.

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

[Jerry Van Baren]

Post by Scott Wood

Post by Ben Warren

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

Post by Scott Wood
-Scott

gvb %;-)

[Timur Tabi]

Post by Scott Wood
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.

[Grant Likely]

Post by 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.

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.

[Kumar Gala]

Post by Grant Likely

Post by 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.

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

[Scott Wood]

Post by Kumar Gala

Post by Grant Likely
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.

Post by Kumar Gala
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

[Haavard Skinnemoen]

Post by Kumar Gala
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

[Wolfgang Grandegger]

Post by 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.

Last year I brought up the topic twice:

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

Post by Kumar Gala
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.

[Kumar Gala]

Post by Wolfgang Grandegger

Post by 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.

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

Post by Kumar Gala
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

[Jon Loeliger]

Post by Kumar Gala

Post by Wolfgang Grandegger
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

[Robert Schwebel]

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

[Robert Schwebel]

Post by 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.

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

[Timur Tabi]

Post by 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.

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.

[Jon Smirl]

Post by Timur Tabi

Post by 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.

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.

[Wolfgang Denk]

Post by Jon Smirl

Post by Timur Tabi
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.

Post by Jon Smirl
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

[Jon Smirl]

Post by Wolfgang Denk

Post by Jon Smirl

Post by Timur Tabi
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.

Post by Wolfgang Denk

Post by Jon Smirl
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.

Post by Wolfgang Denk
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: [phone] Fax: [phone] Email: wd at denx.de
Unsichtbar macht sich die Dummheit, indem sie immer gr??ere Ausma?e
annimmt. -- Bertold Brecht: Der Tui-Roman

[Andrew Dyer]

Post by Jon Smirl
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.

[Jon Smirl]

Post by Wolfgang Denk

Post by Jon Smirl

Post by Timur Tabi
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.

[Timur Tabi]

Post by Jon Smirl
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.

[Wolfgang Denk]

Post by Jon Smirl

Post by Wolfgang Denk
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

[Timur Tabi]

Post by Wolfgang Denk
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.

[Grant Likely]

Post by Timur Tabi

Post by Wolfgang Denk
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.

[Timur Tabi]

Post by Grant Likely
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.

[Albert ARIBAUD]

Post by Timur Tabi

Post by Grant Likely
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,

[Jens Gehrlein]

Post by Grant Likely

Post by Timur Tabi

Post by Wolfgang Denk
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

[Wolfgang Denk]

Post by Timur Tabi

Post by Wolfgang Denk
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.

Post by Timur Tabi
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

[Timur Tabi]

Post by Wolfgang Denk
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.

[Wolfgang Denk]

Post by Timur Tabi

Post by Wolfgang Denk
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

[Timur Tabi]

Post by Wolfgang Denk

Post by Timur Tabi

Post by Wolfgang Denk
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.