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

[Jean Lucas]

On 11/17/20 1:28 PM, Jean Lucas wrote:
> 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.
> 

Hi,

Interestingly, disabling OHCI did the trick, and the Pinebook Pro and 
RockPro64 both boot normally. Unfortunately, Pinebook Pro's keyboard is 
connected to the mainboard via USB, and RockPro64 is USB-only as well, 
so OHCI support will have to be reviewed for these boards at least.

Interestingly, flashing the same U-Boot revision (except with OHCI 
enabled) to eMMC on Pinebook Pro - which results in SPL loading U-Boot 
from the eMMC by default, even when booted from SPI - results in working 
USB support. The boot hang only becomes an issue when U-Boot is loaded 
purely from SPI.

Regards,
Jean