[U-Boot] rockchip: rk3288: Possible regression in sdram setup

[Romain Perier]

Hi,


Le 09/01/2017 à 08:20, Kever Yang a écrit :
>
> On 01/06/2017 06:52 PM, Romain Perier wrote:
>> Add Rockchip Engineers to Cc:
>>
>>
>> Le 06/01/2017 à 11:28, Romain Perier a écrit :
>>> Hello,
>>>
>>> I have a strange behaviour with the SPL on rk3288.
>>>
>>> When I build u-boot-rockchip master for the rock2 (rock2_defconfig), 
>>> I can easily start u-boot SPL and u-boot from an sdcard (the emmc 
>>> boot partition is erased so my board starts in maskrom mode by 
>>> default) without any issues.
>>>
>>>
>>> Now, I load uboot SPL and uboot over usb:
>>>
>>> - I power up the board
>>>
>>> - I generate an image for the bootrom:
>>>
>>> # tools/mkimage -n rk3288 -T rkimage -d spl/u-boot-spl-dtb.bin out
>>>
>>> - I uploaded this image via usb to the board
>>>
>>> # cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | 
>>> ../tools/rkflashtool/rkflashtool l
>>>
>>> I get no output from the SPL. I have investigated and found that it 
>>> is caused by sdram_rk3288.c: sdram_init(). More especially by the 
>>> function phy_pctrl_reset(). I enabled EARLY_UART and added 2 
>>> printascii() in this function. This functions hangs in the second 
>>> for loop. I hacked this function locally, I reduce the number of 
>>> iterations from 4 to 3 then I added 2 uart outputs to this function 
>>> and "OH!":   it works, I get the following output:
>>>
>>> pctrl_reset:for
>>> pctrl_reset:end for
>>> pctrl_reset:for
>>> pctrl_reset:end for
>>>
>>> U-Boot SPL 2016.11-08675-ga4ae4ddda3-dirty (Jan 06 2017 - 10:35:41)
>>>
>>>
>>>
>>> Now, if I remove my printascii() functions completly, it's no longer 
>>> working. Which suggests that it might have something to do with busy 
>>> wait delays... (I could be wrong)
>>>
>>> From the sdram setup point of view, I don't see a real difference 
>>> between an SPL loaded from sdcard and an SPL loaded via usb.
>>>
>>> Rockchip guys: Would you have an idea about the problem ?
>>>
>
> SPL load from sdcard/emmc and loaded via usb, one difference may be 
> cpu frequency.
>
> I agree that the udelay() may not correct, could you help to do:
> - delay 1 S or more with udelay(), then we can see if it's correct, I 
> don't know how the udelay is implement on rk3288,
>     if it's using ARM generic timer, then it's related to cpu frequency;
> - using rockchip_udelay() instead of udelay(), this interface is using 
> rktimer, it should be correct.

I have just tried both solutions, unfortunately, it did not help (same 
issues)

Thanks,
Romain