Production Pyra photos/videos/thoughts thread


So what are the options? One is loading it in the initramfs (which I think it loaded by the bootloader or something rather close to it) and the other is doing it in the bootloader itself? I guess doing it in the initramfs will be slower to start charging, because it need to load the initramfs of a potentially slow SD card, but then again the initramfs is only in the order to 8MiB or so I assume, which could take as long as two seconds on an old class 4 card but in all likelihood probably won't. But I'm still tending to support the idea of doing it from the bootloader, because it seems simpler.

Boot process is as follows:
1. USB power is presented on microUSB or the power key is pressed. This causes the PMIC to begin its powerup procedure. It is unavoidable that both of these events trigger a powerup, that is how the hardware is configured.
2. BootROM begins executing and tries to locate the SPL (primary bootloader). If it finds it, it loads it into OCRAM and jumps to the start vector. It will first search the left SD slot, then eMMC/uSD.
3. SPL does basic device configuration setting up some necessary clocks and most importantly configure the SDRAM and load the full bootloader U-Boot into SDRAM and jump. I've modified the SPL to also reset the charger chip and bump up the input current limit to 3A at this point. While the SPL is running, most of the system is off and the SOC is running at a low clock speed. This keeps us under the 500mA limit which is the default input current limit on the charger chip. Once this is bumped up, we are safe to turn on other devices and start consuming more power.
4. U-Boot does all configuration of the SOC necessary for booting, loads the kernel, initramfs, and device tree into RAM and jumps to the kernel start vector. It does some other boring but important stuff, like check the HW revision number to load the right device tree, handle some logic for the eMMC/uSD, and further configure the charger chip/PMIC.

The two options for handling the charging without booting are:
1. Handle charging in the bootloader. If we detect the battery is below some threshold (read the fuel gauge chip) or that we have not booted by user request (warm reset or power button), then we can sit and hang in the bootloader after we've configured the charger. Here we can display the charge level by modifying the color of an LED (red=low, orange=ok, green=good). In the future, I could potentially append this to have display feedback depending on level of effort and priorities (or someone else can do it too :)). While in this state, if the user presses the power key and we are above charge threshold, we will continue to boot (at this point we have not loaded the kernel). Otherwise we hang here, periodically checking the battery level and status of the power input (power off if removed). In this state, we will be consuming less power than with a fully or partially booted kernel, as most things are still turned off. (though we may have some things turned on and unconfigured, which may be worse. need to check this out).

2. Handle charging in the initramfs. When we boot the kernel, the initramfs is used as a filesystem before mounting the actual rootfs. There are some configuration scripts which run here, but the kernel is fully booted with the exception of kernel modules. We could add a script which checks the battery level and halts the process if we are below threshold until we are above. At this point we have the benefit of most kernel drivers up and running, so we can (I believe) do display feedback out of the box and we'll be running with the full kernel driver for the fuel gauge and charger chip rather than the minimalistic ones in the bootloader. However, we need to fully boot the kernel (just the kernel, not the OS) to get to this point. Also to make use of this feature, you must be using our initramfs. The initramfs is not necessary and some users may use a custom boot process which bypasses this.

Option one is currently WIP. Option 2 I hadn't considered until this conversation.
 
I guess the benefit of option 2 is given you've loaded a kernel in the initramfs, giving you all of that development goodness and as you say you can even bring up the display if it makes the most sense to do that. I guess that's what most phones do. But if you can do it earlier in the boot and stop if booting any further, that does sound more efficient. I'd forgotten these were full RGB LEDs so three colours sounds good to me.

I wonder if we need to consider how this interfaces with the use of LEDs when the system is booted. I guess less information is needed there, since the screen should be active and you can look there to see remaining time to charge and things like that, but it might be nice to replicate the same colour changes on one of the LEDs so we can check with half an eye open when we wake up, if we've left it compiling something and plugged it in overnight.

Out of interest, do you know what the LEDs are doing at present? While it's pre-kernel it looks to me like it's doing a light show they has no other informational use whatsoever, but I'm cool with that. After the kernel boots it looks like it switches to indicating file system activity on the left light only.

On Pandora we had lights viewable from either inside or outside that indicated wifi, bluetooth, left and right SD card activity, charge and power and perhaps other things I've forgotten, but I'm pretty sure activity of the internal flash wasn't indicated at all, so that can be considered an improvement. It was useful on the Pandora because you generally wanted to turn off wifi and bluetooth overnight when you weren't using them, but I guess times have changed, and you're less likely to be bothered about leaving those on when the system isn't in use for a few hours.

