[U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Dirk Behme <dirk.behme@de.bosch.com>]

On 03.02.2012 09:51, Stefano Babic wrote:
> On 03/02/2012 08:25, Dirk Behme wrote:
>> Hi,
>>
> 
> Hi Dirk,
> 
>> on i.MX6 devices, e.g. ARM2 or SabreLite, the ROM boot loader copies the
>> U-Boot image from the boot device, e.g. the SD card, to the main memory.
>> This does mean that U-Boot is started in RAM.
>>
> 
> The same happens on MX5 and on several other SOCs, such as TIs.
> 
> 
>> With this, one might wonder why any relocation RAM -> RAM is done anyway
>> and if this could be skipped?
> 
> There was very long threads in the ML when it was discussed 

Sorry if this was a FAQ. Many thanks for answering! :)

> if and how
> to introduce relocation for ARM processors. U-Boot for PowerPC have
> always supported relocation.
> 
> Relocation has other advantages as only to make U-Boot running from RAM.
> The main advantage I can see is that with relocation we can find at
> runtime the current size of installed RAM, and then move U-Boot at the
> end of RAM, leaving the whole memory free for the rest.
> 
> As rest I mean also loading the kernel, and avoiding that by increasing
> the kernel size or loading other images (ramdisks, fpga, some other
> blobs) there is a conflict with the running bootloader. This happened
> mopre often as we can imagine ;-)
> 
> Another point is that, getting the RAM size at runtime, we can have the
> same image if additional RAM is installed (or a new version with more
> memory is developped). This does not happen generally for the evaluation
> boards, but it happens very often with custom boards.
> In most cases, customers appreciate to have a single image supporting
> both hardware revisions (with more or less RAM).
> 
> There are also other features running with relocation (protected RAM,
> for example), sharing memory with Linux. We cannot have a general
> solution if each SOC defines its own private and fix address in RAM to
> link U-Boot.
> 
>> Looking into the details shows that board_init_f() in
>> arch/arm/lib/board.c and relocate_code() in arch/arm/cpu/armv7/start.S
>> [1] are involved in this.
>>
>> In board_init_f() the relocation destination address 'addr' is
>> calculated. This is basically at the end of the available RAM (- some
>> space for various stuff like TLB tables etc.). At SabreLite this results
>> in 0x4FF8D000.
> 
> This is the reason - independently how much RAM you have on a Sabre, on
> a mx53QSB, or on the Beagleboard, U-Boot will be moved for all targets
> at the end of the memory.
> 
>> By the boot loader, the U-Boot is loaded to
>>
>> CONFIG_SYS_TEXT_BASE        0x17800000
>>
>> This results in relocate_code() copying U-Boot from RAM 0x17800000 to
>> RAM 0x4FF8D000.
> 
> Right
> 
>> Setting CONFIG_SYS_TEXT_BASE to the relocation destination address
>> 0x4FF8D000 does avoid the (unnecessary?) copy by
> 
> That's right - it was used in the past. We had also a
> CONFIG_SKIP_RELOCATE_UBOOT during the transition phase, together
> with other ones (I remember CONFIG_SYS_ARM_WITHOUT_RELOC).
> 
> These CONFIG_ are obsolete and they were removed some times ago.
> 
>> cmp    r0, r6
>> moveq    r9, #0    /* no relocation. relocation offset(r9) = 0 */
>> beq    clear_bss /* skip relocation */
>>
>> in relocate_code().
>>
>> But:
>>
>> 1) The resulting image still runs without the relocation
>> (CONFIG_SYS_TEXT_BASE 0x4FF8D000). But e.g. the U-Boot command line
>> doesn't work properly any more. Most probably this is because not only
>> the copy is skipped by the 'beq    clear_bss', but the whole 'fix
>> .rel.dyn relocations' is skipped too.
>>
>> 2) It's hard to set CONFIG_SYS_TEXT_BASE at compile time to the
>> relocation address calculated at runtime in board_init_f() due to the
>> amount of #ifdef and runtime calculation done there. So finding a
>> generic approach which could easily defined in the config files to avoid
>> the relocation seems difficult.
> 
> Well, this is an advantage of relocation - we do not need such fixed
> address, and we have a generic way running on all architectures. You can
> of couse fix things to skip relocation on your board, 

Ok, understood :) Do you have any pointers or hints how to implement a 
board specific relocation skip? Just in case somebody wants us to 
implement this for a specific i.MX6 board ...

> but it is hard to
> make it generic and for the above reasons I doubt that can flow to mainline.
> 
> As your concerns are surely related to speed up the boot process, IMHO
> we can focus efforts to add cache support for MX5 / MX6.

Ok, sounds good. Any idea what has to be done for this? Or what would be 
the steps for this? Maybe we should open a new thread or at least rename 
the subject of this mail for this discussion?

Best regards

Dirk