imx8qxp mek: Booting mainline kernel with mainline U-Boot

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Peng,

Have you managed to boot a mainline kernel with mainline U-Boot on a
imx8qxp mek?

Here is what I get:

U-Boot SPL 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300)
Normal Boot
WDT:   Not found!
Trying to boot from MMC2_2
Load image from MMC/SD 0x46800


U-Boot 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300)

CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz at 32C

Model: Freescale i.MX8QXP MEK
Board: iMX8QXP MEK
Build: SCFW 550f3079, SECO-FW d7523fe8, ATF 70fa7bc
Boot:  SD1
DRAM:  3 GiB
Failed to enable ipg clk
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial at 5a060000
Out:   serial at 5a060000
Err:   serial at 5a060000
Net:   Failed to enable ipg clk

Warning: ethernet at 5b040000 (eth0) using random MAC address - e2:9c:db:94:fc:d5
eth0: ethernet at 5b040000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
26221056 bytes read in 1134 ms (22.1 MiB/s)
Booting from mmc ...
13953 bytes read in 14 ms (972.7 KiB/s)
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 0000000083000000, end 0000000083006680

Starting kernel ...
[It hangs here]

Booting a NXP kernel also did not work.

Any ideas?

Regards,

Fabio Estevam

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Anatolij Gustschin]

Hi Fabio,

On Mon, 13 Jan 2020 12:36:20 -0300
Fabio Estevam festevam at gmail.com wrote:
...
> Starting kernel ...
> [It hangs here]
> 
> Booting a NXP kernel also did not work.
> 
> Any ideas?

Does the kernel boot if you apply following U-Boot changes ?

diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
index 65c8ac1a7e..e51fe4b897 100644
--- a/arch/arm/mach-imx/imx8/fdt.c
+++ b/arch/arm/mach-imx/imx8/fdt.c
@@ -279,8 +279,9 @@ static int ft_add_optee_node(void *fdt, bd_t *bd)
 int ft_system_setup(void *blob, bd_t *bd)
 {
 	int ret;
-
+#if 0
 	update_fdt_with_owned_resources(blob);
+#endif
 
 	if (is_imx8qm()) {
 		ret = config_smmu_fdt(blob);
diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
index 5c8dc4ad70..be041b0b4c 100644
--- a/drivers/core/device-remove.c
+++ b/drivers/core/device-remove.c
@@ -192,10 +192,11 @@ int device_remove(struct udevice *dev, uint flags)
 				__func__, dev->name);
 		}
 	}
-
+#if 0
 	if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
 	    (dev != gd->cur_serial_dev))
 		dev_power_domain_off(dev);
