# Bad Linux ARM64 Image magic! **URL:** \ **Category:** General Discussions\ **Tags:** zeus\ **Created:** [May 6, 2021, 7:41am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604 "2021-05-06T07:41:40Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ABTP](https://avatars.discourse-cdn.com/v4/letter/a/58f4c7/32.png) [@ABTP](https://hub.mender.io/u/ABTP)\ **Post date:** [May 6, 2021, 7:41am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/1 "2021-05-06T07:41:40Z")
Hi dear community members, I have been trying to integrate Mender with a Variscite VAR-SOM-MX8M-MINI running Boot2Qt-Zeus based on : Yocto: Poky 3.0, BSP: NXP L5.4.3-1.0.0, Linux: lf-5.4.y Before trying to integrate Mender, I was able to produce a bootable Boot2Qt image. Then, I added meta-mender-community and meta-mender layers both from the Zeus branches and followed the regular integration approach (updating local.conf and bblayers.conf for sdcard image). After tweeking local.conf variables a bit, I managed to get the image to successfully build. However, after flashing it into an SDCard, u-boot is not able to load the kernel. Here is the serial output: > ``` > U-Boot SPL 2019.04-lf-5.4.y_v2019.04_var01+gbcdb05a53e (Apr 28 2021 - 08:00:24 +0000) > Normal Boot > Trying to boot from MMC1 > > U-Boot 2019.04-lf-5.4.y_v2019.04_var01+gbcdb05a53e (Apr 28 2021 - 08:00:24 +0000) > > CPU: Freescale i.MX8MMQ rev1.0 1800 MHz (running at 1200 MHz) > CPU: Commercial temperature grade (0C to 95C) at 45C > Reset cause: POR > Model: Variscite VAR-SOM-MX8M-MINI > DRAM: 2 GiB > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC… OK > In: serial > Out: serial > Err: serial > > BuildInfo: > > ATF 7b3389d > U-Boot 2019.04-lf-5.4.y_v2019.04_var01+gbcdb05a53e > > Part number: VSM-MX8MM-101 > Assembly: AS2002150192 > Production date: 2020 Apr 06 > Serial Number: f8:dc:7a:3e:81:ba > flash target is MMC:1 > Net: eth0: ethernet@30be0000 > Fastboot: Normal > Normal Boot > Hit any key to stop autoboot: 0 > Bad Linux ARM64 Image magic! > > ``` printenv: > ``` > u-boot=> printenv > altbootcmd=run mender_altbootcmd; run bootcmd > arch=arm > baudrate=115200 > board=imx8mm_var_dart > board_name=VAR-SOM-MX8M-MINI > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} > boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi > boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf} > boot_net_usb_start=usb start > boot_prefixes=/ /boot/ > boot_script_dhcp=boot.scr.uimg > boot_scripts=boot.scr.uimg boot.scr > boot_syslinux_conf=extlinux/extlinux.conf > boot_targets=mmc2 mmc1 > bootargs=root=/dev/mmcblk1p1 > bootcmd=run mender_setup; setenv bootargs root=${mender_kernel_root} ${bootargs}; if test “${fdt_addr_r}” != “”; then load ${mender_uboot_root} ${fdt_addr_r} /boot/${mender_dtb_name}; fi; load ${mender_uboot_root} ${kernel_addr_r} /boot/${mender_kernel_name}; ${mender_boot_kernel_type} ${kernel_addr_r} - ${fdt_addr_r}; run mender_try_to_recover > bootcmd_mfg=run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo “Run fastboot …”; fastboot 0; fi; > bootcmd_mmc1=devnum=1; run mmc_boot > bootcmd_mmc2=devnum=2; run mmc_boot > bootcount=1 > bootdelay=1 > bootdir=/boot > bootlimit=1 > cma_size=cma=640M@1376M > console=ttymxc3,115200 earlycon=ec_imx6q,0x30a60000,115200 > cpu=armv8 > distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done > efi_dtb_prefixes=/ /dtb/ /dtb/current/ > emmc_dev=1 > ethaddr=f8:dc:7a:3e:81:ba > ethprime=FEC > fastboot_dev=mmc1 > fdt_addr_r=0x43000000 > fdt_high=0xffffffffffffffff > fdtcontroladdr=b6d2d7c0 > fdtfile=imx8mm-var-som.dtb > findfdt=if test $fdtfile = undefined; then if test $board_name = VAR-SOM-MX8M-MINI; then if test $som_rev = som_rev10; then setenv fdtfile imx8mm-var-som-rev10.dtb; else setenv fdtfile imx8mm-var-som.dtb; fi;else setenv fdtfile imx8mm-var-dart.dtb;fi; fi; > image=Image.gz > img_addr=0x42000000 > initrd_addr=0x43800000 > initrd_high=0xffffffffffffffff > kboot=booti > kernel_addr_r=0x40480000 > load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} > loadaddr=0x40480000 > loadm4bin=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootdir}/${m4_bin}; cp.b ${loadaddr} ${m4_addr} ${filesize} > m4_addr=0x7e0000 > m4_bin=hello_world.bin > mender_altbootcmd=if test ${mender_boot_part} = 1; then setenv mender_boot_part 2; setenv mender_boot_part_hex 2; else setenv mender_boot_part 1; setenv mender_boot_part_hex 1; fi; setenv upgrade_available 0; saveenv; run mender_setup > mender_boot_kernel_type=booti > mender_boot_part=1 > mender_boot_part_hex=1 > mender_boot_part_name=/dev/mmcblk1p1 > mender_check_saveenv_canary=1 > mender_kernel_name=Image > mender_kernel_root=/dev/mmcblk1p1 > mender_kernel_root_name=/dev/mmcblk1p1 > mender_pre_setup_commands= if test “${ramsize_check}” != “”; then run ramsize_check; fi; if test “${mmcargs}” != “”; then run mmcargs; fi; if test “${videoargs}” != “”; then run videoargs; fi; if test “${optargs}” != “”; then run optargs; fi; run findfdt; setenv mender_dtb_name ${fdt_file}; setenv kernel_addr_r ${loadaddr}; > mender_saveenv_canary=1 > mender_setup=if test “${mender_saveenv_canary}” != “1”; then setenv mender_saveenv_canary 1; saveenv; fi; if test “${mender_pre_setup_commands}” != “”; then run mender_pre_setup_commands; fi; if test “${mender_systemd_machine_id}” != “”; then setenv bootargs “systemd.machine_id=${mender_systemd_machine_id} ${bootargs}”; fi; setenv mender_kernel_root /dev/mmcblk1p${mender_boot_part}; if test ${mender_boot_part} = 1; then setenv mender_boot_part_name /dev/mmcblk1p1; else setenv mender_boot_part_name /dev/mmcblk1p2; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root mmc 0:${mender_boot_part_hex}; setenv mender_uboot_root_name ${mender_boot_part_name}; setenv expand_bootargs “setenv bootargs \”${bootargs}\""; run expand_bootargs; setenv expand_bootargs; if test “${mender_post_setup_commands}” != “”; then run mender_post_setup_commands; fi > mender_try_to_recover=if test ${upgrade_available} = 1; then reset; fi > mender_uboot_boot=mmc 0:1 > mender_uboot_dev=0 > mender_uboot_if=mmc > mender_uboot_root=mmc 0:1 > mender_uboot_root_name=/dev/mmcblk1p1 > mfgtool_args=setenv bootargs console=${console},${baudrate} rdinit=/linuxrc clk_ignore_unused > mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi > mmcdev=0 > mmcpart=1 > ramsize_check=if test $sdram_size -le 512; then setenv cma_size cma=320M; else setenv cma_size cma=640M@1376M; fi; > runm4bin=if test ${m4_addr} = 0x7e0000; then echo Booting M4 from TCM; else echo Booting M4 from DRAM; dcache flush; fi; bootaux ${m4_addr}; > scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}…; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi; > scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist > scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing…; fi; setenv efi_fdtfile > scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing…; fi > scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing…; fi; done > script=boot.scr > sd_dev=0 > sdram_size=2048 > serial#=220c1a09dab4b749 > soc=imx8m > soc_type=imx8mm > som_rev=som_rev11 > stderr=serial > stdin=serial > stdout=serial > upgrade_available=0 > usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi > use_m4=no > vendor=variscite > > Environment size: 6623/131067 bytes > > ``` local.conf: (mender section only) > MENDER\_ARTIFACT\_NAME = “release-1” > INHERIT += “mender-full” > DISTRO\_FEATURES\_append = " systemd" > VIRTUAL-RUNTIME\_init\_manager = “systemd” > DISTRO\_FEATURES\_BACKFILL\_CONSIDERED = “sysvinit” > VIRTUAL-RUNTIME\_initscripts = “” > > MENDER\_IMAGE\_BOOTLOADER\_FILE\_imx6ul-var-dart = “u-boot-spl.img” > MENDER\_IMAGE\_BOOTLOADER\_BOOTSECTOR\_OFFSET\_imx6ul-var-dart = “2” > > MENDER\_IMAGE\_BOOTLOADER\_FILE\_imx8mm-var-dart = “imx-boot-imx8mm-var-dart-sd.bin” > MENDER\_IMAGE\_BOOTLOADER\_BOOTSECTOR\_OFFSET\_imx8mm-var-dart = “66” > > MENDER\_IMAGE\_BOOTLOADER\_FILE\_imx8mn-var-som = “imx-boot” > MENDER\_IMAGE\_BOOTLOADER\_BOOTSECTOR\_OFFSET\_imx8mn-var-som = “64” > do\_image\_sdimg[depends] += “${@bb.utils.contains(‘MACHINE’, ‘imx8mn-var-som’, ‘imx-boot:do\_deploy’, ‘’, d)}” > > MENDER\_BOOT\_PART\_SIZE\_MB\_imx6ul-var-dart = “16” > IMAGE\_BOOT\_FILES\_remove\_imx6ul-var-dart = “${KERNEL\_IMAGETYPE} ${KERNEL\_DEVICETREE}” > > MENDER\_BOOT\_PART\_SIZE\_MB\_imx8mm-var-dart = “16” > IMAGE\_BOOT\_FILES\_remove\_imx8mm-var-dart = “${KERNEL\_IMAGETYPE} ${@make\_dtb\_boot\_files(d)}” > > MENDER\_BOOT\_PART\_SIZE\_MB\_imx8mn-var-som = “16” > IMAGE\_BOOT\_FILES\_remove\_imx8mn-var-som = “${KERNEL\_IMAGETYPE} ${@make\_dtb\_boot\_files(d)}” > > IMAGE\_FSTYPES\_remove = “tar.gz ext4 wic.gz wic.bmap multiubi mender.bmap wic sdcard” > > MENDER\_FEATURES\_ENABLE\_append = " mender-image-sd mender-uboot" > MENDER\_FEATURES\_DISABLE\_append = " mender-image-uefi mender-grub" > > MACHINE\_EXTRA\_RDEPENDS\_append= " u-boot-fw-utils" > VARISCITE\_UBOOT\_ENV\_IN\_EMMC = “0” > > MENDER\_STORAGE\_DEVICE\_imx6ul-var-dart = “/dev/mmcblk0” > MENDER\_UBOOT\_STORAGE\_DEVICE\_imx6ul-var-dart = “0” > UBOOT\_CONFIG\_imx6ul-var-dart = “sd” > > MENDER\_STORAGE\_DEVICE\_imx8mm-var-dart = “/dev/mmcblk1” > MENDER\_UBOOT\_STORAGE\_DEVICE\_imx8mm-var-dart = “0” > UBOOT\_CONFIG\_imx8mm-var-dart = “sd” > > MENDER\_STORAGE\_DEVICE\_imx8mn-var-som = “/dev/mmcblk1” > MENDER\_UBOOT\_STORAGE\_DEVICE\_imx8mn-var-som = “1” > UBOOT\_CONFIG\_imx8mm-var-dart = “sd” > > MENDER\_BOOT\_PART\_SIZE\_MB\_mender-uboot = “0” > MENDER\_KERNEL\_IMAGETYPE= “Image” > > MENDER\_STORAGE\_TOTAL\_SIZE\_MB\_imx8mm-var-dart = “6144” > IMAGE\_POSTPROCESS\_COMMAND\_remove = “do\_qbsp\_image;” After going though posts from people facing similar error: [https://hub.mender.io/t/issue-with-variscite-var-som-mx8m-nano/2840/11](https://hub.mender.io/t/issue-with-variscite-var-som-mx8m-nano/2840/11) [https://hub.mender.io/t/variscite-var-dart-imx8mm-problem/2811](https://hub.mender.io/t/variscite-var-dart-imx8mm-problem/2811) I made a couple of changes to the local.conf according to those posts, but I am still getting the same error message. The only thing that succeeded in loading the kernel was to enable grub: > MENDER\_FEATURES\_ENABLE\_append = " mender-image-sd mender-grub" > MENDER\_FEATURES\_DISABLE\_append = " mender-image-uefi" This results in u-boot loading Grub then Grub loading the kernel, so somwhere Grub is able to load the kernel but u-boot is not able. I do not want this behavious, as I want u-boot to load the kernel. Does anyone have an idea how I can solve this " Bad Linux ARM64 Image magic! " issue? I really appreciate any kind of help. Thank you 🙂 ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [May 10, 2021, 6:46am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/2 "2021-05-10T06:46:25Z")
Probably it requires a custom board integration for U-Boot. But if it works, why do you not wish to use Grub? ---
**Author:** ![ABTP](https://avatars.discourse-cdn.com/v4/letter/a/58f4c7/32.png) [@ABTP](https://hub.mender.io/u/ABTP)\ **Post date:** [May 10, 2021, 12:37pm UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/3 "2021-05-10T12:37:23Z")
> [@ABTP](#): > > `Bad Linux ARM64 Image magic!` Hi Thanks for the reply 🙂 Why do you think it needs a custom board integration for U-Boot? Mender should have been integrated for this board running Zeus according to: [https://hub.mender.io/t/variscite-var-som-mx8m-mini-nxp-i-mx-8m-mini/1918](https://hub.mender.io/t/variscite-var-som-mx8m-mini-nxp-i-mx-8m-mini/1918) and this board uses U-boot, so I am assuming it should work without customization…but in case customization is needed, can you please point me in the right direction? When I build u-boot, I was receiving this Warning message when applying patches: > WARNING: u-boot-variscite-1.0-r0 do\_patch: Fuzz detected: > > Applying patch 0003-Integration-of-Mender-boot-code-into-U-Boot.patch > patching file include/env\_default.h > Hunk #1 succeeded at 9 with fuzz 2. could this be the cause? The reason why I want u-boot to load the kernel is because firstly it takes forever to boot (around 2 minutes to see the boo2qt demo), and secondly there is a problem with executing reboot commands for some reason. When I was trying the check the mender integration list, the board freezes after issuing a reboot command…something is not right there. ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [May 11, 2021, 7:34am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/4 "2021-05-11T07:34:05Z")
Right, the page does not mention that you have to disable Grub, that’s why I assumed they integrated with it, and not U-Boot. Unfortunately I don’t have a lot to contribute beyond what Drew already said, and I don’t have a board to test with. If you are set on U-Boot you will have to start experimenting with boot commands. But since Grub already works, maybe it’s possible to solve your problems: 1. Which part of the boot process is taking so long? 2. Is it possible to reboot using this command (as root)? ```auto echo b > /proc/sysrq-trigger ``` ---
**Author:** ![ABTP](https://avatars.discourse-cdn.com/v4/letter/a/58f4c7/32.png) [@ABTP](https://hub.mender.io/u/ABTP)\ **Post date:** [May 12, 2021, 8:24am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/5 "2021-05-12T08:24:47Z")
Hi Kristian Regarding the problems with Grub, the command you suggested does not work. When used, the board just freezes the same as when using the reboot command. As for the which part of the boot process is taking long, I tried to visualize it using > systemd-analyze plot \> plot.svg but I get this message: > Failed to get timestamp properties: Connection timed out I am not sure what else I can do? any suggestions please? ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [May 12, 2021, 9:15am UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/6 "2021-05-12T09:15:38Z")
Ok, unfortunately the freeze confirms that the problem is on the kernel level, which may indeed be related to the bootloader mechanics. Debugging at that level is beyond my skill set, but I have one last thing you can try: Both Grub and the kernel are using UEFI services which are provided by U-Boot (it acts as a UEFI provider), and I know there has been a lot of fixes in this area in recent years. Is it possible for you to try a more recent version of U-Boot? Let’s ignore the other problem for now, it’s possible it’s related to the same issue if there are instabilities at the kernel level. If we can’t solve that problem, then the boot delay is a moot point anyway. ---
**Author:** ![ABTP](https://avatars.discourse-cdn.com/v4/letter/a/58f4c7/32.png) [@ABTP](https://hub.mender.io/u/ABTP)\ **Post date:** [May 12, 2021, 2:22pm UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/7 "2021-05-12T14:22:50Z")
That is unfortunate if that’s the case. As for trying a newer version of u-boot, I have considered doing that before but I was worried of the complication, but I will try it and see…I guess I will have to use different Mender patches to get it to work,right? ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [May 12, 2021, 3:01pm UTC](https://hub.mender.io/t/bad-linux-arm64-image-magic/3604/8 "2021-05-12T15:01:35Z")
When using U-Boot with UEFI and Grub, you don’t need any patches, only an updated recipe. But upgrading U-Boot may also solve the `ARM64 Image magic` problem, so I encourage you to try both configurations: One with `mender-grub` turned on, and one with `mender-uboot` turned on. For `mender-uboot` you will indeed need patches, but sometimes the existing ones keep working even when upgrading; it’s hard to say in advance.