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)
<Dylanger>
[ 1206.257128] device-mapper: ioctl: error adding target to table
<Dylanger>
Anyone know if I'm missing something here
<Dylanger>
When I try to open a LUKs drive with `cryptsetup luksOpen`
<steev>
missing the cipher it uses in your kernel config?
<steev>
is cryptomanager loaded?
<steev>
don't recall its exact name
<robclark>
macc24: rather than porting u-boot to all the different chromebooks that have coreboot support (which sounds, at least to me, like a lot of driver writing/porting), have you considered going in the other direction and porting u-boots efi-loader to coreboot? Tbf I haven't looked too deeply into either option but coreboot already has all the drivers you are missing.. it just misses the efi interfaces and support to load
<robclark>
and jump to an efi app (like grub), which seems like it should mostly all be portable
<robclark>
sjg or possibly amstan might be the sort of person that would know how much of a sane idea that is.. but it seems to me that one-time work is a whole lot better than per-SoC work
<amstan>
sjg would probably be super into this (i think he's the uboot rockchip maintainer as a hobby)
<amstan>
i'm generally more pragmatic and don't care much about my bootloader as long as i can make it boot my arch kernel, so even depthcharge is fine to me
<robclark>
I'm not sure how coreboot upstream would feel about efi-loader support.. but to be fair u-boot's efi implementation is a lot more pragmatic and less nutso than edk2
<robclark>
(alternate idea is find way for u-boot and coreboot to share drivers.. which I guess sjg would also be into.. haven't looked at coreboot driver model so not sure if that is sane or insane idea)
<Dylanger>
<steev> "missing the cipher it uses in..." <- Ah I was missing xts, enabled the QC RNG too because why not
<Dylanger>
> The second is to create one or more device-mappers using the module parameter “dm-mod.create=” through the kernel boot command line argument.
<Dylanger>
<Dylanger> "Could this this a shot" <- Hm, this is kind of useless, I don't want to put a password in cmdline
<Dylanger>
Not having an initrd is super limiting for disk crypto
<macc24>
robclark: well, coreboot isn't really made to do anything beyond basic hardware init
<macc24>
so far i'm leaning into "coreboot with u-boot payload" option
<amstan>
Dylanger: you could always have some kind of partition that boots first, then pivots root to the real one just like the initrd would
<amstan>
actually... you might be able to just extract your initrd (they're ext4 or whatever, no?) onto that partition and if your root is that it might just boot it like initrd normally would
<amstan>
i guess this only works for initrd, not for initramfs
<amstan>
nvm: `lsinitcpio -x /boot/initramfs-linux.img` does the trick
<amstan>
yeah, there's an init there and everything
<amstan>
pretty sure this would work
<amstan>
aha, but you want to make sure you're using pivot_root, since switch_root will rm stuff
<Dylanger>
Thanks heaps
<Dylanger>
I'll give it a whirl
<Dylanger>
Any idea how to actually generate one for Debian
<Dylanger>
I'll Google 👍
<macc24>
Dylanger: when i was tinkering around initrd i was making it manually and then scripted it up
<macc24>
i was thinking about using a basic initrd to replace chromeos on chromebooks without any pendrive or storage medium
<macc24>
i did get a kernel to boot but fitting entire debian installation into a small kernel partition or getting cadmium to install from barebones busybox is hard.
<javierm>
Dylanger: I may be missing some context but maybe one option is to have an initramfs built-in the kernel that contains the LUKS unlocking and ask for password ?
<javierm>
Dylanger: or would also that don't work with depthcharge? IIUC the constraint you mentioned is that wasn't able to load an initrd and pass to the kernel
<Dylanger>
I think depthcharge supports initramfs images just fine, from what I understand you simply pass it in when you package the kernel up for depthcharge
<Dylanger>
It is an interesting problem tho, initramfs is quite complex, it's interesting there's no direct kernel solution out there
<Dylanger>
I can understand keeping that complexity out of the kernel tho
<Dylanger>
<javierm> "Dylanger: I may be missing..." <- I _think_ this is how depthcharge works currently no?
<Dylanger>
<amstan> "Dylanger: you could always..." <- I'm honestly happy to just expand the ChromeOS Kernel partition to like 300MB or whatever
<javierm>
Dylanger: I'm not familiar with depthcharge. It uses a FIT image right? AFAIK you can define an initrd image in the FIT .its
<javierm>
but I was not talking about adding an initrd to the FIT image but to the kernel image itself (
<Dylanger>
Yeah I believe so
<javierm>
if that bootloader couldn't load and initrd, that is. Which is not the case of deptcharge I understand now
<Dylanger>
I've never created one manually before
<macc24>
Dylanger: i think you saw the code to make initrd manually
<macc24>
Dylanger: check out #fedora-arm on libera
<javierm>
Dylanger: the missing bit I think would be to have something re-generating a FIT image and writing to the kernel partition after a ostree update transaction
<javierm>
since all that OSTree does is to create the symlink to the current boot entry
<javierm>
but that assumes that the bootloader knows how to parse the entries and boot the current that points to the correct OSTree
SallyAhaj has quit [Remote host closed the connection]
<robclark>
macc24: well, not sure of how much of it is depthcharge and how much is coreboot, but the stuff that runs before kernel is loaded on chromebooks knows how to light up display, knows how to operate emmc/usb/etc.. basically all the device specific things you need.
<macc24>
robclark: i see some graphics init code in coreboot for chromebooks
<macc24>
and theoretically, gru, veyron and kukui probably have mmc/usb/i2c/spi working in u-boot
<macc24>
implementing a graphics output driver for mt8183 is one of the last things i want to be doing...
<robclark>
anyways, my point is that efi code in u-boot isn't device specific, if you port it to use the drivers that coreboot already has then you get support for all the chromebooks, rather than just one or two
<macc24>
mmc driver from coreboot?
<macc24>
O_o
<robclark>
well, I assume your goal is to have grub running (and probably shim, etc) so normal "distro" bootflow works.. for that you need display, and mmc/ssd.. you probably also want usb
<macc24>
display -> simplefb
<macc24>
that can be marked off
<macc24>
mmc / usb -> u-boot's efi service
<macc24>
services*
<robclark>
simplefb needs bootloader to leave display on.. coreboot does not
<robclark>
u-boot might have that for some platforms.. but defn not all
* macc24
points at line 199 of src/mainboard/google/kukui/mainboard.c in coreboot's source
<macc24>
robclark: u-boot has them for rk3399 and rk3288 socs, and /should/ have for mt8183. i am not touching anything qualcomm related without a stick.
<robclark>
how is u-boot going to use coreboot's drivers.. it could if coreboot exposed those to the payload via something like efi but then you wouldn't need u-boot, now would you?
<macc24>
last time i checked, coreboot doesn't leave almost nothing running after it jumps into payload
<macc24>
coreboot just inits the hardware and leaves everything else to the payload
<robclark>
right.. so then if your payload is u-boot, it needs to duplicate all the drivers from coreboot
<robclark>
that is the point I'm trying to make
<macc24>
does coreboot even have mmc or usb /drivers/ to read/write data?
<robclark>
I think the thing it misses compared to u-boot is ext4/fat/etc fs support
<macc24>
...
<robclark>
not 100% sure about things like emmc write.. but otoh you probably don't actually need that to have enough uefi to boot a distro
<robclark>
(I did work on u-boot's efi implementation at one point in time, to get it complete enough to boot fedora.. and, well, Shell.efi as well)
<macc24>
i wonder if windows 10 can be booted from u-boot
<robclark>
I wouldn't be completely surprised if it could
<macc24>
thatd be so funny
<javierm>
I think that u-boot's efi even have tpm support now so maybe even windows 11 work :)
<robclark>
macc24: also, for u-boot, you'd need to port panel and/or bridge support for display, ie. for devices that use different edp bridge or mipi panel, and things like that.. whereas coreboot already has all that (plus also emmc/usb/display/etc support for future chromebooks that don't exist yet).. so slurping in u-boots efi implementation into coreboot and porting it to use coreboot's driver api's seems like a lot less work
<robclark>
and more future proof
<macc24>
uh
<macc24>
right.
<alyssa>
amstan: "i'm generally more pragmatic and don't care much about my bootloader as long as i can make it boot my... kernel" <--- i get that
<macc24>
we gotta coin a new term "whatever boots your kernel"
<macc24>
just like "whatever floats your boat"
<macc24>
but better
<alyssa>
whatever boots your root
<macc24>
whatever crashes your mali
<robclark>
IME looking funny at a gpu is a good way to crash it.. of the possible state space of a gpu, more of it is crashing than not crashing :-P
<macc24>
skamteboard
<alyssa>
robclark: looking funny? old enough malis crash if you look at them at all1
jonasbits has joined #aarch64-laptops
vkoul has quit [Remote host closed the connection]
vkoul has joined #aarch64-laptops
robher has quit [Read error: Connection reset by peer]
arnd has quit [Read error: Connection reset by peer]
steev has quit [Read error: Connection reset by peer]
arnd has joined #aarch64-laptops
steev has joined #aarch64-laptops
robher has joined #aarch64-laptops
iivanov_ has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
<steev>
blergh
<steev>
the xt_socket build failure actually propogated from next to linus' tree
iivanov has quit [Remote host closed the connection]