+#endif
 
 	if (flags_remove(flags, drv->flags)) {
 		device_free(dev);

--
Anatolij

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Anatolij,

On Mon, Jan 13, 2020 at 12:53 PM Anatolij Gustschin <agust@denx.de> wrote:

> Does the kernel boot if you apply following U-Boot changes ?

Thanks for your suggestion.

With these changes I start to see some kernel output at least:

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd042]
[    0.000000] Linux version 5.4.11 (fabio at fabio-OptiPlex-7010) (gcc
version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #31 SMP PREEMPT
Mon Jan 13 11:19:04 -03 2020
[    0.000000] Machine model: Freescale i.MX8QXP MEK
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fe000000
[    0.000000] earlycon: lpuart32 at MMIO 0x000000005a060000 (options '')
[    0.000000] printk: bootconsole [lpuart32] enabled
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem
0x0000000080200000-0x00000008bfffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x8bf9fb800-0x8bf9fcfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000008bfffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000000923fffff]
[    0.000000]   node   0: [mem 0x0000000094400000-0x00000000ffffffff]
[    0.000000]   node   0: [mem 0x0000000880000000-0x00000008bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000008bfffffff]
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 22 pages/cpu s52952 r8192 d28968 u90112
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 765448
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: console=ttyLP0,${baudrate}
earlycon early_printk root=/dev/mmcblk1p2 rootwait rw
[    0.000000] Dentry cache hash table entries: 524288 (order: 10,
4194304 bytes, linear)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9,
2097152 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xfa000000-0xfe000000] (64MB)
[    0.000000] Memory: 2924312K/3110912K available (12220K kernel
code, 1862K rwdata, 6428K rodata, 5056K init, 450K bss, 153832K
reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[    0.000000]  Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GICv3: 512 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: no VLPI support, no direct LPI support
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000051b00000
[    0.000000] random: get_random_bytes called from
start_kernel+0x2b8/0x458 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 8.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
[    0.000005] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps
every 2199023255500ns
[    0.008404] Console: colour dummy device 80x25
[    0.012587] Calibrating delay loop (skipped), value calculated
using timer frequency.. 16.00 BogoMIPS (lpj=32000)
[    0.022760] pid_max: default: 32768 minimum: 301
[    0.027451] LSM: Security Framework initializing
[    0.032044] Mount-cache hash table entries: 8192 (order: 4, 65536
bytes, linear)
[    0.039365] Mountpoint-cache hash table entries: 8192 (order: 4,
65536 bytes, linear)
[    0.071266] ASID allocator initialised with 32768 entries
[    0.084363] rcu: Hierarchical SRCU implementation.
[    0.097852] EFI services will not be available.
[    0.110068] smp: Bringing up secondary CPUs ...
[    0.146720] Detected VIPT I-cache on CPU1
[    0.146753] GICv3: CPU1: found redistributor 1 region 0:0x0000000051b20000
[    0.146794] CPU1: Booted secondary processor 0x0000000001 [0x410fd042]
[    0.178767] Detected VIPT I-cache on CPU2
[    0.178790] GICv3: CPU2: found redistributor 2 region 0:0x0000000051b40000
[    0.178816] CPU2: Booted secondary processor 0x0000000002 [0x410fd042]
[    0.210832] Detected VIPT I-cache on CPU3
[    0.210852] GICv3: CPU3: found redistributor 3 region 0:0x0000000051b60000
[    0.210873] CPU3: Booted secondary processor 0x0000000003 [0x410fd042]
[    0.210946] smp: Brought up 1 node, 4 CPUs
[    0.266844] SMP: Total of 4 processors activated.
[    0.271529] CPU features: detected: 32-bit EL0 Support
[    0.276667] CPU features: detected: CRC32 instructions
[    0.287773] CPU: All CPU(s) started at EL2
[    0.291556] alternatives: patching kernel code
[    0.297159] devtmpfs: initialized
[    0.303755] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.313180] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.321296] pinctrl core: initialized pinctrl subsystem
[    0.327317] DMI not present or invalid.
[    0.331210] NET: Registered protocol family 16
[    0.336580] DMA: preallocated 256 KiB pool for atomic allocations
[    0.342353] audit: initializing netlink subsys (disabled)
[    0.347912] audit: type=2000 audit(0.292:1): state=initialized
audit_enabled=0 res=1
[    0.355774] cpuidle: using governor menu
[    0.359722] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.367445] Serial: AMBA PL011 UART driver
[    0.388890] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.395273] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.401954] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.408640] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.417405] cryptd: max_cpu_qlen set to 1000
[    0.425356] ACPI: Interpreter disabled.
[    0.430089] iommu: Default domain type: Translated
[    0.434841] vgaarb: loaded
[    0.437651] SCSI subsystem initialized
[    0.441494] usbcore: registered new interface driver usbfs
[    0.446839] usbcore: registered new interface driver hub
[    0.452010] usbcore: registered new device driver usb
[    0.457570] pps_core: LinuxPPS API ver. 1 registered
[    0.462201] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[    0.471334] PTP clock support registered
[    0.475343] EDAC MC: Ver: 3.0.0
[    0.479323] FPGA manager framework
[    0.482486] Advanced Linux Sound Architecture Driver Initialized.
[    0.489290] clocksource: Switched to clocksource arch_sys_counter
[    0.495244] VFS: Disk quotas dquot_6.6.0
[    0.499027] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.506026] pnp: PnP ACPI: disabled
[    0.515818] thermal_sys: Registered thermal governor 'step_wise'
[    0.515823] thermal_sys: Registered thermal governor 'power_allocator'
[    0.521753] NET: Registered protocol family 2
[    0.532755] tcp_listen_portaddr_hash hash table entries: 2048
(order: 3, 32768 bytes, linear)
[    0.541008] TCP established hash table entries: 32768 (order: 6,
262144 bytes, linear)
[    0.549137] TCP bind hash table entries: 32768 (order: 7, 524288
bytes, linear)
[    0.556626] TCP: Hash tables configured (established 32768 bind 32768)
[    0.562932] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.569585] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.576851] NET: Registered protocol family 1
[    0.581472] RPC: Registered named UNIX socket transport module.
[    0.587060] RPC: Registered udp transport module.
[    0.591749] RPC: Registered tcp transport module.
[    0.596440] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.602877] PCI: CLS 0 bytes, default 64
[    0.607602] hw perfevents: enabled with armv8_pmuv3 PMU driver, 7
counters available
[    0.615229] kvm [1]: IPA Size Limit: 40bits
[    0.619913] kvm [1]: GICv3: no GICV resource entry
[    0.624370] kvm [1]: disabling GICv2 emulation
[    0.628817] kvm [1]: GIC system register CPU interface enabled
[    0.634691] kvm [1]: vgic interrupt IRQ1
[    0.638656] kvm [1]: Hyp mode initialized successfully
[    0.651074] Initialise system trusted keyrings
[    0.655382] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[    0.669250] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.675594] NFS: Registering the id_resolver key type
[    0.680346] Key type id_resolver registered
[    0.684478] Key type id_legacy registered
[    0.688483] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.695354] 9p: Installing v9fs 9p2000 file system support
[    0.717745] Key type asymmetric registered
[    0.721514] Asymmetric key parser 'x509' registered
[    0.726400] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 245)
[    0.733756] io scheduler mq-deadline registered
[    0.738271] io scheduler kyber registered
[    0.750589] EINJ: ACPI disabled.
[    0.772083] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.780231] SuperH (H)SCI(F) driver initialized
[    0.784918] msm_serial: driver initialized
[    0.797448] loop: module loaded
[    0.804366] libphy: Fixed MDIO Bus: probed
[    0.808498] tun: Universal TUN/TAP device driver, 1.6
[    0.813967] thunder_xcv, ver 1.0
[    0.816884] thunder_bgx, ver 1.0
[    0.820117] nicpf, ver 1.0
[    0.823344] hclge is initializing
[    0.826323] hns3: Hisilicon Ethernet Network Driver for Hip08
Family - version
[    0.833528] hns3: Copyright (c) 2017 Huawei Corporation.
[    0.838888] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    0.844650] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.850597] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    0.857508] igb: Copyright (c) 2007-2014 Intel Corporation.
[    0.863106] igbvf: Intel(R) Gigabit Virtual Function Network Driver
- version 2.4.0-k
[    0.870884] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    0.877093] sky2: driver version 1.30
[    0.881069] VFIO - User Level meta-driver version: 0.3
[    0.887273] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.893481] ehci-pci: EHCI PCI platform driver
[    0.897959] ehci-platform: EHCI generic platform driver
[    0.903241] ehci-orion: EHCI orion driver
[    0.907198] ehci-exynos: EHCI EXYNOS driver
[    0.911350] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.917466] ohci-pci: OHCI PCI platform driver
[    0.921912] ohci-platform: OHCI generic platform driver
[    0.927177] ohci-exynos: OHCI EXYNOS driver
[    0.931691] usbcore: registered new interface driver usb-storage
[    0.940035] i2c /dev entries driver
[    0.948138] sdhci: Secure Digital Host Controller Interface driver
[    0.953997] sdhci: Copyright(c) Pierre Ossman
[    0.958695] Synopsys Designware Multimedia Card Interface Driver
[    0.965161] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.971959] ledtrig-cpu: registered to indicate activity on CPUs
[    0.978896] usbcore: registered new interface driver usbhid
[    0.984145] usbhid: USB HID core driver
[    0.991961] NET: Registered protocol family 17
[    0.996255] 9pnet: Installing 9P2000 support
[    1.000383] Key type dns_resolver registered
[    1.004995] registered taskstats version 1
[    1.008765] Loading compiled-in X.509 certificates
[    1.039475] imx-scu scu: NXP i.MX SCU Initialized
[    1.058681] imx8qxp-pinctrl scu:pinctrl: initialized IMX pinctrl driver
[    1.087023] 5a060000.serial: ttyLP0 at MMIO 0x5a060000 (irq = 7,
base_baud = 5000000) is a FSL_LPUAR

