Silence!


I will admit my interest has died down a bit, but I'm stILL gonna continue with the Pyra primarily as a Phone and for PS1 games

Check Librem 5, It will be pain in the ass to use Pyra as primary phone.
My plan is to get Librem 5 and WiFi only version of Pyra, especially if the next CPU board is equipped with i.MX8M QuadLite (the same SoC as the one used in Librem 5).

GPD Win 2 is nice and powerful but it will lack the battery life even with his huge battery.
Also I am pretty sure that the Pyra will be superior in terms of craftsmanship, build quality, and ruggedness.
 
Check Librem 5, It will be pain in the ass to use Pyra as primary phone.
My plan is to get Librem 5 and WiFi only version of Pyra, especially if the next CPU board is equipped with i.MX8M QuadLite (the same SoC as the one used in Librem 5).

GPD Win 2 is nice and powerful but it will lack the battery life even with his huge battery.
Also I am pretty sure that the Pyra will be superior in terms of craftsmanship, build quality, and ruggedness.
I'm currently happy with a Blackberry Q10 as of now (even if it's dated), I can't go back to a touchscreen only phone ;)
If it's too much of a pain to use the Pyra as a phone, then I'll likely stick with the Q10. But then I'm not too sure what I would use the Pyra for
 
Aaaaand it's time for a newspost - it will be a short one (as I'm even more flooded with work than usual), but I hope you'll like it :)

Can you believe it? I can't. But let's not do the happy dance yet - let's wait for the prototypes to be finalized. As soon as I place the mass production order, we can do the happy dance!

Are these the prototypes that are going out to pre-orders, or, just prototypes for further testing?
 
We really need a term to describe the openness of devices like to Pyra or almost any x86 box with an nvidia video card. At least the primary computation path is all using open source code, it's just the final picture you draw depends on a binary blob (although if your writing to a framebuffer provided from that blob I reckon that would be relatively easy to test out)

I'm not sure RISC-V is strictly relevant to this discussion. The ARM ISA is fully documented, even if the internal layout isn't, so it's all deterministically specified (apart possible from some TrustCore weirdness I don't fully understand yet). Of couse, RISC-V giving us an open source layout which is neat to have, but it doesn't give us particularly more power to run open source code, which I care about more personally.

¿A term to describe openness (open, openness level)? The same than a term to describe heat levels :)

1st there is true real openness, like real white and after that there is grey, more gray, a lot of darker grays... and black :)

On other side I think you begin with a bad comparison: you get Pyra with ARM SOC, where near all ARM SOC with GPU haven't open drivers, and with x86 box you get one with a discrete graphics card, while Intel x86 can have integrate graphics with open drivers, something near most ARM can't have.

«At least the primary computation path is all using open source code»: sorry but binary blob is at kernel level, so you have soft in a very inner circle that you don't know what it is doing or what it can do. The same if you include cell phone modem: this is even worse, as they can introduce code from cell network! For example Librem 5 phone will have a separate hard for baseband, so main CPU/SO will be separate from them (baseband will have it's CPU-SO).

«The ARM ISA is fully documented»: the same for Intel ISA. The problem is that those chips (Intel and most ARM) include much much more than that documented ISA: there is much more in a SOC than Cortex or x86 cores, and we don't have control over them: even worse, some of those parts can have total control over our cores. This is really nasty, but so is reality about most actual computers.

My complain is that some people think that ARM SOC is free/Linux while Intel isn't, while Intel has Linux too, Intel support Linux, even Intel GPUs are the few with open driver, while near most GPUs used in Intel aren't.

Some people think ARM is good while Intel is bad (speaking about open model), and that isn't real.
Of course, I like ARM ISA more than Intel, as ARM is a much more clean modern ISA than x86 with all its heritage from old CPU, but that is another history.

Be warned: RISC-V is free, but in extreme: it has BSD Open Source license, so each manufactures can decide if he wants to open all, some parts, or close its chip/development. They have that freedom (to show/open or not, its work/product), and that is a requirement for industrial interest. The good part is that can be open hard, like for example Si-Five.

About a 100% RISC-V with less power: I would love to have one, even with less power. Because freedom and being real owner of my computer (I can control it) has no price: even I prefer half power and being real owner. But RISC-V isn't enough mature in this moment. We have seen 1st 64 bit RISC-V capable of running Linux, but still not in mass production and even without integrated graphics chip.
[doublepost=1520005275,1520004736][/doublepost]
on a slightly related note, last bios update for the GPD Pocket is from August last year and they do not seem to plan an update to fix Spectre ... so I personally would not trust them with that kind of money again

Do you know the date of last old OMAP5 binary driver/blob and if that 'update' solves ACTUAL Spectre bugs?

And the problem with Spectre is that there is no final solution (new forms to use Spectre will be discovered and new patch will be needed):

Meltdown and Spectre are not just hardware exploits, they are the processor and microprocessor exploits. Meltdown is an exploit against the CPU which has a patch in progress, while Spectre is an exploit against the design of microprocessors which has a “possibility to patch upon each exploit as it is identified” in a never ending game of cat-and-mouse.

Source: https://puri.sm/posts/meltdown-spectre-and-the-future-of-secure-hardware/

PD: Remember that OMAP5 binary driver/blob is at kernel level, all time on. So if it doesn't solves Spectre, that bug is present at a very inner circle.
 
There was The kids TV show based on young-adult novels called 'The Tripods'. That may not have shown where you are though. I don't particularly remember much about it though, but I think they came from space.

There were three books with the plot happening several decades, possibly a few hundred years, after the invasion of the tripods. However a prologue book was published later that described the invasion: First a new TV series for kids appeared and nobody knew where it came from; people speculated that the series was of extraterrestrial origin. . . The tripods came form space.

Sorry for straying off topic but I read the books and found them quite intriguing :)
 
  • Like
Reactions: rSl
With a glossy screen.

I hate glossy screen, but I hate even more resistive layer in front of screen: I have had a few pocket computers with resistive screen (Casio PB-1000, 68k PDA similar to Palm, HP Jornada, 2 Shap Zaurus) and that resistive layer is really horrible... and reflective.

When Pyra and Win 2 be ready, we'll can compare if Sharp Glossy screen in GPD Win 2 is worse or better than BOE with resistive layer added in Pyra.
[doublepost=1520006499,1520005816][/doublepost]
To be fair, that isn't by choice - there are no open-source options for it, and ED has stated he would prefer that if it were at all possible... but it isn't.

So if you feel like disassembling the binary and reimplementing it in an open-source way, go for it, or find some hardware of comparable power that has open source drivers.

In lieu of those... This is the best that can be done.

We know the actual situation, and for that reason I can't be quiet when someone says Pyra is open and GPD Win 2 isn't, when both of them can run open SO Linux, but only Win 2 can have open driver for GPU, while Pyra must have it closed.

