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