[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
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
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@denx.de
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
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
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@denx.de
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
Hi,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@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
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@denx.de
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@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/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@denx.de
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
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
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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 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@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
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
-----Original Message----- From: Scott Wood [mailto:scottwood@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" 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-30KBNAND 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 alsobe 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
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
-----Original Message----- From: Mike Frysinger [mailto:vapier@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-30KBthe 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 alsobe 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
On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh aneesh@ti.com wrote:
Hi,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@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.
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@lists.denx.de [mailto:u-boot- bounces@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
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
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
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@denx.de
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
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
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
participants (9)
-
Kyungmin Park -
Mike Frysinger -
Premi, Sanjeev -
Scott Wood -
Stefan Roese -
V, Aneesh -
Vaibhav Bedia -
Vipin Kumar -
Wolfgang Denk