ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
<Dylanger>
Wow, its like, impossible to statically compile cryptsetup lol
<Dylanger>
🙃
<steev>
i think you need to build a static lvm2 and then it should
<Dylanger>
I think right now, it's not possible to compile cryptsetup statically for aarch64
<Dylanger>
It's a shame there's no direct way for the kernel to ask for password input, avoiding initramfs all together
<alpernebbi>
Dylanger: I remember getting Debian's kernel/initramfs working for booting on LUKS/LVM etc. with Depthcharge but its size limit is the big problem
<Dylanger>
For the moment, I'm trying amstan's hack, just created a normal ext4 partition, then gonna try point init= to that partition
<Dylanger>
Then do pivot_root
<Dylanger>
After everything is up
<Dylanger>
Should only need busybox + cryptsetup statically compiled
<Dylanger>
Shouldn't be over ~15MB?
<alpernebbi>
do you have a lazor? guessing from a previous link
<Dylanger>
Homestar (Duet 5)
<Dylanger>
Same baseboard as Lazor tho I think
<Dylanger>
strongbad
<alpernebbi>
I think those are new enough to have switched to a 512MiB limit
<alpernebbi>
arm64 boards had 32MiB, older arms 16MiB I think
<alpernebbi>
IIRC you just gotta put it in the FIT and that works
<Dylanger>
32MB should be enough for a tiiiny shim
<Dylanger>
I wish either
<Dylanger>
A) There was a super smol rust bin that just did the thing and pivoted
<Dylanger>
B) Kernel did the thing (yayyay more attack surface)
<alpernebbi>
oh and you can compress the kernel before putting it inside the FIT, which gives you a lot of room
<alyssa>
alpernebbi: Oh hi there
<alpernebbi>
hello :D
<alyssa>
Dylanger: I do have debian initramfs cryptsetup + debian kernel under the 32MB limit, following alpernebbi 's surface
<alyssa>
though dunno if that's still possible
<alpernebbi>
tbh my main motivation in working on u-boot was to get rid of that restriction
<alpernebbi>
I'm also somewhat in the "whatever makes it boot" team
<Dylanger>
I agree, whatever gets it to finish, without an initramfs the whole process would be much more elegant, wouldn't it?
<alpernebbi>
not sure, initramfs is a powerful construct, like debian-installer completely runs as an initramfs
<alpernebbi>
macc24: There's "coreboot" defconfigs for u-boot but they're x86-only, I guess the stuff those use needs porting to arm64 and into a new "coreboot_arm64" defconfig
<alpernebbi>
and coreboot's build system also has to be modified to have u-boot as a choice for arm64 with that defconfig (instead of the specific board's defconfig like I did)
<macc24>
alpernebbi: yea i'll tinker around it
<alpernebbi>
I also tried to build it with tianocore once, but gave up when I noticed it was using x86 compilers...
<Dylanger>
Does anyone know what Google's reasoning was for dropping U-Boot for Depthcharge?
<macc24>
a
* alpernebbi
plans to work on other u-boot things, pulseaudio, depthcharge-tools before even starting on coreboot
<alyssa>
Dylanger: moar speed?
<Dylanger>
Ah yeah fair enough
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
Lucanis1 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
robher has quit [Remote host closed the connection]
robher has joined #aarch64-laptops
Lucanis1 has quit [Ping timeout: 480 seconds]
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
<gwolf>
Dylanger: Well, if it's hard to compile statically... maybe it is a sign you should port cryptsetup to Rust! ;-)
hexdump01 has joined #aarch64-laptops
hexdump01 has quit []
alyssa has left #aarch64-laptops [#aarch64-laptops]
<amstan>
what is this 32MB limit people are talking about for depthcharge?
<hexdump0815>
essentially the trick is to get below 32mb for kernel and initrd which is possible by heavily compressing them - works well without any extra effort on a plain debian or ubuntu system
<hexdump0815>
amstan: it looks like depthcharge does not load anything larger than 32mb from the kernel partition
<amstan>
that sounds like a bug
<hexdump0815>
16mb for armv7 32bit systems and maybe the limit is lifted for newer chromebooks
<amstan>
i mean, i know the partition sizes are around there, you one could always make them bigger
<hexdump0815>
amstan: i think the 16mb for early systems was even kind of documented somewhere
<hexdump0815>
yes, but if you make them bigger booting will only work as long as the kpart is below 32/16mb
<hexdump0815>
"16mb will be enough for ever" :)
<amstan>
i'm pretty sure i was using kparts in arch above 32MB before i figured out how to compress them
<macc24>
amstan: huh?
<macc24>
i remember not getting >16mb kernel to boot on veyron
<hexdump0815>
as robclark mentioned: it looks like lazor and newer seems to have lifted the limed maybe - but i also verified the limit on oak and kukui to be in place still
<amstan>
see linux-aarch64-rc-chromebook-5.12.rc3-3-aarch64.pkg.tar.xz
<amstan>
vs linux-aarch64-rc-chromebook-5.12.rc3-2-aarch64.pkg.tar.xz
<hexdump0815>
for the armv7 chromebooks its not a big deal as there is a chainloadable u-boot for nearly all of them and you can just use that for loading the initrd
<macc24>
imagine needing an initrd
<hexdump0815>
for aarch64 it works quite well with 32mb limit too with compression - there is still a bit of headroom, even if the initrd has a lot of modules in it etc.
<macc24>
with lz4 compressed kernel i have 12mb/32mb kernel partition space used
<hexdump0815>
macc24: if you want encrypt your rootfs (which makes a lot of sense for a portable device) anything without initrd is getting painful easily as Dylanger found out as well now :)
<macc24>
hexdump0815: hold my beer ;)
<alpernebbi>
amstan: the size limit is CONFIG_KERNEL_SIZE in Depthcharge
<hexdump0815>
alpernebbi: i have that on my radar already, but it might take a bit until i get to playing around with those as for now i already have my own chainload u-boot builds for all i need
<hexdump0815>
but i was very happy to see this, especially the new things like gru :)
iivanov has quit []
<steev>
hmm
<steev>
i wonder if those nyan ones could bring mine back to life
<steev>
i miss it
<alpernebbi>
steev: probably not, they're meant to run from the original firmware, I didn't consider SPI ROM images as I didn't know if they'd be useful
<steev>
alpernebbi: hm, well my nyan still has the original firmwares
<steev>
now that it's eol, i just wanna make it easier to run "real" linux instead of cros
<steev>
and also not have to deal with the 30 second timeout and beep
<hexdump0815>
i looked for options to make encrypted root working on chromebooks and none of the alternative solutions to using initramfs did really convince me: they were either very cumbersome to use/setup or not working at all (like having the passphrase in /proc/cmdline :) )
<Dylanger>
<hexdump0815> "Dylanger: i'm running luks..." <- How are you generating the actual initramfs image itself?
<hexdump0815>
on debian/ubuntu its done via the update-initramfs command and one needs some extra options to make it use heavy compression
<hexdump0815>
see the install-to-emmc-with-luks-full-disk-encryption.txt notes i linked above
<Dylanger>
Thank you!
<Dylanger>
I'll try this today
<hexdump0815>
let me know if anything is unclear - those notes of me are often not really proper documentation :) ... but they should give a clear idea how it is supposed to work