path: root/arch/mips/lib/reloc.c
Commit message (Collapse)AuthorAgeFilesLines
* MIPS: correctly work with disabled CONFIG_MMUAntony Pavlov2020-06-081-1/+5
| | | | | | | | | | | | | | There are some issues with CONFIG_MMU=n in MIPS configuration (e.g. qemu-malta_defconfig): * "Cannot request SDRAM region for stack" error message on start; * empty kseg1_ram0 region in the iomem command output. The patch fixes the problems by forcing KSEG1 memory region usage for CONFIG_MMU=n MIPS configurations. Signed-off-by: Antony Pavlov <> Signed-off-by: Sascha Hauer <>
* MIPS: don't overlay relocation data with BSSOleksij Rempel2020-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .bss __rel_start (OVERLAY) was used to optimize RAM size used by barebox. Since .bss and __rel_start overlap, we should clear bss only after __rel_start was used. Following patch changed initialization sequence to clear .bss before __rel_start: 1e5aef61fc6a444 ("MIPS: reloc: init bss and cpu") This make relocation buffer unusable and broke relocation with different symptoms reported by Antony Pavlov <>: * iomem output has no information on sdram regions, so memtest is unusable; * pc = 0xa081232c, relocation does not work, barebox is located with 8M offset from start of RAM. The board has 256M and relocation routine should move barebox code much higher; * pc = 0xa081232c, so barebox code works from KSEG1 not from KSEG0 as MMU=y option implies. There is a choice of moving .bss clear sequence after __rel_start or remove this optimization. Since the use of this optimization is minimal and danger to trap in to similar issue is still high, i prefer to remove this optimization. As result of this change, we need to fix calculation of relocation are size: relocate_code() calculates relocation area size as a sum (barebox_image_size + bss_len). barebox_image_size and bss_len are calculated as (__image_end - __image_start) and (__bss_stop - __bss_start) respectively. This doesn't take into account relocation data placed between __image_end and __bss_start. However relocation preserves BSS position relative to image start, as if relocation data is still there. This causes RAM overflow during BSS initialization in main_entry(). This problem may be hidden due to the alignment of the `relocaddr`. Reported-by: Antony Pavlov <> Fixes: 1e5aef61fc6a444 ("MIPS: reloc: init bss and cpu") Signed-off-by: Oleksij Rempel <> Signed-off-by: Peter Mamonov <> Signed-off-by: Sascha Hauer <>
* MIPS: reloc: init bss and cpuOleksij Rempel2019-10-231-0/+2
| | | | | | | We need it to make flush_cache_all() work properly. Signed-off-by: Oleksij Rempel <> Signed-off-by: Sascha Hauer <>
* MIPS: reloc: remove init of relocated bssOleksij Rempel2019-10-231-5/+1
| | | | | | | It will be done in main_entry() any way. Signed-off-by: Oleksij Rempel <> Signed-off-by: Sascha Hauer <>
* mips: reloc: remove outdated commentOleksij Rempel2019-07-021-11/+0
| | | | | Signed-off-by: Oleksij Rempel <> Signed-off-by: Sascha Hauer <>
* MIPS: relocate_code: fix barebox image memcpy() sizeAntony Pavlov2019-06-201-6/+5
| | | | | | | | | | | | | | | | | In this relocate_code() piece 'length' is greater than 'barebox_image_size': #define MAX_BSS_SIZE SZ_1M ... length = barebox_image_size + MAX_BSS_SIZE; relocaddr = ALIGN_DOWN(ram_size - barebox_image_size, SZ_64K); ... memcpy((void *)relocaddr, __image_start, length); so 'ram_size' overflow occurs during memcpy(). Signed-off-by: Antony Pavlov <> Tested-by: Oleksij Rempel <> Signed-off-by: Sascha Hauer <>
* MIPS: relocation: add relocation supportOleksij Rempel2019-04-231-0/+182
this patch i a port of following patch from u-boot with some additional integration changes and fixes of original code: | Subject: [PATCH] MIPS: Stop building position independent code | | U-Boot has up until now built with -fpic for the MIPS architecture, | producing position independent code which uses indirection through a | global offset table, making relocation fairly straightforward as it | simply involves patching up GOT entries. | | Using -fpic does however have some downsides. The biggest of these is | that generated code is bloated in various ways. For example, function | calls are indirected through the GOT & the t9 register: | | 8f998064 lw t9,-32668(gp) | 0320f809 jalr t9 | | Without -fpic the call is simply: | | 0f803f01 jal be00fc04 <puts> | | This is more compact & faster (due to the lack of the load & the | dependency the jump has on its result). It is also easier to read & | debug because the disassembly shows what function is being called, | rather than just an offset from gp which would then have to be looked up | in the ELF to discover the target function. | | Another disadvantage of -fpic is that each function begins with a | sequence to calculate the value of the gp register, for example: | | 3c1c0004 lui gp,0x4 | 279c3384 addiu gp,gp,13188 | 0399e021 addu gp,gp,t9 | | Without using -fpic this sequence no longer appears at the start of each | function, reducing code size considerably. | | This patch switches U-Boot from building with -fpic to building with | -fno-pic, in order to gain the benefits described above. The cost of | this is an extra step during the build process to extract relocation | data from the ELF & write it into a new .rel section in a compact | format, plus the added complexity of dealing with multiple types of | relocation rather than the single type that applied to the GOT. The | benefit is smaller, cleaner, more debuggable code. The relocate_code() | function is reimplemented in C to handle the new relocation scheme, | which also makes it easier to read & debug. | | Taking maltael_defconfig as an example the size of u-boot.bin built | using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils | 2.24.90) shrinks from 254KiB to 224KiB. | | Signed-off-by: Paul Burton <> Signed-off-by: Oleksij Rempel <> Signed-off-by: Sascha Hauer <>