I'm using a BoundaryDevices Nitrogen 6 SOM2v2 with an i.MX6Q and sst25vf016b SPI NOR for U-Boot (environment stored on /dev/mtd1). System image is built via buildroot. For our system upgrade process, we need to change U-Boot variables from a shell script which is achieved via fw_setenv.
The issue now is, that trying to use a kernel after 5.4 (tested with 5.10. 5.15, and 6.1), fw_setenv destroys the environment on the MTD, making the upgrade process fail (same failure for fw_setenv from UBOOT_TOOLS and LIBUBOOTENV). According to the folks at Boundary Devices, "The issue you're seeing is related to a bug in the MTD driver. The driver comes from NXP, and we haven't made any modifications."
The latest buildroot (2024.02.1), using the defconfig for this board uses the MTD driver from https://github.com/boundarydevices/linux/tree/boundary-imx_6.1.y/drivers/mtd
The failure can easily be triggered using the following steps:
# fw_printenv bootdelay
bootdelay=3
# fw_setenv bootdelay 5
# fw_printenv bootdelay
Warning: Bad CRC, using default environment
Looking at the stored environment after these steps by means of
hexdump -C /dev/mtd1
we can see that everything but the first byte for each block is 0xff, pointing to the erase being successful but the write only writing one byte.
Any ideas on how to fix the driver? We really would like to move on past a 5.4 kernel/buildroot 2021.02…