[U-Boot] [PATCH 0/5] 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.
One note worthy of mention is that the same commit that breaks[1] the sbc8548 board [commit 294b91a58171 ("Set up stdio earlier when using driver model")] also breaks this board in the identical way (hangs at "Net:" line during bootup). So the baseline for run time testing was one commit prior to that commit that introduced the regressions.
The fixes are all board specific and a branch off 294b91a58171~ will merge seamlessly to master, or they can be applied to master; whenever the regressions of 294b91a58171 are resolved then things will work again on the tip of tree.
[1] https://www.marc.info/?l=u-boot&m=142655649417364&w=3
Paul Gortmaker (5): 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
board/sbc8641d/README | 21 +++++++++++++++++++++ include/configs/sbc8641d.h | 7 +++++-- 2 files changed, 26 insertions(+), 2 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 8eb7276618b0..354b673845cf 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -495,6 +495,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 */
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 354b673845cf..77a7e5a799b8 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
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 77a7e5a799b8..20e7152b0952 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 */
...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.
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 20e7152b0952..32468453f524 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 08/24/2015 12:26 PM, Paul Gortmaker wrote:
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.
Paul,
I can't test this patch. As the commit message said, it only works on an ancient point. Even this patch is merged, you can use the top of tree anyway. Is there any effort to find out why it is broken?
York
On 2015-09-01 10:08 PM, York Sun wrote:
On 08/24/2015 12:26 PM, Paul Gortmaker wrote:
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.
Paul,
I can't test this patch. As the commit message said, it only works on an ancient point. Even this patch is merged, you can use the top of tree anyway. Is there any effort to find out why it is broken?
Well, I was hoping to get more detailed suggestions from folks here, now that we know it is not board specific and probably breaks a lot of the older freescale boards - both the sbc8548 and sbc8641d were close derivatives of their MPC8548CDS and HPCNET/8641D cousins, but just targeting a smaller form factor. I'm betting they are dead too.
Maybe now that we know that, Simon [added to CC] can offer some more detailed suggestions on what is going on, since I bisected it back to his commit relating to uart init.
http://marc.info/?l=u-boot&m=142715170512534
I can test incremental changes on top of that last working baseline easily enough, since the board has redundant flash (which let me get that far). But currently I've no clue where to start, since the uart init breaking net init, or leaving a booby-trap such that touching the net device hangs - doesn't really point to an obvious starting point to test. :(
Paul. --
York
Hi Paul,
On 2 September 2015 at 07:37, Paul Gortmaker paul.gortmaker@windriver.com wrote:
On 2015-09-01 10:08 PM, York Sun wrote:
On 08/24/2015 12:26 PM, Paul Gortmaker wrote:
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.
Paul,
I can't test this patch. As the commit message said, it only works on an ancient point. Even this patch is merged, you can use the top of tree anyway. Is there any effort to find out why it is broken?
Well, I was hoping to get more detailed suggestions from folks here, now that we know it is not board specific and probably breaks a lot of the older freescale boards - both the sbc8548 and sbc8641d were close derivatives of their MPC8548CDS and HPCNET/8641D cousins, but just targeting a smaller form factor. I'm betting they are dead too.
Maybe now that we know that, Simon [added to CC] can offer some more detailed suggestions on what is going on, since I bisected it back to his commit relating to uart init.
http://marc.info/?l=u-boot&m=142715170512534
I can test incremental changes on top of that last working baseline easily enough, since the board has redundant flash (which let me get that far). But currently I've no clue where to start, since the uart init breaking net init, or leaving a booby-trap such that touching the net device hangs - doesn't really point to an obvious starting point to test. :(
I don't have any good ideas, you could try these (with reference to my commit 294b91a5):
1. Move the initr_barrier()...initr_dm() code sequence back to its original place below initr_w83c553f(), and see if that fixes it. Then progressively move it earlier until you see a breakage.
2. Add another initr_barrier() in the original place
3. Comment out initr_dm()
Since you are presumably not using driver model for serial yet you should be able to fiddling things around quite a bit without breaking anything. Once you narrow it down a fix may be obvious, or may need a bit of thought.
Regards, Simon
Hi.
2015-09-02 23:05 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Paul,
On 2 September 2015 at 07:37, Paul Gortmaker paul.gortmaker@windriver.com wrote:
On 2015-09-01 10:08 PM, York Sun wrote:
On 08/24/2015 12:26 PM, Paul Gortmaker wrote:
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.
Paul,
I can't test this patch. As the commit message said, it only works on an ancient point. Even this patch is merged, you can use the top of tree anyway. Is there any effort to find out why it is broken?
Well, I was hoping to get more detailed suggestions from folks here, now that we know it is not board specific and probably breaks a lot of the older freescale boards - both the sbc8548 and sbc8641d were close derivatives of their MPC8548CDS and HPCNET/8641D cousins, but just targeting a smaller form factor. I'm betting they are dead too.
Maybe now that we know that, Simon [added to CC] can offer some more detailed suggestions on what is going on, since I bisected it back to his commit relating to uart init.
http://marc.info/?l=u-boot&m=142715170512534
I can test incremental changes on top of that last working baseline easily enough, since the board has redundant flash (which let me get that far). But currently I've no clue where to start, since the uart init breaking net init, or leaving a booby-trap such that touching the net device hangs - doesn't really point to an obvious starting point to test. :(
I don't have any good ideas, you could try these (with reference to my commit 294b91a5):
- Move the initr_barrier()...initr_dm() code sequence back to its
original place below initr_w83c553f(), and see if that fixes it. Then progressively move it earlier until you see a breakage.
Add another initr_barrier() in the original place
Comment out initr_dm()
Since you are presumably not using driver model for serial yet you should be able to fiddling things around quite a bit without breaking anything. Once you narrow it down a fix may be obvious, or may need a bit of thought.
Any plan about this patch?
I think this is the last non-generic board for PowerPC architecture.
This board is still keeping us from removing arch/powerpc/lib/board.c
[Re: [U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD] On 04/10/2015 (Sun 01:45) Masahiro Yamada wrote:
Hi.
2015-09-02 23:05 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Paul,
On 2 September 2015 at 07:37, Paul Gortmaker paul.gortmaker@windriver.com wrote:
On 2015-09-01 10:08 PM, York Sun wrote:
On 08/24/2015 12:26 PM, Paul Gortmaker wrote:
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.
Paul,
I can't test this patch. As the commit message said, it only works on an ancient point. Even this patch is merged, you can use the top of tree anyway. Is there any effort to find out why it is broken?
Well, I was hoping to get more detailed suggestions from folks here, now that we know it is not board specific and probably breaks a lot of the older freescale boards - both the sbc8548 and sbc8641d were close derivatives of their MPC8548CDS and HPCNET/8641D cousins, but just targeting a smaller form factor. I'm betting they are dead too.
Maybe now that we know that, Simon [added to CC] can offer some more detailed suggestions on what is going on, since I bisected it back to his commit relating to uart init.
http://marc.info/?l=u-boot&m=142715170512534
I can test incremental changes on top of that last working baseline easily enough, since the board has redundant flash (which let me get that far). But currently I've no clue where to start, since the uart init breaking net init, or leaving a booby-trap such that touching the net device hangs - doesn't really point to an obvious starting point to test. :(
I don't have any good ideas, you could try these (with reference to my commit 294b91a5):
- Move the initr_barrier()...initr_dm() code sequence back to its
original place below initr_w83c553f(), and see if that fixes it. Then progressively move it earlier until you see a breakage.
Add another initr_barrier() in the original place
Comment out initr_dm()
Since you are presumably not using driver model for serial yet you should be able to fiddling things around quite a bit without breaking anything. Once you narrow it down a fix may be obvious, or may need a bit of thought.
Any plan about this patch?
I think this is the last non-generic board for PowerPC architecture.
This board is still keeping us from removing arch/powerpc/lib/board.c
Let me see if I can identify the exact line of change that breaks booting tomorrow, and maybe then Simon or someone can suggest next steps from there.
P. --
-- Best Regards Masahiro Yamada
On 2015-10-05 08:53 PM, Paul Gortmaker wrote:
[Re: [U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD] On 04/10/2015 (Sun 01:45) Masahiro Yamada wrote:
[...]
Any plan about this patch?
I think this is the last non-generic board for PowerPC architecture.
This board is still keeping us from removing arch/powerpc/lib/board.c
Let me see if I can identify the exact line of change that breaks booting tomorrow, and maybe then Simon or someone can suggest next steps from there.
So I broke down the suspect patch into three chunks, testing each chunk as I went and it booted each time. A git diff of my split by 3 vs a cherry pick of what I thought was the offending commit shows nothing.
So at this point, it seems the bisect returned the wrong result, which is odd, since it seemed the same for sbc8548 and sbc8641. Maybe a makefile bug let an object file get re-used that should not have been? I'll do distclean in each bisect step in the future.
I'll have another chance to work on this Thurs AM, and I'm curious to get to the bottom of this, so I'll follow up then with what I find out.
Paul. --
P.
-- Best Regards Masahiro Yamada
On 2015-10-06 11:27 AM, Paul Gortmaker wrote:
On 2015-10-05 08:53 PM, Paul Gortmaker wrote:
[Re: [U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD] On 04/10/2015 (Sun 01:45) Masahiro Yamada wrote:
[...]
Any plan about this patch?
I think this is the last non-generic board for PowerPC architecture.
This board is still keeping us from removing arch/powerpc/lib/board.c
Let me see if I can identify the exact line of change that breaks booting tomorrow, and maybe then Simon or someone can suggest next steps from there.
So I broke down the suspect patch into three chunks, testing each chunk as I went and it booted each time. A git diff of my split by 3 vs a cherry pick of what I thought was the offending commit shows nothing.
So at this point, it seems the bisect returned the wrong result, which is odd, since it seemed the same for sbc8548 and sbc8641. Maybe a makefile bug let an object file get re-used that should not have been? I'll do distclean in each bisect step in the future.
I'll have another chance to work on this Thurs AM, and I'm curious to get to the bottom of this, so I'll follow up then with what I find out.
OK. So I finally got to the bottom of this and now it makes more sense. The monitor len was set to 256k and we were flirting with breaking that threshold based on .config settings and where we were in the tree ; my 2nd bisect led me to 2015.07-ish stuff and there I saw this when comparing the passing build with the fail:
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
The 412 commit added CONFIG_NET to the board and added 5k to the image which broke the 256k limit. Not sure why the earlier bisect that led to Simon's commit was breaking initially, but then not reproducible; I'm guessing that I wasn't re-running the defconfig step for each bisect step perhaps?
I'll send a v2 of the series with 384k mon len shortly ; I have it booting on today's master commit now.
Paul. --
U-Boot 2015.10-rc5-00024-gefbcba5eb4a0 (Oct 16 2015 - 17:34:32 -0400)
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 *** Warning - bad CRC, using default environment
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 [PRIME] Error: eTSEC1 address not set. , eTSEC2 Error: eTSEC2 address not set. , eTSEC3 Error: eTSEC3 address not set. , eTSEC4 Error: eTSEC4 address not set.
Hit any key to stop autoboot: 0 =>
Hi Paul,
On 16 October 2015 at 15:51, Paul Gortmaker paul.gortmaker@windriver.com wrote:
On 2015-10-06 11:27 AM, Paul Gortmaker wrote:
On 2015-10-05 08:53 PM, Paul Gortmaker wrote:
[Re: [U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD] On 04/10/2015 (Sun 01:45) Masahiro Yamada wrote:
[...]
Any plan about this patch?
I think this is the last non-generic board for PowerPC architecture.
This board is still keeping us from removing arch/powerpc/lib/board.c
Let me see if I can identify the exact line of change that breaks booting tomorrow, and maybe then Simon or someone can suggest next steps from there.
So I broke down the suspect patch into three chunks, testing each chunk as I went and it booted each time. A git diff of my split by 3 vs a cherry pick of what I thought was the offending commit shows nothing.
So at this point, it seems the bisect returned the wrong result, which is odd, since it seemed the same for sbc8548 and sbc8641. Maybe a makefile bug let an object file get re-used that should not have been? I'll do distclean in each bisect step in the future.
I'll have another chance to work on this Thurs AM, and I'm curious to get to the bottom of this, so I'll follow up then with what I find out.
OK. So I finally got to the bottom of this and now it makes more sense. The monitor len was set to 256k and we were flirting with breaking that threshold based on .config settings and where we were in the tree ; my 2nd bisect led me to 2015.07-ish stuff and there I saw this when comparing the passing build with the fail:
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 262144The 412 commit added CONFIG_NET to the board and added 5k to the image which broke the 256k limit. Not sure why the earlier bisect that led to Simon's commit was breaking initially, but then not reproducible; I'm guessing that I wasn't re-running the defconfig step for each bisect step perhaps?
I'll send a v2 of the series with 384k mon len shortly ; I have it booting on today's master commit now.
Great that you got to the bottom of this! I wonder if we could add a check for CONFIG_SYS_MONITOR_LEN being too msmall?
Regards, Simon
participants (4)
-
Masahiro Yamada -
Paul Gortmaker -
Simon Glass -
York Sun