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

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

[Paul Gortmaker]

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.

Thanks,
Paul.

[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@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.

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

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

[Paul Gortmaker]

[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

[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@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@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?

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