I’m trying to decide between the two available CPU units for the Pocket Reform. As far as I can tell, these are the main points of each.
RK3588:
16/32 GB RAM
HDMI output
QCS6490:
Better CPU/GPU performance
Only 8 GB RAM
Sleep mode
So what I’m wondering is:
Is the QCS6490’s USB-C DisplayPort Alt Mode easy/reliable to use? If I have a USB-C dongle with HDMI on it, will that work to make up for the lack of built-in HDMI, or are there limitations I should be aware of?
Are there any plans to support sleep on the RK3588 in the future?
Is there the possibility of upgrading the QCS6490 with additional RAM in the future?
Hi, I hope it’s ok to jump onto this thread, but I’ve also been weighing up the two processor options. My preferred operating system is (currently) OpenBSD and it seems there’s been a fair amount of progress made with the RK3588 recently.
Is it likely that similar work can/will be done on the QCS6490, or are there any technical considerations that might make the Quasar less feasible for OpenBSD?
We (the community) doesn’t know yet because none of us has a QCS6490 in their hands thus far. The first batch of QCS6490 will be shipped to customers once 25 people have clicked the purchase button. This has not yet happened.
MNT is busy with a whole lot of other stuff. There are a number of people (including myself) who would pitch in to pay a developer with the right skills to make suspend/resume work on RK3588. Lucie already got it working with a monolithic kernel. Since RK3588 can suspend/resume in other platforms, this should “just” be a matter of the person with the right skills working on this topic. If you know somebody who could do this, please shout!
Of course my offer goes to you just as it would go to anybody: set up a gofundme or similar and I will wire some euros (I’m sure others would be willing to do so as well). This is a feature I really want.
Always feel free to nerdsnipe me. Especially if it is regarding one of the chips I’m running.
Perfect, let me have a look at it over the next week or so, while I’m looking at upstreaming kernel stuff anyway. I have to dust off all those parts of my brain, I might as well use them for something.
Part of why I moved to the rk3588s was to get s2idle working on the rk3588 devices. Well, that and barebox.
I checked out the kernel code. Looks pretty straightforward for the rk3588 SoC. Just kernel config and DTB updates needed to enable sleep.
On the rk3588 adapter (reform2-rk3588), the SOC_WAKE net is fully routed: it connects J1 pin 22 to U1 (reform2-som-connector) pin 145, whose function is GPIO1_IO3. Confirmed via netlist export, and schematic inspection. So when I get my Reform Next in the mail I can start testing that board.
I also had a look at the RCM4 schematic as well. That one doesn’t look so good. IIRC the raspberry pi cm4 didn’t have a sleep state.
The RCM4 board carries the same signal called SOC_WAKE, and it appears twice. On the motherboard-facing connector (reform2-som-connector), it lands on pin 49, whose stock name in that generic connector definition is CSI_P2_D1_N, a MIPI CSI camera lane, repurposed here. So on the RCM4 side, this pin does carry a real signal (whatever the RP2040/system controller drives for wake).
Sadly, on the CM4-module-facing side, that same SOC_WAKE net terminates in an explicit no_connect marker. The just means we need something to wake the rk3588 up, and unsurprisingly the board doesn’t provide it for us.
I might be able to hack something together with USB or soldering a giant button to one of the SOC_WAKE traces (j/k), but I’ll probably pause for now and pick back up with the Reform Next.
Oh my god I do not understand any of this, but if you could make suspend/resume on the rk3588 in my pocket reform happen that would be absolutely amazing!! Willing to also throw some money at it if wanted, as @josch suggested
