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

[levi]

Yes, you're right. Charging current never needs to go through the hinge, providing the charge port is on the bottom. The only current that needs to go through the hinge is enough to run the CPU, GPU, and all of the 5V parts (usb ports in the main).

 

[ClockworkCoder]

News threads these days have become too quiet, nary a sign of zombies, nor any off-topic shenanigans.

Also, aside from our resident YouTube hero, I don't think there's been much content from other Pyra owners.

Is there any update re assembly? Or anything new re the new CPU upgrade?

 

[netcat]

There should zero emphasis on cpu upgrades until the pre-orders are fulfilled.

 

[spud42]

yep ED said a POSSIBLE cpu upgrade , now everyone thinks it will be ready tomorrow...

a new board will take at least two months™ to produce and test.

 

[ClockworkCoder]

Right now, I'll take any news.

Also, not sure how many (of pre-orderers) may want to stall until a version with a new CPU is preinstalled.

 

[Null]

nor any off-topic shenanigans.

Give me a break, I'm just one man.

Also, not sure how many (of pre-orderers) may want to stall until a version with a new CPU is preinstalled.

I'm personally fine with doing that.

 

[netcat]

Right now, I'll take any news.

but you did the is-my-pyra-ready website so you have access to the data no? specifically you have access to the completion history so you can plot the trajectory which we can use to predict when ours will be done. better indicator than ED's forecast.

 

[ClockworkCoder]

so you have access to the data no?

No, unfortunately not.

 

[netcat]

but surely you left your id.rsa.pub in his .authorized_keys somewhere?

 

[ClockworkCoder]

but surely you left your id.rsa.pub in his .authorized_keys somewhere?

It's a single-page script. No need for access to any server, and I'd rather EDs servers were hardened rather than having back-doors being left in willy-nilly.

 

[Djoga'Ro]

I can give you a fuzzy data point. My Pyra just arrived and I had pre-ordered it within the first 15 minutes.

 

[TrashyMG]

I can give you a fuzzy data point. My Pyra just arrived and I had pre-ordered it within the first 15 minutes.

slow poke...

 

[netcat]

I can give you a fuzzy data point. My Pyra just arrived and I had pre-ordered it within the first 15 minutes.

what's your invoice number?

 

[Djoga'Ro]

I don't know. In my old emails I can only find an order number made up of letters - nothing like the digital number invoice numbers Ed states in the other thread.

 

[Batou456]

There should zero emphasis on cpu upgrades until the pre-orders are fulfilled.

If I'm understanding things correctly the RK3568 is effectively the more hobbiest friendly version of the RK3566 used in the Anbernic RG503 & RG353P. Linux development thus can steal off the Anbernic related efforts, and GPU of the RK3566 is Mali based for what that's theoretically worth.

GitHub - JustEnoughLinuxOS/distribution: Home of the JELOS Linux distribution.

Home of the JELOS Linux distribution. Contribute to JustEnoughLinuxOS/distribution development by creating an account on GitHub.

github.com

I don't own examples of and have not detailed tested an OMAP5 & RK3566 side by side, but I would tend to expect CPU performance to be more of a side grade than an upgrade. The Cortex A15 is a three-issue Out of Order performance core from 2012. The Cortex A55 is a dual issue In Order efficiency core from 2017, intended to complement the Cortex A75.

Exploring DynamIQ and ARM’s New CPUs: Cortex-A75, Cortex-A55

www.anandtech.com

The RK3566 should be more power efficient, offer newer APIs, and offer a few other niceties associated with being newer but... while the branch prediction engine is far newer the Cortex A55 is still a two-issue In Order processor with an expected clock advantage of only 20%. In CPU terms I would tend to expect which one comes ahead to depend on the nature of the particular program, with something analogous to an AMD K5 versus an OG Pentium. That said the RK3568 should be fine for running Duckstation at 2x resolution and otherwise maturing up what the Pandora could with a reasonably efficient passively cooled solution.

Given how overdue* this project has been, which in part is due to the larger Linux Community not having developed particular interest in the OMAP5, I'm fine with them effectively leaning on JELOS and the FOSS Mali driver efforts personally. My only potential concern with the RK3568 would be the sound system side of things, given TI parts have been noted to for their good sound chips.

*https://en.wikipedia.org/wiki/DragonBox_Pyra

Friendly reminder the Pyra was presented during the 2014 FOSDEM, and the original expectation was that it would be shipping around the same time as the original GPD Win in 2016. It's now 2022.

 

[ptitSeb]

In french (graphics and number don't need translation), but some benches for RK3568 vs other cpu: https://fr.gadgetversus.com/processeur/rockchip-rk3568-fiche-technique/ Not bad for nomething that doesn't heat up

 

[pyrat]

There should zero emphasis on cpu upgrades until the pre-orders are fulfilled.

I absolutely agree. Having said that: did I read right that RK3568 has Wifi 6 in SOC ? I think now the wifi chip is not even in the same board as the SOC ?
I kind of prefer anything with proprietary firmware in a different chip, but I guess anyway the Wifi functionality, just as some other, won't be used to maintain
the rest of the Pyra design and allow any new CPU board to be mounted in old Pyras. I'm guessing a different wifi standard would need different antennas too, so it's better to ignore it (except to switch it off and not feed any power to it).
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.

OMAP5432	RK3568
28 nm	22 nm
2 A15 cores @ 1,5GHz (thanks, @TrashyMG)	4 A55 cores @ 1,8GHz (or 2GHz stated somewhere?)
2MB? 1MB? cache	512 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)

But I insist: preorders are for OMAP5432 Pyras, and soem components, including OMAP5432, RAM etc. are already in stock, so the priority should be building and shipping the current design first.

 

[TrashyMG]

2 A15 cores @ 2GHz (1,5MHz? 2 MHz?)

1,5GHz is the default clocking on the OMAP5, don't think I've ever seen it stated to run at 2GHz. I know I have played with 1,7GHz OC when I was playing with the Device Tree settings, but this was on the devboard with a fairly chunky Heatsink.

2 Mali G52 820 MHz (32 shaders , 54,4 GFLOPS (GPU))
(free driver, I think)

From what I understand the Mali driver is just like the PowerVR SGX Driver, the kernel sources are open-sourced, but require a binary blob package to function. But the Mali drivers are much better supported. That and is a much better 3D graphics core.

 

[pyrat]

From what I understand the Mali driver is just like the PowerVR SGX Driver, the kernel sources are open-sourced, but require a binary blob package to function. But the Mali drivers are much better supported. That and is a much better 3D graphics core.

So Panfrost can't be used ? Or Panfrost still requires blobs ? I know there are proprietary Mali drivers. I just thought Panfrost gave a 100% free alternative...
I thought I used Panfrost in a blob free rk3399 once, but I use so little 3D that maybe I just didn't notice ?

 

[TrashyMG]

So Panfrost can't be used ? Or Panfrost still requires blobs ? I know there are proprietary Mali drivers. I just thought Panfrost gave a 100% free alternative...
I thought I used Panfrost in a blob free rk3399 once, but I use so little 3D that maybe I just didn't notice ?

I didn't know about Panfrost, I was stating from the official driver standpoint. if it works great it will be a nice bonus to the project, hopefully performance is good on panfrost vs proprietary driver.