Now ACRN supports direct boot mode, which could be SBL/ABL, or GRUB boot.
Thus the vboot wrapper layer can be removed and the direct boot functions
don't need to be wrapped in direct_boot.c:
- remove call to init_vboot(), and call e820_alloc_memory() directly at the
time when the trampoline buffer is actually needed.
- Similarly, call CPU_IRQ_ENABLE() instead of the wrapper init_vboot_irq().
- remove get_ap_trampoline_buf(), since the existing function
get_trampoline_start16_paddr() returns the exact same value.
- merge init_general_vm_boot_info() into init_vm_boot_info().
- remove vm_sw_loader pointer, and call direct_boot_sw_loader() directly.
- move get_rsdp_ptr() from vboot_wrapper.c to multiboot.c, and remove the
wrapper over two boot modes.
Tracked-On: #5197
Signed-off-by: Zide Chen <zide.chen@intel.com>
The acrn_mbi.mi_mmap_va should point to struct multiboot2_mmap_entry when
boot from multiboot2, which is different from struct multiboot_mmap when
boot from multiboot1. So we should handle mmap info separately for multiboot2.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Previously the VM kernel bootargs for pre-launched VMs and direct boot mode
of SOS VM are built-in hypervisor binary so end users have no way to change
it. Now we provide another option that the multiboot module string could be
used as bootargs also. This would bring convenience to end users when they
use GRUB as bootloader because the bootargs could be configurable in GRUB
menu.
The usage is if there is any string follows configured kernel_mod_tag in
module string, the string will be used as new kernel bootargs instead of
built-in kernel bootargs. If there is no string follows kernel_mod_tag,
then the built-in bootargs will be the default kernel bootargs.
Please note kernel_mod_tag must be the first word in module string in any
case, it is used to specify the module for which VM.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
The multiboot2 cmdline would be used as hypervisor cmdline, add parse logic
for the case that hypervisor boot from multiboot2 protocol.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Previously sanitize_multiboot_info() was called after init_debug_pre() because
the debug message can only print after uart is initialized. On the other hand,
multiboot cmdline need to be parsed before init_debug_pre() because the cmdline
could override uart settings and make sure debug message printed successfully.
This cause multiboot info was parsed in two stages.
The patch revise the multiboot parse logic that split sanitize_multiboot_info()
api and use init_acrn_multiboot_info() api for the early stage. The most of
multiboot info will be initialized during this stage and no debug message need
to be printed. After uart is initialized, the sanitize_multiboot_info() would
do sanitize multiboot info and print needed debug messages.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- need to specify the load_addr in the multiboot2 address tag. GRUB needs
it to correctly calculate the ACRN binary's load size if load_end_addr is
a non-zero value.
- multiboot2 can be enabled if hypervisor relocation is disabled.
- print the name of the boot loader. This might be helpful if the boot
loader, e.g. GRUB, inludes its version in the name string.
Tracked-On: #4441
Signed-off-by: Victor Sun <victor.sun@intel.com>
Signed-off-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Initialize mmap info of acrn mbi when boot from multiboot2 protocol,
with this patch acrn hv could boot from multiboot2;
Tracked-On: #4419
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Initialize and sanitize a acrn specific multiboot info struct with current
supported multiboot1 in very early boot stage, which would bring below
benifits:
- don't need to do hpa2hva convention every time when refering boot_regs;
- panic early if failed to sanitize multiboot info, so that don't need to
check multiboot info pointer/flags and panic in later boot process;
- keep most code unchanged when introduce multiboot2 support in future;
Tracked-On: #4419
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
boot/multiboot.c is only used by SBL. So move it to boot/sbl.
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <Eddie.dong@intel.com>
According to the explaination for pref_address
in Documentation/x86/boot.txt, a relocating bootloader
should attempt to load kernel at pref_address if possible.
But due to a non-relocatable kernel will unconditionally
move itself and to run at perf address, no need to copy
kernel to perf_address by bootloader.
Signed-off-by: Zheng, Gen <gen.zheng@intel.com>
1. refine multiboot related code, move to /boot.
2. firmware files and ramdisk can be stitched in iasImage;
and they will be loaded as multiboot modules.
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
