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
<louist103[m]>
Is that the same thing as kmscon?
<konradybcio>
no
<konradybcio>
kmscube renders a cube
<konradybcio>
it even spins
<louist103[m]>
Well we will see if it does then
<louist103[m]>
Yeah I may hold this for now lol [ebuild N ] sys-devel/llvm-18.1.8-r1 Don't exactly feel like building llvm atm
<steev>
it's not failing to find board-2.bin, it's failing to find your board's id in there
<calebccff>
steev: ah! yeah the ath10k stuff is such a pain XD
<calebccff>
well im trying to get a fresh installation going but the bootloader won't pick up the ESP I created :(
<calebccff>
really confused tbh, it picks up the usb drive
<louist103[m]>
I never had any real bootloader issues other than the fact that you can't have a dtb in a grub config
<steev>
you can, but without the ubuntu patches, it won't add it automagically
<steev>
you can manually add it yourself to the config after its generated
<calebccff>
heh
<calebccff>
pmos handles it natively
<louist103[m]>
steev: I see. Cause I didn't apply the audio patch you linked a few days ago yet. I wanted a working system before I messed with patches.
<calebccff>
not biased :3
<louist103[m]>
steev: I had to.
<steev>
louist103[m]: nah, that one doesn't work afaik
<steev>
louist103[m]: yes, that's what i'm saying, you have to manually add it without the ubuntu patches
<steev>
hm, one thing i do notice is that for some reason, despite upower reporting the battery, waybar says there isn't one
<calebccff>
hmm, don't see the GUID i pasted above
<steev>
i don't either
<steev>
maybe something in your efivars ?
bluerise_ has joined #aarch64-laptops
bluerise has quit [Ping timeout: 480 seconds]
<travmurav[m]>
calebccff: c12a is parttype for esp, not unique partuuid
<travmurav[m]>
so like any esp /should/ have that parttype
<travmurav[m]>
(using i.e. gparted this uuid set if you ask for flags -> esp)
rlittl01 has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
rlittl01 has quit [Ping timeout: 480 seconds]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
powpingdone has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
<powpingdone>
dumb question, is there a reason why a devicetree is supported over using ACPI?
krei-se- has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
ACPI seems to be a rudimentary implementation on these aarch64 boxes, doesn't do. The Windows drivers implement part of the ACPI functionality that it works on Windows. Apparently.
<powpingdone>
would it be apt to call ACPI a "bootstrap" configuration to install drivers later on a fresh install instead of something that actively defines the system?
<Painkiller995[m]>
Jens Glathe: Here is the error for the remoteproc.
powpingdone has quit [Remote host closed the connection]
<JensGlathe[m]>
Painkiller995: might not be the expected answer, but... thats okay. These firmwares are not on the image, should be able to boot without it. Of course its not found then.
<JensGlathe[m]>
Testing v4 of the image
<JensGlathe[m]>
it boots, without pd-mapper in the kernel
<JosDehaes[m]>
problem is all the entries are from april 19 😆
<JensGlathe[m]>
On early boot the clock is not synced, that's normal
<JosDehaes[m]>
yes I know, the rtc is not working yet
<JensGlathe[m]>
now let's compare this with a successful boot on the same box to see what would be next
<JensGlathe[m]>
preferrably debian
<JosDehaes[m]>
what would be next depends on systemd configuration I guess, kernel is long done
<JensGlathe[m]>
looks like it, yeah
<JensGlathe[m]>
systemd can be a hurdle though
<JosDehaes[m]>
yes, maybe systemd just reboots the machine?
<JensGlathe[m]>
for what reason
<JosDehaes[m]>
does not know what to do?
<JensGlathe[m]>
Same config comes up on sc8280xp
<JosDehaes[m]>
hmm
<JensGlathe[m]>
and the one deliberate reboot, I've disabled thaat unit
<JensGlathe[m]>
Hmm looks like maybe GPU for some reason. On my ref machine (the wdk running on EL2, also "no" firmwares) gpu will be accessed after that point.
<JosDehaes[m]>
I tried adding the firmware in initrd and in rootfs
einar has joined #aarch64-laptops
<einar>
is the x13s still in production?
iivanov has quit [Remote host closed the connection]
<JensGlathe[m]>
udev, and it has a problem with the edp panel. Last time I had this the dts was not quite right re display.
<JensGlathe[m]>
But, the yoga and the vivobook both reboot... there must be sth else
<Painkiller995[m]>
I'll try to test more over the weekend. I might be able to find something. I'm not testing enough.
<JosDehaes[m]>
BTW, I always have an oops for the panel
<JosDehaes[m]>
but works regardless
<JosDehaes[m]>
yes, the same trace on a successful boot of Arch
<JosDehaes[m]>
although, looking again at my journal output, I see it failed to load the zap firmware, while I did put it
<JosDehaes[m]>
it did load the gen70500.bin that I put
<JosDehaes[m]>
* `gen70500_gmu.bin`
<robclark>
JensGlathe[m]: the panel-edp WARN_ON() is "normal", it is just because we don't have the proper dts for panel yet (see dts patch I sent yesterday for 7x)
<robclark>
I don't think it is a systemd initiated reboot, we'd see something in the journal about that
<JosDehaes[m]>
no it's probably related to starting graphics/changing mode
<robclark>
idk if there is some kernel cmdline thing that will cause journald to flush to disk more agressively.. that plus udev.log-priority=debug might give a hint
<robclark>
I don't think it is gpu, I don't have fw in initrd.. although tbh I can repro this booting without initrd
<JosDehaes[m]>
I put it in initrd and in rootfs
<robclark>
I think we need to get bamse or someone with CRD or something with debug uart to repro.. hopefully over debug uart we can get an error msg from the fw
<robclark>
this kinda feels like an async SError
<robclark>
you could try removing gpu fw to rule out that it is gpu related, but I don't think that is it, it wouldn't explain why removing the udev rule "fixes" the reboot (I have DRM_MSM=y atm, there seems to be a separate issue with it =m but I was hoping to fix the udev reboot first)
<JosDehaes[m]>
it was already rebooting before I put the firmware
<robclark>
ok, that rules out gpu then
<JosDehaes[m]>
but it seems to happen at the point that it would try to switch to GUI mode
<robclark>
idk if the dev kit has debug uart, if it did I might be tempted to order one just to debug this, but hopefully bamse can repro with JensGlathe[m]'s image
<robclark>
if you remove gpu fw then gpu driver won't touch the hw
<robclark>
like I said I think it is async SError that tz or hyp is trapping and resetting the system, I see no indication that it is a HLOS initiated reboot
<robclark>
and since it is async the timing is a bit random
<robclark>
ie. _something_ writes some register or protected memory.. since write is async the reset happens at some point after the write
<robclark>
with debug uart (and possibly debug fw) there should be some error msg printed about the abort.. unfortunately that isn't something we can get at on production devices
<JosDehaes[m]>
just tried again, and the screen seems to switch to graphics mode for a millisecond and then fallback to text mode, then reboots
<robclark>
you could even just disable DRM if you have a way to ssh into it (usb-c eth adapter)
<robclark>
I'm pretty sure it will still reboot
<JosDehaes[m]>
I do have a usb c ethernet adapter
<JosDehaes[m]>
blacklist drm ?
<robclark>
easier just to disable it in kernel config if you can rebuild kernel.. or if built as modules delete/move them
<JosDehaes[m]>
oh, on Jens' kernel, drm is builtin
<robclark>
you can try msm.modeset=0 on kernel cmdline
<JosDehaes[m]>
with my kernel that boots on the nvme, I can't get the USB image to boot
<JosDehaes[m]>
ok that I can do
<jannau>
have you tried disabling runtime PM? SError on boot reminds me of the issue we saw on asahi devices with the sd-card reader. The driver doesn't support runtime PM but udev might enable autosuspend before the driver is bound. The SError occurs when reading from the device's BAR. it is possibly be apple specific though
<JosDehaes[m]>
still reboots, but now I don't have any logging on console
<robclark>
no logging on console is expected with that
<robclark>
jannau: hmm, is there cmdline to disable runpm.. I suspect that will lead to problems for anything that isn't left on by uefi but I guess worth a try
<jannau>
I don't think there's cmdline argument
<konradybcio>
Jos Dehaes: where did you get your zap fw from?
<JensGlathe[m]>
dumb q: could be some other device in x1e80100.dtsi
<JensGlathe[m]>
a lot of those are not disabled
<konradybcio>
Jos Dehaes: they seem to be failing because loading is attempted before rootfs is mounted
<konradybcio>
so, they're just not there yet
<JosDehaes[m]>
ah that explains the no such file or directory
<JosDehaes[m]>
because the path is right
<JosDehaes[m]>
there is rootdelay=20 on the cmdline
<JosDehaes[m]>
I have them in the initrd too
<JosDehaes[m]>
oh wait, I don't, forgot to change the initrd line in grub apparently
<robclark>
JosDehaes[m]: the zap fw needs to be in qcom/x1e80100/LENOVO/83ED/qcdxkmsuc8380.mbn(.xz)
<robclark>
not in the qcom directory
<JosDehaes[m]>
yes, it's there
<robclark>
(that is the path for 7x, the path will be different on other laptops)
<robclark>
hmm, is size 0?
<JosDehaes[m]>
no
<robclark>
maybe it is not in initrd, but that should be fine the driver will try again later
<robclark>
other thing, if the zap is copied from a different laptop model (at minimum, from different OEM) the signing might not match
<JosDehaes[m]>
no it's all from same yoga
<robclark>
hmm, well somehow `__free_fw_priv: fw-qcom/x1e80100/LENOVO/83ED/qcdxkmsuc8380.mbn fw_priv=0000000013c47e37 data=0000000000000000 size=0` is significant
<robclark>
looks like your other fw's are zst compressed (but not being compressed should be ok AFAIU)
<JosDehaes[m]>
-rw-r--r-- 1 jos jos 12K 16 jul 11:04 qcdxkmsuc8380.mbn
<JosDehaes[m]>
when I add the firmware, repack the initrd, and use that one, it fails to mount root filesystem 🤔
<JosDehaes[m]>
need to stop now though, I have to interview a candidate rust dev 😅
<mjeanson>
JensGlathe[m]: in your linux_ms_dev_kit repo you report successfully running an el2 kernel on a wdk2023, could you tell me which specific build it is?
<mjeanson>
I tried all the el2 builds from your google drive and none got past "exiting boot services"
<mjeanson>
the regular 6.10.0 works without issues
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
flokli has quit [Ping timeout: 480 seconds]
flokli has joined #aarch64-laptops
<steev>
lumag: btw, i just noticed something, the yoga c630 stuff that is in 6.11, doesn't seem to export(?) charge_now (or capacity) - this causes waybar not to work; i'm not sure which is at fault though.
<louist103[m]>
Oh thats not great. That was not intended.
<louist103[m]>
I'm too used to discord lol
<louist103[m]>
Sway works with the use flags. NGL had a mild panic attack when I saw the machine paniced on boot the quickly remembered the broken kernel is the default