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