Assembly restart. Software work. And maybe our next SoC?


if it works great it will be a nice bonus to the project, hopefully performance is good on panfrost vs proprietary driver.
Hopefully. I really don't understand 3D. I'm just giving random articles from the internet:
 
Even using the subset of RK3568 functions included in the functionality of the current CPU board, the change of performance and power should be noticeable.

OMAP5432RK3568
28 nm22 nm
2 A15 cores @ 1,5GHz (thanks, @TrashyMG)4 A55 cores @ 2GHz
2MB? 1MB? cache512 MB cache ? (less? RAM is faster but 4 cores demand more than 2?)
DDR3 532 MHz (1067 MT/s?)LPDDR4-1600 (3200 MT/s?)
2x POWERVR SGX544 (no free driver)2 Mali G52 820 MHz (32 shaders , 54,4 GFLOPS (GPU))
(free driver, I think)
The advertized speed and RK3566 implementations we've seen are at 1.8GHz. Again the A15 is a three-issue Out of Order performance core, while the A55 is a two-issue In Order efficiency core. That only represents a 20% clock advantage for the A55.

Please note the issue width refers to how many instructions a CPU can theoretically handle at one time, and a Out of Order is designed to significantly reduce the amount of time the CPU is waiting on RAM. This should be a side grade on the CPU side.

If you prefer benchmarks, Geekbench 4...
RK3568 single core 875

Tegra 4 Cortex A15@1.8GHz single core 877

Please note for normal dynamic recompiler emulation purposes, single core is the limiting factor. Also mind there is a concern that the synthetics in question here may be setup in a way that reduces the apparent value of Out of Order execution versus real code.

So once again this is a side grade where some loads will be better and some worse on the CPU side. Outside of edge case scenarios the distinction would lie with the RK3568 being more efficient in hitting that target, being more modern, having better support associated with Mali, and supporting newer APIs. In addition to the Linux community otherwise having good support for the SoC given the precedent of JELOS for the Anbernic RG353P and associated.

That said given Dragonbox is currently 6 years behind schedule in delivering orders I can see having some concern that developing a new CPU board would only result in further excessive delays. That said the person/people who would develop the CPU board aren't a limiting factor on current production, so unless Dragonbox halts production efforts to wait on said CPU board to finish development it shouldn't effect anything to pursue that and the design was intentionally setup so said modules could be swapped.
 
Last edited:
The advertized speed and RK3566 implementations we've seen are at 1.8GHz. Again the A15 is a three-issue Out of Order performance core, while the A55 is a two-issue In Order efficiency core. That only represents a 20% clock advantage for the A55.

Please note the issue width refers to how many instructions a CPU can theoretically handle at one time, and a Out of Order is designed to significantly reduce the amount of time the CPU is waiting on RAM. This should be a side grade on the CPU side.
The RK3566 also supports much faster RAM. I'm not sure of the value of an out-of-order architecture on ARM chips. I don't know the stats for new chips but I remember on an ARM2 every instruction took 1 clock tick to execute apart from MUL (multiply) and LDM/SDM (Load/Store multiple registers to a stack); perhaps a STM could be decomposed to it's multiple memory write instructions and those could be easily integrated into the instructions that follow and even run at the same time if that instruction only works on registers as long as they ready before the register in question is reused. That could be a small win, but other than that I'm not really sure of the value. But I suspect the bigger win with this new rockchip chip is it's designed for phones and SBCs and not strapped to a massive metal chassis in a car.
 
The RK3566 also supports much faster RAM. I'm not sure of the value of an out-of-order architecture on ARM chips.
With all due respect from where I'm standing these two sentences are contradictory.
  • If you're trying to argue that the CPU doesn't need to stall to circle back to RAM then 'faster RAM' would be irrelevant in this context.
  • If you're acknowledging that the CPU does need to stall to circle back to RAM, then you should be acknowledging the value of Out of Order in mitigating the impact of those issues.
The correct answer is those kinds of issues are for all practical intents and purposes are _the_ problem for the front-end of a CPU, which is why all ARM performance cores are Out of Order execution and only the efficiency cores do In Order execution associated with minimizing the number of transistors that _have_ to be active when handling relatively undemanding code.

Please remember the registers and execution units do their thing after the front end, and how many clocks an ALU takes to complete an instruction has nothing to do with the CPU's characteristics associated with having to stall and wait on RAM or mitigate needing to do so. Something which also speaks to the practical utility of the Cortex A15 being three-issue versus the A55 being only two-issue.

