binarycraft[m] has quit [Server closed connection]
binarycraft[m] has joined #linux-cros-arm
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-cros-arm
<hexdump0815>
jenneron[m]: (continuation from ##aarch64-laptops discussion) yes, i can fully understand your move to depthcharge booting for them for pmos
<hexdump0815>
and i think its cleaner as well as this is what is used for the 64bit ones as well
<jenneron[m]>
hexdump0815: i think i may still keep it for exynos devices, they have 8M limit
<hexdump0815>
also i think depthcharge is actually quite a nice bootloader once one gets used to it
<jenneron[m]>
actually, i can fit 8M too, but snow refuses to boot initramfs still
<hexdump0815>
i think they have some hacked-u-boot based bootloader
<hexdump0815>
they do not have depthcharge
<jenneron[m]>
and mainline u-boot is mostly fully functional on exynos devices: emmc, sd, usb
<jenneron[m]>
except spring, i didn't have much chances to fix it because of blackouts, but i've tried some things, and usb situation is... unpleasant
<hexdump0815>
for now i stick to my precompiled u-boot version, which seem to work at least for the devices i was able to test it with directly or indirectly
<jenneron[m]>
hexdump0815: it's better than android
<hexdump0815>
but in the long run i may switch to what pmos uses if that is working well (which i guess it will at some point)
<jenneron[m]>
i think we will use depthcharge on all devices except exynos
<jenneron[m]>
also, there is an annoying issue that crossystem loses parameters after battery depthcharge
<jenneron[m]>
when booting from eMMC we can work around that with init script, but it's not possible when booting with secondary u-boot
<jenneron[m]>
battery discharge*
<hexdump0815>
i think this is not only snow or is this snow only? this is why i recommend to set the gbb flags to 0x19 to have the important settings to boot from usb enabled by default
<jenneron[m]>
maybe crossystem can be work arounded with modifying dtb in u-boot
<jenneron[m]>
hexdump0815: yeah, not only snow
<jenneron[m]>
nyan and veyron too
<hexdump0815>
i think there was also some way to run crossystem and ectool from within linuxwhich might make life easier as well - i did not look into this yet but plan to at some point
<jenneron[m]>
yes, but it doesn't work when chainloading with u-boot
<jenneron[m]>
depthcharge modifies dtb for crossystem, u-boot does not
<hexdump0815>
oh - does it mean that this problem (forgetting settings with empty battery) is gone for the 64bit chromebooks?
<jenneron[m]>
it didn't happen on any of mine
<jenneron[m]>
(aarch64 ones)
<hexdump0815>
interesting - actually never tried there
<jenneron[m]>
well my hana has similar to spring problem with battery discharging in disabled state
<jenneron[m]>
i've never had issues with booting from usb/sd after it
<hexdump0815>
one thing i plan to look into at some point is that ectool seems to has some nice options for batter charging handling - maybe this can be used to keep the battery charged at 80% instead of 100% to extend its life with some userspace help from linux
<hexdump0815>
but currently i do not have that much time to work on things - just doing small things currently - hopefully will have more time between the years
<hexdump0815>
btw. are there any plans to integrate zswap into pmos (maybe optionally)? i'm using it for years now and find it working very good
<hexdump0815>
it gives you what zram gives you if you only need limited memory but can also swap very efficiently (i.e. compressed) if more memory is needed
<hexdump0815>
also the mgrlu kernel option coming with v6.1 is very nice for lower end hardware
<hexdump0815>
i'm writing right now on a system with 4gb ram and 20% configured for zswap with zstd compression and zsmalloc allocator and it never uses more than about 100mb of real swap space even when i have firefox with 60+ tabs open
<hexdump0815>
for my usage the zswap part of the memory gets compressed around 1:5 making that 20% for zswap virtually 2gb, so essentually the system feels like having close to 6gb of ram without any noticable side effects
<hexdump0815>
and another nice thing is using btrfs which is rock solid if you avoid the fancy stuff and can use built in zstd compression making even a 16gb emmc quite a lot of space
<hexdump0815>
as a bonus btrfs does internal checksum checks of the files on ready, so one will notice when the emmc or sd card is dying and one can check integrity based on those checksums at any time via btrfs scrub command