I just tested with bitbake mender-artifact-native and that at least passed on my end.
.config will not be available in configure_prepend as it is generated during configure
Just did another clean run and had the same issue so I edited the mender-artifact_3.2.0.bb file and uncommented DEFAULT_PREFERENCE = “-1” which I assume forces it to use the 3.1.0 version instead and that worked. It’s strange that you can compile it and I can’t.
I swear this thing doesn’t like me…
I’ve taken a look in the kernel and u-boot and both FAT and ext4 are enabled. I can explore the partitions in u-boot.
[ 2.952704] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6
[ 2.960505] Please append a correct "root=" boot option; here are the available partitions:
[ 2.968893] 1f00 4096 mtdblock0
[ 2.968894] (driver?)
[ 2.975453] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.983743] CPU1: stopping
[ 2.986461] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.1.21-yocto-standard #1
[ 2.993703] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 2.999652] [<c0111aac>] (unwind_backtrace) from [<c010ca68>] (show_stack+0x10/0x14)
[ 3.007424] [<c010ca68>] (show_stack) from [<c0869a64>] (dump_stack+0x88/0x9c)
[ 3.014671] [<c0869a64>] (dump_stack) from [<c0110778>] (handle_IPI+0x34c/0x384)
[ 3.022092] [<c0110778>] (handle_IPI) from [<c0408d5c>] (gic_handle_irq+0x8c/0x90)
[ 3.029687] [<c0408d5c>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0x90)
[ 3.037190] Exception stack(0xef0cff60 to 0xef0cffa8)
[ 3.042257] ff60: 00000000 0001a924 ef7e2ea0 c011a820 ffffe000 c0c07c70 c0c07cac 00000002
[ 3.050459] ff80: c0b7dac0 c0c7bcc6 00000000 00000000 00000000 ef0cffb0 c0109190 c0109194
[ 3.058658] ffa0: 60000013 ffffffff
[ 3.062160] [<c0101a8c>] (__irq_svc) from [<c0109194>] (arch_cpu_idle+0x38/0x3c)
[ 3.069582] [<c0109194>] (arch_cpu_idle) from [<c014f7b8>] (do_idle+0x1c4/0x244)
[ 3.077001] [<c014f7b8>] (do_idle) from [<c014fae0>] (cpu_startup_entry+0x18/0x20)
[ 3.084594] [<c014fae0>] (cpu_startup_entry) from [<001025ac>] (0x1025ac)
[ 3.091405] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
I’m so close…
Hmm interesting, it seems the bootargs didn’t append rw rootwait and the dtb file didn’t have the patch for emmc to skip the sd card empty pin.
Not sure where the configuration is to set bootargs but I can fix the emmc pin issue.
Progress!
One last question, with regards to boot.cmd.in
From what I can tell using the u-boot auto patcher it doesn’t use boot.scr but instead directly sets bootcmd with everything required.
Is there an easy way to change it to use boot.scr? Last thing stopping me from booting (still haven’t fixed the compile issue for the full release).
I do not think there is an easy way to force the auto patcher to use boot.scr. Instead one would need to disable the auto patching and do it “manually”
Time goes quick. Anyway, following up, you’re right in that boot.scr isn’t used so for the moment I’ve been manually changing the bootcmd to get it working. That said it would be nice if the auto patcher had an extra variable that could be set before bootz ${kernel_addr_r} - ${fdt_addr_r} so that patches can be done to the loaded dtb file before booting.
When I was looking at this back in November, I had a plan but having worked on other things I’m not sure where to do the change.
I’m still a little busy to go looking through the mender code to add this change but if it went through I will find the time to finish off the clearfog-pro layer.
Still haven’t found time to look at this issue but I thought I’d throw in a quick note for people who want to use mender with an eMMC board.
At the end of the Known Issues there’s a code snippet that can be run to patch the SD-Card slot detection.
Hopefully I’ll get a chance soon to look at it and fix the layer.
1 Like