On Wed, 17 Nov 2010 21:58:31 +0100 Wolfgang Denk <w...@denx.de> wrote:
> Dear Kumar Gala, > > In message <1290008461-21171-1-git-send-email-ga...@kernel.crashing.org> you > wrote: > > We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC > > and utilize a L2 or L3 cache in SRAM mode. In this case we will > > end up changing the cache from SRAM mode back to cache before we > > relocate the environment properly in env_relocate(). > > > > So we need to manual relocate the env pointer out of SRAM into DDR. > > > > Signed-off-by: Kumar Gala <ga...@kernel.crashing.org> > > --- > > arch/powerpc/lib/board.c | 12 ++++++++++++ > > 1 files changed, 12 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c > > index 2e0749d..5ce9caa 100644 > > --- a/arch/powerpc/lib/board.c > > +++ b/arch/powerpc/lib/board.c > > @@ -645,6 +645,18 @@ void board_init_r (gd_t *id, ulong dest_addr) > > gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; > > #endif > > > > +#if defined(CONFIG_MPC85xx) && defined(CONFIG_SYS_RAMBOOT) > > + /* > > + * We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC > > I think this is a bad misuse of the CONFIG_SYS_RAMBOOT variable here. > Assume I have a 85xx system where U-Boot gets loaded by some means > into DDR. Of course I will have CONFIG_MPC85xx and CONFIG_SYS_RAMBOOT > set, but I do not want in any way that this special mechanism kicks > in. Instead of trying to guess whether this is a boot scenario that needs this, how about checking env_addr to see if it falls within the bounds of the old image? If so, relocate it. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
