[U-Boot] Rockchip RK3288 boot trouble

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

Hi Rick,

On 01/16/2017 10:50 AM, Simon Glass wrote:
> +Kever
>
> Hi Rick,
>
> On 15 January 2017 at 12:05, Rick Bronson <rick@efn.org> wrote:
>> Hi All,
>>
>>    I updated one of my two RK3288 boards (Viewsonic) with newer Android
>> factory firmware (using Windows) and now it won't boot mainline u-boot
>> when I use the same exact recipe that worked previously:
>>
>> sudo ${UPGD} db rkbin/rk32/rk3288_boot.bin
>> sudo ${UPGD} wl 0x40 tftpboot/u-boot-dtb.bin

I didn't see your detail steps for getting u-boot-dtb.bin, does it 
include SPL here?

We have two way to boot the RK3288 on upstream U-Boot SPL(pls reference to
doc/README.rockchip):
1. without "CONFIG_ROCKCHIP_SPL_BACK_TO_BROM", which is previous version,
To write an image that boots from an SD card (assumed to be /dev/sdc):

    ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
         firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
    sudo dd if=out of=/dev/sdc seek=64 && \
    sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=256
This puts the Rockchip header and SPL image first and then places the U-Boot
image at block 256.

2. with "CONFIG_ROCKCHIP_SPL_BACK_TO_BROM", which is default setting 
recently,
The rockchip bootrom can load and boot an initial spl, then continue to
load a second-level bootloader(ie. U-BOOT) as soon as it returns to bootrom.
Therefore RK3288 has another loading sequence like RK3036.
You can create the image via the following operations:

    ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
         firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
    cat firefly-rk3288/u-boot-dtb.bin >> out && \
    sudo dd if=out of=/dev/sdc seek=64

both way using upstream SPL + upstream u-boot.bin.
>>    Been trying to figure out what's wrong.  My theory is that the newer
>> firmware enabled one of the "boot areas" of the eMMC and the "wl 0x40"
>> command above only writes to the user area of the eMMC.
>>
>>    I can still load and run one of the Android u-boots using the
>> boot_merger method:
>>
>> ./tools/boot_merger --subfix ".10.bin" ./tools/rk_tools/RKBOOT/RK3288.ini

boot_merger is a tool from Rockchip, which create image for Rockchip 
bootrom,
you may need to modify RK3288.ini and keep everything else but replace the
FlashBoot with mainline U-Boot bin.
In this way, you are using Rockchip SPL(ddr init) and upstream U-Boot.

>>    then flashing via:
>>
>> sudo ${UPGD} ul u-boot-android/RK3288UbootLoader_V2.30.10.bin
>>
>>    But these u-boot's are virtually useless since they striped of
>> useful commands (like mmc commands).
>>
>>    I tried using the above boot_merger command on mainline u-boot but
>> it only boots this far (I've tried u-boot-dtb.bin and u-boot.bin):
>>
>> --------------------------
>> U-Boot 2016.11-08467-g05b8ba7-dirty (Jan 15 2017 - 10:40:37 -0800)
>>
>> Model: SCT36-RK3288
>> DRAM:  128 MiB
>> --------------------------
>>
>>    Note the incorrect DRAM size.

I'm confusing with this incorrect DRAM size, could you share the console 
output
during you flash the image, there should have correct DRAM size info.
I'm not sure if the DRAM on your board is symmetric or not,  or any else 
special.

If you are using the upstream SPL, could you pls enable the DEBUG option and
dump a log, we may able to see what happen on your board.

>>   My normal boot looks like:
>>
>> --------------------------
>> U-Boot SPL 2016.11-08467-g05b8ba7-dirty (Dec 18 2016 - 11:00:14)
>>
>> U-Boot 2016.11-08467-g05b8ba7-dirty (Dec 18 2016 - 11:00:14 -0800)
>>
>> Model: SCT36-RK3288
>> DRAM:  2 GiB
>> MMC:   dwmmc at ff0c0000: 0, dwmmc at ff0f0000: 1
>> ...
>> --------------------------
>>
>>    Note that this runs SPL, then normal u-boot whereas the previous one
>> didn't run SPL.

When you are using Rockchip SPL(DRAM INIT), there is no message with 'SPL',
but there do have some print about DRAM info, could you dump that message?

Thanks,
- Kever
>>
>>    Any ideas how I can get mainline u-boot running on this board?
> You might try a git bisect. We moved to auto-detected the RAM size
> recently, so perhaps that changed something?
>
> 7d6c78f rk3288: sdram: auto-detect the capacity
>
>>    Thanks much,
>>
>>    Rick
>>
>>
>>
> Regards,
> Simon
>
>
>