but then it hangs here when the serial driver is probed.

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Peng Fan]

> Subject: imx8qxp mek: Booting mainline kernel with mainline U-Boot
> 
> Hi Peng,
> 
> Have you managed to boot a mainline kernel with mainline U-Boot on a
> imx8qxp mek?

I have not try that. Aisheng has some Linux patches pending  which are
restructuring the Linux side SCU 8QXP/QM code, so I not put efforts
on booting mainline kernel.

Regards,
Peng.

> 
> Here is what I get:
> 
> U-Boot SPL 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300)
> Normal Boot
> WDT:   Not found!
> Trying to boot from MMC2_2
> Load image from MMC/SD 0x46800
> 
> 
> U-Boot 2020.01-00369-ge80a8b0222-dirty (Jan 13 2020 - 12:30:21 -0300)
> 
> CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz at 32C
> 
> Model: Freescale i.MX8QXP MEK
> Board: iMX8QXP MEK
> Build: SCFW 550f3079, SECO-FW d7523fe8, ATF 70fa7bc
> Boot:  SD1
> DRAM:  3 GiB
> Failed to enable ipg clk
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... OK
> In:    serial at 5a060000
> Out:   serial at 5a060000
> Err:   serial at 5a060000
> Net:   Failed to enable ipg clk
> 
> Warning: ethernet at 5b040000 (eth0) using random MAC address -
> e2:9c:db:94:fc:d5
> eth0: ethernet at 5b040000
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc1 is current device
> 26221056 bytes read in 1134 ms (22.1 MiB/s) Booting from mmc ...
> 13953 bytes read in 14 ms (972.7 KiB/s)
> ## Flattened Device Tree blob at 83000000
>    Booting using the fdt blob at 0x83000000
>    Using Device Tree in place at 0000000083000000, end
> 0000000083006680
> 
> Starting kernel ...
> [It hangs here]
> 
> Booting a NXP kernel also did not work.
> 
> Any ideas?
> 
> Regards,
> 
> Fabio Estevam

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Peng,

