* 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
[parent not found: <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>]
* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).