Future of the CPU board?

[Grench]

Although, out of curiosity, what do you see as a potential way to further optimize for the OMAP5? I don't know much about the platform or what it has to offer other than having an ARM NEON vector unit, which is certainly a good thing to have and can speed a surprising number of operations up.

I have no idea. However, I do know, that when the Pandora was finally on the verge of coming out people ranted about how 'old' the SoC was and how it should be made from XYZ instead and that it would never be able to run (insert half of what Pandora can do here). A large part of the fun with the Pandora is how the community figured out how to do the things that were 'impossible' when it was released. The Pyra isn't about what it can do on release. It is what we as a collective community can convince it to do over the months and years -after- we get them. Give it/us/Pyra a couple of years on the current SoC THEN look to see what SoCs might be available for the next iteration.

Think of the Pandora and it's progression from the first CC units through the Rebirth and the 1Ghz. It expanded and refined itself over time on the same platform. The Pyra could, in theory, go through 2-3 additional advancements on the OMAP5432 over the next 18-24 months after release, but it first needs to BE released AND be adopted by the community AND sell in significant numbers to make any advancements 'worth it'.

Lets play with the toy we got first.

 

[Galaxis]

From my experience, working with the iMX8 family is the path of least resistance software wise. I have done board bringup on iMX8MQ based platforms in the past and it has very good support. Many other vendors have proven to have significantly worse software support (poorly written kernel code that needs to be rewritten, etc).

The MNT Reform is going to use an i.MX 8M too. The Reform has way more space available in the case though, and more battery power...

