From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Fri, 3 Feb 2012 11:18:19 +0100 Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? In-Reply-To: <4F2BA01B.5080203@denx.de> References: <4F2B8BD1.2030009@de.bosch.com> <4F2BA01B.5080203@denx.de> Message-ID: <4F2BB46B.6040904@de.bosch.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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