- 08 5月, 2009 1 次提交
-
-
由 Paul Gortmaker 提交于
From: Bruce Ashfield <bruce.ashfield@windriver.com> To fully support the armv7-a instruction set/optimizations, support for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is required. The MOVW and MOVT are both load-immediate instructions, MOVW loads 16 bits into the bottom half of a register, and MOVT loads 16 bits into the top half of a register. The relocation information for these instructions has a full 32 bit value, plus an addend which is stored in the 16 immediate bits in the instruction itself. The immediate bits in the instruction are not contiguous (the register # splits it into a 4 bit and 12 bit value), so the addend has to be extracted accordingly and added to the value. The value is then split and put into the instruction; a MOVW uses the bottom 16 bits of the value, and a MOVT uses the top 16 bits. Signed-off-by: NDavid Borman <david.borman@windriver.com> Signed-off-by: NBruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 21 3月, 2009 1 次提交
-
-
由 Daniel Silverstone 提交于
It would seem when building kernel modules with modern binutils (required by modern GCC) for ARM v4T targets (specifically observed with the Samsung 24xx SoC which is an 920T) R_ARM_V4BX relocations are emitted for function epilogues. This manifests at module load time with an "unknown relocation: 40" error message. The following patch adds the R_ARM_V4BX relocation to the ARM kernel module loader. The relocation operation is taken from that within the binutils bfd library. Signed-off-by: NSimtec Linux Team <linux@simtec.co.uk> Signed-off-by: NVincent Sanders <vince@simtec.co.uk> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 2月, 2009 1 次提交
-
-
由 Catalin Marinas 提交于
This patch adds ELF section parsing for the unwinding tables in loadable modules together with the PREL31 relocation symbol resolving. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 12月, 2008 1 次提交
-
-
由 Russell King 提交于
Update to use the asm/sections.h header rather than declaring these symbols ourselves. Change __data_start to _data to conform with the naming found within asm/sections.h. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 11月, 2008 1 次提交
-
-
由 Russell King 提交于
As of 73bdf0a6, the kernel needs to know where modules are located in the virtual address space. On ARM, we located this region between MODULE_START and MODULE_END. Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END. Update ARM to use the same naming, so is_vmalloc_or_module_addr() can work properly. Also update the comment on mm/vmalloc.c to reflect that ARM also places modules in a separate region from the vmalloc space. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 10月, 2008 1 次提交
-
-
由 Russell King 提交于
Add support for detecting non-executable stack binaries, and adjust permissions to prevent execution from data and stack areas. Also, ensure that READ_IMPLIES_EXEC is enabled for older CPUs where that is true, and for any executable-stack binary. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 25 7月, 2008 1 次提交
-
-
由 Andrea Righi 提交于
On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit boundary. For example: u64 val = PAGE_ALIGN(size); always returns a value < 4GB even if size is greater than 4GB. The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for example): #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) ... #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK) The "~" is performed on a 32-bit value, so everything in "and" with PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary. Using the ALIGN() macro seems to be the right way, because it uses typeof(addr) for the mask. Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in include/linux/mm.h. See also lkml discussion: http://lkml.org/lkml/2008/6/11/237 [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c] [akpm@linux-foundation.org: fix v850] [akpm@linux-foundation.org: fix powerpc] [akpm@linux-foundation.org: fix arm] [akpm@linux-foundation.org: fix mips] [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c] [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c] [akpm@linux-foundation.org: fix powerpc] Signed-off-by: NAndrea Righi <righi.andrea@gmail.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 5月, 2007 1 次提交
-
-
由 Kevin Welton 提交于
Branches in the ARM architecture are restricted to a range of +/- 32MB. However, the code in .../arch/arm/kernel/module.c::apply_relocate() was checking offset against a range of +/- 64MB. Signed-off-by: NKevin Welton <Kevin.Welton@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 28 9月, 2006 1 次提交
-
-
由 Hyok S. Choi 提交于
A simple patch to support module in nommu mode. The vmalloc is used instead of __vmalloc_area which depends on CONFIG_MMU. Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 15 12月, 2005 1 次提交
-
-
由 Daniel Jacobowitz 提交于
Patch from Daniel Jacobowitz Handle new EABI relocations when loading kernel modules. This is necessary for CONFIG_AEABI kernels, and also for some broken (since fixed) old ABI toolchains. Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 28 10月, 2005 1 次提交
-
-
由 Russell King 提交于
Fix sparse warnings in arch/arm/kernel/module.c, arch/arm/mm/consistent.c, drivers/pcmcia/sa1111_generic.c, and platform support files. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-