03:57 <steev> hmm, yeah, even with 6.12, the debian kernel doesn't show a camera for the x13s

04:44 <dgilmore> steev: does is show with the libcamera tools?

04:45 <dgilmore> https://www.irccloud.com/pastebin/1x14aKI2/

04:45 <steev> nope

04:46 <steev> looks like maybe it's because of no udmabuf in the kernel?

04:47 <dgilmore> 6.12.6-200.fc41.aarch64 is what I am running

04:47 <dgilmore> grep -i udmabuf /boot/config-6.12.6-200.fc41.aarch64

04:47 <dgilmore> CONFIG_UDMABUF=y

04:47 <dgilmore> maybe

04:49 <dgilmore> mine is currently not actually working

04:49 <dgilmore> https://www.irccloud.com/pastebin/ag0l7Tz0/

04:50 <steev> i'm rebuilding the debian kernel with it enabled to test

04:54 <dgilmore> https://www.irccloud.com/pastebin/4w6ld9gX/

04:58 <dgilmore> works okay after a reboot

04:59 <dgilmore> well okaish, quality is not great

05:03 <steev> that's due to the lack of ir sensor i think?

05:04 <steev> and yeah i've seen that cma alloc error before too

05:04 <steev> bryanodonoghue: ^^

05:53 <travmurav[m]> @_oftc_SpieringsAE:matrix.org: for u-boot I'd expect mainline u-boot to just use mainline dtb carried from linux

05:56 <travmurav[m]> SpieringsAE: that is, mainline u-boot usually syncs up their dtbs with mainline linux, so ideally your board would have latest dtb installed via u-boot, and it would place it into the efi configuration table (same way dtbloader does) and also provide EFI_FIXUP_PROTOCOL (same way as dtbloader) for things like sd-boot. AFAIK on risc-v it's actually required sicne bootlaoder is supposed to update the dtb with some cpu specific things

05:56 <travmurav[m]> and so that protocol was made initially for risc-v purposes

05:57 <travmurav[m]> SpieringsAE: so ideally I'd expect one to not need dtbloader on u-boot platforms, though I believe there is some smbios support in u-boot that could make it possible

06:07 <travmurav[m]> SpieringsAE: https://elixir.bootlin.com/u-boot/v2025.01-rc4/source/arch/riscv/lib/fdt_fixup.c#L156-L160

06:07 <travmurav[m]> I think you want this fixup to happen on your dtb

06:07 <travmurav[m]> (though I'm afraid I don't exactly know the risc-v bootflow)

06:10 <travmurav[m]> ah apparently the dt node is deprecated now and they use a dedicated efi protocol, so u-boot would expose that proeprly even if the dtb wasn't fixed up by it

06:11 <travmurav[m]> still I'd expect u-boot system to populate the dtb configuration table on it's own, with no dtbloader needed

06:12 <travmurav[m]> which is what, ideally, should happen on all systems that target linux/dtb boot

06:12 <travmurav[m]> of which commerical woa ones only x13s is I guess

09:17 <SpieringsAE> travmurav: interesting, I am currently loading my own test dtb with grub, and it seems to just work, or will grub automatically call that EFI_FIXUP_PROTOCOL on the devicetree I load with it?

09:19 <SpieringsAE> but yeah, dtbloader seems redundant indeed

09:21 <SpieringsAE> Couldn't this cause an issue though, from my understanding uboot on riscv likes using FIT images with the dtb in it. But if the kernel updates something, uboot will still have an old dtb untill that updates too

09:34 <travmurav[m]> SpieringsAE: grub doesn't have efi_dt_fixup_protocol but sd-boot has, though apparently u-boot implements a different protocol now, that linux consumes directly, without grub/sdboot/etc involvement so I guess it works that way

09:35 <travmurav[m]> SpieringsAE: dtbs should theoretically be both-ways-compatible but yeah with out-of-band dtb you want your u-boot to be up-to-date all the time indeed

09:36 <travmurav[m]> SpieringsAE: I guess worst case if you really need to override the dtb, there is a cmdline param in the efistub

09:39 <SpieringsAE> well grub seems to do fine at overriding the dtb when I use the devicetree parameter, already tested some dtb changes with it

10:16 <kettenis> SpieringsAE: it might not have reserved memory regions marked correctly in the dtb if you do it that way

10:17 <kettenis> but the EFI memory map should be correct so that probably isn't an issue

10:18 <travmurav[m]> linux strongly prefers uefi memory map to the dt one

10:18 <noisycoil[m]> steev: Kali became installable again on apple silicon

10:18 <travmurav[m]> all of our woa devices would've been crashing terribly if that wasn't the case considering there are random carveouts all over the place :P

10:19 <noisycoil[m]> steev: If you are interested you'll find an asahi branch at https://gitlab.com/NoisyCoil/kali-arm/

10:23 <noisycoil[m]> It currently uses my own deb repo for the kernel and mesa drivers (and u-boot, but this is not so important). The mesa drivers are exactly the same as https://salsa.debian.org/bananas-team/wip/mesa-asahi. The kernel is from the kali branch at https://gitlab.com/debian-asahi-nc/linux-asahi and it is the one at https://salsa.debian.org/bananas-team/wip/linux-asahi + the non-hardware-specific patches kali uses for 6.11

10:24 <noisycoil[m]> (The hardware-specific patches are of course useless on apple silicon so I just ignored them)

10:26 <noisycoil[m]> The branch in the kali-arm repo currently produces images good for booting from usb (to build an image compatible with the asahi installer one should split up the boot and root partitions in two separate image and produce suitable json metadata). To boot from usb you must still install the asahi bootloader

