| Message ID | 1440437213-49224-6-git-send-email-paul.gortmaker@windriver.com |
|---|---|
| State | Superseded |
| Delegated to: | York Sun |
| Headers | show |
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): > > 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
[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
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 > 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
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 */
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(+)