Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

We are trying to initialize the u-boot environment from linux kernel space.

We are following the flash script steps that basically unlock the special boot device and dd the file in to the correct location...

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=uboot.env of=/dev/mmcblk0boot0 bs=512 seek=7944

7944 being offset address divided block size of 512. We have used dd to read that space and confirmed it appears to be written to disk.

Unfortunately, u-boot disagrees...

U-Boot 2024.04-ti-g1d3ba9d16938 (Oct 29 2024 - 14:04:51 +0000)

SoC:   AM62X SR1.0 HS-FS
Model: Critical Link MitySOM-AM62x
MitySOM-62x - Model No: 6254-TX-X9E-RC Serial No: 24003477 Part Number: 80-001744RC-3A
DRAM:  4 GiB
Core:  101 devices, 31 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from FAT... MMC: no card present
** Bad device specification mmc 1 **
Loading Environment from MMC... *** Warning - bad CRC, using default environment

If I pause in u-boot and run saveenv it will initialize the environment and be happy at the next boot up. fw_printenv/setenv in Linux are also happy with that environment.

So I took an image of first 9000 512 blocks of /dev/mmcblk0 when u-boot wasn't happy, and the same image when it was happy, hex dumped them both and compared.

The good crc image has an environment at address offset 0x3e1000, the bad crc image does not have an environment there. It seems like the special device is not really becoming read/write capable when unlocked. Like it is a shadow copy or something.

As a workaround I was able to include the fw_utils and an initial env file and then run `fw_setenv -f /etc/u-boot-initial-env` to initialize it from user space.
After that u-boot was happy with the env.

Any ideas why the dd method failed?

Thanks,
Nathan