summaryrefslogtreecommitdiffstats
path: root/arch/x86_64/boot/setup.S
AgeCommit message (Collapse)AuthorFilesLines
2007-07-12Use the new x86 setup code for x86-64; unify with i386H. Peter Anvin1-826/+0
This unifies arch/*/boot (except arch/*/boot/compressed) between i386 and x86-64, and uses the new x86 setup code for x86-64 as well. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-02[PATCH] x86-64: Share identical video.S between i386 and x86-64Andi Kleen1-1/+1
Signed-off-by: Andi Kleen <ak@suse.de>
2007-05-02[PATCH] x86: add command line length to boot protocolBernhard Walle1-1/+6
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>
2007-05-02[PATCH] x86-64: Move cpu verification code to common fileVivek Goyal1-59/+6
o This patch moves the code to verify long mode and SSE to a common file. This code is now shared by trampoline.S, wakeup.S, boot/setup.S and boot/compressed/head.S o So far we used to do very limited check in trampoline.S, wakeup.S and in 32bit entry point. Now all the entry paths are forced to do the exhaustive check, including SSE because verify_cpu is shared. o I am keeping this patch as last in the x86 relocatable series because previous patches have got quite some amount of testing done and don't want to distrub that. So that if there is problem introduced by this patch, at least it can be easily isolated. 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>
2007-05-02[PATCH] x86-64: Extend bzImage protocol for relocatable bzImageVivek Goyal1-2/+11
o Extend the bzImage protocol (same as i386) to allow bzImage loaders to load the protected mode kernel at non-1MB address. Now protected mode component is relocatable and can be loaded at non-1MB addresses. o As of today kdump uses it to run a second kernel from a reserved memory area. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de>
2006-11-14[PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment saysSteven Rostedt1-3/+2
Stephen Tweedie, Herbert Xu, and myself have been struggling with a very nasty bug in Xen. But it also pointed out a small bug in the x86_64 kernel boot setup. The GDT limit being setup by the initial bzImage code when entering into protected mode is way too big. The comment by the code states that the size of the GDT is 2048, but the actual size being set up is much bigger (32768). This happens simply because of one extra '0'. Instead of setting up a 0x800 size, 0x8000 is set up. On bare metal this is fine because the CPU wont load any segments unless they are explicitly used. But unfortunately, this breaks Xen on vmx FV, since it (for now) blindly loads all the segments into the VMCS if they are less than the gdt limit. Since the real mode segments are around 0x3000, we are getting junk into the VMCS and that later causes an exception. Stephen Tweedie has written up a patch to fix the Xen side and will be submitting that to those folks. But that doesn't excuse the GDT limit being a magnitude too big. AK: changed to compute true gdt size in assembler, fixed comment Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26[PATCH] x86: AUX_DEVICE_INFO is one byte long, use 'movb'Diego Calleja1-2/+2
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 Ravnborg1-1/+1
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 Engel1-1/+0
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 Anvin1-1/+1
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 Puncer1-4/+4
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 Pallipadi1-3/+3
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-rc2v2.6.12-rc2Linus Torvalds1-0/+867
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!