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

[Simon Glass]

Hi Paul,

On 16 March 2015 at 19:41, Paul Gortmaker <paul.gortmaker at 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 at windriver.com>
> AuthorDate: Thu Aug 14 10:42:52 2014 -0400
> Commit:     York Sun <yorksun at 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 at 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.

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

Regards,
Simon