英文:
Why is the VOP (Video Output Processor) on the Rockchip RK3588 acting inaccessible?
问题
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 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.
答案1
得分: 2
我解决了这个问题：问题在于尽管可能存在其他方法，但初始化需要U-Boot执行ARM Trusted Firmware流程。而我之前加载的MMC中包含错误的U-Boot镜像，因为编译生成了多个镜像，其中一个不包括ATF组件。特别是，您应该包括这些组件（即适用于Rockchip开发工具包的bl31包），然后使用u-boot.itb加载系统，而不是我之前一直在使用的u-boot.img。
在经过ATF流程后，VOP已准备就绪......尽管我现在遇到了一个不同的问题，但那是另一个问题了。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论