ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
bamse: before i test them.. those geni patches... i shouldn't use on the flex if i want a (somewhat) working system?
<clover[m]>
not sure if that's correct. couldn't figure out mcopy from docs so i just tried matching the existing syntax
<steev>
weird that is says unsupported
<clover[m]>
maybe i need Image.gz?
<clover[m]>
like does it expect it to be compressed
<steev>
i have no idea what systemd boot requires, no other system requires it
<bamse>
steev: they won't break anything, just make things better
<bamse>
steev: the problem i have on flex 5g, is that on linux-next as soon as we try to do a DMA operation in the i2c driver we screw up the busses or something...still trying to figure out why that is
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<steev>
oh, yeah i'm still on 5.19
<steev>
and also... something linus pulled in recently broke audio
<steev>
not sure what though since nothing sticks out, but the audio device is probe deferred
<steev>
soc@0:sound msm-snd-sdm845: MultiMedia1: error getting cpu dai name
<steev>
srinik: ^
<clover[m]>
<steev> "you should be able to look at..." <- good point
<qzed>
I think that's the same output I get without efi=novamap
<steev>
at that point it should be jumping to the kernel - you might want to add earlycon=efifb
falk689_ has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
<qzed>
huh, I didn't know that uefi also provides a rtc interface...
<qzed>
in true fashion for our devices, it seems to be unusable though
<steev>
there is something about qcom's rtc... i can't remember what
<steev>
i found it somewhere in their forums
<qzed>
afaik it's not accessible from the unsecure world or something
<qzed>
yeah, you've posted that before
<steev>
yeah, something along those lines
<qzed>
I was able to read from that though... but with the uefi interface not even that is working
<steev>
bamse: do you happen to know if 300MHz was left off of the sc8280xp dtsi for a reason? is it broken on !thinkpad ?
<szclsya[m]>
steev: I'm currently using your kernel tree and is stuck at no filesystem to mount as root, do you have similar trouble?
<szclsya[m]>
(my root fs is currently on a usb drive, probably USB stack issue?
<steev>
szclsya[m]: if you aren't using an initramfs, you need to build usb in to the kernel
<steev>
if you are... try the other usb port
<qzed>
i.e. figure out what kind of magic incantation needs to go into the config, or alternatively what kind of magic incantation needs to go into initcpio.conf (or the equivalent conf)
<qzed>
you should be able to trace everything from the '.compatible's in the dts
<szclsya[m]>
Hmm... I'm working upon the laptop_defconfig in the tree and seems that it has the USB stuff built in already
<szclsya[m]>
Lemme check qualcomm specific drivers
<steev>
no, definitely doesn't have it built in
<steev>
you might need the phy qcom usb stuff
<steev>
at least, the phys aren't
<steev>
or maybe it doesn't need them
<szclsya[m]>
Just checked my .config, CONFIG_PHY_QCOM* are already on
<szclsya[m]>
I'm using ext4 which is also built into the kernel, hmm...
<steev>
maybe i should attempt to pull in qzed's usb stuff, but i need to do some other things away from the computer
<szclsya[m]>
Wait, just realized I didn't build various TYPEC stuff into the kernel
<szclsya[m]>
Lemme do a rebuild real quick
<steev>
or throw them into the initramfs, then you wouldn't need to rebuild the kernel
<steev>
there are however, comments in the dts to define usb-c connector properly, so it may not be fully working just yet regardless
<szclsya[m]>
Right... Should take a look at how to do initramfs manually (I just relied on dracut and mkinitcpio before
<steev>
what distro are you using?
<szclsya[m]>
I'm using Arch (btw) on my x86 thinkpads
<bamse>
steev: in the cpu opp-table?
<steev>
bamse: yeah
<steev>
i added it in here, and all seems to be okay on the thinkpad at least
<steev>
szclsya[m]: i mean on whatever device you're using my kernel on
<szclsya[m]>
I'm just manually building the kernel right now
<steev>
but which device? lol, i have many trees
<steev>
well, branches
<szclsya[m]>
Ah sorry, the X13s
<bamse>
steev: i believe the opp-table is a dump of the frequencies on my first x13s
<bamse>
steev: if there's things missing now that we've hit production, please do send me patches
<steev>
bamse: will do :)
<clover[m]>
<steev> "at that point it should be..." <- testing
<szclsya[m]>
Huh the behavior changes. It panicked before, but now it just gives me a blank screen after some messages on screen without resetting. I guess it might be running as I didn't specify panic=0
<szclsya[m]>
Should I extract the firmware first?
<steev>
szclsya[m]: same thing i told clover, earlycon=efifb :)
<steev>
should boot and be usable without the firmware (minus the charging)
<szclsya[m]>
Been using it all along
<steev>
you might wanna get with clover though, they're using the mkarchiso thingiemabobber
<steev>
i haven't used arch in a long time, minus their wiki, which is stellar
<steev>
though, they're doing an install it seems, not just running off usb
<clover[m]>
<szclsya[m]> "(on clover..." <- Leo if you wanna try the latest artifact is pushed to my fileshare maybe you can at least get a serial console working now.
falk689_ has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<szclsya[m]>
<clover[m]> "Leo if you wanna try the..." <- archiso?
<clover[m]>
still confused why systemd-boot option `devicetree` says 'Unsupported', but kernel option `dtb=` works
<bamse>
clover[m]: when i tried that on my machine the kernel would claim that secure boot was enabled and it ignored it...and hence booted with acpi anyways
<szclsya[m]>
thx
<clover[m]>
bamse the works you are saying i don't understand T_T
<clover[m]>
words*
<steev>
clover[m]: record the boot with a video, then watch it back and pause it very near the beginning and it should say ACPI: Interpreter disabled. if it's not using acpi (i believe)
<steev>
welcome to debugging without serial console :P
<clover[m]>
Will try later. Maybe Leo can capture with serial. Out getting sammich
<steev>
szclsya[m]: you have serial?
<bamse>
clover[m]: dtb=foo.dtb is supposed to make the kernel reach into uefi and load foo.dtb...what i'm saying is that on my device it refuses to do that...and therefor boots with acpi instead
<szclsya[m]>
I have the devices but hasn't try them yet
<szclsya[m]>
But I believe my device tree should be working, use dtb=/path/to/device/tree in cmdline with systemd-boot
<steev>
that seems like a bug if systemd-boot isn't using devicetree option properly
<szclsya[m]>
Yeah, I had the same issue with sd-boot's devicetree config line
<steev>
and i'd assume systemd had a release since then
<szclsya[m]>
I can see the kernel log now with rootwait
<szclsya[m]>
Weird, the kernel is able to load USB 2.0 and 1.1 drivers and usb-storage driver, but it should show a message recognizing my usb drive, but it doesn't
<szclsya[m]>
Probably because it didn't load USB 3 drivers? Since my drive is a USB 3 one
<qzed>
I'd guess it should still work via usb2...
<qzed>
do you have CONFIG_USB_STORAGE and CONFIG_USB_UAS built in?
<steev>
storage should be, uas is a module, in the defconfig, at least
<szclsya[m]>
I changed them to built in, no dice
<szclsya[m]>
https://fars.ee/nsiy The kernel .config file I'm currently working on
<steev>
i didn't realize \ for the path works with the kernel
<steev>
that's cool
<clover[m]>
from systemd-boot notes:
<clover[m]>
>Note that all paths used in the configuration snippets use a Unix-style "/" as path separator. This needs to be converted to an EFI-style "\" separator in EFI boot loaders.