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


It might improve video playback on those chips, but if I was running one of them I'd currently be configuring my video players to stick to software decoding until it's hit a release and been well tested.
 
pyrat said:
Yes, that's understood. 7W is possibly too much. But I understand 7W is thermal dissipation power at max load ? Or is it some average or made up number?
My question is what performance can you get at say 4W TDP with RK3588. It should be more than what you get from a RK3568 at 4W TDP.
Now you're either running with half the SOC off or you're running with most of it on for a few ms and then sleeping it all a few more. Or throttling down clock most of the time, Or some such.
So you're paying 5 times more for a SOC and using only half or it or using it only half the time or something. But you should still get a little more processing than with the cheaper one.
Is it worth it ? Dunno.
Click to expand...

Let's put it this way.

The original GPD Win used an actively cooled setup with an Intel Atom x7-Z8700 which has a SDP of 2 Watts, and had serious issues with inadequate cooling. This led to a beefier redesign with the Win 2 and a Intel Core M3-7Y30 which has a TDP of 4.5 Watts:
ark.intel.com

Product Specifications

quick reference guide including specifications, features, pricing, compatibility, design documentation, ordering codes, spec codes and more.
ark.intel.com ark.intel.com

The TDP [Thermal Design Power] specification is for the intended cooling solution, that's what it's called that. Manufacturers aren't necessarily as consistent as they should be about such things, but trying to cheat the TDP is folly, especially in a passively cooled device.

tl;dr:
A 7 Watt TDP chip is even not vaguely reasonable for the Pyra.
 
EvilDragon said:
It's not new, it's pretty old :) @mclien built it years ago when we released the Pyra at the Gamescom :)
Click to expand...
Well, the text is correct, but it's linked to the wrong user profile. :-(
(Might be my curse: When contributing to a open hardware project, it is always another "Mc-someone" that gets the credits.... Happened to my contribution to the Novena, too.)
 
This is great! I definitely will be buying the new CPU board. I'd also like to replace my case; I still have the one that causes the battery overheating problem. And I'd like to buy a new display cable, in case the one I have actually is broken.
 
I'll also buy the new CPU board and will assemble it in the new case. However, with the old case and CPU board, I would like to make a working OMAP5 Pyra, too. For experimental purposes, etc.
I guess I'm not the only one wanting this...
 
Last edited:
Last edited:
I don't see why it would need TrustZone (dunno how they've gotten the initialism of TF-A from that but that's not really my concern now). Trutzone was added to a design that simply booted by going to Address 0 in Supervisor mode, or more likely some Ring-0 mode these days, so if you add trustzone to that I don't see why it would need to go through that first. But even if it does provided we don't need to change it we shouldn't need the binary blob anyway. It should boot without network so i tend to thing the attack surface is limited.
 
TF-A = Trusted Firmware ARM ? whatever, it used to be called ATF before.
I'm not sure what other options are there. I know that rk3399 loads bootrom (fixed inside SOC), bootrom loads U-Boot TPL, TPL inits DDR and returns to bootlrom. Bootrom then loads U-Boot SPL and SPL loads ATF parts to DDR RAM and SRAM and loads U-Boot proper. Then ATF runs and "stays resident" and U-Boot proper starts. The ATF gets some interrupts first and has its own protected memory, there are some PSCI serivces or something in ATF that the kernel calls.
Even if it could be made differently, it may be some work if nobody tried. For rk3399 I've read people compiled ATF from source (without a propietary hdcp.bin) and it worked, but I haven't heard people using rk3399 without atf (TF-A). rk35XX doesn't have to work like rk3399 though.
I may just be missing information, I don't know.
 
I have an RK3399 based PineBook Pro. It doesn't seem to be as well optimized as a RaspberryPi 4 compute unit (or so I've heard). This is while trying to run the Renoise music editor on it because it has only 2 performance cores and 4 efficiency cores while the RasPi 4 series has 4 performace cores only. Other people have found Renoise to be capable on the RasPi 400, my system is only minimally capable. The Tension song is the stress test and my PineBook Pro lasts about 5 seconds into playback before the CPU overloads and aborts.

If the current Pyra is using an RK3399 it may be a little weak. The PinePhone Pro models have a mobile edition of the RK3399 that clocks slower in exchange for improved battery life.
 
samuraicrow said:
If the current Pyra is using an RK3399 it may be a little weak. The PinePhone Pro models have a mobile edition of the RK3399 that clocks slower in exchange for improved battery life.
Click to expand...
No. The current Pyra is not using a RK3399. It uses an OMAP 5432 (2x CortexA15) . Unless there's some optimization I'm missing it should do worse than an RK3399.
I just mentioned the rk3399 because it's the closer SOC to rk3588 that I know something about. Sorry if I misled you. It's all very especulative. Both SOCs require too much power and generate too much heat for the Pyra anyway.
 
That's awesome that renoise is a possibility. I do hope to run trackers on my Pyra but was thinking on an Atari st emu but renoise would be ffffff cool.
 
You must log in or register to reply here.

Similar threads

EvilDragon
Samples received, visit to Greece to restart the production planned
2
Replies
20
Views
111K
Magic Sam
Magic Sam
EvilDragon
  • Locked
Merry christmas and a happy new year (2012-12-25)
8 9 10
Replies
181
Views
44K
Wally
Wally
L
Selling my GP32 on eBay...
Replies
12
Views
2K
Tenno
T
L
Selling my GP32...
Replies
3
Views
2K
liquidcross
L
EvilDragon
New rooms, updated cases
2 3 4
Replies
66
Views
174K
levi
levi
Back
Top