Bug#979548: u-boot: Package Xen build
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote: > On 2021-01-07, Elliott Mitchell wrote: > > Might it be possible to get a u-boot-xen-arm64 package built? While > > "PyGRUB" is great for Linux, it isn't so good for booting other OSes. > > Do you mean: > > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/board/xen/xenguest_arm64.rst > > This doesn't describe how to use it or, importantly, what files we would > need to ship in the package. If you could help clarify that (possibly > provide a patch), and ideally get it clarified in the upstream > documentation, then I would think we would be able to ship such a > package. Appears the build issue wasn't libfdt-dev, but instead `dwz` and `debhelper`. I suspect libfdt-dev:any or libfdt-dev may now be sufficient for building (I'm not 100% sure since I have a workaround in place). Anyway I now have something which looks like a first pass at having U-Boot/ARM boot a Xen VM. Some progress has been made, but it I haven't confirmed full operation yet. The build was achieved by copying configs/xenguest_arm64_defconfig over qemu_arm64_defconfig and then cross-building for arm64. This suggests extra steps for "qemu" are also appropriate for "xenguest". Once complete, the file ./usr/lib/u-boot/qemu_arm64/u-boot.bin was copied to the host machine. A configuration file was created for xl, the value for "kernel" was pointed at the u-boot.bin file, both "bootloader" and "ramdisk" options were left unset. Upon attempt to boot this VM (`xl create -c u-boot.cfg`) I ended up at a prompt "xenguest# ". The command-line appeared to act how I would expect U-Boot to act, so I conclude U-Boot had successfully loaded. The next task is to get the OS I wish to run in the VM loaded by U-Boot. As of 2020.10+dfsg-2, appears the "xenguest" defconfig disables all EFI/GPT support. I must recommend the U-Boot maintainers advise upstream to set CONFIG_EFI_LOADER=y and CONFIG_CMD_PART=y in the Xen defconfig. While some smaller VMs may not need EFI support, it appears to be gaining traction everywhere with ARM64. I note SuSE uses it as an intermediate stage between U-Boot and GRUB. FreeBSD's ARM64 VM images appear to *assume* EFI is in use. I haven't gotten U-Boot/Xen to successfully load FreeBSD's bootloader yet, but progress is being made. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#979548: u-boot: Package Xen build
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote: > This doesn't describe how to use it or, importantly, what files we would > need to ship in the package. If you could help clarify that (possibly > provide a patch), and ideally get it clarified in the upstream > documentation, then I would think we would be able to ship such a > package. I think 2 or 3 files would be useful to ship in such a package. First would be "u-boot.bin" or whatever the output filename is. Second might be a README mentioning the 3 values needing to be set in a domu.cfg file. Third might be a /etc/xen/xlexample.u-boot file. The 3 values which need to be set in the domain configuration file are: kernel = "/usr/lib/u-boot/xen/u-boot.bin" # ramdisk = # extra = Mainly the "ramdisk" and "extra" settings should be left unset, while "kernel" points at the U-Boot image. A /etc/xen/xlexample.u-boot would be a copy of Xen's /etc/xen/xlexample.pvlinux with the 3 values set appropriately. Then https://wiki.debian.org/Xen should be adjusted to mention U-Boot being available to boot user domains for Xen. In fact I'm trying to find out whether Xen/U-Boot can load OSes besides Linux. Note, this is presently theory as src:u-boot has a problematic set of package requirements. Presently libfdt-dev doesn't allow installation of multiple architecture versions. My build VM is setup to target Xen which needs the host package, while the u-boot build needs the build package. Grr! -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#979548: u-boot: Package Xen build
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote: > On 2021-01-07, Elliott Mitchell wrote: > > Might it be possible to get a u-boot-xen-arm64 package built? While > > "PyGRUB" is great for Linux, it isn't so good for booting other OSes. > > Do you mean: > > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/board/xen/xenguest_arm64.rst > > This doesn't describe how to use it or, importantly, what files we would > need to ship in the package. If you could help clarify that (possibly > provide a patch), and ideally get it clarified in the upstream > documentation, then I would think we would be able to ship such a > package. I'm less than 100% sure myself. :-) Most likely you simply configure xenguest_arm64_defconfig, build the configuration and the package would be the copyright plus one output file. In order to use this you setup a VM/domain configuration file where the single output file is specified as the "kernel" parameter. This would cause the U-Boot image to be loaded as if it was an OS kernel and be loaded into the resultant VM and started. Then in theory U-Boot loads configuration parameters from VM disk devices as it normally would. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#979548: u-boot: Package Xen build
Control: tags 979548 moreinfo On 2021-01-07, Elliott Mitchell wrote: > Might it be possible to get a u-boot-xen-arm64 package built? While > "PyGRUB" is great for Linux, it isn't so good for booting other OSes. Do you mean: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/board/xen/xenguest_arm64.rst This doesn't describe how to use it or, importantly, what files we would need to ship in the package. If you could help clarify that (possibly provide a patch), and ideally get it clarified in the upstream documentation, then I would think we would be able to ship such a package. live well, vagrant signature.asc Description: PGP signature
