I have for a while had a device - the Firefly ITX-3588J - that uses this chip that I've been trying to turn into a kind of low-grade but still usable, ARM desktop system. More specifically, I've been trying to play around with incorporating the Rockchip-provided DRM drivers, e.g.
https://github.com/rockchip-linux/u-boot/
for video in the bootloader, U-Boot, in the newest versions of that bootloader which have a fair bit of mainstream support now for the chip, because especially their UEFI implementation looks to be much more comprehensive than that one which is a long-standing derivative of a 2017 U-Boot release.
Yet, when I then go to fire it up, the board/chip always seems to crash hard whenever it tries to access the VOP2 - in particular, testing reveals that address 0xfdd90000 and onward (the whole VOP2 memory-mapped register stack, at least) cannot be accessed - at least if it is accessed from the U-Boot primary; it does seem accessible from U-Boot SPL. This isn't just a problem with the specific Rockchip driver code; even without it, simply trying to access the address by an ad hoc read fails the same way, and depending on how far into the boot I try to do that access, it either just hangs there, or else it gives a "Synchronous Abort" with an ESR of 0x96000010.
Is there something that needs to be done to initialize the VOP2 to make it run, that mainstream U-Boot does not do?
I've tried to message some of the people on the U-Boot development team too by email, to no avail.
I solved it: the problem was that - though another way may exist - the initialization requires U-Boot to do a walk through the ARM Trusted Firmware process. And I had been loading the MMC with the wrong U-Boot image, as the compile generates several, and that one did not include the ATF components. In particular, you should include those (that is, a suitable bl31 package, such as the one obtainable from the Rockchip dev tools kits), then load the system with u-boot.itb, and not u-boot.img as I had been doing.
After it walks through ATF, the VOP is ready to rumble ... though I now have a different problem with it, but that's for another question.