[U-Boot] Can I read env from RAM in uboot script?

[U-Boot] Can I read env from RAM in uboot script?

[John Stile]

Is it possible to have uboot read it's environment from a RAM address,
rather than NAND?
OR
Can uboot's scripting support load variables from a RAM address?

My NAND layout has redundant halves:
0
  uboot
  ubootenv
  kernel
  fs
128
  uboot
  ubootenv
  kernel
  fs 
256

My firmware update strategy will update the non-booted side of NAND.

It is easy to hack at91bootstrap, to load a uboots env area at some
RAM address, just as it loads uboot at JUMP_ADDR, but how do I get uboot
to use this preloaded uboot-env?

Since uboot takes its environment area address at compile time, I wonder
if uboot could be made to read it from a RAM address (written there by
at91bootstrap), durring the env_relocate_spec()?

So far I have traced:
cpu/arm926ejs/start.S  calls start_armboot()
lib_arm/board.c start_armboot() calls env_relocate()
./common/env_common.c env_relocate() calls env_relocate_spec()
My u-boot.map indicates my env_relocate_spec() comes from env_nand.o
./common/env_nand.c has env_relocate_spec() has ifdefs for
ENV_IS_EMBEDDED, but my config is not.  and CFG_ENV_IS_IN_NAND which I
am currently configured for. 

So where is a good point of attack, or is there one?

[U-Boot] Can I read env from RAM in uboot script?

[Wolfgang Denk]

Dear John Stile,

In message <1359165410.7974.114.camel@genx> you wrote:
> Is it possible to have uboot read it's environment from a RAM address,
> rather than NAND?
> OR
> Can uboot's scripting support load variables from a RAM address?

Yes, all this can be done.  And easily.  See for example the
"env import" command.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates

[U-Boot] Can I read env from RAM in uboot script?

[John Stile]

On Sat, 2013-01-26 at 08:41 +0100, Wolfgang Denk wrote:
> Dear John Stile,
> 
> In message <1359165410.7974.114.camel@genx> you wrote:
> > Is it possible to have uboot read it's environment from a RAM address,
> > rather than NAND?
> > OR
> > Can uboot's scripting support load variables from a RAM address?
> 
> Yes, all this can be done.  And easily.  See for example the
> "env import" command.
> 
That is a great idea.
What version of uboot introduced 'env import'?
I'm stuck on u-boot-1.3.4.
Is there a patch?

[U-Boot] Can I read env from RAM in uboot script?

[Jeroen Hofstee]

Hello John,

On 01/28/2013 10:19 PM, John Stile wrote:
> On Sat, 2013-01-26 at 08:41 +0100, Wolfgang Denk wrote:
>> Dear John Stile,
>>
>> In message <1359165410.7974.114.camel@genx> you wrote:
>>> Is it possible to have uboot read it's environment from a RAM address,
>>> rather than NAND?
>>> OR
>>> Can uboot's scripting support load variables from a RAM address?
>> Yes, all this can be done.  And easily.  See for example the
>> "env import" command.
>>
> That is a great idea.
> What version of uboot introduced 'env import'?
> I'm stuck on u-boot-1.3.4.
> Is there a patch?
>
search the mailinglist, this is asking for a visit to
http://www.uboat.net/special/archiv/ or a response the
like. Try to upgrade if possible...

Regards,
Jeroen

[U-Boot] Can I read env from RAM in uboot script?

[Jeroen Hofstee]

> On 01/28/2013 10:19 PM, John Stile wrote:
>> On Sat, 2013-01-26 at 08:41 +0100, Wolfgang Denk wrote:
>>> Dear John Stile,
>>>
>>> In message <1359165410.7974.114.camel@genx> you wrote:
>>>> Is it possible to have uboot read it's environment from a RAM address,
>>>> rather than NAND?
>>>> OR
>>>> Can uboot's scripting support load variables from a RAM address?
>>> Yes, all this can be done.  And easily.  See for example the
>>> "env import" command.
>>>
>> That is a great idea.
>> What version of uboot introduced 'env import'?
>> I'm stuck on u-boot-1.3.4.
>> Is there a patch?
>>
> search the mailinglist, this is asking for a visit to
> http://www.uboat.net/special/archiv/ or a response the
> like. Try to upgrade if possible...

