2005-04-16 15:20:36 -07:00
|
|
|
#
|
2007-10-11 11:16:45 +02:00
|
|
|
# arch/x86/boot/Makefile
|
2005-04-16 15:20:36 -07:00
|
|
|
#
|
|
|
|
# This file is subject to the terms and conditions of the GNU General Public
|
|
|
|
# License. See the file "COPYING" in the main directory of this archive
|
|
|
|
# for more details.
|
|
|
|
#
|
|
|
|
# Copyright (C) 1994 by Linus Torvalds
|
2009-03-11 10:55:33 -07:00
|
|
|
# Changed by many, many contributors over the years.
|
2005-04-16 15:20:36 -07:00
|
|
|
#
|
|
|
|
|
|
|
|
# If you want to preset the SVGA mode, uncomment the next line and
|
|
|
|
# set SVGA_MODE to whatever number you want.
|
|
|
|
# Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode.
|
|
|
|
# The number is the same as you would ordinarily press at bootup.
|
|
|
|
|
2009-03-11 10:55:33 -07:00
|
|
|
SVGA_MODE := -DSVGA_MODE=NORMAL_VGA
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-11 10:55:33 -07:00
|
|
|
targets := vmlinux.bin setup.bin setup.elf bzImage
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
targets += fdimage fdimage144 fdimage288 image.iso hdimage
|
2008-02-04 16:48:00 +01:00
|
|
|
subdir- := compressed
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-10-10 17:18:13 -07:00
|
|
|
setup-y += a20.o bioscall.o cmdline.o copy.o cpu.o cpuflags.o cpucheck.o
|
2015-07-20 18:23:50 +02:00
|
|
|
setup-y += early_serial_console.o edd.o header.o main.o memory.o
|
2010-08-02 02:17:31 -07:00
|
|
|
setup-y += pm.o pmjump.o printf.o regs.o string.o tty.o video.o
|
|
|
|
setup-y += video-mode.o version.o
|
2008-01-30 13:32:49 +01:00
|
|
|
setup-$(CONFIG_X86_APM_BOOT) += apm.o
|
2007-07-11 12:18:56 -07:00
|
|
|
|
|
|
|
# The link order of the video-*.o modules can matter. In particular,
|
|
|
|
# video-vga.o *must* be listed first, followed by video-vesa.o.
|
|
|
|
# Hardware-specific drivers should follow in the order they should be
|
|
|
|
# probed, and video-bios.o should typically be last.
|
|
|
|
setup-y += video-vga.o
|
|
|
|
setup-y += video-vesa.o
|
|
|
|
setup-y += video-bios.o
|
2007-10-15 17:13:22 -07:00
|
|
|
|
2007-07-17 22:27:22 +02:00
|
|
|
targets += $(setup-y)
|
2020-02-02 01:49:24 +09:00
|
|
|
hostprogs += mkcpustr
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-12 11:19:59 +01:00
|
|
|
HOST_EXTRACFLAGS += -I$(srctree)/tools/include \
|
|
|
|
-include include/generated/autoconf.h \
|
2012-03-22 11:08:18 -07:00
|
|
|
-D__EXPORTED_HEADERS__
|
|
|
|
|
2008-02-04 16:48:00 +01:00
|
|
|
$(obj)/cpu.o: $(obj)/cpustr.h
|
|
|
|
|
|
|
|
quiet_cmd_cpustr = CPUSTR $@
|
|
|
|
cmd_cpustr = $(obj)/mkcpustr > $@
|
|
|
|
$(obj)/cpustr.h: $(obj)/mkcpustr FORCE
|
|
|
|
$(call if_changed,cpustr)
|
2020-02-15 15:32:41 +09:00
|
|
|
targets += cpustr.h
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
2016-11-03 10:47:48 +01:00
|
|
|
KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP
|
2007-10-15 21:59:31 +02:00
|
|
|
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
|
2020-02-24 18:21:28 -05:00
|
|
|
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
|
2024-05-16 12:22:40 +02:00
|
|
|
KBUILD_CFLAGS += $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
|
2007-07-11 12:18:56 -07:00
|
|
|
|
2009-03-11 10:55:33 -07:00
|
|
|
$(obj)/bzImage: asflags-y := $(SVGA_MODE)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
quiet_cmd_image = BUILD $@
|
2025-04-24 12:19:18 +02:00
|
|
|
cmd_image = (dd if=$< bs=4k conv=sync status=none; cat $(filter-out $<,$(real-prereqs))) >$@
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86/boot: Drop CRC-32 checksum and the build tool that generates it
Apart from some sanity checks on the size of setup.bin, the only
remaining task carried out by the arch/x86/boot/tools/build.c build tool
is generating the CRC-32 checksum of the bzImage. This feature was added
in commit
7d6e737c8d2698b6 ("x86: add a crc32 checksum to the kernel image.")
without any motivation (or any commit log text, for that matter). This
checksum is not verified by any known bootloader, and given that
a) the checksum of the entire bzImage is reported by most tools (zlib,
rhash) as 0xffffffff and not 0x0 as documented,
b) the checksum is corrupted when the image is signed for secure boot,
which means that no distro ships x86 images with valid CRCs,
it seems quite unlikely that this checksum is being used, so let's just
drop it, along with the tool that generates it.
Instead, use simple file concatenation and truncation to combine the two
pieces into bzImage, and replace the checks on the size of the setup
block with a couple of ASSERT()s in the linker script.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250307164801.885261-2-ardb+git@google.com
2025-03-07 17:48:02 +01:00
|
|
|
$(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin FORCE
|
2005-04-16 15:20:36 -07:00
|
|
|
$(call if_changed,image)
|
2022-11-22 23:39:02 +09:00
|
|
|
@$(kecho) 'Kernel: $@ is ready' ' (#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-04 16:47:56 +01:00
|
|
|
OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
|
2005-04-16 15:20:36 -07:00
|
|
|
$(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
|
|
|
|
$(call if_changed,objcopy)
|
|
|
|
|
2007-07-11 12:18:56 -07:00
|
|
|
SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-06-03 11:19:51 +02:00
|
|
|
sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [a-zA-Z] \(startup_32\|efi.._stub_entry\|efi\(32\)\?_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|_e\?data\|_e\?sbat\|z_.*\)$$/\#define ZO_\2 0x\1/p'
|
2009-05-11 14:21:12 -07:00
|
|
|
|
|
|
|
quiet_cmd_zoffset = ZOFFSET $@
|
|
|
|
cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@
|
|
|
|
|
|
|
|
targets += zoffset.h
|
|
|
|
$(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE
|
|
|
|
$(call if_changed,zoffset)
|
2008-02-13 20:54:58 +00:00
|
|
|
|
|
|
|
|
2016-06-15 17:45:46 +02:00
|
|
|
AFLAGS_header.o += -I$(objtree)/$(obj)
|
x86/boot: Fix "run_size" calculation
Currently, the "run_size" variable holds the total kernel size
(size of code plus brk and bss) and is calculated via the shell script
arch/x86/tools/calc_run_size.sh. It gets the file offset and mem size
of the .bss and .brk sections from the vmlinux, and adds them as follows:
run_size = $(( $offsetA + $sizeA + $sizeB ))
However, this is not correct (it is too large). To illustrate, here's
a walk-through of the script's calculation, compared to the correct way
to find it.
First, offsetA is found as the starting address of the first .bss or
.brk section seen in the ELF file. The sizeA and sizeB values are the
respective section sizes.
[bhe@x1 linux]$ objdump -h vmlinux
vmlinux: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
27 .bss 00170000 ffffffff81ec8000 0000000001ec8000 012c8000 2**12
ALLOC
28 .brk 00027000 ffffffff82038000 0000000002038000 012c8000 2**0
ALLOC
Here, offsetA is 0x012c8000, with sizeA at 0x00170000 and sizeB at
0x00027000. The resulting run_size is 0x145f000:
0x012c8000 + 0x00170000 + 0x00027000 = 0x145f000
However, if we instead examine the ELF LOAD program headers, we see a
different picture.
[bhe@x1 linux]$ readelf -l vmlinux
Elf file type is EXEC (Executable file)
Entry point 0x1000000
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
0x0000000000b5e000 0x0000000000b5e000 R E 200000
LOAD 0x0000000000e00000 0xffffffff81c00000 0x0000000001c00000
0x0000000000145000 0x0000000000145000 RW 200000
LOAD 0x0000000001000000 0x0000000000000000 0x0000000001d45000
0x0000000000018158 0x0000000000018158 RW 200000
LOAD 0x000000000115e000 0xffffffff81d5e000 0x0000000001d5e000
0x000000000016a000 0x0000000000301000 RWE 200000
NOTE 0x000000000099bcac 0xffffffff8179bcac 0x000000000179bcac
0x00000000000001bc 0x00000000000001bc 4
Section to Segment mapping:
Segment Sections...
00 .text .notes __ex_table .rodata __bug_table .pci_fixup .tracedata
__ksymtab __ksymtab_gpl __ksymtab_strings __init_rodata __param
__modver
01 .data .vvar
02 .data..percpu
03 .init.text .init.data .x86_cpu_dev.init .parainstructions
.altinstructions .altinstr_replacement .iommu_table .apicdrivers
.exit.text .smp_locks .bss .brk
04 .notes
As mentioned, run_size needs to be the size of the running kernel
including .bss and .brk. We can see from the Section/Segment mapping
above that .bss and .brk are included in segment 03 (which corresponds
to the final LOAD program header). To find the run_size, we calculate
the end of the LOAD segment from its PhysAddr start (0x0000000001d5e000)
and its MemSiz (0x0000000000301000), minus the physical load address of
the kernel (the first LOAD segment's PhysAddr: 0x0000000001000000). The
resulting run_size is 0x105f000:
0x0000000001d5e000 + 0x0000000000301000 - 0x0000000001000000 = 0x105f000
So, from this we can see that the existing run_size calculation is
0x400000 too high. And, as it turns out, the correct run_size is
actually equal to VO_end - VO_text, which is certainly easier to calculate.
_end: 0xffffffff8205f000
_text:0xffffffff81000000
0xffffffff8205f000 - 0xffffffff81000000 = 0x105f000
As a result, run_size is a simple constant, so we don't need to pass it
around; we already have voffset.h for such things. We can share voffset.h
between misc.c and header.S instead of getting run_size in other ways.
This patch moves voffset.h creation code to boot/compressed/Makefile,
and switches misc.c to use the VO_end - VO_text calculation for run_size.
Dependence before:
boot/header.S ==> boot/voffset.h ==> vmlinux
boot/header.S ==> compressed/vmlinux ==> compressed/misc.c
Dependence after:
boot/header.S ==> compressed/vmlinux ==> compressed/misc.c ==> boot/voffset.h ==> vmlinux
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
[ Rewrote the changelog. ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Junjie Mao <eternal.n08@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: lasse.collin@tukaani.org
Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
Link: http://lkml.kernel.org/r/1461888548-32439-5-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-28 17:09:06 -07:00
|
|
|
$(obj)/header.o: $(obj)/zoffset.h
|
2008-02-13 20:54:58 +00:00
|
|
|
|
2022-08-10 15:24:41 -07:00
|
|
|
LDFLAGS_setup.elf := -m elf_i386 -z noexecstack -T
|
2007-07-11 12:18:56 -07:00
|
|
|
$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
|
2005-04-16 15:20:36 -07:00
|
|
|
$(call if_changed,ld)
|
|
|
|
|
2007-07-11 12:18:56 -07:00
|
|
|
OBJCOPYFLAGS_setup.bin := -O binary
|
|
|
|
$(obj)/setup.bin: $(obj)/setup.elf FORCE
|
|
|
|
$(call if_changed,objcopy)
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
$(obj)/compressed/vmlinux: FORCE
|
2008-10-04 21:18:51 +02:00
|
|
|
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 12:50:33 -07:00
|
|
|
# Set this if you want to pass append arguments to the
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
# bzdisk/fdimage/hdimage/isoimage kernel
|
2008-02-04 16:48:00 +01:00
|
|
|
FDARGS =
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
# Set this if you want one or more initrds included in the image
|
2006-03-26 01:36:59 -08:00
|
|
|
FDINITRD =
|
|
|
|
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
imgdeps = $(obj)/bzImage $(obj)/mtools.conf $(src)/genimage.sh
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
$(obj)/mtools.conf: $(src)/mtools.conf.in
|
|
|
|
sed -e 's|@OBJ@|$(obj)|g' < $< > $@
|
|
|
|
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
targets += mtools.conf
|
|
|
|
|
|
|
|
# genimage.sh requires bash, but it also has a bunch of other
|
|
|
|
# external dependencies.
|
2017-11-06 11:32:56 +08:00
|
|
|
quiet_cmd_genimage = GENIMAGE $3
|
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-04-27 23:55:02 +09:00
|
|
|
cmd_genimage = $(BASH) $(src)/genimage.sh $2 $3 $(obj)/bzImage \
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
$(obj)/mtools.conf '$(FDARGS)' $(FDINITRD)
|
2017-11-06 11:32:56 +08:00
|
|
|
|
2021-07-29 23:00:23 +09:00
|
|
|
PHONY += bzdisk fdimage fdimage144 fdimage288 hdimage isoimage
|
2020-02-15 15:38:52 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
# This requires write access to /dev/fd0
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
# All images require syslinux to be installed; hdimage also requires
|
|
|
|
# EDK2/OVMF if the kernel is compiled with the EFI stub.
|
|
|
|
bzdisk: $(imgdeps)
|
2017-11-06 11:32:56 +08:00
|
|
|
$(call cmd,genimage,bzdisk,/dev/fd0)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
fdimage fdimage144: $(imgdeps)
|
2017-11-06 11:32:56 +08:00
|
|
|
$(call cmd,genimage,fdimage144,$(obj)/fdimage)
|
|
|
|
@$(kecho) 'Kernel: $(obj)/fdimage is ready'
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
fdimage288: $(imgdeps)
|
2017-11-06 11:32:56 +08:00
|
|
|
$(call cmd,genimage,fdimage288,$(obj)/fdimage)
|
|
|
|
@$(kecho) 'Kernel: $(obj)/fdimage is ready'
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86/boot: Modernize genimage script; hdimage+EFI support
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted by either BIOS or
EFI (if the kernel is compiled with the EFI stub.) For EFI to be able
to pass the command line to the kernel, we need the EFI shell, but the
firmware builtin EFI shell, if it even exists, is pretty much always
the last resort boot option, so search for OVMF or EDK2 and explicitly
include a copy of the EFI shell.
To make this all work, use bash features in the script. Furthermore,
this version of the script makes use of some mtools features,
especially mpartition, that might not exist in very old version of
mtools, but given all the other dependencies on this script this
doesn't seem such a big deal.
Finally, put a volume label ("LINUX_BOOT") on all generated images.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210510082840.628372-1-hpa@zytor.com
2021-05-10 01:28:40 -07:00
|
|
|
hdimage: $(imgdeps)
|
|
|
|
$(call cmd,genimage,hdimage,$(obj)/hdimage)
|
|
|
|
@$(kecho) 'Kernel: $(obj)/hdimage is ready'
|
|
|
|
|
|
|
|
isoimage: $(imgdeps)
|
2017-11-06 11:32:56 +08:00
|
|
|
$(call cmd,genimage,isoimage,$(obj)/image.iso)
|
|
|
|
@$(kecho) 'Kernel: $(obj)/image.iso is ready'
|