U-Boot failures on CM4 and Pi4-8Gb

[Dave Jones]

Hi Matthias,

On Wed, Dec 16, 2020 at 05:21:50PM +0100, Matthias Brugger wrote:
>
>
>On 16/12/2020 17:20, Peter Robinson wrote:
>> On Wed, Dec 16, 2020 at 4:15 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
[snip]
>>>
>>> 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.
>>
>
>Right, sorry not my day today:
>https://patchwork.ozlabs.org/project/uboot/list/?series=220661

Thanks for the swift reply! I've tried this patch series on top of our 
v2020.10 build (excluding my hack to disable CONFIG_PCI_BRCMSTB) and 
unfortunately I get similar results to Peter:


     U-Boot 2020.10-dirty (Dec 16 2020 - 17:39:11 +0000)

     DRAM:  7.9 GiB
     RPI 4 Model B (0xd03114)
     MMC:   mmcnr at 7e300000: 1, emmc2 at 7e340000: 0
     Loading Environment from FAT... *** Warning - bad CRC, using default environment

     In:    serial
     Out:   serial
     Err:   serial
     Net:   eth0: ethernet at 7d580000
     PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
     starting USB...
     Bus xhci_pci: probe failed, error -110
     No working controllers found
     Hit any key to stop autoboot:  0
     switch to partitions #0, OK
     mmc0 is current device
     Scanning mmc 0:1...
     Found extlinux/extlinux.conf
     Invalid filesystem: 0x02400000
     SCRIPT FAILED: continuing...
     "Synchronous Abort" handler, esr 0x96000004
     elr: 00000000000dab8c lr : 000000000009257c (reloc)
     elr: 000000003b3b2b8c lr : 000000003b36a57c
     x0 : 0378696600000005 x1 : 000000003af4a5f0
     x2 : 00000000ffffffd5 x3 : 0000000000000000
     x4 : 0378696600000005 x5 : 0000000000000048
     x6 : 0000000000000021 x7 : 000000003afd6840
     x8 : 0000000000000001 x9 : 0000000000000008
     x10: 0000000000000002 x11: 000000003af46dd0
     x12: 0000000000000000 x13: 0000000000000200
     x14: 000000003af2bf30 x15: 0000000000000021
     x16: 000000003b38ad4c x17: 0000000000000007
     x18: 000000003af37d90 x19: 0000000000000000
     x20: 000000003af4a100 x21: 000000003af4a5f7
     x22: 000000003af4a5f0 x23: 0000000000000000
     x24: 000000003b3e5000 x25: 0000000000000000
     x26: 000000003af49b60 x27: 000000003af4a610
     x28: 000000003af49c00 x29: 000000003af2a7f0

     Code: 3900007f d65f03c0 aa0003e4 d2800003 (38636885)
     Resetting CPU ...

     resetting ...


However, when I tried the patch on top of master (a439136599), things 
worked perfectly:


     U-Boot 2021.01-rc3-00159-ga439136599-dirty (Dec 16 2020 - 20:00:16 
     +0000)

     DRAM:  7.9 GiB
     RPI 4 Model B (0xd03114)
     MMC:   mmcnr at 7e300000: 1, emmc2 at 7e340000: 0
     Loading Environment from FAT... *** Warning - bad CRC, using default environment

     In:    serial
     Out:   serial
     Err:   serial
     Net:   eth0: ethernet at 7d580000
     PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
     starting USB...
     Bus xhci_pci: probe failed, error -110
     No working controllers found
     Hit any key to stop autoboot:  0
     switch to partitions #0, OK
     mmc0 is current device
     Scanning mmc 0:1...
     Found U-Boot script /boot.scr
     2603 bytes read in 35 ms (72.3 KiB/s)
     ## Executing script at 02400000
     8340400 bytes read in 626 ms (12.7 MiB/s)
     Total of 1 halfword(s) were the same
     Decompressing kernel...
     Uncompressed size: 23824896 = 0x16B8A00
     29335440 bytes read in 2167 ms (12.9 MiB/s)
     Booting Ubuntu (with booti) from mmc 0:...
     ## Flattened Device Tree blob at 02600000
        Booting using the fdt blob at 0x2600000
        Using Device Tree in place at 0000000002600000, end 000000000260ee5b

     Starting kernel ...


Just to make certain it was the patch-set responsible for fixing things 
on master, I rebuilt without your patch-set and tried that. However, 
that also worked perfectly (same output as above) so I'm guessing some 
other commit was responsible?

I'm happy to do another bisect run to try and figure out what's fixing 
it if that would be helpful?

Still, given it looks like the next version may "just fix it" anyway 
(though I haven't tested CM4 / 400 on it yet) I'd be content with 
waiting for that to land upstream in Debian and just getting by with my 
hacky patches for now.

Thanks,

Dave