[U-Boot] [PATCH 0/5] sbc8641d: misc fixes and generic board enablement

[U-Boot] [PATCH 0/5] sbc8641d: misc fixes and generic board enablement

[Paul Gortmaker]

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(-)

-- 
2.1.0

[U-Boot] [PATCH 1/5] sbc8641d: enable command line editing

[Paul Gortmaker]

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 */
-- 
2.1.0

[U-Boot] [PATCH 2/5] sbc8641d: increase malloc pool size to a sane default

[Paul Gortmaker]

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
-- 
2.1.0

[U-Boot] [PATCH 3/5] sbc8641d: set proper environment sector size.

[Paul Gortmaker]

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 */
-- 
2.1.0

[U-Boot] [PATCH 4/5] sbc8641d: add basic flash setup instructions to README file

[Paul Gortmaker]

...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.
-- 
2.1.0

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

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 */
-- 
2.1.0

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[York Sun]

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

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

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
> 

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Simon Glass]

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

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Masahiro Yamada]

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):
>
> 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.
>


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



-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

[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):
> >
> > 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.
> >
> 
> 
> 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

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

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

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Paul Gortmaker]

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
=>

[U-Boot] [PATCH 5/5] sbc8641d: enable and test CONFIG_SYS_GENERIC_BOARD

[Simon Glass]

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
>      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.

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