Thanks for your email… I was able to download the core-image-minimal.
Yes, microchip-headless-image is huge because it got all the bells and whistle enabled. Initial bake takes longer but once it has cached next releases are fast.
You mentioned " both kernel and device tree get installed to /boot :" - Looking at all my builds, both kernel and DTB files are in /boot but U-Boot always fails to find at91-sama7g5ek.dtb file. As mentioned in my earlier post, this dtb file at91-sama7g5ek.dtb is visible on SD card but not when U-Boot boots up. Why? I don’t know…
I will give it a try booting your core-image-minimal and see.
Think about how it would look like if u-boot always tries to load the kernel and dtb from the eMMC storage, not SD card? So to verify that, you could boot up the “old” eMMC system, add something random to /boot, like a test.txt, then boot into u-boot again. If ext4ls mmc 0:2 then shows you this test.txt, then we have always been looking at the wrong block device.
I booted up with your core-image-minimal-sama7g5ek-sd.sdimg and it worked (passed the u-boot prompt), so that checks out file at91-sama7g5ek.dtb needs to be in /boot. How did you manage to add at91-sama7g5ek.dtb file?
But it failed to initialize the partitions and dropped me in emergence mode:
[ *** ] (1 of 3) A start job is running for /dev/mmcblk0p1 (38s / 1min 30s)
[ **] (2 of 3) A start job is running for /dev/mmcblk0p4 (59s / 1min 30s)
[*** ] (3 of 3) A start job is running for…e Configured (1min 27s / no limit)
[ TIME ] Timed out waiting for device /dev/mmcblk0p1.
[DEPEND] Dependency failed for /uboot.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for File…ystem Check on /dev/mmcblk0p1.
[ TIME ] Timed out waiting for device /dev/mmcblk0p4.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for Grow File System on /data.
[DEPEND] Dependency failed for File…ystem Check on /dev/mmcblk0p4.
On the other hand, booted up with standard Linux4Sam sd-card image and filesystem looks like this:
# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
mmcblk0
|-mmcblk0p1 vfat boot F31B-E136
`-mmcblk0p2 ext4 root 1c6ef229-5144-4503-ba6c-d6aacdbd0a65
mmcblk1
|-mmcblk1p1 vfat boot 16C8-40A8
`-mmcblk1p2 ext4 root f9c1869e-5224-4725-88f1-3d7126c0775e 240.2M 62% /
# ls -lah /boot/
total 9.1M
drwxr-xr-x 2 root root 4.0K May 15 19:51 .
drwxr-xr-x 19 root root 4.0K May 15 15:15 ..
-rwxr-xr-x 1 root root 4.6M Mar 9 2018 sama7g5ek.itb
-rwxr-xr-x 1 root root 3.6K Mar 9 2018 sama7g5ek.its
-rwxr-xr-x 1 root root 1.3K Mar 9 2018 sama7g5ek_i2s0_pcm5102a.dtbo
-rwxr-xr-x 1 root root 1.4K Mar 9 2018 sama7g5ek_i2s0_proto.dtbo
-rwxr-xr-x 1 root root 4.2K Mar 9 2018 sama7g5ek_isc_imx219.dtbo
-rwxr-xr-x 1 root root 2.7K Mar 9 2018 sama7g5ek_isc_imx274.dtbo
-rwxr-xr-x 1 root root 1.4K Mar 9 2018 sama7g5ek_pdmc0.dtbo
-rwxr-xr-x 1 root root 1.8K Mar 9 2018 sama7g5ek_wilc3000.dtbo
-rw-r--r-- 1 root root 24 May 15 19:51 test.txt
lrwxrwxrwx 1 root root 38 Mar 9 2018 zImage -> zImage-5.15.68-linux4microchip-2022.10
-rw-r--r-- 1 root root 4.5M Mar 9 2018 zImage-5.15.68-linux4microchip-2022.10
I think we’re really getting closer here. So just to nail things down:
the .sdimg of Mender is meant to be put onto the SD card, and run from there.
therefore, the MENDER_STORAGE_DEVICE needs to point to the device that matches the SD card. Is this definitely /dev/mmcblk0? What is /dev/mmcblk1, then?
same area, MENDER_UBOOT_STORAGE_DEVICE needs to point to the SD card enumeraition as seen by u-boot.
You need to triple check those!
For the dtb on my image, I did a very simple build of poky + meta-atmel+ meta-mender, and their respective dependencies. Target was MACHINE = "sama7g5ek-sd" as seen here. No additional patching, just the following configuration:
Indeed we are on final stretch but this storage media is really screwing me up. I’m 99.99% sure it is /dev/mmcblk0 but got no idea where /dev/mmcblk1 coming up.
~# fdisk -l
Disk /dev/ram0: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mmcblk0: 3.64 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4796bfcd
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8 42605 42598 20.8M c W95 FAT32 (LBA)
/dev/mmcblk0p2 42608 238373 195766 95.6M 83 Linux
Disk /dev/mmcblk1: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00275678
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 8 42605 42598 20.8M c W95 FAT32 (LBA)
/dev/mmcblk1p2 42608 1731135 1688528 824.5M 83 Linux
And now I don’t know what happen to my build environment… Any image I produce with Mender it is going in loop again, like it used to do before when partition was missing p. So I’m going to setup new environment and start again and this time work with core-image-minimal-sama7g5ek-sd.
Sorry took longer then expected… So I re-setup everything and back to same problem:
Failed to load '/boot/at91-sama7g5ek.dtb'
4706176 bytes read in 295 ms (15.2 MiB/s)
Kernel image @ 0x62000000 [ 0x000000 - 0x47cf80 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
=>
I tried both methods you mentioned in your last message /dev/mmcblk1 and /dev/mmcblk0. Same issue…
Other strange problem I came across was with uboot environment. In my local.conf I am breaking the partitions:
But when uboot environment is generated, one of the partition mender_kernel_root is missing p.
mender_kernel_root=/dev/mmcblk02
mender_kernel_root_name=/dev/mmcblk0p2
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_ma
chine_id} ${bootargs}"; fi; setenv mender_kernel_root /dev/mmcblk0${mender_boot_part}; if test ${mender_boot_part} = 2; then setenv mender_boot_part_
name /dev/mmcblk0p2; else setenv mender_boot_part_name /dev/mmcblk0p3; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_ubo
ot_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
Also I was looking at meta-mender-community for Sama5 and it requires some patches for uboot. Don’t I need for Sama7 since they are similar? I don’t know I’m just swinging for a home run here… Running out of time to demo
Sad to hear indeed. Unfortunately most of the team is off for the rest of the week, especially today as its a bank holiday - and so am I - so a short notice will have to do.
correct, the SAMA5 doesn’t need an actual code patch, it’s just a small configuration tweak
you really don’t have to set up all the MENDER_*_PART_* strings manually. As my local.conf shows, I also didn’t.
I am pretty convinced that there is something concerning storage where we are going astray when talking about it. These two partitions ending in boot0 and boot1 indicate specific boot partitions as found on an eMMC. I’ve never seen those on an SD card. The standard assumption our sdimg makes is being put on an SD card, and running directly from there. And thats obviously also my assumption.
As I do not have the board to inspect it, there’s little else that I can do the rest of the week, I’m afraid. I know this is bad news.
No worries at all… I really appreciate your support and yes enjoy the holidays.
While going back and forth with SD card setup, what if we flash directly into Sama7 eMMC? I did create a standard OS and flashed wic image into Sama7 eMMC:
Sorry, actually things are a bit complicated here at the moment. I personally won’t be able to respond in the next 10 days or so, but maybe @texierp or @kacf can chime in.
From the booting point of view it really should not be much of a difference. The key is and stays that the device identifiers that you pass into MENDER_STORAGE_DEVICE and friends are correct.
Again, you really should not set any of those unless the defaults are not working:
I didn’t do so for the image I built and sent, and as it managed to get beyond u-boot, the defaults should probably be fine.
Looking at the fdisk -l output, there are two devices. One is 4GB, probably the eMMC, on mmcblk0, the other is 64GB, probably the SD card, on mmcblk1. So the correct setting for MENDER_STORAGE_DEVICE is /dev/mmcblk1, if my assumptions are correct.
Then the last thing you have to check is MENDER_UBOOT_STORAGE_INTERFACE = "mmc" and MENDER_UBOOT_STORAGE_DEVICE = "0". Again, just guessing from that fdisk -l, MENDER_UBOOT_STORAGE_DEVICE should probably be 1. You definitely should be able to inspect the filesystems on the u-boot prompt. If you have problems in identifying, just add some descriptive file to the sd card using your development host.
I was able to finally get the image building (with the Mender core layer) and get past u-boot to loading Linux. In my case, I am using an external SD card. If it helps anyone, I have my config file below. However, I have a different problem now. I get a bunch of dependency failed errors after a delay (it looks like it runs some tasks and then times out). @TheYoctoJester@ndivecha any ideas?
[ TIME ] Timed out waiting for device /dev/mmcblk1p1.
[DEPEND] Dependency failed for /uboot.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for File…ystem Check on /dev/mmcblk1p1.
[ TIME ] Timed out waiting for device /dev/mmcblk1p4.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for File…ystem Check on /dev/mmcblk1p4.
[ OK ] Stopped Dispatch Password …ts to Console Directory Watch.
[ OK ] Stopped Forward Password R…uests to Wall Directory Watch.
[ OK ] Reached target Timer Units.
[ OK ] Reached target Login Prompts.
[ OK ] Reached target Socket Units.
[ OK ] Started Emergency Shell.
Config file:
# Mender
INHERIT += "mender-full"
MENDER_FEATURES_ENABLE:append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi mender-growfs-data"
MENDER_ARTIFACT_NAME = "test-1"
MENDER_STORAGE_DEVICE = "/dev/mmcblk1"
ARTIFACTIMG_FSTYPE = "ext4"
MENDER_STORAGE_TOTAL_SIZE_MB = "8000"
MENDER_UBOOT_STORAGE_INTERFACE = "mmc"
# 0 is eMMC, 1 is SD
MENDER_UBOOT_STORAGE_DEVICE = "1"
MENDER_BOOT_PART_SIZE_MB = "64"
INIT_MANAGER = "systemd"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append = " kernel-image kernel-devicetree"
# size of /data partition
MENDER_DATA_PART_SIZE_MB = "2500"
# below line was commented out, or the file is missing and it will not boot
# IMAGE_BOOT_FILES:remove = " sama7g5ek.itb"
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "_REDACTED_"
EDIT: I also see errors like:
Buffer I/O error on dev mmcblk0, logical block 0, async page read
mmcblk0: unable to read partition table
mmcblk0boot0: mmc0:0001 S40004 4.00 MiB
mmcblk0boot1: mmc0:0001 S40004 4.00 MiB
mmcblk0rpmb: mmc0:0001 S40004 4.00 MiB, chardev (247:0)
...
systemd[1]: Hostname set to <sama7g5ek-sd>.
systemd[1]: Initializing machine ID from random generator.
systemd[1]: Queued start job for default target Multi-User System.
systemd[1]: -.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup/unified, i gnoring: Function not implemented
systemd[1]: system.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup/unifi ed/system.slice, ignoring: Function not implemented
systemd[1]: system-getty.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup /unified/system.slice/system-getty.slice, ignoring: Function not implemented
systemd[1]: Created slice Slice /system/getty.
[ OK ] Created slice Slice /system/getty.
systemd[1]: system-modprobe.slice: Failed to get cgroup ID on cgroup /sys/fs/cgr oup/unified/system.slice/system-modprobe.slice, ignoring: Function not implement ed
systemd[1]: Created slice Slice /system/modprobe.
[ OK ] Created slice Slice /system/modprobe.
systemd[1]: system-serial\x2dgetty.slice: Failed to get cgroup ID on cgroup /sys /fs/cgroup/unified/system.slice/system-serial\x2dgetty.slice, ignoring: Function not implemented
systemd[1]: Created slice Slice /system/serial-getty.
[ OK ] Created slice Slice /system/serial-getty.
systemd[1]: system-systemd\x2dfsck.slice: Failed to get cgroup ID on cgroup /sys /fs/cgroup/unified/system.slice/system-systemd\x2dfsck.slice, ignoring: Function not implemented
Just guessing is that the storage configuration is off, as the mentions of mmcblk0 and mmcblk1 in the logs are inconsistent. Also to check is if the boot chain is really proceeding as intended. I don’t know this specific board, but there are situations in which a U-Boot from ROM is always executed before loading kernel and root filesystem from SD card.
So the first step in my opinion would be to stop in the u-boot console, and inspect the environment if the Mender integration is there and if the values make sense. Same for the environment.