for completeness sake, Wolfgang will likely tell you it is museum material,
since it is almost 5 years old. No idea what the site is about, just popped
up with "u-boot museum" instead of Wolfgang's replies.

Regards,
Jeroen

[U-Boot] Can I read env from RAM in uboot script?

[John Stile]

On Mon, 2013-01-28 at 23:01 +0100, Jeroen Hofstee wrote:
> > On 01/28/2013 10:19 PM, John Stile wrote:
> >> On Sat, 2013-01-26 at 08:41 +0100, Wolfgang Denk wrote:
> >>> Dear John Stile,
> >>>
> >>> In message <1359165410.7974.114.camel@genx> you wrote:
> >>>> Is it possible to have uboot read it's environment from a RAM address,
> >>>> rather than NAND?
> >>>> OR
> >>>> Can uboot's scripting support load variables from a RAM address?
> >>> Yes, all this can be done.  And easily.  See for example the
> >>> "env import" command.
> >>>
> >> That is a great idea.
> >> What version of uboot introduced 'env import'?
> >> I'm stuck on u-boot-1.3.4.
> >> Is there a patch?
> >>
> > search the mailinglist, this is asking for a visit to
> > http://www.uboat.net/special/archiv/ or a response the
> > like. Try to upgrade if possible...
> 
> for completeness sake, Wolfgang will likely tell you it is museum material,
> since it is almost 5 years old. No idea what the site is about, just popped
> up with "u-boot museum" instead of Wolfgang's replies.
> 
I saw that.

I tried to update u-boot-1.3.4 to u-boot-2013.

I changed at91bootstrap's JUMP_ADDR from 0x23F00000 to 0x21F00000, as
advised by previous posts.

Now I am getting the wrong board type error from the kernel.
my board is an AT91SAM9G20EK_2MMC

I am having a hard time setting:
#define MACH_TYPE_AT91SAM9G20EK_2MMC   2288
insted of 
#define MACH_TYPE_AT91SAM9G20EK        1624

In had to change buildroot's .config from:
BR2_TARGET_UBOOT_BOARDNAME="at91sam9g20ek_2mmc_nandflash"
to
BR2_TARGET_UBOOT_BOARDNAME="at91sam9g20ek_nandflash"
whihch I suspect is the problem.

I'm trying to change the buildroots output/build/uboot-custom manually,
and rerun the build, but no luck yet.

My kernel is built with CONFIG_MACH_AT91SAM9G20EK_2MMC=y

So how do I force u-boot to agree?

[U-Boot] Can I read env from RAM in uboot script?

[Bo Shen]

Hi John Stile,

On 01/29/2013 08:25 AM, John Stile wrote:
[snip]
> I saw that.
>
> I tried to update u-boot-1.3.4 to u-boot-2013.
>
> I changed at91bootstrap's JUMP_ADDR from 0x23F00000 to 0x21F00000, as
> advised by previous posts.
>
> Now I am getting the wrong board type error from the kernel.
> my board is an AT91SAM9G20EK_2MMC
>
> I am having a hard time setting:
> #define MACH_TYPE_AT91SAM9G20EK_2MMC   2288
> insted of
> #define MACH_TYPE_AT91SAM9G20EK        1624
>
> In had to change buildroot's .config from:
> BR2_TARGET_UBOOT_BOARDNAME="at91sam9g20ek_2mmc_nandflash"
> to
> BR2_TARGET_UBOOT_BOARDNAME="at91sam9g20ek_nandflash"
> whihch I suspect is the problem.
>
> I'm trying to change the buildroots output/build/uboot-custom manually,
> and rerun the build, but no luck yet.
>
> My kernel is built with CONFIG_MACH_AT91SAM9G20EK_2MMC=y
>
> So how do I force u-boot to agree?

