ChanServ changed the topic of #linux-cros-arm to:
hexdump0815 has joined #linux-cros-arm
hexdump01 has quit [Ping timeout: 480 seconds]
dcz has joined #linux-cros-arm
dcz has quit [Ping timeout: 480 seconds]
<janrinze> ellyq: Sorry to hear about your health issues. Hope you will recover soon. (I don't know what MT stands for b.t.w.)
<weirdtreething[m]> I think she means mediatek
<ellyq> janrinze: MediaTek :D
<janrinze> jenneron[m]: What I meant is someone better than me. I can test changes but I just stop experimenting with dtbs and such. There are people way more knowledgable about these things than me.
<jenneron[m]> janrinze: there is angelo giving me hints on email, heh
<jenneron[m]> but nor me neither angelo has dojo hardware
<jenneron[m]> so we need someone to test it
<janrinze> jenneron[m]: I can test if you have an image to test. Testing itself is usually just a short round trip.
<jenneron[m]> not image, but patches
<janrinze> Patches are fine, I have around 8 different kernel trees but i assume it is the for-kernelci branch that you have patches for, right?
<janrinze> jenneron[m]: The google chromeos kernels don't have working sound either. I wonder if HP has their own kernel branch for this device.
<jenneron[m]> yes, only for-kernelci
<jenneron[m]> google (chrome os) has a different userspace
<janrinze> I currently run 6.6.18 from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-6.6 which is a tad faster on NVMe and possibly has better compatibility with Debian 12. (some graphics issues with 6.8 are apparent and may be related to mesa API changes.)
<weirdtreething[m]> I would stick to the version that chromeos uses
<weirdtreething[m]> I don't think google works on specific platforms outside of the kernel version used by cros
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
<jenneron[m]> janrinze: btw, does your snow have modem?
dcz has joined #linux-cros-arm
<jenneron[m]> hexdump0815: FYI: we have some success with spring
<jenneron[m]> although it has no battery support, and i'm not sure that it will ever happen
<jenneron[m]> i tried getting battery to work here
<jenneron[m]> but it just hangs when reading i2c, i don't know how to fix it
<janrinze> jenneron[m]: it has a simcard option. Have used that in the past when I could get an extra data sim for free with my phone.
<jenneron[m]> janrinze: oh cool, can you check `dmesg | grep usb` in pmOS to see if modem gets initialized?
<jenneron[m]> if not i think i can fix it with one patch
<jenneron[m]> i tried to find a snow board with modem a while ago, but they are very rare :P
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-cros-arm
<hexdump0815> jenneron[m]: thanks a lot for the updates about snow and spring - very happy to hear those - not much happening on my end currently but i hope to have some more time at some point again
<jenneron[m]> hexdump0815: i suggest you to make kernel as small as in pmOS (maybe use the same config) and use depthcharge-tools, so you can build a generic image for all exynos5 devices
<jenneron[m]> this way you can support spring and peach-pi without having ones
<jenneron[m]> the problem with depthcharge on these devices is that you need to fit kernel + initramfs + dtbs in 8M which is difficult, especially if you need initramfs (which pmOS needs for FDE), but if you fit it in 8M it works well
dcz has quit [Ping timeout: 480 seconds]
<hexdump0815> jenneron[m]: i'll definitely look into depthchargetools for the 64bit arm chromebooks, for 32bit i would prefer to stay with u-boot chainloading, but maybe depthcharge will be required for spring, so maybe i'll look into that direction there too
<hexdump0815> but all that when i find some time again ...
<jenneron[m]> hexdump0815: i tried getting usb to work in u-boot for spring. the problem is that usb ports are connected through a usb hub which needs its power sequence. i implemented it in u-boot according to kernel, but for some reason it doesn't work for me
<jenneron[m]> and since it doesn't have sd card.. the only way to boot it for now is depthcharge
<jenneron[m]> btw you have old spring images with downstream kernel which work well. you can suggest users to boot old image and then flash new image with u-boot on emmc. it should work
<jenneron[m]> or you can suggest users to flash pmOS image to USB, and install your image on eMMC from there
<jenneron[m]> it is quite annoying.. also, there is a bunch of veyron boards not supported in u-boot, but supported in kernel. we support them in pmOS using depthcharge
<jenneron[m]> which is not possible with u-boot
<hexdump0815> i'm also completely fine recommending pmos in case my images do not work for some hardware - its a very nice project and i like to see it (and its chromebook support) growing
<hexdump0815> its just that i prefer debian personally
<jenneron[m]> hexdump0815: it would be cool to integrate https://gitlab.com/postmarketOS/boot-deploy with debian or armbian or mobian. this would give a lot of ways to boot the distro by configuring a single "deviceinfo" config: depthcharge, boot.img, systemd-boot, grub, extlinux, etc
<jenneron[m]> we're trying to make boot-deploy distro-agnostic
<weirdtreething[m]> <jenneron[m]> "it is quite annoying.. also..." <- even on supported boards, it doesn't always work on every sku
<weirdtreething[m]> it seems like the 2gb skus of speedy don't work with u-boot