<hexdump0815>
jenneron[m]: i do not know or rememebr in detail, but there was something strange with bt on minnie - i have found some pointers, but they do not relly look like addressing the problem
<jenneron[m]>
also it affects many other parts of hardware
<macc24>
jenneron[m]: remind me to look at that on monday or tuesdaya
<macc24>
plaese
<jenneron[m]>
ok
<macc24>
if i don't forget to check in i'll look at that bt issue
<macc24>
jenneron[m]: errno -517 at boot time is a missing driver or driver compiled into module
<macc24>
-110 is a timeout hm
<jenneron[m]>
macc24: i don't think so
<jenneron[m]>
sound works without CONFIG_SERIAL_DEV_CTRL_TTYPORT
<jenneron[m]>
i suppose this config affects some device sound depends on
<jenneron[m]>
so it is deffered
<macc24>
jenneron[m]: you did a depmod -a, right?
<jenneron[m]>
where?
<macc24>
on your laptop
<jenneron[m]>
it is a clean install
<jenneron[m]>
i've just built a kernel package, placed it in my local repository and installed rootfs using it
<macc24>
huh
<jenneron[m]>
i usually can simply do pmbootstrap sideload --host ip linux-google-veyron to upgrade kernel package, but device doesn't boot into userspace in this state
<jenneron[m]>
in current state*
<macc24>
oh pmbootstrap
<macc24>
jenneron[m]: btw feel free to change "free bootloader" to "works" on rk3288 devices
<jenneron[m]>
do you mean libreboot?
<macc24>
the stock coreboot's sources are public
<macc24>
and iirc it doesn't use a dram init blob thingy
<macc24>
also depthcharge
<macc24>
idk amstan might be able to talk more about it than 70%-asleep me
<jenneron[m]>
well, i would prefer to mark it as works only if we have a convenient way to build it from source and install
<jenneron[m]>
at least an instruction in pmOS wiki
<macc24>
jenneron[m]: also uboot can do uefi just fine
<macc24>
no need for tiano
<macc24>
pinephone pro does that
<jenneron[m]>
yeah, but again rk3288 chromebooks have poor support in u-boot, and u-boot doesn't have generic armv7/aarch64 coreboot payloads
<macc24>
oh yeah
<macc24>
forgot
<macc24>
damn i really should go to sleep
<macc24>
be back either in a day or couple months lol
<amstan>
stop doing things in hard mode, lol
<amstan>
another problem with diversity like this, is that if every distro has a different way of supporting the device it'll just confuse everyone
<jenneron[m]>
the thing is that most distros support EFI and very few of them support depthcharge
<amstan>
it's much easier to get a critical mass of users/devs on a device if they're all talking about the same stuff
<jenneron[m]>
i still prefer to use depthcharge, so i integrated it in postmarketOS
<amstan>
efi is non-relevant on arm32
<amstan>
i have fpga 32 bit boards running arch that boot with a uboot.txt script
<amstan>
like... the distro should adapt to the hardware, not the hardware to the distro
<jenneron[m]>
but adapting hardware is an action in one place, adapting distros is an action in all distros
<jenneron[m]>
with depthcharge we have only a few distros supporting these devices
<amstan>
any distros need device tree support and a bunch of special configs (probably =y) to even have the hardware boot, so i don't think it's much farther to ask to package the kernel in a particular way
<jenneron[m]>
it would be nice to implement depthcharge in distributions and that's what i'm working on for pmOS, but i understand that most distros won't do that
<amstan>
i think trying to force a standard that comes from non-chromebooks is extra work that's not really worth it
<jenneron[m]>
depthcharge is not feasible especially on these armv7 devices
<jenneron[m]>
especially on exynos ones which can't boot images bigger than 8M
<robclark>
yeah, for board with enough u-boot support.. which sadly isn't all of them
<jenneron[m]>
indeed
<jenneron[m]>
to support all devices we have to stick with depthcharge in distros
<amstan>
what ended up happening for me early on: oh... that device can't boot anything but chromeos packaged kernels
<amstan>
rw_legacy is not a thing (at the time)
<amstan>
u-boot is not ported to this device
<amstan>
so instead of doing all that work i would just figure out how to get the kernel booting with the most minimal amount of work, and then get to the more fun part (of using that device)
<amstan>
the size limitations kind of suck, compression helps a little bit
<amstan>
it usually ended up being just package it like depthcharge expects
<amstan>
the kernel probably has to be custom for that device anyway (even when compiled from upstream) so it could be made smaller, at that point you also don't need an initramfs
<amstan>
i like the sticking with vanilla depthcharge because it's scalable with all future chromebooks
<amstan>
i don't have to wait for any other project (u-boot) to get support before i can boot arch on a prototype chromebook
<jenneron[m]>
need of initramfs is not related to kernel size
<jenneron[m]>
we use initramfs for splash screen, for custom logic of detection boot and root partitioin, for full disk encryption and maybe a few other things
<jenneron[m]>
the problem is that it's quite difficult to fit kernel + initramfs into 8M, so i did that pmbootstrap installs u-boot on kpart for these devices
<amstan>
splash screen should be possible without initramfs
<jenneron[m]>
FDE?
<amstan>
for root partition i usually do PARTUUID=%U/PARTNROFF=1
<amstan>
FDE is a little tricky
<amstan>
someone in aarch64-laptops put an unpacked version of the initramfs in a normal partition and just used that as a temporary rootfs
<jenneron[m]>
fun
<jenneron[m]>
i just use initramfs
<jenneron[m]>
also, these things might be easier for you, but not for distributions which already have another way implemented
<jenneron[m]>
i'm trying to unify this as much as possible, we use generate initramfs the same way for android, chrome os and other devices, fde works the same way too
<jenneron[m]>
s/use//
<jenneron[m]>
my point is that it should be as easy as possible for distributions, and end-users should not care about it at all because distributions take care of it
<jenneron[m]>
(eventually)
<jenneron[m]>
for pmOS you don't have to care about initramfs or that second partition, you just do pmbootstrap install --sdcard /dev/sdX and if you want FDE you just add --fde parameter
<alpernebbi>
oh hey, more familiar nicknames, hi!
<alpernebbi>
(I want to reply to stuff, but can't seem to form sentences right now, oh well)