Please have test with the following patch (add at91sam9g20ek 2mmc 
nandflash boot support) and check whether it will solve you problem.

You should use at91sam9g20ek_2mmc_nandflash to configure the u-boot

------------------------------------------------
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c 
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 2555672..ce475df 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -157,6 +157,10 @@ int board_early_init_f(void)

  int board_init(void)
  {
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+       /* arch number of AT91SAM9260EK-Board */
+       gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
  #ifdef CONFIG_AT91SAM9G20EK
         /* arch number of AT91SAM9260EK-Board */
         gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@ int board_init(void)
         /* arch number of AT91SAM9260EK-Board */
         gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
  #endif
+#endif
         /* adress of boot parameters */
         gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;

diff --git a/boards.cfg b/boards.cfg
index e4b0d44..fa863dc 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -95,6 +95,7 @@ at91sam9g10ek_nandflash      arm         arm926ejs 
at91sam9261ek       atmel
  at91sam9g20ek_dataflash_cs0  arm         arm926ejs   at91sam9260ek 
    atmel          at91 
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
  at91sam9g20ek_dataflash_cs1  arm         arm926ejs   at91sam9260ek 
    atmel          at91 
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
  at91sam9g20ek_nandflash      arm         arm926ejs   at91sam9260ek 
    atmel          at91        at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
+at91sam9g20ek_2mmc_nandflash arm         arm926ejs   at91sam9260ek 
   atmel          at91 
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
  at91sam9m10g45ek_nandflash   arm         arm926ejs   at91sam9m10g45ek 
    atmel          at91 
at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
  at91sam9rlek_dataflash       arm         arm926ejs   at91sam9rlek 
    atmel          at91        at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
  at91sam9rlek_nandflash       arm         arm926ejs   at91sam9rlek 
    atmel          at91        at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
---------------------------------------------------------------------------

Best Regards,
Bo Shen

[U-Boot] Can I read env from RAM in uboot script?

[John Stile]

On Tue, 2013-01-29 at 17:58 +0800, Bo Shen wrote:
> 
> You should use at91sam9g20ek_2mmc_nandflash to configure the u-boot
> 
> ------------------------------------------------
> diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c 
> b/board/atmel/at91sam9260ek/at91sam9260ek.c
> index 2555672..ce475df 100644
> --- a/board/atmel/at91sam9260ek/at91sam9260ek.c
> +++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
> @@ -157,6 +157,10 @@ int board_early_init_f(void)
> 
>   int board_init(void)
>   {
> +#ifdef CONFIG_AT91SAM9G20EK_2MMC
> +       /* arch number of AT91SAM9260EK-Board */
> +       gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
> +#else
>   #ifdef CONFIG_AT91SAM9G20EK
>          /* arch number of AT91SAM9260EK-Board */
>          gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
> @@ -164,6 +168,7 @@ int board_init(void)
>          /* arch number of AT91SAM9260EK-Board */
>          gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
>   #endif
> +#endif
>          /* adress of boot parameters */
>          gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
> 
> diff --git a/boards.cfg b/boards.cfg
> index e4b0d44..fa863dc 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -95,6 +95,7 @@ at91sam9g10ek_nandflash      arm         arm926ejs 
> at91sam9261ek       atmel
>   at91sam9g20ek_dataflash_cs0  arm         arm926ejs   at91sam9260ek 
>     atmel          at91 
> at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
>   at91sam9g20ek_dataflash_cs1  arm         arm926ejs   at91sam9260ek 
>     atmel          at91 
> at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
>   at91sam9g20ek_nandflash      arm         arm926ejs   at91sam9260ek 
>     atmel          at91
> at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
> +at91sam9g20ek_2mmc_nandflash arm         arm926ejs   at91sam9260ek 
>    atmel          at91 
> at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
>   at91sam9m10g45ek_nandflash   arm         arm926ejs
> at91sam9m10g45ek 
>     atmel          at91 
> at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
>   at91sam9rlek_dataflash       arm         arm926ejs   at91sam9rlek 
>     atmel          at91
> at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
>   at91sam9rlek_nandflash       arm         arm926ejs   at91sam9rlek 
>     atmel          at91
> at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
> ---------------------------------------------------------------------------
> 
> 
That worked!  Very nice!  But, I had to apply the patches manually.
Email may have messed up the patch sets with new-lines and indentation.
Can this be added to the main stream?  I am on to learning 'env import'.
Thank you.

If email messed it up once, I guess it could mess it up again, but I
generated patches using:
  diff -Naur before/ after/ > diff.patch

--- board/atmel/at91sam9260ek/at91sam9260ek.c.orig    2013-01-29 09:09:35.000000000 -0800
+++ board/atmel/at91sam9260ek/at91sam9260ek.c 2013-01-29 09:10:46.000000000 -0800
@@ -157,6 +157,10 @@
 
 int board_init(void)
 {
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+       /* arch number of AT91SAM9260EK-Board */
+       gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
 #ifdef CONFIG_AT91SAM9G20EK
        /* arch number of AT91SAM9260EK-Board */
        gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@
        /* arch number of AT91SAM9260EK-Board */
        gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
 #endif
+#endif
        /* adress of boot parameters */
        gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
--- boards.cfg.orig   2013-01-29 08:56:47.000000000 -0800
+++ boards.cfg        2013-01-29 08:58:21.000000000 -0800
@@ -94,6 +94,7 @@
 at91sam9g10ek_nandflash      arm         arm926ejs   at91sam9261ek       atmel          at91        at91sam9261ek:AT91SAM9G10,SYS_USE_NANDFLASH
 at91sam9g20ek_dataflash_cs0  arm         arm926ejs   at91sam9260ek       atmel          at91        at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
 at91sam9g20ek_dataflash_cs1  arm         arm926ejs   at91sam9260ek       atmel          at91        at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
+at91sam9g20ek_2mmc_nandflash arm         arm926ejs   at91sam9260ek       atmel          at91        at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
 at91sam9g20ek_nandflash      arm         arm926ejs   at91sam9260ek       atmel          at91        at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
 at91sam9m10g45ek_nandflash   arm         arm926ejs   at91sam9m10g45ek    atmel          at91        at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
 at91sam9rlek_dataflash       arm         arm926ejs   at91sam9rlek        atmel          at91        at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH

[U-Boot] Can I read env from RAM in uboot script?

[Bo Shen]

Hi John Stile,

On 01/30/2013 01:33 AM, John Stile wrote:
> That worked!  Very nice!  But, I had to apply the patches manually.
> Email may have messed up the patch sets with new-lines and indentation.
> Can this be added to the main stream?  I am on to learning 'env import'.
> Thank you.

I will prepare the patch and send to u-boot mainline.

> If email messed it up once, I guess it could mess it up again, but I
> generated patches using:
>    diff -Naur before/ after/>  diff.patch

I think this can not be applied to u-boot mainline directly, because it 
missed comments and author, and etc.

Best Regards,
Bo Shen

[U-Boot] Can I read env from RAM in uboot script?

[Wolfgang Denk]

Dear Jeroen Hofstee,

In message <5106F529.2030407@myspectrum.nl> you wrote:
> 
> >> I'm stuck on u-boot-1.3.4.
> >> Is there a patch?
> >>
> > search the mailinglist, this is asking for a visit to
> > http://www.uboat.net/special/archiv/ or a response the
> > like. Try to upgrade if possible...
> 
> for completeness sake, Wolfgang will likely tell you it is museum material,
> since it is almost 5 years old. No idea what the site is about, just popped
> up with "u-boot museum" instead of Wolfgang's replies.

No surprise.  Museums were not invented yet by the time when v1.3.4
was current ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn