[U-Boot] Set up stdio earlier when using driver model <--- breaks sbc8548 booting.
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.
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
[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
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
participants (2)
-
Paul Gortmaker -
Simon Glass