Mainline kernel 5.15 on Espressobin

[gtbX]

Hi!

I’ve been a user of an Espressobin for a few years now, first time posting. I have mine built into a NAS enclosure, using a 4-port SATA card in the mini PCIe slot to do RAID. It’s running Gentoo, with a (mostly) mainline kernel 5.4.156. This is working just fine, but that kernel is getting old, by Gentoo standards anyway ;P

I’ve tried building newer kernels – including actual mainline sources – my latest attempt was 5.15.16 – but each time I run into the same issue: the PCIe card isn’t being recognized. For example, I see this output in the boot log for the working kernel, which is absent in the non-working one:

[ 1.753820] advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges:
[ 1.760986] advk-pcie d0070000.pcie: MEM 0xe8000000..0xefefffff -> 0xe8000000
[ 1.768467] advk-pcie d0070000.pcie: IO 0xefff0000..0xefffffff -> 0xefff0000
[ 1.876008] advk-pcie d0070000.pcie: link up
[ 1.880475] advk-pcie d0070000.pcie: PCI host bridge to bus 0000:00

Aside from not being able to access the disks, the system will otherwise boot from SD card. I understand some things have changed in the kernel for Espressobin since 5.4, and there are new device trees available for newer Espressobin models, but I’m not sure how to get things working again. Perhaps there’s a config option I overlooked?

Thanks!

[pali]

Hello @gtbX! Could you please provide output from “lspci -nn -vv” command from working kernel and whole dmesg ouput from non-working kernel? I can look at PCIe issues. In recent kernels there are lot of fixes for pci-aardvark.c A3720 PCIe driver.

[gtbX]

I was directed to try the kernel defconfig here https://github.com/sarnold/arm64-multiplatform/tree/v5.16.x/patches, and it seems to have done the trick. Still don’t know what was wrong about my original config, but given the number of differences it’ll take a while to find it.

I would’ve replied sooner, but apparently attempting to paste terminal output in this forum flags you for a temporary ban?

[pali]

Check if you have enabled CONFIG_PCI_AARDVARK (=y or =m) and in case it is =m then check if you have loaded pci-aardvark.ko module. This is driver for PCIe controller.

Basically for Marvell Armada 3720 boards you need these options:
CONFIG_AHCI_MVEBU
CONFIG_ARCH_MVEBU
CONFIG_ARMADA_37XX_CLK
CONFIG_ARMADA_37XX_RWTM_MBOX
CONFIG_ARMADA_37XX_WATCHDOG
CONFIG_ARM_ARMADA_37XX_CPUFREQ
CONFIG_CRYPTO_DEV_SAFEXCEL
CONFIG_GPIO_MOXTET
CONFIG_I2C_PXA
CONFIG_MARVELL_PHY
CONFIG_MMC_SDHCI_XENON
CONFIG_MOXTET
CONFIG_MVMDIO
CONFIG_MVNETA
CONFIG_NET_DSA_MV88E6XXX
CONFIG_PCI_AARDVARK
CONFIG_PHY_MVEBU_A3700_COMPHY
CONFIG_PHY_MVEBU_A3700_UTMI
CONFIG_PINCTRL_ARMADA_37XX
CONFIG_SERIAL_MVEBU_CONSOLE
CONFIG_SERIAL_MVEBU_UART
CONFIG_SPI_ARMADA_3700
CONFIG_TURRIS_MOX_RWTM
CONFIG_USB_EHCI_HCD_ORION
CONFIG_USB_XHCI_MVEBU

So check that you have all of them enabled.

[gtbX]

Thanks. I went back to my original config, and checked each of those options. I think the issue was that I had CONFIG_PCI_AARDVARK=y, but CONFIG_PHY_MVEBU_A3700_COMPHY=m. According to the help for that option, it seems required to use PCIe, along with some other buses. It makes sense then that it couldn’t mount the rootfs if a module required for doing so was stored there. I changed it to ‘y’ and it’s able to boot again.

[Author]

Posts