Bottomline without making things excessively technical is the RK3568 represents a side grade for the CPU, and the distinction otherwise is liable to be felt more in battery life than anything else.
 
Last edited:
Yes, any instruction that reads or writes to non-cached memory has to wait until that resource has ticked round, no matter how many ticks of the clock that instruction is listed as. Which is why higher clocked RAM is better, at least for writing to the framebuffer and other things too big to fit in the cache.

But hopefully we can agree that better battery life is a big win for Pyra users.
 
battery life is a primary consideration hence the giant battery. it's less about the CPU and more about the battery and also leveraging low power modes which iiuc we've hardly scratched.
 
From my experience with the PinePhone Pro, I think the Panfrost driver needs a bit of bug fixing, but a larger community of users and hobby devs should help with that. :)
 
Bottomline without making things excessively technical is the RK3568 represents a side grade for the CPU, and the distinction otherwise is liable to be felt more in battery life than anything else.
I'm not sure I follow you well enough and I don't want to dive so deep into technical issues that you probably know better than me.
I get the idea you value a lot single core performance. You talked of emulation. I don't intend to use emulation much. I'm more interested in text reading, office stuff, mail, web browsing, a little music, the odd video...
In the rough understanding I'm able to bring myself to here and now, 2 cores 3 stages deep means there're always (except stalls or interprocess sync etc) 6 instructions in execution. 4 cores 2 stages deep means there're always 8 instructions in execution (except the same).
So yes, with single core loads you have 3 instructions executing instead of 2, but with (for me) more realistic loads you have up to 6 instead of up to 8.
Yes, any instruction that reads or writes to non-cached memory has to wait until that resource has ticked round, no matter how many ticks of the clock that instruction is listed as. Which is why higher clocked RAM is better, at least for writing to the framebuffer and other things too big to fit in the cache.

But hopefully we can agree that better battery life is a big win for Pyra users.
Yes, faster RAM doesn't mean fewer stalls, it means shorter stalls. But faster RAM may also mean more power spent in RAM (not necessarily). I mean it's very likely quite a lot less power spent with the new CPU board for the same task. But not for the same time, since you'll be able to do more tasks in that time. So whether it translates to more battery time depends on how well you manage to not do more tasks in the same time, so how well you sleep or turn down silly desktop animations or whatever. Games or videos may use the speed for better quality instead of more battery time, etc.
From my experience with the PinePhone Pro, I think the Panfrost driver needs a bit of bug fixing, but a larger community of users and hobby devs should help with that.
I'm curious for your experience. Do you get hangs ? image corruption? software refusing to use hardware acceleration ? low performance? compared with the Mali blob? And is you Panfrost and stack new or old ? Did you have time to upgrade a few times ? Is it getting better or worse ? The Bifrost in the RK3568 should be newer than the one in RK3399 (the PPP has a RK3399, right?), but I'm not sure which is better supported by Panfrost.

There's also video decoding, but that's not about Panfrost. And I don't know whether RK3568 and RK3399 have the same decoding hardware or how is the support in free software for either.

And yes, my impression is that converging communities in fewer SOCs or SOC families may help get better support. Official support is not usually very long lived. If at least it was abandoned but free... (this years there's anecdotal improvement there maybe). But community support is increasingly resource starved (or maybe it's just my pessimism?). Yet I read today that they're still improving support in Lima (the free driver for older Mali) for hardware like 15 years old. That's something.
 
I get the idea you value a lot single core performance. You talked of emulation. I don't intend to use emulation much. I'm more interested in text reading, office stuff, mail, web browsing, a little music, the odd video...
In the rough understanding I'm able to bring myself to here and now, 2 cores 3 stages deep means there're always (except stalls or interprocess sync etc) 6 instructions in execution. 4 cores 2 stages deep means there're always 8 instructions in execution (except the same).
So yes, with single core loads you have 3 instructions executing instead of 2, but with (for me) more realistic loads you have up to 6 instead of up to 8..
I think you're in danger of mixing up pipeline depth and decode width there, but then I don't really understand decode width myself, and I think I specifically don't understand why you'd want it to be more than 1 when we;re doing everything strictly in order anyway. But yes, modern web browsers and video decoders are very good at exploiting multiprocessor hardware these days.
 
