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)
<robclark>
w/ systemd-boot the kernel/initrd/dtb's all go on the ESP so you want a bigger ESP (and the ext4 boot partition you might use w/ grub serves no real purpose)
<robclark>
steev: btw, I guess lack of battery status is known issue?
<robclark>
(also, my xps13 looks positively clunky next to the x13s)
<HdkR>
robclark: You're missing pd-mapper in that case
<robclark>
hmm, nothing along that name shows up in dnf
<steev>
robclark: it might be called something different in fedora? in debian, it's called protection-domain-mapper
<robclark>
pd-mapper, I just built from git with HdkR's instructions
<robclark>
I think fedora is just behind on packaging bits for shiny new platforms
<steev>
smh, that’s been around for ages (in Debian it’s packaged as protection-domain-mapper thou for whatever reason)
<steev>
But yeah you need qrtr and pd-mapper for the battery to charge
<steev>
Afaiui, without that, it won’t charge the battery either, it just won’t power off when the battery dies
<robclark>
hmm, for how long it's lasted so far without charger plugged in I assume it must have been charging
<robclark>
I guess we'll see if I suddenly disappear ;-)
<steev>
Lol
<steev>
You should get ~10 hours of battery life, give it take
<robclark>
but I could believe that fedora is a bit behind the ball on "silly embedded nonsense hacks" ;-)
systwi_ has quit [Ping timeout: 480 seconds]
systwi has joined #aarch64-laptops
<steev>
i believe they have an upstream first, mentality, so if things aren't upstream, they won't allow is
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
stirl has joined #aarch64-laptops
<stirl>
clover[m] -- had another failed attempt tonight. Seemed like everything was alright but the linux bootloader option in the boot menu doesn't do anything :/ not sure what I am doing wrong
<cenunix[m]>
stirl: I’m assuming you have secure boot turned off in the bios?
<cenunix[m]>
I’m having the same issue right now, if you mean when first booting pressing f12, when I click on Linux boot manager it just does nothing. Black screen for a second then returns me to previous screen
Cyrinux9 has quit []
Cyrinux9 has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
systwi_ has joined #aarch64-laptops
systwi has quit [Ping timeout: 480 seconds]
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
Hello, my "Samsung Galaxy Book S (8cx Gen1)" notebook runs with Debian 12, the kernel 6.1.8, X11 and Bluetooth mice! WLAN and the battery status does at this time not yet work. But it runs :-)
<jenneron[m]>
battery is not going to happen any time soon
<jenneron[m]>
we need someone else to work on it, because i don't want to study about reverse engineering windows drivers
<qzed>
does it use something custom or is it similar to the lenovo/qualcomm thing? (I think the x13s and flex 5g use the qualcomm thing, right?)
<jenneron[m]>
another way might be to find an owner of x86 version of this laptop which may have more battery info in ACPI tables
<jenneron[m]>
qzed: apparently it uses some samsung EC sitting on 5-6 i2c lines without much info in DSDT
<qzed>
ah, that sucks :/
<agl7-Galaxy>
jenneron[m], Hello jenneron :-), I download the firmware-for-Galaxy-book-s from your gitlab.com/jenneron account, but I don't know in which directories under /usr/lib/firmware the different files I have to put!
<jenneron[m]>
qzed: i'm not 100% sure, because it seems that most part of logic is in drivers, but i have also tried that qualcomm thing, it doesn't work on this device
<jenneron[m]>
i couldn't find schematics for galaxy book s
<jenneron[m]>
i found for lenovo flex 5g and at some point for surface pro x
<jenneron[m]>
but not this one
<qzed>
hmm that sucks...
<qzed>
hmm, the driver dump you sent has a "Qualcomm PMIC Battery Miniclass Driver"
<qzed>
So I think emuec and qcbattminiclass850 is what you might want to look at... but I'm not sure what the latter exactly is
agl7-Galaxy has quit [Quit: Leaving]
<qzed>
could also be some weird remnant from something else because it's 850 and not 8180
agl7-Galaxy has joined #aarch64-laptops
agl7-Galaxy has quit []
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
jenneron[m]: WLAN does now work. This IRC connection goes over the WLAN port :-)
<agl7-Galaxy>
I have not yet installed Debian on the internal SSD (UFS). I boot from an USB-Stick.
<agl7-Galaxy>
jenneron[m]: What is working on the GALAXY Book S: UFS-qcom-driver, usc-c access, WLAN and Bluetooth (mice)!
<agl7-Galaxy>
jenneron[m]: Was is NOT working: Accu/Battery device, sound and microphones !
<qzed>
I think sound/microphones is currently not working across all sc8180 devices
<agl7-Galaxy>
ok
<agl7-Galaxy>
jenneron[m]: What also work: SSD access to an external USB-C-Box, LAN access over the Ethernet interface (realtek chip) int the usb-c-box. LAN access over a 2,5 Gbit Ethernet adapter (usb-c) which is connected to the usb-c-box
<agl7-Galaxy>
What also not work ist the light of the keyboard :-(
<agl7-Galaxy>
jenneron[m]: Thanks for the status
agl7-Galaxy has quit [Quit: Leaving]
Xyaon has joined #aarch64-laptops
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
jenneron[m]: Do you know that at boot time the kernel needs some time and wait. After ca. 10 seconds the boot goes on. When I look into dmesg there is CPU dump/trace. Do you wish to have a look on my dmesg message?
<agl7-Galaxy>
Ther is a little problem an a CPU is dumping
<jenneron[m]>
i have this device
<agl7-Galaxy>
jenneron[m]: Du you from Ukraine where the War is?
<jenneron[m]>
i am
<agl7-Galaxy>
I'am also in Europe Germany
agl7-Galaxy has quit [Quit: Leaving]
<Leandro[m]>
<agl7-Galaxy> "I'am also in Europe Germany" <- Basiert
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
jenneron[m]: Oh, Cinnamon works also and this in Hardware acceleration modus (not software rendering)!!!
mcbridematt has quit [Remote host closed the connection]
mcbridematt has joined #aarch64-laptops
<agl7-Galaxy>
jenneron[m]: The battery control does not work. Does the Galaxy runs on battery and not with power from the power supply?
<agl7-Galaxy>
When i have plugged in the power supply!
<jenneron[m]>
it doesn't charge
<agl7-Galaxy>
but the battte
<agl7-Galaxy>
but the battery is not discharged wehen the power suplly is connected, or?
<jenneron[m]>
I don't know
agl7-Galaxy has quit [Quit: Leaving]
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
jenneron[m]: The Cinnamon applet "battery/Accu" means the battery is discharging, but when I shut down after a longer time and the picture of the charging icon is displaying, it tells always 85%, so as it is not discharged.
<agl7-Galaxy>
jenneron[m]: I let running the galaxy now once more for a longer time and in a half hour i will go eating. Then I will look if the battery is a bit discharged.
<robclark>
bamse, HdkR, ajhalaney[m]: So at least one problem with pd-mapper/qrtr on fedora is that it is crapping 64b libs into /usr/lib instead of /usr/lib64
<robclark>
when I manually fix that, if I try running it manually I get `no pd maps available`
<robclark>
oh.. and I bet it doesn't understand .xz compressed firmware
<robclark>
yup.. that is the problem.. you probably want to use something like libarchive so you can deal with compressed fw
<HdkR>
robclark: Sounds like Fedora should support multiarch :P
<robclark>
for all the times I need to install ppc binaries on my arm laptop?
<HdkR>
Indeed
<HdkR>
Everyone wants to emulate xbox 360 and PS3 using binfmt_misc right?
<robclark>
heheh
<konradybcio>
@robclark do you have .jsn files in /lib/firmware/..
<robclark>
well, probably just pd-mapper and qrtr should use a grown up build system so it doesn't have this problem
<konradybcio>
these contain the pd maps
<robclark>
konradybcio: I have *.jsn.xz ;-)
<konradybcio>
yay for saving 300 bytes :P
<robclark>
well I manually uncompressed them.. but that is just a workaround for now
<HdkR>
Well, I won't debate that problem :)
<robclark>
distro cmpresses all the fw's which saves a lot
<konradybcio>
funnily enough adding support to read .jsn.xz to pd-mapper would probably increase the binary size by more than we save by having them raw
<robclark>
it doesn't realize that some fw's are for userspace to read (or that userspace is less capable than kernel when it comes to decompression :-P)
<robclark>
libarchive is a thing and easy enough to use
<konradybcio>
I pitched the idea of moving pd-mapper to kernel to bamse a few times..
<robclark>
anyways, maybe I'll find some time in the next couple weeks to type up MRs with meson and libarchive support
<robclark>
that should also make it easier for more distros to package
stirl has joined #aarch64-laptops
agl7-Galaxy has quit [Quit: Leaving]
<ajhalaney[m]>
bamse has even floated the moving to the kernel idea. That's been on my list robclark are you using my copr for pd-mapper? I'll look into it later this weekend hopefully
<ajhalaney[m]>
I have intended to package it officially but never done that and also don't totally get what it does lol so was waiting till I got around to understanding it
<ajhalaney[m]>
Think I got burned by that lpg bug with the backlight like half of yesterday fwiw when trying to figure out missing bits for Fedora kernel to sort of work. Hopefully continue on that effort soon too
stirl has quit [Remote host closed the connection]
stirl has joined #aarch64-laptops
<robclark>
ajhalaney[m]: oh, didn't realize you had a copr
<robclark>
steev: hmm, is there a newer version of bamse's a690 patch? The one in your kernel is the one with broken perfcntrs (the CP_PROTECT issue)
<robclark>
(bamse, I also just noticed your a690 stuff isn't showing up in patchworks for some reason)
<robclark>
ahh, there it is, I see it now.. I was looking for wrong email addr
<ajhalaney[m]>
<ajhalaney[m]> "bamse has even floated the..." <- konradybcio robclark HdkR HdkR HdkR HdkR robclark konradybcio canIa
stirl has quit [Read error: Connection reset by peer]
<HdkR>
robclark: Now that you've got an X13s, run the Vulkan CTS to see the AHB hangs :P
<robclark>
hmm, joy
<robclark>
I guess I should at least clone and build deqp
<HdkR>
Something about the memory tests were likely to cause it but it is never consistent
<steev>
robclark: are you on the latest kernel yet or stil rc7?
<robclark>
steev: on lenovo-x13s-linux-6.3.y
<robclark>
hmm, even with charger plugged in battery seems to discharge when building deqp.. tbf I'm using some random charger (I think only 45W).. and no idea if thermals cause it to start drawing less from the charger)
<steev>
there are definitely times where it seems to be able to draw more than the charger (but i'm also not using its charger.... i'm using a macbook 2018? 2019? charger)
<steev>
usually if i'm building say, 3 different rust apps as well as 2 kernels at the same time
<robclark>
deqp is pretty big.. and ninja so very parallel.. on lesser things it would OoM doing a parallel build
<robclark>
I guess I should try again with the proper charger at some point.. not sure if it is the charger or some other reason that it isn't negotiating max charging power
<steev>
robclark: also good deal on being on the latest 6.3 - did you still have the other issue?
<robclark>
it cleaned up the couple splats I had before.. only change I have right now is the fixup I pasted a bit earlier
<steev>
okay, good deal
<steev>
i think that's one of the patches that got lost in time, i definitely had it previously for hdkr
<robclark>
pretty sure I mentioned at least the first hunk on list at some point.. don't remember if I noticed the 2nd one or not
<HdkR>
Could be your charger doesn't support one of the random voltages USB-C can pump out versus what the device can accept?
<robclark>
actually... it seemed to have stopped charging.. battery level went down some more after build stopped.. but re-plug and now it is going back up.. 🤷
<HdkR>
Curious
<robclark>
but yeah, could also be a mismatch like that.. I think the charger I'm using is a lenovo one but just smaller one
<robclark>
I should probably switch to proper charger, but that would require re-jiggering cables behind my desk
<HdkR>
I definitely had a device do that to me. Something only supported 12v or 15v but my charger was 9v and 20v or something?
<HdkR>
Too many optional voltages. Gimme one that supports all the things
<robclark>
I guess it is still better than the pre-historic times when everything had an incompatible barrel jack.. but yeah
<HdkR>
Backpacks filled with barrel to lenovo rectangle adapters
<robclark>
heh lol.. I remember those days
agl7-Galaxy has joined #aarch64-laptops
<steev>
robclark: oh, i know what happened; once bamse submitted to the list, johan picked up the patches, so mine stopped being used
<steev>
id' had the fixups in my patchset; so might want to ping jhovold about it too so he sees
userTPOO77 has joined #aarch64-laptops
<userTPOO77>
i use arch btw.
<clover[m]>
but do you also use aarch64?
userTPOO77 has quit []
<steev>
apparently not
<clover[m]>
flatpak is solving a lot of my woes right now. thanks for reminding me that is a thing robclark