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…
Solved! Go to Solution.
After comparing the SPI traffic during write with working vs. non-working kernel issues I was able to track the issue down to the SST write code in the MTD driver and managed to fix this using the attached patch (patch against Linux 6.1, only tested against sst25vf016b).
We experienced the same issue using the sst25vf032b and sst26vf032b in both the 6.1 and 6.6 kernels. Thanks for this patch it has fixed the problem in both kernels versions for us as well.
Hello,
Maybe someone of @Nitrogen could help on this.
Regards
If by "Nitrogen" you mean the people at Ezurio (formerly Boundary Devices), I've tried that first and they said that their Linux kernel is the one from NXP so I should try here…