| Age | Commit message (Collapse) | Author |
|---|
|
This is needed for proper alignment when the DTB appending feature
is used.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
|
|
Place read-only data in a .rodata output section, and the compressed
piggy data in .piggydata. Place the .got.plt section before the .got
section as is standard ELF practise.
This allows the piggydata to be more easily extracted from the
compressed vmlinux file for verification purposes.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used. Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.
While at it, let's align .bss as well.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
CC: stable@kernel.org
|
|
We currently presume a 4x expansion to guess the decompressed kernel size
in order to determine if the decompressed kernel is in conflict with
the location where zImage is loaded. This guess may cause many issues
by overestimating the final kernel image size:
- This may force a needless relocation if the location of zImage was
fine, wasting some precious microseconds of boot time.
- The relocation may be located way too far, possibly overwriting the
initrd image in RAM.
- If the kernel image includes a large already-compressed initramfs image
then the problem is even more exacerbated.
And if by some strange means the 4x guess is too low then we may overwrite
ourselves with the decompressed image.
So let's use the exact decompressed kernel image size instead. For that
we need to rely on the stat command, but this is hardly a new build
dependency as the kernel already depends on many external commands
to be built provided by the coreutils package where stat is found.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The .stack section doesn't contain any contents, and doesn't require
initialization either. Rather than marking the output section with
'NOLOAD' but still having it exist in the object files, mark it with
%nobits which avoids the assembler marking the section with 'CONTENTS'.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
|
|
Commit 2552fc2 changed the way the decompressor decides if it is safe
to decompress the kernel directly to its final location. Unfortunately,
it took the top of the compressed data as being the stack pointer,
which it is for ROM=n cases. However, for ROM=y, the stack pointer
is not relevant, and results in the wrong answer.
Fix this by explicitly storing the end of the biggybacked data in the
decompressor, and use that to calculate the compressed image size.
CC: <stable@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
We used to build decompressors with -Dstatic= to avoid any local data
being generated. The problem is that local data generates GOTOFF
relocations, which means we can't relocate the data relative to the
text segment.
Global data, on the other hand, goes through the GOT, and can be
relocated anywhere.
Unfortunately, with the new decompressors, this presents a problem
since they declare static data within functions, and this leads to
stack overflow.
Fix this by separating out the decompressor code into a separate file,
and removing 'static' from BSS data in misc.c.
Also, discard the .data section - this means that should we end up
with read/write initialized data, the decompressor will fail to link
and the problem will be obvious.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
This patch adds the main functionality for parsing the stack unwinding
information generated by the ARM EABI toolchains. The unwinding
information consists of an index with a pair of words per function and a
table with unwinding instructions. For more information, see "Exception
Handling ABI for the ARM Architecture" at:
http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Arrange for all the text ends up in the right place when
-ffunction-sections is used.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
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!
|
