Commit Graph

11 Commits

Author SHA1 Message Date
Nicolas Pitre
72bf0bce41 ARM: zImage: ensure it is always a multiple of 64 bits in size
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>
2011-09-14 12:12:12 -04:00
Russell King
3002b41bc6 ARM: decompressor: use better output sections
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>
2011-07-07 23:35:35 +01:00
Nicolas Pitre
3bd2cbb955 ARM: zImage: make sure the stack is 64-bit aligned
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
2011-05-06 23:55:49 -04:00
Nicolas Pitre
d239b1dc09 ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel
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>
2011-02-26 13:39:51 +00:00
Russell King
b0c4d4ee4e ARM: avoid marking decompressor .stack section as having contents
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>
2010-11-22 12:00:59 +00:00
Russell King
91e013827c Merge branch 'master' into for-linus 2010-03-08 20:24:11 +00:00
Russell King
98e12b5a6e ARM: Fix decompressor's kernel size estimation for ROM=y
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>
2010-02-26 00:10:47 +00:00
Russell King
5de813b6cd ARM: Eliminate decompressor -Dstatic= PIC hack
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>
2010-02-25 19:34:31 +00:00
Catalin Marinas
bff595c15c [ARM] 5383/2: unwind: Add core support for ARM stack unwinding
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>
2009-02-19 11:26:24 +00:00
Russell King
c5b8ef62b5 [ARM] Allow decompressor to be built with -ffunction-sections
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>
2006-04-09 19:08:42 +01:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00