Commit Graph

78 Commits

Author SHA1 Message Date
Matthew Wilcox
12795067cf Update .gitignore for arch/i386/boot
With the new setup code, we generate a couple more files

Signed-off-by: Matthew Wilcox <matthew@wil.cx>
[ .. and do the same for x86-64 - Alexey ]
Acked-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 14:32:38 -07:00
Sam Ravnborg
3fbc54165d [PATCH] x86: do not recompile boot for each build
Keep the arch/i386/boot directory from being rebuilt every time.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2007-07-18 11:36:17 -07:00
H. Peter Anvin
8c027ae2dc [x86 setup] Save/restore DS around invocations of INT 10h
There exists at least one card, Trident TVGA8900CL (BIOS dated 1992/9/8)
which clobbers DS when "scrolling in an SVGA text mode of more than
800x600 pixels."  Although we are extremely unlikely to run into that
situation, it is cheap insurance to save and restore DS, and it only adds
a grand total of 50 bytes to the total output.

Pointed out by Etienne Lorrain.

Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2007-07-18 11:36:17 -07:00
H. Peter Anvin
7ad37df02c [x86 setup] VGA: Clear the Protect bit before setting the vertical height
If the user has asked for the vertical height registers to be recomputed
by setting bit 15 in the video mode number, we do so without clearing the
Protect bit in the Vertical Retrace Register before setting the Overflow
register.  As a result, if the VGA BIOS had set the Protect bit, the
write to the Overflow register will be dropped, and bits [9:8] of the
vertical height will be left unchanged.

This is a bug imported from the assembly version of this code.  It was
pointed out by Etienne Lorrain.

Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2007-07-18 11:36:17 -07:00
H. Peter Anvin
5593eaa854 [x86 setup] Fix assembly constraints
Fix incorrect assembly constraints.  In particular, fix memory
constraints used inside push..pop, which can cause invalid operation
since gcc may generate %esp-relative references.

Additionally:

outl() should have "dN" not "dn".

query_mca() shouldn't listen 16/32-bit registers in an 8-bit only
context.

has_eflag(): the "mask" is only used well after both the stack pointer
and the output registers have been touched; this requires the output
registers to be earlyclobbers (=&) and the input to exclude memory (so
"ri", not "g").

Thanks to Etienne Lorrain and Chuck Ebbert for prompting this review.

Cc: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2007-07-18 11:36:17 -07:00
H. Peter Anvin
9aa3909c0e [x86 setup] build/tools.c: fix comment
Correct a comment in arch/i386/boot/build/tools.c; we now build the
kernel from only two components instead of three, since the boot
sector has been integrated in the setup code.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2007-07-18 11:36:17 -07:00
Jeremy Fitzhardinge
600b2fc242 xen: suppress abs symbol warnings for unused reloc pointers
arch/i386/xen/xen-asm.S defines some small pieces of code which are
used to implement a few paravirt_ops.  They're designed so they can be
used either in-place, or be inline patched into their callsites if
there's enough space.

Some of those operations need to make calls out (specifically, if you
re-enable events [interrupts], and there's a pending event at that
time).  These calls need the call instruction to be relocated if the
code is patched inline.  In this case xen_foo_reloc is a
section-relative symbol which points to xen_foo's required relocation.

Other operations have no need of a relocation, and so their
corresponding xen_bar_reloc is absolute 0.  These are the cases which
are triggering the warning.

This patch adds those symbols to the list of safe abs symbols.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Adrian Bunk <bunk@stusta.de>
2007-07-18 08:47:45 -07:00
H. Peter Anvin
c397368232 Remove old i386 setup code
This removes the old i386 setup code.  This is done as a separate patch
to avoid breaking git bisect as some of the i386 code was also used by
the old x86-64 code.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:56 -07:00
H. Peter Anvin
4fd06960f1 Use the new x86 setup code for i386
This patch hooks the new x86 setup code into the Makefile machinery.  It
also adapts boot/tools/build.c to a two-file (as opposed to three-file)
universe, and simplifies it substantially.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
f2d98ae63d Linker script for the new x86 setup code
Linker script to define the layout of the new x86 setup code.
Includes assert for size overflow and a misaligned setup header.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
626073132b Assembly header and main routine for new x86 setup code
The assembly header and initialization code, and the main() routine.
main.c also contains some miscellaneous very short routines.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
7052fdd890 Code for actual protected-mode entry
This is the code which actually does the switch to protected mode,
including all preparation.  It is also responsible for invoking the
boot loader hooks, if present.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
5e8ddcbe86 Video mode probing support for the new x86 setup code
Video mode probing for the new x86 setup code.  This code breaks down
different drivers into modules.  This code deliberately drops support
for a lot of the vendor-specific mode probing present in the assembly
version, since a lot of those probes have been found to be stale in
current versions of those chips -- frequently, support for those modes
have been dropped from recent video BIOSes due to space constraints,
but the video BIOS signatures are still the same.