«disassembling the binary and reimplementing it in an open-source way»: my friend, there is people working that way with some ARM GPUs and it is a very hard work and without very good results :) To do that work in a better way first you would need complete specification/doc of that component, and even with that is a very hard work to do a driver for a GPU. It may be Raspberry Pi (I haven't look enough at that) have got complete doc about GPU, and even with that to do a open complete driver is a monumental work for experienced coders.
 
Do you know the date of last old OMAP5 binary driver/blob and if that 'update' solves ACTUAL Spectre bugs?

there is a difference between may not be available / gets added quickly if available and it's available but no update planned at all ;)

Microsoft got fed up btw. and will include microcode loaders and distribute updates into Windows now and I am not surehow to feel about that xD

modern CPUs are very complex and bugs happen all the time, this may be a bigger one and quite persistant for now (one form or another) but BIOS Updates / Microcode Updates have always been important ... also anyone else remember that one : https://en.wikipedia.org/wiki/Pentium_FDIV_bug ?
 
You don't even HAVE to have the GPU driver at all to use it. You won't have accelerated graphics then, but there's an awful lot it can do without those.

Can you boot and run Pyra WITHOUT any closed soft or binary blob or firmware? I don't think so, but I would like it we can.

Do I have real control over that hardware from Cortex cores (the ones I acces as user/programmer) or there are hard items with control over them inside SOC?
 
Can you boot and run Pyra WITHOUT any closed soft or binary blob or firmware? I don't think so, but I would like it we can.

Do I have real control over that hardware from Cortex cores (the ones I acces as user/programmer) or there are hard items with control over them inside SOC?

Is this an issue that could cause problems in the future, as in: Could the situation arise that an update to Debian breaks compatibility, without being able to fix it as it is proprietary?
 
there is a difference between may not be available / gets added quickly if available and it's available but no update planned at all ;)

Microsoft got fed up btw. and will include microcode loaders and distribute updates into Windows now and I am not surehow to feel about that xD

modern CPUs are very complex and bugs happen all the time, this may be a bigger one and quite persistant for now (one form or another) but BIOS Updates / Microcode Updates have always been important ... also anyone else remember that one : https://en.wikipedia.org/wiki/Pentium_FDIV_bug ?

So simply you have no idea if OMP5 have solved or will solve Spectre bugs sometime for its closed driver/binary blob in the old OMAP5 SOC :O
[doublepost=1520007705,1520007281][/doublepost]
Is this an issue that could cause problems in the future, as in: Could the situation arise that an update to Debian breaks compatibility, without being able to fix it as it is proprietary?

With a closed driver/binary blob you can have problems in future versions because of compatibility, but my concern goes even further: having code and/or hard that can control your machine.

For example some modern CPU have an internal and no documented CPU (with its OS) controlling all other components (main CPU which we use). Other CPU have closed/blob code that control and even boot CPU/hard firmware updates... So you are not in control of those computers/hard: others have control over it.

I like to be the real owner of my hard and only I would decide what to do with it. Modern computers are every day further away from this. But things are so and today there is no other option. It may be we get better options in a future.

PD: My initial message only was a complaint for a user saying Pyra is open and GPD Win 2 close, while both can run Linux, but only GPD have open drivers GPU, whule Pyra has closed drivers.
 
Last edited:
¿A term to describe openness (open, openness level)? The same than a term to describe heat levels :)

More than terms I'd like some definitions and a kind of checklist (for every device on sale) :
OSHW No
RYF Yes
XYZ No
...

«At least the primary computation path is all using open source code»: sorry but binary blob is at kernel level, so you have soft in a very inner circle that you don't know what it is doing or what it can do.

Can you specify what blob do you mean ?
I've been assuming (I usually try to make sure about this things before I pay, but it's been so long I'm not sure my memory is right) that you could run
a Pyra without blobs (deblobing hms linux or patching the litlle delta on linux-libre).
Then you didn't get wifi or BT (you can use an USB dongle) and you have unaccelerated graphics (just display), but the rest works. Maybe the modem does
not work if you don't load the blob to the modem.

But you sound like if the only way to boot a pyra is with some blob inside the kernel ?

The same if you include cell phone modem: this is even worse, as they can introduce code from cell network! For example Librem 5 phone will have a separate hard for baseband, so main CPU/SO will be separate from them (baseband will have it's CPU-SO).

But the Pyra will also have separate hardware for baseband, even if only to let people order versions with ot without it, right ?
I'm not sure of the particular design but I thought in the Pyra the modem does not have access to main memory, so it's similar to Librem in that regard.
But I'm not very sure right now about both designs.
Somebody may confirm or I may look up docs when I have time.

My complain is that some people think that ARM SOC is free/Linux while Intel isn't, while Intel has Linux too, Intel support Linux, even Intel GPUs are the few with open driver, while near most GPUs used in Intel aren't.

I don't think all ARM SOCs are similar enough to say much of all of them .
For me the real problem is Intel ME. With Intel and some ARM the system is under the control of the manufacturer, or parties that can control the manufacturer or their keys.
For some ARM SOCs this does not happen. I think it does not happen with OMAP5, and iMX, which says nothing of other SOCs

About a 100% RISC-V with less power: I would love to have one, even with less power. Because freedom and being real owner of my computer (I can control it) has no price: even I prefer half power and being real owner.

I agree, but I thought the Pyra allowed this, Not with full functionality, but still working (keyboard, screen, touch, audio, USB, SDs, something more).
 
I'm currently happy with a Blackberry Q10 as of now (even if it's dated), I can't go back to a touchscreen only phone ;)
If it's too much of a pain to use the Pyra as a phone, then I'll likely stick with the Q10. But then I'm not too sure what I would use the Pyra for

If you use BB Q10 as a modem for Pyra you will have no problem. I think it is even better, because the problem is to run cell modem soft in Pyra (that modem can update code over cell network and it is at very low level in your machine).
 
