[U-Boot] U-Boot Tool: fw_setenv - kernel option?

[U-Boot] U-Boot Tool: fw_setenv - kernel option?

[Arno Steffens]

After using a plain vanilla instead of a vendor kernel I do have problems with fw_setenv.
Althoug fw_printenv still works fine, after usage of fw_setenv the environment is destroyed, CRC error.

I checked a lot of things, changed u-boot, devicetree, fw_setenv ... and finally came to the point, that it just depends on the kernel. Only changing the kernel makes the difference. I assume that there is an option not enabled. Honestly, I am lost with the differences - I couldn't identify the one that makes difference. 
Using an older config file, with lot more options, than it works also with a newer kernel.

Someone has an idea, which of the million settings is my friend? CONFIG_CRC16 and 32 are both enabled.

Best regards
Arno

[U-Boot] U-Boot Tool: fw_setenv - kernel option?

[Tom Rini]

On Mon, Jul 17, 2017 at 04:08:27PM +0200, Arno Steffens wrote:

> After using a plain vanilla instead of a vendor kernel I do have
> problems with fw_setenv.
> Althoug fw_printenv still works fine, after usage of fw_setenv the
> environment is destroyed, CRC error.
> 
> I checked a lot of things, changed u-boot, devicetree, fw_setenv ...
> and finally came to the point, that it just depends on the kernel.
> Only changing the kernel makes the difference. I assume that there is
> an option not enabled. Honestly, I am lost with the differences - I
> couldn't identify the one that makes difference. 
> Using an older config file, with lot more options, than it works also
> with a newer kernel.
> 
> Someone has an idea, which of the million settings is my friend?
> CONFIG_CRC16 and 32 are both enabled.

The most likely answer here is that in the working kernel you have
things enabled correctly for your environment storage device (I would
guess some form of NAND) and in the not working kernel you do not have
things such as ECC scheme configured correctly, so writes do not work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/447aa053/attachment.sig>

[U-Boot] U-Boot Tool: fw_setenv - kernel option?

[Arno Steffens]

> Gesendet: Mittwoch, 19. Juli 2017 um 00:55 Uhr
> Von: "Tom Rini" <trini@konsulko.com>
> An: "Arno Steffens" <epsi@gmx.de>
> Cc: u-boot at lists.denx.de
> Betreff: Re: [U-Boot] U-Boot Tool: fw_setenv - kernel option?
>
> On Mon, Jul 17, 2017 at 04:08:27PM +0200, Arno Steffens wrote:
> 
> > After using a plain vanilla instead of a vendor kernel I do have
> > problems with fw_setenv.
> > Althoug fw_printenv still works fine, after usage of fw_setenv the
> > environment is destroyed, CRC error.
> > 
> > I checked a lot of things, changed u-boot, devicetree, fw_setenv ...
> > and finally came to the point, that it just depends on the kernel.
> > Only changing the kernel makes the difference. I assume that there is
> > an option not enabled. Honestly, I am lost with the differences - I
> > couldn't identify the one that makes difference. 
> > Using an older config file, with lot more options, than it works also
> > with a newer kernel.
> > 
> > Someone has an idea, which of the million settings is my friend?
> > CONFIG_CRC16 and 32 are both enabled.
> 
> The most likely answer here is that in the working kernel you have
> things enabled correctly for your environment storage device (I would
> guess some form of NAND) and in the not working kernel you do not have
> things such as ECC scheme configured correctly, so writes do not work.
> 
> -- 
> Tom
> 

Dear Tom,
thanks for your message. My boot storage is nor and you are right. I could found the problem.
For those who are interested, I found a difference using strace (always good to have a working reference ;):

ioctl(4, MIXER_READ(1) or MEMGETINFO, {type=MTD_NORFLASH, flags=MTD_WRITEABLE|MTD_BIT_WRITEABLE, size=0x10000, erasesize=0x1000, writesize=0x1, oobsize=0, padding=0}) = 0
 
and the other
 
ioctl(4, MIXER_READ(1) or MEMGETINFO, {type=MTD_NORFLASH, flags=MTD_WRITEABLE|MTD_BIT_WRITEABLE, size=0x10000, erasesize=0x10000, writesize=0x1, oobsize=0, padding=0}) = 0

So the erase size differes (although stated correctly in conf-file. I guess it has been this setting:

CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y, which was set by default and has to be disabled.

Have a nice day :)
Arno