I guess this isn't anything you're too interested in at the moment. As I say there many not be much value in aligning it with system live colours, and I can't even decide what would be worth showing. I guess it might be best to leave a lot of this stuff configurable to the user, but I guess at the end of the day we need a default.
 
  • Like
Reactions: rSl
Fn should be mappable, AFAIK it's all software mapped using funkeymonkey.

There is a lingering problem with relying on funkeymonkey for the mappings though. Funkeymonkey only kicks in after the graphical desktop launches. If you're ever booting straight to a command prompt, many of the Fn layer keys are missing mappings. My thought is that every symbol printed on they keymat should exist already even at a command line boot and that funkeymonkey should be allowed / able to override those mappings once the DE has launched. Thoughts?
 
There is a lingering problem with relying on funkeymonkey for the mappings though. Funkeymonkey only kicks in after the graphical desktop launches. If you're ever booting straight to a command prompt, many of the Fn layer keys are missing mappings. My thought is that every symbol printed on they keymat should exist already even at a command line boot and that funkeymonkey should be allowed / able to override those mappings once the DE has launched. Thoughts?
Funkeymonkey does run before X11 starts, the problem is that the some of the resulting keycodes it produces are currently only being interpreted correctly by X11; the console keyboard probably needs to be configured correctly to understand these (or funkeymonkey needs to be modified to produce console-compatible keycodes, I don't know which way is best).
 
Hmm, that's something I've never noticed before. The keyboard on this machine is pretty much limited to english characters and computer punctuation. Whenever I need something more obtuse, I've learned various uncode codes; e.g. em-dash is 2014 in hexadecimal, and en-dash is one less, and in X terminals I can just type shift+ctrl+u then the hex number then space to produce those symbols, but what I'd not noticed is that doesn't happen in pure screen terminals.

I'll have to check later what happens on my server, which I connect over ssh to to a system running a tmux session (which gets started by my .bashrc when I log in there). Believably, maybe I've just never needed it there,
 
Option one is currently WIP. Option 2 I hadn't considered until this conversation.

Thanks for explaining. Option one sounds as the most useful. Option 2 would be OK if it was less effort.

About LED feedback, three colors is more than enough, but an alternative could also be 2 colors + time. So chose some resolution, say 5 charge states or 10 charge states,
and then if you chose 5 states, and charge is 20% you light green black red back red black red black red black black black black and the same sequence again.
so
red - red - red - red - red would be 0%
green - red - red - red - red would be 20%
green - green - red - red - red would be 40%
green - green - green - red - red would be 60%
green - green - green - green - red would be 80%
green - green - green - green - green would be 100%

If you want more detailed resolution, you just light in 10 steps or 20 or whatever.

It's somewhat like telling the time with bells. You count the strikes to know the hour.

If you have other info to show with leds you could still use other colors for it (instead of black, or after the charge information, or by changing the green/red combination to orange/blue or yellow/white or whatever).

But it sounds like too much trouble when coding it, so red/orange/green is just fine.
 
What I'm also curious about is whether the Pyra plays in-browser DRM content already. Stuff like Spotify, Netflix etc?

Well, I don't want to be against anyone, but I for one would be happy to own a device that can't play DRM.
Either DRM or freedom are broken, or they can't be had at the same time, so I choose unbroken freedom.
I don't mean to disparage anyone. If the Pyra plays DRM I know @Eight Bit and others will be happy.
But if it can't I hope somebody can soothe homself thinking at least I will be happy.
Most likely it will be able or not depending on what software you load (although that would be broken DRM really).
 
  • Love
Reactions: rSl
Not to co-opt anyone's symbols, but using a simple 'rainbow' pattern should suffice pretty well. Combining Indigo and Violet into purple as most human eyes have trouble distinguishing one from the other without the other as reference.
Red <= 5%
Orange > 5 and <= 15%
Yellow > 15% and <= 25%
Green > 25% and <= 75%
Blue > 75% and <= 99%
Purple > 99%

Whatever the color or pattern you decide on, though, can we tie the 'intensity' of the glow out to whatever the keyboard backlight is +1? I.e. the light always glows when plugged in, but when the thing is booted up can be dimmed in line with the keyboard back-light settings.
 
I'm probably going to do something most similar to Grench's solution. I can control the color by modifying the PWM duty cycle of a R, G, and B LED. I can pretty easily create a function which takes the battery percentage and generates the appropriate values for the PWM for each LED. As far as when the thing is booted up, the LEDs are controlled from userspace. Right now there's a weird service that starts up and flickers all these LEDs randomly but it turns off after a while. Its pretty annoying and I'd like to get rid of it. I'll be getting to this LED stuff when I start working on power profiling after my charger driver modifications have been accepted by HNS. We're still in discussion mode on this as there's lots to change.
 
Could the GPIO on the Pyra be accessible via python?

For the LEDs? Its an LED controller over I2C but yes there is a driver and they are each individually accessible from sysfs. /sys/class/led/. There are 3 LEDs exposed for Left, Middle, and Right (RGB for each). They are controllable through the standard LED interface where you can get/set the brightness and get the max brightness. Similar for the ones behind the display.
 
Boot process is as follows:
1. USB power is presented on microUSB or the power key is pressed. This causes the PMIC to begin its powerup procedure. It is unavoidable that both of these events trigger a powerup, that is how the hardware is configured.
2. BootROM begins executing and tries to locate the SPL (primary bootloader). If it finds it, it loads it into OCRAM and jumps to the start vector. It will first search the left SD slot, then eMMC/uSD.
3. SPL does basic device configuration setting up some necessary clocks and most importantly configure the SDRAM and load the full bootloader U-Boot into SDRAM and jump. I've modified the SPL to also reset the charger chip and bump up the input current limit to 3A at this point. While the SPL is running, most of the system is off and the SOC is running at a low clock speed. This keeps us under the 500mA limit which is the default input current limit on the charger chip. Once this is bumped up, we are safe to turn on other devices and start consuming more power.
4. U-Boot does all configuration of the SOC necessary for booting, loads the kernel, initramfs, and device tree into RAM and jumps to the kernel start vector. It does some other boring but important stuff, like check the HW revision number to load the right device tree, handle some logic for the eMMC/uSD, and further configure the charger chip/PMIC.

The two options for handling the charging without booting are:
1. Handle charging in the bootloader. If we detect the battery is below some threshold (read the fuel gauge chip) or that we have not booted by user request (warm reset or power button), then we can sit and hang in the bootloader after we've configured the charger. Here we can display the charge level by modifying the color of an LED (red=low, orange=ok, green=good). In the future, I could potentially append this to have display feedback depending on level of effort and priorities (or someone else can do it too :)). While in this state, if the user presses the power key and we are above charge threshold, we will continue to boot (at this point we have not loaded the kernel). Otherwise we hang here, periodically checking the battery level and status of the power input (power off if removed). In this state, we will be consuming less power than with a fully or partially booted kernel, as most things are still turned off. (though we may have some things turned on and unconfigured, which may be worse. need to check this out).

2. Handle charging in the initramfs. When we boot the kernel, the initramfs is used as a filesystem before mounting the actual rootfs. There are some configuration scripts which run here, but the kernel is fully booted with the exception of kernel modules. We could add a script which checks the battery level and halts the process if we are below threshold until we are above. At this point we have the benefit of most kernel drivers up and running, so we can (I believe) do display feedback out of the box and we'll be running with the full kernel driver for the fuel gauge and charger chip rather than the minimalistic ones in the bootloader. However, we need to fully boot the kernel (just the kernel, not the OS) to get to this point. Also to make use of this feature, you must be using our initramfs. The initramfs is not necessary and some users may use a custom boot process which bypasses this.

Option one is currently WIP. Option 2 I hadn't considered until this conversation.

Is it not possible to have U-Boot detect if the power-on was charger-induced or power-button-induced and load a charging microkernel instead of the regular kernel? I remember this being discussed, but never implemented, back on the Pandora.

-God Ginrai
 
Is it not possible to have U-Boot detect if the power-on was charger-induced or power-button-induced and load a charging microkernel instead of the regular kernel? I remember this being discussed, but never implemented, back on the Pandora.

-God Ginrai

This is definitely possible. Loading a micro kernel to charge is a bit overkill since uboot is plenty capable already. Right now I don’t have support in uboot yet to read the battery level but I’m currently working on this. There is currently logic in a merge request for detecting the reason for boot up and powering off in certain situations.

 
I think i will make a Pyra Video, and i had some thoughts this morning how to do:
- As Camera i think my Iphone should work out, but i still needs a Mount, i could use a few books and the Kickstand of its Panzer Case, or i could use the Suction Pad Smartphone Holder i have in my Car, but then i would need something to attech its pad.. i dont know yet..

- I plan to make a test video these Days whit my Pandora, if its work out, i think i will release it on youtube, but dont exect it to be super professional..
If somewhone find a issue, he can take it, and have fun whit it ^^

These where my first Videos, but if these make fun, i think some will follow.. ^^
 
Dont thank me in advance, i dont know if this work out.. also i dont like my voice when its come from outside..
Lets hope this works this afternoon whit my Pandora..
If its dosnt work out, i just make Pictures in a few weeks..
 
Back
Top