Re: espressobin device tree with kernel 5.1 RC

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Uwe Kleine-König]

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

Re: espressobin device tree with kernel 5.1 RC

[Marc Gonzalez]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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

RE: espressobin device tree with kernel 5.1 RC

[Timothy Krantz]

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

Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal]

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