Getting closer...


Although... Modifying the dbp system to allow a single package to provide binary for multiple platforms wouldn't be more than an afternoon of work...
:p
Well handling it on the repo side wouldnt be much more work either.
But, imho, having both binaries in the same package is useless. Why not using 2 different files ? The (your) dbp system already have architecture support build-in. The repo currently cannot have the same package for 2 distincts architecture, but changing this is a 2h job (changing a db constraint, and review the code)
 
I think it's a little early to be thinking about upgrades, but I'd like to see some actual benchmarks of the i.MX8 versus the OMAP5 we've got now.
Agreed, however since ED was the one that brought it up, it's kind of fair game IMHO.

.....................

Something about this one has me intrigued.
https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html
It is an automotive SoC, so it would, in theory, have a long availability cycle.

Linux is listed as the primary supported OS. "Supported OSs: Linux, Android, QNX® Neutrino® RTOS, Integrity®, others"
Linux support page: https://elinux.org/R-Car/Boards/H3SK
3D is handled through: IMG PowerVR Series6XT GX6650
(Question to ask - does Linux support include the 3D chip and if so, how long is the support envisioned for?)

Thermal considerations - this is a high speed 10 core chip. It would not be able to be run flat out with all cores in the Pyra's thermal envelope. However, if we restrict to using 2 cores OR 4 cores at lower clock rates, would it fit the performance/heat profile? Maybe even 1 CA57 core overclocked (game thread) and 1 CA53 core underclocked (OS thread)?

Dev board kit isn't cheap, but is more inclusive than most:
https://www.digikey.com/product-det...KBX0010SA09/RTP0RC7796SKBX0010SA09-ND/6621861

Performance - others are better equipped to make those estimations than I am.

Cost? For a Pyra type device, an SoC like the Renesas H3 may be getting binned at the manufacturer such that they are only using examples with all cores working. Maybe they have rejects where the one or more of the CA53 cores doesn't work and we're only interested in the CA57 cores? No idea - that would be for ED to ask any companies he's interested in working with.

The point? The above is one example scenario. I'm not saying 'we gotta do this'. There are a lot of ARM SoC producers/sellers out there beyond the cell phone parts that get all of the press. Today's cars have more processing power than the original space shuttle did - and their SoCs are very similar to Pyra type needs. There may be people in the community who know of other examples of SoC options that would be non-mainstream but still solid options to consider.
 
Last edited:
Well, if you are going to consider SOCs now, at least choose something based on the A72 or A73 . At least then by the time the upgrade board comes out , it will use a SOC with last generation tech as opposed to several generation old tech

Even the GPD XD+ which is about to hit the market for ~ $200 has a SOC with A72's in it and Vulkan support. It uses the MT8176 -> https://www.mediatek.com/products/tablets/mt8176
It's a hexacore SOC with 2 x A72s and 4 x A53's

Maybe there is a similar SOC with open source GPU drivers
 
Last edited:
Can we buy the socs from GPD? When they buy 10K or 100K for the consoles, maybe their will sell 1K or 2K to us, for their purchase price + 20%?
 
Well, if you are going to consider SOCs now, at least choose something based on the A72 or A73 . At least then by the time the upgrade board comes out , it will use a SOC with last generation tech as opposed to several generation old tech

Even the GPD XD+ which is about to hit the market for ~ $200 has a SOC with A72's in it and Vulkan support. It uses the MT8176 -> https://www.mediatek.com/products/tablets/mt8176

Maybe there is a similar SOC with open source GPU drivers

Most SoCs (especially by Chinese manufacturers) only have Android support, no Linux support.
Often with tons of binary blobs you can't use.

The HiSilicon ones might be better, as they're supported by Linaro and they have working Linux Devboards.
Getting them is another question thoug...
 
On the Gamescom, they runn the Dreamcast Emulator on the Pyra Prototyphe, and this was early one..,
PSX Emulation Multiple Times, so even if the 3D ditnt work the first few months, the Pyra should be quite usefull, at least for me.. as i just want a "New Pandora",
It is nt sayd that the Pyra will be a expensive brick the first few months after release, as the Debian on it is on a usable state, just not obtimiced for the Pyra Hardware..

Expect the Display Backlight brightness controlls (its stays for ever on full brigthness, as long the Pandora is "On"), and some scretches on the Case, my Pandora still works, so im not in a hurry,..
 
@levi I didn't mean running any emulator this way, but a specialized one, that can and does rely on being the only process being executed (over all cores at any given time, it is being executed). Well, that thought wasn't formed that well, when I wrote that earlier. Does Linux provide a way to guarantee a process or even a group of processes to run and stop on the number of cores it wants to simultaniously (in terms of context switches)? Or do I first have to ask, if CPUs/SoCs do provide any basis for this?

What you're looking for is putting "isolcpus=[cores you want dedicated]" on the Linux command line in the bootloader. Then use "taskset [core bitmask] [executable]" from a terminal.

It's about as close as you get to running individual cores in single user mode. The kernel will keep off the cores as much as possible. Any core bound interrupts will obviously still go through but it won't schedule any tasks on it without being explicitly told to do so.
 
You can go a lot further, if you look at the OpenAMP project and the `remoteproc` Linux kernel driver. That way it's possible to have two different operating systems - or both OS and baremetal code - running on multiple cores of a SoC.

In my case I used this to have one core of a dual core Cortex A9 running Linux, and another running FreeRTOS for more critical real-time functionality.
 
I would love to get some feedback regarding how well (or not) the GSM/3G/LTE modules are performing.
It is a bit concerning that there are so little mention of this. It feels like another bubble waiting to burst...
 
About the "Future version":
Could be it bought this year without buying older CPU-Board?
Would it Support Exagear?
Since mentioned SoC is 64-bit would there be 8+ GB versions of new CPU-Board?
 
Back
Top