On Wed, Dec 16, 2020 at 4:15 PM Matthias Brugger matthias.bgg@gmail.com wrote:
Hi Dave,
On 16/12/2020 15:23, Dave Jones wrote:
Hi,
We've recently run across some failures with U-Boot on a couple of platforms, specifically the relatively new Pi Compute Module 4, and the Pi 4 8GB of RAM. On the CM4, U-Boot failed to identify the eMMC storage, and on the Pi 4 8GB, a crash and reset occurred when U-Boot tried to read from the boot file-system on the SD card, but only when booted with no monitor attached (attaching a monitor results in a successful boot, at least under arm64). These were with more-or-less stock rpi_4_defconfig and rpi_4_32b_defconfig configurations from v2020.10 (our local config changes bump the env-size, enable OF_BOARD, and RAW_INITRD, but that's it).
I've bisected the source and figured out roughly the commits responsible; for the CM4 eMMC case it's the enabling of DMA for the SDHCI interface in c6b9fbf756.
The Pi 4 8GB failure was a little more complex in that the bisection pointed to 3113c84ba2 (a merge), however that gave me a few clues to try and after a little experimenting I found that disabling CONFIG_PCI_BRCMSTB (effectively disabling the PCI driver for the platform) got things working happily again.
I'm happy to submit the local patches I'm adding to the Ubuntu build to work around these, but obviously those fixes are "brute force and ignorance" patches that just disable the relevant config; would such patches be wanted, or would the community prefer to figure out the root causes in each case? I'm happy to test any patches on the relevant hardware if anyone doesn't have access to the necessary boards.
Thanks for looking into this. I'm aware of problems booting CM4 and RPi 400 with PCI. I wasn't aware that RPi4 8GB problem was related to PCI as well. Would you mind to test this series, if this fixes your problems: https://patchwork.ozlabs.org/user/todo/uboot/?series=220661
That's your todo list so the link doesn't work for an anonymous consumer.