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

[Jean Lucas]

On 11/19/20 12:45 AM, Jean Lucas wrote:
> 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

Ah, I spoke too soon regarding U-Boot flashed to eMMC with OHCI support 
resulting in working boot, and the boot hang only being when U-Boot with 
OHCI support is loaded purely from SPI.

The hang indeed also occurs as of v2021.01-rc2-67-ge800d715e0, even when 
loaded from eMMC.

Regards