[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 at chromium.org>:
> > Hi Paul,
> >
> > On 2 September 2015 at 07:37, Paul Gortmaker
> > <paul.gortmaker at 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