On Tue, 2020-01-07 at 00:32 +0100, Olivier wrote: > Hello > > I do not know if the list is interested by RAID adapters on > rockchip-3399.It's my first report, please let me know if > i have to provide more outputs. > > My Goals, test some RAID adapters : > _ LSI 2208 (Today) > _ MEGARAID 9240 / 9260 (soon) > _ INTEL SRC16S (i do not remember (soon)) > > Platform : RockPro64 using u-boot-aarch64 firmware from snapshot/packages > (January 2020)(without dtb file on i > partition) > > F.Y.I. Without the RAID's adapter the machine is running well. > > *************************************** > Once adapter is plugged, Kernel Panic : > *************************************** > > U-Boot TPL 2019.10 (Jan 02 2020 - 15:53:24) > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2019.10 (Jan 02 2020 - 15:53:24 -0700) > Trying to boot from MMC2 > NOTICE: BL31: v2.1(debug):2.1 > NOTICE: BL31: Built : 15:10:01, Jan 2 2020 > INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in > EL3 > INFO: plat_rockchip_pmu_init(1596): pd status 3e > INFO: BL31: Initializing runtime services > WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing! > WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing! > WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing! > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x200000 > INFO: SPSR = 0x3c9 > > > U-Boot 2019.10 (Jan 02 2020 - 15:53:24 -0700) > > Model: Pine64 RockPro64 > DRAM: 3.9 GiB > MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In: serial@ff1a0000 > Out: serial@ff1a0000 > Err: serial@ff1a0000 > Model: Pine64 RockPro64 > rockchip_dnl_key_pressed: adc_channel_single_shot fail! > Net: eth0: ethernet@fe300000 > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0(part 0) is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Card did not respond to voltage select! > Scanning disk [email protected]... > Disk [email protected] not ready > Scanning disk [email protected]... > Found 3 disks > BootOrder not defined > EFI boot manager: Cannot load any image > 165151 bytes read in 45 ms (3.5 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > disks: sd0* > > > > > > > > OpenBSD/arm64 BOOTAA64 0.20 > boot> > booting sd0a:/bsd: 7595784+1478976+538544+847472 > [504619+109+946320+533467]=0xd371f0 > type 0x2 pa 0x200000 va 0x200000 pages 0x4000 attr 0x8 > type 0x7 pa 0x4200000 va 0x4200000 pages 0x3eec attr 0x8 > type 0x4 pa 0x80ec000 va 0x80ec000 pages 0x28 attr 0x8 > type 0x7 pa 0x8114000 va 0x8114000 pages 0xec18c attr 0x8 > type 0x2 pa 0xf42a0000 va 0xf42a0000 pages 0xb47 attr 0x8 > type 0x4 pa 0xf4de7000 va 0xf4de7000 pages 0x1 attr 0x8 > type 0x2 pa 0xf4de8000 va 0xf4de8000 pages 0x3 attr 0x8 > type 0x7 pa 0xf4deb000 va 0xf4deb000 pages 0x1 attr 0x8 > type 0x2 pa 0xf4dec000 va 0xf4dec000 pages 0x100 attr 0x8 > type 0x1 pa 0xf4eec000 va 0xf4eec000 pages 0x29 attr 0x8 > type 0x0 pa 0xf4f15000 va 0xf4f15000 pages 0x7 attr 0x8 > type 0x4 pa 0xf4f1c000 va 0xf4f1c000 pages 0x1 attr 0x8 > type 0x6 pa 0xf4f1d000 va 0x4979a7000 pages 0x1 attr 0x8000000000000008 > type 0x4 pa 0xf4f1e000 va 0xf4f1e000 pages 0x2 attr 0x8 > type 0x0 pa 0xf4f20000 va 0xf4f20000 pages 0x4 attr 0x8 > type 0x4 pa 0xf4f24000 va 0xf4f24000 pages 0x2 attr 0x8 > type 0x6 pa 0xf4f26000 va 0x4979b0000 pages 0x1 attr 0x8000000000000008 > type 0x2 pa 0xf4f27000 va 0xf4f27000 pages 0x3019 attr 0x8 > type 0x5 pa 0xf7f40000 va 0x49a9ca000 pages 0x10 attr 0x8000000000000008 > type 0x2 pa 0xf7f50000 va 0xf7f50000 pages 0xb0 attr 0x8 > [ using 1985488 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.6-current (GENERIC.MP) #413: Sat Jan 4 16:35:40 MST 2020 > [email protected]:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 4094132224 (3904MB) > avail mem = 3895042048 (3714MB) > mainbus0 at root: Pine64 RockPro64 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 512KB 64b/line 16-way L2 cache > efi0 at mainbus0: UEFI 2.8 > efi0: Das U-Boot rev 0x20191000 > apm0 at mainbus0 > psci0 at mainbus0: PSCI 1.1, SMCCC 1.1 > agintc0 at mainbus0 sec shift 3:3 nirq 288 nredist 6 ipi: 0, 1: > "interrupt-controller" > agintcmsi0 at agintc0 > syscon0 at mainbus0: "qos" > syscon1 at mainbus0: "qos" > syscon2 at mainbus0: "qos" > syscon3 at mainbus0: "qos" > syscon4 at mainbus0: "qos" > syscon5 at mainbus0: "qos" > syscon6 at mainbus0: "qos" > syscon7 at mainbus0: "qos" > syscon8 at mainbus0: "qos" > syscon9 at mainbus0: "qos" > syscon10 at mainbus0: "qos" > syscon11 at mainbus0: "qos" > syscon12 at mainbus0: "qos" > syscon13 at mainbus0: "qos" > syscon14 at mainbus0: "qos" > syscon15 at mainbus0: "qos" > syscon16 at mainbus0: "qos" > syscon17 at mainbus0: "qos" > syscon18 at mainbus0: "qos" > syscon19 at mainbus0: "qos" > syscon20 at mainbus0: "qos" > syscon21 at mainbus0: "qos" > syscon22 at mainbus0: "qos" > syscon23 at mainbus0: "qos" > syscon24 at mainbus0: "qos" > syscon25 at mainbus0: "power-management" > "power-controller" at syscon25 not configured > syscon26 at mainbus0: "syscon" > "io-domains" at syscon26 not configured > syscon27 at mainbus0: "syscon" > syscon28 at mainbus0: "syscon" > rkclock0 at mainbus0 > rkclock1 at mainbus0 > syscon29 at mainbus0: "syscon" > "io-domains" at syscon29 not configured > "usb2-phy" at syscon29 not configured > "usb2-phy" at syscon29 not configured > rkemmcphy0 at syscon29 > "pcie-phy" at syscon29 not configured > rkpinctrl0 at mainbus0: "pinctrl" > rkgpio0 at rkpinctrl0 > rkgpio1 at rkpinctrl0 > rkgpio2 at rkpinctrl0 > rkgpio3 at rkpinctrl0 > rkgpio4 at rkpinctrl0 > pwmreg0 at mainbus0 > "fit-images" at mainbus0 not configured > "pmu_a53" at mainbus0 not configured > "pmu_a72" at mainbus0 not configured > agtimer0 at mainbus0: tick rate 24000 KHz > "xin24m" at mainbus0 not configured > simplebus0 at mainbus0: "amba" > "dma-controller" at simplebus0 not configured > "dma-controller" at simplebus0 not configured > rkpcie0 at mainbus0 > pci0 at rkpcie0 > ppb0 at pci0 dev 0 function 0 "Rockchip RK3399 Root Complex" rev 0x00: msi > panic: uvm_fault failed: ffffff8000213870 > Stopped at panic+0x150: TID PID UID PRFLAGS PFLAGS > C > PU COMMAND > * 0 0 0 0x10000 0x200 0K swapper > db_enter() at panic+0x14c > panic() at $x.0+0x6c > $x.0() at ppb_alloc_resources+0xb4 > ppb_alloc_resources() at ppbattach+0x2c4 > ppbattach() at config_attach+0x220 > config_attach() at pci_probe_device+0x3f0 > pci_probe_device() at pci_enumerate_bus+0x11c > https://www.openbsd.org/ddb.html describes the minimum info required in bug > reports. Insufficient info makes it difficult to find and fix bugs. > > ddb{0}> trace > db_enter() at panic+0x14c > panic() at $x.0+0x6c > $x.0() at ppb_alloc_resources+0xb4 > ppb_alloc_resources() at ppbattach+0x2c4 > ppbattach() at config_attach+0x220 > config_attach() at pci_probe_device+0x3f0 > pci_probe_device() at pci_enumerate_bus+0x11c > pci_enumerate_bus() at config_attach+0x220 > config_attach() at rkpcie_attach+0x6e0 > rkpcie_attach() at config_attach+0x220 > config_attach() at mainbus_attach_node+0x2c4 > mainbus_attach_node() at mainbus_attach+0x298 > mainbus_attach() at config_attach+0x220 > config_attach() at cpu_configure+0x2c > cpu_configure() at main+0x308 > main() at $x.2+0x70 > > ddb{0}> show panic > uvm_fault failed: ffffff8000213870 > > Have a nice evening :) >
This is the panic I was referring to previously here: https://marc.info/?l=openbsd-arm&m=157426949805676&w=2 For reference: > Cards that don't work panic when first accessing the PCIe configuration > memory during boot. The reason for this is unknown and appears to be an > issue with Linux as well: https://github.com/rockchip-linux/kernel/issues/116 > Some cards can be made to work by adding an arbitrary delay into the > rkpci driver after link training but this is a hack without a root > cause known so it is unlikely to be committed. > > The current driver does not support cards that have PCI bridge's on > them as well. Regards, -Kurt
