[U-Boot] Can I read env from RAM in uboot script?
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?
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
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?
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
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
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?
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
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
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
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
participants (4)
-
Bo Shen -
Jeroen Hofstee -
John Stile -
Wolfgang Denk