[Macchiato] EDKII grub boot fails with PCIe init

[Ard Biesheuvel]

On 12 March 2018 at 16:15, Frederik Lotter
<frederik.lotter at netronome.com> wrote:
> Hi,
> I am getting CPU stall warnings when booting up using the EFI route. I
> suspect the PCIe interface, as the stall warning sometimes contain the probe
> function. Other times is seems to get further than PCIe init, but still
> stall interrupt handling.
> Here are some facts around my observation:
>
> I have two sdcards for my Machiattobin board. They have identical kernels
> (4.16 rc5) with Ubuntu 16.04 rootfs. The one sdcard uses a uboot, DT and
> kernel boot. The second sdcard has EDKII, grub kernel boot. The EDKII build
> includes the device tree DTB (and DTS which I believe is unused) from the
> one used on the uboot sdcard.
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd081]
> [    0.000000] Linux version 4.16.0-rc5-mbcin-netronome-2-dirty
> (root at mcb1-cpt) (gcc version 5.4.0 20160609 (Ubuntu/Linaro
> 5.4.0-6ubuntu1~16.04.9)) #2 SMP PREEMPT Mon Mar 12 14:40:25 UTC 2018
> [    0.000000] Machine model: Marvell 8040 MACHIATOBin
> [    0.000000] efi: Getting EFI parameters from FDT:
> [    0.000000] efi: EFI v2.70 by EDK II
> [    0.000000] efi:  SMBIOS 3.0=0xbfd00000  ACPI 2.0=0xb6760000
> MEMATTR=0xb8973418  RNG=0xbffdbf98
> [    0.000000] random: fast init done
> [    0.000000] efi: seeding entropy pool
> :
>
> (I am using the latest EDKII master, the Marvell edk2-open-platform 17.10
> banch, with all the latest mv-ddr/ atf /etc....).
>
> The DT data appear there in die EFI boot, but the PCIe interface fails, and
> results (I believe) in the CPU stall warnings:
>
> [  717.453025] INFO: rcu_preempt self-detected stall on CPU
> :
> :
> [  717.589783]  armada8k_pcie_probe+0x140/0x240
> :
>
> Other times, the pcie gets further:
>
> [    3.312127] PCI: OF: host bridge /cp0/pcie at f2600000 ranges:
> [    3.317740] PCI: OF:    IO 0xf9000000..0xf900ffff -> 0xf9000000
> [    3.323692] PCI: OF:   MEM 0xc0000000..0xdfffffff -> 0xc0000000
> [    3.328915] random: crng init done
> [    4.326158] armada8k-pcie f2600000.pcie: phy link never came up
> [    4.332109] armada8k-pcie f2600000.pcie: Link not up after
> reconfiguration
> [    4.339056] armada8k-pcie f2600000.pcie: PCI host bridge to bus 0000:00


To be brutally honest, the armada8k-pcie driver is a piece of junk,
and you're much better off using the generic ECAM driver, which now
includes special handling for the missing root port on Synopsys IP.

It also allows you to have both MMIO32 and MMIO64 regions, which can
be useful with some PCIe cards with large BARs

Could you try

compatible = "marvell,armada8k-pcie-ecam";

in the DT node, please?

(Before you do that, please check whether UEFI recognizes your PCI
hardware using the 'pci' command in the shell)


> [    4.345705] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    4.351217] pci_bus 0000:00: root bus resource [io  0x0000-0xffff] (bus
> address [0xf9000000-0xf900ffff])
> [    4.360741] pci_bus 0000:00: root bus resource [mem
> 0xc0000000-0xdfffffff]
> [    4.367659] pci 0000:00:00.0: [11ab:0110] type 01 class 0x060400
> [    4.373708] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit]
> [    4.380562] pci 0000:00:00.0: supports D1 D2
> [    4.384853] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> [    4.390697] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]),
> reconfiguring
> [    4.398771] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> [    4.405427] pci 0000:00:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff
> 64bit]
> [    4.412776] pci 0000:00:00.0: PCI bridge to [bus 01]
> [    4.725111] pcieport 0000:00:00.0: Signaling PME with IRQ 56
> [    4.730842] pcieport 0000:00:00.0: AER enabled with IRQ 56
>
> but then CPUs are still stalled on some incoming IRQ
>
> [   87.352768]  dump_backtrace+0x0/0x150
> [   87.356445]  show_stack+0x14/0x20
> [   87.359773]  sched_show_task+0x14c/0x170
> [   87.363711]  dump_cpu_task+0x40/0x50
> [   87.367300]  rcu_dump_cpu_stacks+0x94/0xd8
> [   87.371412]  rcu_check_callbacks+0x7ac/0x980
> [   87.375700]  update_process_times+0x2c/0x58
> [   87.379900]  tick_sched_handle.isra.5+0x30/0x50
> [   87.384449]  tick_sched_timer+0x40/0x90
> [   87.388301]  __hrtimer_run_queues+0x124/0x198
> [   87.392676]  hrtimer_interrupt+0xe4/0x240
> [   87.396701]  arch_timer_handler_phys+0x30/0x40
> [   87.401163]  handle_percpu_devid_irq+0x78/0x130
> [   87.405712]  generic_handle_irq+0x24/0x38
> [   87.409738]  __handle_domain_irq+0x5c/0xb8
> [   87.413850]  gic_handle_irq+0x58/0xb0
> [   87.417526]  el1_irq+0xb0/0x128
> [   87.420678]  __do_softirq+0xb0/0x228
> [   87.424267]  irq_exit+0xbc/0xf0
> [   87.427421]  __handle_domain_irq+0x60/0xb8
> [   87.431533]  gic_handle_irq+0x58/0xb0
> [   87.435209]  el1_irq+0xb0/0x128
>
> Is anyone aware of any issue like this?
>
> Regards,
> Fred
>
>
> _______________________________________________
> Macchiato mailing list
> Macchiato at lists.einval.com
> https://lists.einval.com/cgi-bin/mailman/listinfo/macchiato