* [U-Boot] Multiple binaries built through u-boot source @ 2010-09-14 5:22 Vipin Kumar 2010-09-14 7:05 ` Mike Frysinger 2010-09-14 7:16 ` Stefan Roese 0 siblings, 2 replies; 26+ messages in thread From: Vipin Kumar @ 2010-09-14 5:22 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 5:22 [U-Boot] Multiple binaries built through u-boot source Vipin Kumar @ 2010-09-14 7:05 ` Mike Frysinger 2010-09-14 7:16 ` Stefan Roese 1 sibling, 0 replies; 26+ messages in thread From: Mike Frysinger @ 2010-09-14 7:05 UTC (permalink / raw) To: u-boot 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/7e7e57d4/attachment.pgp ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 5:22 [U-Boot] Multiple binaries built through u-boot source Vipin Kumar 2010-09-14 7:05 ` Mike Frysinger @ 2010-09-14 7:16 ` Stefan Roese 2010-09-14 8:11 ` Kyungmin Park 2010-09-14 10:21 ` Vipin Kumar 1 sibling, 2 replies; 26+ messages in thread From: Stefan Roese @ 2010-09-14 7:16 UTC (permalink / raw) To: u-boot 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: office at denx.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 7:16 ` Stefan Roese @ 2010-09-14 8:11 ` Kyungmin Park 2010-09-14 10:21 ` Vipin Kumar 1 sibling, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-09-14 8:11 UTC (permalink / raw) To: u-boot On Tue, Sep 14, 2010 at 4:16 PM, Stefan Roese <sr@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 7:16 ` Stefan Roese 2010-09-14 8:11 ` Kyungmin Park @ 2010-09-14 10:21 ` Vipin Kumar 2010-09-14 12:40 ` Stefan Roese 2010-09-14 13:33 ` V, Aneesh 1 sibling, 2 replies; 26+ messages in thread From: Vipin Kumar @ 2010-09-14 10:21 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 10:21 ` Vipin Kumar @ 2010-09-14 12:40 ` Stefan Roese 2010-09-14 13:02 ` Mike Frysinger 2010-09-14 13:33 ` V, Aneesh 1 sibling, 1 reply; 26+ messages in thread From: Stefan Roese @ 2010-09-14 12:40 UTC (permalink / raw) To: u-boot 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: office at denx.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 12:40 ` Stefan Roese @ 2010-09-14 13:02 ` Mike Frysinger 0 siblings, 0 replies; 26+ messages in thread From: Mike Frysinger @ 2010-09-14 13:02 UTC (permalink / raw) To: u-boot 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/a769ee6c/attachment.pgp ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 10:21 ` Vipin Kumar 2010-09-14 12:40 ` Stefan Roese @ 2010-09-14 13:33 ` V, Aneesh 2010-09-14 13:51 ` Stefan Roese ` (2 more replies) 1 sibling, 3 replies; 26+ messages in thread From: V, Aneesh @ 2010-09-14 13:33 UTC (permalink / raw) To: u-boot Hi, > -----Original Message----- > From: u-boot-bounces at lists.denx.de [mailto:u-boot- > bounces at lists.denx.de] On Behalf Of Vipin Kumar > Sent: Tuesday, September 14, 2010 3:52 PM > To: Stefan Roese > Cc: u-boot at 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 13:33 ` V, Aneesh @ 2010-09-14 13:51 ` Stefan Roese 2010-09-14 14:18 ` Kyungmin Park 2010-09-14 14:22 ` Vaibhav Bedia 2010-09-14 16:17 ` Wolfgang Denk 2 siblings, 1 reply; 26+ messages in thread From: Stefan Roese @ 2010-09-14 13:51 UTC (permalink / raw) To: u-boot 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: office at denx.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 13:51 ` Stefan Roese @ 2010-09-14 14:18 ` Kyungmin Park 2010-09-14 14:26 ` Stefan Roese 2010-09-16 15:44 ` Premi, Sanjeev 0 siblings, 2 replies; 26+ messages in thread From: Kyungmin Park @ 2010-09-14 14:18 UTC (permalink / raw) To: u-boot On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese <sr@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: office at denx.de > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 14:18 ` Kyungmin Park @ 2010-09-14 14:26 ` Stefan Roese 2010-09-14 14:32 ` Kyungmin Park 2010-09-16 15:44 ` Premi, Sanjeev 1 sibling, 1 reply; 26+ messages in thread From: Stefan Roese @ 2010-09-14 14:26 UTC (permalink / raw) To: u-boot 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: office at denx.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 14:26 ` Stefan Roese @ 2010-09-14 14:32 ` Kyungmin Park 2010-09-14 15:16 ` Mike Frysinger 0 siblings, 1 reply; 26+ messages in thread From: Kyungmin Park @ 2010-09-14 14:32 UTC (permalink / raw) To: u-boot On Tue, Sep 14, 2010 at 11:26 PM, Stefan Roese <sr@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 14:32 ` Kyungmin Park @ 2010-09-14 15:16 ` Mike Frysinger 0 siblings, 0 replies; 26+ messages in thread From: Mike Frysinger @ 2010-09-14 15:16 UTC (permalink / raw) To: u-boot 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/f0748b8b/attachment.pgp ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 14:18 ` Kyungmin Park 2010-09-14 14:26 ` Stefan Roese @ 2010-09-16 15:44 ` Premi, Sanjeev 2010-09-16 17:59 ` Scott Wood 2010-09-16 18:31 ` Mike Frysinger 1 sibling, 2 replies; 26+ messages in thread From: Premi, Sanjeev @ 2010-09-16 15:44 UTC (permalink / raw) To: u-boot > -----Original Message----- > From: u-boot-bounces at lists.denx.de > [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Kyungmin Park > Sent: Tuesday, September 14, 2010 7:48 PM > To: Stefan Roese > Cc: u-boot at 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 <sr@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: > office at denx.de > > _______________________________________________ > > U-Boot mailing list > > U-Boot at lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-16 15:44 ` Premi, Sanjeev @ 2010-09-16 17:59 ` Scott Wood 2010-09-17 9:12 ` Premi, Sanjeev 2010-09-16 18:31 ` Mike Frysinger 1 sibling, 1 reply; 26+ messages in thread From: Scott Wood @ 2010-09-16 17:59 UTC (permalink / raw) To: u-boot On Thu, 16 Sep 2010 21:14:57 +0530 "Premi, Sanjeev" <premi@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-16 17:59 ` Scott Wood @ 2010-09-17 9:12 ` Premi, Sanjeev 0 siblings, 0 replies; 26+ messages in thread From: Premi, Sanjeev @ 2010-09-17 9:12 UTC (permalink / raw) To: u-boot > -----Original Message----- > From: Scott Wood [mailto:scottwood at freescale.com] > Sent: Thursday, September 16, 2010 11:30 PM > To: Premi, Sanjeev > Cc: Kyungmin Park; Stefan Roese; u-boot at 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" <premi@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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-16 15:44 ` Premi, Sanjeev 2010-09-16 17:59 ` Scott Wood @ 2010-09-16 18:31 ` Mike Frysinger 2010-09-17 9:21 ` Premi, Sanjeev 1 sibling, 1 reply; 26+ messages in thread From: Mike Frysinger @ 2010-09-16 18:31 UTC (permalink / raw) To: u-boot 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100916/ae727bfa/attachment.pgp ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-16 18:31 ` Mike Frysinger @ 2010-09-17 9:21 ` Premi, Sanjeev 0 siblings, 0 replies; 26+ messages in thread From: Premi, Sanjeev @ 2010-09-17 9:21 UTC (permalink / raw) To: u-boot > -----Original Message----- > From: Mike Frysinger [mailto:vapier at gentoo.org] > Sent: Friday, September 17, 2010 12:02 AM > To: u-boot at 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 13:33 ` V, Aneesh 2010-09-14 13:51 ` Stefan Roese @ 2010-09-14 14:22 ` Vaibhav Bedia 2010-09-14 14:26 ` Kyungmin Park 2010-09-14 16:17 ` Wolfgang Denk 2 siblings, 1 reply; 26+ messages in thread From: Vaibhav Bedia @ 2010-09-14 14:22 UTC (permalink / raw) To: u-boot On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh <aneesh@ti.com> wrote: > Hi, > > > -----Original Message----- > > From: u-boot-bounces at lists.denx.de [mailto:u-boot- > > bounces at lists.denx.de] On Behalf Of Vipin Kumar > > Sent: Tuesday, September 14, 2010 3:52 PM > > To: Stefan Roese > > Cc: u-boot at 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 at 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 14:22 ` Vaibhav Bedia @ 2010-09-14 14:26 ` Kyungmin Park 0 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-09-14 14:26 UTC (permalink / raw) To: u-boot On Tue, Sep 14, 2010 at 11:22 PM, Vaibhav Bedia <vaibhav.bedia@gmail.com> wrote: > On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh <aneesh@ti.com> wrote: > >> Hi, >> >> > -----Original Message----- >> > From: u-boot-bounces at lists.denx.de [mailto:u-boot- >> > bounces at lists.denx.de] On Behalf Of Vipin Kumar >> > Sent: Tuesday, September 14, 2010 3:52 PM >> > To: Stefan Roese >> > Cc: u-boot at 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 at 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 13:33 ` V, Aneesh 2010-09-14 13:51 ` Stefan Roese 2010-09-14 14:22 ` Vaibhav Bedia @ 2010-09-14 16:17 ` Wolfgang Denk 2010-09-15 16:36 ` Scott Wood 2 siblings, 1 reply; 26+ messages in thread From: Wolfgang Denk @ 2010-09-14 16:17 UTC (permalink / raw) To: u-boot Dear "V, Aneesh", In message <FF55437E1F14DA4BAEB721A458B6701706C58885A2@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: wd at 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." ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-14 16:17 ` Wolfgang Denk @ 2010-09-15 16:36 ` Scott Wood 2010-09-15 17:20 ` Stefan Roese 2010-09-15 17:45 ` Wolfgang Denk 0 siblings, 2 replies; 26+ messages in thread From: Scott Wood @ 2010-09-15 16:36 UTC (permalink / raw) To: u-boot On Tue, 14 Sep 2010 18:17:47 +0200 Wolfgang Denk <wd@denx.de> wrote: > Dear "V, Aneesh", > > In message <FF55437E1F14DA4BAEB721A458B6701706C58885A2@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-15 16:36 ` Scott Wood @ 2010-09-15 17:20 ` Stefan Roese 2010-09-15 17:45 ` Wolfgang Denk 1 sibling, 0 replies; 26+ messages in thread From: Stefan Roese @ 2010-09-15 17:20 UTC (permalink / raw) To: u-boot 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: office at denx.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-15 16:36 ` Scott Wood 2010-09-15 17:20 ` Stefan Roese @ 2010-09-15 17:45 ` Wolfgang Denk 2010-09-15 18:01 ` Scott Wood 1 sibling, 1 reply; 26+ messages in thread From: Wolfgang Denk @ 2010-09-15 17:45 UTC (permalink / raw) To: u-boot Dear Scott Wood, In message <20100915113602.52666885@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: wd at denx.de Microsoft Multitasking: several applications can crash at the same time. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-15 17:45 ` Wolfgang Denk @ 2010-09-15 18:01 ` Scott Wood 2010-09-15 19:21 ` Wolfgang Denk 0 siblings, 1 reply; 26+ messages in thread From: Scott Wood @ 2010-09-15 18:01 UTC (permalink / raw) To: u-boot On Wed, 15 Sep 2010 19:45:17 +0200 Wolfgang Denk <wd@denx.de> wrote: > Dear Scott Wood, > > In message <20100915113602.52666885@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] Multiple binaries built through u-boot source 2010-09-15 18:01 ` Scott Wood @ 2010-09-15 19:21 ` Wolfgang Denk 0 siblings, 0 replies; 26+ messages in thread From: Wolfgang Denk @ 2010-09-15 19:21 UTC (permalink / raw) To: u-boot Dear Scott Wood, In message <20100915130155.7e7b2039@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: wd at 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_ ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2010-09-17 9:21 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-09-14 5:22 [U-Boot] Multiple binaries built through u-boot source Vipin Kumar 2010-09-14 7:05 ` Mike Frysinger 2010-09-14 7:16 ` Stefan Roese 2010-09-14 8:11 ` Kyungmin Park 2010-09-14 10:21 ` Vipin Kumar 2010-09-14 12:40 ` Stefan Roese 2010-09-14 13:02 ` Mike Frysinger 2010-09-14 13:33 ` V, Aneesh 2010-09-14 13:51 ` Stefan Roese 2010-09-14 14:18 ` Kyungmin Park 2010-09-14 14:26 ` Stefan Roese 2010-09-14 14:32 ` Kyungmin Park 2010-09-14 15:16 ` Mike Frysinger 2010-09-16 15:44 ` Premi, Sanjeev 2010-09-16 17:59 ` Scott Wood 2010-09-17 9:12 ` Premi, Sanjeev 2010-09-16 18:31 ` Mike Frysinger 2010-09-17 9:21 ` Premi, Sanjeev 2010-09-14 14:22 ` Vaibhav Bedia 2010-09-14 14:26 ` Kyungmin Park 2010-09-14 16:17 ` Wolfgang Denk 2010-09-15 16:36 ` Scott Wood 2010-09-15 17:20 ` Stefan Roese 2010-09-15 17:45 ` Wolfgang Denk 2010-09-15 18:01 ` Scott Wood 2010-09-15 19:21 ` Wolfgang Denk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.