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