However, additional drivers should be extremely straightforward to plug
in, if desirable.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
337496eb73 Voyager support for the new x86 setup code
Voyager support for the new x86 setup code.  This implements the same
functionality as the assembly version.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
449f2ab946 Memory probing support for the new x86 setup code
Probe memory (INT 15h: E820, E801, 88).

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
3b53d3045b MCA support for new x86 setup code
MCA probing support for the new x86 setup code.  This implements the
same functionality as the assembly version.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
d13444a5a5 EDD probing code for the new x86 setup code
Probe EDD and MBR signatures, in order to make it easier to map
physical hard drives to BIOS drives.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
31b54f40e1 CPU features verification for the new x86 setup code
Verify that the CPU has enough features to run the kernel.  This may
entail enabling features on some CPUs.

By doing this in the setup code we can be guaranteed to still be able to
write to the console through the BIOS.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
0008ea39bd Version string for the new x86 setup code
Module which only includes the kernel version string.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
1543610ad7 Console-writing code for the new x86 setup code
This implements writing text to the console, including printf().

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
e44c22f65f Command-line parsing code for the new x86 setup code
Simple command-line parser which allows us to access the kernel command
line from the setup code.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
49df18fa3f APM probing code
APM probing code for the new x86 setup code.  This implements the
same functionality as the assembly version.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
5a8a8128bc A20 handling code
A20 handling code for the new x86 setup code.  This implements the same
algorithms as the assembly version.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
5be8656615 String-handling functions for the new x86 setup code.
strcmp(), memcpy(), memset(), as well as routines to copy to and from
other segments (as pointed to by fs and gs).

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:55 -07:00
H. Peter Anvin
ad7e906d56 Simple bitops for the new x86 setup code.
A simple collection of bitops for the new x86 setup code.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:54 -07:00
H. Peter Anvin
62bd0337d0 Top header file for new x86 setup code
Top header file for the new x86 setup code.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:54 -07:00
H. Peter Anvin
f7f4a5fbd2 Header file to produce 16-bit code with gcc
gcc for i386 can be used with the assembly prefix ".code16gcc" to generate
16-bit (real-mode) code.  This header file provides the assembly prefix.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12 10:55:54 -07:00
H. Peter Anvin
85414b693a Define zero-page offset 0x1e4 as a scratch field, and use it
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-07-12 10:55:54 -07:00
Christian Volkmann
4c1f59d8be i386: Fix wrong CPU error message in early boot path
- boot/setup.S did not print "PANIC: CPU too old for this kernel"
  ( not visible, also the message did not match )
- I add "# missed before: set ds"
  => somebody should check if I am right with the way to set.
  => seems to be a generic error in setup.S not to set "ds" for error messages.

AK: extracted patch out of other changes
AK: also couldn't find any other case where ds is wrong
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-21 09:56:57 -07:00
Linus Torvalds
01e73be3c8 Revert "fbdev: ignore VESA modes if framebuffer is disabled"
This reverts commit 464bdd33e9.

Peter Anvin correctly points out that VESA modes have nothing to do with
frame buffers per se - they are often just regular extended text modes.
Disabling them just because we don't have frame buffer support is very
wrong.

Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Antonino A. Daplas <adaplas@gmail.com>,
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 20:12:30 -07:00
Antonino A. Daplas
464bdd33e9 fbdev: ignore VESA modes if framebuffer is disabled
If the option vga=<VESA graphics mode> is added to the boot parameter, it will
activate graphics mode, but without any framebuffer support, the user is left
with an unusable display.

Change the behavior such that the user is instead prompted for another mode
(ala vga=ask).

NOTE: People can always use vbetool to set a graphics mode if this is really
desired, but the number of people doing this approaches zero.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08 11:15:26 -07:00
Andi Kleen
c7f81c9453 [PATCH] i386: Verify important CPUID bits in real mode
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 19:27:20 +02:00
Andi Kleen
484ad39365 [PATCH] i386: Drop -traditional in arch/i386/boot
Needed for followon patch

