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

[Stefano Babic <sbabic@denx.de>]

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

Best regards,
Stefano

-- 
=====================================================================
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 at denx.de
=====================================================================