[U-Boot] Set up stdio earlier when using driver model <--- breaks sbc8548 booting.
Paul Gortmaker
paul.gortmaker at windriver.com
Tue Mar 24 14:33:43 CET 2015
[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?
>
> 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
More information about the U-Boot
mailing list