Rockchip U-Boot notes

[mirrexagon]

• https://source.denx.de/u-boot/u-boot/-/commit/f6f9affdcea058bec6004895ab427a4ecda775b2
• https://source.denx.de/u-boot/u-boot/-/commit/dd397609fc45472d78894256e1effd6902a7c12d
• https://lists.denx.de/pipermail/u-boot/2020-June/414942.html
• https://lists.denx.de/pipermail/u-boot/2020-June/thread.html - search for "Drop to handle rkspi image type"
• https://github.com/NixOS/nixpkgs/pull/146725

[mirrexagon]

Tow-Boot sets some config items for SPI boot: https://github.com/Tow-Boot/Tow-Boot/blob/released/support/builders/rockchip-rk3399/default.nix#L76

Also explicitly sets CONFIG_SYS_SPI_U_BOOT_OFFS to 0x80000 and patches RK3399 U-Boot device trees to the same: https://github.com/Tow-Boot/Tow-Boot/blob/released/boards/pine64/0001-rockpro64-rk3399-Configure-SPI-flash-boot-offset.patch#L19

TODO: Find out why

[mirrexagon]

Various ways to set offset to U-Boot Proper in media where U-Boot resides:

• CONFIG_SYS_SPI_U_BOOT_OFFS
• CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - for ARCH_ROCKCHIP, defaults to 0x4000 sectors in common/spl/KConfig -> 16384 sectors
• CONFIG_SPL_PAD_TO: eg. include/configs/rockchip-common.h - Makefile uses this to pad u-boot-rockchip.bin
• /config/u-boot,spl-payload-offset U-Boot device tree node, eg. arch/arm/dts/rk3399-rockpro64-u-boot.dtsi

Device tree overrides config, doc/device-tree-bindings/config.txt:

u-boot,spl-payload-offset (int) If present (and SPL is controlled by the device-tree), this allows to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value from the device-tree.

[mirrexagon]

binman:

• https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
• arch/arm/dts/rockchip-u-boot.dtsi has a binman node, when is this used? Makefile has a note and TODO about ARM64 and using binman to generate u-boot-rockchip.bin

[mirrexagon]

There is a CONFIG_ROCKCHIP_SPI_IMAGE in U-Boot, but maybe only implemented for some boards: https://source.denx.de/u-boot/u-boot/-/commit/c4cea2bbf995764f325a907061c22ecd6768cf7b

[mirrexagon]

It seems like ideally we would:

• Modify binman to be able to call mkimage with two images separated by a colon, as required to make a most-correct combined SD/MMC or SPI image (for SD you can technically cat SPL onto a mkimaged TPL, but for SPI you can't. mkimage's rksd and rkspi formats will take the two colon-separated images and set the image header to be exact size. If you just mkimage TPL and cat on SPL, the header is added but it has the maximum size set for SPL, so the bootROM probably copies more than needed when loading SPL).
• Use that to get binman to produce the SD/MMC image, including mkimaging TPL and SPL in the right way (not needing idbloader.img anymore).
• Get binman to produce the SPI image in a very similar way.

Considerations and other notes:

• How to specify a custom TPL externally, to use proprietary RAM training?
• See what non-ARM64 does, it already uses binman to combine a built idbloader.img and u-boot.img. ARM64 needs u-boot.itb at the moment instead of u-boot.img. What's the difference? Is ATF part of it?

---

There is a note when building that this board uses CONFIG_SPL_FIT_GENERATOR and it should use binman instead. I think this is about building u-boot.itb, using BL31, etc. That is orthogonal to TPL+SPL, and could be a next step after all the TPL+SPL stuff using binman is working.

[mirrexagon]

Some info on INPUTS-y: https://lists.denx.de/pipermail/u-boot/2020-July/419536.html

[mirrexagon]

Commit showing use of binman to produce u-boot.itb: https://source.denx.de/u-boot/u-boot/-/commit/a32dd071485b17137b6d6088d26cee8011c5b9fc

• Introduced the !BINMAN check and implies that for now maybe we should just set HAS_ROM to get CONFIG_BINMAN set. But in my case, I'm trying to make ALL Rockchip targets use binman at least for final image generation. Is that too ambitious?

[mirrexagon]

The binman FIT entry type example in fit.py has a type = "rkspi" field. Do I use that instead of what I changed in the mkimage entry type (colon-separated data, passing type and name args)?

[mirrexagon]

Wat

The RK3328 boots rksd format images from SPI, not rkspi, from my testing. More investigation on what exactly the differences are are required - maybe the image header is actually different between them, not just the 2K block spreading thing.