Production Pyra photos/videos/thoughts thread


The newer display boards use a much faster PWM frequency (8.3kHz). Based on the backlight driver chip (TPS61169DCK) datasheet, there is essentially a low pass filter inside so this gives true-analog backlight control by changing the setpoint current rather than actually turning the LEDs on and off.
 
After my Pandora had an issue whit its Backlight Controll, which was gone some hours bevore i accidently trow it on the Floor, which causes the Backlight to fire up on full power all the time it was on, and it was uncontrollable.. its nice to hear, that the Pyra will get a decent backlight controll ..
 
My Work Jeans Shorts dos have Buttons on the "Hosenstall" (Pants Stable), and they are a bit thight to close as its a pretty though Jeans Material,
So i can close this Pants in Darkness, but not that easy as if it would have a "Zipper" ^^

But therefore, there is a Zipper in the "Pandora/Pyra" Pocket,
 
Neelix said:
*shrugs* I don't specifically have anything against them myself, though I do prefer to wear jeans during my waking hours. The quote however always struck me as funny and as such it stuck in my head.

-Neelix
Click to expand...
It does not matter anyway. Drawstring pants cannot go back into style again because they never went out of style.
 
levi said:
Probably because you had your phone/other camera device oriented pointing down, the accelerometer in it got confused. I'm not sure what this looks like on your camera device of choice, so no suggestions on how to stop it happening in future, although if I remember properly, ffmpeg can rotate videos in a jiffy if you spot that mistake prior to posting it.
Click to expand...

whoopsies I’ll keep an eye on that in the future. Thanks for the ffmpeg tip forgot about that tool. I’ll probably need to use it when I get around to working on splash screen.
 
Will it be easy to make it just show boot lines? I couldn't disable the boot splash on the Pandora.
 
Silent-Hunter said:
Will it be easy to make it just show boot lines? I couldn't disable the boot splash on the Pandora.
Click to expand...
I mean that’s what it does now so it’s pretty easy :) I haven’t really started to look into the splash screen on the bootloader yet. I think ED said there’s no display driver in uboot for the omap5 so that’s definitely a waste of effort at this point. Kernel should be doable but there’s a number of priorities before that to get resolved
 
daveshah said:
Here are some instructions to try (I haven't actually tried them verbatim yet so expect problems...).

If you aren't on Buster already, you can start from this image: https://packages.pyra-handheld.com/rootfs/buster/mate.img.7z

Run:

Code: 
sudo apt-get update
sudo apt-get install linux-image-5.6.15-letux-lpae-dave dri3wsegl-pyra xserver-xorg-video-armsoc-omap5

Reboot, and replace /etc/X11/xorg.conf.d/10-fbturbo.conf with the following content (you will need to be root to edit this file):

Code: 
Section "Device"
    Identifier    "Pyra  FBDEV"
    Driver        "omap5"
    Option        "DRICard" "2" # must point to the /dev/dri/cardX corresponding to omapdrm because detection can sometimes fail
    Option        "DriverName" "omapdrm"
    Option        "SoftEXA" "false" # will disable etnaviv acceleration. CPU only EXA is actually faster, but let all the work to A15 core
    Option        "TilerRotation" "270"
EndSection

Finally, reboot again, and you will now have 3D and X11 playing together. Download a gl4es build from ds0.me/libGL.so.zip and extract it somewhere (for the sake of below, /home/david/gl4es).

Then, in a terminal, run

Code: 
export LD_LIBRARY_PATH=/opt/omap5-sgx-ddk-um-linux/lib/:/home/david/gl4es DRI3_VSYNC=1
glxgears

Make sure that glxgears runs smoothly. If you are connected over SSH or serial, rather than a terminal window on the Pyra itself, you will need to add DISPLAY=:0 XAUTHORITY=~/.Xauthority to the export command.

Finally, in the same terminal, run SuperTux:
Code: 
sudo apt-get install supertux
/usr/games/supertux2

Let me know how you get on with this :) I do apologise that it isn't as user-friendly as it could be, but it's still a work in progress.

