diff mbox series

imx8qxp mek: Booting mainline kernel with mainline U-Boot

Message ID 39592224-4f2d-a1b2-b8e5-3004db942f6b@ti.com
State New
Headers show
Series imx8qxp mek: Booting mainline kernel with mainline U-Boot | expand

Commit Message

Lokesh Vutla Jan. 17, 2020, 6:07 a.m. UTC
On 16/01/20 11:46 PM, Tom Rini wrote:
> On Thu, Jan 16, 2020 at 08:03:51PM +0200, Igor Opaniuk wrote:
>> Hi Fabio,
>>
>> On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam <festevam at gmail.com> wrote:
>>>
>>> Hi Anatolij,
>>>
>>> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust at denx.de> wrote:
>>>
>>>> Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot
>>>> test, but I have an i.MX8QXP based custom SoM with console on ttyLP2.
>>>> Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga
>>>> and it boots successfully (with NFS rootfs or rootfs on eMMC).
>>>
>>> I have just tested imx_4.14.98_2.0.0_ga and still get the same hang.
>>>
>>> [Adding Marcel]
>> Marcel is on vacation.
>>
>> FYI, mainline U-boot is broken on all our iMX8QXP and iMX8QM SoMs
>> at all since f0cc4eae9a ("core: device: use dev_power_domain_on") is merged, the
>> status hasn't changed. I haven't got deeply into this issue, just
>> quickly tried different
>> combinations of TF-A and SECO/SCFW, none of them has any impact.
>> Will get back to this issue soon.
>>>
>>> Just wondering if anyone else managed to boot mainline U-Boot with
>>> mainline kernel on i.MX8QXP.
>> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
> 
> Adding in Lokesh as he nak'd the revert before because that would break
> other platforms and I chimed in saying that breaking one set of
> platforms to unbreak another set of platforms isn't a trade-off I like.
> 

Right, the mentioned patch f0cc4eae9a1 ("core: device: use dev_power_domain_on")
checks for power_domain return status when dm core tries to enable pd during
probe. If power domain enabling is failed then no point proceeding further to probe.

There are 2 ways to solve this:
1) Drop the return check like below. Which IMHO is a hack:



2) Debug which device power-domain is failing and fix the driver or make sure
that dm core will not touch the pd by enabling the flag
DM_FLAG_DEFAULT_PD_CTRL_OFF in it.

Thanks and regards,
Lokesh

Comments

Oliver Graute Jan. 23, 2020, 1:53 p.m. UTC | #1
On 17/01/20, Lokesh Vutla wrote:
> >>> Just wondering if anyone else managed to boot mainline U-Boot with
> >>> mainline kernel on i.MX8QXP.
> >> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
> > 
> > Adding in Lokesh as he nak'd the revert before because that would break
> > other platforms and I chimed in saying that breaking one set of
> > platforms to unbreak another set of platforms isn't a trade-off I like.
> > 
> 
> Right, the mentioned patch f0cc4eae9a1 ("core: device: use dev_power_domain_on")
> checks for power_domain return status when dm core tries to enable pd during
> probe. If power domain enabling is failed then no point proceeding further to probe.
> 
> There are 2 ways to solve this:
> 1) Drop the return check like below. Which IMHO is a hack:
> 
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 9f39218423..c80ce16fbd 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -432,11 +432,8 @@ int device_probe(struct udevice *dev)
> 
>  	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
>  	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> -	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> -		ret = dev_power_domain_on(dev);
> -		if (ret)
> -			goto fail;
> -	}
> +	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> +		dev_power_domain_on(dev);
> 
>  	ret = uclass_pre_probe_device(dev);
>  	if (ret)

ok very thx, this works for me together with fresh a compiled scfw
(1.2.5) from advantech. Now I'am running into this phy issue:

U-Boot 2020.01-00001-g7b3e47a09f (Jan 23 2020 - 14:30:03 +0100)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

Model: Advantech iMX8QM Qseven series
Board: ROM-7720-A1 4GB
Build: SCFW 494c97f3, SECO-FW 5ea79733, ATF d6451cc
Boot:  SD2
DRAM:  4 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial at 5a060000
Out:   serial at 5a060000
Err:   serial at 5a060000
Net:   Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Can't find FEC0 clk rate: -19
Could not get PHY for FEC1: addr 1
No ethernet found.

Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc2 is current device
** No partition table - mmc 2 **
** No partition table - mmc 2 **
Booting from net ...
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
No ethernet found.
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
Could not get PHY for FEC0: addr 0
No ethernet found.
Could not get PHY for FEC0: addr 0

Best Regards,

Oliver
Lokesh Vutla Jan. 23, 2020, 2:07 p.m. UTC | #2
On 23/01/20 7:23 PM, Oliver Graute wrote:
> On 17/01/20, Lokesh Vutla wrote:
>>>>> Just wondering if anyone else managed to boot mainline U-Boot with
>>>>> mainline kernel on i.MX8QXP.
>>>> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
>>>
>>> Adding in Lokesh as he nak'd the revert before because that would break
>>> other platforms and I chimed in saying that breaking one set of
>>> platforms to unbreak another set of platforms isn't a trade-off I like.
>>>
>>
>> Right, the mentioned patch f0cc4eae9a1 ("core: device: use dev_power_domain_on")
>> checks for power_domain return status when dm core tries to enable pd during
>> probe. If power domain enabling is failed then no point proceeding further to probe.
>>
>> There are 2 ways to solve this:
>> 1) Drop the return check like below. Which IMHO is a hack:
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index 9f39218423..c80ce16fbd 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -432,11 +432,8 @@ int device_probe(struct udevice *dev)
>>
>>  	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
>>  	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
>> -	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
>> -		ret = dev_power_domain_on(dev);
>> -		if (ret)
>> -			goto fail;
>> -	}
>> +	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
>> +		dev_power_domain_on(dev);
>>
>>  	ret = uclass_pre_probe_device(dev);
>>  	if (ret)
> 
> ok very thx, this works for me together with fresh a compiled scfw

This is because enabling power domain is failed and the failure is being
ignored. Ignorance of such issues can lead to unexpected behavior like the one
below :)

> (1.2.5) from advantech. Now I'am running into this phy issue:

I am not really an expert here. Peng should be able to comment on this.

Thanks and regards,
Lokesh

> 
> U-Boot 2020.01-00001-g7b3e47a09f (Jan 23 2020 - 14:30:03 +0100)
> 
> CPU:   NXP i.MX8QM RevB A53 at 1200 MHz
> 
> Model: Advantech iMX8QM Qseven series
> Board: ROM-7720-A1 4GB
> Build: SCFW 494c97f3, SECO-FW 5ea79733, ATF d6451cc
> Boot:  SD2
> DRAM:  4 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> In:    serial at 5a060000
> Out:   serial at 5a060000
> Err:   serial at 5a060000
> Net:   Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Can't find FEC0 clk rate: -19
> Could not get PHY for FEC1: addr 1
> No ethernet found.
> 
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc2 is current device
> ** No partition table - mmc 2 **
> ** No partition table - mmc 2 **
> Booting from net ...
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> No ethernet found.
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> Could not get PHY for FEC0: addr 0
> No ethernet found.
> Could not get PHY for FEC0: addr 0
> 
> Best Regards,
> 
> Oliver
>
Peng Fan Jan. 27, 2020, 1:13 p.m. UTC | #3
> Subject: Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
> 
> 
> 
> On 23/01/20 7:23 PM, Oliver Graute wrote:
> > On 17/01/20, Lokesh Vutla wrote:
> >>>>> Just wondering if anyone else managed to boot mainline U-Boot with
> >>>>> mainline kernel on i.MX8QXP.
> >>>> I can test it for you with the revert patch for f0cc4eae9a applied
> tomorrow.
> >>>
> >>> Adding in Lokesh as he nak'd the revert before because that would
> >>> break other platforms and I chimed in saying that breaking one set
> >>> of platforms to unbreak another set of platforms isn't a trade-off I like.
> >>>
> >>
> >> Right, the mentioned patch f0cc4eae9a1 ("core: device: use
> >> dev_power_domain_on") checks for power_domain return status when
> dm
> >> core tries to enable pd during probe. If power domain enabling is failed
> then no point proceeding further to probe.
> >>
> >> There are 2 ways to solve this:
> >> 1) Drop the return check like below. Which IMHO is a hack:
> >>
> >> diff --git a/drivers/core/device.c b/drivers/core/device.c index
> >> 9f39218423..c80ce16fbd 100644
> >> --- a/drivers/core/device.c
> >> +++ b/drivers/core/device.c
> >> @@ -432,11 +432,8 @@ int device_probe(struct udevice *dev)
> >>
> >>  	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
> >>  	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> >> -	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> >> -		ret = dev_power_domain_on(dev);
> >> -		if (ret)
> >> -			goto fail;
> >> -	}
> >> +	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> >> +		dev_power_domain_on(dev);
> >>
> >>  	ret = uclass_pre_probe_device(dev);
> >>  	if (ret)
> >
> > ok very thx, this works for me together with fresh a compiled scfw
> 
> This is because enabling power domain is failed and the failure is being
> ignored. Ignorance of such issues can lead to unexpected behavior like the
> one below :)

Yes. A err msg be printed out when failure should be helpful.

Regards,
Peng.

> 
> > (1.2.5) from advantech. Now I'am running into this phy issue:
> 
> I am not really an expert here. Peng should be able to comment on this.
> 
> Thanks and regards,
> Lokesh
> 
> >
> > U-Boot 2020.01-00001-g7b3e47a09f (Jan 23 2020 - 14:30:03 +0100)
> >
> > CPU:   NXP i.MX8QM RevB A53 at 1200 MHz
> >
> > Model: Advantech iMX8QM Qseven series
> > Board: ROM-7720-A1 4GB
> > Build: SCFW 494c97f3, SECO-FW 5ea79733, ATF d6451cc
> > Boot:  SD2
> > DRAM:  4 GiB
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... *** Warning - bad CRC, using default
> > environment
> >
> > In:    serial at 5a060000
> > Out:   serial at 5a060000
> > Err:   serial at 5a060000
> > Net:   Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Can't find FEC0 clk rate: -19
> > Could not get PHY for FEC1: addr 1
> > No ethernet found.
> >
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc2 is current device
> > ** No partition table - mmc 2 **
> > ** No partition table - mmc 2 **
> > Booting from net ...
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > No ethernet found.
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > Could not get PHY for FEC0: addr 0
> > No ethernet found.
> > Could not get PHY for FEC0: addr 0
> >
> > Best Regards,
> >
> > Oliver
> >
diff mbox series

Patch

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 9f39218423..c80ce16fbd 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -432,11 +432,8 @@  int device_probe(struct udevice *dev)

 	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
 	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
-	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
-		ret = dev_power_domain_on(dev);
-		if (ret)
-			goto fail;
-	}
+	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
+		dev_power_domain_on(dev);

 	ret = uclass_pre_probe_device(dev);
 	if (ret)