Commit Graph

10 Commits (002547b4f86c27bfac5bae344b723d250857be6b)

Author SHA1 Message Date
Russell King 9d4f13e531 [ARM] Make kernel link address depend on PAGE_OFFSET
We are coding the kernel link address into the makefiles, which is
invisibly dependent on PAGE_OFFSET.  If PAGE_OFFSET is changed, the
makefiles also need to be changed.

Make adjustments such that the makefiles encode just the offset from
PAGE_OFFSET for the kernel link address, and use PAGE_OFFSET in the
linker scripts directly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-03 17:28:33 +00:00
Russell King 728f5c076a [ARM] Improve comment about ASSERT()s in vmlinux.lds.S
Provide folk with an idea what to do if the ASSERT statements fail
with their linker.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-17 16:43:14 +00:00
Nicolas Pitre 37d07b72ef [ARM] 3061/1: cleanup the XIP link address mess
Patch from Nicolas Pitre

Since vmlinux.lds.S is preprocessed, we can use the defines already
present in asm/memory.h (allowed by patch #3060) for the XIP kernel link
address instead of relying on a duplicated Makefile hardcoded value, and
also get rid of its dependency on awk to handle it at the same time.

While at it let's clean XIP stuff even further and make things clearer
in head.S with a nice code reduction.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29 21:44:56 +01:00
Nicolas Pitre 13b1f64c16 [ARM] 3008/1: the exception table is not read-only
Patch from Nicolas Pitre

... and therefore should not live in the .text section.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-13 22:04:37 +01:00
Ben Dooks 9d0fd1eb8a [ARM] 2927/1: .arch.info - postfix section with .init for `make buildcheck`
Patch from Ben Dooks

The `make buildcheck` is erroneously reporting that the .arch.info
list is referencing items in the .init section as it is not itself
postfixed with .init

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-20 16:45:20 +01:00
Ben Dooks 02b7dd1244 [ARM] 2926/1: .proc.info - postfix section with .init for `make buildcheck`
Patch from Ben Dooks

The `make buildcheck` is erroneously reporting that the .proc.info
list is referencing items in the .init section as it is not itself
postfixed with .init

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-20 16:35:03 +01:00
Ben Dooks bfe6815e04 [ARM] 2925/3: earlyparam - postfix section with .init for `make buildcheck`
Patch from Ben Dooks

The `make buildcheck` is erroneously reporting that the earlyparam
list is referencing items in the .init section as it is not itself
postfixed with .init
Also, as per rmk's suggestion, rename the __early_param to
.early_param to bring it into line with everything else

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-20 16:25:12 +01:00
Ben Dooks 9506057fca [ARM] 2924/3: taglist - postfix section with .init for `make buildcheck`
Patch from Ben Dooks

The `make buildcheck` is erroneously reporting that the taglist
is referencing items in the .init section as it is not itself
postfixed with .init

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-20 16:20:49 +01:00
Russell King 4f7a18124c [PATCH] ARM: Fix kernel stack offset calculations
Various places in the ARM kernel implicitly assumed that kernel
stacks are always 8K due to hard coded constants.  Replace these
constants with definitions.

Correct the allowable range of kernel stack pointer values within
the allocation.  Arrange for the entire kernel stack to be zeroed,
not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-05 13:11:00 +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