| Age | Commit message (Collapse) | Author |
|---|
|
Since linux kernel has dropped support for simple firmware interface
(SFI), the only way of boot newer versions on intel MID platform is
using devicetree
Signed-off-by: Julian Winkler <julian.winkler1@web.de>
Signed-off-by: Simon Horman <horms@kernel.org>
|
|
After commit 060eee58 "x86: use old screen_info if needed", kexec-tools
will force use old screen_info and vga type if failed to determine
current vga type. But it is not always a good idea.
Currently kernel hanging is inspected on some hyper-v VMs after this
commit, because hyperv_fb will mimic EFI (or VESA) VGA on first boot
up, but after the real driver is loaded, it will switch to new mode
and no longer compatible with EFI/VESA VGA. Keep setting
orig_video_isVGA to EFI/VESA VGA flag will get wrong driver loaded and
try to manipulate the framebuffer in a wrong way.
We can't ensure this won't happen on other framebuffer drivers, But
it's a helpful feature if the framebuffer drivers just work. So this
patch introduce a --reuse-video-type options to let user decide if the
old screen_info hould be used unconditional or not.
Signed-off-by: Kairui Song <kasong@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For kernel boot with efi=old_map or some quirked machines like SGI UV
they use old ioremap instead of 1:1 mapping. But kexec efi support
depends on the 1:1 mapping thus we need to switch to use the old way
There's a kernel patch for exporting the efi flags so we can check the memory
mapping method. But user may want to explictly disable efi boot for unknown
reasons.
So here add a new arch option '--noefi' for this case.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
need to check xloadflags to see the bzImage is for 64bit relocatable.
-v2: add kexec-bzImage64.c according to Eric.
-v3: don't need to purgatory under 2g after Eric's change to purgatory code.
-v4: use locate_hole find position first then add_buffer... suggested by Eric
add buffer for kernel image at last to make kexec-load faster.
use xloadflags in setup_header to tell if is bzImage64.
remove not cross GB boundary searching.
add --entry-32bit and --real-mode for skipping bzImage64.
-v5: add buffer with runtime size instead, so kernel could use BRK
early and safely.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug, we have to re-compile the source
code with -DDEBUG. This is not convenient, we want to have
a generic --debug option so that we can enable debugging code
without re-compiling.
This patch moves the arch-specific --debug to generic place
and moves code under #ifdef DEBUG to --debug on x86.
BTW, the size of kexec binary increases very little after this patch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The argument parsing is currently a bit broken as main()'s getopt_long()
knows nothing about either the architecture-specific options or, even
more specifically, the architecture-and-loader-specific options.
This patch introduces new #defines for all architectures,
KEXEC_ALL_OPTIONS and KEXEC_ALL_OPT_STR. These contain all possible
options for a given build, and the getopt_long() passes in main() and
arch_process_options() will now recognise arch- and loader-specific
options; these will not be re-ordered in argv[], there is no confusion
over which argv[] entry is the kernel filename, and using '--opt=foo' and
'--opt foo' both work.
All architectures have command line options (and #define OPT_BLAHs)
consolidated into their include/arch/option.h files. x86_64 builds
parts of i386/ as well, so now both share a single option.h file (with
a symlink).
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Problem: If --elf32-core-headers option is specified after --initrd option
then initrd effectively becomes null and capture kernel does not see
any initrd.
o This problem happens because OPT_ELF32_CORE and OPT_RAMDISK are having
same value. This problem got introduced when option --elf32-core-headers
was moved from loader option to architecture dependent option.
o This patch needs to be applied after applying consolidated kdump patch.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o Creates a segment for storing elf headers.
o Creates Elf headers for dump capture.
o Functionality to modify command line internally. (Appending elfcorehdr= and
user defined memory map, memap=exactmap).
o Adds command line option to choose between ELF32 and ELF64 headers for core.
o As of today, gdb does not open ELF64 core file for i386 systems. So for
users who don't have PAE systems, can generate ELF32 headers by specifying
--elf32-core-headers on kexec command line. --elf64-core-headers forces
generation of ELF64 headers. ELF64 headers are generated by default.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