I'm curious for your experience. Do you get hangs ? image corruption? software refusing to use hardware acceleration ? low performance? compared with the Mali blob? And is you Panfrost and stack new or old ? Did you have time to upgrade a few times ? Is it getting better or worse ? The Bifrost in the RK3568 should be newer than the one in RK3399 (the PPP has a RK3399, right?), but I'm not sure which is better supported by Panfrost.

There's also video decoding, but that's not about Panfrost. And I don't know whether RK3568 and RK3399 have the same decoding hardware or how is the support in free software for either.

And yes, my impression is that converging communities in fewer SOCs or SOC families may help get better support. Official support is not usually very long lived. If at least it was abandoned but free... (this years there's anecdotal improvement there maybe). But community support is increasingly resource starved (or maybe it's just my pessimism?). Yet I read today that they're still improving support in Lima (the free driver for older Mali) for hardware like 15 years old. That's something.
Lots of questions to answer here.

> Do you get hangs?

The most notable hang is triggered by Waydroid. Waydroid currently ships LineageOS 17.1, which has a really old version of Mesa. This old version of Mesa has some mismatch between it and the kernel driver causing it to go into a hard lockup. The system keeps running but the display remains frozen until you reset the GPU by rebooting. Even a Mesa mismatch shouldn't crash the GPU, so more work is needed there. Other than that one there really hasn't been any pure hangs.

> Image corruption?

So far it's only been that with an external 3440x1440 display (DP altmode on the type C connector) I get corruption outside of the leftmost 2560x1440 area. I haven't traced it back to the Panfrost driver so it could also be a bug in Phoc (the compositing window manager for Phosh).

> Software refusing to use hardware acceleration?

Well, I run Mobian on it and since it's running Phosh I think everything runs through OpenGL ES, which is fully supported. Haven't tried anything but simple games on it though.

> Low performance?

I wouldn't say that. There's currently a refresh rate bug on the PinePhone Pro which makes things run at 53 Hz on the panel so there are some subtle stutters, but the hardware is perfectly capable of running even full desktop applications. Waking up from sleep can take a while sometimes with the display sometimes flashing once for each attempt, but I'm not sure if it's the GPU or some other underlying SoC quirk.

> Compared with the Mali blob?

I wouldn't know, I haven't even considered trying the proprietary blob.

> Is your Panfrost and stack new or old?

Aside from the kernel (which is 5.17 with Mobian patches and one of my own to fix an audio bug) the entire graphics stack is from Debian Sid.

> Did you have time to upgrade a few times?

I've only used it briefly on the 5.16 kernel from Mobian before I upgraded to 5.17, most issues I'm concerned with isn't graphics related. Mesa has seen some minor releases but since I haven't done that much graphically advanced with it I'm note sure I would immediately notice.

> Is it getting better or worse?

So far pretty static from my point of view since I've almost only used kernel 5.17 on it, but I'm sure a lot is happening behind the scenes in the Panfrost driver right now.

All in all I think in an application like the Pyra where it's used mainly for native code and newly compiled emulators, and powered off instead of put to sleep, it could do fine as-is. But if we want to put it to sleep or run stuff from old containers we're going to see confused users. Knowing the Pyra is a niche device to begin with I think we will find more edge cases fairly quickly. It should be pointed out though that even if you're not a dev yourself it helps a lot to just find the bugs so the devs know they have something to fix.
 
One of the important improvements to the Pyra as is would be to reduce power draw and heat generation when the system is idle, and to allow the system to enter various sleep power modes to save power when you're not using it on purpose. I can't say yet what this new CPU proposed would do to that situation, but as is the ability to be able to put the system to sleep or suspend would be greatly appreciated by a few users I think. Also, don't forget that the Pyra is designed also to be able to run any software provided by ARM Debian, which isn't optimised especially well and certainly isn't tweaked for our usage, so the best plan is to use it for various terminal utils and graphical apps up to libreoffice or maybe inkscape, so perhaps there won't be much GPU usage by those apps.
 
Just to be clear, the GPU in my PPP hasn't had any issue running regular applications from the Debian repos. It's the phone oriented stuff (and throwing old versions of Mesa into the mix through Waydroid) that causes issues.

Edit: I should also mention the PinePhone (non-Pro) had a lot more issues with the Lima driver when it was new than the PinePhone Pro does now. These Linux phones really kickstarted a huge wave of bug fixes..
 
The Rk3399 is years old, so it uses more power. It's the old flagship from Rockchip. The new one is the RK3588.
I've done some work on the RK3399 and I wouldn't really recommend it. It's just ok and is not the easiest chip to work with due to the shortcuts made by RK in the base BSP. Granted I was working on an Android device using it. I can definitely say that once you can grab their interest, they are quite an easy company to work with from an engineering perspective once you can get your foot in the door. Most SOC vendors I've worked with are much much worse.

