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
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
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] why eeprom vs flash
On 2/14/08, David Hawkins [EMAIL PROTECTED] wrote: Jon Smirl wrote: I'm new to working on low level code like u-boot. Something I don't understand is why things like the Ethernet address are stored in eeprom instead of flash. Is this something to do with how boards are manufactured? From a high level perspective it doesn't seem to matter if eeprom or flash is used. I think you'll find varied implementations. For example, on the MPC8349EA-MDS-PB boards, the MAC addresses are stored in U-Boot environment variables and they're written on the CPU heatsink base. If you erase the Flash, then poof, gone are your MAC addresses. When you Flash a new version of U-Boot you need to set the IP addresses and save the environment to the Flash. I would imagine some designers prefer saving these type of parameters to an EEPROM, independent of the application (bootloader, kernel, filesystem, etc) flash. This would cut down on the support calls from customers who erase their flash and forget their MAC addresses (or can't see the MAC labels if the units are installed). How are the MAC addresses assigned? So if I order ten Ethernet chips from Digikey will they come with something from the manufacturer indicating which MAC addresses to use? Or do I need to register as a vendor and get my own block of addresses? So, as the designer, its up to you. But keep in mind that you want to make it hard for a customer to screw up, so a separate EEPROM could be a good choice. Cheers, Dave -- Jon Smirl [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Initially loading uboot into flash on MPC5200
On 2/11/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, On 11 Feb 2008 at 11:29, Andreas Schweigstill wrote: Hello! Wolfgang Denk schrieb: Don't try tricks; go and buy a BDI3000. In the long run, it will trun out to be the cheapest solution. I just heard from a customer that he bought a BDI2000 clone which is manufactured by an Austrian company and costs a fraction of the original one from Abatron. I don't know if this clone has restricted features and if there is also a BDI3000 clone available. maybe you are refering to PEEDI made by Ronetix? PEEDI doesn't support MPC5200 according to the web site. In case anyone is wondering, with a tiny amount of logic you can make the PCI socket into a local bus socket when the board first boots. Then put a flash chip onto a PCI form factor card that you programmed elsewhere. The MPC5200 will run the program from the PCI/local bus flash card which will get you bootstrapped. Macraigor USB wiggler supports MPC5200 for $250. But they want another $500 for the flash programming software. The BSDL file for the MPC5200 is on the Freescale site. If we have time we may play with OpenOCD/cheap JTAG and see if we can convince it to program our flash chip. If we can get that to work it will give us a $50 solution for a hobbyist to unbrick their device at home. I have such a device, and it is working really nice for debugging on BDM. Cost does vary depending on configuration, though. There is only one problem left with stand-alone flash programming with my specific combination (Freescale MCF5373L/Intel P30 Flash), but I hope we get this worked out, too. Ronetix support is quite responsive so far. Best regards, Wolfgang - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Jon Smirl [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Initially loading uboot into flash on MPC5200
I'm working on a MPC5200 based design, www.digispeaker.com. What low cost options are there for initially loading the flash if a BDI2000 is not in the budget? Ideally we'd like to find something cheap enough that a hobbyist could buy it if they bricked their board. Our hardware is not finalized so we can still change things to make programming the flash easier. I wish the MPC5200 had a way to load RAM from the serial port like most ARM chips. There is a trick using the PCI bus that can be used on the MPC5200 but we don't have a PCI socket. -- Jon Smirl [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
