| 1 Aug 2025 |
dramforever | there's also nothing on this chip but lol | 12:36:21 |
emily | I am doing split outputs and have to decide what should be the legacy target for random platforms we theoretically supported building a kernel on at some point | 12:36:29 |
dramforever | In reply to @emilazy:matrix.org right which is all I really care about for deciding what targets our linux builds okay so... no you cannot build a generic mips kernel to run on lemote | 12:37:03 |
dramforever | afaict | 12:37:05 |
emily | which is like "zImage for ARM, bzImage for x86, god knows for everything else" | 12:37:06 |
emily | thankfully our bespoke Lemote config already fails to build so I'm removing it | 12:37:25 |
emily | but you can override the defconfig | 12:37:32 |
dramforever | so does it really matter what make target our unusable generic mips kernel is? | 12:38:12 |
dramforever | well at least for riscv it's Image unless the generic compressed kernel has become a thing since last time i checked | 12:38:55 |
emily | I could just break it but Alyssa would get mad at me. because we do nominally have some kind of MIPS conditionals and stuff in there already | 12:38:59 |
emily | we use vmlinuz.efi for RISC-V and LoongArch64 | 12:39:19 |
emily | thankfully | 12:39:21 |
dramforever | in linux, you mean? | 12:39:23 |
emily | so there is just no legacy there | 12:39:27 |
dramforever | or in nixpkgs in general | 12:39:34 |
emily | in our Linux kernel packaging machinery yes | 12:39:37 |
emily | some of which is in lib.systems | 12:39:39 |
dramforever | oh | 12:39:44 |
emily | because someone built something for Lemote in like 2014 or whatever and let it rot | 12:39:57 |
dramforever | huh, so vmlinuz.efi did happen | 12:39:58 |
emily | yes, it's good | 12:40:13 |
emily | part of my goal is to make AArch64 use it by default when you use a UEFI bootloader | 12:40:19 |
dramforever | no more megabytes of holes in the image now | 12:40:40 |
emily | right now we use Image which is UEFI stub but uncompressed kernel for compatibility with not-UEFI, because e.g. U-Boot can't decode the UEFI ZBOOT format to decompress a kernel by itself | 12:40:41 |
emily | so split outputs mean we build the kernel once, pack multiple image formats in different outputs, and you can get either vmlinuz.efi or zImage out based on the output you select, which bootloader modules can do | 12:41:08 |
emily | so we get compressed kernels and UEFI-by-default without breaking anyone's boot (hopefully (probably)) | 12:41:23 |
dramforever | noice | 12:41:34 |
emily | the actual solution is for someone to just implement reading the UEFI ZBOOT header in U-Boot. the actual solution is for everyone to just use UEFI | 12:41:51 |
emily | but I take what I can get | 12:41:54 |
emily | (x86 doesn't use it btw) | 12:43:30 |