i.MX6 Linux: fw_printenv/fw_setenv problems

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX6 Linux: fw_printenv/fw_setenv problems

2,993 Views
ganesank
Contributor III

Problem Statement: Problem in updating u-boot environment variables from Linux using fw_setenv/fw_printenv tools. I observed the following,

What is working:

  • Able to print environment variables without any problem
  • Able to modify a default environment variable

What is not working:

  • Not able to create a new environment variables using fw_setenv. It is leading to Bad CRC issue when new variables are added
  • Not allowing more than one default environment variable to be modified in one power cycle. Modifying more than one variable is also leading to Bad CRC. If I modify one variable, reboot the system and then modify the second one then there is no issue

Our Environment:

We are using Yocto 2.1 - Linux 4.1 Freescale community BSP for our custom board based on Advantech Q7 - i.MX6 CPU module. The u-boot version is 2016.07. The u-boot binary and environment variables are stored in SPI NOR Flash (n25q032)

Any one has faced similar issues?. Any pointers to debug this would be welcome.

Labels (3)
0 Kudos
10 Replies

577 Views
mueller12
Contributor III

fw_setenv code from U-Boot assumes wrong protection scheme. SPI NOR usaually protects not sector by sector but a region beginning from bottom or top. So after first usage a complete region is protected. Maybe disabling the whole protection stuff in fw_setenv optionally if env is on SPI_NOR is a way to go. Maybe should be patched in U-Boot mainline?

0 Kudos

577 Views
woutervh
Contributor IV

Yes, maybe. But I'm a bit surprised we are having this issue. This question dates back to 2016... Nobody else is using spi nor for uboot environment storage? And why not?

0 Kudos

577 Views
woutervh
Contributor IV

Anyone has a valable solution for this one yet?

0 Kudos

577 Views
ganesank
Contributor III

I found the root cause of this problem. The flash sectors are protected so it has to be unlocked before erase & write operations which I expected to be handled in fw_setenv tool. In fact I checked about it in the code and there are unlock and lock ioctl calls being made but it doesn't seem to work properly. I have to debug this further. Any suggestion is most welcome.

Workaround: If I run "flash_unlock /dev/mtd1" command before every "fw_setenv <var> <value>" command then all use-cases like multiple modifications and creation of new variables are working fine.

0 Kudos

577 Views
pietercardoen
Contributor II

I am facing the same problem, however slightly different. If I use fw_setenv in user space, I get in u-boot: spi flash protected.

Has someone already solved this issue or should I use the workaround?

Best regards

Pieter

0 Kudos

577 Views
benjaminp
Contributor I

Same as me. I can unlock the spi flash with the command

'sf protect unlock 0x0 <FLASH_SIZE>',

and after doing so I can change the value of an environment variable as often as I want in the bootloader cli, and exactly once in linux by running the 'fw_setenv' command. After this command, the SPI-flash is protected again.

Does anyone know why the SPI flash gets locked? Is this somehow adjustable by a define during U-Boot configuration?

I use the u-boot-imx 2016.03

Best Regards

Benjamin

0 Kudos

577 Views
pietercardoen
Contributor II

I used a workaround. I searched for the code which is executed if saveenv is applied. At a certain point it tries to write to the SPI flash. Just before, I added a command to unprotect the SPI flash. So now every time I do saveenv, I first get the message: "Unprotecting SPI Flash".

Maybe not the best way but it works.

Best regards

Pieter Cardoen

0 Kudos

577 Views
jimmychan
NXP TechSupport
NXP TechSupport

Could you show me the fw_env.config?

0 Kudos

577 Views
ganesank
Contributor III

fw_env.config:

/dev/mtd1 0x0000 0x2000 0x10000

CONFIG_ENV_SIZE is set to (8 * 1024)

and sector size is 64 KBytes

0 Kudos

577 Views
jimmychan
NXP TechSupport
NXP TechSupport

you may try to set the ENV_SIZE to 0x10000.

If still not work, I think you can try to add some printk in the fw_env.c to see why CRC error happen when modify one more variable.

0 Kudos