Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Thursday, September 16, 2010 11:30 PM To: Premi, Sanjeev Cc: Kyungmin Park; Stefan Roese; u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thu, 16 Sep 2010 21:14:57 +0530 Premi, Sanjeev pr...@ti.com wrote: [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB NAND SPL typically needs to fit in just 4 KiB (sometimes even less). In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Those things are configurable. That doesn't mean we don't need makefile infrastructure to build the two (or sometimes three) separate images, or some special code for an extremely minimal image. [sp] Yes. When we need to be extremely small separate infra may be needed. But for rest, I feel we could/ should continue using the generic makefile infra - with more configuration options - that keeps maintenance low. I also feel that needs/requirements for the extremely small images will differ between the users. Maintaining compatibility will be a challenge for a common codebase. ~sanjeev -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Friday, September 17, 2010 12:02 AM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Kyungmin Park; Stefan Roese; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote: But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB the Blackfin one is in the range of 200-600 bytes. i dont care how configurable you make u-boot, it isnt getting to that. In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... yes, we should do this anyways. i have another use of u-boot where i wanted it down to the 30KiB range, and that required posting patches to make things more configurable. most have been merged already. [sp] I will rebase my work on latest and submit patches. ~sanjeev -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park Sent: Tuesday, September 14, 2010 7:48 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese s...@denx.de wrote: Hi Aneesh, On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That's definitely a good idea. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Best regards, Sanjeev Thank you, Kyungmin Park ... Comments welcome. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Thu, 16 Sep 2010 21:14:57 +0530 Premi, Sanjeev pr...@ti.com wrote: [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB NAND SPL typically needs to fit in just 4 KiB (sometimes even less). In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Those things are configurable. That doesn't mean we don't need makefile infrastructure to build the two (or sometimes three) separate images, or some special code for an extremely minimal image. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote: But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB the Blackfin one is in the range of 200-600 bytes. i dont care how configurable you make u-boot, it isnt getting to that. In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... yes, we should do this anyways. i have another use of u-boot where i wanted it down to the 30KiB range, and that required posting patches to make things more configurable. most have been merged already. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, 14 Sep 2010 18:17:47 +0200 Wolfgang Denk w...@denx.de wrote: Dear V, Aneesh, In message ff55437e1f14da4baeb721a458b6701706c5888...@dbde02.ent.ti.com you wrote: Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That would be greatly appreciated. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Fr now we can stick with the nand_spl name (even if it's becoming a bit misleading); I'd rather just change the name now -- misleading is bad whether there's one exception or several. if other use cases get added we can discuss to rename it. Someone just internally posted a patch adding i2c_spl, FWIW. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Wednesday 15 September 2010 18:36:02 Scott Wood wrote: This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Fr now we can stick with the nand_spl name (even if it's becoming a bit misleading); I'd rather just change the name now -- misleading is bad whether there's one exception or several. Yes, I would prefer this renaming right now as well. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Dear Scott Wood, In message 20100915113602.52666...@schlenkerla.am.freescale.net you wrote: Fr now we can stick with the nand_spl name (even if it's becoming a bit misleading); I'd rather just change the name now -- misleading is bad whether there's one exception or several. OK - suggest a new name, please? 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: w...@denx.de Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Wed, 15 Sep 2010 19:45:17 +0200 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20100915113602.52666...@schlenkerla.am.freescale.net you wrote: Fr now we can stick with the nand_spl name (even if it's becoming a bit misleading); I'd rather just change the name now -- misleading is bad whether there's one exception or several. OK - suggest a new name, please? Plain spl is fine with me, or perhaps something like bootstrap or preboot would be clearer. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Dear Scott Wood, In message 20100915130155.7e7b2...@schlenkerla.am.freescale.net you wrote: OK - suggest a new name, please? Plain spl is fine with me, or perhaps something like bootstrap or preboot would be clearer. spl is OK with me. The other two might cause discussions (all U-Boot is about how to bootstrap an OS, and what exactly is the boot that is preceeded by preboot?). 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: w...@denx.de More software projects have gone awry for lack of calendar time than for all other causes combined. - Fred Brooks, Jr., _The Mythical Man Month_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tuesday, September 14, 2010 01:22:10 Vipin Kumar wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. i dont think there is -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi Vipin, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 4:16 PM, Stefan Roese s...@denx.de wrote: Hi Vipin, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. Same method. OneNAND IPL (2KiB, 8KiB or 16KiB) combined with u-boot.bin and generate u-boot-onenand.bin OneNAND IPL (at SRAM) load the u-boot.bin to DRAM and jump to u-boot address. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. Yes, got it. The only point is that this is meant to boot from NAND, ONENAND devices(As the name suggests). Can there be a generic interface independent of a particular device. Offcourse I agree that execute in place would work for NOR devices and we wont need this kinda solution but still a generic solution for both types of devices is preferable Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi Vipin, On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote: Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. Yes, got it. The only point is that this is meant to boot from NAND, ONENAND devices(As the name suggests). Can there be a generic interface independent of a particular device. Offcourse I agree that execute in place would work for NOR devices and we wont need this kinda solution but still a generic solution for both types of devices is preferable Sure, a more generic approach would be better. But I suspect that this is not so easy to do. Those tight image-size restrictions of the IPL/SPL loaders will make such generalisation efforts quite difficult. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tuesday, September 14, 2010 08:40:55 Stefan Roese wrote: On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote: Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. Yes, got it. The only point is that this is meant to boot from NAND, ONENAND devices(As the name suggests). Can there be a generic interface independent of a particular device. Offcourse I agree that execute in place would work for NOR devices and we wont need this kinda solution but still a generic solution for both types of devices is preferable Sure, a more generic approach would be better. But I suspect that this is not so easy to do. Those tight image-size restrictions of the IPL/SPL loaders will make such generalisation efforts quite difficult. there should at least be a build system unification if the general source code isnt possible. all Blackfin builds now (LDRs) have a dedicated binary to initialize memory before any of u-boot is loaded. this is the initcode stuff in the blackfin cpu dir. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Vipin Kumar Sent: Tuesday, September 14, 2010 3:52 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi Aneesh, On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That's definitely a good idea. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board ... Comments welcome. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese s...@denx.de wrote: Hi Aneesh, On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That's definitely a good idea. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? Thank you, Kyungmin Park ... Comments welcome. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh ane...@ti.com wrote: Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Vipin Kumar Sent: Tuesday, September 14, 2010 3:52 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Hi, On TI's OMAP based devices there is a minimal bootloader called as xloader based on U-Boot. It which takes care of initializing the RAM and loads the U-Boot binary built from the denx tree. The directory structure, ONENAND_spl does seem to based on xloader from the info by the author in the source code. Although it is possible to achieve significant size reduction by making minimal changes to the U-Boot code, problems come in when we have to selectively include some features and not make use of the whole framework due to the size limitation of the initial program loader. Since the directory structure, the build system and flow of xloader is similar to U-Boot.. how about leveraging this for making the spl generic? If linking against the various drivers directly instead of using the whole framework is fine then we could have a common source for both the initial loader and full fledged U-Boot. -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi Kyungmin, On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote: This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. mmc_ipl? This is not in mainline yet. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? Correct. That's how IBM/AMCC called this code first loaded from NAND in their documentation. IPL (Initial Program Loader) was used for the ROM code inside the SoC, loading this SPL code from NAND. Please note that I don't have a strong preference here. We could also call this first loader stage in the U-Boot source IPL. But we should move to one name and stop mixing these names. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 11:22 PM, Vaibhav Bedia vaibhav.be...@gmail.com wrote: On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh ane...@ti.com wrote: Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Vipin Kumar Sent: Tuesday, September 14, 2010 3:52 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Hi, On TI's OMAP based devices there is a minimal bootloader called as xloader based on U-Boot. It which takes care of initializing the RAM and loads the U-Boot binary built from the denx tree. The directory structure, ONENAND_spl does seem to based on xloader from the info by the author in the source code. Right, First OneNAND IPL based on x-loader and used for OMAP2 board. and I integrate it into u-boot as onenand_ipl. To reduce the code size, I introduced the CONFIG_ONENAND_IPL and someone change it to CONFIG_PRELOADER for use both NAND and OneNAND. Although it is possible to achieve significant size reduction by making minimal changes to the U-Boot code, problems come in when we have to selectively include some features and not make use of the whole framework due to the size limitation of the initial program loader. OneNAND IPL ues the symlink method and compile the code only when CONFIG_PRELOADER is defined. you can find it at arm/*/start.S. As I remover arm1176 and armv7 support it. Thank you, Kyungmin Park Since the directory structure, the build system and flow of xloader is similar to U-Boot.. how about leveraging this for making the spl generic? If linking against the various drivers directly instead of using the whole framework is fine then we could have a common source for both the initial loader and full fledged U-Boot. -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 11:26 PM, Stefan Roese s...@denx.de wrote: Hi Kyungmin, On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote: This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. mmc_ipl? This is not in mainline yet. Right, I will tell the person to posting it. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? Correct. That's how IBM/AMCC called this code first loaded from NAND in their documentation. IPL (Initial Program Loader) was used for the ROM code inside the SoC, loading this SPL code from NAND. Please note that I don't have a strong preference here. We could also call this first loader stage in the U-Boot source IPL. But we should move to one name and stop mixing these names. Okay first explain our case. BootROM code - Initial Program Loader (runs on OneNAND 1KiB or internal RAM) - u-boot (secondary bootloader). IPL configure the DRAM and loads the secondary bootloader, u-boot and jump it. It's another story but I introduce the fastboot between IPL and u-boot. So if normal boot, fastboot load the kernel and jump it. if not, e.g., debug or usb download. then jump to u-boot and handle it. In this case I call it Second BootLoader (SBL). I also don't preference. just decide and use it. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tuesday, September 14, 2010 10:32:21 Kyungmin Park wrote: BootROM code - Initial Program Loader (runs on OneNAND 1KiB or internal RAM) - u-boot (secondary bootloader). IPL configure the DRAM and loads the secondary bootloader, u-boot and jump it. the IPL may or may not handle loading of u-boot. in the Blackfin case: BootROM - IPL (program memory/clocks) - return to BootROM which handles loading of and then jumping to u-boot. more in-depth documentation can be found here: http://docs.blackfin.uclinux.org/doku.php?id=bootloaders -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Dear V, Aneesh, In message ff55437e1f14da4baeb721a458b6701706c5888...@dbde02.ent.ti.com you wrote: Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That would be greatly appreciated. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Fr now we can stick with the nand_spl name (even if it's becoming a bit misleading); if other use cases get added we can discuss to rename it. Please no not create yet another such directory. I think we should concentrate such code in one location. 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: w...@denx.de A stone was placed at a ford in a river with the inscription: When this stone is covered it is dangerous to ford here. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Multiple binaries built through u-boot source
Hello, This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. Thanks in advance Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
