ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
juergh_ has joined #aarch64-laptops
juergh has quit [Ping timeout: 480 seconds]
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<robclark> steev: I might have missed it, but did you paste a splat (here or on list)
<steev> robclark: only related to the c630 and soundwire
<steev> it's a null pointer deref
<steev> i see the one about lpass cpu, but i don't think it applies to soundwire; but maybe?
<steev> it says reported-by but theres nothing about where it was reported
<steev> ah yeah, no that's not a driver used on the c630
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
<Segfault[m]> <JensGlathe[m]> "did you try this on EL2?..." <- no luck, same errors from the drivers
hexdump01 has quit [Ping timeout: 480 seconds]
<Segfault[m]> radeon just spits out a Fatal error during GPU init
<Segfault[m]> amdgpu does something slightly different, last time it froze but in el2 it hard rebooted
<Segfault[m]> yeah same nouveau error as well, some kernel null pointer dereference
DJVG has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<DJVG> Hi all! Trying to boot 6.12-rc1 on my thinkpad t14s using the in kernel EFI stub. Using the dtb= arg for the device tree. For a brief moment I see the tuxes and some lines of output (probably using efifb?) but then it goes black and it seems to be stuck. Tried with nomodeset, debug, boot_delay etc.. but no change.
<DJVG> As I do see some information briefly before turning black I get the idea it's trying to switch video modes or something (but was hoping nomodeset would ignore that). I tried multiple console= options too to see if it's actually a different virtual console but nah.
chrisl has quit [Ping timeout: 480 seconds]
<DJVG> I see some people online trying to boot it and they had different issues (related to PCIe) but at least they were able to get consistent output.
<travmurav[m]> DJVG: have you booted it before or this is the first attempt to boot linux?
<travmurav[m]> The kernel probably resets the display engine and/or display power so efifb dies
<DJVG> travmurav[m]: It's the first time I'm trying to get it to boot linux
<travmurav[m]> Might be some cmdline/kernel config missing then
<travmurav[m]> Advertisement moment: pmOS generic bleeding edge images now should work on x elite, it tracks linux-next so the intersection of devices in next and dtbloader should "just boot" to console at least
<DJVG> I think so too
<travmurav[m]> Intersection currently is vivobook, t14s, yoga slim
<DJVG> Cool, let me give that a try
<DJVG> That does something. It does detect the type of the laptop correctly but then still tries to use the dtb from the system itself and fails to boot. Let me see if the DTB is actually in there
<travmurav[m]> Ugh
<DJVG> Yeah "x1e78100-lenovo-thinkpad-t14s.dtb" is in there. Let me check how it actually selects it.
<travmurav[m]> So you just plugged the USB stick, it said "t14s", shown the penguins and crashed after?
<DJVG> Yes
<DJVG> it says Detected device: LENOVO Thinkpad T14s Gen 6
<travmurav[m]> DJVG: it uses https://github.com/TravMurav/dtbloader
<DJVG> Then it says usgin dtb from configuration table
<travmurav[m]> So it loaded the correct dtb file into the efi config table
<DJVG> and then failed to update fdt and exit boot services
chrisl has joined #aarch64-laptops
<DJVG> failed to execute postmarket os linux.efi load error
<travmurav[m]> Oh
<travmurav[m]> DJVG: how much ram?
<DJVG> 32
<travmurav[m]> Mhm
<travmurav[m]> Interesting...
<travmurav[m]> And sadly not the first time we see hlthis mess...
<travmurav[m]> On t14s specifically at least i think...
<DJVG> I also got a vivobook to test but I prefer my thinkpad haha
<travmurav[m]> anonymix007: you had broken ebs too iirc?
<travmurav[m]> DJVG: the other time you tried to boot it you just ran linux.efi from shell/boot order or used some loader?
<DJVG> I got uefi shell loaded with the kernel image with EFI stub embedded
<DJVG> Also tried to use grub instead with the devicetree option
<travmurav[m]> Could you try the same but boot linux.efi dtb= from the pmos image?
<DJVG> Yes, let me try that
<travmurav[m]> Check full cmdline in pmos.conf
<travmurav[m]> I guess might also need the initramfs, not sure if efistub allows loading that from cmdline
<travmurav[m]> But the first idea is to check if that kernel can ebs if there is no sd-boot behind it
<DJVG> yeah my first try was to get the kernel alone to do something, and I actually think it's working but just I can't see it
<DJVG> with dtb= on the command line
<DJVG> it's working!
<DJVG> pmos boot screen
<travmurav[m]> Nice
chrisl has quit [Ping timeout: 480 seconds]
<DJVG> After that goes to black again hmm
<DJVG> Saw "waiting for boot device"
<travmurav[m]> If it felt like 30 seconds, maybe it was still on efifb and linux killed the screen power since real display subsystem didn't load
<DJVG> Yeah I think that was it
<travmurav[m]> DJVG: can you do another test but remove dtb= and instead do "load efi\systemd\drivers\dtbloaderaa64.efi" before starting linux.efi? To see if that causes ebs fail
<travmurav[m]> Can add regulator_ignore_unused for that iirc (to prevent 30s thing)
<DJVG> Loaded the dtbloader driver and then ran linux.efi with the args (made a typo in the root uuid so got a kernel panic for rootfs) but at least that tells me that it did load the right dtb
<DJVG> Hardware name also included the right data
<travmurav[m]> hm so in this case it booted again, no ebs error...
<DJVG> Let me try the original boot again to see if something has changed
<travmurav[m]> DJVG: well, I guess then it would be even more interesting to try booting bootaa64.efi from the shell and see if /that/ crashes
<DJVG> That worked also now (although screen still goes to black after the pmos boot screen)
<DJVG> Let me reflash USB and see if it keeps working
* travmurav[m] is now even mroe confused at that ebs issue
<travmurav[m]> DJVG: for the pmOS image you may want to add `console=tty0 PMOS_NOSPLASH` to get more logs out
<travmurav[m]> might want to just edit the pmos.conf if the image is booting fine now
<DJVG> Fresh flash of the image to USB and it fails again
<DJVG> "Failed to update FDT"
<travmurav[m]> DJVG: also, you plug your usb stick into usb a, right? any chance you could try to use usb-c port? iirc there was some funny stuff before with usb-a not being brought up on some device...
<travmurav[m]> :S
<travmurav[m]> as in, ^^ is related to "boot device not found", not "failed to ebs"
<DJVG> If I look sd-boot from shell it runs fine
<DJVG> I cannot get it to run the original bootaa64.efi directly
<DJVG> if I go through shell it works
<travmurav[m]> so weird
<DJVG> Let me check the args
<travmurav[m]> but hm, I guess as long as we have a way to avoid that firmware bug, we can ignore it for now
<DJVG> Can always write a startup.nsh to work around it
<DJVG> Let me try over usb-c. Was able to get more output and It seemed to try something related to the nvme ssd but it went too fast
<travmurav[m]> but also usb in linux -> the whole thing kinda needs a lot of fun like firmware to work properly, pmOS image relies on usb being brought up by the firmware so I guess there are many chances for it to die
<travmurav[m]> that is, since qcom platforms manage parts of usb power via adsp
<DJVG> usb-c and straight to login prompt...
<travmurav[m]> \o/
<DJVG> So yeah good call on the USB part
<travmurav[m]> so I remembered correctly, cool
<DJVG> clearly something funky there
<JensGlathe[m]> does the t14s dts have the type-a USB part yet
<JensGlathe[m]> I've seen it on abelvesa 's tree and got inspired from it, but not sure if its in linux-next
<travmurav[m]> hm might not be, I think there is only the inintial dts
<travmurav[m]> so I guess makes sense then if there is more work needed
<JensGlathe[m]> then what you see is inaccessible boot device because type-a?
<travmurav[m]> considering it worked with type-c, clearly xD
<DJVG> Yeah the main issue was that it would go to blank, so couldn't see what it was failing on
<DJVG> Now I need to know the root login for pmos lol
<travmurav[m]> DJVG: user/147147
<DJVG> Nice! success!
<travmurav[m]> the display blanking was perhaps because the display stuff was not fully in the initramfs so drivers that'd pin the display power couldn't load
<travmurav[m]> and as soon as it could load them from rootfs, it's fine
<travmurav[m]> that is, some kernel modules
<DJVG> Yeah so it was all related to the usb-a port then. :(
<DJVG> I'll finally test to check if the boot works fine using sd-boot directly too
<travmurav[m]> FWIW there were /a lot/ of different complaints against t14s firmware specifically I feel
<DJVG> Nope, that still is a bit wonky. Still the failed to update FDT
<travmurav[m]> weirid ram allocation issues on the 64gb ones, EBS failures on other ones...
<DJVG> I'm happy to provide details about my specific machine if it helps
<travmurav[m]> well I think it's not even clear still what exactly causes it to fail (or not fail in case of using shell)
<JensGlathe[m]> vivobook probably similar, try type-c first
<DJVG> Interesting. I added startup.nsh to just directly start sd-boot.efi (I named it) and it gave me the same error
<DJVG> Is sd-boot expecting to load from a specific path? In my case my usb device is as "FS5"
<DJVG> when I go to fs5: and load sd-boot it works
<DJVG> I would expect the shell to be already on there tho, but it seems to make a difference
<travmurav[m]> no, it should be fine to load from anywhere
<JensGlathe[m]> there seem to be odd memory issues. efi shell almost always works, grub getting better in the newer incarnations (Ubuntu 24.10 one is quite usable), sd-boot works but is... sd-boot
<travmurav[m]> DJVG: sily idea but what if you add some delay in the startup script by monkeying around and making it list the files in the dir or something
<travmurav[m]> I guess it generally would be nice to figure out what causes the ebs failure: some delay, some input...
<DJVG> travmurav[m]: if I delay some things in startup.nsh and then call sd-boot it just will error out the same. If I directly boot to shell, prevent startup.nsh and directly exec sd-boot.efi it still works fine
<DJVG> So every single time I manually run it, it works, from script, nope. even if I delay it by 10 seconds running things like ls or acpiview
<travmurav[m]> so weird...
<travmurav[m]> DJVG: what if you set few second delay in sd-boot and "menu around" - stop the timer by pressing arrow keys then enter into the (only) boot entry anyway?
<travmurav[m]> that is, to check if keyboard input changes things
<DJVG> Sure! Also captured a dmesg in case it can be of any use.
<DJVG> travmurav[m]: Same error even if I wait for ~10 seconds in the sd-boot selection menu
<travmurav[m]> sad
<travmurav[m]> wth did they do with that firmware x
<DJVG> Another interesting thing seems to be that it returns to the lenovo boot selection menu but it hangs from there, I have do shut it down hard as it's unresponsive
<travmurav[m]> well linux has tried to EBS, so parts of the firmware are shut down by that point
<travmurav[m]> but something in the firmware refused to shutdown and it ended up in a broken state
<travmurav[m]> so it's not surprising that after trying to exit boot services and failing, things won't go smooth xD
<DJVG> Hmm interesting, because if I get the same error from the shell, I can return to the shell, execute again or even return safely back to the boot selection menu. Or is that because shell shuts things down "cleanly"?
<DJVG> ALso just guessing here
<travmurav[m]> well I'm not sure sadly, but afaik per the spec, as soon as you call exit boot services, should assume the firmware is torn down
<DJVG> I load the shell from usb too btw, not sure if this firmware has the shell buildin, but just got the most recent edk2 aa64 build
<travmurav[m]> hm do you use some boot order selector to pick the pmOS disk/shell?
<DJVG> Yes, I use the boot selection to select the USB drive
<DJVG> Mainly because the bios has no option to set the boot order lol
<travmurav[m]> what if you add i.e. sd-boot as the first default boot option via shell (using bcfg) and try booting without any user input whatsoever?
<DJVG> yeah I can try that
<travmurav[m]> bcfg boot add 0 blah\blah.efi "my os"
<travmurav[m]> iirc
<travmurav[m]> then can "bcfg boot dump" to check the order iirc
<DJVG> Testing that now
<DJVG> Same error but now with the nice lenovo logo error present
<travmurav[m]> sad
<travmurav[m]> so I guess whavever happens, it only works after manual input in the efi shell...
<DJVG> Wait, I think I found something that's valuable.
chrisl has joined #aarch64-laptops
<DJVG> It fails on the FIRST try. if I run startup.nsh again, it works.
<DJVG> Of course if you run sd-boot dirextly and it fails, it's stuck
<DJVG> but if I return back to the shell, run startup.nsh again, it boots
<travmurav[m]> so like you let it boot startup.nsh without touching the keyboard, it fails, then you drop into efi shell prompt and manually run it -> it works?
<DJVG> Yes
<travmurav[m]> I guess reaffirming that the "fixing state" is "after efi shell interactive prompt appeared"
<travmurav[m]> this is so weird
<DJVG> I'll try to put the sd-boot twice in there
<DJVG> to see if it works
<DJVG> Yes that works
<travmurav[m]> oh
<DJVG> So I just put "efi\boot\sd-boot.efi" twice in startup.nsh. First try fails, second one succeeds.
<travmurav[m]> interesting
<DJVG> I guess some config is lingering that gets used correctly on the second try?
<travmurav[m]> but it's not just repeating ebs, I think we tried that with anonymix007 ...
<DJVG> s/config/memory/
<travmurav[m]> it may do more random memory allocations on the second try but that won't exactly explain things
<DJVG> Do you think this is on the dtbloader part or sd-boot?
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]> the error I'd blame firmware for, the ""fix"" I'm not sure what does, both efi stub, sd-boot, and certainly dtbloader allocates memory, dtbloader modifies the system table as well
<travmurav[m]> but i have an impression that even without dtbloader and sd-boot if you put linux.efi into the startup.nsh, it fails?
<travmurav[m]> s/system table/ configuration table but it also installs a protocol
<DJVG> Can try that, one sec
<DJVG> Without using dtbloader but with the use of sd-boot: it says generting empty DTB and failed to update FDT.
<DJVG> Without using dtbloader/sd-boot and just linnux.efi directly it now also says generting empty DTB
<DJVG> And then of course hangs as there's no dtb
<travmurav[m]> but doesn't fail ebs?
<travmurav[m]> hm
<travmurav[m]> interesting
<DJVG> I was expecting it to take the system configuration translation?
<travmurav[m]> what about "load dtbloaderaa64.efi" then "linux.efi"?
<travmurav[m]> it tried to boot with acpi but that's a fruitless endevour, though you can add earlycon=efifb keep_bootcon and then even acpi boot should show signs of life
<DJVG> if i load dtbloader first and then linux.efi it succesfully loads
<DJVG> And says "using configuration from.."
<travmurav[m]> mhm so sd-boot does something
<travmurav[m]> yeah dtbloader puts the dtb into the configuration table for linux to find
<travmurav[m]> this is via startup.nsh that would've failed with putting sd-boot there I assume?
<DJVG> I'll try to load the dtbloader first, then start sd-boot in startup.nsh
<travmurav[m]> fwiw sd-boot autoloads it but I guess that would still be an interesting thing to check, to see if allocating extra memory by the first dtbloader changes things
<DJVG> Yup, does not make a difference
<DJVG> Let me try to load dtbloader + linux.efi from startup.nsh
<DJVG> Same error
<DJVG> failed to update FDT
<travmurav[m]> mhm
<travmurav[m]> but pure linux.efi earlycon=efifb boots?
<travmurav[m]> in the startup.nsh that is
<DJVG> FWIW if I try to run linux.efi after it failed to boot it say "invalid header detected on uefi supplied FDT, ignoring"
<travmurav[m]> fun, it might have corrupted the memory by that point
<DJVG> > "linux.efi earlycon=efifb" without any dtbs loaded?
<travmurav[m]> not sure if efistub overwrites the supplied dtb
<travmurav[m]> yeah it shoudl still print a bit of stuff
<travmurav[m]> at least the first few lines of the log
<DJVG> travmurav[m]: Generating empty DTB. Failed to update FDT
<travmurav[m]> sad
<travmurav[m]> so I guess it /is/ firmware then
<travmurav[m]> :S
<DJVG> I don't know enough about the order it loads data. But it is strange that first load fails but the next one works.
<DJVG> Any flags available that I can put to see what it's loading from where?
<travmurav[m]> I'm still assuming it's some weird memory fiddling that causes it to fail tbh
alfredo has joined #aarch64-laptops
<travmurav[m]> DJVG: this verison of dtbloader allocates extra 512MiB of memory, I wonder if you can try this + linux.efi and see if it changes anything
<DJVG> travmurav[m]: Same
<DJVG> Confirmed it says "Making 512 1Mib allocations"
<travmurav[m]> sad, I guess not as simple as throwing a bunch of memory out
<DJVG> And then still failed to update FDT
<DJVG> Interestingly if I then call linux.efi with earlycon
<DJVG> it does complain about the invalid header, but still says using dtb from configuration
<DJVG> and starts to boot but then hangs after it disables legacly bootconsole
<travmurav[m]> right, pretty much what I'd expect form earlycon=efifb
<travmurav[m]> the invalid header is weird I guess
<DJVG> So does that mean linux.efi also modifies memory or does the firmware modifies something after it has been initially read (sorry if I'm talking out of my as here)
<travmurav[m]> well, everything modfiies memory map as it runs, efistub allocates some, sd-boot does
<travmurav[m]> like even printing some stuff on the screen, calls memory allocations under the hood
<travmurav[m]> but now I'm not sure if it's just memory or something else as well
<travmurav[m]> this issue is really weird and I'm not sure what one shoudl really do to debug this beyoned throwing the ideas at the wall and see what sticks tbh xD
<DJVG> I probably misunderstand how some things are connected. I was thinking that htis "configuration data" is just a bit of static memory that's only consumed to make decisions on how to configure devices
<DJVG> """static"""
<travmurav[m]> there is efi configuration table which is filled up with entries by different things, i.e. firmware adds "acpi table" there; dtbloader adds "dtb table"; sd-boot/efistub adds "initramfs table"
<travmurav[m]> and these "tables" are pointers to other allocated memory where teh actual data is located
<travmurav[m]> i.e. in case of the dtb, "dtb configuration table" just points to the allocated memory region with the dtb, efi stub then sees it, copies it into another place (iirc) and adds stuff to it
<DJVG> Hmm sure, but if I run dtbloader it sets dtb table, then I run linux.efi -> it fails unable to update FDT, then i run linux.efi again, it does complain about some invalid header, but it does say using configuration table.. and continues to boot.
<DJVG> Actually let me verify what I'm saying here
<travmurav[m]> since for Linux, dtb is "the" way to pass info from bootloader to kernel proper, so things like initrams address are passed via dtb. (thats why you see "generating empty dtb" for acpi boot)
jhovold has joined #aarch64-laptops
<DJVG> One thing that really really weirds me out is that it always works fine when I start it from the shell directly (without startup.nsh). But startup.nsh is just executing those lines... fail to see how much difference there is.
<travmurav[m]> it might do some extra magic to get the input protocol or whatnot, but yes, it's very weird
<DJVG> There's cleary some memory weirdness happening.
<DJVG> When I boot with just linux.efi from startup.nsh it says: generating empty DTB and failed to update FDT
<DJVG> When I boot with dtbloader, then linux.efi (also fails: failed to update FDT), then linux.efi again (complains about invalid header AND empty DTB) , but it continues booting.
<DJVG> Hmm, scratch the last part. If I boot linux.efi twice (without loading any dtb/sd-boot) it also continues booting...
<DJVG> But then it hangs as it disabled efifb0
<DJVG> Correct
<DJVG> Yes
<travmurav[m]> right, just wanted to confirm it's the ebs that fails, not actual fdt moving/creation
<DJVG> First exit boot services failed
<DJVG> then failed to update fdt
<travmurav[m]> iow it fails in the firmware, not in the efi stub
<steev> DJVG: have you updated the bios to the latest it has?
<DJVG> steev: I got an update two days ago for a bios that was released early september
<DJVG> Let me get the version
<DJVG> steev: bios version N42ET59W (1.33) EC version N42HT50W (1.24)
<DJVG> Machine model is the 21N1CTO1WW
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<DJVG> The lenovo tool has no updates but then windows update has a "Lenovo - System Hardware Update" from yesterday.. let me check what that's all about
<DJVG> Installed it but no versions have changed... I guess some drivers
<steev> that's probably just device firmwares
<travmurav[m]> well considering it dies when running linux.efi directly...
<travmurav[m]> I'd not be surprised that the memory allocation mess is part of the problem
<travmurav[m]> maybe only trying to reserve 512MiB was not enough, should've tried 30GiB xD
<travmurav[m]> I guess the only thing I can say with confidence is that it seems like t14s firmware is a broken mess xD
<steev> which is a shame because the x13s is only kinda broken :P
<DJVG> xD
alfredo has quit [Quit: alfredo]
<travmurav[m]> DJVG: one last thing you can try, this dtbloader reserves ~30GB which would perhaps shoehorn all later alloactions into the 32bit space
<travmurav[m]> this is still hacky so no high hopes but what if xD
chrisl has joined #aarch64-laptops
<DJVG> travmurav[m]: No luck :(
<travmurav[m]> Sad
chrisl has quit [Ping timeout: 480 seconds]
martiert has quit [Quit: WeeChat 4.4.2]
martiert has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
cris has joined #aarch64-laptops
<anonymix007[m]> travmurav: yes, but ebs error is too inconsistent. Sometimes nothing works, sometimes just forcing the sd-boot menu and selecting the UKI works (even though it's already default). What never works is "normal" boot. And GRUB from a USB drive always works.
chrisl has joined #aarch64-laptops
<travmurav[m]> Right, I guess it's still something similar/same to ^^^
chrisl has quit [Ping timeout: 480 seconds]
checkfoc_us9 has quit []
checkfoc_us9 has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
<macc24> anonymix007[m]: sounds like a race between something and something else
srinik has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hipboi has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kalebris> is there any feature in 6.12 for the lenovo x13s that one should get excited about? I heard a lot of updates for the t14s, but not much for the older gen hw
<jhovold> kalebris: camera support
juergh_ is now known as juergh
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<Segfault[m]> oh jhovold on your sc8280xp-6.11 tree on my x13s some boots have broken bluetooth, judging by the commits i assume you already know but just a heads up if you don't
srinik has quit [Ping timeout: 480 seconds]
<jhovold> Segfault[m]: I pushed a fix on top for that after I realised bt was broken, are you running with that fix?
<jhovold> I'm also preparing a proper fix for mainline as we speak, will include it in the 6.12-rc1 branch this week too
<kalebris> w00t, that's pretty cool
<kalebris> huge thanks for everyone working on this
<Segfault[m]> <jhovold> "Segfault: I pushed a fix on..." <- the one labelled as a hack? yes
<Segfault[m]> but if you've got a proper fix in the works I'll give that a go when it's ready
srinik has joined #aarch64-laptops
<Segfault[m]> hm ok i'll give that a go at some point, either if i've got some spare time or whenever your 6.12-rc1 tree goes out
sri has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<jhovold> Segfault[m]: sounds good, thanks
<jhovold> how did the issue you see manifest itself?
<jhovold> do you get the same error that I included in the commit message for the fix?
chrisl has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
<Segfault[m]> <jhovold> "https://lore.kernel.org/lkml/202..."; <- i don't get the 0 RX bytes in line but i do get the others
<jhovold> ok, good, should still be a variant of the same issue
<abby> is this a known issue with the x13s camera on 6.11? [ 19.937094] ov5675 24-0010: failed to get HW configuration: -517
<abby> [ 19.938540] i2c 24-0010: deferred probe pending: ov5675: Failed to get supply 'avdd'
<abby> (6.11.1 with the rgb patch, everything else mainline)
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<macc24> abby: -517 sounns like a driver missing or a module not yet loaded
<jhovold> abby: you need some fixes as well as the sensor patch for functioning camera with 6.11 (see my wip branch)
<jhovold> I have seen the sensor probe deferr, but it always seems to probe successfully eventually here
<abby> media: qcom: camss: Remove use_count guard in stop_streaming
<abby> arm64: dts: qcom: sc8280xp-x13s: Enable RGB sensor
<abby> media: qcom: camss: Fix ordering of pm_runtime_enable
<abby> media: ov5675: Fix power on/off delay timings
<abby> those 4?
<jhovold> yep, those four
<abby> ack, thanks
<abby> any special modules?
chrisl has quit [Ping timeout: 480 seconds]
<jhovold> yeah, those would be enabled in johan_defconfig, don't have a list
alfredo has quit [Ping timeout: 480 seconds]
<erebion[m]> jhovoldDid you try Secure Boot on the X13s? If so, it'd be cool to have the status on the feature list.
<erebion[m]> Also, should lpac / lpa-gtk work for the eSIM?
<erebion[m]> If no one tried eSIM yet, I'll do that once that thing gets here. :D
cris has quit [Quit: WeeChat 4.4.2]
<abby> hm, adding the 3 other patches didn't help
<abby> i'm on the 20240909 release of linux-firmware, so everything should be there
<jhovold> yeah, I don't think those are related to the probe deferral issue
<jhovold> no firmware should be needed eitger
<jhovold> either*
<jhovold> the driver seems to complain about a regulator that should be there, so perhaps you're hitting a new bug related to probe order
<jhovold> erebion[m]: no, I haven't tested that
srinik has quit [Ping timeout: 480 seconds]
<abby> where is avdd defined?
<jhovold> avdd-supply = <&vreg_l6q>;
<jhovold> x13s dts
<abby> yeah i don't see it in there
<jhovold> vreg_l6q: ldo6 {
<jhovold> same dts
<abby> vreg_l6q is there
<jhovold> then what was missing again?
<abby> avdd-supply
<jhovold> it's there (in mainline, my wip branch)
<abby> oh wait i haven't applied the rgb patch in what i was searching
<abby> ok yeah avdd-supply is in cci2_i2c1 { camera@10 {}}
<abby> REGULATOR_QCOM_PM8008 m -> n
<abby> that seems like a smoking gun
<jhovold> yeah, heh, yeah, you need that one
<jhovold> the driver that provides avdd, sorry, I implemented the thing, but a little distracted right now
<abby> np, thanks for the help
<jhovold> abby: you'll also need the two CONFIG_DMABUF_HEAPS for libcamera
<jhovold> and the udev rule from the wiki: https://github.com/jhovold/linux/wiki/X13s#camera
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
nscnt[m] has joined #aarch64-laptops
nscnt[m] has left #aarch64-laptops [#aarch64-laptops]
<abby> yay working camera \o/
chrisl has joined #aarch64-laptops
zdykstra has quit [Quit: WeeChat 4.4.1]
zdykstra has joined #aarch64-laptops
alfredo has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
macc24 has quit [Quit: WeeChat 4.4.2]
zdykstra has quit [Quit: WeeChat 4.4.2]
zdykstra has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
<hogliux> jhovold: is the web cam on the yoga slim 7x the same as on the x13s? (crossing fingers)
<hogliux> jhovold: kind of hoping I could just copy over the dts changes to the yoga slim 7x :-)
hogliux has quit []
alfredo has quit [Remote host closed the connection]
<steev> abby: woo! sorry, i'd thought it was just the missing rgb sensor patch, didn't realize the other patches were required
<abby> yeah, this is what we needed on void: https://github.com/void-linux/void-packages/pull/52444
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev> oh right, the udev rule... clover[m] ^^
<clover[m]> ah lol
chrisl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
jhovold has quit [Ping timeout: 480 seconds]
<clover[m]> still no luck yet
alfredo has quit [Quit: alfredo]
<clover[m]> steev: im guessing you added the camera patch already
<steev> clover[m]: they all come from johan's stuff
<abby> what's in dmesg clover[m]
<JensGlathe[m]> ov5675 24-0010: failed to get HW configuration: -517 hmm
<steev> that's weird, it's like clover is hitting the same thing abby did, but clover has the patches
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> travmurav[m]: (and whoever else might be interested) a friend of mine got one of those new 8 core dell x1p and i managed to grab it for a moment to dump the acpi tables
<hexdump0815> travmurav[m]: they are available here now: https://github.com/aarch64-laptops/build/pull/111
<steev> oh nice
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Dell has them in their shop as a variant, xqp-42-100, same box available with x1p-64-100
chrisl has joined #aarch64-laptops
martiert_work has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
sri has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops