Pyra news partially stale from the dragon's mouth


IIRC, you can look up your voucher in your shop account. If you still know how to login, that is.
 
I don't think so. Actual shop vouchers you buy appear there, but the voucher that is actually the mark of a pyra preorder is different. I'm not sure if it's listed in your deliveries though.
 
M'kay, I looked. I've got a voucher for the money I paid and an additional code to use, when ordering the actual product/making the final payment. Only the voucher is listed in my shop acc.
 
my voucher and pyra order were merged at some point, since vouchers technically expire. they should show in the shop, though.

Screenshot_20200213-201302.png
 
Fortunaly i copyd my Vouchercode to a TXT File on my USB Stick, so i only needs to fire up my GPD WIN Desktop Computer Setup, copy this Code to my Dragonbox Order, wait some days and then change the GPD WIN Desktop Computer Setup in a Pyra Desktop Computer Setup ^^

EDIT: But well, whe should first wait for the new Newspost to come the next few days
 
Last edited:
I do appreciate that both RockChip and AllWinner are at least attempting to get their devices into the mainline Linux Kernel.

One of my annoyances with the Pandora is being stuck on an old kernel (if I want to keep gpu acceleration at least).
For the Pyra, does the team have some way to get binary drivers from TI that are built for later kernels? I'm not asking about open sourcing the drivers, just some way to provide matching binary blobs every once in a while that keep up with the latest Linux kernel LTS release.
TI is doing this for a long time. And yes, there is OpenPandora and Pyra support for v5.6-rc1 because we are participating in the OpenPVRSGX project: https://github.com/openpvrsgx-devgroup
On Pyra, SGX is working (using TI blobs) with the known screen rotation limitations. Pandora 600 MHz has no (working) SGX setup yet, although the SGX drivers can be built. But recently someone has made SGX work on a 5.5 kernel with an OMAP3525 device. Pandora 1 Ghz should even work since we have it working on the GTA04. But I could not test on the Pandora because I have no 1GHz version.

I'd say that's on the edge of what most people mean when they say "hardware switch". What they really mean is a "mechanical switch", but nonetheless a software operated hardware switch can theoretically be operated by malicious software.
Here is a photo of how the tiny hardware switches of the PinePhone look like:
DSC01048.jpg


In my opinions this is more a marketing tool to differentiate a brick with display from another brick with display.
The practical use is IMHO limited since with such tiny switches you tend to never use them. To operate such a device as a phone, you have to turn them all on for your phone call and then turn off again. Who will be regularily doing this? If they are never turned on, well one could buy a cheaper devices that does not even have the switched off hardware...
The other aspect is that some malicious software may sit there and wait until you turn them voluntarily on and then tap some data. So if it is able to tap any data, the hardware kill switch won't help.
Something else to consider is, since these devices (like the Pyra) are open source software devices, everyone will have a different system installed. And you may even have modified your kernel or user-space.
This makes it quite difficult for spyware to focus a well defined target installation. And with just some thousands of these devices it is also not interesting. Unless you are the target of a spying organization that invests a lot of energy to find you and analyse your specific device.
Regarding the software controlled "kill switches" of the Pyra, we can turn off the Modem power through a gpio controlled power FET. Well some AT command does the same, but just to be sure... You can check if this gpio is active from user-space, i.e. you can monitor if some malicious process is tampering with this gpio. For the microphone it is connected to the Audio ADC in the twl6040 chip. This can be powered off separately, or you can remove the code that handles any microphone from the kernel. For WiFi and Bluetooth we use a TiWi module which also has two power on/off gpios. Well, we do not know if they really turn off power, but I think TI could not sell these modules if the power-off function would be broken. So unless someone manages to replace your self-built kernel image, the software controlled hardware switches will stay off.
And finally about securing the data you transfer over the modem or WiFi which is sometimes discussed a the reason why people ask for power switches. The help is end-to-end encryption. It has been designed for unreliable and not trustworthy networks. And the modem is to be considered as part of the not trustworthy network. Yes, there are attacks to not well written WiFi firmware but Linux developers take care of this in the newest kernel releases. Which is a good reason to update the kernel from time to time.
 
Wait, @hns does this mean there are working open source SGX drivers?
Yes, the kernel driver was always open source. TI did release them as part of their board support kernels (they even have new releases for the latest car entertainment chips). There was only no maintainance to keep them compiling and running on newer kernels. So we did set up a project to make the drivers compatible to latest mainline kernel. Unforuntately the code is not at all mature or in a shape that Linus would ever accept into into kernel.org.
But note that operating the SGX means you need user-space code. One part is a firmware that is downloaded into the SGX processor at boot time (similar to WiFi firmware). The other part are libraries which communicate with your OpenGL program and the SGX processor firmware. Neither of this is open source and even worse: there are hundred of different variants in the wild and only the right combination works. But they all use the open source driver.
You can see a video here: and here: Unfortunately I don't have a working OpenPandora setup.
 
