[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.gortma...@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.gortma...@windriver.com> > > AuthorDate: Thu Aug 14 10:42:52 2014 -0400 > > Commit: York Sun <york...@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 <s...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot