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
<anonymix007[m]>
What exactly prevents us from loading dsp firmware or zap in EL2? It certainly can be implemented in the OS (as Windows should be able to do that). Is it, as always, just the lack of documentation?
<steev>
my understanding (and i haven't looked into it) is that el2 breaks the remote procs. travmurav[m] would know the best since he's the one who has dug into it (the slbounce repo has some great documentation that might explain it as well)
ellyq has joined #aarch64-laptops
ellyq_ has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
<travmurav[m]>
anonymix007: you don't need zap at all in el2 since you can just write to the reset register yourself, for remoteprocs one need to know a way to boot them since in el1 qcom's hyp firmware does it for us
<travmurav[m]>
as in, not even "a way to boot them", there is already a driver in linux
<travmurav[m]>
but which resources to bring up along the way for the remoteproc to work
<travmurav[m]>
i.e. which clocks, pds
<travmurav[m]>
so yes, as always, lack of documentation...
<travmurav[m]>
anonymix007: basically, currently for linux on woa we rely fully on "android way" of managing things, where we just send the firmware elf into firmware and hope it does $magic for us
<travmurav[m]>
when we switch to el2, we replace qhee - part of the android firmware stack and so we immediately loose all it's features
<travmurav[m]>
most notably, pas (peripheral authentication service iirc) which lives in qhee and is the thing that gets the elf, checks it's signature and kicks the hexagon to boot it
<travmurav[m]>
but before that one needs to set up clocks and power domains of the core one boots, which is a bit more hard part
<travmurav[m]>
since those are soc specific and there is no downstream to refer to, since i.e. android linux doesn't need to know about those resources
<travmurav[m]>
and then after you boot it, also need to know which iommu id it has, though as of now if you boot with slbounce, the dsps will probably be set to bypass mode automatically since linux will try to inherit qhee's iommu settings
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
thevar1able has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
anonymix007[M]: hopefully today I will get some usb C to usb A adapters so I can finally properly boot, then I will test it on my Asus vivobook
<SpieringsAE>
the UKI you sent yesterday that is
<SpieringsAE>
then its time to see if usb A can be made to function with the recent addition of the dwc3-mp node
<SpieringsAE>
JensGlathe[m]: also hoping to eventually get the devkit, got the asus vivobook s15 for now, it seemed to me like the only good option, it was the cheapest at 1300 euro, and it benchmarks the best despite having the x1e-078.
<SpieringsAE>
The only fear I have is that 16GB of ram is not going to be enough to take on large projects
<JensGlathe[m]>
bluerise: yes, looks like it, at least similar. qmi-chip-id is 18 on mine, there's usually two variants with the same calibration data. One es preproduction I guess
<JensGlathe[m]>
yes is in rc6 I guess, will test this evening
<JensGlathe[m]>
bluerise: did you find a good calibration set?
<bluerise>
nope :/
<bluerise>
hence asking in the bug
<bluerise>
oh, calib in addition to board data?
<bluerise>
only thing we found were like a few drivers on Windows but not suer how to use that
<JensGlathe[m]>
Okay I have more incentive now I guess. Will do my routine with all HP available sets
<JensGlathe[m]>
The Windows files are not really compatible for whatever reason with qca swissarmyknife
<JensGlathe[m]>
So I try the available hp sets in the board-2.bin and take the one with the best perf
<JensGlathe[m]>
bluerise: yes, and regulatory also possible
<JensGlathe[m]>
calibration data is the key to it actually performing, the rest is only keys
<JensGlathe[m]>
will post an update there when I'm done
<abelvesa>
robclark: AFAIU, the slim7x has 3 type-c ports, just like the CRD
<abelvesa>
robclark: so my best guess is to try to do something similar to CRD
<abelvesa>
robclark: so try replicating the CRD patch
<abelvesa>
robclark: please keep in mind that it might not boot up with full display if anything goes wrong, so safekeep a working kernel/initrd
<abelvesa>
robclark: if anything, pastebin the log with those changes and we can debug from there
<anonymix007[m]>
travmurav: So we need remoteproc documentation or is it possible to reverse-engineer what Windows does?
<travmurav[m]>
It's possible to RE, yes
<travmurav[m]>
I could semi easily list you which MMIO writes hyp does and give a guess, which of those are clocks
<anonymix007[m]>
It looks like Qualcomm shares some documentation with some companies, so @linaro guys maybe could get it?
<travmurav[m]>
If nda/qcom allows, maybe
<anonymix007[m]>
What are the chances that Microsoft signs open source replacement for tcblaunch? Like they sign shim already
<travmurav[m]>
No idea, it won't hurt them to do so since the blob is measured but first someone needs to write one and test it
<travmurav[m]>
It was suggested that it's theoretically possible
<travmurav[m]>
And "test it" depends on having a device with hardware secure-boot off, which is also possible but I never bothered sine I don't have one myself and remote-hands debugging is pain for /two/ people
<anonymix007[m]>
Is "hardware secure-boot off" only true for reference devices?
<travmurav[m]>
There is one known retail sb-off device
<anonymix007[m]>
dev kit?
<travmurav[m]>
Maybe the arrow devkit too if we're lucky
<travmurav[m]>
But is it "retail" if no one has it :p
<travmurav[m]>
anonymix007: 7c1 based "TCL book 14 go" is sb-off
<travmurav[m]>
The red laptops should also be sb-off but red laptops don't exist
<SpieringsAE>
i remember being afraid that microsoft would mess up this big attempt at bringing arm into this market, but the lack of the devkit may have caused more issues i feel
<SpieringsAE>
windows for being windows seems to be pretty fine now on arm, but yeah the lack of native software I feel is a direct result of the bad rollout of the devkit
iivanov has joined #aarch64-laptops
<anonymix007[m]>
travmurav: are the red laptops available to only selected companies?
<travmurav[m]>
Red laptops == crd
<travmurav[m]>
Only in the hands of qcom and their contractors
<anonymix007[m]>
Yeah, I know that it's crd. I always wanted to get one, but none of those who I contacted (some even have a verified Qualcomm account and access to some non-public software) could get it.
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<kuruczgy[m]>
travmurav: I saw that you mentioned Windows driver RE, would you have any advice for getting started with black-box analysis of the windows drivers? E.g. if I could confirm that windows is reading gpio 92 that would already be helpful IMO
<travmurav[m]>
kuruczgy: stupid idea but what if you boot to windows and find the sensor with a magnet?
<travmurav[m]>
I never read windows drivers fwiw, mostly qcom firmware bits (and I guess the windows boot chain)
<travmurav[m]>
S/read/re'd/
<kuruczgy[m]>
First I would need to find a magnet... but even if I find where the hall sensor is located, how would that help me?
<travmurav[m]>
But I'd say worth checking if windows uses the acpi lid sensor driver
<kuruczgy[m]>
it does, I checked
<travmurav[m]>
You'd move the magnet around the keyboard to find when display turns off xD
SpieringsAE has quit [Quit: Leaving]
<kuruczgy[m]>
Yeah I get that but how would that help finding the right gpio?
<travmurav[m]>
Well first of all maybe you/ cant/ find it and I.e. the device uses some mess like angle sensor, with lid being a leftover that's absent in hardware
<travmurav[m]>
But then you at least don't need to close open the hinge all the time xD
<kuruczgy[m]>
Aah okay I get it, so just to confirm that a hall sensor even exists
<travmurav[m]>
Yes
<travmurav[m]>
I.e. could be a mis-copy from crd by lenovo
<kuruczgy[m]>
Would there be a way to find out in windows which driver is triggering the lid event? E.g. in the "no hall effect sensor" theory the windows lid acpi driver might just be doing nothing
<travmurav[m]>
I'm afraid idk how windows works but I'd guess you can unload the acpi lid device
<SpieringsAE>
ah okay nvm just read your matrix link
srinik has joined #aarch64-laptops
mrkajetanp has joined #aarch64-laptops
<kuruczgy[m]>
travmurav: Found the hall sensor, it's near the left-side front USB-C port
<travmurav[m]>
Cool, does it break if you kill the acpi lid device?
<kuruczgy[m]>
Lemme try, maybe just disabling it in device manager should work? I am not a windows expert either...
<travmurav[m]>
Yeah that's what I was suggesting
<kuruczgy[m]>
travmurav: Nope, disabling it is not that easy. The "Disable Device" button is disabled. I tried the "Uninstall Device" button and even the trick of installing the wrong driver for the device, but nope, on reboot it reverts back to the right driver and still works.
<travmurav[m]>
Sad
mrkajetanp has quit [Ping timeout: 480 seconds]
<travmurav[m]>
idk if there is some api/command that would allow reading that specific device
<travmurav[m]>
Or I guess there was something about reading raw mmio from the debugger
<travmurav[m]>
Could try to read that gpio offset maybe
<kuruczgy[m]>
Oh that sounds like fun. What kind of debugger are you thinking of that would allow me to do MMIO?
<kuruczgy[m]>
Ooh this sounds very nice, why did I not hear about this method before. Thanks! (And maybe I should consider subscribing to Konrad's blog)
<hogliux>
anonymix007[m]: Thanks for your answer. I've added slimbus, slim-qcom-ctrl, slim-qcom-ngd-ctrl kernel modules, but linux still finds no devices under /sys/bus/slimbus/devices. I need to check windows on how exactly the bluetooth module is connected...
<anonymix007[m]>
AFAIU SLIMbus is only used for A2DP HW offload (at least this is how it's called in AOSP, though windows must have something similar), the actual Bluetooth controller that i.e. bluez will send HCI commands is connected via UART.
<anonymix007[m]>
You have yoga, right? If so, can you maybe open a PR with your firmware blobs?
<hogliux>
OK I will
<hogliux>
First want to test if it actually works
<JosDehaes[m]>
it seems to try to work, it was looking for the firmware, now trying to find the file on the windows drive
<JosDehaes[m]>
I have yoga too indeed
<kuruczgy>
travmurav[m]: I think I managed to read the gpio value with WinDbg, and it seems to be working
<kuruczgy>
The address of gpio92's io reg should be: 0xf15c004 = 0x0f100000 + 0x4 + 0x1000 * 92
<kuruczgy>
I set Windows to "Do Nothing" when closing the lid. It still disables the screen & keyboard though, so I used a delay:
<kuruczgy>
`.sleep 1388; !dd 0xf15c004 L 1` in WinDbg
<kuruczgy>
This reports `00000001` normally, and `00000000` when I put the magnet over the sensor.
<kuruczgy>
Any suggestions for what to check next? My next idea would be to do the same check at the same address on Linux (suggestions for what's the easiest way to do this with gdb welcome), and also to compare the values of the ctl registers.
<travmurav[m]>
kuruczgy: first I suggest checking the pull and drive of that gpio I guess, though it should be hw pull
<travmurav[m]>
Then I guess it's possible that one needs to power up the sensor somehow indeed
<travmurav[m]>
But I'd assume the gpio should read out properly in linux debugfs
<kuruczgy[m]>
Ctl reg is full 0s
<travmurav[m]>
Though I guess you could peek /dev/mem if you wanted to
<kuruczgy[m]>
Yeah, I am also afraid that it needs an extra voltage regulator or something to get power...
<hogliux>
That also includes the BT firmware which seems to be different than the one that was already there.
<JosDehaes[m]>
oh apparently I needed to start the bluetooth.service 😁
<hogliux>
:-)
<hogliux>
JosDehaes[m]: I do wonder what the firmware files actually do then 🤔
<JosDehaes[m]>
maybe it's some regulatory stuff?
alfredo has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
hogliux: your BT firmware seems to be just a newer version. I'll keep the older one for now though
<hogliux>
👍
<anonymix007[m]>
b112 is some sort of configuration file, bin is probably whatever code is needed to make WCN785x work as a HCI device (and it's different between i.e. USB and UART versions)
mrkajetanp has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<abby>
does an acpi dump of these laptops have to be done on windows or can it be done from linux?
<abelvesa>
robclark: I run this one on my t14s. Also added nodes for the slim7x external DP support)
<abelvesa>
robclark: and if it doesn't work, try the branch with the same name but with -dbg suffix. That one spits a lot of debug messages, but will help me figure out what is going on.
<anonymix007[m]>
abelvesa: have you looked at USB-A on T14s?
<abelvesa>
anonymix007[m]: not yet, but it is on my todo list. TBH, at this point the thing that keeps me up at night is the dp+usb mode which I can't get to work yet ...
alfredo has quit [Quit: alfredo]
<abelvesa>
abby: you can do that from anywhere you want, even Shell.EFI
<abby>
cool
<robclark>
abelvesa: ok.. cool.. I'll give that a try today.. I did try (a month or so back) to just copy the crd dts, which didn't work, but maybe I was missing the retimer
<abelvesa>
which laptop do you have?
<abelvesa>
abby: ^^
<abby>
x13s
<abelvesa>
abby: the acpi dumps are already merged in the aarch64-laptops github repo
<JosDehaes[m]>
abelvesa: I tried the DP branch on the yoga 7x, the system boots (can ssh in), but internal screen stays blank and external screen also
<abelvesa>
anonymix007[m]: oh, ok, but again, this will not be accepted upstream as the wcn7850 needs to be handled via the pwrseq
<abelvesa>
I think sgerhold is looking into this, IIRC
<anonymix007[m]>
Well, I'm not going to run the upstream kernel anytime soon anyway (not that it would work anyway), so not a big deal
<JosDehaes[m]>
abelvesa: can not get x1e-next-20240830-dbg to boot
<SpieringsAE>
anonymix007[m]: my first boot attempt was with a stock aarch64-linux-rc kernel from archlinuxarm, it got pretty far tbh
<SpieringsAE>
but then it can't load the rootfs from usb and gives up
<kuruczgy[m]>
Random question: What does the "qup0_se0" gpio func stand for? Apparently windows is setting gpio 0 and 1 to output only when the lid is open. I don't seen any DT bindings for gpio 0 or 1.
<travmurav[m]>
kuruczgy: qup would be geni, se is probably serial
<abelvesa>
JosDehaes[m]: konradybcio suggests that the rtmr0 vreg gpios for 1.15 and 3.3 might not be accessible on the slim7x either (they are on crd and t14s)
<abelvesa>
so try removing those and then boot
<anonymix007[m]>
travmurav: looks like that qcpil is the windows driver responsible for DSP firmware loading. inf file in qcsubsys_ext_adsp8380 has some references to PIL authentication. And QcSkExt8380.exe is probably what's doing that instead of the hypervisor: https://katb.in/osiqimojeme
<anonymix007[m]>
Not sure what to do with that information and how (and if) that'll help to understand what needs to be set up for dsps to work
<anonymix007[m]>
@linaro guys, can you maybe ask Qualcomm about how to work with DSP without hypervisor?
<travmurav[m]>
talking to tz to set up xpus would check out I guess
<travmurav[m]>
I guess you're lucky those strings are even there xD
<travmurav[m]>
I think qcom often strips out stuff like that
<travmurav[m]>
tho not sure if this is some leftover modem stuff
<travmurav[m]>
don't think non-modem dsps need xpu
<travmurav[m]>
but who knows what they changed
<anonymix007[m]>
There is TZ_PIL_AUTH_QDSP6_LITE_PROC in adsp .inf
<robclark>
abelvesa: ok, dp works on one of the two left side ports (the on furthest from the screen, ie. the "front" one).. but with a bunch of link training spam.. doesn't work on other left side port
<anonymix007[m]>
abelvesa konradybcio lumag jhovold (and anyone else who can): sorry for tags, but can you ask Qualcomm about booting DSP in EL2?
<steev>
seems of interest for you x1e types that have to leave off edac
<robclark>
ahh, nice to see a fix for the edac thing
SpieringsAE has quit [Quit: Leaving]
<abelvesa>
robclark: did you have to comment out the gpio related properties in the 1.15 and 3.3 vreg nodes ?
<robclark>
I didn't comment anything out.. maybe I need to?
<abelvesa>
robclark: oh, no, I was afraid it wouldn't boot with display at all
<abelvesa>
robclark: because JosDehaes[m] was saying his doesn't boot with display with my branch
<JosDehaes[m]>
robclark: so Abel's branch just boots for you and even DP is working?
<JosDehaes[m]>
Not sure what I'm doing wrong then
<abelvesa>
robclark: those link training issues are due to some changes needed in dp driver, AFAIU
<abelvesa>
robclark: but the 4th or 5th link training should always succeed
<travmurav[m]>
anonymix007: 8g2 as in some sm or some sc?
<kuruczgy>
travmurav[m]: so I dumped gpio 0-237 registers (except 44-48) on windows (both with the lid open and closed), and looked at the ones set to output.
<kuruczgy>
This means gpio 0,1,6,7,18,20,21,48,49,70,96,97,98,100,116,117,146,152
<kuruczgy>
Out of the ones that are not set as output already on linux, only 116 stood out.
<kuruczgy>
I tried setting the registers of 116 to the same values as on windows, but no luck, gpio 92 is still not reporting the lid status. (It's also not working in the EFI shell FWIW.)
<travmurav[m]>
hm sad
<travmurav[m]>
maybe there is something ec does for it then
<travmurav[m]>
i.e. if there is "rich os has booted" callback somewhere in acpi
<travmurav[m]>
there is a similar thing on aspire1 that unlocks media keys
<travmurav[m]>
but lid there "just works" (tho it's fully managed by ec, there is no gpios, only interrupt event and a ""register"" in the ec)
<travmurav[m]>
might be worth looking for randomly tacked on i2c writes in acpi, I guess without schematics this is not a trivial task at this point to know what exactly is needed :(
<kuruczgy[m]>
I am thinking that the next logical step would be to disassemble the thing and take some nice high quality PCB photos (maybe even poke around with a multimeter)
<kuruczgy[m]>
But I am kinda afraid of doing that, don't wanna kill my expensive laptop with ESD or ruin something else
<kuruczgy[m]>
I assume nobody who has taken the yoga 7x apart has taken photos so far?
<anonymix007[m]>
travmurav: sm8550
<travmurav[m]>
fwiw this is one of the things I actually did when working on aspire1, made a bunch of photos with macro rings and stitched with hugin to get huge 25MiB jpegs
<travmurav[m]>
but the problem is that on 6+ layer (possibly 12 for x1e?) board you won't see much xD
<travmurav[m]>
unless there is stuff directly near
<travmurav[m]>
anonymix007: right, well it would have the same setup then probably, yeah
<travmurav[m]>
since most of the pas is in the hyp for non-modem remoteprocs
<travmurav[m]>
and modem is fully in tz
<travmurav[m]>
since modem is extra special
<anonymix007[m]>
Is hyp partition on some kind of internal flash storage device in x1e laptops? There are lots of different partitions in grub, but none of them seem to be visible in Linux. Can I dump their contents in Linux or somehow else?
<travmurav[m]>
spi flash probably
<travmurav[m]>
might be protected and managed by tz
<robclark>
JosDehaes[m]: yeah, working.. I did have to add CONFIG_TYPEC_MUX_PS8830=m
<travmurav[m]>
I think we dumped it via efi shell on x13s at some point, was a total pain
<robclark>
abelvesa: yeah, that's about right, it works after a few link training tries
<travmurav[m]>
otherwise I have the hyp blob from red laptop somwhere I think, dumped from widnows update
<abelvesa>
robclark: which defconfig have you used ? johan's or the x1e ?
<travmurav[m]>
... but obviously REing that stuff would be quite a bit of pain
<robclark>
abelvesa: I guess it started as a merge of your defconfig and fedora config when I first got the laptop, and then multiple rounds of `make olddefconfig`
<anonymix007[m]>
travmurav: not that there's much choice if we want to have linux fully working in el2
<anonymix007[m]>
Or can we run that QcSkExt8380.exe just like the tcblaunch.exe?
<travmurav[m]>
doubt
<travmurav[m]>
for tcblaunch there is a convenient "bare metal" part that we use
<travmurav[m]>
and we need nothing else of it but like few hundreeds of instructions in semi-bare-metal mode
<travmurav[m]>
I mean there are funny options like loading remoteproc in el1 and then hoping it would survive the switch xD
<travmurav[m]>
but this sounds quite hacky and fragile if at all possible
<travmurav[m]>
fwiw I did a similar thing on 7c but i just needed to assign some memory, not actually do full remoteproc boot
<travmurav[m]>
so ie. dtbhack.efi talks to hyp to prepare modem to boot later by linux
<travmurav[m]>
(since the hyp is not involved in modem boot, compared to other dsps)
<travmurav[m]>
but assigning memory to it to configure xpus /is/ done by the hyps
<travmurav[m]>
and the api of the tz for that is different so I didn't want to figure out how it works xD
<travmurav[m]>
because not like 7c matters that much either in the grand scheme of things anyway
<travmurav[m]>
(on the other hand I'd say adsp/cdsp on 7c is same stuff as on newer things)
<travmurav[m]>
but didn't get that to work, as I've mentioned already
<travmurav[m]>
adsp never fetched ram
zdykstra has quit [Quit: WeeChat 4.4.1]
zdykstra has joined #aarch64-laptops
<robclark>
abelvesa: hmm, dp doesn't seem to come back from dpms (well at least for sample size of 1).. not sure if you see the same thing on crd?
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
<robclark>
second time, it comes back fine from dpms-off..
mrkajetanp has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
konradybcio: I saw that you have a half-done driver for the X13s EC, what were your methods for finding out all the info that went into that?
<kuruczgy[m]>
If I wanted to poke around the yoga 7x EC, where should I start? Where is the firmware located, what kind of MCU is the EC (is datasheet available maybe?), how do I found out its i2c bus and address, etc.?
<travmurav[m]>
fwiw for aspire1 I was mostly looking into dsdt
<travmurav[m]>
if youre lucky can dump firmware blob from update capsule but might be unlucky with some custom arch or like 8051 stuff which is very hard to re
<travmurav[m]>
you don't want to re 8051 code with dynamic memory bank switching I'd say :P
<travmurav[m]>
but dsdt code is easier in this regard
<travmurav[m]>
still annoying but should be readable after you get used to it xD
<kuruczgy[m]>
I was hoping that it's just some COTS MCU that might even have a public datasheet :/ A PCB photo would at least be useful for knowing the IC markings
<kuruczgy[m]>
But okay I will look at the dsdt a bit more again, though it didn't seem to too much useful stuff about the EC at a first glance
<travmurav[m]>
I mean there are defintely leaks of datasheets for some things like ite one could find
<travmurav[m]>
I think I have bits of bsp for mine in aspire1 but it's a total mess with 8051
<travmurav[m]>
and I still got most of the stuff I need just from dsdt
<steev>
hmm, no, the suspend thing isn't the issue with the HTC Rx.... it's back with a vengeance today :(
<konradybcio>
kuruczgy: no matter the MCU, it runs some vendor-specific firmware..
<konradybcio>
your best and only best is probably reading dsdt (or ssdt on some devices)
<konradybcio>
and yes it's not fun xD
<konradybcio>
s/only best/only way to go
<kuruczgy[m]>
I see... well, thanks, then I guess it's time to get more familiar with the dsdt
<hogliux>
llow the spec and should be easy to identify.
<Jasper[m]>
Depends on the ec, also some of those mechanisms are implemented in asl lol
<Jasper[m]>
The book2go returns battery info from a method in asl
<hogliux>
Yes exaclty. For x86 dell XPS 13 EC I once reverse engineered the EC write/read methods were all implemented in asl. But if you know what you are looking for you can identify those asl methods.
<hogliux>
Yes the Dell XPS 13 also returned the battery info with asl. The battery info method would call EC write/read methods also implented in ASL. But if you reverse engineered that ASL, it was clear that it just followed the spec that I linked above. That made reverse engineering much easier.
<hogliux>
Still very hard though!
<abby>
are there any resources for mapping the gpios on sc8280xp?
<abby>
mapping as in determining their purpose
<JensGlathe[m]>
hmm I looked into pinctrl_sc8280xp.c for clues
<abby>
that's helpful
usermode has joined #aarch64-laptops
usermode has quit []
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit []
usermode has joined #aarch64-laptops
usermode has quit [Write error: connection closed]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit []
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Read error: Connection reset by peer]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
usermode has quit [Remote host closed the connection]
usermode has joined #aarch64-laptops
<abby>
I'm looking for i2c9 as listed in the acpi dump, so not sure if that's fully mapped in that file
usermode has quit [Read error: Connection reset by peer]
ifconfig has joined #aarch64-laptops
ifconfig has quit []
ifconfig has joined #aarch64-laptops
ifconfig has quit []
ifconfig has joined #aarch64-laptops
ifconfig has quit []
ifconfig has joined #aarch64-laptops
ifconfig has quit []
ifconfig has joined #aarch64-laptops
ifconfig has quit []
ifconfig has joined #aarch64-laptops
ifconfig has quit [Write error: connection closed]
ifconfig has joined #aarch64-laptops
ifconfig has quit [Remote host closed the connection]
ifconfig has joined #aarch64-laptops
ifconfig has quit [Remote host closed the connection]
ifconfig has joined #aarch64-laptops
ifconfig has quit [Remote host closed the connection]
ifconfig has joined #aarch64-laptops
<JensGlathe[m]>
what's supposed to be there
<JensGlathe[m]>
what does sc8280xp.dtsi say about i2c9
<abby>
nothing :)
<abby>
i'm trying to add it
ifconfig has quit []
ifconfig has joined #aarch64-laptops
<abby>
oh wait the dtsi does say something about it
<JensGlathe[m]>
those are group configs - no idea if only one can be active or what is its real purpose. Falls into the ignore territory. question is more if the dts wires up &i2cqup1 already
<JensGlathe[m]>
&i2c1 and i2c9 are both not in my x13s dts
<Jasper[m]>
@abby can you send a link of the acpi table dump and the line where that device sits?
<Jasper[m]>
Also I think @konradybcio already had something on talking with the ec