Here is a photo of how the tiny hardware switches of the PinePhone look like:View attachment 35795

In my opinions this is more a marketing tool to differentiate a brick with display from another brick with display.
The practical use is IMHO limited since with such tiny switches you tend to never use them. To operate such a device as a phone, you have to turn them all on for your phone call and then turn off again. Who will be regularily doing this? If they are never turned on, well one could buy a cheaper devices that does not even have the switched off hardware...
The other aspect is that some malicious software may sit there and wait until you turn them voluntarily on and then tap some data. So if it is able to tap any data, the hardware kill switch won't help.
Something else to consider is, since these devices (like the Pyra) are open source software devices, everyone will have a different system installed. And you may even have modified your kernel or user-space.
This makes it quite difficult for spyware to focus a well defined target installation. And with just some thousands of these devices it is also not interesting. Unless you are the target of a spying organization that invests a lot of energy to find you and analyse your specific device.
Regarding the software controlled "kill switches" of the Pyra, we can turn off the Modem power through a gpio controlled power FET. Well some AT command does the same, but just to be sure... You can check if this gpio is active from user-space, i.e. you can monitor if some malicious process is tampering with this gpio. For the microphone it is connected to the Audio ADC in the twl6040 chip. This can be powered off separately, or you can remove the code that handles any microphone from the kernel. For WiFi and Bluetooth we use a TiWi module which also has two power on/off gpios. Well, we do not know if they really turn off power, but I think TI could not sell these modules if the power-off function would be broken. So unless someone manages to replace your self-built kernel image, the software controlled hardware switches will stay off.
And finally about securing the data you transfer over the modem or WiFi which is sometimes discussed a the reason why people ask for power switches. The help is end-to-end encryption. It has been designed for unreliable and not trustworthy networks. And the modem is to be considered as part of the not trustworthy network. Yes, there are attacks to not well written WiFi firmware but Linux developers take care of this in the newest kernel releases. Which is a good reason to update the kernel from time to time.

The thing is just that a similar Linux phone without the cameras simply doesn't exist (yet). Those DIP switches are probably not going to like being toggled every day either, so I'd probably end up leaving just the cameras off until I actually need one of them. With my current phone I use the rear camera about one or twice per month and the front camera has been used once or twice over the entire lifetime of the phone (about 2 years now). On my previous phone I think I only used it once and that phone lasted 4 years.

It's a shame I missed the order window for the "Brave Heart" edition though, I lost track of the project and didn't realize until I had already spent most of my electronics budget on new audio gear (and the final pieces are still queued up for the next Thomann order).

But I already agree with you about everything else, sorry if that didn't come across too well in my previous post.
 
If they are never turned on, well one could buy a cheaper devices that does not even have the switched off hardware

This is a good point. If there is scope for the Pyra phone to evolve, it would be one wish of mine to have a modular design: plugin camera module, for example. I guess in reality, that wouldn't make economic sense and could end up with a bulkier phone...

A mini clip-on camera for the Pyra might work...
Post automatically merged:

This may have been asked/answered before and may not be decided yet, but do we know what the boot-up/shutdown times are, or if there is further optimisation possible.

It's a different device and much simpler, but I was impressed with the Odroid Go Advance booting up a minimal Ubuntu in 10-15 seconds and powering off in under 2 seconds.
 
A Pyra Phone could fill a gap in the market where the Librem 5 missed out on being modular in favor of being thinner. I'm not entirely convinced that gap is large enough to turn a profit by itself, but keeping the features and form factor while upgrading the SoC (much like you would in a PC) has been a pipe dream for a lot of people. Time will tell, I guess.

It would be nice to be able to take your decommissioned Pyra Handheld SoC board and stick it in a Pyra Phone with a lightweight OS when a new SoC board comes around though.
 
I wouldn't expect the Pyraphone to be significantly modular against what it gains from the Pyra to begin with (which is a pluggable CPU board and seemingly software controllable switches enabling specific modules). That might be enough for you, and I don't know if it'll have any kind of camera.
 
I wouldn't expect the Pyraphone to be significantly modular against what it gains from the Pyra to begin with (which is a pluggable CPU board and seemingly software controllable switches enabling specific modules). That might be enough for you, and I don't know if it'll have any kind of camera.
Funny enough the OMAP5 has a lot of Camera inputs I think 4 depending on usage of the MIPI interface, it's an automotive SoC so intention was for it to run cameras in a head unit, just the Pyra isn't making use of any of them.
 
@Lao Rebel Contact E.D. privately. Try to find the exact timedate of your transaction. And if you still have the same bankaccount, maybe send a euro E.D. way with a code (previously defined by ED) in the description to "validate" it's you.
@levi lol. I never got such email.. always assumed ED was too busy. (dont worry, if I log into the dragonbox.de webshop it's all there properly registered)
 
Last edited:
Back
Top