aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/boot/setup.S
AgeCommit message (Collapse)Author
2007-05-02[PATCH] i386: Verify important CPUID bits in real modeAndi Kleen
Check some CPUID bits that are needed for compiler generated early in boot. When the system is still in real mode before changing the VESA BIOS mode it is possible to still display an visible error message on the screen. Similar to x86-64. Includes cleanups from Eric Biederman Signed-off-by: Andi Kleen <ak@suse.de>
2007-05-02[PATCH] x86: add command line length to boot protocolBernhard Walle
Because the command line is increased to 2048 characters after 2.6.21, it's not possible for boot loaders and userspace tools to determine the length of the command line the kernel can understand. The benefit of knowing the length is that users can be warned if the command line size is too long which prevents surprise if things don't work after bootup. This patch updates the boot protocol to contain a field called "cmdline_size" that contain the length of the command line (excluding the terminating zero). The patch also adds missing fields (of protocol version 2.05) to the x86_64 setup code. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Alon Bar-Lev <alon.barlev@gmail.com> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2006-12-07[PATCH] i386: extend bzImage protocol for relocatable protected mode kernelVivek Goyal
Extend bzImage protocol to enable bootloaders to load a completely relocatable bzImage. Now protected mode component of kernel is also relocatable and a boot-loader can load the protected mode component at a differnt physical address than 1MB. (If kernel was built with CONFIG_RELOCATABLE) Kexec can make use of it to load this kernel at a different physical address to capture kernel crash dumps. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-12-07[PATCH] i386: Relocatable kernel supportEric W. Biederman
This patch modifies the i386 kernel so that if CONFIG_RELOCATABLE is selected it will be able to be loaded at any 4K aligned address below 1G. The technique used is to compile the decompressor with -fPIC and modify it so the decompressor is fully relocatable. For the main kernel relocations are generated. Resulting in a kernel that is relocatable with no runtime overhead and no need to modify the source code. A reserved 32bit word in the parameters has been assigned to serve as a stack so we figure out where are running. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] x86: AUX_DEVICE_INFO is one byte long, use 'movb'Diego Calleja
Bugzilla #6552 says: "In arch/i386/boot/setup.S, movw is used instead of movb for PS/2 mouse information, although it is unsigned char. This does not harm, because the jmp instruction overwritten by movw is used before executing movw, and never be used again" I've no idea if this is a real bug or how it gets fixed, so I'm submitting it for review instead of letting it die of boredom in bugzilla. Aditionally to i386, I've changed x86-64, which mirrors the same code. Credits to Yoshinori K. Okuji, who found the problem and suggested a fix. Signed-off-by: Diego Calleja <diegocg@gmail.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-07-03kbuild: introduce utsrelease.hSam Ravnborg
include/linux/version.h contained both actual KERNEL version and UTS_RELEASE that contains a subset from git SHA1 for when kernel was compiled as part of a git repository. This had the unfortunate side-effect that all files including version.h would be recompiled when some git changes was made due to changes SHA1. Split it out so we keep independent parts in separate files. Also update checkversion.pl script to no longer check for UTS_RELEASE. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-09-07[PATCH] Make the bzImage format self-terminatingH. Peter Anvin
Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Frank Sorenson <frank@tuxrocks.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] x86_64: coding style and whitespace fixupsDomen Puncer
Remove some of the unnecessary differences between arch/i386 and arch/x86_64. This patch fixes more whitespace issues, some miscellaneous typos, a wrong URL and a factually incorrect statement about the current boot sector code. Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] Increase number of e820 entries hard limit from 32 to 128Venkatesh Pallipadi
The specifications that talk about E820 map doesn't have an upper limit on the number of e820 entries. But, today's kernel has a hard limit of 32. With increase in memory size, we are seeing the number of E820 entries reaching close to 32. Patch below bumps the number upto 128. The patch changes the location of EDDBUF in zero-page (as it comes after E820). As, EDDBUF is not used by boot loaders, this patch should not have any effect on bootloader-setup code interface. Patch covers both i386 and x86-64. Tested on: * grub booting bzImage * lilo booting bzImage with EDID info enabled * pxeboot of bzImage Side-effect: bss increases by ~ 2K and init.data increases by ~7.5K on all systems, due to increase in size of static arrays. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!