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)
jelly has joined #aarch64-laptops
minecrell has quit [Read error: Connection timed out]
minecrell has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
mohamexiety has quit []
iivanov has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
<HdkR>
qzed: Half a DT is likely nicer to write than a full DT with new device bringup :)
godvino has quit [Read error: Connection reset by peer]
godvino has joined #aarch64-laptops
godvino1 has joined #aarch64-laptops
godvino has quit [Ping timeout: 480 seconds]
godvino has joined #aarch64-laptops
godvino1 has quit [Ping timeout: 480 seconds]
<qzed>
True, but on the other hand all the downstream stuff also uses DTs
godvino has quit [Read error: Connection reset by peer]
<HdkR>
Yea, the world is broken sadly :)
<juergh>
steev: can you (or somebody else) post a good dmesg? I'm seeing `[ 9.952102] qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode` which is related, no?
<juergh>
same with your and jhovold's 6.3-rc4 kernels.
<ndec>
juergh: that 'long' delay when using the ubuntu installer, when does it happen? I am trying the usb image, on first boot it complained about bitlocker, so i disabled it , and tried again, and now when I launch the 'install ubuntu' it opens the application and nothing really happens from there..
<juergh>
IIRC give it some time...
<ndec>
but the very first time it started right away, well just to complain that i had bitlocker enabled on windwos..
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
<juergh>
hmm. I just tried it. you should see the Ubuntu logo and the spinning wheel within a couple of secnods.
<juergh>
try to power cycle. I've noticed that somtimes the display doesn't seem to reset properly and stays black after a reboot.
hightower2 has joined #aarch64-laptops
<ndec>
juergh: ok.. it's running now...
godvino has quit [Read error: Connection reset by peer]
godvino has joined #aarch64-laptops
<jhovold>
danielt, juergh: I haven't seen that invalid header message myself so not sure what's wrong there, hopefully "just" differences in the ucm files
<jhovold>
I'm currently using 03662f695498 (ucm2: Qualcomm: sc8280xp: set some default values to mixers) from srinik's repo
<jhovold>
Haven't updates the prebuilt firmware image in a long time either in case something changed there recently
<danielt>
jhovold: My prebuilt hashes (sha256) as 7d17f6239fd4c15d71db70464f83bc83910babb1ec37f780ed6c453a6b429844 /lib/firmware/qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin
<danielt>
jhovold: I'll match the UCM bits but I'm not sure enough of ALSA comes up for the UCM to come into play...
godvino has quit [Remote host closed the connection]
<jhovold>
[ 8.149951] ALSA: Control name 'stream1.vol_ctrl1 MultiMedia1 Playback Volume' truncated to 'stream1.vol_ctrl1 MultiMedia1 Playback Volu'
<jhovold>
[ 8.150313] ALSA: Control name 'stream2.vol_ctrl2 MultiMedia2 Playback Volume' truncated to 'stream2.vol_ctrl2 MultiMedia2 Playback Volu'
<jhovold>
[ 8.155241] input: SC8280XP-LENOVO-X13S Headset Jack as /devices/platform/sound/sound/card0/input11
godvino has joined #aarch64-laptops
godvino has quit []
<ndec>
juergh: the installation went through. but it wouldn't boot. that said it could be something on my system.. since i've been messing a lot with firmware changes and configs. how do you manage the DTB during the boot once ubuntu is installed with the installer?
<ndec>
i think the installer removed all my custom efi boot entries.. so now ubuntu won't boot (i don't know why) and none of my other distro (i have debian and arch) boot. but windows still boots :)
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
<danielt>
ndec: I saw something like that. Everytime Debian updated grub the boot variables were redirected from DtbLoader to the grub binaries. In the end I concluded the not-a-driver version of DtbLoader doesn't really serve any useful purpose on X13s (dropping something into /etc/grub.d integrates better because the distro is more aware of that and doesn't ever clobber it)
<danielt>
steev: I'm not using Ubuntu, I probably just got mine from an outdated git repo...
<steev>
the topology firmware binary hasn't changed in a verrrrrrrrrrrrrrrrrrrrrrrrrrrrry long time
hightower2 has quit [Remote host closed the connection]
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
travmurav[m]: what os/dist are you actually running on your aspire 1 - pmos? i think you also have audio working on it - did you also create an ucm config for it and if yes, is it online available somewhere?
<travmurav[m]>
hexdump0815: I use Alpine/pmOS (for the familiar kernel hacking tools)
<travmurav[m]>
hexdump0815: sound: yes/no - I had it working once with the simple i2s speakers but seems like something broke and I never got my hands to figuring out what
<travmurav[m]>
I did need to make an ucm config, I think it's still on my device as I was writing it on the go
<travmurav[m]>
it was pretty simple though, just toggle adsp mixer to route MM1 to the needed i2s
<hexdump0815>
travmurav[m]: can you maybe put it up somewhere? maybe its useful for the galaxy book go once i get the sound working
<travmurav[m]>
one moment, and it's kinda incomplete anyway given the mic/jack codec is "more smart" and needs extra stuff both in the kernel and the ucm
<travmurav[m]>
hexdump0815: not sure, but I *think* it should be somewhere there
<hexdump0815>
somehow i think windows also needs to know them from acpi, so my guess it must be in there somewhere, but i never really got the idea how the pin list numbers in the dsl relate to those numbers in the dts
<travmurav[m]>
actually maybe you can see the interrupts in the device manager even
<travmurav[m]>
but I think they don't clearly map to the gpios
<qzed>
Iirc, yes that's possible. With some offset usually
<qzed>
+32 or something like that?
<hexdump0815>
qzed: any idea how to construct that offset? i tried to get any logic into it, but it never worked out for me with whatever i tried
<hexdump0815>
qzed: i tried it with fixed offset on existing dts files comparing to their dsl, but one fixed offset never really worked for multiple values i think
<qzed>
No idea, sorry. I think it's some mapping from global pin number down to the chip-local number, with each chip having some offset
<hexdump0815>
travmurav[m]: even an incomplete ucm would be good as a start - better than having to write everything from scratch :)
<qzed>
Yeah I also found that not all things line up when I compare the DT with ACPI
<qzed>
I think I have some comments in the SPX dt about some things not matching
<qzed>
Still works with that change, so my guess is that either it doesn't matter or the ACPI ones can't be that bad
<hexdump0815>
for example the aspire 1 dts from travmurav[m] - i guess kbd and touchpad just use the generic i2c-hid driver from windows, so i do not expect any magic in there - numbers in dsl are (kbd/tpd) 0x180=384/0x1c0=448 and in dts they are 33/94
<travmurav[m]>
otherwise at least for aspire 1 the end goal would be similar to the cros devoces
<travmurav[m]>
hexdump0815: not sure if sammy might have used different audio codecs tho
<hexdump0815>
travmurav[m]: do you maybe remember where you got those numbers from?
<hexdump0815>
travmurav[m]: iirc from dsl there were at least similarities
<travmurav[m]>
i.e. they might have used pmic sound (or is it a dedicated chip again for new qcom platforms...)
<travmurav[m]>
in which case you would look at some phones in i.e. pmOS instead
<travmurav[m]>
hexdump0815: the gpios for me were evident by the schematic
<travmurav[m]>
that is, tlmm interrupts are physical signal lines going to the gpio of the same number
<hexdump0815>
travmurav[m]: but from somewhere windows needs to get this information too and assuming the i2c kdb/tpd drivers are just some generic ones there would only be acpi ... or maybe some .conf or reg entry in windows maybe for such mappings?
iivanov has joined #aarch64-laptops
<travmurav[m]>
hexdump0815: yes I think the dsdt defines the interrupt in some way
<qzed>
Let me check something... Iirc pep does some stuff in that regard too
<qzed>
for i2c7 (whatever that is, it's at least one i2c-hid device)
<hexdump0815>
qzed: yes i2c6 = I2C7 in dsl is kbd and i2c10 = IC11 in dsl is touchpad
<qzed>
but which of the two does what specifically... I don't remember the config values by heart, so I'd need to check how they're set up once I get home
<qzed>
so it could also be that those are just the i2c lines
<hexdump0815>
i think i tried both and they did not work, but maybe i should try once more at some point ... how to deal with having two interrupts in dsl?
<qzed>
ah no they're both the I2C lines as they're tied directly to i2c7... sorry
<juergh>
@ndec DTB is loaded by grub. do you get to grub at all?
<juergh>
ndec: ^^
<qzed>
hexdump0815: yeah it should be that... try 0x140 - 32?
<hexdump0815>
qzed: thanks a lot, any help would be welcome as i'm quite stuck regarding the keyboard and touchpad right now - keyboard works somewhat, but it think the current interrupt in the dts is wrong
<hexdump0815>
but for instance for the aspire 1 (same soc sc7180) this would result in 384-32/448-32 and in dts (working for travmurav[m] and verified by the schematics) they are 33/94
<ndec>
juergh: i am not with the x13s anymore.. but yes i get to grub menu. I can boot windows from there , and i could finally boot my debian install too. But not ubuntu. I will check more later..
<qzed>
hexdump0815: Hmm okay, yeah 32 was just a bad guess because iirc 32 is some ACPI offset with which the lowest pin starts
<qzed>
*lowest pin that is not some legacy thing
<qzed>
*is allowed to (no idea if the first chip can't have a higher offset)
<hexdump0815>
qzed: for aspire 1 the diff in dsl is 64 and in dts is 61 so no real common offset possible
<hexdump0815>
diff between kdb and tpd i mean
<hexdump0815>
if there would be a fixed offset in place the diff should be the same
<minecrell>
qzed: for GIC interrupts it's more likely that an offset of 32 would refer to GIC_SPI
<qzed>
thanks for that link that clears at least some things up for me...
<minecrell>
hexdump0815: given that the mapping should be the same for all sc7180 you can probably just steal both gpio numbers from travmurav[m]
iivanov_ has joined #aarch64-laptops
<hexdump0815>
minecrell: iirc that did not work out when we first tried (but maybe i should look at it again) - acer aspire 1 and samsung galaxy book go are quite different from the specific hw setup like kbd, touchpad etc. - for other things like gpu etc. i was able to profit quite a lot from the work travmurav[m] had done and it work with the aspire 1 settings
iivanov has quit [Ping timeout: 480 seconds]
<minecrell>
hexdump0815: you mean with kbd/touchpad gpios taken as-is from the aspire? that's not what I meant :p
Cyrinux9 has quit []
Cyrinux9 has joined #aarch64-laptops
<hexdump0815>
minecrell: can you maybe explain in a bit more detail what you mean?
<minecrell>
hexdump0815: take your magic GPIO numbers and look if something in aspire uses the same
<minecrell>
with magic GPIO numbers I mean the magic pin number in ACPI
<hexdump0815>
minecrell: sadly there is no real overlap for those
<minecrell>
um
<minecrell>
afaict the keyboard on the go uses 0x0140 and the touchpad 0x0180
<minecrell>
maybe I'm looking at the wrong file
<hexdump0815>
yes - and indeed 0x0140 appears in the aspire dsl as RTK0, but i'm not sure if that made it into the dts yet and i have no real idea what it would be - 0x0180 is not in the aspire dsl
<hexdump0815>
but even properly mapping that 0x0140 would be a good step forward already :)
<minecrell>
and 0x0180 (384 as you wrote before) is the keyboard on aspire1
<minecrell>
except you seem to have it as touchpad
<hexdump0815>
oh - not sure why i did not see that: so tpd on galaxy is kbd on aspire ... and 0x140 seems to be related to i2c9 (IC10) which would be the sound device which has tlmm 28 defined ... sounds like something worth to check
<hexdump0815>
i2c9 itself seems to have pin list 0x0184 and not 0x0140, but at least the seems to be some relation to sound - RTK0 might be the realtek rt5682i audio codec
<hexdump0815>
minecrell: thanks a lot, that at least gives input for new experiments :)