On Sun, Jul 24, 2011 at 03:13:38PM -0400, Jason wrote:
To write a u-boot.kwb test image to flash, here is what I do:
openocd$ sheevaplug_init openocd$ load_image u-boot # known good from Marvell openocd$ load_image u-boot.kwb 0x00800000 # monster I created openocd$ resume 0x00600000 # run the known good
then, in u-boot
u-boot$ sf probe 0 u-boot$ sf erase 0x0 0x100000 u-boot$ sf write 0x00800000 0x0 0x100000
Okay, here's neat problem. In the globalscale u-boot code, they set the environment address to 0x30000 in the 2MB spi nor flash. So, they have:
#ifdef CONFIG_SPI_FLASH #define CONFIG_ENV_IS_IN_SPI_FLASH 1 #define CONFIG_ENV_SECT_SIZE 0x10000 /* 64K */ #else #define CONFIG_ENV_IS_NOWHERE 1 /* if env in SDRAM */ #endif
and...
#define CONFIG_ENV_SIZE 0x1000 /* 4k */ #define CONFIG_ENV_ADDR 0x30000 #define CONFIG_ENV_OFFSET 0x30000 /* env starts here */
If that's an absolute address, and I wrote my u-boot to 0x0 in the flash, did 'saveenv' to remove the CRC message, then that's why it died after reset, right? I must have overwrote part of u-boot with the env.
In my meager understanding, I thought maybe u-boot structured itself so the env was physically stored 0x30000 into the code and it would magically work. Guess not. :-P
So, what is a standard flash layout? Do I put u-boot at 0x0 and just throw the env out at 0x100000 (1MB), or, put the env at 0x0 and u-boot in the second erase block (0x10000)? Doesn't u-boot have to be at 0x0 so the cpu can find it?
Thanks for any advice.
btw - I have everything else tested and working. RTC, spi flash, cpu speed, etc. This issue is the last holdout before I resubmit v5.
thx,
Jason.