Future of the CPU board?

Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,212
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

Member
Joined
Aug 30, 2010
Messages
313
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

Newbie
Joined
Oct 3, 2019
Messages
19
Age
24
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 :eek:
 
  • Like
Reactions: rSl

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
245
Location
Seattle
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.
 

Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,212
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

moonstruck
Joined
Apr 3, 2016
Messages
977
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

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,371
Location
Somewhere off the coast of the EU
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

moonstruck
Joined
Apr 3, 2016
Messages
977
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

Advanced Member
Joined
Mar 5, 2009
Messages
1,286
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

Very Active Member
Joined
Dec 4, 2011
Messages
450
Location
Oberhaching
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-kernel.git;a=tree;f=arch/arm64/boot/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

moonstruck
Joined
Apr 3, 2016
Messages
977
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

Newbie
Joined
Oct 3, 2019
Messages
19
Age
24
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. :confused:

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

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,371
Location
Somewhere off the coast of the EU
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.
 
Top