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

[Simon Glass]

Hi Paul,

On 24 March 2015 at 07:33, Paul Gortmaker <paul.gortmaker at windriver.com> wrote:
> [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 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.
>
> So there is no board wide conversion to some new API needed from this
> change, i.e. things should have stayed working as is?

Right.

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

The author does not know and has racked his brains trying to imagine
what the problem might be. But since it happens after the console is
running, he is at a loss. Once you find the problem the author will
likely experience a revelatory moment.

Break out the ICE :-)

Regards,
Simon