Hi Paul, On 24 March 2015 at 07:33, Paul Gortmaker <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > AuthorDate: Thu Aug 14 10:42:52 2014 -0400 >> > Commit: York Sun <[email protected]> >> > 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 <[email protected]> >> > 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
