| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add support for XZ compressed kernel. Same as on x86 and sh.
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
The 'output' variable is passed from decompress_kernel to
check_ipl_parmblock before it is initialized. That disables the
safe guard against the overwrite of the ipl parameter block.
Fix this by passing the correct value to check_ipl_parmblock.
Reported-by: David Binderman <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Fix two bugs with the kernel image compression:
1) reset the bss section of the compressed vmlinux
2) clear the high half of the registers for 64 bit early enough
for the decompression step
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Add the "bzImage" compile target and the necessary code to generate
compressed kernel images. The old style uncompressed "image" target
is preserved, a simple make will build them both.
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Replace the use of CROSS_COMPILE to select a customized
installkernel script with the possibility to set INSTALLKERNEL
to select a custom installkernel script when running make:
make INSTALLKERNEL=arm-installkernel install
With this patch we are now more consistent across
different architectures - they did not all support use
of CROSS_COMPILE.
The use of CROSS_COMPILE was a hack as this really belongs
to gcc/binutils and the installkernel script does not change
just because we change toolchain.
The use of CROSS_COMPILE caused troubles with an upcoming patch
that saves CROSS_COMPILE when a kernel is built - it would no
longer be installable.
[Thanks to Peter Z. for this hint]
This patch undos what Ian did in commit:
0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46
("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")
The patch has been lightly tested on x86 only - but all changes
looks obvious.
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Mike Frysinger <[email protected]> [blackfin]
Acked-by: Russell King <[email protected]> [arm]
Acked-by: Paul Mundt <[email protected]> [sh]
Acked-by: "H. Peter Anvin" <[email protected]> [x86]
Cc: Ian Campbell <[email protected]>
Cc: Tony Luck <[email protected]> [ia64]
Cc: Fenghua Yu <[email protected]> [ia64]
Cc: Hirokazu Takata <[email protected]> [m32r]
Cc: Geert Uytterhoeven <[email protected]> [m68k]
Cc: Kyle McMartin <[email protected]> [parisc]
Cc: Benjamin Herrenschmidt <[email protected]> [powerpc]
Cc: Martin Schwidefsky <[email protected]> [s390]
Cc: Thomas Gleixner <[email protected]> [x86]
Cc: Ingo Molnar <[email protected]> [x86]
Signed-off-by: Sam Ravnborg <[email protected]>
|
|
The attached patch causes the various arch specific install.sh scripts to
look for ${CROSS_COMPILE}installkernel rather than just installkernel (in
both /sbin/ and ~/bin/ where the script already did this). This allows you
to have e.g. arm-linux-installkernel as a handy way to install on your
cross target. It also prevents the script picking up on the host
/sbin/installkernel which causes the script to fall through and do the
install itself (which is what I actually use myself, with $INSTALL_PATH
set).
I don't believe it causes back-compatibility problems since calling the
host installkernel was never likely to work or be what you wanted when
cross compiling anyway. If $CROSS_COMPILE isn't set then nothing changes.
I only use ARM and i386 myself but I figured it couldn't hurt to do the
whole lot. I've cc'd those who I hope are the arch maintainers for files
that I've touched.
Signed-off-by: Ian Campbell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
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!
|