On 2023-04-30, Roger Shimizu wrote: > I'm trying to support an ARM based RB3 / DB845c [1] dev-board with > android-style boot image to flash-kernel. ... > My question is: > - Currently flash-kernel is mainly u-boot based, is it proper to add > "mkbootimg" based devices? My main worry here is investing too much in flash-kernel, rather than replacing it... both require possibly significant effort, and I wonder if that effort would not be better spent writing a more modular replacement for flash-kernel? That said, I have not mustered the energy to do this myself... To some degree, I have been the de-facto maintainer for flash-kernel, but I am hesitant to make significant changes to it... it is not easy code to read... > - Does mkbootimg need to support udeb in order to support D-I for this > dev-board in the future? I *think* that the udeb (indirectly?) calls flash-kernel inside the chroot... so I am not sure that would be necessary. There's no "u-boot-tools" udeb, and many boards use mkimage from "u-boot-tools". > gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz > cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > Image > mkbootimg \ > --kernel Image \ > --ramdisk /boot/initrd.img-6.1.0-8-arm64 \ > --output boot.img \ > --pagesize "4096" \ > --base "0x80000000" \ > --kernel_offset "0x8000" \ > --ramdisk_offset "0x1000000" \ > --tags_offset "0x100" \ > --cmdline "root=PARTLABEL=rootfs console=tty0 > console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused" That seems "simple" enough, given you're using a Debian packaged kernel and all. Not so different from the mkimage-style support for u-boot. It is a frustrating that there are so many ways to boot arm systems... but that is the reality out there actually implemented in hardware... live well, vagrant
Attachment:
signature.asc
Description: PGP signature