On Mon, Jan 13, 2020 at 9:46 PM Peng Fan <peng.fan@nxp.com> wrote:

> I have not try that. Aisheng has some Linux patches pending  which are
> restructuring the Linux side SCU 8QXP/QM code, so I not put efforts
> on booting mainline kernel.

Even NXP kernel failed booting for me.

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Peng,

On Mon, Jan 13, 2020 at 10:08 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peng,
>
> On Mon, Jan 13, 2020 at 9:46 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> > I have not try that. Aisheng has some Linux patches pending  which are
> > restructuring the Linux side SCU 8QXP/QM code, so I not put efforts
> > on booting mainline kernel.
>
> Even NXP kernel failed booting for me.

Are you able to boot NXP kernel with mainline U-Boot? If so, which version?

With Anatolij's suggestion I get the same hang (during LPUART driver
probe) in mainline as well as with NXP 4.19.35 kernel.

Please see the log:
http://code.bulix.org/fm8ye7-1088212

What needs to be fixed to allow mainline U-Boot to boot a kernel on imx8qxp mek?

Thanks

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Anatolij Gustschin]

Hi Fabio,

On Mon, 13 Jan 2020 13:03:10 -0300
Fabio Estevam festevam at gmail.com wrote:
...
> [    1.039475] imx-scu scu: NXP i.MX SCU Initialized
> [    1.058681] imx8qxp-pinctrl scu:pinctrl: initialized IMX pinctrl driver
> [    1.087023] 5a060000.serial: ttyLP0 at MMIO 0x5a060000 (irq = 7,
> base_baud = 5000000) is a FSL_LPUAR
> 
> but then it hangs here when the serial driver is probed.

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 cannot test NXP 4.19.35 kernel on this SoM yet, so not sure if it
would boot.

--
Anatolij

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Anatolij,

On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust@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]

Just wondering if anyone else managed to boot mainline U-Boot with
mainline kernel on i.MX8QXP.

If so, what firmware combination was used?

Thanks

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Anatolij Gustschin]

Hi Fabio,

On Thu, 16 Jan 2020 13:38:26 -0300
Fabio Estevam festevam at gmail.com wrote:

> Hi Anatolij,
> 
> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust@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.

then it might be due to scfw API incompatibility?

> [Adding Marcel]
> 
> Just wondering if anyone else managed to boot mainline U-Boot with
> mainline kernel on i.MX8QXP.

yesterday I wanted to test some mainline drivers on my SoM and
created simple device tree for booting with console output.
Mainline kernel v5.5-rc6 booted successfully, (but without FEC
support).

> If so, what firmware combination was used?

Unfortunately, my i.MX8QXP SoM was damaged today and it doesn't boot
any more and it is not recoverable, so I cannot check the used firmware
hashes. I only know that it was something from 4.14.98_2.0.0_ga release.

--
Anatolij

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Igor Opaniuk]

Hi Fabio,

On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Anatolij,
>
> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust@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.

>
> If so, what firmware combination was used?
>
> Thanks

Thanks

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Tom Rini]

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@gmail.com> wrote:
> >
> > Hi Anatolij,
> >
> > On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust@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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200116/8b529233/attachment.sig>

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Lokesh Vutla]

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@gmail.com> wrote:
>>>
>>> Hi Anatolij,
>>>
>>> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust@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:

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

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Fabio Estevam]

Hi Peng,

On Tue, Jan 14, 2020 at 4:01 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peng,
>
> On Mon, Jan 13, 2020 at 10:08 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi Peng,
> >
> > On Mon, Jan 13, 2020 at 9:46 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > I have not try that. Aisheng has some Linux patches pending  which are
> > > restructuring the Linux side SCU 8QXP/QM code, so I not put efforts
> > > on booting mainline kernel.
> >
> > Even NXP kernel failed booting for me.
>
> Are you able to boot NXP kernel with mainline U-Boot? If so, which version?
>
> With Anatolij's suggestion I get the same hang (during LPUART driver
> probe) in mainline as well as with NXP 4.19.35 kernel.
>
> Please see the log:
> http://code.bulix.org/fm8ye7-1088212
>
> What needs to be fixed to allow mainline U-Boot to boot a kernel on imx8qxp mek?

Any comments? It would be very helpful if mainline U-Boot could be
used to boot a kernel on i.MX8QXP MEK :-)

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Oliver Graute]

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

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Lokesh Vutla]

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
> 

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Peng Fan]

> Subject: Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
> 
> Hi Peng,
> 
> On Tue, Jan 14, 2020 at 4:01 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> >
> > Hi Peng,
> >
> > On Mon, Jan 13, 2020 at 10:08 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> > >
> > > Hi Peng,
> > >
> > > On Mon, Jan 13, 2020 at 9:46 PM Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > > I have not try that. Aisheng has some Linux patches pending  which
> > > > are restructuring the Linux side SCU 8QXP/QM code, so I not put
> > > > efforts on booting mainline kernel.
> > >
> > > Even NXP kernel failed booting for me.
> >
> > Are you able to boot NXP kernel with mainline U-Boot? If so, which version?
> >
> > With Anatolij's suggestion I get the same hang (during LPUART driver
> > probe) in mainline as well as with NXP 4.19.35 kernel.
> >
> > Please see the log:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.
> >
> bulix.org%2Ffm8ye7-1088212&amp;data=02%7C01%7Cpeng.fan%40nxp.com
> %7C910
> >
> c3515aae1450d63f808d79e98d353%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7
> >
> C0%7C637152251526688933&amp;sdata=XWgf95GO1nTaSjvOK8mnwOo1Vb
> 1%2Frd5EY2
> > qR8nzoXqA%3D&amp;reserved=0
> >
> > What needs to be fixed to allow mainline U-Boot to boot a kernel on
> imx8qxp mek?
> 
> Any comments? It would be very helpful if mainline U-Boot could be used to
> boot a kernel on i.MX8QXP MEK :-)

I have not tried that. I'll give a check when I back to office, might be two weeks
away.

Regards,
Peng.

imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Peng Fan]

> 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
> >

Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot

[vmuthusu]

Is there any update on this.
We are using a custom board based on IMX8QXP and trying to run u-boot
2020.04 with Linux kernel 5.10.9
and stuck with Starting Kernel message.

Thanks
V.Muthusubramanian



--
Sent from: http://u-boot.10912.n7.nabble.com/