Pictures, Videos and thoughts of a Pyra dev-prototype

[ible]

unless you're a gentoo fan, apt-getting most of the productivity/audio player stuff will be much simpler/quicker than building from source and enjoying maybe 10 or 20% day-to-day speed improvement.

it depends on what you're looking for, but i'd be interested in a comparison nonetheless .

 

[levi]

Debian's armhf target equates to ARMv7A+VFP as far as I know. The OMAP5 chip is a couple of ARMv7a CPUs gaffa taped together with some other stuff, so all of debian's packages should work fine. Admittedly they won't use all of the extra gubbins that's in the OMAP5, so some stuff will be better recompiled or hacked for our specific chip, but we'll have to wait and see how much extra that gives us.

As a rough guide, I'd expect us to be using firefox from the repo (or iceweasel specifically, that being debian's version of the same), if we choose that browser. HDonk's Pandora ports aren't as frequent as upstream ones, so I guess he'd be glad of not having to rebuild it every time mozilla spits out a build. We could use debian's mplayer build as our video player engine, or it may turn out building it for NEON and everything makes it better so we may get a DBP release of that, or a binary build pushed to our community debian repo. But I'd expect most of the games Ptitseb ports to be released as DBPs - if those games are even on the debian repo, those extra 10-20% that we might get from hand compiled code might mean the difference between a playable game and a borderline unplayable one.

 

[WizardStan]

Not to mention that games tend to carry fairly large data components which, if installed from the debian repository, could quickly fill up the internal NAND. DBP builds, like PND, would mean that data is kept wherever you want.

 

[Djoga'Ro]

@levi Firefox is dead. Long live Pale Moon!
Looking through the list of pre-builds for Linux on PM's sites I learned about the Pyra, btw.

 

[Swordfish II]

Debian's armhf target equates to ARMv7A+VFP as far as I know. The OMAP5 chip is a couple of ARMv7a CPUs gaffa taped together with some other stuff, so all of debian's packages should work fine. Admittedly they won't use all of the extra gubbins that's in the OMAP5, so some stuff will be better recompiled or hacked for our specific chip, but we'll have to wait and see how much extra that gives us.

As a rough guide, I'd expect us to be using firefox from the repo (or iceweasel specifically, that being debian's version of the same), if we choose that browser. HDonk's Pandora ports aren't as frequent as upstream ones, so I guess he'd be glad of not having to rebuild it every time mozilla spits out a build. We could use debian's mplayer build as our video player engine, or it may turn out building it for NEON and everything makes it better so we may get a DBP release of that, or a binary build pushed to our community debian repo. But I'd expect most of the games Ptitseb ports to be released as DBPs - if those games are even on the debian repo, those extra 10-20% that we might get from hand compiled code might mean the difference between a playable game and a borderline unplayable one.

Yeah, basically what I was thinking... In terms of ports and what not. I do hope they're is a dbp for Pale Moon, and optimized versions as necessary for everything else.

 

[sebt3]

I was also thinking about software. For instance Pandora has panplayer2. Would Pyra get its own video player or would it be vlc from the repo? Will mupen be compiled for the Pyra or will it be the repo version?

I realize a lot of this will be who decides to port things and/or who notices things need to be optimized for the Pyra. I'm not concerned, more curious.

Mupen will probably need a dedicated port as the debian one is build for OpenGL (not the ES version) and having mupen throw glshim seems like a very bad idea..
VLC from the debian repo will probably do fine until someone do an optimized build (a dedicated optimized build of libffmpeg could be good enough for a while too)

Unlike the pandora, when the pyra will be out, we'll already have most package for most stuff from the debian repo. The pyra debian repo will allow us to optimzed the debian packages. DBP will be for optimized builds (so probably mostly games and emulators).

 

[ptitSeb]

