<bpye>
Hah - my squashfs image is smaller than my aarch64 kernel...
<clever>
bpye: aarch64 linux cant be self-uncompressing
<clever>
arm32 linux is only self-uncompressing, it lacked support for non-compressed forms
<clever>
not sure why they changed that
<samueldr>
push those silly features into the boot firmware
<clever>
yeah
<samueldr>
that's my assumption
<samueldr>
but then what happens when a vendor produces a buggy boot firmware?
* samueldr
sighs
<samueldr>
of does not know about a newer compression scheme!
<samueldr>
though, to be fair, it is understandable that the boot firmware or bootloader would know about it
<samueldr>
and hopefully it's a scheme where the bootloader is distinct from the firmware
<samueldr>
e.g. grub + uef
<samueldr>
uefi*
<delroth>
just add more bootloaders, it's the ARM way
<delroth>
it's not a real production system if it has less than 5 bootloaders in the chain
<samueldr>
you'd like Mobile NixOS!
<samueldr>
production ready!
<clever>
another thought, is that the self-unpacking code, atleast on arm32, ran in no-mmu mode
<clever>
so you lack a data cache, and have to deal with patching for relocations
<samueldr>
qualcomm bootloader boots android bootloader [which boots mobile nixos stage-0] which boots mobile nixos stage-1 !
<delroth>
I used to do some kernel development on a Pixel C, it was great... was supposed to be a ChromeOS device then switched to be an Android device late in the development cycle
<delroth>
so it has a ChromeOS boot chain that chainloads an Android boot chain
<clever>
but a bootloader like u-boot, is typically built for that platform, and can turn on the mmu and other stuff
<clever>
so it could decompress faster
<samueldr>
stage-0 does not actually work on most vendor kernels because either they're too old for kexec on aarch64 or they broke it
<samueldr>
I *really* like chromeOS devices
<clever>
it could even decompress during the dma'd reads of the file, and get overlap between load and unpack
<delroth>
coreboot ftw
<samueldr>
they have what I believe is the perfect example of a secure boot chain that leaves the end-user in control
<clever>
so i can see how loading a compressed file with a bootloader, can be faster
* clever
heads off to bed
<samueldr>
I don't like the initial boot firmware being too involved in the operating system boot details
<samueldr>
like how U-Boot "has to" load the FDT the kernel expects
<samueldr>
well, the bootloader, any
<samueldr>
coreboot's approach is nice there, where it runs a payload, rather than it being quite integrated
<bpye>
clever My squashfs is even smaller than the default armv7 config, it doesn't really do anything except boot and bring up networking with a tty - but it's kind of amusing all the same. I'm sure I could get the kernel size down but anything under... 128M is fine which is easy enough
orivej has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<patagonicus>
delroth: Thanks for working on the Pixel C! I still use mine. :D Though I really should look into building LineageOS myself since they stopped providing prebuilt images.
<patagonicus>
Sigh. My config for the odroid hc2s is such a mess. I think I'll make a fresh start to merge it into my shared modules, that might be faster.
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]