[U-Boot] Set up stdio earlier when using driver model <--- breaks sbc8548 booting.

[Paul Gortmaker <paul.gortmaker@windriver.com>]

[Re: Set up stdio earlier when using driver model <--- breaks sbc8548 booting.] On 23/03/2015 (Mon 17:01) Simon Glass wrote:

> Hi Paul,
> 
> On 16 March 2015 at 19:41, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> > Testing latest master on sbc8548 (ppc e500v2 single core) and it hangs
> > at the "Net: " line; a working boot shows the full "Net: " line as:
> >
> >  -------------
> > PCI: Host, 64 bit, 66 MHz, sync, arbiter
> >   00:01.0     - 8086:1026 - Network controller
> > PCI1: Bus 00 - 00
> >
> > PCIe1: disabled
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   eTSEC0 [PRIME], eTSEC1
> > Hit any key to stop autoboot:  0
> >  -------------
> >
> > So we never see the eTSEC0 or any other output after "Net: ".
> >
> > My 1st bisect led to my own commit:
> >
> >  -------------
> > commit 2bf4207b8a452476a591d733c6b8f09b337acc08
> > Author:     Paul Gortmaker <paul.gortmaker@windriver.com>
> > AuthorDate: Thu Aug 14 10:42:52 2014 -0400
> > Commit:     York Sun <yorksun@freescale.com>
> > CommitDate: Fri Nov 14 11:12:13 2014 -0800
> >
> >     sbc8548: enable and test CONFIG_SYS_GENERIC_BOARD
> >  -------------
> >
> > ...but that is a red herring, since I'd tested it on master at Aug14,
> > but it wasn't committed to master until three months later.  So the
> > breakage is in that 3 month window.
> >
> > Since I recorded the original baseline I'd tested on, I restarted the
> > bisect with that baseline as good and the above 2bf42 as bad, and just
> > added the oneline change for CONFIG_SYS_GENERIC_BOARD manually at each
> > bisect point.  Doing that led me unequivocally to:
> >
> >  -------------
> >   commit 294b91a5817147d4b7f47be2ac69bac2a1f26491
> >   Author: Simon Glass <sjg@chromium.org>
> >   Date:   Wed Sep 3 17:37:00 2014 -0600
> >
> >     Set up stdio earlier when using driver model
> >  -------------
> >
> > Based on a part of that commit log, it says "Should there be any
> > problems with this approach they can be dealt with as boards are
> > converted over to use driver model for serial."  So maybe the sbc8548 is
> > just missing some additional conversion?  Oddly it seems it is dying at
> > network device probing and not in/out/err that use serial as stdio.
> >
> > Any hints on what to look at next to solve this would be appreciated. I
> > had a look at this link:
> >
> > http://www.denx.de/wiki/U-Boot/DriverModel
> >
> > ..but wasn't sure where to go from there, since I'm still unsure what
> > the real root of the breakage is.
> 
> Yes it is certainly odd. The driver init for serial is over by then,
> so I don't see why it would hang. Also the code has changed further
> since that commit.

So there is no board wide conversion to some new API needed from this
change, i.e. things should have stayed working as is?

> 
> My suggestion would be to dig into the network init and see if you
> figure out where it hangs. Do you have an ICE?

Ugh.  I could probably find an ICE and the associated software, but I've
never really liked using the things, which is why I bisected my way here
to identify the commit that caused the regression, hoping that once it
was identified, that the author of the changeset would know what
happened...   :-(

P.
--

> 
> Regards,
> Simon