[U-Boot] [PATCH RFC] drivers/rtc: add Marvell Integrated RTC.

[Jason]

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.