Rockchip Tools

0 views
Skip to first unread message

Elia Khensamphanh

unread,
Aug 3, 2024, 2:53:07 PM8/3/24
to wildhanitvers

My understanding is that the mkimage is only for the u-boot image. Though the error is specifically calling out rockchip-fixup.scr as an ERROR 127, which I can confirm does exist, and is in the correct directory.

On the other hand, github user @kidding9 seems to have created an armv8.mk patch that seems to be a good starting point (which seems to also be reusing R2S DTS file). When I have some free time, I will try applying this patch to OpenWrt to see what happens.

What problem am I trying to solve? Wi-Fi standards have developed and also WAN links are fast and reasonably priced these days. When it comes to throughput testing tools like iperf3 servers, 1 Gigabit Ethernet has become a bottleneck. A Wi-Fi 6E...

hello
can't boot with v.5.19 for R5S 4G -5.19/openwrt-rockchip-armv8-friendlyelec_nanopi-r5s-ext4-sysupgrade.img.gz. burn img in Windows and in Linux - just solid red light and nothing happens after. please help, what do I do wrong?

Tried to flash the image to eMMC using FriendlyArm's eFlasher tool. Device failed to boot and the eMMC wasn't detected after trying to reflash it with any of the OEM's images. Had to put the device in MaskROM mode to recover the device using RKDevTool.

Yeah, button was pressed. Solid Red LED with no activity. Can flash it through the terminal with FriendlyWRT already installed but it renders the device unserviacable after rebooting. This is with the new 4GB model.

@Andy-Voigt FriendlyWRT is FiriendlyArm's fork of OpenWRT. I have yet to dive into the the detail of the changes they've made. One thing I have noticed with their image is that Wireguard doesn't work- even after the kmod package is reinstalled.

All the latest Rockchip tools can be downloaded from their Github
GitHub rockchip-linux/toolsRockchip Develop tools. Contribute to rockchip-linux/tools development by creating an account on GitHub.

I have 4K@60hz working well on Android Pie on RK3399.
But Khadas source code is a bit old especially the kernel, u-boot, hardware/rockchip folders, it needs updating to improve 4K playback.
So I need to test it a bit further to improve it.
When using Kodi also make sure you enable frame-rate switching for smoother playback.

I do not understand how to install magisk manager.
video or photos to see the manipulation.
on v1.3 it was simple.
why netflix apk does not work then what is in v1.4.
edge v turns back on after 10 minutes, while I was it.
thank you fred21

Copy the boot.img to a USB drive and connect to the Khadas Edge or download it directly with a web browser(Lightning or Chrome) on the Khadas Edge.
!RUsGEIia!Y-4l1OJsrOh1-WlsVJJvuy670GzX7GSXVLwgFCEiDmc

Flash the patched_magisk.img either by PC AndroidTool v2.67 which is complicated or the new easy way I added on the Khadas Edge itself.
Go to About - Click 7 times on build info to enable Developer Options

However, I liked the interface of v1.4 more than this one.
How can I change the DPI to the one previously used in v1.4?
Is there a way to add 4K resolution to display settings? the maximum now is 1080P

I added a separate boot.img file for people to use with Magisk Manager.
After you patch it, Click 7 times on build Info in the About menu then use Developer Options - Flash Image then boot and choose your patched_boot.img and restart.
Here are some pictures

To change the DPI
Go to TvSettings - Device - More Settings to open the white Settings app.
Under Display Options there should be a menu to change the Size with a slider from left to right.
320DPI is required by a lot of Google AndroidTV apps and works better for compatibility.

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.

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.

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.

RockChip provides proprietary binary-only tools for signing code and burningeFUSEs. Code signing is handled either by rk_sign_tool (Linux) or Secure BootTool (Windows), eFUSE burning is done using eFUSE Tool. Since eFUSE Tool isWindows exclusive, I had to set up Windows box side-by-side my Linuxworkstation.

eFUSE Tool accepts only a signed binary as its input, from which it extracts thepublic key. The binary used here is the same binary we pass to rkdeveloptoolwhen flashing firmware to eMMC. I will call it loader from now on.

Signing with Secure Boot Tool produced binary with a correct header that eFUSETool understands. Note that even though eFUSE Tool cannot load binaries built byrk_sign_tool, rkdeveloptool works with them just fine.

RockChip always boots from SPI first, then eMMC, SD card, and finally MaskROM.There is no way to alter the boot order, so the only way to recover (get backinto MaskROM) from freezing boot is to prevent BootROM from loading bootloaderby shorting the eMMC clock to the ground.

It took me a few tries before I succeeded - I was touching a tiny resistorplaced right next to the test point, draining too much power, around 300 mA.This is very dangerous for the board. Luckily, my board survived. After a fewtries, I got it right, and eFUSE burning succeeded.

Note: work-in-progress. Please add more makers, references, update missing fields, etc. NO marketing talk. Table should be concise (ie. for TL;DR people), with notes and examples explained later in the page. Shall this table focus on particular SoCs? Group similar tier socs?

The RK3288 has had considerable adoption by google partners for use in Chromebooks. It has been around long enough that the rockchip linux community has had time to get both its boot process reverse-engineered (without needing proprietary tools), as well as get both u-boot and linux kernel mainline upstream support for all features. Towards the end of 2016 a chinese software libre developer working for Rockchip was permitted to release a gstreamer plugin and associated v4l2 kernel modifications sufficient to have an entirely libre video decode engine up and running.

The only down-side of the popularity of the RK3288 from the google "chrome" bandwagonning effect is the sheer overwhelming amount of crap that people come up with and post online, making it much harder to find useful information than it really should be. Actual useful resources such as how to boot the processor from scratch over its USB-OTG interface with an entirely libre toolchain, not requiring any proprietary crud at all or requiring any google-sponsored tools, processes or procedures (mandatory use of UEFI boot partitions for example), are completely drowned out by wordpress postings of yet another person's "recipe for installing insert OS of their choice". The best resource on the RK3288 is therefore the #linux-rockchip freenode channel, which is populated by technically well-informed individuals. The developer board of choice at the moment for the RK3288 is the Firefly.

Lastly it does have to be pointed out that Rockchip are not *actively* involved (with the exception of one employee), in supporting or endorsing cooperation, collaboration or any other form of active participation with the Software Libre Community. The only reason then why the RK3288 has such good support is down to its use in chromebooks (where google would clearly have required full legal copyright compliance as part of its use in products) combined with the active efforts of the Software Libre Community (including one Chinese citizen working for Rockchip) to mainline it.

The A20 is the pin-compatible upgrade of the A10. It is one of the Allwinner processors that has had significant (unfunded, independent) reverse-engineering effort put into it. Several other processors from Allwinner have been based around it (A13, A13s, etc). As it is a "kitchen-sink" style processor it includes GbE, SATA-II, can handle dual screen 1920x1080, and can address up to 2GB of RAM. For $4.50 including the PMIC it is extremely powerful for its price, and has the huge benefit of being around for long enough that the software toolchain is entirely libre. This *includes* the USB FEL mode which is incredibly easy to use as a means to boot (or recover) a system. The FEL mode loader has been part of sunxi-tools since at least 2012.

Booting from NAND works, but the boot ROM may be a bit picky about which NAND ICs are supported and which are not. More information can be found at the NAND page. A20 also supports booting from other media, such as SD cards, eMMC and SPI NOR flash.

Just like my microcontroller article, the parts I picked range from the well-worn horses that have pulled along products for the better part of this decade, to fresh-faced ICs with intriguing capabilities that you can keep up your sleeve.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages