Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Grant Likely schrieb: On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi [EMAIL PROTECTED] wrote: On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Timur Tabi a écrit : On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely [EMAIL PROTECTED] 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. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On 8/3/08, Wolfgang Denk [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Superior ability breeds superior ambition. -- Spock, Space Seed, stardate 3141.9 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Wolfgang Denk wrote: In message [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße annimmt. -- Bertold Brecht: Der Tui-Roman - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On 8/3/08, Wolfgang Denk [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße annimmt. -- Bertold Brecht: Der Tui-Roman -- Jon Smirl [EMAIL PROTECTED] - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi [EMAIL PROTECTED] wrote: On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] 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. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] A supercomputer is a machine that runs an endless loop in 2 seconds. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Scott Wood wrote: Ben Warren wrote: On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] 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 %;-) - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On 7/29/08, Timur Tabi [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 10:07 AM, Kumar Gala [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Kumar Gala [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Ben Warren schrieb: On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood [EMAIL PROTECTED] wrote: Ben Warren wrote: On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] 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=100url=/ ___ 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Wolfgang Grandegger schrieb: André Schwarz wrote: Ben Warren schrieb: On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood [EMAIL PROTECTED] wrote: Ben Warren wrote: On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 12:32 PM, Scott Wood [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:07 AM, Kumar Gala [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Ben Warren wrote: On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] wrote: Ben Warren wrote: On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] 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-) - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Ben Warren wrote: On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood [EMAIL PROTECTED] wrote: Ben Warren wrote: On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood [EMAIL PROTECTED] 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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
