Yes I've installed Armbian Focal to the eMMC and not had any issues booting anything else from SD after that. This worked both with the latest Armbian Focal XFCE image and also building a Focal image with LUKS enabled.
The one showstopping issue I have with the Focal build right now is that booting gets stuck when on battery or USB-C power. Messages over serial console aren't illuminating: just hangs at starting kernel.
Interested to know if anyone else can reproduce that. It doesn't effect the Buster images.
03-16-2021, 01:23 PM
(This post was last modified: 03-16-2021, 02:24 PM by RyanAZ.)
(03-15-2021, 12:59 PM)mattpenn Wrote: Yes I've installed Armbian Focal to the eMMC and not had any issues booting anything else from SD after that. This worked both with the latest Armbian Focal XFCE image and also building a Focal image with LUKS enabled.
The one showstopping issue I have with the Focal build right now is that booting gets stuck when on battery or USB-C power. Messages over serial console aren't illuminating: just hangs at starting kernel.
Interested to know if anyone else can reproduce that. It doesn't effect the Buster images. Thanks for the reply. I was attempting to boot Android 7 which I have discovered is a faulty image without a boot loader. I tried boot from the PBP Debian 9 image to SD, it worked, so I can use this if I need to re-image later. It appears I do not need to mess with Armbian emmc uboot.
I have just booted to Fedora in the SD card. All working fine, but I think I'll stay on Armbian now.
Not sure if people are seeking DRM on Armbian, I was able to add DRM for Netflix/Prime/etc to Armbian Ubuntu Focal using the Docker Chromium Media edition script provided by the Twister Armbian distribution. The script assumes your user is 'pi' so it may need to be edited to reflect your user account.
Post install: edit ~/docker-chromium/Chromium-xxxxxxxxx.desktop file. The icon path will require your user profile rather than 'pi'.
If you know of a simple DRM solution for Armbian Ubuntu Focal, please post a reply.
(03-15-2021, 12:59 PM)mattpenn Wrote: Yes I've installed Armbian Focal to the eMMC and not had any issues booting anything else from SD after that. This worked both with the latest Armbian Focal XFCE image and also building a Focal image with LUKS enabled.
The one showstopping issue I have with the Focal build right now is that booting gets stuck when on battery or USB-C power. Messages over serial console aren't illuminating: just hangs at starting kernel.
Interested to know if anyone else can reproduce that. It doesn't effect the Buster images.
You can increase the kernel message logging.. by putting `verbosity=7` in `/boot/armbianEnv.txt`
Rock64, H64, PBP Running Armbian
The (main) challenge I have had with Armbian on the PBP is the power consumption during sleep / suspend. It isn't that different than when running with the screen on! I think previously on Manjaro (after getting it to work) it would go to the "red" LED when in suspend, and would require the power key to "wake up" but the consumption (during suspend) was "good" (it could "sleep" for a day without going "flat").
But with Armbian all LED go out, it does disconnect wifi (so isn't just "screen off") but will wake when hitting a key. Letting it sit overnight will likely fully drain the battery.
Is there a way to change the suspend / sleep behavior via armbian config or some other config file?
04-18-2021, 05:47 AM
(This post was last modified: 04-18-2021, 05:52 AM by lanefu.)
(04-18-2021, 03:39 AM)rik-shaw Wrote: The (main) challenge I have had with Armbian on the PBP is the power consumption during sleep / suspend. It isn't that different than when running with the screen on! I think previously on Manjaro (after getting it to work) it would go to the "red" LED when in suspend, and would require the power key to "wake up" but the consumption (during suspend) was "good" (it could "sleep" for a day without going "flat").
But with Armbian all LED go out, it does disconnect wifi (so isn't just "screen off") but will wake when hitting a key. Letting it sit overnight will likely fully drain the battery.
Is there a way to change the suspend / sleep behavior via armbian config or some other config file?
Sleep is delegated to systemd. See / etc/systemd/sleep.conf
If you find a better configuration please share.
https://www.freedesktop.org/software/sys....conf.html
At the time of implementation hardware sleep of any kind was unreliable so this mode we're using is just kernel-based sleep.
Rock64, H64, PBP Running Armbian
04-18-2021, 08:52 AM
(This post was last modified: 04-18-2021, 08:53 AM by rik-shaw.)
(04-18-2021, 05:47 AM)lanefu Wrote: Sleep is delegated to systemd. See /etc/systemd/sleep.conf
If you find a better configuration please share.
https://www.freedesktop.org/software/sys....conf.html
At the time of implementation hardware sleep of any kind was unreliable so this mode we're using is just kernel-based sleep.
Thanks for the quick reply! Note that in `/etc/systemd/sleep.conf` I had this at the end:
I corrected the typo (Susp*a*nd), and will test a bit more. The man page doesn't give me a lot of detail on the power saving differences between the different options, but it seems that `mem` means it will look at /sys/power/mem_sleep so I'll have to dig around and do some more testing of the various options.
Note that I FULLY support reliability :-) so can understand it may not be reasonably possible to find a better powersaving in sleep, since there are complaints about it disabling sound, possibly wifi, not waking at all, etc. Armbian really is great for the PBP, btw. I am currently on 5.10.21, and use Cinnamon (4.8 via PPA that we maintain) which is really quite performant (older Cinnamon up through 4.6 was sluggish).
04-18-2021, 12:30 PM
(This post was last modified: 04-18-2021, 12:38 PM by wdt.)
FWIW,, I won't use a distro that doesn't have 'good' sleep,,
because then a boot from SD is a viable option
Yes, the boot is slow,, but 3 s to 'sleep' it,, 10-11s to wake, another 10 for wifi
s3, ram to mem, s2ram is about 7% / day
So you can pick it up 2-3 days later and not have to hunt for charger
Damn few distros can manage this, requires 3 things
a specific patched kernel, bsp uboot, right systemd settings
Only 3 that I am aware of, manjaro (kern 5.8). elementary, fedora32
The audio can have a unbind, bind cycle to restore it
oops, forgot,,also NO nvme, pci driver cannot sleep
(04-18-2021, 12:30 PM)wdt Wrote: Damn few distros can manage this, requires 3 things
a specific patched kernel, bsp uboot, right systemd settings
Only 3 that I am aware of, manjaro (kern 5.8). elementary, fedora32
@ wdt thanks for your reply. I have had a hard time consolidating the necessary information to get sleep running well. I have Manjaro on a SD card for testing, but it updated itself to 5.11.x and loses about 50% of battery in 11 hours (just did an overnight test), so I will see how to put back the patched 5.8 kernel to see if that makes it more reasonable like you mention (<10% per day).
Can you make any comment on what kernel elementary uses Since I am using Armbian Focal it would be the easiest for me to match elementary. I don't think they "patch their own kernel" so it would just be a matter of tracking down what they are using.
So, kernel aside, is there a clear guide on the bsp uboot and systemd settings needed? It seems this info would best be consolidated at the PBP wiki page, but no reference to it there I think. Digging through various forum entries makes it confusing to know what the "current" and "authoritative" approach is. Would you be willing to edit there so there is a central place documenting what is needed to get deep sleep to work correctly? https://wiki.pine64.org/index.php/Pinebook_Pro
|
