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

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

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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

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

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

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

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
participants (3)
-
Kever Yang
-
Romain Perier
-
Simon Glass