If you use BB Q10 as a modem for Pyra you will have no problem. I think it is even better, because the problem is to run cell modem soft in Pyra (that modem can update code over cell network and it is at very low level in your machine).

I suspect you haven't fully understood the architecture of the Pyra.

To my understanding, the Cellular modem/radio are not built into the OMAP5 CPU/SoC. They communicate via what amounts to com port. I suspect that if we really wanted to we would be able to monitor and log all data going through that pipe between the 4G module and the SoC.
 
but I hate even more resistive layer in front of screen: I have had a few pocket computers with resistive screen (Casio PB-1000, 68k PDA similar to Palm, HP Jornada, 2 Shap Zaurus) and that resistive layer is really horrible... and reflective.
You should take a look at modern technology instead of relying on your experience with decades old bricks. Just because hardly anyone uses them anymore doesn't mean that they haven't advanced.
 
nah I do not have an OMAP5 board handy or can look into the future :) but that was not my point ;)

yeah anything has a processor and runs some kind of OS these days ... even my lightbulbs do

the modem chips themselves are running their own OS https://threatpost.com/baseband-zero-day-exposes-millions-of-mobile-phones-to-attack/124833/

there were also vulnerabilities in Bluetooth chips and Wi-Fi chips https://googleprojectzero.blogspot.de/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

but for all those devices out there the actually perceived damage has been quite low over the years - wonder what would happen if someone found a way to make money with these
 
Can you specify what blob do you mean ?

GPU blob.

I've been assuming (I usually try to make sure about this things before I pay, but it's been so long I'm not sure my memory is right) that you could run
a Pyra without blobs (deblobing hms linux or patching the litlle delta on linux-libre).
Then you didn't get wifi or BT (you can use an USB dongle) and you have unaccelerated graphics (just display), but the rest works. Maybe the modem does
not work if you don't load the blob to the modem.

But you sound like if the only way to boot a pyra is with some blob inside the kernel ?

It will be interesting if it can boot without a blob (obviously losing internal BT/wifi/GPU functions).

But the Pyra will also have separate hardware for baseband, even if only to let people order versions with ot without it, right ?
I'm not sure of the particular design but I thought in the Pyra the modem does not have access to main memory, so it's similar to Librem in that regard.
But I'm not very sure right now about both designs.

If it is so (only a modem module with its CPU+RealtimeSO only conected by a serial port to CPU without closed driver on Pyra) it will be good. Since a lot of time cell phones share CPU to control baseband chip.


I don't think all ARM SOCs are similar enough to say much of all of them .
For me the real problem is Intel ME. With Intel and some ARM the system is under the control of the manufacturer, or parties that can control the manufacturer or their keys.
For some ARM SOCs this does not happen. I think it does not happen with OMAP5, and iMX, which says nothing of other SOCs

I agree. Intel Management Engine (and equivalent system from AMD and other manufactures) is the most horrible thing in modern computers hard (Intel uses it since a decade or so). Not only the problem is that Intel or "friends" (for example some agencies) can use it, but that it has backdoors, and those doors can be discovered by others "beings" and getting full acces to all inside your computer byppassing all OS protectiion/password/etc.

I suppose OMAP 5, being old and intended more for industrial use, could be free of similar things, but we can't assure: it is not an open hard chip.
[doublepost=1520014041,1520013233][/doublepost]
You should take a look at modern technology instead of relying on your experience with decades old bricks. Just because hardly anyone uses them anymore doesn't mean that they haven't advanced.

¿Has avanced too much from Pandora? Becasue with Pandora I can see lot of reflections due to its resistive layer.

You can watch this video: and you will see lots of reflections when he moves Pandora, or when he uses stylus (you can see stylus like in a mirror on Pandora screen).

But it may be you consider Pandora an old brick, and that resistive layers have evolved a lot of since them. I will wait to see final Pyra to know it resistive layer has evolved enough and doesn't show reflections.

PD: I agree Zaurus SL-C2300 is very old: from 2006, 5 years older than old OMAP 5 from 2011 :)
 
Can you boot and run Pyra WITHOUT any closed soft or binary blob or firmware? I don't think so, but I would like it we can.
I believe you can, I'm almost positive the prototypes are still booting without the GPU driver right now. I was also under the impression that the bluetooth and wifi didn't need blobs.
 
Back
Top