[U-Boot-Users] using a flat device tree to drive u-boot config
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
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
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
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-)
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
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
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
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@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
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.
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
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 %;-)
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.
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.
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
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
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
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%40g...
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.
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%40g...
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
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
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
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
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.
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.
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
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@denx.de Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße annimmt. -- Bertold Brecht: Der Tui-Roman
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
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.
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.
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 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,
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
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
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
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.
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.
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 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.
participants (16)
-
Albert ARIBAUD -
Andrew Dyer -
André Schwarz -
Ben Warren -
Grant Likely -
Haavard Skinnemoen -
Jens Gehrlein -
Jerry Van Baren -
Jon Loeliger -
Jon Smirl -
Kumar Gala -
Robert Schwebel -
Scott Wood -
Timur Tabi -
Wolfgang Denk -
Wolfgang Grandegger