[BUG] Hang shortly after loading FDT when booting on RK3399

[Jean Lucas]

On 11/17/20 9:42 AM, Alper Nebi Yasak wrote:
> On 17/11/2020 17:11, Peter Robinson wrote:
>> On Tue, Nov 17, 2020 at 12:43 PM Alper Nebi Yasak
>> <alpernebiyasak at gmail.com> wrote:
>>> On 17/11/2020 04:49, Jean Lucas wrote:
>>>> Hello all,
>>>>
>>>> On Pine64 RockPro64 and Pinebook Pro (both RK3399), flashing U-Boot
>>>> v2021.01-rc2-47-g9324c9a823 defconfig and mainline ATF
>>>> v2.4-rc0-2-gd01f31c03 to SPI flash of both devices results in a hang
>>>> shortly after loading the appropriate FDT when booting.
>>>>
>>>> On a Pinebook Pro:
>>>>
>>>> => load mmc 0:1 ${kernel_addr_r} Image
>>>> 32418304 bytes read in 1448 ms (21.4 MiB/s)
>>>> => load mmc 0:1 ${fdt_addr_r} dtbs/rockchip/rk3399-pinebook-pro.dtb
>>>> 80831 bytes read in 27 ms (2.9 MiB/s)
>>>> => load mmc 0:1 ${ramdisk_addr_r} initramfs-linux.img
>>>> 29698825 bytes read in 1291 ms (21.9 MiB/s)
>>>> => setenv bootargs console=ttyS2,1500000 console=tty0
>>>> root=/dev/ghost/root audit=0
>>>> => booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
>>>> Moving Image from 0x2080000 to 0x2200000, end=41c0000
>>>> ## Flattened Device Tree blob at 01f00000
>>>>      Booting using the
>>>>
>>>> Behavior is the same on RockPro64.
>>>>
>>>> Worth mentioning is that U-Boot from about a week ago (I think
>>>> rc2-4-gf36603c7a8) with same mainline ATF version written to eMMC
>>>> results in a working boot on Pinebook Pro, so bug seems to be when
>>>> booting from SPI.
>>>>
>>>> To further the hypothesis, on RockPro64, the latest U-Boot I can use
>>>> from SPI (defconfig) is release 2020.04, since later releases also hang
>>>> on loading the appropriate FDT when booting as described above.
>>>>
>>>> Any ideas as to what could be causing the hangs?
>>>>
>>> My gru-kevin was hanging at that same place when I tried to boot from
>>> USB, try running "usb stop" to see if that hangs. If so, try disabling
>>> CONFIG_USB_OHCI_HCD and CONFIG_USB_OHCI_GENERIC, which fixed the hang in
>>> my case.
>> Which probably breaks USB keyboards?
> I wouldn't know, gru-kevin uses cros-ec-keyb so I never needed to try a
> USB keyboard. I meant those as steps to narrow things down.

So, running "usb stop" resulted in a hang.

I will test a build with the OHCI options Alper mentioned disabled, this 
evening.

As far as testing goes, disabling USB is fine since I can access the 
machines over serial.