[U-Boot] SPL framework re-design
Daniel Schwierzeck
daniel.schwierzeck at googlemail.com
Fri Jun 17 20:45:19 CEST 2011
Dear Wolfgang,
On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Daniel Schwierzeck,
>
> In message <BANLkTim9AE2aszKLiDH53vd+Hjpz7GVoNA at mail.gmail.com> you wrote:
>>
>> The relocate_code and board_init_r functions must not be compiled,
>> they are not needed anyway. This
>> can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD.
>
> This is very much wrong. In the general case, you still need
> relocation (because the final start address of the U-Boot code canonly
> be determined at runtime), and you definitely need the code in
> board_init_r().
I guess we are talking about different kinds of SPL. In my understanding a SPL
runs inside an internal SRAM, initializes any external RAM and loads
U-Boot from
any kind of memory or flash device into that RAM at a fixed load address and
then jumps to that address. In this case no relocation is needed. Some kind
of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM
loads the SPL initially into SRAM and jumps to it.
>
>
>> >> available in media specific directories such as nand_spl/ and mmc_spl/.
>> >> Symbolic links?
>> >
>> > No. Let's put this stuff into spl/common/
>>
>> To use the spl directory as remote build directory, the obj and src variables
>> must be tweaked a little. To keep this changes minimal, it is not possible to
>> have further source files and directories inside the spl directory. I suggest to
>> put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on.
>
> No. All SPL related stuff should go into spl/
ok
Best regards,
Daniel
More information about the U-Boot
mailing list