[U-Boot] [PATCH 0/6] sbc8641d: misc fixes and generic board enablement
The sbc8641d is not really a state of the art board anymore, but it does have the distinctive feature of being one of the relatively few SMP powerpc boards around. Combined with its small form factor, it remains a useful testing platform. So here we enable the generic board support so that it can remain in tree.
It turns out that in bringing the board forward, we've run into the size limit for the image, due to inevitable expansion, which led to some odd testing behaviour, depending on .config settings etc. Here we increase the image space from two 128k sectors to three, so we should be good for as long as the board remains relevant now.
---
[v2: add patch for extra sector for image ; retest on master]
Paul Gortmaker (6): sbc8641d: enable command line editing sbc8641d: increase malloc pool size to a sane default sbc8641d: set proper environment sector size. sbc8641d: add basic flash setup instructions to README file sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD sbc8641d: increase monitor size from 256k to 384k
board/sbc8641d/README | 23 ++++++++++++++++++++++- include/configs/sbc8641d.h | 11 +++++++---- 2 files changed, 29 insertions(+), 5 deletions(-)
It is just too painful to use interactively without it.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- include/configs/sbc8641d.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 00aab6b3d51d..b4466bc3b4c8 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -494,6 +494,7 @@ */ #define CONFIG_SYS_LONGHELP /* undef to save memory */ #define CONFIG_SYS_LOAD_ADDR 0x2000000 /* default load address */ +#define CONFIG_CMDLINE_EDITING 1 /* add command line history */
#if defined(CONFIG_CMD_KGDB) #define CONFIG_SYS_CBSIZE 1024 /* Console I/O Buffer Size */
On Sat, Oct 17, 2015 at 04:40:26PM -0400, Paul Gortmaker wrote:
It is just too painful to use interactively without it.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Applied to u-boot/master, thanks!
Currently the board fails to save its env, since the env size is much smaller than the sector size, and the malloc fails for the pad buffer, giving the user visible symptom of:
Unable to save the rest of sector (253952)
Allow for 1M malloc pool, the same as used on the sbc8548 board.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- include/configs/sbc8641d.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index b4466bc3b4c8..d248eff42005 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -242,7 +242,7 @@ #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET
#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ -#define CONFIG_SYS_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ +#define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* Reserved for malloc */
/* Serial Port */ #define CONFIG_CONS_INDEX 1
On Sat, Oct 17, 2015 at 04:40:27PM -0400, Paul Gortmaker wrote:
Currently the board fails to save its env, since the env size is much smaller than the sector size, and the malloc fails for the pad buffer, giving the user visible symptom of:
Unable to save the rest of sector (253952)
Allow for 1M malloc pool, the same as used on the sbc8548 board.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Applied to u-boot/master, thanks!
When debugging an env fail due to too small a malloc pool, it was noted that the env write was 256k. But the device sector size is 1/2 that, as can be seen from "fli" output:
Bank # 1: CFI conformant flash (16 x 16) Size: 16 MB in 131 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1888 Erase timeout: 4096 ms, write timeout: 1 ms Buffer write timeout: 2 ms, buffer size: 64 bytes
Sector Start Addresses: FF000000 E RO FF020000 E RO FF040000 E RO FF060000 E RO FF080000 E RO FF0A0000 E RO FF0C0000 E RO FF0E0000 E RO FF100000 E RO FF120000 E RO [...] FFF00000 RO FFF20000 RO FFF40000 RO FFF60000 RO FFF80000 RO FFFA0000 RO FFFC0000 RO FFFE0000 E RO FFFE8000 RO FFFF0000 E RO FFFF8000 RO =>
The desired env sector is FFF40000->FFF60000, or 0x20000 in length, just after the 256k u-boot image which starts @ FFF00000.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- include/configs/sbc8641d.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index d248eff42005..9fe90f00ff2a 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -473,7 +473,7 @@ */ #define CONFIG_ENV_IS_IN_FLASH 1 #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x40000) -#define CONFIG_ENV_SECT_SIZE 0x40000 /* 256K(one sector) for env */ +#define CONFIG_ENV_SECT_SIZE 0x20000 /* 128k(one sector) for env */ #define CONFIG_ENV_SIZE 0x2000
#define CONFIG_LOADS_ECHO 1 /* echo on for serial download */
On Sat, Oct 17, 2015 at 04:40:28PM -0400, Paul Gortmaker wrote:
When debugging an env fail due to too small a malloc pool, it was noted that the env write was 256k. But the device sector size is 1/2 that, as can be seen from "fli" output:
Bank # 1: CFI conformant flash (16 x 16) Size: 16 MB in 131 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1888 Erase timeout: 4096 ms, write timeout: 1 ms Buffer write timeout: 2 ms, buffer size: 64 bytes
Sector Start Addresses: FF000000 E RO FF020000 E RO FF040000 E RO FF060000 E RO FF080000 E RO FF0A0000 E RO FF0C0000 E RO FF0E0000 E RO FF100000 E RO FF120000 E RO [...] FFF00000 RO FFF20000 RO FFF40000 RO FFF60000 RO FFF80000 RO FFFA0000 RO FFFC0000 RO FFFE0000 E RO FFFE8000 RO FFFF0000 E RO FFFF8000 RO =>
The desired env sector is FFF40000->FFF60000, or 0x20000 in length, just after the 256k u-boot image which starts @ FFF00000.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Applied to u-boot/master, thanks!
...so that I don't have to go work them out from scratch again by peering at the manual.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- board/sbc8641d/README | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
diff --git a/board/sbc8641d/README b/board/sbc8641d/README index a051466a11b0..af180888182d 100644 --- a/board/sbc8641d/README +++ b/board/sbc8641d/README @@ -26,3 +26,24 @@ and settings may change with board revisions. -------------------- PCI: The PCI command may hang if no boards are present in either slot. + +4. Reflashing U-Boot +-------------------- +The board has two independent flash devices which can be used for dual +booting, or for u-boot backup and recovery. A two pin jumper on the +three pin JP10 determines which device is attached to /CS0 line. + +Assuming one device has a functional u-boot, and the other device has +a recently installed non-functional image, to perform a recovery from +that non-functional image goes essentially as follows: + +a) power down the board and jumper JP10 to select the functional image. +b) power on the board and let it get to u-boot prompt. +c) while on, using static precautions, move JP10 back to the failed image. +d) use "md fff00000" to confirm you are looking at the failed image +e) turn off write protect with "prot off all" +f) get new image, i.e. "tftp 200000 /somepath/u-boot.bin" +g) erase failed image: "erase FFF00000 FFF3FFFF" +h) copy in new image: "cp.b 200000 FFF00000 40000" +i) ensure new image is written: "md fff00000" +k) power cycle the board and confirm new image works.
On Sat, Oct 17, 2015 at 04:40:29PM -0400, Paul Gortmaker wrote:
...so that I don't have to go work them out from scratch again by peering at the manual.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Applied to u-boot/master, thanks!
Tested on commit 3ea0953d36023d7e50fb00b2e258d8fb2828aeac ("dm: Move pre-reloc init earlier to cope with board_early_init_f()") since the commit after that ("Set up stdio earlier when using driver model") hangs this board at "Net:" init, just like it hangs the sbc8548 board[1]. So, until that is resolved, this will be the newest functional baseline for both boards.
Boot up looks as follows:
------------------------------- U-Boot 2014.10-rc2-00061-gb5e69635dc20 (Aug 24 2015 - 12:20:40)
CPU: 8641D, Version: 2.0, (0x80900120) Core: e600 Core 0, Version: 2.2, (0x80040202) Clock Configuration: CPU:1000 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled L2: 512 KiB enabled I2C: ready DRAM: 512 MiB Flash: 16 MiB SRIO1: disabled PCIe1: Root Complex, no link, regs @ 0xf8008000 PCIe1: Bus 00 - 00 PCIe2: Root Complex, no link, regs @ 0xf8009000 PCIe2: Bus 01 - 01 In: serial Out: serial Err: serial Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 Hit any key to stop autoboot: 0 => ver
U-Boot 2014.10-rc2-00061-gb5e69635dc20 (Aug 24 2015 - 12:20:40) powerpc-linux-gcc (GCC) 4.5.2 GNU ld (GNU Binutils) 2.21 => -------------------------------
As can be seen, the "generic" banner warning message is now gone.
[1] sbc8548 hang: https://www.marc.info/?l=u-boot&m=142655649417364&w=3
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- include/configs/sbc8641d.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 9fe90f00ff2a..2f3ec2e20088 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -20,6 +20,8 @@ #ifndef __CONFIG_H #define __CONFIG_H
+#define CONFIG_SYS_GENERIC_BOARD + /* High Level Configuration Options */ #define CONFIG_MPC8641 1 /* MPC8641 specific */ #define CONFIG_SBC8641D 1 /* SBC8641D board specific */
On Sat, Oct 17, 2015 at 04:40:30PM -0400, Paul Gortmaker wrote:
[nuked most of the commit message as it's now not true]
Applied to u-boot/master, thanks!
On 2015-10-19 08:07 PM, Tom Rini wrote:
On Sat, Oct 17, 2015 at 04:40:30PM -0400, Paul Gortmaker wrote:
[nuked most of the commit message as it's now not true]
Ah crap, I forgot to get rid of that; thanks for tossing it.
P. --
Applied to u-boot/master, thanks!
Between 2015.07-rc1 and 2015.07-rc2 this board started silent boot failure. A bisect led to commit 6eed3786c68c8a49d ("net: Move the CMD_NET config to defconfigs"). This commit looks harmless in itself, but it did implicitly add a feature to the image which led to this:
u-boot$git describe 6eed3786c68c8a49d v2015.07-rc1-412-g6eed3786c68c ^^^
u-boot$ls -l ../41*/u-boot.bin -rwxrwxr-x 1 paul paul 261476 Oct 16 16:47 ../411/u-boot.bin -rwxrwxr-x 1 paul paul 266392 Oct 16 16:43 ../412/u-boot.bin u-boot$bc bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 256*1024 262144
i.e. we finally broke through the 256k monitor size. Jump it up to 384k and fix the hard coded value used in the env offset at the same time.
We were probably flirting with the 256k size issue without knowing it when testing on different baselines in earlier commits, but since this is all board specific, a rebase or reorder to put this commit 1st is of little value.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- board/sbc8641d/README | 6 +++--- include/configs/sbc8641d.h | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/board/sbc8641d/README b/board/sbc8641d/README index af180888182d..d07f1ccf7c33 100644 --- a/board/sbc8641d/README +++ b/board/sbc8641d/README @@ -3,7 +3,7 @@ Wind River SBC8641D reference board
Created 06/14/2007 Joe Hamman Copyright 2007, Embedded Specialties, Inc. -Copyright 2007 Wind River Systemes, Inc. +Copyright 2007 Wind River Systems, Inc. -----------------------------
1. Building U-Boot @@ -43,7 +43,7 @@ c) while on, using static precautions, move JP10 back to the failed image. d) use "md fff00000" to confirm you are looking at the failed image e) turn off write protect with "prot off all" f) get new image, i.e. "tftp 200000 /somepath/u-boot.bin" -g) erase failed image: "erase FFF00000 FFF3FFFF" -h) copy in new image: "cp.b 200000 FFF00000 40000" +g) erase failed image: "erase FFF00000 FFF5FFFF" +h) copy in new image: "cp.b 200000 FFF00000 60000" i) ensure new image is written: "md fff00000" k) power cycle the board and confirm new image works. diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 2f3ec2e20088..eed0f4975164 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -243,7 +243,7 @@ #define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET
-#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ +#define CONFIG_SYS_MONITOR_LEN (384 * 1024) /* Reserve 384 kB for Mon */ #define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* Reserved for malloc */
/* Serial Port */ @@ -474,7 +474,7 @@ * Environment */ #define CONFIG_ENV_IS_IN_FLASH 1 -#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x40000) +#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN) #define CONFIG_ENV_SECT_SIZE 0x20000 /* 128k(one sector) for env */ #define CONFIG_ENV_SIZE 0x2000
On Sat, Oct 17, 2015 at 04:40:31PM -0400, Paul Gortmaker wrote:
Between 2015.07-rc1 and 2015.07-rc2 this board started silent boot failure. A bisect led to commit 6eed3786c68c8a49d ("net: Move the CMD_NET config to defconfigs"). This commit looks harmless in itself, but it did implicitly add a feature to the image which led to this:
u-boot$git describe 6eed3786c68c8a49d v2015.07-rc1-412-g6eed3786c68c ^^^
u-boot$ls -l ../41*/u-boot.bin -rwxrwxr-x 1 paul paul 261476 Oct 16 16:47 ../411/u-boot.bin -rwxrwxr-x 1 paul paul 266392 Oct 16 16:43 ../412/u-boot.bin u-boot$bc bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 256*1024 262144
i.e. we finally broke through the 256k monitor size. Jump it up to 384k and fix the hard coded value used in the env offset at the same time.
We were probably flirting with the 256k size issue without knowing it when testing on different baselines in earlier commits, but since this is all board specific, a rebase or reorder to put this commit 1st is of little value.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Applied to u-boot/master, thanks!
On Sat, Oct 17, 2015 at 04:40:25PM -0400, Paul Gortmaker wrote:
The sbc8641d is not really a state of the art board anymore, but it does have the distinctive feature of being one of the relatively few SMP powerpc boards around. Combined with its small form factor, it remains a useful testing platform. So here we enable the generic board support so that it can remain in tree.
It turns out that in bringing the board forward, we've run into the size limit for the image, due to inevitable expansion, which led to some odd testing behaviour, depending on .config settings etc. Here we increase the image space from two 128k sectors to three, so we should be good for as long as the board remains relevant now.
Thanks for finding this. I am going to grab this for the release and I might re-word a commit or two. I have one ask tho, can you look at using CONFIG_BOARD_SIZE_LIMIT, perhaps in a generic way so that we catch more "oops, the board grew too big, run-time now will fail!" issues?
[Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 17:50) Tom Rini wrote:
On Sat, Oct 17, 2015 at 04:40:25PM -0400, Paul Gortmaker wrote:
The sbc8641d is not really a state of the art board anymore, but it does have the distinctive feature of being one of the relatively few SMP powerpc boards around. Combined with its small form factor, it remains a useful testing platform. So here we enable the generic board support so that it can remain in tree.
It turns out that in bringing the board forward, we've run into the size limit for the image, due to inevitable expansion, which led to some odd testing behaviour, depending on .config settings etc. Here we increase the image space from two 128k sectors to three, so we should be good for as long as the board remains relevant now.
Thanks for finding this. I am going to grab this for the release and I might re-word a commit or two. I have one ask tho, can you look at using CONFIG_BOARD_SIZE_LIMIT, perhaps in a generic way so that we catch more "oops, the board grew too big, run-time now will fail!" issues?
Yeah, I'll have a look -- I was kind of surprised that it didn't scream at me when this happened during the build, since I'd think we have all the information at our fingertips to do a build bug on or similar, and I can't be the 1st one bitten by this.
P. --
-- Tom
[Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 18:50) Paul Gortmaker wrote:
[Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 17:50) Tom Rini wrote:
On Sat, Oct 17, 2015 at 04:40:25PM -0400, Paul Gortmaker wrote:
The sbc8641d is not really a state of the art board anymore, but it does have the distinctive feature of being one of the relatively few SMP powerpc boards around. Combined with its small form factor, it remains a useful testing platform. So here we enable the generic board support so that it can remain in tree.
It turns out that in bringing the board forward, we've run into the size limit for the image, due to inevitable expansion, which led to some odd testing behaviour, depending on .config settings etc. Here we increase the image space from two 128k sectors to three, so we should be good for as long as the board remains relevant now.
Thanks for finding this. I am going to grab this for the release and I might re-word a commit or two. I have one ask tho, can you look at using CONFIG_BOARD_SIZE_LIMIT, perhaps in a generic way so that we catch more "oops, the board grew too big, run-time now will fail!" issues?
Yeah, I'll have a look -- I was kind of surprised that it didn't scream at me when this happened during the build, since I'd think we have all the information at our fingertips to do a build bug on or similar, and I can't be the 1st one bitten by this.
So, it seems we already have this in a "generic" way via BOARD_SIZE_LIMIT but hardly anyone sets that for their board.
u-boot$git grep -l CONFIG_BOARD_SIZE_LIMIT include/ include/configs/bf548-ezkit.h include/configs/bf609-ezkit.h include/configs/bfin_adi_common.h include/configs/cm-bf537e.h include/configs/cm-bf537u.h include/configs/colibri_pxa270.h include/configs/colibri_vf.h include/configs/pcm052.h include/configs/tcm-bf537.h include/configs/vf610twr.h u-boot$
Can we just assign CONFIG_SYS_MONITOR_LEN to CONFIG_BOARD_SIZE_LIMIT if the latter isn't explicitly set? Or will that not be valid in some cases?
Paul. --
P.
-- Tom
On Sat, Oct 17, 2015 at 07:11:26PM -0400, Paul Gortmaker wrote:
[Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 18:50) Paul Gortmaker wrote:
[Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 17:50) Tom Rini wrote:
On Sat, Oct 17, 2015 at 04:40:25PM -0400, Paul Gortmaker wrote:
The sbc8641d is not really a state of the art board anymore, but it does have the distinctive feature of being one of the relatively few SMP powerpc boards around. Combined with its small form factor, it remains a useful testing platform. So here we enable the generic board support so that it can remain in tree.
It turns out that in bringing the board forward, we've run into the size limit for the image, due to inevitable expansion, which led to some odd testing behaviour, depending on .config settings etc. Here we increase the image space from two 128k sectors to three, so we should be good for as long as the board remains relevant now.
Thanks for finding this. I am going to grab this for the release and I might re-word a commit or two. I have one ask tho, can you look at using CONFIG_BOARD_SIZE_LIMIT, perhaps in a generic way so that we catch more "oops, the board grew too big, run-time now will fail!" issues?
Yeah, I'll have a look -- I was kind of surprised that it didn't scream at me when this happened during the build, since I'd think we have all the information at our fingertips to do a build bug on or similar, and I can't be the 1st one bitten by this.
So, it seems we already have this in a "generic" way via BOARD_SIZE_LIMIT but hardly anyone sets that for their board.
u-boot$git grep -l CONFIG_BOARD_SIZE_LIMIT include/ include/configs/bf548-ezkit.h include/configs/bf609-ezkit.h include/configs/bfin_adi_common.h include/configs/cm-bf537e.h include/configs/cm-bf537u.h include/configs/colibri_pxa270.h include/configs/colibri_vf.h include/configs/pcm052.h include/configs/tcm-bf537.h include/configs/vf610twr.h u-boot$
Can we just assign CONFIG_SYS_MONITOR_LEN to CONFIG_BOARD_SIZE_LIMIT if the latter isn't explicitly set? Or will that not be valid in some cases?
Right, that's what I was hoping you could poke at a bit and see about, at least when CONFIG_SYS_MONITOR_LEN is set (in a post v2015.10 patch too, that is).
participants (2)
-
Paul Gortmaker -
Tom Rini