[U-Boot] Davinci DM365 custom design : Problem when reading uBoot environment variables
Hello all uboot mailist members
First of all, i am new to uboot coding, though i am a user of uboot on many platforms (so without knowing how it is done). So for a custom design, i had to dig inside the uboot code to adapt to a DaVinci board we have built. I use uBoot version 1.3.4 which is used by TI for many designs which I started from. I have customized the <board>.h file to include all "define" I could need i the source code I explored. The first difficulty was to get the environment saved in the right place in the NAND memory, so that my development can begin on it really. I cannot only use the default environment and recompile uboot and reflash...etc.. each time i need to change an environment parameter. So I stick to my problem. The code told parameters were saved. But when I reset the board, the message is *** Warning bad CRC or NAND. the zone was set to a NAND block size of 128KB (since it is mandatory to be the same size). I put some debug messages to find out that the read_env function used returns an error because of my environment variables block is bad. This i cannot understand since it wrote data in the right block.
To widen the problem I choose to double the environment size to 256KB. It is still the same. I typed the "nand bad " at prompt and my blocks + the bad block tables were marked as bad ! is that normal that BBT are marked bad ?
So for the moment i try to remove this bad character from my block by trying to erase all the nand, and using nand scrub. And this is always the same. I run out of solutions now, so that i ask for some debugging ideas about this issue. I will probably try to check if the saveenv worked properly (despite the lack of error messages).
Thanks to all of you Reda
On Wed, 15 Sep 2010 18:21:11 +0200 Reda MIMOUNE reda.mimoune@easii-ic.com wrote:
But when I reset the board, the message is *** Warning bad CRC or NAND. the zone was set to a NAND block size of 128KB (since it is mandatory to be the same size). I put some debug messages to find out that the read_env function used returns an error because of my environment variables block is bad. This i cannot understand since it wrote data in the right block.
If the block is bad, then that's not the right block. :-)
You can use CONFIG_ENV_RANGE to declare a multi-block range, larger than the environment size, to allow bad blocks to be skipped. Or you can use the new env.oob feature to dynamically mark a known-good block as your environment.
To widen the problem I choose to double the environment size to 256KB. It is still the same.
You need to use CONFIG_ENV_RANGE and keep the environment the same size -- otherwise it thinks you really want two blocks of environment data, and one of those blocks being bad is still fatal.
I typed the "nand bad " at prompt and my blocks + the bad block tables were marked as bad ! is that normal that BBT are marked bad ?
Yes, the BBT blocks are marked bad so they won't be used for other purposes.
So for the moment i try to remove this bad character from my block by trying to erase all the nand, and using nand scrub.
Please be careful with that. Unless you have reason to believe that the block was accidentally marked bad by something software did, you ought to leave bad block markers in place. The manufacturer put that marker there to indicate that the block is unreliable (it's normal for NAND flash to contain a few such blocks).
-Scott
Hi Scott. Thank you for your answer.
You can use CONFIG_ENV_RANGE to declare a multi-block range, larger than the environment size, to allow bad blocks to be skipped.
You need to use CONFIG_ENV_RANGE and keep the environment the same size -- otherwise it thinks you really want two blocks of environment data, and one of those blocks being bad is still fatal.
Thank your for the info. I will put this flag in my board definition file. I is exactly the case. The block I choose to be the environment block became bad so i increased the size to 2 blocks and the second block became bad. So in my both cases, what you said explains that the case I met. I will put this flag and check if it is present in my 1.3.4 version.
Or you can use the new env.oob feature to dynamically mark a known-good block as your environment.
I do not know this feature. To which config flag does it relate ?
Please be careful with that. Unless you have reason to believe that the block was accidentally marked bad by something software did, you ought to leave bad block markers in place.
That's what I believed since they became bad only after uboot wrote to them...
The manufacturer put that marker there to indicate that the block is unreliable (it's normal for NAND flash to contain a few such blocks).
For this i am ok with you.
Another question or confirmation: when using environment in NAND, must the environment size be the same than the NAND block size, i.e 128KB in my case (which i think is too huge) ?
Thank you for answering
Reda
On Thu, 16 Sep 2010 09:42:07 +0200 Reda MIMOUNE reda.mimoune@easii-ic.com wrote:
So in my both cases, what you said explains that the case I met. I will put this flag and check if it is present in my 1.3.4 version.
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.
Or you can use the new env.oob feature to dynamically mark a known-good block as your environment.
I do not know this feature. To which config flag does it relate ?
CONFIG_ENV_OFFSET_OOB
You'll need top-of-tree U-Boot for this.
Please be careful with that. Unless you have reason to believe that the block was accidentally marked bad by something software did, you ought to leave bad block markers in place.
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?
Another question or confirmation: when using environment in NAND, must the environment size be the same than the NAND block size, i.e 128KB in my case (which i think is too huge) ?
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.
-Scott
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
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD25@mars.easii.fr you wrote:
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 ?
Of course mkimage is not the same version. When upgrade to a new version of U-Boot, you also get a new version of mkimage.
If yes, I think I will upgrade.
Where would you expect problems? You can build and test the new version of mkimage before updating the U-Boot image on your target board.
And you can keep the old mkimage tool around for reference as well.
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
This makes no sense. I doubt that your NAND flash has 16 kB sectors.
Also I seriously doubt that you need 128 kB for environment.
I saw something equivalent in the Evalution board of Davinci DM365 so it should not be impossible.
Please do not copy code without thinking.
Best regards,
Wolfgang Denk
Hello Wolfgang Thanks for answering. Good to see that mkimage would be ok with both versions.
What do I fear ? I traditionnaly saw many problems of version coherence between binaries and tools generating them. Now I prefer to ask.
Concerning the #define, I made a mistake when recopying.
this should be OK.
#define CFG_ENV_SECT_SIZE SZ_128K /* Env sector Size = 128KB*/ #define CFG_ENV_SIZE SZ_128K /* 128KB is 1-Block size without counting spare*/
Concerning the size of 128KB. Obviously it is too much. I think it too. But reading the README file, here is what I read:
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size.
Since my sectors/blocks are 128KB, I must be at least 128KB!
Is the README file wrong ? Thanks for your help. Reda
________________________________________ De : Wolfgang Denk [wd@denx.de] Date d'envoi : vendredi 17 septembre 2010 14:37 À : Reda MIMOUNE Cc : Scott Wood; u-boot@lists.denx.de Objet : Re: [U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD25@mars.easii.fr you wrote:
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 ?
Of course mkimage is not the same version. When upgrade to a new version of U-Boot, you also get a new version of mkimage.
If yes, I think I will upgrade.
Where would you expect problems? You can build and test the new version of mkimage before updating the U-Boot image on your target board.
And you can keep the old mkimage tool around for reference as well.
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
This makes no sense. I doubt that your NAND flash has 16 kB sectors.
Also I seriously doubt that you need 128 kB for environment.
I saw something equivalent in the Evalution board of Davinci DM365 so it should not be impossible.
Please do not copy code without thinking.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de All this doesn't alter anything, you know. The world is still full of stupid people. They don't use their brains. They don't seem to want to think straight. - Terry Pratchett, _Soul Music_
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD2A@mars.easii.fr you wrote:
reading the README file, here is what I read:
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size.
I think that should be CONFIG_ENV_SECT_SIZE
Since my sectors/blocks are 128KB, I must be at least 128KB!
Is the README file wrong ?
Seems so. Unless Davinci has messed up this.
Best regards,
Wolfgang Denk
Thank you No Davinci did not mess it up. I read 0x4000 (16KB) instead of 0x40000 (256KB). So if I understand you I can swap the values in my first email:
CONFIG_ENV_SECT_SIZE = 128KB CFG_ENV_SIZE = 16KB
Thanks for help. Cordialement, Reda MIMOUNE
Reda MIMOUNE Ingénieur Software Senior
EASII IC SAS 90, avenue Léon Blum BP 2612 Tel : 04 56 580 579 38036 Grenoble cedex 2 Fax : 04 56 580 599 www.easii-ic.com
-----Message d'origine----- De : Wolfgang Denk [mailto:wd@denx.de] Envoyé : vendredi 17 septembre 2010 16:32 À : Reda MIMOUNE Cc : Scott Wood; u-boot@lists.denx.de Objet : Re: RE : [U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD2A@mars.easii.fr you wrote:
reading the README file, here is what I read:
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size.
I think that should be CONFIG_ENV_SECT_SIZE
Since my sectors/blocks are 128KB, I must be at least 128KB!
Is the README file wrong ?
Seems so. Unless Davinci has messed up this.
Best regards,
Wolfgang Denk
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADE8BB05@mars.easii.fr you wrote:
No Davinci did not mess it up. I read 0x4000 (16KB) instead of 0x40000 (256KB).
Actually I do think Davinci is messed up.
Many boards define CONFIG_ENV_SIZE as 256 or 128 KiB, which makes no sense (it just slows down booting):
davinci_dm355evm, davinci_dm355leopard, davinci_dm365evm, davinci_dvevm, davinci_schmoogie, davinci_sffsdr
And many boards define a ewrase block size which seems to be way too small for common NAND flash devices:
davinci_dvevm 512 or 2048 bytes davinci_schmoogie 2048 bytes davinci_sffsdr 2048 bytes davinci_sonata 512 bytes
Sandeep, can you please have a look? Thanks in advance.
Best regards,
Wolfgang Denk
On Fri, 17 Sep 2010 16:32:04 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD2A@mars.easii.fr you wrote:
reading the README file, here is what I read:
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size.
I think that should be CONFIG_ENV_SECT_SIZE
CONFIG_ENV_SECT_SIZE isn't used by env_nand.c -- it uses the dynamically-read block size in nand_info.
Since my sectors/blocks are 128KB, I must be at least 128KB!
Is the README file wrong ?
Seems so. Unless Davinci has messed up this.
Yes, the README is wrong. It used to be that way until commit c3db8c649c6ab3da2f1411c4c6d61aecea054aa4, and README wasn't updated.
The current requirement is that CONFIG_ENV_SIZE be a multiple of the page size.
-Scott
Some news to my problem. I found the source of the problem : The flags as explicited in uBoot 1.3.4 induces some problem. I had to undef the HW_ECC_4BIT flag since when using it the oob is overwritten. Since it looks at the oob to determine if a block is bad there was a problem. The unknown here is to understand why it did not use the BBT instead. By removing this flag and adding the nand_large_page flag it worked ! I however fixed the environment size issue so that it is no more a weird config. Thank you to all for your ideas and help. reda ________________________________________ De : Scott Wood [scottwood@freescale.com] Date d'envoi : vendredi 17 septembre 2010 20:01 À : Wolfgang Denk Cc : Reda MIMOUNE; u-boot@lists.denx.de Objet : Re: [U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables
On Fri, 17 Sep 2010 16:32:04 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Reda MIMOUNE,
In message 1918F436C366B34BB245DD28389E039453ADFAAD2A@mars.easii.fr you wrote:
reading the README file, here is what I read:
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size.I think that should be CONFIG_ENV_SECT_SIZE
CONFIG_ENV_SECT_SIZE isn't used by env_nand.c -- it uses the dynamically-read block size in nand_info.
Since my sectors/blocks are 128KB, I must be at least 128KB!
Is the README file wrong ?
Seems so. Unless Davinci has messed up this.
Yes, the README is wrong. It used to be that way until commit c3db8c649c6ab3da2f1411c4c6d61aecea054aa4, and README wasn't updated.
The current requirement is that CONFIG_ENV_SIZE be a multiple of the page size.
-Scott
participants (3)
-
Reda MIMOUNE -
Scott Wood -
Wolfgang Denk