* imx8qxp mek: Booting mainline kernel with mainline U-Boot
@ 2020-01-13 15:36 Fabio Estevam
2020-01-13 15:53 ` Anatolij Gustschin
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Fabio Estevam @ 2020-01-13 15:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-13 15:36 imx8qxp mek: Booting mainline kernel with mainline U-Boot Fabio Estevam
@ 2020-01-13 15:53 ` Anatolij Gustschin
2020-01-13 16:03 ` Fabio Estevam
2020-01-14 0:46 ` Peng Fan
2021-06-12 12:51 ` vmuthusu
2 siblings, 1 reply; 18+ messages in thread
From: Anatolij Gustschin @ 2020-01-13 15:53 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-13 15:53 ` Anatolij Gustschin
@ 2020-01-13 16:03 ` Fabio Estevam
2020-01-14 23:04 ` Anatolij Gustschin
0 siblings, 1 reply; 18+ messages in thread
From: Fabio Estevam @ 2020-01-13 16:03 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-13 15:36 imx8qxp mek: Booting mainline kernel with mainline U-Boot Fabio Estevam
2020-01-13 15:53 ` Anatolij Gustschin
@ 2020-01-14 0:46 ` Peng Fan
2020-01-14 1:08 ` Fabio Estevam
2021-06-12 12:51 ` vmuthusu
2 siblings, 1 reply; 18+ messages in thread
From: Peng Fan @ 2020-01-14 0:46 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-14 0:46 ` Peng Fan
@ 2020-01-14 1:08 ` Fabio Estevam
2020-01-14 19:01 ` Fabio Estevam
0 siblings, 1 reply; 18+ messages in thread
From: Fabio Estevam @ 2020-01-14 1:08 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-14 1:08 ` Fabio Estevam
@ 2020-01-14 19:01 ` Fabio Estevam
2020-01-21 17:39 ` Fabio Estevam
0 siblings, 1 reply; 18+ messages in thread
From: Fabio Estevam @ 2020-01-14 19:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-13 16:03 ` Fabio Estevam
@ 2020-01-14 23:04 ` Anatolij Gustschin
2020-01-16 16:38 ` Fabio Estevam
0 siblings, 1 reply; 18+ messages in thread
From: Anatolij Gustschin @ 2020-01-14 23:04 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-14 23:04 ` Anatolij Gustschin
@ 2020-01-16 16:38 ` Fabio Estevam
2020-01-16 16:57 ` Anatolij Gustschin
2020-01-16 18:03 ` Igor Opaniuk
0 siblings, 2 replies; 18+ messages in thread
From: Fabio Estevam @ 2020-01-16 16:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-16 16:38 ` Fabio Estevam
@ 2020-01-16 16:57 ` Anatolij Gustschin
2020-01-16 18:03 ` Igor Opaniuk
1 sibling, 0 replies; 18+ messages in thread
From: Anatolij Gustschin @ 2020-01-16 16:57 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-16 16:38 ` Fabio Estevam
2020-01-16 16:57 ` Anatolij Gustschin
@ 2020-01-16 18:03 ` Igor Opaniuk
2020-01-16 18:16 ` Tom Rini
1 sibling, 1 reply; 18+ messages in thread
From: Igor Opaniuk @ 2020-01-16 18:03 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-16 18:03 ` Igor Opaniuk
@ 2020-01-16 18:16 ` Tom Rini
2020-01-17 6:07 ` Lokesh Vutla
0 siblings, 1 reply; 18+ messages in thread
From: Tom Rini @ 2020-01-16 18:16 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-16 18:16 ` Tom Rini
@ 2020-01-17 6:07 ` Lokesh Vutla
2020-01-23 13:53 ` Oliver Graute
0 siblings, 1 reply; 18+ messages in thread
From: Lokesh Vutla @ 2020-01-17 6:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-14 19:01 ` Fabio Estevam
@ 2020-01-21 17:39 ` Fabio Estevam
2020-01-27 13:11 ` Peng Fan
0 siblings, 1 reply; 18+ messages in thread
From: Fabio Estevam @ 2020-01-21 17:39 UTC (permalink / raw)
To: 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:
> 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 :-)
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-17 6:07 ` Lokesh Vutla
@ 2020-01-23 13:53 ` Oliver Graute
2020-01-23 14:07 ` Lokesh Vutla
0 siblings, 1 reply; 18+ messages in thread
From: Oliver Graute @ 2020-01-23 13:53 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-23 13:53 ` Oliver Graute
@ 2020-01-23 14:07 ` Lokesh Vutla
2020-01-27 13:13 ` Peng Fan
0 siblings, 1 reply; 18+ messages in thread
From: Lokesh Vutla @ 2020-01-23 14:07 UTC (permalink / raw)
To: 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 :)
> (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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-21 17:39 ` Fabio Estevam
@ 2020-01-27 13:11 ` Peng Fan
0 siblings, 0 replies; 18+ messages in thread
From: Peng Fan @ 2020-01-27 13:11 UTC (permalink / raw)
To: u-boot
> 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&data=02%7C01%7Cpeng.fan%40nxp.com
> %7C910
> >
> c3515aae1450d63f808d79e98d353%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7
> >
> C0%7C637152251526688933&sdata=XWgf95GO1nTaSjvOK8mnwOo1Vb
> 1%2Frd5EY2
> > qR8nzoXqA%3D&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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-23 14:07 ` Lokesh Vutla
@ 2020-01-27 13:13 ` Peng Fan
0 siblings, 0 replies; 18+ messages in thread
From: Peng Fan @ 2020-01-27 13:13 UTC (permalink / raw)
To: u-boot
> 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
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
2020-01-13 15:36 imx8qxp mek: Booting mainline kernel with mainline U-Boot Fabio Estevam
2020-01-13 15:53 ` Anatolij Gustschin
2020-01-14 0:46 ` Peng Fan
@ 2021-06-12 12:51 ` vmuthusu
2 siblings, 0 replies; 18+ messages in thread
From: vmuthusu @ 2021-06-12 12:51 UTC (permalink / raw)
To: u-boot
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/
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-06-12 23:58 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-13 15:36 imx8qxp mek: Booting mainline kernel with mainline U-Boot Fabio Estevam
2020-01-13 15:53 ` Anatolij Gustschin
2020-01-13 16:03 ` Fabio Estevam
2020-01-14 23:04 ` Anatolij Gustschin
2020-01-16 16:38 ` Fabio Estevam
2020-01-16 16:57 ` Anatolij Gustschin
2020-01-16 18:03 ` Igor Opaniuk
2020-01-16 18:16 ` Tom Rini
2020-01-17 6:07 ` Lokesh Vutla
2020-01-23 13:53 ` Oliver Graute
2020-01-23 14:07 ` Lokesh Vutla
2020-01-27 13:13 ` Peng Fan
2020-01-14 0:46 ` Peng Fan
2020-01-14 1:08 ` Fabio Estevam
2020-01-14 19:01 ` Fabio Estevam
2020-01-21 17:39 ` Fabio Estevam
2020-01-27 13:11 ` Peng Fan
2021-06-12 12:51 ` vmuthusu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.