(See https://mntre.com/media/news_md/2019-05-20-reintroducing-reform.html and pictures at https://mastodon.social/@mntmn/media)

 

[everfresh]

Lets play with the toy we got first.

I'm all for optimizations and coaxing performance out of low-power hardware, I like this vision for the device. I've actually been theorycrafting a lighter weight GUI for devices like this for some time now, previously for Raspberry Pi-powered hardware but it could certainly work well for this. It involves a lot of terminal apps and i3 window manager

 

[ToastBucket]

Lets play with the toy we got first.

I understand where you’re coming from, but I don’t really see any problem with simply discussing this. That’s what the forum is for. Clearly no money or resources have been launched into this, and whether they do and when is entirely up to ED and HNS. I just don’t see the harm in discussing the future since the Pyra was specifically designed for this. It’s just fun and interesting.

 

[levi]

Yes, that's certainly true, but on the other hand.

 

[Grench]

I understand where you’re coming from, but I don’t really see any problem with simply discussing this. That’s what the forum is for. Clearly no money or resources have been launched into this, and whether they do and when is entirely up to ED and HNS. I just don’t see the harm in discussing the future since the Pyra was specifically designed for this. It’s just fun and interesting.

Unless it is being led a project lead or primary developer. Then the future can seem 'too near' resulting in fear, uncertainty or doubt regarding purchasing the current device.

Yes, that's certainly true, but on the other hand.

Exactly.

 

[Djoga'Ro]

Doesn't the current state of Risc-V provide ideal grounds for Osborne Effect mitigation? Aren't there high hopes in Risc-V about less legal entanglement, better libre capabilities for systems atop of it, made-to-order SoCs, low minimum order quantities, and whatnot? (Please correct me, if some or all of these points sprung from my imagination. I myself am not 100% certain, that I got it right entirely.) But on the other hand, it's all just starting out to become a reality and one would want to wait out its maturing.
So great outlook and an early onset to to be expected?
[doublepost=1570161596,1570159197][/doublepost]

Although, out of curiosity, what do you see as a potential way to further optimize for the OMAP5? I don't know much about the platform or what it has to offer other than having an ARM NEON vector unit, which is certainly a good thing to have and can speed a surprising number of operations up.

If I got that right, there are still several facilities the SoC brings that don't get utilized by the software in its current state - the M4 cores, graphics acelleration, stuff. (You may want to wait for others to correct me or maybe add stuff.)

 

[levi]

Doesn't the current state of Risc-V provide ideal grounds for Osborne Effect mitigation? Aren't there high hopes in Risc-V about less legal entanglement, better libre capabilities for systems atop of it, made-to-order SoCs, low minimum order quantities, and whatnot? (Please correct me, if some or all of these points sprung from my imagination. I myself am not 100% certain, that I got it right entirely.) But on the other hand, it's all just starting out to become a reality and one would want to wait out its maturing.
So great outlook and an early onset to to be expected?

I'm not sure what legal entanglements there are with other CPUs you can buy to be honest. Maybe patents, but those don't really affect end buyers. I guess if you had the skills to edit the RISC-V lithography you could make your own super-chip just for your own needs, but how exactly are you going to get that made? Nobody's offering made-to-order SoCs in the way you imagine just yet, as far as I've seen. The best you'll get is places like GlobalFoundries, and I don't know what their minimum order quantity is, but I doubt it's revolutionary. Maybe we'll get more players entering the market using the RISC-V designs to make new low power and quick chips, but we still need to wait for that to happen.

And how this mitigates the osbourne effect I have no idea really.

 

[Djoga'Ro]

I'm not sure what legal entanglements there are with other CPUs you can buy to be honest. Maybe patents, but those don't really affect end buyers.

I've read about something about not being very flexible with licences bought from ARM Holdings. Just some gefaehrliches Halbwissen on my part. Doesn't affect end user, true.

Nobody's offering made-to-order SoCs in the way you imagine just yet, as far as I've seen.

Not like at the tailor's, more like with Lego: sifive.com

And how this mitigates the osbourne effect I have no idea really.

Shift potential buyers' focus to Risc-V pushing expectations, while lowering the expectation of an upgrade coming, soon.

I'm just probing around, hopefully receiving intel on what may actually be expected of Risc-V and what might rather be just induced by my excitement.

 

[Letalis Sonus]

Doesn't the current state of Risc-V provide ideal grounds for Osborne Effect mitigation?

One of the bigger problems is that with any CPU that ought to provide a significant performance nowadays you have to put a lot more effort into what's below the actual architecture specification. RISC-V itself is just the boilerplate, its current implementations are simply not overengineered enough to provide enough performance. It will have to conquer the microcontroller market before it comes even close to becoming a viable alternative for any A-class Cortex to get enough traction.

That first step has already started, though, the Chinese already sell extremely cheap RISC-V microcontrollers that compete with the M-class Cortex chips. Take the Longan Nano board as an example, it only costs 5$.

 

[hns]

If the subsystems have been modified on the NXP side or the Letux side, there is significantly more effort involved repairing this to create compatibility. Letux already supports iMX6, so I have some confidence that we don’t stray too far but I’m not sure how stable the iMX support is in Letux.

i.MX6 is supported for Udoo neo (I use one almost daily as an Ethernet connected SD-Card reader). i.MX8 is neither tested nor configured, but 100% coming from upstream: http://git.goldelico.com/?p=letux-k...oot/dts/freescale;hb=refs/heads/letux-5.4-rc1 What is of course missing is some device tree for a specific combination of Pyra-mainboard and a newly developed i.MX8 based board.
Generally it is not very difficult to prototype something based on a ca. 100€ i.MX8M board and developing an adapter fitting into the connector positions of the omap5 board. Could be done in ca. 4 weeks (if someone pays for it) and would allow someone to work on the software side.
[doublepost=1570170333,1570169990][/doublepost]

Although, out of curiosity, what do you see as a potential way to further optimize for the OMAP5? I don't know much about the platform or what it has to offer other than having an ARM NEON vector unit, which is certainly a good thing to have and can speed a surprising number of operations up.

AFAIK the idle states inside the omap5 are not fully supported so it may draw more energy in idle mode than needed. There have been discussions about "Smart Reflex" which is currently not supported by the kernel. This would further optimize processor voltage at high clock rates allowing to run faster without overheating. NEON can be used if compiler options are chosen to create code (AFAIK standard Debian doesn't do that) - and code can make use of it (it is a vector calculation unit to speed up e.g. video decoders or physics models for gaming).
RISC-V is nice, but there are no high-speed tablet/smartphone/notebook SoC at the horizon. Mainly microcontrollers. So it is long-term future.

 

[Djoga'Ro]

One of the bigger problems is that with any CPU that ought to provide a significant performance nowadays you have to put a lot more effort into what's below the actual architecture specification. RISC-V itself is just the boilerplate, its current implementations are simply not overengineered enough to provide enough performance. It will have to conquer the microcontroller market before it comes even close to becoming a viable alternative for any A-class Cortex to get enough traction.

That first step has already started, though, the Chinese already sell extremely cheap RISC-V microcontrollers that compete with the M-class Cortex chips. Take the Longan Nano board as an example, it only costs 5$.

Yes of course, it needs time to mature. I just see it having a big advantage via the shared effords premise. I'm aware that sharing isn't a legal obligation, which is where for me some uncertainty comes in. For now, I'm very excited to see for example, what Esperanto Technologies will have to show and how that sharing idea will play out.

 

[everfresh]

AFAIK the idle states inside the omap5 are not fully supported so it may draw more energy in idle mode than needed

I would definitely be interested in exploring this since it is important for using the Pyra as a phone, and could further increase its already incredible battery life.

NEON can be used if compiler options are chosen to create code (AFAIK standard Debian doesn't do that) - and code can make use of it (it is a vector calculation unit to speed up e.g. video decoders or physics models for gaming).

Having used NEON intrinsics in code before I can tell you that being clever about how you use it can provide strong benefits. This will likely only work if you build packages from source since I would doubt that the packages in the repo are compiled for the NEON since not every processor has one and the repo needs to be generic. Even without code changes, compiling with NEON extensions in GCC causes the compiler to optimize around things like moving 64-bit quantities around, which is pretty cool in and of itself.

RISC-V is nice, but there are no high-speed tablet/smartphone/notebook SoC at the horizon

I think Alibaba was planning a notebook class RISC-V chip, but trust them as much as you will to make it open. I wouldn't hedge my bets.

That said you might look to SiFive, which does have a dev kit (albeit an expensive one) for their more powerful RISC-V core which I have personally used at a demo at a conference. It is in fact linux capable and performance is better than you might expect. Going out on a limb with RISC-V is the possibility of some of us getting together and building our own core designed specifically for the Pyra and spinning it up on an FPGA. I would expect that a midrange Kintex is what we would actually need for something like this, and while the part cost is high it does mean that we could push out software and hardware updates for the Pyra, which would honestly be so cyberpunk that I'm getting chills thinking about it.

The big thing I like about RISC-V is that the instruction set is freely modifiable at the hardware level, which means we could create some macro operations and other extensions that would be useful to a wide variety of Pyra users. Maybe it's a lofty goal but we're just theory-crafting at this point.

 

[levi]

Yes, the community as a whole has experience of NEON optimisations, at least Exophase and Ptitseb have used them I think.

Debian I think targets some old pre-cortex chips like the ARM11 I think which don't have NEON operations, I assume. And maybe it also run on some cortex-M chips that don't have NEON, I'm not sure. It's definitely worth compiling with NEON enabled for some of the bigger projects that need the performance and the efficiency, and thankfully we can put those in dbp packages and leave the debian repos alone.

 

[levi]

To perhaps bring this thread back on topic, Mediatek have announced a new chip, aimed at mobile gaming:

MediaTek formally pulls open G85 SoC drawer, reveals chipset for next-gen budget blowers

Clock speed? Up to 2GHz. 5G radio baked in? Nope

go.theregister.co.uk

I don't know what linux support for Mali graphics is like these days, and I suspect that talk of a fancy governor to keep temperatures in check is android only, and there are probably other reasons to discount it but it might interest someone at least.

 

[Eight Bit]

I've been very happy recently, running Manjaro Linux 64 bit on my Pinebook pro (much happier than I was when it ran Debian) which sports a rockchip RK3399 SOC with Mali T860 MP4 GPU. Now I'm no expert on SOC's and the PBP is surely not a gaming device but Manjaro seems to run quite decently with the latest kernel. I now even have 32 bit chromium running in a docker container so I can use Wiidevine for watching and listening to DRM content like spotify and netflix and it works great. I feel it will only get better as it did with the Pandora.

So maybe that or the RK3399pro are worth considering as it would be easy to surf along on already made efforts in regards to the software?

 

[kaprikawn]

To perhaps bring this thread back on topic, Mediatek have announced a new chip, aimed at mobile gaming:

MediaTek formally pulls open G85 SoC drawer, reveals chipset for next-gen budget blowers

Clock speed? Up to 2GHz. 5G radio baked in? Nope

go.theregister.co.uk

I don't know what linux support for Mali graphics is like these days, and I suspect that talk of a fancy governor to keep temperatures in check is android only, and there are probably other reasons to discount it but it might interest someone at least.

I'm not particularly knowledgeable on such things but I think the panfrost driver might be relevant, it's an open source driver for mali GPUs being developed by Collabora

 

[daveshah]

At a guess, the best candidate for a new CPU board would come from NXP, perhaps if they do an "i.MX9" - I don't think the i.MX8s tick enough boxes to be worth the downsides of a new CPU board (fragmentation and cost). The mobile-oriented SoCs often don't really have the feature set, availability or documentation good enough for something like this. Personally I'd rather see the OMAP5 pushed to its limits, for the next few years at least.

Realistically, the requirements for a new SoC would tick the following boxes:

- Better CPU performance than the OMAP5 - this rules out pretty anything A53 based
- Better GPU - fairly easy but drivers might be an issue, true OpenGL rather than just ES might be nice
- Fits within size/thermal/power constraints - perf/W issues rule out another 28nm SoC, should probably be 14nm or below, also rules out most industrial type SoCs
- Enough connectivity for Pyra feature set - MMC/SD ports, USB, HDMI, DSI, many mobile SoCs only support 1 SD card
- Reasonable low-level documentation, OMAP5 isn't perfect but the public TRM does cover the basic peripherals
- Available to buy from a reputable source in Pyra quantities - rules out Qualcomm et al.

From what I've seen of RISC-V SoC projects, none of them are going to tick all these boxes for a while. A bit of a wildcard is the Microsemi PolarFire RISC-V SoC + FPGA, but that is almost going to be very expensive and of rather niche interest (you'd have to build your own GPU in the FPGA part, and that would kill power consumption).

 

[comradekingu]

MNT Reform and Librem 5 already uses the i.mx8. Mobile variant or a next one would be sweet.

 

[EvilDragon]

The i.MX8 Mobile is actually the one we´re looking at.
It´s not much faster than the OMAP5 - but needs less power and produces less heat.