Addendum:
- when I say reboot, I really mean "turn off and on again", soft reboots are still in the progress of being fixed and a patch isn't included in that kernel yet
- if you get spurious '+' button presses, run "sudo rfkill block wwan"
Click to expand...

I got through the step for replacing /etc/X11/xorg.conf.d/10-fbturbo.conf with the contents provided. I did that step on my Linux workstation so I could just copy/paste the contents in. The next boot on the Pyra resulted in getting stuck in the boot process. Removed battery, restarted, same issue. I can try to get Minicom working again if we need it. The following is what is on the 'stuck screen'. Marble is my name for my Pyra. I'm typing this in, and this text on the Pyra is an eye chart, so please excuse typos.

Debian GNU/Linux 10 Marble tty1

Marble login: [ 20.807835] wlcore: PHY firmware version: Rev 8.2.0.0.242
[ 20.904400] wlcore: firmware booted (Rev 8.9.0.0.79)
[ 20.922144] wlcore: down
[ 21.402970] wlcore: PHY firmware version: Rev 8.2.0.0.242
[ 25.948722] wlcore: down
[ 29.949722] wlan0: authenticate with ((big hex code))
[ 29.993508] wlan0: send auth to ((big hex code))
[ 30.028856] wlan0: authenticated
[ 30.041232] wlan0: associate with ((big hex code))
[ 30.067395] wlan0: associated
[ 30.162074] IPv6: ADDRCDNF(NETDEV_CHANGE): wlan0: link becomes ready
[ 30.17387] wlcore: Association completed.
[ 34.401101] host1_vbus_power: supplied by modem_vbus_hdmi_power
[ 34.409538] host2_vbus_power: supplied y modem_vbus_hdmi_power
[ 34.421938] ldo3: disabling
[ 34.425074] ldo8: disabling
[ 34.435074] otg_path: disabling
[ 152.982463] bqbq2429x_charger 1-066b: bq2429x_usb_detect: r8=b4 ADAP CHGTERM PWGOOD r9=80 WDDG
[ 153.530485] bqbq2429x_charger 1-066b: bq2429x_usb_detect: r8=ac ADAP FCH6 INDPM PWGOOD r9-80 WDDG
[ 194.065548] bqbq2429x_charger 1-066b: bq2429x_usb_detect: r8=00 r9=80 WDDG
[ 194.073214] bqbq2429x_charger 1-066b: bq2429x: VBUS became unavailable

The last line appeared when I disconnected the power to bring it over to the desk so I could try to type all that.

Any ideas?


Oh - and I just noted that it was not 'completely frozen' in that state. Touching the power button flashed the usual shutdown text and then the unit powered down.
 
Just a note - I want to help test stuff - but I also don't want to waste your "Pyra Time" by doing tech support for my benefit. If it is easier to say, 'wait for the next round of release', that is fine too.
 
No, it's very useful to have this stuff beta tested before 100s of people are playing with it!

Minicom is probably going to be needed (as the wireless seems to be working, if you know the IP address it should also be possible to ssh into it.)

To find out why X11 isn't working, the output of `cat /var/log/Xorg.0.log` should be insightful. You don't need to post the whole thing, just however many lines at the end reference some kind of error or problem.
 
In case it's just X11 not starting, switching to a virtual console by e.g. Ctrl+Alt+F4 (or on Pyra Ctrl+Alt+Fn+4) might work too for checking /var/log/Xorg.0.log and modifying /etc/X11/xorg.conf.d/10-fbturbo.conf.

Edit:
Grench said:
Debian GNU/Linux 10 Marble tty1

Marble login:
Click to expand...
I haven't noticed before: The boot was actually successful. You can just login with username and password. And then 'cat /var/log/Xorg.0.log'. The last few lines should give a hint what's wrong.
 
Last edited:
  • Like
Reactions: rSl
There is a known bug which causes freezes. I’ve encountered it a couple times, it happens randomly and semi-frequently (maybe once every day or 2). daveshah has found it to be related to the power state code. This could be what you’re experiencing, though I’m not sure. I’m pretty sure a symptom of that bug is full CPU lockup in which case clean shutdown would not be possible.