Signed-off-by: Andi Kleen <ak@suse.de>
2007-05-02 19:27:20 +02:00
Jeremy Fitzhardinge
35c7422649 [PATCH] x86: deflate stack usage in lib/inflate.c
inflate_fixed and huft_build together use around 2.7k of stack.  When
using 4k stacks, I saw stack overflows from interrupts arriving while
unpacking the root initrd:

do_IRQ: stack overflow: 384
 [<c0106b64>] show_trace_log_lvl+0x1a/0x30
 [<c01075e6>] show_trace+0x12/0x14
 [<c010763f>] dump_stack+0x16/0x18
 [<c0107ca4>] do_IRQ+0x6d/0xd9
 [<c010202b>] xen_evtchn_do_upcall+0x6e/0xa2
 [<c0106781>] xen_hypervisor_callback+0x25/0x2c
 [<c010116c>] xen_restore_fl+0x27/0x29
 [<c0330f63>] _spin_unlock_irqrestore+0x4a/0x50
 [<c0117aab>] change_page_attr+0x577/0x584
 [<c0117b45>] kernel_map_pages+0x8d/0xb4
 [<c016a314>] cache_alloc_refill+0x53f/0x632
 [<c016a6c2>] __kmalloc+0xc1/0x10d
 [<c0463d34>] malloc+0x10/0x12
 [<c04641c1>] huft_build+0x2a7/0x5fa
 [<c04645a5>] inflate_fixed+0x91/0x136
 [<c04657e2>] unpack_to_rootfs+0x5f2/0x8c1
 [<c0465acf>] populate_rootfs+0x1e/0xe4

(This was under Xen, but there's no reason it couldn't happen on bare
  hardware.)

This patch mallocs the local variables, thereby reducing the stack
usage to sane levels.

Also, up the heap size for the kernel decompressor to deal with the
extra allocation.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Tim Yamin <plasmaroo@gentoo.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ian Molton <spyro@f2s.com>
2007-05-02 19:27:15 +02:00
Bernhard Walle
8f9aeca7a0 [PATCH] x86: add command line length to boot protocol
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 19:27:10 +02:00
Zwane Mwaikambo
a369a7100d [PATCH] x86: Don't probe for DDC on VBE1.2
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst
uncompressing kernel with some video cards. Make sure we check VBE version
before fiddling around with DDC.

http://bugzilla.kernel.org/show_bug.cgi?id=1458

Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03

Much thanks to Tobias Hain for help in testing and investigating the bug.
Tested on;

i386, Chips & Technologies 65548 VESA VBE 1.2
CONFIG_VIDEO_SELECT=Y
CONFIG_FIRMWARE_EDID=Y

Untested on x86_64.

Signed-off-by: Zwane Mwaikambo <zwane@infradead.org>
Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-02 12:14:12 +02:00
Robert P. J. Day
ca820181fc Use ARRAY_SIZE() macro in i386 relocs.c file
Change the explicit code in the relocs.c file to use ARRAY_SIZE()
and add a definition of ARRAY_SIZE() since this is a userspace program
and wouldn't include kernel.h.

Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-02-17 19:10:01 +01:00
Al Viro
2a3d4f1f1f [PATCH] __crc_... is intended to be absolute
i386 boot/compressed/relocs checks for absolute symbols and warns about
unexpected ones.  If you build with modversions, you get ~2500 warnings
about __crc_<symbol>.  These suckers are really absolute symbols - we
do _not_ want to modify them on relocation.

They are generated by genksyms - EXPORT_... generates a weak alias, then
genksyms produces an ld script with __crc_<symbol> = <checksum> and it's
fed to ld to produce the final object file.  Their only use is to match
kernel and module at modprobe time; they _must_ be absolute.

