20 Jul, 2007
1 commit
-
Follow Al Viro's m68k change from l-k:
i.e. tell modpost that entry point code (that has to be outside
of .init.text for external reasons) is OK to refer to .init.*Shuts up some section mismatch warnings from modpost.
Signed-off-by: Paul Mundt
12 Dec, 2006
1 commit
-
Signed-off-by: Paul Mundt
06 Dec, 2006
2 commits
-
There were a number of places that made evil PAGE_SIZE == 4k
assumptions that ended up breaking when trying to play with
8k and 64k page sizes, this fixes those up.The most significant change is the way we load THREAD_SIZE,
previously this was done via:mov #(THREAD_SIZE >> 8), reg
shll8 regto avoid a memory access and allow the immediate load. With
a 64k PAGE_SIZE, we're out of range for the immediate load
size without resorting to special instructions available in
later ISAs (movi20s and so on). The "workaround" for this is
to bump up the shift to 10 and insert a shll2, which gives a
bit more flexibility while still being much cheaper than a
memory access.Signed-off-by: Paul Mundt
-
This splits out common bits from the existing exception handler for
use between SH-2/SH-2A and SH-3/4, and adds support for the SH-2/2A
exceptions.Signed-off-by: Yoshinori Sato
Signed-off-by: Paul Mundt
27 Sep, 2006
4 commits
-
This enables support for 4K stacks on SH.
Currently this depends on DEBUG_KERNEL, but likely all boards
will switch to this as the default in the future.Signed-off-by: Paul Mundt
-
This adds a DEBUG_STACK_USAGE and DEBUG_STACKOVERFLOW for SH.
Signed-off-by: Paul Mundt
-
A synco is needed before we jump to start_kernel().
While we're at it, also move the sh_cpu_init() jump until after
we've zeroed BSS, as this has caused some undesirable results
in sh_cpu_init().Signed-off-by: Paul Mundt
-
We had a special .stack section in the ld script that
was being used to position r15 initially. This is
nonsensical, as we can just use a THREAD_SIZE offset
from the init_thread_union instead (as every other arch
does).Signed-off-by: Paul Mundt
17 Apr, 2005
1 commit
-
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!
