arch/x86: Correct multiboot interpretation when building for EFI
When loaded via EFI, we obviously don't have a multiboot info pointer available (we might have an EFI system table, but zefi doesn't pass that through yet). Don't try to parse the "whatever garbage was in %rbp" as a multiboot table. The configuration is a little clumsy, as strictly our EFI kconfig just says we're "building for" EFI but not that we'll boot that way. And tests like arch/x86/info are trying to set CONFIG_MULTIBOOT=n unconditionally, when it really should be something they detect from devicetree or wherever. Fixes #33545 Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit is contained in:
parent
653e7a28ea
commit
41e885947e
4 changed files with 8 additions and 2 deletions
|
@ -39,7 +39,7 @@ FUNC_NORETURN void z_x86_prep_c(void *arg)
|
|||
x86_64_irq_init();
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_MULTIBOOT_INFO
|
||||
#if defined(CONFIG_MULTIBOOT_INFO) && !defined(CONFIG_BUILD_OUTPUT_EFI)
|
||||
z_multiboot_init(info);
|
||||
#else
|
||||
ARG_UNUSED(info);
|
||||
|
|
|
@ -8,6 +8,6 @@ project(x86_info)
|
|||
|
||||
target_sources(app PRIVATE src/main.c)
|
||||
target_sources(app PRIVATE src/timer.c)
|
||||
target_sources(app PRIVATE src/memmap.c)
|
||||
target_sources_ifdef(CONFIG_ACPI app PRIVATE src/acpi.c)
|
||||
target_sources_ifdef(CONFIG_MULTIBOOT app PRIVATE src/multiboot.c)
|
||||
target_sources_ifdef(CONFIG_X86_MEMMAP app PRIVATE src/memmap.c)
|
||||
|
|
|
@ -4,3 +4,4 @@ CONFIG_MULTIBOOT_MEMMAP=y
|
|||
CONFIG_MULTIBOOT_FRAMEBUF=y
|
||||
CONFIG_COUNTER=y
|
||||
CONFIG_COUNTER_CMOS=y
|
||||
CONFIG_X86_MEMMAP=y
|
||||
|
|
|
@ -11,6 +11,11 @@ __weak void multiboot(void)
|
|||
printk("MULTIBOOT: Not supported in this build.\n\n");
|
||||
}
|
||||
|
||||
__weak void memmap(void)
|
||||
{
|
||||
printk("MEMMAP: Not supported in this build.\n\n");
|
||||
}
|
||||
|
||||
__weak void acpi(void)
|
||||
{
|
||||
printk("ACPI: Not supported in this build.\n\n");
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue