From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lokesh Vutla Date: Fri, 17 Jan 2020 11:37:04 +0530 Subject: imx8qxp mek: Booting mainline kernel with mainline U-Boot In-Reply-To: <20200116181628.GM8732@bill-the-cat> References: <20200113165316.5368475d@crub> <20200115000431.0a911446@crub> <20200116181628.GM8732@bill-the-cat> Message-ID: <39592224-4f2d-a1b2-b8e5-3004db942f6b@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >>> >>> Hi Anatolij, >>> >>> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin 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: 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) 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