summaryrefslogtreecommitdiff
path: root/Documentation/i386
AgeCommit message (Collapse)AuthorFilesLines
2007-07-12Define zero-page offset 0x1e4 as a scratch field, and use itH. Peter Anvin1-0/+1
The relocatable kernel code needs a scratch field for the decompressor to determine its own location. It was using a location inside struct screen_info; reserve a free location and document it as scratch instead. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-23boot documentation: clarificationsH. Peter Anvin1-10/+22
Textual clarifications (and fix an off-by-one error) based on feedback mostly from Jeremy Fitzhardinge. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-18Further update of the i386 boot documentationH. Peter Anvin1-82/+303
A number of items in the i386 boot documentation have been either vague, outdated or hard to read. This text revision adds several more examples, including a memory map for a modern kernel load. It also adds a field-by-field detailed description of the setup header, and a bootloader ID for Qemu. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08Documentation/i386/boot.txt: update and correctH. Peter Anvin1-23/+78
In the process of rewriting the x86 setup code, I found a number of inaccuracies and outdated recommendations in the boot protocol documentation. Revamp to make it more up to date. In particular, the common use of the heap actually requires (slightly) more than 4K of heap plus stack, which is the recommended amount in the document; currently the code compensates by being smaller than specified, but we can't assume that will be true forever. Thus, recommend that if we have a modern bzImage kernel, that the bootloader maximizes the available space. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-02[PATCH] x86: add command line length to boot protocolBernhard Walle1-6/+17
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-01-26[PATCH] Boot loader ID for GujinH. Peter Anvin1-1/+2
Add an official boot loader ID for Gujin. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-07[PATCH] x86-64: Correct documentation for bzImage protocol v2.05Vivek Goyal1-3/+3
Correct the documentation for bzImage protocol extension due to relocatable bzImage. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Acked-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@osdl.org>
2006-12-07[PATCH] i386: extend bzImage protocol for relocatable protected mode kernelVivek Goyal1-0/+4
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-09-13[PATCH] x86: reserve a boot-loader ID number for XenJeremy Fitzhardinge2-0/+5
Claim an ID number for Xen in the LOADER_TYPE field. Also, keep the table in zero-page.txt consistent with boot.txt. [hpa says: 6 was skipped because I couldn't rule out that it hadn't been unofficially used. It seemed easier to skip it for now.] Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Acked-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07[PATCH] Make the bzImage format self-terminatingH. Peter Anvin1-13/+22
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-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-rc2Linus Torvalds4-0/+686
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!