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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