Yes, dbp will be for optimized port, and stuff not found on regular Debian repo (PaleMoon for example, not sure it's on Debian).

The optimise settings is a whole question.
There has been some debate in the Pandora, on the best C/C++ optimize flags.

On the Pyra, we have a cortex-a15 cpu, with Neon/vfpv4 and we are on hard float.
So, the minimum CFLAGS / CXXFLAGS would be

-mcpu=cortex-a15 -mfpu=neon-vfvp4 -mfloat-abi=hard

Now, fast-math can probably be added, as it may help with vectorizing some float math.
single-precision-constant may also be added, but I'm less sure of the effect of this one on the Pyra CPU, this has to be tested (and this one can have some negative effect on the building, requiring many sources adaptations).

What I also found out, is that, by default (at least on the gcc 6.3 that comes with the current OS on the Pyra), the compilation target "Thumb" mode. So while it's pretty much transparent on most software, for emulator having a JIT, it can be significant. So I'll force arm mode for my custom compile for now, and I'll add the thumb-interworking flag to stay on the safe side.

So for now, my current CFLAGS is

-mcpu=cortex-a15 -mfpu=neon-vfvp4 -mfloat-abi=hard -marm -mthumb-interwork -ffast-math -ftree-vectorize

 

[Pyramancer]

Not to mention that games tend to carry fairly large data components which, if installed from the debian repository, could quickly fill up the internal NAND. DBP builds, like PND, would mean that data is kept wherever you want.

To avoid that limitation, could one not simply move one's /usr file system somewhere else? To a card in the internal microSD slot, perhaps, would be most convenient.

 

[EvilDragon]

To avoid that limitation, could one not simply move one's /usr file system somewhere else? To a card in the internal microSD slot, perhaps, would be most convenient.

Sure, but then the OS will stop to work when the SD Card is gone and needs to be fully reflashed.

 

[sebt3]

To avoid that limitation, could one not simply move one's /usr file system somewhere else? To a card in the internal microSD slot, perhaps, would be most convenient.

That's an option open to anyone willing to toy with this solution. yet that mean your SD card will be mandatory for your pyra...

EDIT: ninja'd in the worst way possible

 

[Pyramancer]

Sure, but then the OS will stop to work when the SD Card is gone and needs to be fully reflashed.

Hi EvilDragon. By "gone" here, do you mean removed from the Pyra. Or do you mean dead, as in worn out from too many writes. For the former problem, that's why I was thinking of the internal slot -- I'd put a fairly large card in there and leave it in forever as a sort of equivalent of a hard drive. For the latter problem, I would have made backups (I hope!). But yes, these problems are the trade off, I think, between the convenience of permanent storage, and the need for more space.

 

[EvilDragon]

Hi EvilDragon. By "gone" here, do you mean removed from the Pyra. Or do you mean dead, as in worn out from too many writes. For the former problem, that's why I was thinking of the internal slot -- I'd put a fairly large card in there and leave it in forever as a sort of equivalent of a hard drive. For the latter problem, I would have made backups (I hope!). But yes, these problems are the trade off, I think, between the convenience of permanent storage, and the need for more space.

Both. Whenever the card is missing and /usr is gone, the OS won't work anymore.
The reason WHY the card is gone is irrelevant.
Sure, if you just removed it, putting it back in should make it bootable again, so that's better than a died card.

 

[Pyramancer]

Both. Whenever the card is missing and /usr is gone, the OS won't work anymore.
The reason WHY the card is gone is irrelevant.
Sure, if you just removed it, putting it back in should make it bootable again, so that's better than a died card.

Yup. All true. I just don't plan to remove the card. [If I do remove it in a fit of absent-mindedness, well, then I just get what I deserve!]

 

[oskda]

I'm not sure we even have HDMI enabled in the OS yet... It's still VERY very young.

Sent from my XT1650-03 using Tapatalk

EvilDragon: can we know Pyra weight? (with or without battery)

I search for Pyra weight and I find no information. I suppose in this stage we can know weight in a good precise way.

 

[PokeParadox]

Both. Whenever the card is missing and /usr is gone, the OS won't work anymore.
The reason WHY the card is gone is irrelevant.
Sure, if you just removed it, putting it back in should make it bootable again, so that's better than a died card.

O/T but could you do this as a sort of physical key to use the Pyra (or even Pandora for that matter)!

 

[Swordfish II]

Mupen will probably need a dedicated port as the debian one is build for OpenGL (not the ES version) and having mupen throw glshim seems like a very bad idea..
VLC from the debian repo will probably do fine until someone do an optimized build (a dedicated optimized build of libffmpeg could be good enough for a while too)

Unlike the pandora, when the pyra will be out, we'll already have most package for most stuff from the debian repo. The pyra debian repo will allow us to optimzed the debian packages. DBP will be for optimized builds (so probably mostly games and emulators).

Certainly understand that. I'm just curious where we end up if that makes sense
[doublepost=1498757554,1498757493][/doublepost]

Yes, dbp will be for optimized port, and stuff not found on regular Debian repo (PaleMoon for example, not sure it's on Debian).

The optimise settings is a whole question.
There has been some debate in the Pandora, on the best C/C++ optimize flags.

On the Pyra, we have a cortex-a15 cpu, with Neon/vfpv4 and we are on hard float.
So, the minimum CFLAGS / CXXFLAGS would be

-mcpu=cortex-a15 -mfpu=neon-vfvp4 -mfloat-abi=hard

Now, fast-math can probably be added, as it may help with vectorizing some float math.
single-precision-constant may also be added, but I'm less sure of the effect of this one on the Pyra CPU, this has to be tested (and this one can have some negative effect on the building, requiring many sources adaptations).

What I also found out, is that, by default (at least on the gcc 6.3 that comes with the current OS on the Pyra), the compilation target "Thumb" mode. So while it's pretty much transparent on most software, for emulator having a JIT, it can be significant. So I'll force arm mode for my custom compile for now, and I'll add the thumb-interworking flag to stay on the safe side.

So for now, my current CFLAGS is

-mcpu=cortex-a15 -mfpu=neon-vfvp4 -mfloat-abi=hard -marm -mthumb-interwork -ffast-math -ftree-vectorize

Pale moon is not on the repo, had to compile it myself for a different machine

 

[_jr_]

NB: Has someone successfully run a debug build of Palemoon? It's asserting left and right for me, and some of these asserts (like in the JS engine) really do worry me. Is it just my configure options?

 

[Kev2442]

@ptitSeb : About saturday, how long will you stay ? If I go there, I might only get there at about 18:15. Is it still okay to have a nice chat and a grab at a Pyra ?

 

[ptitSeb]

I don't know yet, I haven't planned much, but I'll try to stay around yes.

 

[WizardStan]

To avoid that limitation, could one not simply move one's /usr file system somewhere else? To a card in the internal microSD slot, perhaps, would be most convenient.

If you're going to go that far you may as well go a little further and mount the internal uSD as an overlay. You can install the base OS onto the internal NAND, mount the uSD with read/write over top of it, and then install whatever you want and it all goes to the uSD card. If the card goes bad or you feel like something in the OS isn't working right you just disable it (remove it) and the NAND goes back to stock.