Pyra Question


StopPlayingKidz

Still Fresh
Joined
May 19, 2015
Messages
7
HI everyone,
This is my second post and I'm getting ahead of myself. But searching the amounts of possibilities that occurred to the OpenPandora in the terms of software, my question is specifically, could it be possible to dual boot Android or say Steam OS (from my knowledge I doubt Steam OS could run, but curious of the possibility and technicalities)? Not sure if my post makes sense but I'm just curious. Thanks peeps
 
I will let one of the pro nerds give a more complete answer, but yes it will be possible... with a not insignificant amount of hacking.

You would be better off waiting (or assisting) on getting Android apps running under Debian... or using a vm.

Simple answer: no. Not out of the box... and if you don't have the capabilities yourself, it will be a bit of a gamble to see if there is a dev or two within the community who is keen enough to bring it about.

Pyra is sure to bring more meat into the flock though, so you can expect a greater potential for this.
 
As FaeMinx already explained, Android is a maybe with a big tendency to yes - someone has to do the work, there is already one dev reporting some progress in get things going, wether he will continue his efforts and actually tries to get it to run on the Pyra, remains to be seen.
Technically SteamOS could run on the Pyra as its an adjusted Linux distribution with standard components. But the Steam client is made for x86 PCs not for the ARM plattform the Pyra uses and so are the games that you can get over Steam.
There are some efforts from forum users, to utilize Exagear (= run x86 software on ARM), to run Steam on the Pyra, but it also remains to be seen what games will be playable in this setup
 
Interesting stuff peeps. From what I know and the research I've done, Android phones or tablets processors are ARM, the vast majority is my assumption. Makes sense that Pyra would need a Android port. As of Steam OS, I had my doubts since it is mainly supported for pc's. That's why I was curious. But I still wanted to know whether dual booting would be similar to pc's as in modifying the BIOS secure boot and installing an IMG or ISO to a flash drive. Without going to the step by step point, will the pyra be capable to dual boot in the terms of software currently. Or does the Pyra need to support dual booting. I'm trying to sound as if I know what Im saying peeps. I'm a newb clearly so hope you peeps understand what I mean.
 
The Pyra wil definately be able to boot more then one OS > as the Pandora, she will sport a boot menu where you can choose which one you want. But it won't work as you are used on a regular PC. You will have to prepare an image of the OS you want to boot (or use a premade one if availalable), that you put either on a card in the internal MicroSD or one of the external SD-Card - slots
 
^ in theory, you could even multi-partition the NAND and boot multiple OSs directly from the NAND. Not sure why you'd want to - but it's there.

ED even rumored that there may be a way to have the boot menu give a choice including NAND/microSD switching. So, theoretical boot options could theoretically point to any partition on any of these:
NAND
microSD
left SD
right SD
USB3.0 OTG
left USB
right USB

Does the WiFi chip allow for network boot?
 
U-Boot can boot over Ethernet, but configuring the Wifi from U-Boot isn't possible i think. Also you forgot the Esata Port.
 
Last I heard, there was a physical, mechanical switch that selects either the µSD slot of the built-in eMMC mmory, so that cannot be handled in software (?)
 
Got a quote for that? I remember that that was the original assumption, based Nikolaus' description of how the overloading worked, but I seem to recall that the first actual mention of the switching mechanism by either ED or Nikolaus mentioned it being selectable in the bootloader.

-Neelix
 
It's a switch, but it's digital, so it can be changed via software.
In theory, you could even write a driver that handles switching between both the MicroSD Card slot and the MMC, so that both can be mounted at once.
 
As long as you don't expect to use both literally at the same time, like copying between them, or running apps from either one.
 
I think the proposed driver switches between them at such a speed that as far as the OS is concerned they're both present all of the time. I guess, like old computers with only one disc drive, copy routines actually read a chunk of data into RAM (though probably over DMA these days) and then squirt it out to the other disc, after you've ejected the first one and inserted the second. So perhaps they don't actually need to be present simultaneously ever.

It's all just a wild theoretical driver at the moment though. Experiments will need to be done to see if it's at all feasible.
 
think the proposed driver switches between them at such a speed that as far as the OS is concerned they're both present all of the time.
Yes, but it's still going through a single bus. In addition to the overhead of switching and synchronizing, trying to use both simultaneously, speed will be atrocious.
 
Yes, but it's still going through a single bus. In addition to the overhead of switching and synchronizing, trying to use both simultaneously, speed will be atrocious.

Atrocious depends a lot on the perspective. The eMMC is capable of up to 208MB/s. The uSD is capable of up to 104MB/s. Both theoretical. However, assuming that we're getting half (for switching) of half (for reality) speed through each of them, and correcting down for the slower of the two interfaces, we're still talking about a 25MB/s data transfer.

The Pandora maxed out around 18MB/s.
Gigabit ethernet speeds through common switches runs 50MB/s give or take.

So - in this case 'atrocious' is something in between those ranges - which is, frankly, 'good enough' on the rare instances where someone would want to copy large amounts of data between an 8GB +/- NAND flash that should be OS reserved and an on-device long term storage, that in theory, would be rare to access at the same time as the OS unless you booted from it - and then a similar device contention would exist.

I REALLY like the switching solution that ED is theorizing. Even if, during simultaneous operations from NAND + uSD it dumps the performance down to 1/4 or even 1/8 normal,. that should be a rare-ish need. Making it possible at all is VERY cool.
 
I wonder if @TrashyMG was able to run some VMs on the devboard... I know, it's not like dual-booting but...
 
I wonder if @TrashyMG was able to run some VMs on the devboard... I know, it's not like dual-booting but...
Never got around to it, as my Devboard appears to be dead. Not entirely sure what happened, but I can't get it to boot or get any response from the serial device. I discovered it frozen and garbled display, it didn't boot after that.
 
Never got around to it, as my Devboard appears to be dead. Not entirely sure what happened, but I can't get it to boot or get any response from the serial device. I discovered it frozen and garbled display, it didn't boot after that.
Is it still covered by warranty? Hope you didn't fry it or anything...
 
Back
Top