First information for new Pyra owners (FAQ)

[EvilDragon]

This is a quick information about the currently state of issues (software). I'll update this page when new things will be reported, so keep an eye out here

Hopefully, we'll find some more devs who will help improve everything in the future. At the moment, the Pyra is not really usable for gaming, but that will change.

The first thing you should do is connect to the internet and update your unit!
Either using Synaptic or using apt update && apt upgrade

This will already fix some bugs!

1. The Pyra does not boot if there's an SD Card in the left slot

The left SD Card slot has the highest boot priority. The OMAP5 does a quick check for some special bytes to determine if it's bootable or not. Some (even brand new) SD Cards have these bytes and are falsely detected as bootable card. Therefore, the OMAP5 tries to boot from it and fails.
Reformatting / Repartitioning the card fixes that.

2. 3D games run dog slow

While hardware accelerated 3D does work in theory, it hasn't been properly integrated into the OS (packaging the whole thing as Debian package is not that easy).
Therefore, GL4ES (the OpenGL -> GLES wrapper by ptitSeb) is not currently included - which forces all 3D games to use the MESA Software 3D.

3. SDL Games don't run proper fullscreen / are also very slow

Due to the fact that we're using a portrait display rather than a landscape one (these are only readily available with up to 800x480), TILER does some low-level hardware rotation.
Fullscreen SDL isn't aware of that - and therefore, doesn't work properly.
Windowed SDL works fine, however, scaling is purely done in software, so it will need a LOT more CPU than it should and slows the system down immensively (which means that a lot of stock emulators installed from the Debian repo heat up the unit and only achieve a few FPS.
Ideally, SDL should support hardware scaling via TILER - or we should mostly concentrate on software using SDLv2, as this can use OpenGL (and therefore, scale in fullspeed once the hardware OpenGL is properly integrated).

The fullscreen fix shouldn't be too hard to achieve, hardware scaling is probably more work. If someone wants to take on SDL and create a Pyra optimized version, let me know

4. The unit becomes slower and slower over time / charges slower

The system has a small temperature daemon included that changes the CPU speed and allowed charger input.
However, the preinstalled version has a bug - it lowers the speed / charger, but doesn't increase it anymore if the temperature is lower again!
Upgrading the system via apt will fix that.

5. I have issues charging the unit - the red light starts to blink regulary!

The red light means that there is some error reported with the battery. Usually, that would be a too hot temperature, so charging is disabled until the temperature is low enough again.
This especially happens when the unit is switched on and running. You can still keep charging it, but it will take a bit longer.

There is also a small bug in the charger driver that will sometimes report an error as well - even if everything is fine. This rarely happens, so debugging it is not easy.
Charging currently works best when the unit is powered down via the USB-OTG port.

6. Rebooting the unit doesn't work

Some driver is stuck - so rebooting has some issues. Power off and switch on again is the better way right now.

7. My USB3 device doesn't work

The blue port is not an USB3 port with the current CPU board - it uses the additional connections for SATA.
Usually, USB3 devices shouldn't care about that and simply switch to USB2 mode. However, it seems that some care and simply refuse to work.
Simply use the other USB port for these devices at the moment.
It could be that simply disabling the SATA driver will fix that issue, but we haven't tried it yet.

8. HDMI doesn't work properly

Somehow, HDMI is also affected by the TILER rotation. This didn't have the highest priority for us yet, but it's something that should be fixed in the future.

9. The speakers don't switch off when I connect a headset

Audio is still a heavy work in progress right now. Unlike older devices where you simply had one audio stream which is cut off by hardware if you connect headphones, this one has multiple streams at once that can be used with Pulseaudio.
So it's possible to play music via headphones and run an emulator on the speakers.
This needs quite a bit of setup though, and while PulseAudio has been properly configured, the hardware stuff hasn't fully been implemented.
Therefore, the audio switch inside the headphones port doesn't enable / disable audio for the speakers at the moment, and the volume control daemon also needs quite a few improvements.

10. The nubs seems to be stuck / the mouse moves slowly into one direction

Unless it's really physically stuck (which we usually test here, but it could be we miss one), then it's a tolerance issue.
The magnet / nub location has a bit of a tolerance in placement (0.1mm) which changes the deadzone.
We had set up a very tight one - so it reacts on some units even though the nub isn't touched.

This has also been fixed already, so using synaptic / apt to upgrade your system should fix that.

11. Where do I put .dbp files from the repository on the SD Card?

The dbp files go into /dragonbox/packages
The files will automatically create their config files in /dragonbox/appdata

We do NOT have a package download manager like PNDManager on the Pandora yet, so you need to download and copy them there manually.

That should be mostly it for the moment. Let me know if you stumble across any other issues / have further questions.

12. How can I recover the unit in case I broke the OS?

Reflashing the unit is easy! All you need is an empty SD Card (at least 4GB size)

Extract that 7z file to get an .img file

1. Grab the latest install image from https://packages.pyra-handheld.com/images/buster/
   Install images are currently named "testXX-install.img.7z"
2. Unpack that image.
3. Write that image file to an SD card with something like etcher, Win32DiskImager or simply dd.
   Please note: This will delete all content on that SD Card! Be sure there's nothing important on it!
4. Insert SD card into Pyra left SD card slot
5. Power on, and it should start flashing.
   Please note: The OS will be reflashed without any further notice. Any data you have on the internal eMMC will be fully deleted!
   If you want to backup some data from the eMMC first, you can flash the "testXX.img.7z" onto your SD Card. That will change the SD Card into a bootable OS. You can then boot from the SD Card and access the eMMC to backup your needed data. After that, follow the process to reflash.

 

[TrashyMG]

2) I think there is something not working properly on the current OS image that prevents even regular GLES 3D acceleration from working, but will need others to confirm if it's just my unit.

3) this I feel should be a high priority

Also to add, I feel there should be some work to get a similar Pandora like system tray utilities that can enable and disable hardware like Wifi and Bluetooth to save power.

 

[pyrat]

This needs quite a bit of setup though, and while PulseAudio has been properly configured, the hardware stuff hasn't fully been implemented

You mean software/config for the hardware right ? Drivers, device trees or something than should read the headphone switch and inform pulseaudio and friends ?
hardware not being implemented sounds like the switch is not connected to any SOC input or something, but that could not be fixed later and you say "at the moment". So I'm guessing it's just software.

 

[EvilDragon]

You mean software/config for the hardware right ? Drivers, device trees or something than should read the headphone switch and inform pulseaudio and friends ?
hardware not being implemented sounds like the switch is not connected to any SOC input or something, but that could not be fixed later and you say "at the moment". So I'm guessing it's just software.

Yes, correct. The hardware itself is working, the switch also reports an event, but nothing happens with that event yet

 

[matzesu]

Ok one question on the sd cart: how do I know my SD Cart have this Boot Byte??
If I boot the Pyra whit booth Cards, and it’s Boots fine, this means I can let them in?

And wouldn’t make the internal Micro SD Slot makes more sense??

To update: just type „sudo apt update „ ?


Send from something, i guess ^^

 

[EvilDragon]

Ok one question on the sd cart: how do I know my SD Cart have this Boot Byte??
If I boot the Pyra whit booth Cards, and it’s Boots fine, this means I can let them in?

If the unit shows a black screen with a green LED on the lid, it means it tried to boot from the SD Card.
That's when you notice that the SD Card causes issues ,)

And wouldn’t make the internal Micro SD Slot makes more sense??

For booting? Yes, it would (especially as its the same MMC as the internal storage), but the OMAP5 doesn't allow an easy change of the boot order.

To update: just type „sudo apt update „ ?

And "sudo apt upgrade" afterwards.
The "update" only updates the package LIST, the "upgrade" upgrades the packages itself.

 

[matzesu]

Ah ok, but when I noticed the SD Card makes trouble: how do I shut down the Pyra savely? And then simply boot new whiteout the card??


Send from something, i guess ^^

 

[Cralex]

Ok one question on the sd cart: how do I know my SD Cart have this Boot Byte??
If I boot the Pyra whit booth Cards, and it’s Boots fine, this means I can let them in?

And wouldn’t make the internal Micro SD Slot makes more sense??

To update: just type „sudo apt update „ ?


Send from something, i guess ^^

If it boots correctly with a card in the left slot, then the boot bytes are not set. If not, then you could either use it only in the right slot, reformat it using a tool such as gparted on Linux, or use some sort of tool to set the card as “not bootable”.

With Linux systems that use apt, like the Pyra “sudo apt update” will cause the system to check what packages are currently available in the repository, and “sudo apt upgrade” will actually go and update the currently installed packages to the latest version. So you’d run both commands in that order to update the system.

There’s also programs available to update the system with a graphical user interface instead of the command line, such as Synaptic.


