The Future of Pyra's CPU

[MrConfusion]

I wonder whether this kills the PicoRio?

Well... at least they seem to have a plan:
"Imagination is also creating a new open-source GPU driver to provide a complete, up-streamed open-source kernel and user-mode driver stack to support Vulkan® and OpenGL® ES within the Mesa framework. It will be openly developed with intermediate milestones visible to the open-source community and a complete open-source Linux driver will be delivered by Q2 2022. Imagination will work with RIOS to run the open-source GPU driver on the PicoRio open-source platform." (https://riscv.org/blog/2020/11/picorio-the-raspberry-pi-like-small-board-computer-for-risc-v/)

I hope that works out, but of course one is left wondering what the coverage of such a plan is: will this apply to all designs and implementations or just some of them? I've become hideously skeptical (more than I'd want to be) of the "openness of stuff" recently. But one should not complain: a single well documented and supported implementation is better than none I guess.

Imagination (to my knowledge) never even gave any promises about the openness of the design and the implementers have definitely done their merry best to make the most mess achievable of all things related to openness :-(.

Even with RiscV the Hype has constantly been "because it is an open design, everything's going to be fine". But what does an open design benefit us if the implementations based on them are more closely guarded secrets than ever and co-operation between the end users and the implementers is nonexistent (unless you want to know where to stick the powercord, you'll get an answer to that from the support email in a matter of minutes so you know someone is reading it).

To my knowledge there's nothing "viral" about the openness of RiscV, so the pessimist me fails to see how things would change: we get a new ISA with even more obscure extensions, bootloaders, toolchains. Yay. As if having these from the ARM camp wasn't enough.

I'm sorry for spewing such pessimism, I'll just shut up and go back to work now...

 

[matzesu]

Well, as im now a Pyra User on Daylie base (at least when im not too lazy), i notice that even the "Lame" Omap 5 makes this thing noticable warm, and this is just 2 x 1,4 ghz, and im only in a bit of Internet and Office usecase, not that many games yet..
So if whe want a better CPU Board, whe need something that cools the System a lot better, maybe the CPU Board whit Connectors so you can put a Modified Bottompart on whit a Active Van? This would make the Pyra thicker..

Or a faster CPU who dont make that much heat..

 

[Djoga'Ro]

@MrConfusion I hear you. On the laptop I've been given to work on I installed Devuan and I don't get any sound devices. Learned so far that Sound Open Firmware stuff is in order. But, I also read most devices that support sof only accept signed fw. WTF
Stupid shit like this makes me depressive. Obstacles intentionally put in place by fellow humans. What a bunch of assholes. They really need to work on their colaboration skills.

 

[pyrat]

[EDIT: I've just read (2021-02-05) someone that seems to know more than I claiming that IMX8M needs blobs for the DDR controller, so it can't use RAM without blobs. That's quite a show stopper for me. I didn't know it.
I don't know about other IMX8 models. The mention is in the last footnote, the rest of the article is interesting but unrelated ]

Sorry, I said I'd leave this thread, but I've now read something that I didn't know then and edited my post.

 

[oskda]

Do I recall completely wrong when I seem to recall that the Pandora was of loose relation to the Beagleboard?
Well, now there's this: https://www.seeedstudio.com/blog/20...-single-board-computer-designed-to-run-linux/

Unfortunately, it has a SOC clearly meant for non-gaming, but I'd personally find it quite cool... "if only, but then again maybe not", because for the Pyra there's so many wasted transistors in that SOC and also due to the wasted ones a glaring omission (though there could be Hope with regards to that):
"One obvious item missing from the specifications is a GPU, and I was told while the first batch scheduled in March will be GPU less, but the next batch – slated to be manufactured in September – will come with an Imagination Technologies GPU." (https://www.cnx-software.com/2021/0...are-risc-v-linux-sbc-targets-ai-applications/)

...

I would love that RISC-V SOC (second version, with GPU). But I don't know how good it would be availability for Pyra, and worst, it may be a SOC adequate for a SBC, but id doesn't imply it be good for a mobile device: it may be power be too much for a small mobile device like Pyra (at this moment I don't have that info).

On other side I suppose ED and team would prefer other ARM to reuse code near directly (although I think it must be a 64-bit ARM and if you want to use it in proper way you would need to compile for 64-bits, because using it in 32 bit mode is a waste¹).

¹: We must remenber 64-bit ARM ISA is really a different ISA from 32-bit ARM. The share some points, but in fact they are different ISA, and you can't mix 32 ans 64-bit code (each one must be separate). ARM is not like x86 in that aspect. In x86 it is like a big monster with parts glued together: it was originally a very horrible 16-bit ISA, expanded to 32 and later (thanks to AMD) to 64-bits, and you can mix 16-32-64 bits code. ARM is totally different.

 

[oskda]

Even with RiscV the Hype has constantly been "because it is an open design, everything's going to be fine". But what does an open design benefit us if the implementations based on them are more closely guarded secrets than ever and co-operation between the end users and the implementers is nonexistent (unless you want to know where to stick the powercord, you'll get an answer to that from the support email in a matter of minutes so you know someone is reading it).

To my knowledge there's nothing "viral" about the openness of RiscV, so the pessimist me fails to see how things would change: we get a new ISA with even more obscure extensions, bootloaders, toolchains. Yay. As if having these from the ARM camp wasn't enough.

We must differentiate hype and hot expectations from reality. RISC-V ISA is free/libre, but in fact it is so libre it lets to do completely closed processors, and most of them will be closed. Only a very small fraction of RISC-V processors will be aimed at real freedom for final users. But that part is the one we may be more interested although being really small and not the most powerful processors.

For me that is the point (from open-minded user viewpoint): there can be some RISC-V open processors (without closed functions), and it is probable they will reach market although being a minority inside RISC-V. That option doesn't exist on x86 or ARM.

Some people (you don't obviously) confuse RISC-V openness and implications.

Even development in RISC-V ISA is so closed that some open projects abandoned it. For example Libre-SOC Project switched from RISC-V to PowerPC ISA: Libre RISC-V Open-Source Effort Now Looking At POWER Instead Of RISC-V

 

[oskda]

... So if whe want a better CPU Board, whe need something that cools the System a lot better, maybe the CPU Board whit Connectors so you can put a Modified Bottompart on whit a Active Van? This would make the Pyra thicker..

I think that is not an option as that imply modifying Pyra case. And that only would work when connected to that bottom part with fan.

Or a faster CPU who don't make that much heat..

That is the option: a more modern and more integrated (lower nm), more efficient CPU/SOC. But being more efficient doesn't mean it be faster. It may be even slower. For example Cortex-A53 cores SOC with more modern fabrication (lower nm) would be more efficient consuming much less energy for same work, but it could result it is not faster in mono core utilization.

PD: Only imagination: For me the ideal solution would have been to include SOC card on upper part (even integrating LCD board with it), under LCD display (separated with insulator) having external upper display case in aluminum acting as a "big" radiator (even with small fins to increment surface area) connected to SOC. Even in this way we eliminate heat from SOC to Li battery, prolonging its life, and it would not transfer heat from SOC to our hands. Obviously this can't be done, as other more standard way was selected, and it would need bigger hinges and more weight on base (bigger battery, or better two batteries).

PD2: I enjoy you being a fan of Commodore as I am. I saw in Youtube you had a Commodore manual on your desk.

 

[Djoga'Ro]

Then you wouldn't have to lead the display connection through the hinge, but everything else. Sounds like asking for interferences. Plus power for the display and the CPU board.

 

[levi]

On other side I suppose ED and team would prefer other ARM to reuse code near directly (although I think it must be a 64-bit ARM and if you want to use it in proper way you would need to compile for 64-bits, because using it in 32 bit mode is a waste¹).

¹: We must remenber 64-bit ARM ISA is really a different ISA from 32-bit ARM. The share some points, but in fact they are different ISA, and you can't mix 32 ans 64-bit code (each one must be separate). ARM is not like x86 in that aspect. In x86 it is like a big monster with parts glued together: it was originally a very horrible 16-bit ISA, expanded to 32 and later (thanks to AMD) to 64-bits, and you can mix 16-32-64 bits code. ARM is totally different.

Yes, x86 ISA and the following one add all the new instructions to the main ISA using the extra bits to add commands. That complicates microprocessor design because it doesn't know beforehand how many bits to fetch; could be 8 for the 8086 ISA, could be 16 for 386, 32 for 486 or 64 for AMD64. It probably fetches the full 64 bits and if it turns out it didn't need to rolls back the program counter and only interprets the bits found it needs to, but that's a complicated operation to do every instruction fetch. ARM instead since the Thumb ISA was invented added a flag to the status register that tells the chip what mode to be in, so that the chip can just run with that mode until the next time supervisor mode is entered. I'd argue that it's more efficient to do everything in the biggest mode you can be in. Usually that's the case because it gives you access to bigger registers, but at least in the slightly artificial case where you have a small number and you want to add 2 to it, it's most efficient to do that in thumb mode if you only need 16-bits for your data.

I did try to grok how to enter and leave 64-bit ARM mode but the docs are a little too dense to get my head around at present. I gather you need to go into a more powerful mode even than supervisor mode.

 

[Letalis Sonus]

I did try to grok how to enter and leave 64-bit ARM mode but the docs are a little too dense to get my head around at present. I gather you need to go into a more powerful mode even than supervisor mode.

It only works by switching the exception level, you basically reconfigure the lower exception level you want to switch into to be 32bit before triggering the exception return into it. Rule of thumb: you can only go down on lower exception levels, once you enter 32bit mode you can only switch back by triggering an exception into a higher exception level that is running in 64bit mode.

 

[matzesu]

Im a fan of the C64, because it was basically my first Video Game Plattform (was the C64 from my Sister), i have the Manual, but only the C64 Maxxi, i wanted to search our Original C64 but never found it..

im now short bevor my first 1 Months of Using the Pyra, and i dont had that much trouble whit only 2 x 1,4 ghz and only 4 gb ram, but i know that the OMAP5 is quite old

 

[λ the β-Redex Reducer]

One thing that I like about C64 is that it assumes knowledge of the computer because there are few abstractions. I like how you can just poke and peek directly into memory. I recently even bought a C64 manual in a thrift store.

 

[levi]

That's the benefit of linux. It runs pretty well on slower chips. Sure, some games and stuff might push it, but you can still do cool stuff with older kit.

 

[oskda]

Then you wouldn't have to lead the display connection through the hinge, but everything else. Sounds like asking for interferences. Plus power for the display and the CPU board.

I think you are wrong: actually we have a very big data transit between lower and upper case as video display travels from one to other.

On other hand, if we had CPU board (contains RAM, GPU etc) next to display, in same part, we would save lots of data transit from lower to upper case.

What means much more data transit in Pyra, video or storage? I suppose it is video.

But I insist: other way was selected and now it can't be undone.

 

[hns]

Only imagination: For me the ideal solution would have been to include SOC card on upper part (even integrating LCD board with it), under LCD display (separated with insulator) having external upper display case in aluminum acting as a "big" radiator (even with small fins to increment surface area) connected to SOC. Even in this way we eliminate heat from SOC to Li battery, prolonging its life, and it would not transfer heat from SOC to our hands.

Then you wouldn't have to lead the display connection through the hinge, but everything else. Sounds like asking for interferences. Plus power for the display and the CPU board.

I think you are wrong: actually we have a very big data transit between lower and upper case as video display travels from one to other.

On other hand, if we had CPU board (contains RAM, GPU etc) next to display, in same part, we would save lots of data transit from lower to upper case.

What means much more data transit in Pyra, video or storage? I suppose it is video.

But I insist: other way was selected and now it can't be undone.

(I have added back some quotations of the original proposal and a response which goes in the direction of our design decisions).
Well, we had thought about putting everything behind the display like a compact module.
But such a design has quite some drawbacks.
It is not only about data rate. For Video we can use the optimized MIPI standard which has been designed for this purpose. So sending MIPI through the cable through the display hinge is energy efficient and takes care to keep radiation low. And, it suffices to have 10 signal wires. We add I2C for the touch screen and LED controller and power.
Now comes the key problem to be solved: energy should flow with as low resistance as possible from the battery to the modem and the SoC card. Getting this distributed to the display through the hinge would be really difficile, although not impossible. So we decided for the simpler solution.
Another aspect is where the connectors should be. We have 2xUSB3, 1xUSB2, HDMI, Console, Headset and 2 full SD slots. This means to fiddle much more wires from the CPU board through the hinge to the basement than we have with the chosen split.
SD signals are slower than video, but we have USB3 connectors and HDMI. These can be used for even higher data rates than the MIPI video signals. So we would have much higher speed signals going through the hinge from the display to the base with interfaces not designed for that purpose.
Alls this means we would need a much thicker or wider cable which has more risk to break - or we can not open and close the lid.
Well, a solution would have been to add all connectors to the display (upper part). But then what happens if you open the display lid? The cables move around. And the display would have to be much thicker than currently to give space for all the components while the basement would not become much thinner even if we remove most electronics and just keep the keyboard matrix and battery connector and the battery itself in the base.
Moving components to the display would also the center of gravity and the risk that the device tilts while not holding in your hand gets higher (I once had a notebook where the display glass was too heavy compared to the battery in the bottom part... I didn't have it for a long time).
So there are quite some arguments for the current design - which is necessarily a compromise... The challenge is to find the sweet spot.

 

[oskda]

For Video we can use the optimized MIPI standard which has been designed for this purpose. So sending MIPI through the cable through the display hinge is energy efficient and takes care to keep radiation low. And, it suffices to have 10 signal wires.

¿How many wires takes a USB 3 cable or similar connector?

With my idea you had micro HDMI on top part, on its border, but all the other connectors would be on bottom part andwould only need one USB 3 or similar to connect all them to upper part, using a USB hub chip on lower part. Even keyboard+game controlls would be connected to that USB hub chip, and battery controller. So you only need to pass a USB cable (or similar) and a power cable from bottom case to upper case.

I own a Thinkpad Helix 2 convertible (tablet-notebook) computer with detachable keyboard-base. On base it has power, backlight keyboard, trackpad+trackpoint, USB port, video port and extra Li-ion battery, and there is no problem connecting both parts.

Now comes the key problem to be solved: energy should flow with as low resistance as possible from the battery to the modem and the SoC card.

On my Helix 2 wih "Pro" keyboard base (with that base it is not like a Suface tablet, but like a notebook), not only foldable like Pyra or a notebook but with separable parts, there is no problem with energy or connections, and in lower part there is a battery and power connector to feed complete computer (both parts).

Well, a solution would have been to add all connectors to the display (upper part).

I think only HDMI would be better on upper part, all the other, as they are not super fast (SD card interface used in Pyra is no that fast) can be combined in USB 3. Even could would be place for a M.2 drive on lower part, and that could speed up data even using a USB 3 for comms, compared to SD cards.

I understand other direction was taken, and there is no way to return to the past, but I continue thinking integrate CPU on bottom part is a bad idea, because there is no place or other elements to cool it in a good way on Pyra, while in top part it could use upper case as a big aluminum radiator, while in lower part it will heat up battery and user hands.

With very old pocket computers (I have a lot of them) there was no problem as CPU and other components didn't generate heat, but with modern CPUs and modern software it is completely different.

 

[Letalis Sonus]

¿How many wires takes a USB 3 cable or similar connector?

USB 3.0 (not counting the USB-C extra cables) has 2 cables for power, a simple twisted cable pair for USB 1.1/2.0 signals and two high-frequency twisted cable pairs for USB 3.0 signals. For HDMI, you need at least 4 high-frequency twisted cable pairs - and that may still not work, because using cable pairs that were not designed for the targeted frequencies may cause the shielding of the cable to fail on you.

That's why you only have USB 2.0 left if you use HDMI through USB-C, it needs all 4 high-frequency twisted pairs.

On my Helix 2 wih "Pro" keyboard base (with that base it is not like a Suface tablet, but like a notebook), not only foldable like Pyra or a notebook but with separable parts, there is no problem with energy or connections, and in lower part there is a battery and power connector to feed complete computer (both parts).

Embedded displays on larger devices switched to DisplayPort long ago, which only requires a single high-frequency twisted cable pair per channel and another less critical cable pair for the AUX channel, which uses rather low frequencies if you only need the interface to output video data at a fixed refresh rate. Additionally, DisplayPort only uses a few fixed transmission frequencies, which makes it much easier to adapt the hardware design to minimize electromagnetic interference than HDMI.

With DisplayPort 1.2, a single channel provides enough bandwidth to feed a FullHD screen at 60Hz, which allows for very simple and robust display connections.

 

[oskda]

That's why you only have USB 2.0 left if you use HDMI through USB-C, it needs all 4 high-frequency twisted pairs.

For that reason in my idea HDMI is on upper case part, while all the other connectors are in lower case, all sharing a USB 3 hub chip So you would have USB 3 speed, enough for Pyra even combined in a hub chip.

Embedded displays on larger devices switched to DisplayPort long ago

I remember something like DisplayPort was royalty free or something like that, while to use HDMI you had to pay. So even more reasons to use DisplayPort

 

[netlinker]

As far, as I know the better way would be to use Type C DisplayPort Alternate Mode. It injects Displayport Packets into the USB Traffic and has quite some spread now and does not use the USB 3 Lines in a blocking manner. Librem 5 has this implemented according to specifications. This is likely how those docking solutions are working. I'm personally not a friend of such solutions, especially not for storage. Raspberry Pi moved away from this solution for a reason.
You should also keep in mind that you need to write drivers for all your boot devices and USB is not easy to implement.

 

[Letalis Sonus]

It injects Displayport Packets into the USB Traffic

There is no injection happening. It simply uses the entire cable pairs instead, making them unavailable for USB 3.x. However, USB 3.x only needs 2 out of the 4 available cable pairs, so you can just transmit 2 DisplayPort channels in parallel to the USB 3.x connection. If you need more than 2 DisplayPort channels, USB 3.x is unavailable.