[U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables

[Reda MIMOUNE]

Hi Scott;
Again thank you for the answer.

>My expense request for a time machine was denied, so we can't go back
>and put new features in old versions. :-)
>Please upgrade, or backport the features yourself.

Have a question about it, if I upgrade to a new version of uBoot. Is it guaranteed that mkimage
will wrap the uboot binary the same way. Is mkimage the same version ?
If yes, I think I will upgrade.

> Or you can use the new env.oob feature to dynamically mark a known-good block as
> your environment.
>CONFIG_ENV_OFFSET_OOB
>You'll need top-of-tree U-Boot for this.

It is interesting, but i will look at this after upgrade.

>> That's what I believed since they became bad only after uboot wrote to them...
>Perhaps something is wrong with your NAND driver, then.
>Are you sure it wasn't marked bad before?

Yes they were not marked. I used "nand bad" and only the BBT blocks were marked.
And once I changed the environment block in the uboot code and reflashed it and
run again "nand bad" after a savenv, the newly chosen block was marked bad. 
It is a bit strange. It happened between my first message and your second answer.
I also changed the place to the first block adress 0. The one which cannot fail. And
it was marked bad. I think there is a problem in the software probably. My uBoot 1.3.4
source code is maybe wrong concerning all the saveenv function.
I use a Samsung NAND 3.3V 8bit which is recognized.

>The environment data itself, probably not.  But it must take up a
>multiple of the block size in NAND, because you don't want to erase
>other things when updating the environment.

Of course, I understood that. My question was in the config file. I put this:

#define CFG_ENV_SECT_SIZE			SZ_16K
#define CFG_ENV_SIZE				SZ_128K

I saw something equivalent in the Evalution board of Davinci DM365 so it should not be
impossible.

Thanks for all
-Reda