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

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

[Romain Perier]

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 ?


Thanks,

Regards,

Romain

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

[Romain Perier]

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 ?
>
>
> Thanks,
>
> Regards,
>
> Romain
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Kever Yang]

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
>
>
>
>

[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

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

[Romain Perier]

Hi,

no ideas ?

I can try another solution if you want.

Regards,

Romain


Le 09/01/2017 ? 09:23, Romain Perier a ?crit :
> 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
>

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

[Simon Glass]

Hi,

On 19 January 2017 at 02:59, Romain Perier <romain.perier@collabora.com> wrote:
> Hi,
>
> no ideas ?
>
> I can try another solution if you want.
>
> Regards,
>
> Romain

I'm not sure - is it possible to add delays to make it work? That
might help with diagnosis.

Regards,
Simon

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

[Romain Perier]

Hi,


That's what I already tried, but I can re-try differently (the delays
were added at specific points, as suggested by Kever, if I remember
correctly. I could try different approach)


Thanks,

Romain


Le 26/01/2017 ? 15:24, Simon Glass a ?crit :
> Hi,
>
> On 19 January 2017 at 02:59, Romain Perier <romain.perier@collabora.com> wrote:
>> Hi,
>>
>> no ideas ?
>>
>> I can try another solution if you want.
>>
>> Regards,
>>
>> Romain
> I'm not sure - is it possible to add delays to make it work? That
> might help with diagnosis.
>
> Regards,
> Simon