Rockchip support

[macpijan]

Hi,

What it takes to add a new board to this project?

Has adding Rockchip been evaluated so far, if so, what's the outcome?

AFAIK, flashing Rockchips can be done via an open-source tool: https://github.com/rockchip-linux/rkdeveloptool which can make things a bit easier.

[rgantois]

Hello,

There has been an effort on our side to add Rockchip support to Snagrecover, but it has been postponed for various reasons related to time constraints.

I still haven't given up on implementing this but it won't happen in the near future, as currently my time is taken up with other features which have higher priority.

Here is my assessment of what it would take to add Rockchip support, in case you'd like to tackle the challenge yourself:

The goal of Snagrecover is to get U-Boot up and running in external RAM without touching any non-volatile memory devices. To achieve this, you must leverage the features of the ROM code USB recovery mode and various other bootloader stages to design a "recovery flow". This is essentially a list of USB commands and firmware executions that will eventually lead to U-Boot running in external RAM.

The various Rockchip boot options are described here: https://opensource.rock-chips.com/wiki_Boot_option

The general idea here would be to emulate the rkdeveloptool "db" command to copy a first bootloader stage to SRAM. This first stage should be capable of initializing the external RAM, then loading U-Boot Proper over the USB connection and launching it. I haven't yet settled on what that first stage should be. I've managed to get a U-Boot SPL banner to print using this method, but haven't gotten further than this.

There will be additional complications with arm64 SoCs, as you'll also have to run ATF and co.

Regarding the actual code to write in Snagrecover, you'll have to add a recovery flow for Rockchip SoCs in snagrecover/recoveries, a firmware parsing and running module in snagrecover/firmware, and low-level USB protocols in snagrecover/protocols. The best way to see how it's done is to look at existing code for other SoC families.

The important thing to keep in mind is that the recovery flow you design should not interact with any non-volatile memory device.

If you do decide to tackle this, feel free to ask me any relevant questions you might have. I'll do my best to answer them.

[apatard]

I've done some work for that. It possibly need some cleanup. My current test target is roc-rk3399-pc but my code is not really rk3399 specific. The current flow is:

1. boot u-boot TPL
2. boot u-boot SPL
3. load u-boot proper over SPL DFU

Once done, the system is running a full u-boot so snagflash can be used to flash the device at this point.
To do steps 1 and 2:

• either the files are merged into a bin file generated ATM with Radxa's boot_merger. I've not tested other versions, as I had this one at hand. I think I've read that some other versions of boot_merger may just crash.
• or provide the TPL and SPL binaries. The code will encrypt them to RC4 at run time

Notes:

• I may try to revisit the boot flow later
• I probably need to test on other rockchip device.
• the code may possibly need some cleaning/...

The URL are :

• https://github.com/apatard/u-boot/tree/rockchip-spl-dfu for SPL DFU support on RK3399
• https://github.com/apatard/snagboot/tree/rockchip for the snagrecovery support.

[obbardc]

@apatard you may be interested in these U-Boot series' from Radxa:

• https://patchwork.ozlabs.org/project/uboot/list/?series=443757
• https://patchwork.ozlabs.org/project/uboot/list/?series=443761
• https://patchwork.ozlabs.org/project/uboot/list/?series=443764

[apatard]

@obbardc thanks. Actually, Sjoerd mentioned them to me before you :)