If the form factor fits and the price point can be made to work, the RK3588 is a significantly better option for the Pyra. First off, the RK3588 is built on an 8nm process whereas the RK3568 is a 22nm process, so massive TDP improvements can be anticipated here. Secondly, the RK3588's A76 cores support out-of-order execution, whereas the A55 cores don't (the RK3568 only has A55's). This will provide massive performance benefits for general purpose tasks like web browsing and is a standard feature for high performance cores in big.LITTLE. For me, this is a crucial consideration for this kind of device. For reference, the Pyra's current A15 cores support out-of-order execution. Of course, whether the RK3588 is a viable option will depend on chip sourcing (more challenging because its new), price point (big delta here), and form factor (there is almost zero wiggle room unless things have changed since I've been gone so options are limited).

Also, when considering performance comparisons to something like the RPi, make sure to factor in the hundreds->thousands of hours of software development done to get it there. As a small, community-driven project we don't have the same resources as the Pi Foundation to throw at a platform to maximize performance, so the comparison based on raw hardware power is not one-to-one. Userspace improvements like UI improvements and helpful features are not a challenge for something community-driven, but early boot and kernel improvements are more challenging due to less fish in the sea able to help. TLDR our performance for a platform will always be less than a similar platform which has been provided with higher levels of optimization.

Also, hello again! Sorry I've been off the map. I haven't been able to contribute to the project at all recently due to increased responsibilities at work limiting my free time, including the extra space my brain has for more work like this. I'm hoping I can continue to provide support to this project in some way moving forward, even if its not as much as I would like to :). Given that I have some prior experience with the RK chipsets, I could hopefully help here.
 
@Djhg2000 I have the pp (non pro).
Does the new soc make a huge difference?
Is the emmc faster?
I was thinking to upgrade but for me the pp is more a toy than anything else.
I am currently not brave enough to daliy drive it. It would daily drive me crazy ;)
Did they fix the hardware bugs (screen flickering is anoying)?
How about the camera, does the sensor take usable images (besides from megapixels not working at the moment)?
Does the speakers work correctly?
 
Yes it will be not the fastest PS2 Emulation but with AetherSX2 Alpha..there exist a Video with RK3568 and PS2 on Youtube.
It is possible and maybe when Aether SX2 will be more optimized in the Future and maybe Framedropping..
..it should work good enough for most beautyfull turn based RPGs like Ar Tonelico or Atelier Iris 1-3.

For comparison, here's the RK3588. We would probably need to run Android for best performance here (OpenGL/Vulkan libraries will be better optimized, as well as the emulators themselves). Of course heat is going to be a challenge with either SOC.
 
Some more thoughts about that:

The OMAP5432 can get really warm, as we already know. Sadly, we don't know the TDP value (which basically says how hot it gets).
The RK3568 is the SoC used in the Anbernic RG503. It doesn't have ANY cooling. Not even a small heatpad. It just sits on the board, directly on top of the battery.
So we can assume that the RK3568 doesn't run hot. It might not be a huge speed increase compared to the OMAP5432, but it's a lot more efficient and cooler, which is a huge step forward.

Now, the RK3588 is not widely used yet. I don't know anything about the Linux Support or how hot it runs, but I still want to take it into consideration.

About the price:
The RK3568 currently is about 25 EUR.
The OMAP5432 is about 50 EUR.
The RK3588 is about 120 EUR.

Of course, that might all change if the global parts shortage ends at some time (and it looks like it 's getting better end of 2022 already).

The RK3568 has a TDP of 5W, the RK3588 6W.
We don't know about the OMAP5, but the OMAP3 used in the Pandora was 0.68W :)

So it needs a bit of testing, but seeing the RK3568 being used without any heatsink at all in a commercially available device, running Linux as well is a good sign.
 
FWIW. I've found in a website I didn't know, so I can't assess how trustworthy the source is, that RK3399K TDP is 7W, RK3399Pro is 5W and RK3399S (the one used in PinePhone Pro) is also 5W.
Edit: the Allwinner A64 in the original Pinephone would be 4W TDP I'm not sure what to make of those numbers, just trying to compare with devices that don't have much room for ventilation.
 
Last edited:
Also:
OMAP5432: 17x17mm (thanks, @ToastBucket)
RK3568: 19x19 mm
RK3588: 23x23 mm balls 0.65 mm apart
 
Last edited:
Some more thoughts about that:

The OMAP5432 can get really warm, as we already know. Sadly, we don't know the TDP value (which basically says how hot it gets).
The RK3568 is the SoC used in the Anbernic RG503. It doesn't have ANY cooling. Not even a small heatpad. It just sits on the board, directly on top of the battery.
So we can assume that the RK3568 doesn't run hot. It might not be a huge speed increase compared to the OMAP5432, but it's a lot more efficient and cooler, which is a huge step forward.

Now, the RK3588 is not widely used yet. I don't know anything about the Linux Support or how hot it runs, but I still want to take it into consideration.

About the price:
The RK3568 currently is about 25 EUR.
The OMAP5432 is about 50 EUR.
The RK3588 is about 120 EUR.

Of course, that might all change if the global parts shortage ends at some time (and it looks like it 's getting better end of 2022 already).

The RK3568 has a TDP of 5W, the RK3588 6W.
We don't know about the OMAP5, but the OMAP3 used in the Pandora was 0.68W :)

So it needs a bit of testing, but seeing the RK3568 being used without any heatsink at all in a commercially available device, running Linux as well is a good sign.

At that price point, I think the RK3568 is looking really good. When considering the dimensions as well, I think the RK3588 is just too big. Not exactly sure which package you went with for the OMAP5, but looks like it'd be 17mm, which means the RK3568 is worth trying, RK3588 is probably much too big.

I wouldn't recommend using Anbernic's lack of cooling as a sign that this chip can be used fine without any cooling. These kinds of budget devices typically cut some corners in this domain and that results in decreased performance. Either the chip is getting too hot and throttling, or they just limit the chip in software as its cheaper than finding an appropriate cooling solution.

In terms of some realities of heat dissipation with regards to RK3588 and RK3568, the RK3568 will definitely be easier to keep cool. However, it is easier to keep cool because it has no high performance cores, so we take a hit there (the A15's in the OMAP5 are previous generation high performance cores). The RK3568 has proven to perform quite well for the general purpose tasks, but its going to be making more use of all those cores in order to do it, since each one is less performant and, importantly, does not support out-of-order execution. I would expect slightly better general purpose performance than the OMAP5 and roughly the same or maybe even a little bit worse for emulation. No reasonable PS2 emulation on this SOC, but up to it should be ok.

The RK3588 will perform significantly better, up to Gamecube (it can even do some Wii and Switch emulation). However, heat will be a serious challenge with this. In reality, in order to deal with this we would probably have to leave off most of the A76 cores and probably just run with 1, maaaaybe 2. At full blast (so when doing GC, Wii, Switch) this chip actually will need more like 10W with all cores on. I also have some concerns regarding the current power supply capabilities of the existing circuit, especially surrounding the battery charger in early boot phases. We're barely able to get the OMAP5 going due to limitations in early boot with the input current limit on the BQ charger chip. We need the SOC to be running in a limited power state early on in order to open up the gates and allow more current in, which the RK3588 may need too much to get kicked off for this. ARMv8's secure boot sequence introduces some limitations here which could require us to make changes to the main board to get this to work. The RK3568 also poses risk for this, but the risk is less.

Then of course there is the issue of OS. These days, mobile cores for higher performance graphics are really targeted at Android. In particular, these chips we're discussing are targeted at EdgeAI purposes on Linux. As such, the acceleration libraries provided by RK (this is almost always closed-source) reflect this. Android has kind of taken over as the target platform for emulation, and so the emulators themselves are better optimized for this platform. Similarly, manufacturers of chips such as these focus their efforts on optimizing their graphics acceleration libraries for Android and spend less time on the Linux versions. One may argue that Android runs the Linux kernel, so it should be the same, but it is not. There are separate OpenGL/Vulkan userspace libraries for Linux and Android as Android has specific requirements and additional features which need to be supported. You can see this in particular with the RK3588, which can handle emulation very well under Android, but actually quite poorly under Linux (see the end of the video I posted earlier). This means that regardless of which chip we use, we really must begin considering Android as a platform when targeting emulation. Linux is clearly much better for general purpose behavior, but for emulation and web browsing (which both heavily depend on 2D and 3D acceleration) Android is likely to have significantly better performance.

Also, it doesn't really seem to me that we would make good use of any of the features of the RK3568 over the RK3566, so maybe that is a better target as its cheaper.
 
Last edited:
Back
Top