** Description changed: In live-build/ubuntu-cpc/hooks.d/base/disk-image-uefi-non-cloud.binary we currently write file /etc/flash-kernel/machine to control which device-tree is copied to /boot and in subsequently to generate a devicetree command in grub.cfg. - So + So We have only one image for the VisionFive 2 board but there are two revisions (1.2A, 1.3B) which require different device-trees. Instead of writing /etc/flash-kernel/machine, all device-trees of the current kernel could be copied to /boot/efi/dts/. U-Boot will then search this directory for a file called $filename and load it. Whenever the kernel will be updated, flash-kernel will copy the updated device- tree to /boot and GRUB will pick it up. [ Impact ] * This lets us build more generic images [ Test Plan ] - * After creating risc-v images with the proposed solution, it can be - checked that all the device trees are in /boot/dtbs, that the kernel is - correctly exposing the machine from the firmware provided device tree in - /proc/device-tree/model, and that grub.cfg has no device tree entry yet. - It can be then checked that after a kernel update the file - /boot/dtb-$kernel_version is created and a device tree entry is created - by update-grub. + * After creating risc-v images with the proposed solution, the test plan + is to check that on first boot all the device trees are in /boot/dtbs, + the kernel is correctly exposing the machine from the firmware-provided + device tree in /proc/device-tree, and grub.cfg has no device tree entry + yet. It is then necessary to check that kernel updates work correctly + with the proposed solution: that is, that after a kernel update the file + /boot/dtb-$kernel_version is created and picked up by update-grub, which + in turn creates a devicetree entry for the subsequent boots.
** Description changed: In live-build/ubuntu-cpc/hooks.d/base/disk-image-uefi-non-cloud.binary we currently write file /etc/flash-kernel/machine to control which device-tree is copied to /boot and in subsequently to generate a devicetree command in grub.cfg. So We have only one image for the VisionFive 2 board but there are two revisions (1.2A, 1.3B) which require different device-trees. Instead of writing /etc/flash-kernel/machine, all device-trees of the current kernel could be copied to /boot/efi/dts/. U-Boot will then search this directory for a file called $filename and load it. Whenever the kernel will be updated, flash-kernel will copy the updated device- tree to /boot and GRUB will pick it up. [ Impact ] * This lets us build more generic images [ Test Plan ] * After creating risc-v images with the proposed solution, the test plan is to check that on first boot all the device trees are in /boot/dtbs, the kernel is correctly exposing the machine from the firmware-provided device tree in /proc/device-tree, and grub.cfg has no device tree entry yet. It is then necessary to check that kernel updates work correctly with the proposed solution: that is, that after a kernel update the file - /boot/dtb-$kernel_version is created and picked up by update-grub, which - in turn creates a devicetree entry for the subsequent boots. + /boot/dtb-$kernel_version is created and picked up by update-grub, and + that update-grub in turn creates a devicetree entry for the subsequent + boots pointing to /boot/dtb-$kernel_version. ** Description changed: In live-build/ubuntu-cpc/hooks.d/base/disk-image-uefi-non-cloud.binary we currently write file /etc/flash-kernel/machine to control which device-tree is copied to /boot and in subsequently to generate a devicetree command in grub.cfg. So We have only one image for the VisionFive 2 board but there are two revisions (1.2A, 1.3B) which require different device-trees. Instead of writing /etc/flash-kernel/machine, all device-trees of the current kernel could be copied to /boot/efi/dts/. U-Boot will then search this directory for a file called $filename and load it. Whenever the kernel will be updated, flash-kernel will copy the updated device- tree to /boot and GRUB will pick it up. [ Impact ] * This lets us build more generic images [ Test Plan ] * After creating risc-v images with the proposed solution, the test plan is to check that on first boot all the device trees are in /boot/dtbs, the kernel is correctly exposing the machine from the firmware-provided device tree in /proc/device-tree, and grub.cfg has no device tree entry yet. It is then necessary to check that kernel updates work correctly - with the proposed solution: that is, that after a kernel update the file - /boot/dtb-$kernel_version is created and picked up by update-grub, and - that update-grub in turn creates a devicetree entry for the subsequent - boots pointing to /boot/dtb-$kernel_version. + with the proposed solution: that is, that after a kernel update the + script /etc/kernel/postinst.d/zz-flash-kernel creates the file + /boot/dtb-$kernel_version, and that this file is picked up by update- + grub to create a devicetree entry for the subsequent boots pointing to + /boot/dtb-$kernel_version. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2092205 Title: Using /etc/flash-kernel/machine in risc-v images does not permit building generic images To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2092205/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
