[U-Boot] Getting "Unable to save the rest of sector (196608)" when I turn on Redundant env with CFG_ENV_ADDR_REDUND
Hi,
I'm using u-boot 1.1.6 and have been using a single 256k flash sector for the environment. I want to use the redundant env. feature so I changed my config to:
#define CFG_ENV_IS_IN_FLASH 1 /* Environment variables stored in Flash memory */ #define CFG_ENV_ADDR (PC20X_BOOTABLE_FLASH_BASE+FLASH_SECTOR_SIZE) #define CFG_ENV_SECT_SIZE FLASH_SECTOR_SIZE /* One flash sector for environment info */ #define CFG_ENV_SIZE 0x10000 /* But 64K is sufficient */ //#define CFG_ENV_SIZE CFG_ENV_SECT_SIZE /* the whole sector */
/* Redundant environment */ #define CFG_ENV_ADDR_REDUND (CFG_ENV_ADDR + CFG_ENV_SECT_SIZE) #define CFG_ENV_SIZE_REDUND (CFG_ENV_SIZE)
#define CONFIG_ENV_OVERWRITE /* Turn off wite protection for vendor parameters */
When I use u-boot built with a CFG_ENV_SIZE of 0x10000 (what was working before I started) and enable CFG_ENV_ADDR_REDUND .... I get the following when trying to saveenv:
=> saveenv Saving Environment to Flash... Un-Protected 1 sectors Un-Protected 1 sectors Unable to save the rest of sector (196608) Protected 1 sectors Protected 1 sectors
My physical NOR flash is setup as: 0x20000000 = u-boot 0x20040000 = u-boot env. (the original env that works if I don't have redund turned on) 0x20080000 = u-boot redund env. (what I added)
I'm not certain what the problem is. I'm getting to the code in common/env_flash.c that has:
#if CFG_ENV_SECT_SIZE > CFG_ENV_SIZE up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE)); debug ("Data to save 0x%x\n", up_data); if (up_data) { if ((saved_data = malloc(up_data)) == NULL) { printf("Unable to save the rest of sector (%ld)\n", up_data); goto Done; } memcpy(saved_data, (void *)((long)flash_addr_new + CFG_ENV_SIZE), up_data); debug ("Data (start 0x%x, len 0x%x) saved at 0x%x\n", (long)flash_addr_new + CFG_ENV_SIZE, up_data, saved_data); } #endif
... which to my understanding is intended to allow you to save RAM by using a env. smaller than your sector size which is my case.
I've also tried to set CFG_ENV_SIZE to be the flash sector size which gets me over the above "Unable to save the rest of sector" problem but I suspect that I'm having RAM issues as I only have 128M RAM and am trying to use two environments of 256k each and the problem I'm having then becomes when I try to nfs boot my board .... it just hangs.
Any ideas on what I should check? The "Unable to save the rest of sector (196608)" is kind of strange as 196608 in hex is 0x30000 which is the sector u-boot lives in!
Regards,
Brian
Update.
I'm on a ARM 926 by the way. Forgot to mention that.
I fired up my trusty JTAG OpenOCD and gdb to investigate this more.
Looks like the malloc of up_data (which is 0x30000) is failing.
My env size is 0x10000 so why am I trying to malloc 0x30000?
Regards,
Brian
Sorry for the top post. Resending in plan test. This was the second message of the thread.
On Wed, Apr 7, 2010 at 4:14 PM, Brian Hutchinson b.hutchman@gmail.com wrote:
Update.
I'm on a ARM 926 by the way. Forgot to mention that.
I fired up my trusty JTAG OpenOCD and gdb to investigate this more.
Looks like the malloc of up_data (which is 0x30000) is failing.
My env size is 0x10000 so why am I trying to malloc 0x30000?
Regards,
Brian
Dear Brian Hutchinson,
In message q2m3d1967ab1004071747zf70f0006x1f4eb1012f66e895@mail.gmail.com you wrote:
Looks like the malloc of up_data (which is 0x30000) is failing.
So maybe you want to increase the size of the malloc arena?
My env size is 0x10000 so why am I trying to malloc 0x30000?
To have room for two copies of the environment sectors plus some reserve for other purposes?
Best regards,
Wolfgang Denk
#if CFG_ENV_SECT_SIZE > CFG_ENV_SIZE up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE)); debug ("Data to save 0x%x\n", up_data); if (up_data) { if ((saved_data = malloc(up_data)) == NULL) { printf("Unable to save the rest of sector (%ld)\n", up_data); goto Done; } memcpy(saved_data, (void *)((long)flash_addr_new + CFG_ENV_SIZE), up_data); debug ("Data (start 0x%x, len 0x%x) saved at 0x%x\n", (long)flash_addr_new + CFG_ENV_SIZE, up_data, saved_data); } #endif
I guess I don't understand at all why flash_addr_new + CFG_ENV_SIZE is getting saved off when I want my redundant environment to start at flash_addr_new.
So, I went back to the other test case I'm trying where my CFG_ENV_SIZE is equal to flash sector size (256k in my case) which makes the redundant environment work but when I try to NFS boot my board I get:
=> run fixed_nfs Ethernet PHY auto-negotiation complete Ethernet link: is up Ethernet link: Full-duplex mode Ethernet link: 100 Mbit/s Using pc20x_emac device TFTP from server 192.168.0.2; our IP address is 192.168.0.5 Filename 'uImage-cpe20x'. Load address: 0x200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######## done Bytes transferred = 1700872 (19f408 hex) ## Booting image at 00200000 ... Image Name: Linux-2.6.28-picochip-3.2.0 Created: 2010-04-05 19:24:18 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1700808 Bytes = 1.6 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK
And then everything hangs. Should I play with moving around TEXT_BASE (0x05000000), linker files? I'm kind of stumped at the moment. :(
Regards,
Brian
Sorry for top post. This is the third message of the thread being re-sent in plain text. I'll also add that the test case below also hangs on trying to bootm a kernel in flash just as it did in the nfs boot case of the shown below.
On Wed, Apr 7, 2010 at 5:07 PM, Brian Hutchinson b.hutchman@gmail.com wrote:
#if CFG_ENV_SECT_SIZE > CFG_ENV_SIZE up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE)); debug ("Data to save 0x%x\n", up_data); if (up_data) { if ((saved_data = malloc(up_data)) == NULL) { printf("Unable to save the rest of sector (%ld)\n", up_data); goto Done; } memcpy(saved_data, (void *)((long)flash_addr_new + CFG_ENV_SIZE), up_data); debug ("Data (start 0x%x, len 0x%x) saved at 0x%x\n", (long)flash_addr_new + CFG_ENV_SIZE, up_data, saved_data); } #endif
I guess I don't understand at all why flash_addr_new + CFG_ENV_SIZE is getting saved off when I want my redundant environment to start at flash_addr_new.
So, I went back to the other test case I'm trying where my CFG_ENV_SIZE is equal to flash sector size (256k in my case) which makes the redundant environment work but when I try to NFS boot my board I get:
=> run fixed_nfs Ethernet PHY auto-negotiation complete Ethernet link: is up Ethernet link: Full-duplex mode Ethernet link: 100 Mbit/s Using pc20x_emac device TFTP from server 192.168.0.2; our IP address is 192.168.0.5 Filename 'uImage-cpe20x'. Load address: 0x200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######## done Bytes transferred = 1700872 (19f408 hex) ## Booting image at 00200000 ... Image Name: Linux-2.6.28-picochip-3.2.0 Created: 2010-04-05 19:24:18 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1700808 Bytes = 1.6 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK
And then everything hangs. Should I play with moving around TEXT_BASE (0x05000000), linker files? I'm kind of stumped at the moment. :(
Regards,
Brian
Dear Brian Hutchinson,
In message s2x3d1967ab1004071751j50c177f6haaafa222f76f3632@mail.gmail.com you wrote:
...
## Booting image at 00200000 ... Image Name: Linux-2.6.28-picochip-3.2.0 Created: 2010-04-05 19:24:18 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1700808 Bytes = 1.6 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK
And then everything hangs. Should I play with moving around TEXT_BASE (0x05000000), linker files? I'm kind of stumped at the moment. :(
What makes you think this would be a U-Boot problem?
A load address of 0x00008000 / entry point of 0x00008000 is pretty certainly bogus on a ARM system, which typically has ROM at this address range. Are you sure that you have unused RAM there on your system?
Best regards,
Wolfgang Denk
On Thu, Apr 8, 2010 at 6:08 AM, Wolfgang Denk wd@denx.de wrote:
Dear Brian Hutchinson,
In message s2x3d1967ab1004071751j50c177f6haaafa222f76f3632@mail.gmail.com you wrote:
...
## Booting image at 00200000 ... Image Name: Linux-2.6.28-picochip-3.2.0 Created: 2010-04-05 19:24:18 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1700808 Bytes = 1.6 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK
And then everything hangs. Should I play with moving around TEXT_BASE (0x05000000), linker files? I'm kind of stumped at the moment. :(
What makes you think this would be a U-Boot problem?
Because everything worked just fine before. I only ran into problems when I turned on the redundant environment.
A load address of 0x00008000 / entry point of 0x00008000 is pretty certainly bogus on a ARM system, which typically has ROM at this address range. Are you sure that you have unused RAM there on your system?
Yes, again, everything worked fine before.
I guess I wasn't clear on why I thought it was a RAM issue. The context of the u-boot README that talked about the REDUNDANT environment has a big warning right after it that talks about linker sections etc. This plus the malloc failing is what caused me to start thinking it might be something to do with memory, memory sections etc.
I noticed my malloc pool was only 128k so I changed that to 256 and it didn't help.
CFG_MONITOR_LEN is set to 256k, the same size as a flash sector.
I guess I could continue to increase the malloc pool but I'm not sure that is my problem since when I make the environment size the same as the sector size ... I get past the malloc problem but then the kernel does not boot and hangs. The good news is saveenv is working in the case where I make the environment length the same as the flash sector length.
Regards,
Brian
Dear Brian Hutchinson,
In message k2m3d1967ab1004080409w81bf0842pa84001760c214242@mail.gmail.com you wrote:
A load address of 0x00008000 / entry point of 0x00008000 is pretty certainly bogus on a ARM system, which typically has ROM at this address range. =A0Are you sure that you have unused RAM there on your system?
Yes, again, everything worked fine before.
But environment configuration has no influence on booting Linux, I think.
I noticed my malloc pool was only 128k so I changed that to 256 and it didn't help.
CFG_MONITOR_LEN is set to 256k, the same size as a flash sector.
Well, and what hapopens when you inclrease the malloc size to - say - 1024 kB ?
Best regards,
Wolfgang Denk
Hi Wolfgang,
I noticed my malloc pool was only 128k so I changed that to 256 and it didn't help.
CFG_MONITOR_LEN is set to 256k, the same size as a flash sector.
Well, and what hapopens when you inclrease the malloc size to - say - 1024 kB ?
About a hour before your post, I tried bumping it up to 512k and that made everything work!
So now I have bootcount implemented (using onboard SRAM since registers do not survive reset) and redundant environment working on ARM! Thanks again for your help!
Regards,
Brian
Sorry for the top post. Resending in plain text as original message was UTF-8
On Wed, Apr 7, 2010 at 11:14 AM, Brian Hutchinson b.hutchman@gmail.com wrote:
Hi,
I'm using u-boot 1.1.6 and have been using a single 256k flash sector for the environment. I want to use the redundant env. feature so I changed my config to:
#define CFG_ENV_IS_IN_FLASH 1 /* Environment variables stored in Flash memory */ #define CFG_ENV_ADDR (PC20X_BOOTABLE_FLASH_BASE+FLASH_SECTOR_SIZE) #define CFG_ENV_SECT_SIZE FLASH_SECTOR_SIZE /* One flash sector for environment info */ #define CFG_ENV_SIZE 0x10000 /* But 64K is sufficient */ //#define CFG_ENV_SIZE CFG_ENV_SECT_SIZE /* the whole sector */
/* Redundant environment */ #define CFG_ENV_ADDR_REDUND (CFG_ENV_ADDR + CFG_ENV_SECT_SIZE) #define CFG_ENV_SIZE_REDUND (CFG_ENV_SIZE)
#define CONFIG_ENV_OVERWRITE /* Turn off wite protection for vendor parameters */
When I use u-boot built with a CFG_ENV_SIZE of 0x10000 (what was working before I started) and enable CFG_ENV_ADDR_REDUND .... I get the following when trying to saveenv:
=> saveenv Saving Environment to Flash... Un-Protected 1 sectors Un-Protected 1 sectors Unable to save the rest of sector (196608) Protected 1 sectors Protected 1 sectors
My physical NOR flash is setup as: 0x20000000 = u-boot 0x20040000 = u-boot env. (the original env that works if I don't have redund turned on) 0x20080000 = u-boot redund env. (what I added)
I'm not certain what the problem is. I'm getting to the code in common/env_flash.c that has:
#if CFG_ENV_SECT_SIZE > CFG_ENV_SIZE up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE)); debug ("Data to save 0x%x\n", up_data); if (up_data) { if ((saved_data = malloc(up_data)) == NULL) { printf("Unable to save the rest of sector (%ld)\n", up_data); goto Done; } memcpy(saved_data, (void *)((long)flash_addr_new + CFG_ENV_SIZE), up_data); debug ("Data (start 0x%x, len 0x%x) saved at 0x%x\n", (long)flash_addr_new + CFG_ENV_SIZE, up_data, saved_data); } #endif
... which to my understanding is intended to allow you to save RAM by using a env. smaller than your sector size which is my case.
I've also tried to set CFG_ENV_SIZE to be the flash sector size which gets me over the above "Unable to save the rest of sector" problem but I suspect that I'm having RAM issues as I only have 128M RAM and am trying to use two environments of 256k each and the problem I'm having then becomes when I try to nfs boot my board .... it just hangs.
Any ideas on what I should check? The "Unable to save the rest of sector (196608)" is kind of strange as 196608 in hex is 0x30000 which is the sector u-boot lives in!
Regards,
Brian
Dear Brian Hutchinson,
In message y2o3d1967ab1004071745y111d704oda973290a7a4afa6@mail.gmail.com you wrote:
#if CFG_ENV_SECT_SIZE > CFG_ENV_SIZE up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE)); debug ("Data to save 0x%x\n", up_data); if (up_data) { if ((saved_data = malloc(up_data)) => = NULL) { printf("Unable to save the> rest of sector (%ld)\n", up_data); goto Done; } memcpy(saved_data, (void *)((long)flash_addr_> new + CFG_ENV_SIZE), up_data); debug ("Data (start 0x%x, len 0x%x) saved > at 0x%x\n", (long)flash_addr_new > + CFG_ENV_SIZE, up_data, s> aved_data); } #endif
... which to my understanding is intended to allow you to save RAM by using a env. smaller than your sector size which is my case.
This has nothing to do with saving RAM.
The thing is that with CFG_ENV_SECT_SIZE > CFG_ENV_SIZE, there might be important data in the part of the sector that is not occupied by the environment, so we must save and restore this content.
I've also tried to set CFG_ENV_SIZE to be the flash sector size which gets me over the above "Unable to save the rest of sector" problem but I suspect that I'm having RAM issues as I only have 128M RAM and am
128 MB of RAM is an awful lot.
trying to use two environments of 256k each and the problem I'm having then becomes when I try to nfs boot my board .... it just hangs.
Two copies of 256 kB each gives just a 0.4% of the available RAM - I don't understand why you think this might be a critical amount.
Best regards,
Wolfgang Denk
Hi Wolfgang,
... which to my understanding is intended to allow you to save RAM by using a env. smaller than your sector size which is my case.
This has nothing to do with saving RAM.
You are right (as usual). I was searching the archives before I started posting and I read something to make be think this way but when I just looked again I couldn't the post I was thinking of and instead found posts that explained the area after the environment getting saved off and restored ... I don't know how I missed that before ... tunnel vision I guess. So I have no idea why I thought that!
Regards,
Brian
participants (2)
-
Brian Hutchinson -
Wolfgang Denk