10:28 <noisycoil[m]> For the record, I'm not maintaining kali, I just push updates once in a while, but right it's quite up-to-date (except for the kernel which I'll upload later)

10:30 <noisycoil[m]> Ah and builds of the kali image were tested only on arm64 (specifically, from Debian testing running on apple silicon itself)

14:04 <HdkR> https://videocardz.com/newz/geekom-launches-first-core-ultra-9-285h-mini-pc-ryzen-ai-and-snapdragon-x-systems-also-revealed A bit more geekom snapdragon stuff. Looks like they don't expose the additional PCIe lanes. What a shame, also only X1E-80-100 instead of X1E-84-100

14:08 <SpieringsAE> it has intel wifi instead of the default qualcomm chipsets so far, so I guess actually m.2 module?

14:09 <SpieringsAE> very interesting display/usb layout as well

14:13 <kettenis> intel 2.5G Ethernet as well

14:14 <kettenis> so that must be using a PCIe lane

15:13 <JensGlathe[m]> This sounds like dev kit with working hdmi / dp ports

15:14 <HdkR> And a lower clocked SoC

15:26 <JensGlathe[m]> Oh right. compile time on dev kit 28m vs HP X14 40m

15:44 <JensGlathe[m]> but thesewill be sorta nice anyway and have their uses

16:53 <steev> noisycoil[m]: oh nice :) asahi is only m1 to m3 right now?

16:53 <noisycoil[m]> No m3 :-( m1 and m2

16:58 <noisycoil[m]> (About half an hour ago I pushed linux-asahi 6.12.8-2-1kali1 to my deb repo, which is linux 6.12.8 + asahi patchset 2 + bananas patchset 1 + kali patches)

18:21 <steev> dgilmore: hm, no it's not udmabuf either, i wonder what the heck it is

18:22 <dgilmore> steev: :( I can paste fedora's config

18:22 <steev> oh

18:22 <steev> i wonder if we don't have the sensor

18:23 <steev> yeah, that's what it is :D

18:23 <steev> debian doesn't have VIDEO_OV5675

18:24 <clover[m]> I had to give my m1 pro laptop back to my old company. My desk felt cold so i decided to get a pi 5 to play with. Man the coil whine / fan on that thing is loud

18:26 <steev> just take the fan off, bonus of getting more heating :P

18:26 <travmurav[m]> big-hunk-of-aluminium passive coolers ftw

18:27 <dgilmore> steev: you will need that

18:27 <steev> indeed :)

18:27 <Jasper[m]> steev, m3 is left out because there's no M3 Mac Mini to easily debug

18:27 <steev> Jasper[m]: i only have acccess to an m1 anyway, but i know we have users who have m3/m4

18:28 <Jasper[m]> M4 will be in luck I guess, dunno what they'll do with M3

18:34 <leio> Jasper[m]: err, https://social.treehouse.systems/@marcan/113424156602040386

18:36 <Jasper[m]> leio aha! thanks for that

18:36 <Jasper[m]> I love spreading misinformation on the internet

18:50 <steev> heck yeah leio

18:50 <steev> but also, happy new year, hope things are well in gentoo land

18:53 <leio> heck yeah on what? :)

18:53 <leio> happy this year :)

18:54 <leio> I'm a bit out of touch, just helped sam a bit on gstreamer bumps

19:20 <noisycoil[m]> <Jasper[m]> "steev, m3 is left out because..." <- I don't think this is true, Marcan recently posted on mastodon about this argument

19:21 <noisycoil[m]> Ah yes, the one above

19:21 <Jasper[m]> Got corrected, thank you

19:21 <noisycoil[m]> Yep, sorry, hadn't seen it yet :-)

19:23 <steev> Heck yeah on the correction. It’s good for my knowledge too

20:07 <agl> steev: Do you patched Kernel 6.12.8 but haven't pushed it on your web site?

20:08 <agl> steev: The last kernel is 6.12.4 on your web-site at github.com.

20:15 <steev> agl: correct, i haven't pushed yet

20:19 <anthony25> I looked closer to the wakeup due to USB on my lenovo slim 7x (x1e), I realized that there is one wakeup that if disabled, the laptop crashes and reboots directly

20:19 <anthony25> soc@0/a0f8800.usb/a000000.usb

20:20 <anthony25> same thing if I remove the 'wakeup-source' directive from the USB devices in the dts

20:49 <agl> steev: I wait so long until it is pushed ...

22:56 <dgilmore> I created a new image for the t14s, with it as soon as I touch the keyboard or mouse I get the bluescreen and it reboots. I assume I am missing some firmware in the initrd thats causing something to not work right. as the same kernel works when booted from usb

22:56 <dgilmore> does anyone have an idea which?

23:28 <steev> bleh, also forgot camss apparently

23:29 <dgilmore> https://www.irccloud.com/pastebin/kvTP5IvB/

23:30 <dgilmore> seems the t14s's panel is unkown

23:30 <steev> not uncommon

23:32 <dgilmore> still no clue why the keyboard and mouse kill the system

23:34 <steev> that is odd. they shouldn't require any firmware though

23:34 <steev> that should be i2c

23:34 <steev> or maybe usb if unlucky

23:35 <dgilmore> its i2c

23:36 <dgilmore> anytime I use them the screen goes blue and the system restarts

23:36 <steev> anything in the journal ?

23:36 <dgilmore> I am currently sshing in, an external usb keyboard is fine

23:39 <dgilmore> nothing in the journal

23:49 <dgilmore> alright got something

23:49 <dgilmore> https://www.irccloud.com/pastebin/LeljIhxM/

23:50 <dgilmore> I ran journalctl -fl then touched the touchpad and got that

23:52 <dgilmore> I had been blacklisting qcom_q6v5_pas as I could not boot from usb without doing so