jannik2099 / pinebookpro-overlay Goto Github PK

The battery controller starts throttling after either reaching some temperature or detecting greater than x current draw after some time, I'm not entirely sure.
This will cause the pbp to slowly discharge during compiles, which is... less than ideal.

I found that limiting the big cores ( cpupower -c 4,5 ) to 1.4 GHz circumvents this, I haven't had it happen since.

A script that checks for an emerge job that has been running for more than say an hour, sets the lower clock, and then sets it back up to maximum when the job is done should suffice.

Does this require some bash shenanigans, is it solveable with systemd unit files, would this be portable to OpenRC? No one knows, someone should find out. For now, people running into this have to do it manually

Package uboot:
This one is gonna take some more effort:
First of all we need a good uboot config, will probably take it from dhivael
After that, need an install script that 100% definitely does NOT damage your system - using dd is kinda scary

We should create a more slimmed down defconfig (i.e. without amdgpu, sata and other shenanigans) - best would be taking the manjaro config and working down from that.

The defconfig should be able to boot without an initramfs, and have all modules built in that are required for minimum usage (screen / drm, networking, HID, other peripherals). Everything that can be (reasonably) used on the pbp should be a module, everything else turned off

Quartz64 support ?

Maybe we could patch in hantro from https://github.com/Kwiboo/linux-rockchip/tree/v4l2-5.5-work-in-progress-v5.5/drivers/staging/media/hantro

Pretty straightforward description, sys-kernel/gentoo-sources has a few patches that we should include for sakes of consistency

https://github.com/sakaki-/genpi64-overlay/tree/master/profiles

for rockpro64 /pinebook pro ... other than tablet mode , r64pro also nice to have as /disfiles /packages and gp NAS /distcc along with RPI4 r64 for compute nodes.

while sakis bins will run , on either , adding profile links. a plus.

ie packages mask

https://github.com/ayufan-rock64/chromiumos-build needs porting ..

https://github.com/psychedup/gentoo-pine64 kernel ebuild skells added but needs work

if only you could rig firmware atf to load r64/pro/pinebook-pro...
https://github.com/tianocore/edk2-platforms dose have an R-64-pro and r64-pro seems to load the pb-pro. also.. has u-boot/atf bits ie elf compiled in fails if you dont.
https://github.com/andreiw/rk3399-edk2/ ebuild for the UEFI loader2 firmware awould be a plus..
can be built but not as easily. and ebuild ... dear loard.

grub2 efi
/boot/efi
./efi/overlay
/boot/overlay >>> /boot/efi/overlay SYM for compatibility ...

loader/s
/boot/efi
/boot
/

https://www.dropbox.com/sh/gfsfqv3p4lvnzi6/AAAE-Mb_8ko1oX3xSROVkP8ia?dl=0
grub or sysd-boot should work with the above , i need to cp file from atf into /workspace$

ayufan also has repos supporting rock64 /p-book-pro etc variants.

https://github.com/ayufan-rock64/pinebook-pro-keyboard-updater

https://github.com/ayufan-rock64/linux-package now updated to pinebookpro

Rumors are the 5.5 Kernel has fixed the glamor xwayland bug - I haven't had time to test that yet, anyone who can confirm this is more than welcome

Same for the qt gles option: I heard someone using GL + panfrost without fbturbo, and everything working fine

Similar to the raid6 patch, this should noticeably speed up boot times

Hello!

Would it be worth bumping sys-firmware/pinebookpro-firmware to at least commit e2e6321ac77cee8a5b712a1ba9120286ac0667a3? We don't have to pull in the latest ones with all the non-pinebook-related packages.

The primary useful change in that commit is switching the ccode value in nvram_ap6256.txt, so that new users (who do not live in Germany :P) can get 5Ghz WiFi. In the current config, we are stuck with 2.4Ghz unless that file is manually patched.

hello!

can you update the kernel ebuild? (:

This is a low priority issue, although everyone who speaks asm is welcome to try.

There's a bunch of packages that have NEON assembler optimizations, notably audio video and crypto libraries. Some of these do not work on armv8, porting them should not be more than rewriting them in the new syntax (speaking as someone who has no idea about asm or programming in general)

This should help with cpu bottlenecks especially during multimedia workloads. wether it also saves power is another question.

These patches would be toggled by the global performance-patches useflag.

A list of affected packages should be https://packages.gentoo.org/useflags/cpu_flags_arm_neon

Package extlinux in some way or another:
My current idea is an extlinux-update script that generates an extlinux.conf similar to how grub-update generates a grub.cfg

Some modules are required to get display output during initramfs stage - needed for e.g. unlocking encrypted rootfs. This shouldn't be more than finding out what the modules are called