On Mon, 2 Feb 2009, Wolfgang Denk wrote: > Dear Guennadi Liakhovetski, > > In message <pine.lnx.4.64.0902021725100.4...@axis700.grange> you wrote: > > > > -#ifdef ENV_IS_EMBEDDED > > +#if defined(ENV_IS_EMBEDDED) > > extern uchar environment[]; > > env_t *env_ptr = (env_t *)(&environment[0]); > > +#elif defined(CFG_ENV_IS_APPENDED) > > What makes you think an "appended" environment is so special that it > is worth a separate #ifdef here? What about a prepended environment? > Or one two sectors apart?
Ok, agree, the name is badly chosen. The real restriction of this specific implementation is that the environment must be on the same NAND chip as the one we are booting from. Any location on that chip can be handled, I think. > > -#if defined(ENV_IS_EMBEDDED) > > - size_t total; > > +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED) > > int crc1_ok = 0, crc2_ok = 0; > > - env_t *tmp_env1, *tmp_env2; > > + env_t *tmp_env1; > > > > Note that there is a fundamental difference between embedded and > non-embedded (in whatever which way) environments, but I can see no > significant difference between an "appended" or a "prepended" or > otherwise separate environment. The reason they share the same #if case here is that both get initialised early, not as was only possible until now on NAND - after all initcalls. > Maybe you try to explain what you have in mind with this > special-casing here? > > And I don't understand the rest of your implementation either. Please > explain... Ok, currently environment in NAND has two cases: 1. embedded, in this case the real environment is initialised at env_init() time, otherwise first default environment is used 2. other, env_init() initialises the default environment, the real (stored in NAND) environment is first activated at env_relocate() time. With this patch we add one more case 3. environment, located on the same NAND chip as the boot NAND. in this case we can also let the nand_spl code load it for is in RAM and then we can use it in env_init(). > > diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h > > index 1ee4191..3acf7cd 100644 > > --- a/include/configs/smdk6400.h > > +++ b/include/configs/smdk6400.h > > @@ -223,6 +224,8 @@ > > #define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e00000) > > > > #define CFG_ENV_OFFSET 0x0040000 > > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */ > > +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x80000) > > ???? What's that? What has BSS to do with the environment storage ??? This is smdk6400 header, on this board I chose to place the environment read in by nand_spl above bss, because, AFAIU, the area above __bss_end is unused by u-boot. But I didn't find an easy way to pass a calculated value from u-boot proper to nand_spl or vice versa. As you know, these two objects use saparate linker scripts and are linked absolutely independently, and just cat'ed together in the end. So, I had to use a macro to specify the location of the environment copy in RAM instead of calculating it precisely. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot