-----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