Sent from my iPhone using Tapatalk

 

[matzesu]

Ah ok, thanks for the kind answer,
Could be some of my questions are allready answered in the Pyra Manual, but I seems like I don’t have them yet..


Send from something, i guess ^^

 

[levi]

Charging currently works best when the unit is powered down via the USB-OTG port.

Tricksy wording here. I assume you can't actually turn the unit off using the OTG port, but you mean to charge the unit using the OTG port when it's already been turned off separately. Does it really charge better using the OTG micro USB 3 port than the dedicated charge (and debug) micro USB 2 port?

 

[EvilDragon]

Tricksy wording here. I assume you can't actually turn the unit off using the OTG port, but you mean to charge the unit using the OTG port when it's already been turned off separately. Does it really charge better using the OTG micro USB 3 port than the dedicated charge (and debug) micro USB 2 port?

He, you're right
The USB-OTG port is a "smart" port that negotiates with the charger how much power it can supply, whereas the Debug Micro USB2 port is dumb.
We increase the limit for the "dumb" port as well and the charger SHOULD save the disabled limit (and therefore it should charge as fast as with the OTG port), but as the software for the charger chip is in its early states, I cannot guarantee this works 100%.

The USB-OTG port with a proper charger will always negotiate the proper limit, even without the OS running at all.

 

[matzesu]

Ok but I can’t breake something when I put a Micro USB Cable in one of the 2 Ports, ?
And if my SD Card got this Boot Byte? Simply shootdown the Pyra and reboot whiteout?


Send from something, i guess ^^

 

[Autian]

Ok one question on the sd cart: how do I know my SD Cart have this Boot Byte??
If I boot the Pyra whit booth Cards, and it’s Boots fine, this means I can let them in?

If I'm guessing this right, the "boot" flag of partitions are meant.

So if you want to check this without trial and error on any system, you can try inspecting the partition flags with a partition manager if you have root permissions.

A couple of screenshots to get you started:

Spoiler

Start a partition manager, select the correct storage device and inspect the partition flags (the "esp" flag is UEFI related, so probably not relevant for the Pyra. And yes, the following examples are on a GPT partition table but this should still apply for MS-DOS partition tables as well):
Your card device node is probably named as either "/dev/mmcblk..." or "/dev/sd...". Make sure properties such as size, names, etc. do match.
You can try removing the boot checkmark of your card partitions and apply the changes, usually nothing should go wrong. Make backups if in doubt (you can mess up things pretty quickly if changes are not made carefully).
gparted:

partitionmanager ("KDE Partition Manager"; the "boot" checkmark is labeled "bootfähig" in German):

parted (CLI):
list all storage devices with their partitions

# parted --list

and if one of the partitions of your card does have boot flags set it will be shown in this manner (see Flags column):

Model: PNY CS3030 250GB SSD (nvme)
Disk /dev/nvme0n1: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
1      1049kB  269MB  268MB  fat32              boot, esp
2      269MB   239GB  238GB  ext4

 

[TrashyMG]

I don't think u-boot cares about boot flags at all, embedded systems behave a bit differently that standard PCs.

 

[EvilDragon]

I don't think u-boot cares about boot flags at all, embedded systems behave a bit differently that standard PCs.

It's the OMAP5 that tries to boot and hangs, not U-Boot.

 

[levi]

He, you're right

Maybe just switch around the phrase ordering then.
"Currently charging works best via the USB-OTG port when the unit is powered down."

 

[TrashyMG]

It's the OMAP5 that tries to boot and hangs, not U-Boot.

Right, but isn't what you choose to boot from decided in U-Boot? I'm just saying I've never seen boot flags used on any embedded device I've played with.

 

[Linux-SWAT]

Is serial out enabled on some Pyra port ?

 

[Letalis Sonus]

Right, but isn't what you choose to boot from decided in U-Boot? I'm just saying I've never seen boot flags used on any embedded device I've played with.

The OMAP5 first needs to boot u-boot before it can boot anything else. A lot of ARM SoCs nowadays have a hard coded bootloader (mask ROM) that may perform its own probing of possible boot devices first. If your own boot device is not on the top of the boot priority list stuff like this can happen. They usually expect a fairly complex boot image header format and should bail early if some things are not looking right, though. Writable on-chip flash for a bootloader is kind of old-fashioned now

 

[Silent-Hunter]

How is the mobile data and phone support? Is that usable yet?