[U-Boot] [PATCH 0/6] omap3: overo: collected fixes

This series collects several board-enablement fixes for the Gumstix Overo as well as switching to BCH8 for NAND ECC, updating the UBI boot sequence for DTB-based boots, and correcting a RAM configuration for Overo COMs of Revision 0.
This series follows after the series previously submitted: http://lists.denx.de/pipermail/u-boot/2015-April/211651.html
Arun Bharadwaj (2): omap3: overo: Add DTS support for TobiDuo expansion overo: Override RAM setup for rev. 0 boards
Ash Charles (4): omap3: overo: Set the Arbor43C 'expansionname' overo: Add support for Palo35 expansion board omap3: overo: Use software BCH8 ECC for NAND omap3: overo: Allow boot with kernel in UBI rootfs
board/overo/overo.c | 3 +++ board/overo/spl.c | 2 +- include/configs/omap3_overo.h | 32 ++++++++++++++++++++++++++++---- 3 files changed, 32 insertions(+), 5 deletions(-)

The Gumstix Arbor43C expansion board [1] uses a customized device tree file. When this expansion board is detected, load this file.
[1] https://store.gumstix.com/index.php/products/635/
Signed-off-by: Ash Charles ashcharles@gmail.com --- board/overo/overo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/board/overo/overo.c b/board/overo/overo.c index 6253825..2845e7c 100644 --- a/board/overo/overo.c +++ b/board/overo/overo.c @@ -257,6 +257,7 @@ int misc_init_r(void) MUX_GUMSTIX(); MUX_ARBOR43C(); setenv("defaultdisplay", "lcd43"); + setenv("expansionname", "arbor43c"); break; case ETTUS_USRP_E: printf("Recognized Ettus Research USRP-E (rev %d %s)\n",

On Tue, Apr 28, 2015 at 04:17:50PM -0700, Ash Charles wrote:
The Gumstix Arbor43C expansion board [1] uses a customized device tree file. When this expansion board is detected, load this file.
[1] https://store.gumstix.com/index.php/products/635/
Signed-off-by: Ash Charles ashcharles@gmail.com
Applied to u-boot/master, thanks!

From: Arun Bharadwaj arun@gumstix.com
Signed-off-by: Arun Bharadwaj arun@gumstix.com Signed-off-by: Ash Charles ashcharles@gmail.com --- board/overo/overo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/board/overo/overo.c b/board/overo/overo.c index 2845e7c..3f14b03 100644 --- a/board/overo/overo.c +++ b/board/overo/overo.c @@ -185,6 +185,7 @@ int misc_init_r(void) expansion_config.revision, expansion_config.fab_revision); MUX_GUMSTIX(); + setenv("expansionname", "tobiduo"); break; case GUMSTIX_PALO35: printf("Recognized Palo35 expansion board (rev %d %s)\n",

On Tue, Apr 28, 2015 at 04:17:51PM -0700, Ash Charles wrote:
From: Arun Bharadwaj arun@gumstix.com
Signed-off-by: Arun Bharadwaj arun@gumstix.com Signed-off-by: Ash Charles ashcharles@gmail.com
Applied to u-boot/master, thanks!

Signed-off-by: Ash Charles ashcharles@gmail.com --- board/overo/overo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/board/overo/overo.c b/board/overo/overo.c index 3f14b03..d5ac1ad 100644 --- a/board/overo/overo.c +++ b/board/overo/overo.c @@ -193,6 +193,7 @@ int misc_init_r(void) expansion_config.fab_revision); MUX_GUMSTIX(); setenv("defaultdisplay", "lcd35"); + setenv("expansionname", "palo35"); break; case GUMSTIX_PALO43: printf("Recognized Palo43 expansion board (rev %d %s)\n",

On Tue, Apr 28, 2015 at 04:17:52PM -0700, Ash Charles wrote:
Signed-off-by: Ash Charles ashcharles@gmail.com
Applied to u-boot/master, thanks!

Overo COMs have NAND flash that requires 4-bit ECC or better except for the first sector which can use 1-bit ECC. The boot ROM expects to load a payload from NAND written using 1-bit hardware-based ECC. In short, write SPL to NAND something like this (4 times for redundancy): #> nandecc hw #> nand write ${loadaddr} 0x0 ${filesize} #> nand write ${loadaddr} 0x20000 ${filesize} #> nand write ${loadaddr} 0x40000 ${filesize} #> nand write ${loadaddr} 0x60000 ${filesize}
Then, switch back to software-based BCH8 for everything else: #> nandecc sw bch8
After [1], enlarge the max size of the SPL so the BCH code can fit.
[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg163912.html
Signed-off-by: Ash Charles ashcharles@gmail.com --- include/configs/omap3_overo.h | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index c58636a..61213df 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -11,6 +11,12 @@ #define CONFIG_NAND
#include <configs/ti_omap3_common.h> +#undef CONFIG_SPL_MAX_SIZE +#define CONFIG_SPL_MAX_SIZE (64*1024) +#undef CONFIG_SPL_TEXT_BASE +#define CONFIG_SPL_TEXT_BASE 0x40200000 + +#define CONFIG_BCH
/* Display CPU and Board information */ #define CONFIG_DISPLAY_CPUINFO @@ -212,17 +218,22 @@
/* NAND boot config */ #define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 +#define CONFIG_SYS_NAND_MAX_ECCPOS 56 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_OOBSIZE 64 #define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024) #define CONFIG_SYS_NAND_BAD_BLOCK_POS NAND_LARGE_BADBLOCK_POS -#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9,\ - 10, 11, 12, 13} +#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, \ + 13, 14, 16, 17, 18, 19, 20, 21, 22, \ + 23, 24, 25, 26, 27, 28, 30, 31, 32, \ + 33, 34, 35, 36, 37, 38, 39, 40, 41, \ + 42, 44, 45, 46, 47, 48, 49, 50, 51, \ + 52, 53, 54, 55, 56} #define CONFIG_SYS_NAND_ECCSIZE 512 -#define CONFIG_SYS_NAND_ECCBYTES 3 -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW +#define CONFIG_SYS_NAND_ECCBYTES 13 +#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x80000 /* NAND: SPL falcon mode configs */

On Tue, Apr 28, 2015 at 04:17:53PM -0700, Ash Charles wrote:
Overo COMs have NAND flash that requires 4-bit ECC or better except for the first sector which can use 1-bit ECC. The boot ROM expects to load a payload from NAND written using 1-bit hardware-based ECC. In short, write SPL to NAND something like this (4 times for redundancy): #> nandecc hw #> nand write ${loadaddr} 0x0 ${filesize} #> nand write ${loadaddr} 0x20000 ${filesize} #> nand write ${loadaddr} 0x40000 ${filesize} #> nand write ${loadaddr} 0x60000 ${filesize}
Then, switch back to software-based BCH8 for everything else: #> nandecc sw bch8
After [1], enlarge the max size of the SPL so the BCH code can fit.
[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg163912.html
Signed-off-by: Ash Charles ashcharles@gmail.com
Applied to u-boot/master, thanks!

If regular NAND booting fails to find a valid uImage in the kernel partition in NAND, try to boot using a zImage and dtb found in a UBI volume in the rootfs partition. This is the NAND analog of mmc zImage booting for device-tree based kernels.
Signed-off-by: Ash Charles ashcharles@gmail.com Signed-off-by: Arun Bharadwaj arun@gumstix.com --- include/configs/omap3_overo.h | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 61213df..e1db29a 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -140,6 +140,8 @@ "bootm ${loadaddr}\0" \ "loadzimage=load mmc ${mmcdev}:2 ${loadaddr} ${bootdir}/${bootfile}\0" \ "loadfdt=load mmc ${mmcdev}:2 ${fdtaddr} ${bootdir}/${fdtfile}\0" \ + "loadubizimage=ubifsload ${loadaddr} ${bootdir}/${bootfile}\0" \ + "loadubifdt=ubifsload ${fdtaddr} ${bootdir}/${fdtfile}\0" \ "mmcbootfdt=echo Booting with DT from mmc ...; " \ "run mmcargs; " \ "bootz ${loadaddr} - ${fdtaddr}\0" \ @@ -148,6 +150,13 @@ "if nand read ${loadaddr} linux; then " \ "bootm ${loadaddr};" \ "fi;\0" \ + "nanddtsboot=echo Booting from nand with DTS...; " \ + "run nandargs; " \ + "ubi part rootfs; "\ + "ubifsmount ubi0:rootfs; "\ + "run loadubifdt; "\ + "run loadubizimage; "\ + "bootz ${loadaddr} - ${fdtaddr}\0" \
#define CONFIG_BOOTCOMMAND \ "mmc dev ${mmcdev}; if mmc rescan; then " \ @@ -175,6 +184,10 @@ "fi;" \ "fi;" \ "run nandboot; " \ + "if test -z "${fdtfile}"; then "\ + "setenv fdtfile omap3-${boardname}-${expansionname}.dtb;" \ + "fi;" \ + "run nanddtsboot; " \
/* * Miscellaneous configurable options

On Tue, Apr 28, 2015 at 04:17:54PM -0700, Ash Charles wrote:
If regular NAND booting fails to find a valid uImage in the kernel partition in NAND, try to boot using a zImage and dtb found in a UBI volume in the rootfs partition. This is the NAND analog of mmc zImage booting for device-tree based kernels.
Signed-off-by: Ash Charles ashcharles@gmail.com Signed-off-by: Arun Bharadwaj arun@gumstix.com
Applied to u-boot/master, thanks!

From: Arun Bharadwaj arun@gumstix.com
Overo boards with board revision 0 use a 256MB RAM + 256MB NAND chip. For an unknown reason, these boards fail to boot a 3.17.8 kernel based on the RAM size configuration in u-boot. As a workaround, fake out the RAM setting in u-boot (discussion [1]).
[1] http://gumstix.8.x6.nabble.com/running-built-images-tt4969794.html
Signed-off-by: Arun Bharadwaj arun@gumstix.com Signed-off-by: Ash Charles ashcharles@gmail.com --- board/overo/spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/overo/spl.c b/board/overo/spl.c index 64c33d6..e1652c3 100644 --- a/board/overo/spl.c +++ b/board/overo/spl.c @@ -59,7 +59,7 @@ void get_board_mem_timings(struct board_sdrc_timings *timings) timings->mr = MICRON_V_MR_165; switch (get_board_revision()) { case REVISION_0: /* Micron 1286MB/256MB, 1/2 banks of 128MB */ - timings->mcfg = MICRON_V_MCFG_165(128 << 20); + timings->mcfg = MICRON_V_MCFG_165(256 << 20); timings->ctrla = MICRON_V_ACTIMA_165; timings->ctrlb = MICRON_V_ACTIMB_165; timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;

On Tue, Apr 28, 2015 at 04:17:55PM -0700, Ash Charles wrote:
From: Arun Bharadwaj arun@gumstix.com
Overo boards with board revision 0 use a 256MB RAM + 256MB NAND chip. For an unknown reason, these boards fail to boot a 3.17.8 kernel based on the RAM size configuration in u-boot. As a workaround, fake out the RAM setting in u-boot (discussion [1]).
[1] http://gumstix.8.x6.nabble.com/running-built-images-tt4969794.html
Signed-off-by: Arun Bharadwaj arun@gumstix.com Signed-off-by: Ash Charles ashcharles@gmail.com
Just for the record (since I just dug into it), this change was included in the v2 of the series that created board/overo/spl.c and thus not needed.

Ah---good catch. Thanks for the explanation Tom. --Ash
On Sun, May 10, 2015 at 7:07 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Apr 28, 2015 at 04:17:55PM -0700, Ash Charles wrote:
From: Arun Bharadwaj arun@gumstix.com
Overo boards with board revision 0 use a 256MB RAM + 256MB NAND chip. For an unknown reason, these boards fail to boot a 3.17.8 kernel based on the RAM size configuration in u-boot. As a workaround, fake out the RAM setting in u-boot (discussion [1]).
[1] http://gumstix.8.x6.nabble.com/running-built-images-tt4969794.html
Signed-off-by: Arun Bharadwaj arun@gumstix.com Signed-off-by: Ash Charles ashcharles@gmail.com
Just for the record (since I just dug into it), this change was included in the v2 of the series that created board/overo/spl.c and thus not needed.
-- Tom
participants (2)
-
Ash Charles
-
Tom Rini