Good afternoon @TheYoctoJester ,
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.
Much appreciated for going extra mile!
Cheers,
Nitesh
Hi @ndivecha,
Long shot, but: are you sure that those are really correct?
MENDER_STORAGE_DEVICE = “/dev/mmcblk0”
#MENDER_UBOOT_STORAGE_DEVICE = “0”
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.
Greetz,
Josef
Hello @TheYoctoJester
You are correct!
Created test.txt manually under /boot folder but it doesn’t shows up on u-boot prompt when ext4ls mmc 0:2 boot. Just
=> ext4ls mmc 0:2 boot
<DIR> 1024 .
<DIR> 1024 ..
4767128 sama7g5ek.itb
3664 sama7g5ek.its
1323 sama7g5ek_i2s0_pcm5102a.dtbo
1398 sama7g5ek_i2s0_proto.dtbo
4251 sama7g5ek_isc_imx219.dtbo
2718 sama7g5ek_isc_imx274.dtbo
1415 sama7g5ek_pdmc0.dtbo
1808 sama7g5ek_wilc3000.dtbo
<SYM> 41 zImage
4706176 zImage-6.1.22-linux4microchip-2023.04-rc2
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
Hi @ndivecha,
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:
INHERIT += "mender-full"
MENDER_FEATURES_ENABLE:append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi"
MENDER_ARTIFACT_NAME = "test1"
MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
ARTIFACTIMG_FSTYPE = "ext4"
MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
MENDER_UBOOT_STORAGE_INTERFACE = "mmc"
MENDER_UBOOT_STORAGE_DEVICE = "0"
MENDER_BOOT_PART_SIZE_MB = "64"
INIT_MANAGER = "systemd"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append = " kernel-image kernel-devicetree"
IMAGE_BOOT_FILES:remove = " sama7g5ek.itb"
So if I had to guess again, I would give this a try:
INHERIT += "mender-full"
MENDER_FEATURES_ENABLE:append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi"
MENDER_ARTIFACT_NAME = "test2"
MENDER_STORAGE_DEVICE = "/dev/mmcblk1"
MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
MENDER_UBOOT_STORAGE_INTERFACE = "mmc"
MENDER_BOOT_PART_SIZE_MB = "64"
INIT_MANAGER = "systemd"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append = " kernel-image kernel-devicetree"
IMAGE_BOOT_FILES:remove = " sama7g5ek.itb"
Th
Hello @TheYoctoJester
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.
On a normal boot I see following on the screen:
mmc0: new DDR MMC card at address 0001
mmcblk0: mmc0:0001 S40004 3.64 GiB
mmcblk0: p1 p2
mmcblk0boot0: mmc0:0001 S40004 4.00 MiB
mmcblk0boot1: mmc0:0001 S40004 4.00 MiB
mmcblk0rpmb: mmc0:0001 S40004 4.00 MiB, chardev (247:0)
mmc1: new ultra high speed DDR50 SDXC card at address aaaa
mmcblk1: mmc1:aaaa SR64G 59.5 GiB
mmcblk1: p1 p2
then when booted up, fdisk -l:
~# 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.
my local.conf
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 = ""
ARTIFACTIMG_FSTYPE = "ext4"
MENDER_BOOT_PART_SIZE_MB = "64"
MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
MENDER_UBOOT_STORAGE_INTERFACE = "mmc"
MENDER_STORAGE_DEVICE = "/dev/mmcblk1"
MENDER_STORAGE_DEVICE_BASE = "${MENDER_STORAGE_DEVICE}"
MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}p1"
MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}p2"
MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}p3"
MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}p4"
MENDER_FEATURES_ENABLE:append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append = " kernel-image kernel-devicetree"
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "<TOKEN>"
and I have following added in ../meta-atmel/recipes-bsp/u-boot/u-boot-at91_2022.10.bb:
require /home/nitesh/Projects/yocto/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-mender.inc
# Mender
PROVIDES += "u-boot"
RPROVIDES_${PN} += "u-boot"
BOOTENV_SIZE = "0x20000"
I have tried both /dev/mmcblk1 and /dev/mmcblk0
Sorry for the setbacks and inconvenience.
Cheers,
Nitesh
Hello @TheYoctoJester
Hope all is well with ya!
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:
MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
MENDER_STORAGE_DEVICE_BASE = "${MENDER_STORAGE_DEVICE}"
MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}p1"
MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}p2"
MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}p3"
MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}p4"
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 
Any help will be highly appreciated.
Cheers,
Nitesh
Hi @ndivecha,
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. 
Greetz,
Josef
Happy Friday @TheYoctoJester
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:
Got following:
=> mmc list
mmc@e1204000: 0 (eMMC)
mmc@e1208000: 1
=>
=> printenv
bootargs=console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait atmel.pm_modes=standby,ulp0 cma=192m
bootcmd=fatload mmc 0:1 0x63000000 sama7g5ek.itb; bootm 0x63000000#kernel_dtb
bootdelay=1
eth1addr=04:91:62:f2:a4:c9
ethact=gmac0
ethaddr=04:91:62:f2:ae:88
fdtcontroladdr=7fb674f0
stderr=serial@200
stdin=serial@200
stdout=serial@200
Environment size: 349/16380 bytes
=>
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait atmel.pm_modes=standby,ulp0 cma=192m
[ 1.318116] mmc0: SDHCI controller on e1204000.mmc [e1204000.mmc] using ADMA
[ 1.354316] mmc1: SDHCI controller on e1208000.mmc [e1208000.mmc] using ADMA
[ 1.572210] Waiting for root device /dev/mmcblk0p2...
[ 1.577084] mmc0: new DDR MMC card at address 0001
[ 1.581388] mmcblk0: mmc0:0001 S40004 3.64 GiB
[ 1.586957] mmcblk0: p1 p2
[ 1.589424] mmcblk0boot0: mmc0:0001 S40004 4.00 MiB
[ 1.595002] mmcblk0boot1: mmc0:0001 S40004 4.00 MiB
[ 1.599967] mmcblk0rpmb: mmc0:0001 S40004 4.00 MiB, chardev (247:0)
[ 1.634276] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: disabled.
[ 4.034470] EXT4-fs (mmcblk0p2): re-mounted. Quota mode: disabled.
root@sama7g54:~# 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: 0x20f35e36
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8 42605 42598 20.8M c W95 FAT32 (LBA)
/dev/mmcblk0p2 42608 1033755 991148 484M 83 Linux
root@sama7g54:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 3.6G 0 disk
|-mmcblk0p1 179:1 0 20.8M 0 part
`-mmcblk0p2 179:2 0 484M 0 part /
root@sama7g54:~#
Will this help to iron out all the MENDER_STORAGE_DEVICE and MENDER_*_PART_* problems?
Have a great weekend 
Cheers,
Nitesh
Hello @TheYoctoJester
Hope all is well with ya! Just following up with you on this… Any thoughts if we flash directly into Sama7 eMMC?
Cheers,
Nitesh
Hi @ndivecha,
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:
ARTIFACTIMG_FSTYPE
MENDER_STORAGE_DEVICE_BASE
MENDER_BOOT_PART
MENDER_ROOTFS_PART_A
MENDER_ROOTFS_PART_B
MENDER_DATA_PART
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.
Hope this helps,
Josef