boot/compressed/relocs has a whitelist of known absolute symbols, but
it doesn't know about __crc_... stuff.  As the result, we get shitloads
of false positives on any ld(1) version.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-01 16:17:06 -08:00
Segher Boessenkool
c6b33cc4e9 [PATCH] Fix insta-reboot with "i386: Relocatable kernel support"
Commit 968de4f026 ("i386: Relocatable
kernel support") caused problems for people with old binutils versions
that didn't mark ".text.*" sections automatically allocated.

So we should use .section command to specifically mark .text.head
section as AX (allocatable and executable) to solve the problem.

This should be unnecessary with binutils 2.15 and later, which is
already three years old, but it doesn't hurt supporting older toolchains
where possible.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2007-01-02 13:44:11 -08:00
Thomas Meyer
29263fbf9e [PATCH] Add .gitignore file for relocs in arch/i386
Due to the changes to make the kernel relocateable a new file is created
during the build process.

[jirislaby@gmail.com: The .gitigonre was intended to be in arch/ subtree]
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-30 10:55:55 -08:00
Randy Dunlap
d5d2448d89 [PATCH] x86-64: Fix numaq build error
CC      arch/i386/boot/compressed/misc.o
arch/i386/boot/compressed/misc.c:120: error: static declaration of 'xquad_portio' follows non-static declaration
include/asm/io.h:275: error: previous declaration of 'xquad_portio' was here
make[2]: *** [arch/i386/boot/compressed/misc.o] Error 1

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-07 02:14:13 +01:00
Rusty Russell
d3561b7fa0 [PATCH] paravirt: header and stubs for paravirtualisation
Create a paravirt.h header for all the critical operations which need to be
replaced with hypervisor calls, and include that instead of defining native
operations, when CONFIG_PARAVIRT.

This patch does the dumbest possible replacement of paravirtualized
instructions: calls through a "paravirt_ops" structure.  Currently these are
function implementations of native hardware: hypervisors will override the ops
structure with their own variants.

All the pv-ops functions are declared "fastcall" so that a specific
register-based ABI is used, to make inlining assember easier.

And:

+From: Andy Whitcroft <apw@shadowen.org>

The paravirt ops introduce a 'weak' attribute onto memory_setup().
Code ordering leads to the following warnings on x86:

    arch/i386/kernel/setup.c:651: warning: weak declaration of
                `memory_setup' after first use results in unspecified behavior

Move memory_setup() to avoid this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
2006-12-07 02:14:07 +01:00
Vivek Goyal
be274eeaf2 [PATCH] i386: extend bzImage protocol for relocatable protected mode kernel
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 02:14:04 +01:00
Vivek Goyal
e69f202d0a [PATCH] i386: Implement CONFIG_PHYSICAL_ALIGN
o Now CONFIG_PHYSICAL_START is being replaced with CONFIG_PHYSICAL_ALIGN.
  Hardcoding the kernel physical start value creates a problem in relocatable
  kernel context due to boot loader limitations. For ex, if somebody
  compiles a relocatable kernel to be run from address 4MB, but this kernel
  will run from location 1MB as grub loads the kernel at physical address
  1MB. Kernel thinks that I am a relocatable kernel and I should run from
  the address I have been loaded at. So somebody wanting to run kernel
  from 4MB alignment location (for improved performance regions) can't do
  that.

o Hence, Eric proposed that probably CONFIG_PHYSICAL_ALIGN will make
  more sense in relocatable kernel context. At run time kernel will move
  itself to a physical addr location which meets user specified alignment
  restrictions.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-07 02:14:04 +01:00
Vivek Goyal
6a044b3a0a [PATCH] i386: Warn upon absolute relocations being present
o Relocations generated w.r.t absolute symbols are not processed as by
  definition, absolute symbols are not to be relocated. Explicitly warn
  user about absolutions relocations present at compile time.

o These relocations get introduced either due to linker optimizations or
  some programming oversights.

o Also create a list of symbols which have been audited to be safe and
  don't emit warnings for these.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-07 02:14:04 +01:00
Eric W. Biederman
968de4f026 [PATCH] i386: Relocatable kernel support
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-12-07 02:14:04 +01:00
Eric W. Biederman
2a43f3ede4 [PATCH] i386: CONFIG_PHYSICAL_START cleanup
Defining __PHYSICAL_START and __KERNEL_START in asm-i386/page.h works but
it triggers a full kernel rebuild for the silliest of reasons.  This
modifies the users to directly use CONFIG_PHYSICAL_START and linux/config.h
which prevents the full rebuild problem, which makes the code much
more maintainer and hopefully user friendly.

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-12-07 02:14:04 +01:00
Zachary Amsden
5a73fdc5ea [PATCH] Some config.h removals
During tracking down a PAE compile failure, I found that config.h was being
included in a bunch of places in i386 code.  It is no longer necessary, so
drop it.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01 00:39:34 -07:00
H. Peter Anvin
575400d1b4 [PATCH] i386: Fix the EDD code misparsing the command line
The EDD code would scan the command line as a fixed array, without
taking account of either whitespace, null-termination, the old
command-line protocol, late overrides early, or the fact that the
command line may not be reachable from INITSEG.

This should fix those problems, and enable us to use a longer command
line.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:38 +02:00
Diego Calleja
606bd58de6 [PATCH] x86: AUX_DEVICE_INFO is one byte long, use 'movb'
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-09-26 10:52:30 +02:00