it’s VERY useful to have others in the field finding and reporting bugs. The more tests are run, the more data we have and the easier it is to track these bad boys down n fix em.

it’s also possible that the bug is related to the charger driver. Maybe it’s just because that’s where my headspace has been, but I’ve experienced a lot of weird behavior in the driver that I’m still fully characterizing. I have seen the work queue which manages updating the charger state lock up, so it’s possible you hit a particularly bad one where the IRQ triggered at the same time as the polling detect and both locked up running in separate cores. I’m hoping to have fixes for this driver merged in soon but it’s involving quite a lot of work.
 
Annoyingly, think there might actually be two lockup bugs.

The first, probably more commonly observed on the Pyra, is probably indeed charge driver related. I did notice a bit of a correlation too early on between lockups and charger events but I'm not 100% sure.

There is also the power state lockup bug. I haven't actually confirmed this affects the Pyra because I don't have JTAG yet; but as I have seen two or three lockups without a charger connected I suspect it does. So far I have mostly been debugging this one on the uEVM as JTAG is a bit less fidly, this also removes a number of drivers like the charger one from the equation which simplifies debugging.

Incidentally, you can tell if the device has actually locked up, rather than just X11 not working, by seeing if the red lid LED is still blinking.
 
Last edited:
daveshah said:
The first, probably more commonly observed on the Pyra, is probably indeed charge driver related. I did notice a bit of a correlation too early on between lockups and charger events but I'm not 100% sure.
Click to expand...
There's definitely some sort of hangups happening in there. I think due to the way the mutex is handled in the usb_detect function (called when IRQ or polling event occurs). The mutex wraps a large amount of logic and I2C transactions and there's a lot of action on the bus IIRC. It could be hanging waiting for other drivers on the bus to be serviced. I notice if I plug and unplug the OTG USB multiple times, often I get no events for a number of seconds, sometimes minutes. Then all of the queued work occurs at once. Its possible that there is a deadlock in here that sometimes occurs and locks up both cores forever. My rewritten driver didn't experience this bug, likely because the equivalent of the usb_detect function was much less busy. Just grabs the status and fault registers, wraps the saving of this data in a lock, and notifies the power_supply subsystem of change.

daveshah said:
There is also the power state lockup bug. I haven't actually confirmed this affects the Pyra because I don't have JTAG yet; but as I have seen two or three lockups without a charger connected I suspect it does. So far I have mostly been debugging this one on the uEVM as JTAG is a bit less fidly, this also removes a number of drivers like the charger one from the equation which simplifies debugging.
Click to expand...

We have JTAG on the Pyra? What controller are you using? I should probably set this up.
 
daveshah said:
No, it's very useful to have this stuff beta tested before 100s of people are playing with it!

Minicom is probably going to be needed (as the wireless seems to be working, if you know the IP address it should also be possible to ssh into it.)

To find out why X11 isn't working, the output of `cat /var/log/Xorg.0.log` should be insightful. You don't need to post the whole thing, just however many lines at the end reference some kind of error or problem.
Click to expand...
Alright. I was able to hit enter and get to a login - and log into it from command line. I have something for you from Xorg.0.log.

(II) LoadModule: "omap5"
(WW) Warning, couldn't open module omap5
(EE) Failed to load module "omap5" (module does not exist, 0)
(EE) No drivers available.
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult theThe X.Org Foundation support
at http://wiki.x.org
for help
(EE) Please also check the log file at "/var/log/xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.

So - any chance I'm just missing a file?
 
You must log in or register to reply here.

Similar threads

Wally
Pyra first Run Wizard
Replies
12
Views
4K
Christoph.Krn
Christoph.Krn
EvilDragon
Pyra Prototype Videos - Askarus Edition
2 3 4
Replies
63
Views
23K
MrLimatex
MrLimatex
L
Creating an "empty" OS for the pyra
2
Replies
24
Views
8K
levi
levi
Orz
My Thoughts on the Pyra
3 4 5
Replies
91
Views
11K
levi
levi
Gren
Early Pyra Impressions
Replies
7
Views
2K
matzesu
matzesu
Back
Top