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

[Kever Yang <kever.yang@rock-chips.com>]

Hi Romain,

     Thanks for your report and debug.

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.

Thanks,
- Kever
>>
>> Thanks,
>>
>> Regards,
>>
>> Romain
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
>