* Re: espressobin device tree with kernel 5.1 RC
[not found] <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAABB6J1kxOR7T73eMrM92Eq+AQAAAAA=@stahurabrenner.com>
@ 2019-04-29 7:57 ` Miquel Raynal
2019-04-29 15:03 ` Timothy Krantz
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
0 siblings, 2 replies; 18+ messages in thread
From: Miquel Raynal @ 2019-04-29 7:57 UTC (permalink / raw)
To: Timothy Krantz, linux-arm-kernel
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 22 Apr 2019
15:07:12 -0400:
> Hi,
> Please excuse my emailing you directly. I do not know the proper channels
> to report my problem.
>
For this kind of question I think adding the Linux ARM Kernel Mailing
List (LAKML) is the right thing to do.
> I build my own kernels for my 3 espressobins. Up through kernel 5.0 things
> work fine.
>
> In the 5.1 RC kernels I have been unable to boot using the 5.1 RC device
> tree. I get :
>
> ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
>
> then the boot fails waiting for the rootfs on my sata device.
>
> If I use a kernel 5.0 device tree with a 5.1 RC kernel it boots fine.
>
> I am glad to test anything if that would help.
Do you have PHY_MVEBU_A3700_COMPHY enabled?
>
> Tim Krantz
>
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-04-29 7:57 ` espressobin device tree with kernel 5.1 RC Miquel Raynal
@ 2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
` (2 more replies)
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
1 sibling, 3 replies; 18+ messages in thread
From: Timothy Krantz @ 2019-04-29 15:03 UTC (permalink / raw)
To: 'Miquel Raynal', linux-arm-kernel
Hi Miquel thanks for the response.
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Monday, April 29, 2019 3:57 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 22 Apr
> 2019
> 15:07:12 -0400:
>
> > Hi,
> > Please excuse my emailing you directly. I do not know the proper
> > channels to report my problem.
> >
>
> For this kind of question I think adding the Linux ARM Kernel Mailing List
> (LAKML) is the right thing to do.
Got it, thanks for the information.
>
> > I build my own kernels for my 3 espressobins. Up through kernel 5.0
> > things work fine.
> >
> > In the 5.1 RC kernels I have been unable to boot using the 5.1 RC
> > device tree. I get :
> >
> > ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
> >
> > then the boot fails waiting for the rootfs on my sata device.
> >
> > If I use a kernel 5.0 device tree with a 5.1 RC kernel it boots fine.
> >
> > I am glad to test anything if that would help.
>
> Do you have PHY_MVEBU_A3700_COMPHY enabled?
I had it compiled as a modules but am not using an initrd, so I compiled it into the kernel itself (i.e. not as a modules)
But I still fail to boot. I do not get the trace above but I just hang at "Waiting for root device /dev/sda2...".
Replacing the 5.1-rc7 device tree with a 5.0 device tree boots fine.
Thanks,
Tim Krantz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-04-29 15:03 ` Timothy Krantz
@ 2019-04-29 15:25 ` Uwe Kleine-König
2019-04-29 16:07 ` Marc Gonzalez
2019-04-29 18:10 ` Miquel Raynal
2 siblings, 0 replies; 18+ messages in thread
From: Uwe Kleine-König @ 2019-04-29 15:25 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel, 'Miquel Raynal'
On Mon, Apr 29, 2019 at 11:03:33AM -0400, Timothy Krantz wrote:
> Hi Miquel thanks for the response.
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Monday, April 29, 2019 3:57 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 22 Apr
> > 2019
> > 15:07:12 -0400:
> >
> > > Hi,
> > > Please excuse my emailing you directly. I do not know the proper
> > > channels to report my problem.
> > >
> >
> > For this kind of question I think adding the Linux ARM Kernel Mailing List
> > (LAKML) is the right thing to do.
>
> Got it, thanks for the information.
>
> >
> > > I build my own kernels for my 3 espressobins. Up through kernel 5.0
> > > things work fine.
> > >
> > > In the 5.1 RC kernels I have been unable to boot using the 5.1 RC
> > > device tree. I get :
> > >
> > > ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
> > >
> > > then the boot fails waiting for the rootfs on my sata device.
> > >
> > > If I use a kernel 5.0 device tree with a 5.1 RC kernel it boots fine.
> > >
> > > I am glad to test anything if that would help.
> >
> > Do you have PHY_MVEBU_A3700_COMPHY enabled?
>
> I had it compiled as a modules but am not using an initrd, so I compiled it into the kernel itself (i.e. not as a modules)
> But I still fail to boot. I do not get the trace above but I just hang at "Waiting for root device /dev/sda2...".
> Replacing the 5.1-rc7 device tree with a 5.0 device tree boots fine.
Can you bisect the problem? I'd start testing
1c2950563a260ecdb87ec9645b50b5a6f227568c and
31af04cd60d3162a58213363fd740a2b0cf0a08e.
If you don't understand that, don't hesitate to ask. Maybe come into the
#armlinux or #mvlinux irc channel on freenode.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
@ 2019-04-29 16:07 ` Marc Gonzalez
2019-04-29 18:10 ` Miquel Raynal
2 siblings, 0 replies; 18+ messages in thread
From: Marc Gonzalez @ 2019-04-29 16:07 UTC (permalink / raw)
To: Timothy Krantz, Miquel Raynal; +Cc: Grzegorz Jaszczyk, Linux ARM
On 29/04/2019 17:03, Timothy Krantz wrote:
> I build my own kernels for my 3 espressobins. Up through kernel 5.0 things work fine.
>
> In the 5.1 RC kernels I have been unable to boot using the 5.1 RC device tree.
>
> ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
>
> then the boot fails waiting for the rootfs on my sata device.
>
> If I use a kernel 5.0 device tree with a 5.1 RC kernel it boots fine.
$ git diff --stat=99 v5.0 v5.1-rc7 arch/arm64/boot/dts/marvell
arch/arm64/boot/dts/marvell/Makefile | 1 +
arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 12 +++
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts | 162 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 82 +++++++++++++++-
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 4 -
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 4 -
arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi | 4 +-
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 8 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 18 +++-
arch/arm64/boot/dts/marvell/armada-ap810-ap0-octa-core.dtsi | 16 +--
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 15 ++-
12 files changed, 296 insertions(+), 32 deletions(-)
https://lore.kernel.org/patchwork/project/lkml/list/?series=378682
d68def52498eb arm64: dts: marvell: armada-37xx: fix SATA node scope
2ef303f0fe44f arm64: dts: marvell: armada-37xx: declare the COMPHY node
8e18c8e58da64 arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 846003bb480c..6be019e1888e 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -46,11 +46,16 @@
/* J9 */
&pcie0 {
status = "okay";
+ phys = <&comphy1 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_reset_pins &pcie_clkreq_pins>;
};
/* J6 */
&sata {
status = "okay";
+ phys = <&comphy2 0>;
+ phy-names = "sata-phy";
};
/* J1 */
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e05594ea15fb..f43c43168b00 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -247,6 +247,35 @@
reg = <0x14000 0x60>;
};
+ comphy: phy@18300 {
+ compatible = "marvell,comphy-a3700";
+ reg = <0x18300 0x300>,
+ <0x1F000 0x400>,
+ <0x5C000 0x400>,
+ <0xe0178 0x8>;
+ reg-names = "comphy",
+ "lane1_pcie_gbe",
+ "lane0_usb3_gbe",
+ "lane2_sata_usb3";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+
+ comphy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
pinctrl_sb: pinctrl@18800 {
compatible = "marvell,armada3710-sb-pinctrl",
"syscon", "simple-mfd";
@@ -368,8 +443,9 @@
sata: sata@e0000 {
compatible = "marvell,armada-3700-ahci";
- reg = <0xe0000 0x2000>;
+ reg = <0xe0000 0x178>;
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&nb_periph_clk 1>;
status = "disabled";
};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
2019-04-29 16:07 ` Marc Gonzalez
@ 2019-04-29 18:10 ` Miquel Raynal
2 siblings, 0 replies; 18+ messages in thread
From: Miquel Raynal @ 2019-04-29 18:10 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 29 Apr 2019
11:03:33 -0400:
> Hi Miquel thanks for the response.
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Monday, April 29, 2019 3:57 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 22 Apr
> > 2019
> > 15:07:12 -0400:
> >
> > > Hi,
> > > Please excuse my emailing you directly. I do not know the proper
> > > channels to report my problem.
> > >
> >
> > For this kind of question I think adding the Linux ARM Kernel Mailing List
> > (LAKML) is the right thing to do.
>
> Got it, thanks for the information.
>
> >
> > > I build my own kernels for my 3 espressobins. Up through kernel 5.0
> > > things work fine.
> > >
> > > In the 5.1 RC kernels I have been unable to boot using the 5.1 RC
> > > device tree. I get :
> > >
> > > ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
-517 is -EPROBE_DEFFER. While a new case in the switch located in
ahci_platform_get_phy() should probably handle this case silently, it
does not explain why it hangs.
Could you add traces in ahci_mvebu.c to check where it hangs?
As Uwe told you, #armlinux or #mvlinux might be good places to discuss
this topic.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
@ 2019-06-17 9:38 ` Miquel Raynal
2019-06-17 9:40 ` Miquel Raynal
0 siblings, 1 reply; 18+ messages in thread
From: Miquel Raynal @ 2019-06-17 9:38 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
Please keep the Linux ARM kernel ML in copy.
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Sat, 15 Jun 2019
18:56:00 -0400:
> Hello,
> I am still unable to get 5.1 or 5.2rc kernels to boot with the associated dtb. They all seem to work fine with the older dtb.
>
> I am certain that it is something in my .config that is not properly set.
>
> I don't suppose you can send me a copy of your .config that works so that I can try with that?
MyHere is my configuration for a 5.2-rc1 kernel.
>
> Thanks for your consideration.
>
> Tim Krantz
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Monday, April 29, 2019 3:57 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 22 Apr
> > 2019
> > 15:07:12 -0400:
> >
> > > Hi,
> > > Please excuse my emailing you directly. I do not know the proper
> > > channels to report my problem.
> > >
> >
> > For this kind of question I think adding the Linux ARM Kernel Mailing List
> > (LAKML) is the right thing to do.
> >
> > > I build my own kernels for my 3 espressobins. Up through kernel 5.0
> > > things work fine.
> > >
> > > In the 5.1 RC kernels I have been unable to boot using the 5.1 RC
> > > device tree. I get :
> > >
> > > ahci-mvebu d00e0000.sata: couldn't get PHY in node sata: -517
> > >
> > > then the boot fails waiting for the rootfs on my sata device.
> > >
> > > If I use a kernel 5.0 device tree with a 5.1 RC kernel it boots fine.
> > >
> > > I am glad to test anything if that would help.
> >
> > Do you have PHY_MVEBU_A3700_COMPHY enabled?
> >
> > >
> > > Tim Krantz
> > >
> >
> >
> > Thanks,
> > Miquèl
>
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-17 9:38 ` Miquel Raynal
@ 2019-06-17 9:40 ` Miquel Raynal
2019-06-17 17:19 ` Timothy Krantz
0 siblings, 1 reply; 18+ messages in thread
From: Miquel Raynal @ 2019-06-17 9:40 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 17 Jun 2019
11:38:41 +0200:
> Hi Timothy,
>
> Please keep the Linux ARM kernel ML in copy.
>
> "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Sat, 15 Jun 2019
> 18:56:00 -0400:
>
> > Hello,
> > I am still unable to get 5.1 or 5.2rc kernels to boot with the associated dtb. They all seem to work fine with the older dtb.
> >
> > I am certain that it is something in my .config that is not properly set.
> >
> > I don't suppose you can send me a copy of your .config that works so that I can try with that?
>
> MyHere is my configuration for a 5.2-rc1 kernel.
Here it is -> http://code.bulix.org/ngdr8z-774071
SATA port is working with this setup.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-17 9:40 ` Miquel Raynal
@ 2019-06-17 17:19 ` Timothy Krantz
2019-06-18 7:58 ` Miquel Raynal
0 siblings, 1 reply; 18+ messages in thread
From: Timothy Krantz @ 2019-06-17 17:19 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Thanks Miquel,
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Monday, June 17, 2019 5:40 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 17 Jun 2019
> 11:38:41 +0200:
>
> > Hi Timothy,
> >
> > Please keep the Linux ARM kernel ML in copy.
> >
> > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Sat, 15 Jun
> 2019
> > 18:56:00 -0400:
> >
> > > Hello,
> > > I am still unable to get 5.1 or 5.2rc kernels to boot with the associated dtb.
> They all seem to work fine with the older dtb.
> > >
> > > I am certain that it is something in my .config that is not properly set.
> > >
> > > I don't suppose you can send me a copy of your .config that works so that
> I can try with that?
> >
> > MyHere is my configuration for a 5.2-rc1 kernel.
>
> Here it is -> http://code.bulix.org/ngdr8z-774071
>
> SATA port is working with this setup.
>
> Thanks,
> Miquèl
This https://pastebin.com/xPTMdbbx
Is what I get with a kernel configured with your .config.
I suspect there is some magic in
CONFIG_INITRAMFS_SOURCE="/home/mraynal/buildroot/output-arm/images/rootfs.cpio"
Which I do not have that may be making a difference? (that is the only difference in what I compiled and you sent to me).
Thanks for any input you might have.
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-17 17:19 ` Timothy Krantz
@ 2019-06-18 7:58 ` Miquel Raynal
2019-06-18 14:15 ` Timothy Krantz
0 siblings, 1 reply; 18+ messages in thread
From: Miquel Raynal @ 2019-06-18 7:58 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 17 Jun 2019
13:19:46 -0400:
> Thanks Miquel,
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Monday, June 17, 2019 5:40 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 17 Jun 2019
> > 11:38:41 +0200:
> >
> > > Hi Timothy,
> > >
> > > Please keep the Linux ARM kernel ML in copy.
> > >
> > > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Sat, 15 Jun
> > 2019
> > > 18:56:00 -0400:
> > >
> > > > Hello,
> > > > I am still unable to get 5.1 or 5.2rc kernels to boot with the associated dtb.
> > They all seem to work fine with the older dtb.
> > > >
> > > > I am certain that it is something in my .config that is not properly set.
> > > >
> > > > I don't suppose you can send me a copy of your .config that works so that
> > I can try with that?
> > >
> > > MyHere is my configuration for a 5.2-rc1 kernel.
> >
> > Here it is -> http://code.bulix.org/ngdr8z-774071
> >
> > SATA port is working with this setup.
> >
> > Thanks,
> > Miquèl
>
> This https://pastebin.com/xPTMdbbx
>
You should add traces where theses prints come from and find what is
missing.
> Is what I get with a kernel configured with your .config.
>
> I suspect there is some magic in
>
> CONFIG_INITRAMFS_SOURCE="/home/mraynal/buildroot/output-arm/images/rootfs.cpio"
>
> Which I do not have that may be making a difference? (that is the only difference in what I compiled and you sent to me).
Not at all, this is just my rootfs as an initramfs, not related to the
content of the kernel at all.
Good luck!
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-18 7:58 ` Miquel Raynal
@ 2019-06-18 14:15 ` Timothy Krantz
2019-06-18 14:24 ` Miquel Raynal
0 siblings, 1 reply; 18+ messages in thread
From: Timothy Krantz @ 2019-06-18 14:15 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Hi Miquel,
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Tuesday, June 18, 2019 3:58 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Mon, 17 Jun
> 2019
> 13:19:46 -0400:
>
> > Thanks Miquel,
> >
> > > -----Original Message-----
> > > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > > Sent: Monday, June 17, 2019 5:40 AM
> > > To: Timothy Krantz <tkrantz@stahurabrenner.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Subject: Re: espressobin device tree with kernel 5.1 RC
> > >
> > > Hi Timothy,
> > >
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 17 Jun 2019
> > > 11:38:41 +0200:
> > >
> > > > Hi Timothy,
> > > >
> > > > Please keep the Linux ARM kernel ML in copy.
> > > >
> > > > "Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Sat, 15 Jun
> > > 2019
> > > > 18:56:00 -0400:
> > > >
> > > > > Hello,
> > > > > I am still unable to get 5.1 or 5.2rc kernels to boot with the associated
> dtb.
> > > They all seem to work fine with the older dtb.
> > > > >
> > > > > I am certain that it is something in my .config that is not properly set.
> > > > >
> > > > > I don't suppose you can send me a copy of your .config that
> > > > > works so that
> > > I can try with that?
> > > >
> > > > MyHere is my configuration for a 5.2-rc1 kernel.
> > >
> > > Here it is -> http://code.bulix.org/ngdr8z-774071
> > >
> > > SATA port is working with this setup.
> > >
> > > Thanks,
> > > Miquèl
> >
> > This https://pastebin.com/xPTMdbbx
> >
>
> You should add traces where theses prints come from and find what is
> missing.
>
> > Is what I get with a kernel configured with your .config.
> >
> > I suspect there is some magic in
> >
> > CONFIG_INITRAMFS_SOURCE="/home/mraynal/buildroot/output-
> arm/images/rootfs.cpio"
> >
> > Which I do not have that may be making a difference? (that is the only
> difference in what I compiled and you sent to me).
>
> Not at all, this is just my rootfs as an initramfs, not related to the content of
> the kernel at all.
>
>
> Good luck!
> Miquèl
I put in this (simplistic and ugly) tracing:
static int ahci_mvebu_probe(struct platform_device *pdev)
{
const struct ahci_mvebu_plat_data *pdata;
struct ahci_host_priv *hpriv;
int rc;
printk(KERN_INFO "in mvebu probe\n");
pdata = of_device_get_match_data(&pdev->dev);
printk(KERN_INFO "check device match\n");
if (!pdata)
return -EINVAL;
printk(KERN_INFO "device did match\n");
hpriv = ahci_platform_get_resources(pdev, 0);
printk(KERN_INFO "check resources\n");
if (IS_ERR(hpriv))
return PTR_ERR(hpriv);
printk(KERN_INFO "resources ok\n");
hpriv->flags |= pdata->flags;
hpriv->plat_data = (void *)pdata;
rc = ahci_platform_enable_resources(hpriv);
printk(KERN_INFO "enable resources\n");
if (rc)
return rc;
printk(KERN_INFO "past enable resources\n");
hpriv->stop_engine = ahci_mvebu_stop_engine;
rc = pdata->plat_config(hpriv);
printk(KERN_INFO "disenable resources\n");
if (rc)
goto disable_resources;
printk(KERN_INFO "past disable resources\n");
printk(KERN_INFO "init host\n");
rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
&ahci_platform_sht);
printk(KERN_INFO "past init host\n");
if (rc)
goto disable_resources;
printk(KERN_INFO "past rc check\n");
return 0;
disable_resources:
printk(KERN_INFO "in disable resources\n");
ahci_platform_disable_resources(hpriv);
return rc;
}
With the 5.2-rc5 device tree I get :
[snip]
[ 4.204366] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 4.210876] in mvebu probe
[ 4.213608] check device match
[ 4.216710] device did match
[ 4.219762] check resources
[ 4.222555] resources ok
[ 4.225174] phy phy-d0018300.phy.2: phy poweron failed --> -1
[ 4.231069] enable resources
[ 4.234054] ahci-mvebu: probe of d00e0000.sata failed with error -1
[ 4.240800] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 4.248736] MACsec IEEE 802.1AE
[ 4.252344] libphy: Fixed MDIO Bus: probed
[snip]
With exactly the same kernel but the 5.0 device tree I get :
[snip]
[ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 4.210192] in mvebu probe
[ 4.212924] check device match
[ 4.216026] device did match
[ 4.219058] check resources
[ 4.221858] resources ok
[ 4.224458] enable resources
[ 4.227405] past enable resources
[ 4.230817] disenable resources
[ 4.234042] past disable resources
[ 4.237536] init host
[ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl platform mode
[ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs pio slum part sxs
[ 4.258647] scsi host0: ahci-mvebu
[ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-0xd00e1fff] port 0x100 irq 21
[ 4.270609] past init host
[ 4.273353] past rc check
[ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 4.284408] MACsec IEEE 802.1AE
[ 4.287965] libphy: Fixed MDIO Bus: probed
[snip]
Unfortunately that does not tell me much. Does it say anything to you?
I mean I guess rc = ahci_platform_enable_resources(hpriv); Is failing, should I put some traces in that?
Thanks again,
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-18 14:15 ` Timothy Krantz
@ 2019-06-18 14:24 ` Miquel Raynal
2019-06-18 15:28 ` Timothy Krantz
0 siblings, 1 reply; 18+ messages in thread
From: Miquel Raynal @ 2019-06-18 14:24 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
> > You should add traces where theses prints come from and find what is
> > missing.
> >
> > > Is what I get with a kernel configured with your .config.
> > >
> > > I suspect there is some magic in
> > >
> > > CONFIG_INITRAMFS_SOURCE="/home/mraynal/buildroot/output-
> > arm/images/rootfs.cpio"
> > >
> > > Which I do not have that may be making a difference? (that is the only
> > difference in what I compiled and you sent to me).
> >
> > Not at all, this is just my rootfs as an initramfs, not related to the content of
> > the kernel at all.
> >
> >
> > Good luck!
> > Miquèl
>
> I put in this (simplistic and ugly) tracing:
> static int ahci_mvebu_probe(struct platform_device *pdev)
> {
> const struct ahci_mvebu_plat_data *pdata;
> struct ahci_host_priv *hpriv;
> int rc;
>
> printk(KERN_INFO "in mvebu probe\n");
> pdata = of_device_get_match_data(&pdev->dev);
> printk(KERN_INFO "check device match\n");
> if (!pdata)
> return -EINVAL;
> printk(KERN_INFO "device did match\n");
>
> hpriv = ahci_platform_get_resources(pdev, 0);
> printk(KERN_INFO "check resources\n");
> if (IS_ERR(hpriv))
> return PTR_ERR(hpriv);
>
> printk(KERN_INFO "resources ok\n");
> hpriv->flags |= pdata->flags;
> hpriv->plat_data = (void *)pdata;
>
> rc = ahci_platform_enable_resources(hpriv);
> printk(KERN_INFO "enable resources\n");
> if (rc)
> return rc;
>
> printk(KERN_INFO "past enable resources\n");
> hpriv->stop_engine = ahci_mvebu_stop_engine;
>
> rc = pdata->plat_config(hpriv);
> printk(KERN_INFO "disenable resources\n");
> if (rc)
> goto disable_resources;
> printk(KERN_INFO "past disable resources\n");
>
> printk(KERN_INFO "init host\n");
> rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
> &ahci_platform_sht);
> printk(KERN_INFO "past init host\n");
> if (rc)
> goto disable_resources;
> printk(KERN_INFO "past rc check\n");
>
> return 0;
>
> disable_resources:
> printk(KERN_INFO "in disable resources\n");
> ahci_platform_disable_resources(hpriv);
> return rc;
> }
>
>
> With the 5.2-rc5 device tree I get :
>
> [snip]
> [ 4.204366] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 4.210876] in mvebu probe
> [ 4.213608] check device match
> [ 4.216710] device did match
> [ 4.219762] check resources
> [ 4.222555] resources ok
> [ 4.225174] phy phy-d0018300.phy.2: phy poweron failed --> -1
> [ 4.231069] enable resources
> [ 4.234054] ahci-mvebu: probe of d00e0000.sata failed with error -1
> [ 4.240800] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> [ 4.248736] MACsec IEEE 802.1AE
> [ 4.252344] libphy: Fixed MDIO Bus: probed
> [snip]
>
> With exactly the same kernel but the 5.0 device tree I get :
>
> [snip]
> [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 4.210192] in mvebu probe
> [ 4.212924] check device match
> [ 4.216026] device did match
> [ 4.219058] check resources
> [ 4.221858] resources ok
> [ 4.224458] enable resources
> [ 4.227405] past enable resources
> [ 4.230817] disenable resources
> [ 4.234042] past disable resources
> [ 4.237536] init host
> [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl platform mode
> [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs pio slum part sxs
> [ 4.258647] scsi host0: ahci-mvebu
> [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-0xd00e1fff] port 0x100 irq 21
> [ 4.270609] past init host
> [ 4.273353] past rc check
> [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> [ 4.284408] MACsec IEEE 802.1AE
> [ 4.287965] libphy: Fixed MDIO Bus: probed
> [snip]
>
> Unfortunately that does not tell me much. Does it say anything to you?
> I mean I guess rc = ahci_platform_enable_resources(hpriv); Is failing, should I put some traces in that?
Yes, in particular around the PHY initialization, until you found where
it fails exactly.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-18 14:24 ` Miquel Raynal
@ 2019-06-18 15:28 ` Timothy Krantz
2019-06-18 15:36 ` Miquel Raynal
0 siblings, 1 reply; 18+ messages in thread
From: Timothy Krantz @ 2019-06-18 15:28 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Hi Miquel,
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Tuesday, June 18, 2019 10:24 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> > > You should add traces where theses prints come from and find what is
> > > missing.
> > >
> > > > Is what I get with a kernel configured with your .config.
> > > >
> > > > I suspect there is some magic in
> > > >
> > > > CONFIG_INITRAMFS_SOURCE="/home/mraynal/buildroot/output-
> > > arm/images/rootfs.cpio"
> > > >
> > > > Which I do not have that may be making a difference? (that is the
> > > > only
> > > difference in what I compiled and you sent to me).
> > >
> > > Not at all, this is just my rootfs as an initramfs, not related to
> > > the content of the kernel at all.
> > >
> > >
> > > Good luck!
> > > Miquèl
> >
> > I put in this (simplistic and ugly) tracing:
> > static int ahci_mvebu_probe(struct platform_device *pdev) {
> > const struct ahci_mvebu_plat_data *pdata;
> > struct ahci_host_priv *hpriv;
> > int rc;
> >
> > printk(KERN_INFO "in mvebu probe\n");
> > pdata = of_device_get_match_data(&pdev->dev);
> > printk(KERN_INFO "check device match\n");
> > if (!pdata)
> > return -EINVAL;
> > printk(KERN_INFO "device did match\n");
> >
> > hpriv = ahci_platform_get_resources(pdev, 0); printk(KERN_INFO
> > "check resources\n");
> > if (IS_ERR(hpriv))
> > return PTR_ERR(hpriv);
> >
> > printk(KERN_INFO "resources ok\n");
> > hpriv->flags |= pdata->flags;
> > hpriv->plat_data = (void *)pdata;
> >
> > rc = ahci_platform_enable_resources(hpriv);
> > printk(KERN_INFO "enable resources\n");
> > if (rc)
> > return rc;
> >
> > printk(KERN_INFO "past enable resources\n");
> > hpriv->stop_engine = ahci_mvebu_stop_engine;
> >
> > rc = pdata->plat_config(hpriv); printk(KERN_INFO "disenable
> > resources\n");
> > if (rc)
> > goto disable_resources; printk(KERN_INFO "past disable
> > resources\n");
> >
> > printk(KERN_INFO "init host\n");
> > rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
> > &ahci_platform_sht);
> > printk(KERN_INFO "past init host\n");
> > if (rc)
> > goto disable_resources; printk(KERN_INFO "past rc
> > check\n");
> >
> > return 0;
> >
> > disable_resources:
> > printk(KERN_INFO "in disable resources\n");
> > ahci_platform_disable_resources(hpriv);
> > return rc;
> > }
> >
> >
> > With the 5.2-rc5 device tree I get :
> >
> > [snip]
> > [ 4.204366] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [ 4.210876] in mvebu probe
> > [ 4.213608] check device match
> > [ 4.216710] device did match
> > [ 4.219762] check resources
> > [ 4.222555] resources ok
> > [ 4.225174] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > [ 4.231069] enable resources
> > [ 4.234054] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > [ 4.240800] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [ 4.248736] MACsec IEEE 802.1AE
> > [ 4.252344] libphy: Fixed MDIO Bus: probed
> > [snip]
> >
> > With exactly the same kernel but the 5.0 device tree I get :
> >
> > [snip]
> > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [ 4.210192] in mvebu probe
> > [ 4.212924] check device match
> > [ 4.216026] device did match
> > [ 4.219058] check resources
> > [ 4.221858] resources ok
> > [ 4.224458] enable resources
> > [ 4.227405] past enable resources
> > [ 4.230817] disenable resources
> > [ 4.234042] past disable resources
> > [ 4.237536] init host
> > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports 6
> Gbps 0x1 impl platform mode
> > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs pio
> slum part sxs
> > [ 4.258647] scsi host0: ahci-mvebu
> > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> 0xd00e1fff] port 0x100 irq 21
> > [ 4.270609] past init host
> > [ 4.273353] past rc check
> > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [ 4.284408] MACsec IEEE 802.1AE
> > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > [snip]
> >
> > Unfortunately that does not tell me much. Does it say anything to you?
> > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is failing,
> should I put some traces in that?
>
> Yes, in particular around the PHY initialization, until you found where it fails
> exactly.
>
>
> Thanks,
> Miquèl
I have traced it down to phy_init in phy-core.c and have put in the following traces:
int phy_init(struct phy *phy)
{
int ret;
if (!phy)
return 0;
ret = phy_pm_runtime_get_sync(phy);
if (ret < 0 && ret != -ENOTSUPP)
return ret;
ret = 0; /* Override possible ret == -ENOTSUPP */
mutex_lock(&phy->mutex);
printk(KERN_INFO "in phy init before check\n");
printk(KERN_INFO "phy->init_count %d\n", phy->init_count);
printk(KERN_INFO "phy->ops->init %pr\n", phy->ops->init);
if (phy->init_count == 0 && phy->ops->init) {
printk(KERN_INFO "in phy init past check\n");
ret = phy->ops->init(phy);
if (ret < 0) {
printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
dev_err(&phy->dev, "phy init failed --> %d\n", ret);
goto out;
}
}
++phy->init_count;
out:
mutex_unlock(&phy->mutex);
phy_pm_runtime_put(phy);
return ret;
}
Which produces the following dmesg :
[ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 4.211777] in mvebu probe
[ 4.214508] check device match
[ 4.217609] device did match
[ 4.220662] check resources
[ 4.223455] resources ok
[ 4.226061] in phy init before check
[ 4.229718] phy->init_count 0
[ 4.232774] phy->ops->init (null)
[ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
[ 4.242095] enable resources
[ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
[ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 4.259753] MACsec IEEE 802.1AE
[ 4.263371] libphy: Fixed MDIO Bus: probed
[ 4.267777] tun: Universal TUN/TAP device driver, 1.6
[ 4.273375] libphy: orion_mdio_bus: probed
I believe the significant line is [ 4.232774] phy->ops->init (null)
I'm not sure where that was supposed to have been initialized but it apparently was not.
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-18 15:28 ` Timothy Krantz
@ 2019-06-18 15:36 ` Miquel Raynal
2019-06-18 15:42 ` Timothy Krantz
2019-06-18 17:08 ` Timothy Krantz
0 siblings, 2 replies; 18+ messages in thread
From: Miquel Raynal @ 2019-06-18 15:36 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
> > > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > [ 4.210192] in mvebu probe
> > > [ 4.212924] check device match
> > > [ 4.216026] device did match
> > > [ 4.219058] check resources
> > > [ 4.221858] resources ok
> > > [ 4.224458] enable resources
> > > [ 4.227405] past enable resources
> > > [ 4.230817] disenable resources
> > > [ 4.234042] past disable resources
> > > [ 4.237536] init host
> > > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports 6
> > Gbps 0x1 impl platform mode
> > > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs pio
> > slum part sxs
> > > [ 4.258647] scsi host0: ahci-mvebu
> > > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > 0xd00e1fff] port 0x100 irq 21
> > > [ 4.270609] past init host
> > > [ 4.273353] past rc check
> > > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > [ 4.284408] MACsec IEEE 802.1AE
> > > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > > [snip]
> > >
> > > Unfortunately that does not tell me much. Does it say anything to you?
> > > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is failing,
> > should I put some traces in that?
> >
> > Yes, in particular around the PHY initialization, until you found where it fails
> > exactly.
> >
> >
> > Thanks,
> > Miquèl
>
> I have traced it down to phy_init in phy-core.c and have put in the following traces:
>
> int phy_init(struct phy *phy)
> {
> int ret;
>
> if (!phy)
> return 0;
>
> ret = phy_pm_runtime_get_sync(phy);
> if (ret < 0 && ret != -ENOTSUPP)
> return ret;
> ret = 0; /* Override possible ret == -ENOTSUPP */
>
> mutex_lock(&phy->mutex);
> printk(KERN_INFO "in phy init before check\n");
> printk(KERN_INFO "phy->init_count %d\n", phy->init_count);
> printk(KERN_INFO "phy->ops->init %pr\n", phy->ops->init);
> if (phy->init_count == 0 && phy->ops->init) {
> printk(KERN_INFO "in phy init past check\n");
> ret = phy->ops->init(phy);
> if (ret < 0) {
> printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
> dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> goto out;
> }
> }
> ++phy->init_count;
>
> out:
> mutex_unlock(&phy->mutex);
> phy_pm_runtime_put(phy);
> return ret;
> }
>
> Which produces the following dmesg :
> [ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 4.211777] in mvebu probe
> [ 4.214508] check device match
> [ 4.217609] device did match
> [ 4.220662] check resources
> [ 4.223455] resources ok
> [ 4.226061] in phy init before check
> [ 4.229718] phy->init_count 0
> [ 4.232774] phy->ops->init (null)
> [ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> [ 4.242095] enable resources
> [ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> [ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> [ 4.259753] MACsec IEEE 802.1AE
> [ 4.263371] libphy: Fixed MDIO Bus: probed
> [ 4.267777] tun: Universal TUN/TAP device driver, 1.6
> [ 4.273375] libphy: orion_mdio_bus: probed
>
> I believe the significant line is [ 4.232774] phy->ops->init (null)
>
> I'm not sure where that was supposed to have been initialized but it apparently was not.
Something looks wrong in your logs: you have init_count to 0 and
ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
be evaluated to true?
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-18 15:36 ` Miquel Raynal
@ 2019-06-18 15:42 ` Timothy Krantz
2019-06-18 17:08 ` Timothy Krantz
1 sibling, 0 replies; 18+ messages in thread
From: Timothy Krantz @ 2019-06-18 15:42 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Hi Miquel,
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Tuesday, June 18, 2019 11:36 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> > > > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > [ 4.210192] in mvebu probe
> > > > [ 4.212924] check device match
> > > > [ 4.216026] device did match
> > > > [ 4.219058] check resources
> > > > [ 4.221858] resources ok
> > > > [ 4.224458] enable resources
> > > > [ 4.227405] past enable resources
> > > > [ 4.230817] disenable resources
> > > > [ 4.234042] past disable resources
> > > > [ 4.237536] init host
> > > > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports
> 6
> > > Gbps 0x1 impl platform mode
> > > > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs
> pio
> > > slum part sxs
> > > > [ 4.258647] scsi host0: ahci-mvebu
> > > > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > > 0xd00e1fff] port 0x100 irq 21
> > > > [ 4.270609] past init host
> > > > [ 4.273353] past rc check
> > > > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > > [ 4.284408] MACsec IEEE 802.1AE
> > > > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > > > [snip]
> > > >
> > > > Unfortunately that does not tell me much. Does it say anything to you?
> > > > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is
> failing,
> > > should I put some traces in that?
> > >
> > > Yes, in particular around the PHY initialization, until you found
> > > where it fails exactly.
> > >
> > >
> > > Thanks,
> > > Miquèl
> >
> > I have traced it down to phy_init in phy-core.c and have put in the following
> traces:
> >
> > int phy_init(struct phy *phy)
> > {
> > int ret;
> >
> > if (!phy)
> > return 0;
> >
> > ret = phy_pm_runtime_get_sync(phy);
> > if (ret < 0 && ret != -ENOTSUPP)
> > return ret;
> > ret = 0; /* Override possible ret == -ENOTSUPP */
> >
> > mutex_lock(&phy->mutex);
> > printk(KERN_INFO "in phy init before check\n"); printk(KERN_INFO
> > "phy->init_count %d\n", phy->init_count); printk(KERN_INFO
> > "phy->ops->init %pr\n", phy->ops->init);
> > if (phy->init_count == 0 && phy->ops->init) { printk(KERN_INFO
> > "in phy init past check\n");
> > ret = phy->ops->init(phy);
> > if (ret < 0) {
> > printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
> > dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> > goto out;
> > }
> > }
> > ++phy->init_count;
> >
> > out:
> > mutex_unlock(&phy->mutex);
> > phy_pm_runtime_put(phy);
> > return ret;
> > }
> >
> > Which produces the following dmesg :
> > [ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [ 4.211777] in mvebu probe
> > [ 4.214508] check device match
> > [ 4.217609] device did match
> > [ 4.220662] check resources
> > [ 4.223455] resources ok
> > [ 4.226061] in phy init before check
> > [ 4.229718] phy->init_count 0
> > [ 4.232774] phy->ops->init (null)
> > [ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > [ 4.242095] enable resources
> > [ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > [ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [ 4.259753] MACsec IEEE 802.1AE
> > [ 4.263371] libphy: Fixed MDIO Bus: probed
> > [ 4.267777] tun: Universal TUN/TAP device driver, 1.6
> > [ 4.273375] libphy: orion_mdio_bus: probed
> >
> > I believe the significant line is [ 4.232774] phy->ops->init (null)
> >
> > I'm not sure where that was supposed to have been initialized but it
> apparently was not.
>
> Something looks wrong in your logs: you have init_count to 0 and
> ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
> be evaluated to true?
>
> Miquèl
I do not believe it did evaluate true. I believe it fell through to
> ++phy->init_count;
>
> out:
> mutex_unlock(&phy->mutex);
> phy_pm_runtime_put(phy);
> return ret;
> }
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-18 15:36 ` Miquel Raynal
2019-06-18 15:42 ` Timothy Krantz
@ 2019-06-18 17:08 ` Timothy Krantz
2019-06-18 17:26 ` Miquel Raynal
1 sibling, 1 reply; 18+ messages in thread
From: Timothy Krantz @ 2019-06-18 17:08 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Miquel,
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Tuesday, June 18, 2019 11:36 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
>
> Hi Timothy,
>
> > > > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > [ 4.210192] in mvebu probe
> > > > [ 4.212924] check device match
> > > > [ 4.216026] device did match
> > > > [ 4.219058] check resources
> > > > [ 4.221858] resources ok
> > > > [ 4.224458] enable resources
> > > > [ 4.227405] past enable resources
> > > > [ 4.230817] disenable resources
> > > > [ 4.234042] past disable resources
> > > > [ 4.237536] init host
> > > > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports
> 6
> > > Gbps 0x1 impl platform mode
> > > > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs
> pio
> > > slum part sxs
> > > > [ 4.258647] scsi host0: ahci-mvebu
> > > > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > > 0xd00e1fff] port 0x100 irq 21
> > > > [ 4.270609] past init host
> > > > [ 4.273353] past rc check
> > > > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > > [ 4.284408] MACsec IEEE 802.1AE
> > > > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > > > [snip]
> > > >
> > > > Unfortunately that does not tell me much. Does it say anything to you?
> > > > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is
> failing,
> > > should I put some traces in that?
> > >
> > > Yes, in particular around the PHY initialization, until you found
> > > where it fails exactly.
> > >
> > >
> > > Thanks,
> > > Miquèl
> >
> > I have traced it down to phy_init in phy-core.c and have put in the following
> traces:
> >
> > int phy_init(struct phy *phy)
> > {
> > int ret;
> >
> > if (!phy)
> > return 0;
> >
> > ret = phy_pm_runtime_get_sync(phy);
> > if (ret < 0 && ret != -ENOTSUPP)
> > return ret;
> > ret = 0; /* Override possible ret == -ENOTSUPP */
> >
> > mutex_lock(&phy->mutex);
> > printk(KERN_INFO "in phy init before check\n"); printk(KERN_INFO
> > "phy->init_count %d\n", phy->init_count); printk(KERN_INFO
> > "phy->ops->init %pr\n", phy->ops->init);
> > if (phy->init_count == 0 && phy->ops->init) { printk(KERN_INFO
> > "in phy init past check\n");
> > ret = phy->ops->init(phy);
> > if (ret < 0) {
> > printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
> > dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> > goto out;
> > }
> > }
> > ++phy->init_count;
> >
> > out:
> > mutex_unlock(&phy->mutex);
> > phy_pm_runtime_put(phy);
> > return ret;
> > }
> >
> > Which produces the following dmesg :
> > [ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [ 4.211777] in mvebu probe
> > [ 4.214508] check device match
> > [ 4.217609] device did match
> > [ 4.220662] check resources
> > [ 4.223455] resources ok
> > [ 4.226061] in phy init before check
> > [ 4.229718] phy->init_count 0
> > [ 4.232774] phy->ops->init (null)
> > [ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > [ 4.242095] enable resources
> > [ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > [ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [ 4.259753] MACsec IEEE 802.1AE
> > [ 4.263371] libphy: Fixed MDIO Bus: probed
> > [ 4.267777] tun: Universal TUN/TAP device driver, 1.6
> > [ 4.273375] libphy: orion_mdio_bus: probed
> >
> > I believe the significant line is [ 4.232774] phy->ops->init (null)
> >
> > I'm not sure where that was supposed to have been initialized but it
> apparently was not.
>
> Something looks wrong in your logs: you have init_count to 0 and
> ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
> be evaluated to true?
>
> Miquèl
My prior assertion that the if did not evaluate true is based on not seeing the :
printk(KERN_INFO "in phy init past check\n");
inside of the if statement.
That being said. I have 3 espressobins, one from the original kickstart, one bought on amazon and purported to be a v5 board and one v7 board bought from globalscale directly.
All of the testing I have done has been on the v5 board. Is there any chance that there might be some differences in the various revisions? Want revision board are you testing on? If I have one that matches I will test on that one as well.
Tim
p.s. Thank you for your patience.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-18 17:08 ` Timothy Krantz
@ 2019-06-18 17:26 ` Miquel Raynal
2019-06-18 20:07 ` Timothy Krantz
0 siblings, 1 reply; 18+ messages in thread
From: Miquel Raynal @ 2019-06-18 17:26 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Tue, 18 Jun 2019
13:08:39 -0400:
> Miquel,
>
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Tuesday, June 18, 2019 11:36 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > > > > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > > [ 4.210192] in mvebu probe
> > > > > [ 4.212924] check device match
> > > > > [ 4.216026] device did match
> > > > > [ 4.219058] check resources
> > > > > [ 4.221858] resources ok
> > > > > [ 4.224458] enable resources
> > > > > [ 4.227405] past enable resources
> > > > > [ 4.230817] disenable resources
> > > > > [ 4.234042] past disable resources
> > > > > [ 4.237536] init host
> > > > > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports
> > 6
> > > > Gbps 0x1 impl platform mode
> > > > > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs
> > pio
> > > > slum part sxs
> > > > > [ 4.258647] scsi host0: ahci-mvebu
> > > > > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > > > 0xd00e1fff] port 0x100 irq 21
> > > > > [ 4.270609] past init host
> > > > > [ 4.273353] past rc check
> > > > > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > > > [ 4.284408] MACsec IEEE 802.1AE
> > > > > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > > > > [snip]
> > > > >
> > > > > Unfortunately that does not tell me much. Does it say anything to you?
> > > > > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is
> > failing,
> > > > should I put some traces in that?
> > > >
> > > > Yes, in particular around the PHY initialization, until you found
> > > > where it fails exactly.
> > > >
> > > >
> > > > Thanks,
> > > > Miquèl
> > >
> > > I have traced it down to phy_init in phy-core.c and have put in the following
> > traces:
> > >
> > > int phy_init(struct phy *phy)
> > > {
> > > int ret;
> > >
> > > if (!phy)
> > > return 0;
> > >
> > > ret = phy_pm_runtime_get_sync(phy);
> > > if (ret < 0 && ret != -ENOTSUPP)
> > > return ret;
> > > ret = 0; /* Override possible ret == -ENOTSUPP */
> > >
> > > mutex_lock(&phy->mutex);
> > > printk(KERN_INFO "in phy init before check\n"); printk(KERN_INFO
> > > "phy->init_count %d\n", phy->init_count); printk(KERN_INFO
> > > "phy->ops->init %pr\n", phy->ops->init);
> > > if (phy->init_count == 0 && phy->ops->init) { printk(KERN_INFO
> > > "in phy init past check\n");
> > > ret = phy->ops->init(phy);
> > > if (ret < 0) {
> > > printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
> > > dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> > > goto out;
> > > }
> > > }
> > > ++phy->init_count;
> > >
> > > out:
> > > mutex_unlock(&phy->mutex);
> > > phy_pm_runtime_put(phy);
> > > return ret;
> > > }
> > >
> > > Which produces the following dmesg :
> > > [ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > > [ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > [ 4.211777] in mvebu probe
> > > [ 4.214508] check device match
> > > [ 4.217609] device did match
> > > [ 4.220662] check resources
> > > [ 4.223455] resources ok
> > > [ 4.226061] in phy init before check
> > > [ 4.229718] phy->init_count 0
> > > [ 4.232774] phy->ops->init (null)
> > > [ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > > [ 4.242095] enable resources
> > > [ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > > [ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > [ 4.259753] MACsec IEEE 802.1AE
> > > [ 4.263371] libphy: Fixed MDIO Bus: probed
> > > [ 4.267777] tun: Universal TUN/TAP device driver, 1.6
> > > [ 4.273375] libphy: orion_mdio_bus: probed
> > >
> > > I believe the significant line is [ 4.232774] phy->ops->init (null)
> > >
> > > I'm not sure where that was supposed to have been initialized but it
> > apparently was not.
> >
> > Something looks wrong in your logs: you have init_count to 0 and
> > ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
> > be evaluated to true?
> >
> > Miquèl
>
> My prior assertion that the if did not evaluate true is based on not seeing the :
>
> printk(KERN_INFO "in phy init past check\n");
>
> inside of the if statement.
>
> That being said. I have 3 espressobins, one from the original kickstart, one bought on amazon and purported to be a v5 board and one v7 board bought from globalscale directly.
>
> All of the testing I have done has been on the v5 board. Is there any chance that there might be some differences in the various revisions? Want revision board are you testing on? If I have one that matches I will test on that one as well.
I don't think it's a hw problem, v5 is fine. Have you updated your
firmware recently? You will need a recent firmware (ATF) in order to
have the SMC calls to work. You can trace the _power_on() function
which probably fails at its end in
drivers/phy/marvell/phy-mvebu-a3700-comphy.c.
Good luck!
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: espressobin device tree with kernel 5.1 RC
2019-06-18 17:26 ` Miquel Raynal
@ 2019-06-18 20:07 ` Timothy Krantz
2019-06-19 10:29 ` Miquel Raynal
0 siblings, 1 reply; 18+ messages in thread
From: Timothy Krantz @ 2019-06-18 20:07 UTC (permalink / raw)
To: 'Miquel Raynal'; +Cc: linux-arm-kernel
Hi Miquel,
> -----Original Message-----
>
> I don't think it's a hw problem, v5 is fine. Have you updated your firmware
> recently? You will need a recent firmware (ATF) in order to have the SMC
> calls to work. You can trace the _power_on() function which probably fails at
> its end in drivers/phy/marvell/phy-mvebu-a3700-comphy.c.
>
> Good luck!
> Miquèl
I added the following traces to drivers/phy/marvell/phy-mvebu-a3700-comphy.c :
static int mvebu_a3700_comphy_smc(unsigned long function, unsigned long lane,
unsigned long mode)
{
struct arm_smccc_res res;
printk(KERN_INFO "in a3700 comphy smc\n");
arm_smccc_smc(function, lane, mode, 0, 0, 0, 0, 0, &res);
printk(KERN_INFO "res.a0=%lx\n", res.a0);
return res.a0;
}
And
static int mvebu_a3700_comphy_power_on(struct phy *phy)
{
struct mvebu_a3700_comphy_lane *lane = phy_get_drvdata(phy);
u32 fw_param;
int fw_mode;
fw_mode = mvebu_a3700_comphy_get_fw_mode(lane->id, lane->port,
lane->mode, lane->submode);
printk(KERN_INFO "in power on\n");
if (fw_mode < 0) {
printk(KERN_INFO "fw_mode < 0\n");
dev_err(lane->dev, "invalid COMPHY mode\n");
return fw_mode;
}
printk(KERN_INFO "switch lane->mode\n");
switch (lane->mode) {
case PHY_MODE_USB_HOST_SS:
printk(KERN_INFO "usb host\n");
dev_dbg(lane->dev, "set lane %d to USB3 host mode\n", lane->id);
fw_param = COMPHY_FW_MODE(fw_mode);
break;
case PHY_MODE_SATA:
printk(KERN_INFO "sata\n");
dev_dbg(lane->dev, "set lane %d to SATA mode\n", lane->id);
fw_param = COMPHY_FW_MODE(fw_mode);
break;
case PHY_MODE_ETHERNET:
switch (lane->submode) {
case PHY_INTERFACE_MODE_SGMII:
printk(KERN_INFO "sgmii\n");
dev_dbg(lane->dev, "set lane %d to SGMII mode\n",
lane->id);
fw_param = COMPHY_FW_NET(fw_mode, lane->port,
COMPHY_FW_SPEED_1_25G);
break;
case PHY_INTERFACE_MODE_2500BASEX:
printk(KERN_INFO "HS sgmii\n");
dev_dbg(lane->dev, "set lane %d to HS SGMII mode\n",
lane->id);
fw_param = COMPHY_FW_NET(fw_mode, lane->port,
COMPHY_FW_SPEED_3_125G);
break;
default:
printk(KERN_INFO "unsupported mode\n");
dev_err(lane->dev, "unsupported PHY submode (%d)\n",
lane->submode);
return -ENOTSUPP;
}
break;
case PHY_MODE_PCIE:
printk(KERN_INFO "pcie\n");
dev_dbg(lane->dev, "set lane %d to PCIe mode\n", lane->id);
fw_param = COMPHY_FW_PCIE(fw_mode, lane->port,
COMPHY_FW_SPEED_5G,
phy->attrs.bus_width);
break;
default:
printk(KERN_INFO "unsupported 2\n");
dev_err(lane->dev, "unsupported PHY mode (%d)\n", lane->mode);
return -ENOTSUPP;
}
return mvebu_a3700_comphy_smc(COMPHY_SIP_POWER_ON, lane->id, fw_param);
}
Resulting in the following dmesg:
[ 4.204429] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 4.210933] in mvebu probe
[ 4.213664] check device match
[ 4.216765] device did match
[ 4.219825] check resources
[ 4.222619] resources ok
[ 4.225225] in phy init before check
[ 4.228881] phy->init_count 0
[ 4.231936] phy->ops->init (null)
[ 4.235342] in power on
[ 4.237847] switch lane->mode
[ 4.240887] sata
[ 4.242775] in a3700 comphy smc
[ 4.246003] res.a0=ffffffffffffffff
[ 4.249593] phy phy-d0018300.phy.2: phy poweron failed --> -1
[ 4.255504] enable resources
[ 4.258487] ahci-mvebu: probe of d00e0000.sata failed with error -1
[ 4.265231] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
So [ 4.246003] res.a0=ffffffffffffffff is the power on failure?
> You will need a recent firmware (ATF) in order to have the SMC
> calls to work.
That sounds promising. My UBOOT is not *that* old:
üTIM-1.0
WTMI-devel-18.07.0-6050fd5
WTMI: system early-init
CPU VDD voltage default value: 1.155V
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL1: Built : 15:11:39, Sep 7 2018
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL2: Built : 15:11:42, Sep 7 2018
NOTICE: BL1: Booting BL31
NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL31: Built : 15:1
U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200)
Do you know where I might find a newer (pre built) uboot?
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: espressobin device tree with kernel 5.1 RC
2019-06-18 20:07 ` Timothy Krantz
@ 2019-06-19 10:29 ` Miquel Raynal
0 siblings, 0 replies; 18+ messages in thread
From: Miquel Raynal @ 2019-06-19 10:29 UTC (permalink / raw)
To: Timothy Krantz; +Cc: linux-arm-kernel
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Tue, 18 Jun 2019
16:07:34 -0400:
> Hi Miquel,
>
> > -----Original Message-----
> >
> > I don't think it's a hw problem, v5 is fine. Have you updated your firmware
> > recently? You will need a recent firmware (ATF) in order to have the SMC
> > calls to work. You can trace the _power_on() function which probably fails at
> > its end in drivers/phy/marvell/phy-mvebu-a3700-comphy.c.
> >
> > Good luck!
> > Miquèl
>
> I added the following traces to drivers/phy/marvell/phy-mvebu-a3700-comphy.c :
>
> static int mvebu_a3700_comphy_smc(unsigned long function, unsigned long lane,
> unsigned long mode)
> {
> struct arm_smccc_res res;
>
> printk(KERN_INFO "in a3700 comphy smc\n");
> arm_smccc_smc(function, lane, mode, 0, 0, 0, 0, 0, &res);
> printk(KERN_INFO "res.a0=%lx\n", res.a0);
>
> return res.a0;
> }
>
> And
> static int mvebu_a3700_comphy_power_on(struct phy *phy)
> {
> struct mvebu_a3700_comphy_lane *lane = phy_get_drvdata(phy);
> u32 fw_param;
> int fw_mode;
>
> fw_mode = mvebu_a3700_comphy_get_fw_mode(lane->id, lane->port,
> lane->mode, lane->submode);
> printk(KERN_INFO "in power on\n");
> if (fw_mode < 0) {
> printk(KERN_INFO "fw_mode < 0\n");
> dev_err(lane->dev, "invalid COMPHY mode\n");
> return fw_mode;
> }
>
> printk(KERN_INFO "switch lane->mode\n");
> switch (lane->mode) {
> case PHY_MODE_USB_HOST_SS:
> printk(KERN_INFO "usb host\n");
> dev_dbg(lane->dev, "set lane %d to USB3 host mode\n", lane->id);
> fw_param = COMPHY_FW_MODE(fw_mode);
> break;
> case PHY_MODE_SATA:
> printk(KERN_INFO "sata\n");
> dev_dbg(lane->dev, "set lane %d to SATA mode\n", lane->id);
> fw_param = COMPHY_FW_MODE(fw_mode);
> break;
> case PHY_MODE_ETHERNET:
> switch (lane->submode) {
> case PHY_INTERFACE_MODE_SGMII:
> printk(KERN_INFO "sgmii\n");
> dev_dbg(lane->dev, "set lane %d to SGMII mode\n",
> lane->id);
> fw_param = COMPHY_FW_NET(fw_mode, lane->port,
> COMPHY_FW_SPEED_1_25G);
> break;
> case PHY_INTERFACE_MODE_2500BASEX:
> printk(KERN_INFO "HS sgmii\n");
> dev_dbg(lane->dev, "set lane %d to HS SGMII mode\n",
> lane->id);
> fw_param = COMPHY_FW_NET(fw_mode, lane->port,
> COMPHY_FW_SPEED_3_125G);
> break;
> default:
> printk(KERN_INFO "unsupported mode\n");
> dev_err(lane->dev, "unsupported PHY submode (%d)\n",
> lane->submode);
> return -ENOTSUPP;
> }
> break;
> case PHY_MODE_PCIE:
> printk(KERN_INFO "pcie\n");
> dev_dbg(lane->dev, "set lane %d to PCIe mode\n", lane->id);
> fw_param = COMPHY_FW_PCIE(fw_mode, lane->port,
> COMPHY_FW_SPEED_5G,
> phy->attrs.bus_width);
> break;
> default:
> printk(KERN_INFO "unsupported 2\n");
> dev_err(lane->dev, "unsupported PHY mode (%d)\n", lane->mode);
> return -ENOTSUPP;
> }
>
> return mvebu_a3700_comphy_smc(COMPHY_SIP_POWER_ON, lane->id, fw_param);
> }
>
> Resulting in the following dmesg:
>
> [ 4.204429] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 4.210933] in mvebu probe
> [ 4.213664] check device match
> [ 4.216765] device did match
> [ 4.219825] check resources
> [ 4.222619] resources ok
> [ 4.225225] in phy init before check
> [ 4.228881] phy->init_count 0
> [ 4.231936] phy->ops->init (null)
> [ 4.235342] in power on
> [ 4.237847] switch lane->mode
> [ 4.240887] sata
> [ 4.242775] in a3700 comphy smc
> [ 4.246003] res.a0=ffffffffffffffff
> [ 4.249593] phy phy-d0018300.phy.2: phy poweron failed --> -1
> [ 4.255504] enable resources
> [ 4.258487] ahci-mvebu: probe of d00e0000.sata failed with error -1
> [ 4.265231] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>
>
> So [ 4.246003] res.a0=ffffffffffffffff is the power on failure?
That's indeed -1 if you consider it as a signed 64-bit value.
>
> > You will need a recent firmware (ATF) in order to have the SMC
> > calls to work.
>
> That sounds promising. My UBOOT is not *that* old:
>
> üTIM-1.0
> WTMI-devel-18.07.0-6050fd5
> WTMI: system early-init
> CPU VDD voltage default value: 1.155V
> NOTICE: Booting Trusted Firmware
> NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
> NOTICE: BL1: Built : 15:11:39, Sep 7 2018
> NOTICE: BL1: Booting BL2
> NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
> NOTICE: BL2: Built : 15:11:42, Sep 7 2018
> NOTICE: BL1: Booting BL31
> NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
> NOTICE: BL31: Built : 15:1
>
> U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200)
>
> Do you know where I might find a newer (pre built) uboot?
http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-06-19 10:29 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAABB6J1kxOR7T73eMrM92Eq+AQAAAAA=@stahurabrenner.com>
2019-04-29 7:57 ` espressobin device tree with kernel 5.1 RC Miquel Raynal
2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
2019-04-29 16:07 ` Marc Gonzalez
2019-04-29 18:10 ` Miquel Raynal
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
2019-06-17 9:38 ` Miquel Raynal
2019-06-17 9:40 ` Miquel Raynal
2019-06-17 17:19 ` Timothy Krantz
2019-06-18 7:58 ` Miquel Raynal
2019-06-18 14:15 ` Timothy Krantz
2019-06-18 14:24 ` Miquel Raynal
2019-06-18 15:28 ` Timothy Krantz
2019-06-18 15:36 ` Miquel Raynal
2019-06-18 15:42 ` Timothy Krantz
2019-06-18 17:08 ` Timothy Krantz
2019-06-18 17:26 ` Miquel Raynal
2019-06-18 20:07 ` Timothy Krantz
2019-06-19 10:29 ` Miquel Raynal
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.