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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
