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.