fw_setenv corrupts environment on MTD for Linux kernels after 5.4

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

fw_setenv corrupts environment on MTD for Linux kernels after 5.4

Jump to solution
1,033 Views
aahndee
Contributor II

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…

Labels (2)
0 Kudos
Reply
1 Solution
856 Views
aahndee
Contributor II

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).

View solution in original post

4 Replies
857 Views
aahndee
Contributor II

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).

808 Views
shawnkarow
Contributor II

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. 

1,009 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello,

Maybe someone of @Nitrogen could help on this.

Regards

0 Kudos
Reply
938 Views
aahndee
Contributor II

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…

0 Kudos
Reply