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)
<aceridus>
So, I get compile errors straight away regarding mpss_mem (/soc@0/remoteproc@4080000), venus_mem (/soc@0/video-codec@aa00000) and wlan_mem (/soc@0/wifi@18800000). I can see those in other dts files, but they aren't the same reserved memory ranges suggesting they vary by board?
<aceridus>
I am wondering if sc7180-idp.dts might be a better starting place because it defines a lot more things including voltage regulators. I even get the sense that the IDP might have been Qualcomms development board for sc7180, maybe the galaxy book was based off of it?
<aceridus>
I may as well just try booting it with that once since that dtb is already built
<aceridus>
The sc7180-idp.dtb boots but still without keyboard and a bunch of 'deferred probe pending' messages
<leezu>
aceridus: I was the one trying to geth the Galaxy Book Go running previously and was also unable to get keyboard / mouse to work. Unlike Chromebooks, the laptop's keyboard and touchpad are connected via HID over I2C, so you'll need to get that working first. jenneron[m] helped me with that before, but I gave up and got the Acer Spin 513. IMO it has a better build quality for
<leezu>
the price and you'll save many days (or weeks?) of work. And even with Chromebook hardware, there are still open issues with the "standard" linux desktop on ARM that you could contribute to, for example getting hardware video decode / encode acceleration enabled in browsers or implementing night light support given that Qualcomm hardware lacks the GAMMA_LUT used on x86 (and
<leezu>
targeted by Gnome / KDE currently). You'd meet the same issues with the Galaxy Book Go.
<jenneron[m]>
yeah missing video decoding in browsers is annoying
<jenneron[m]>
leezu: do you work on it?
<robclark>
so advantage of getting acpi boot work is that should give basic functionality working for all the 7c laptops.. I guess maybe some usb thing also needs to be updated w/ an acpi-id
<aceridus>
My #1 complaint for a while has been the lack of proper hardware accelerated video decoding in especially official Chrome in Linux. It gives so many lower powered ARM laptops and SBCs a bad rap because people test video playback on them and see horrible performance due to software decoding. Yet, the board is advertised to support 4k@30 or 4k@60 in hardware.
<aceridus>
I know so little about all of the layers involved in wiring that up, so unfortunately I am ill equipped to help change that as of yet...
<robclark>
leezu: will need to check when I'm in front of a dev mode device.. but I know qcom wired up some color processing property support specifically for night light
<robclark>
as far as video, 7c should be able to comfortably do 1080p w/ sw codecs.. but I guess for 4k you probably want hw
<leezu>
aceridus: On Qualcomm based devices, the only missing part is that the browser needs to call Linux V4L2 APIs. The integration would be substantially similar to the existing VA-API integration in Firefox, so if you do have time, this can be a fun project and should be feasible
<robclark>
all the v4l2 code should exist in chrome(ium) src tree.. although probably all under #ifdef CROS or something like that
<aceridus>
robclark: Your ACPI suggestions have helped so far in my estimate. Do you have some more reference material that might help me understand how to find more ACPI IDs that need adding? I wonder, how do you know that another one might be necessary for USB?
<robclark>
I guess look where acpi_device_list stuff was added in various other qcom platform drivers? idk, shawnguo or bamse probably have better advice, I didn't actually do any of that work
<leezu>
robclark: "qcom wired up some color processing property support specifically for night light" do you think that is upstream? If you can check drm_info on a dev_mode lazor that would be interesting. My understanding so far is that on lazor Color Transform Matrix needs to be used instead of GAMMA_LUT
<robclark>
oh, maybe it was CTM.. whatever we have, it is defn upstream
<robclark>
we landed all that stuff upstream first and backported to cros kernel
<leezu>
Ok, then it should be CTM
<robclark>
for 7c g1/g2 I guess you need to make the compositor support CTM then.. there will be gamma/degamma lut (in addition to CTM) on some devices, but the thing we have now is the only thing sc7180 supports
<aceridus>
So, should the 6.1.0 kernel have driver support for most of the devices in the Galaxy Book Go (sc7180). Do I need to have .mbn blobs loading for everything to work?
<jenneron[m]>
yes
<robclark>
all the kernel support for sc7180 was in place long ago (modulo some acpi device id's).. you do need fw for a few things (not display, but gpu and video enc/dec for example).. but that should all be in linux-firmware (other than possibly wifi/lte fw which might need a signed version?)
<aceridus>
Ok, good to know.
<aceridus>
I guess the first issue I need to sort out is why the keyboard/mouse don't work. According to leezu that is HID over I2C. Is there a way to figure out what driver is responsible for getting the keyboard going?
<robclark>
I think i2c and spi and all the things use "geni".. a sorta generic serial protocol thing..
<robclark>
hmm, but I think for chromebooks depth charge configures the "firmware" programming thing to setup all the channels as i2c vs whatever else
<robclark>
maybe a thing that dianders or amstan or bamse knows about?
<robclark>
(sorry, I do gpu kernel and userspace and a bit of display.. and for lower level bits it is mostly 2nd hand knowledge of those things)
<amstan>
yeah, qup is the hardware (think of it like the PRU from beaglebone and other advanced bitbangers), geni is the firmware that runs on the qup hardware?
<amstan>
unfortunatelly the firmware is not very hackable (can't make your own), so the best you can do is load different ones from depthcharge/coreboot for i2c vs uart vs spi
<jenneron[m]>
aceridus: start with regulators
<jenneron[m]>
many hardware pieces depend on them
<robclark>
I assume the 8c* devices are qup/geni as well.. so probably they took the same approach with bios configuring everything as whatever it needed to be
<aceridus>
Is DT really the only way that will likely succeed at this? ACPI isn't worth it for some reason? If I focus on regulators how can I know that my DT changes are working, especially without a function keyboard to poke around in /sys and /proc?
<aceridus>
I am trying to find the smallest nibble to work on currently and it seems like the highest impact item would be getting the keyboard to function whether it be through ACPI or DT...
<robclark>
so ACPI won't get you various accel things (cpufreq, gpu, venus (vid enc/dec), modesetting, etc).. but it should get the basics and in a way that works for all 7c windows laptops (no idea how many of those there are)..
<robclark>
long run, you want dt for enabling all the shiny things
<robclark>
but acpi boot is likely what distro installers will use until they figure out *which* dtb to install
<shawnguo>
robclark: ACPI support on Qualcomm laptop seems hard to move forward, so bamse suggested to use DT kernel for installer for those new laptops like thinkpad x13s. it makes some sense to me.
<robclark>
if there is a sane way for distros to use dt, then fine w/ me.. I think getting "full accel" support w/ acpi is going to be pretty hard
<robclark>
otoh, I guess we'll see how much distro's are willing to bend over backwards for hw that doesn't really look like standard x86 uefi+acpi with the apple laptops.. since they are far weirder ;-)
<shawnguo>
yeah, getting distros to buy it would probably be a problem
<aceridus>
Ok, so it sounds like DT might be the better option. I can try to focus on that, but can anyone give me some guidance on how I can verify my DT changes are working? If I start by enabling regulators how can I know they are actually enable and working? I suppose kernel message will be the only way until I find the right DT setup to enable the keyboard to work?
<jenneron[m]>
aceridus: you will see pmic logs in kmsg
<jenneron[m]>
about setting voltages
<jenneron[m]>
use efifb and console=tty1 in cmdline
<aceridus>
I have earlycon=efifb already and I see the console all the way to the (initramfs) prompt
<bamse>
robclark: the solution for the distro installer is to move the dtb to the firmware...
<bamse>
robclark: that solves all the practical problems for a general purpose OS
<robclark>
heh, so full circle back to DtbLoader ;-)
<robclark>
but tbh, I agree
<bamse>
yes, but so far DtbLoader has been part of the OS
<robclark>
it shouldn't be, at least not long term.. and with a bit of work we can get fwupd to deliver updated dtb
<bamse>
correct
<robclark>
ofc if we can get ihv's to buy in and ship dtb support that would be even better (assuming we can get a sane fw update story as bindings for new things make their way upstream)
<bamse>
what's left is the issue of writing DT, which might be a duplicate effort for devices that already has ACPI tables...but there's quite nice leverage against all other qualcomm platforms there...
<robclark>
but without that DtbLoader+fwupd could do the job
<robclark>
yeah
uuidNuniq has joined #aarch64-laptops
uuidNuniq has left #aarch64-laptops [WeeChat 3.5]
phire has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
aceridus has quit [Quit: Page closed]
falk689_ has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
falk689_ has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
kettenis has joined #aarch64-laptops
<kettenis>
FWIW, we've had some success with sc7180 laptops and ACPI in OpenBSD
<kettenis>
biggest challenge to get the keyboard/touchpad to work is the GPIO stuff
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
falk689_ has quit []
falk689 has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
falk689 has quit [Quit: No Ping reply in 180 seconds.]
iivanov__ has quit [Ping timeout: 480 seconds]
falk689 has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
solsTiCe has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving...]
matthias_bgg has joined #aarch64-laptops
gwolf has quit [Quit: WeeChat 3.4]
<bamse>
kettenis: we've had success in getting some basic set of functionality up on both sdm850 and 8cx-based laptops as well
gwolf has joined #aarch64-laptops
<bamse>
kettenis: but then it stops; gpu, audio, wifi, modem isn't descrribed in a suitable fashion
<bamse>
kettenis: and then there's the whole power-management thing
<kettenis>
bamse: agreed, you hit a pretty hard wall when the basics are done
<kettenis>
we'll probably switch to device trees at some point, but may keep ACPI support to bootstrap the installation
<hexdump0815>
aceridus: i have a galaxybook go here as well which i would like to get working with linux - tried it and got as far as you
<hexdump0815>
my experiments are currently on hold due to little time and energy right now - but i'm very happy about any kind of progress regarding this device and will come back to working on it towards later this year most probably
<hexdump0815>
i think it would be very nice to get linux working on it as there are plenty of devices out there which will most probably be forgotten at the next windows update and would all wait for linux on them :)
<aceridus>
hexdump0815: Maybe we can help each other out. I feel in quite over my head because I am not a hardware/drive/device tree developer. I have plenty of experience in other areas, just not the ones required for hardware bring-up
<hexdump0815>
aceridus: i'm in a similar position as you i think, but i hope to get forward step by step maybe - i'm not expecting to get anywhere very quickly, but hopefully over time and currently collect all potential useful info like the discussion here right now
<aceridus>
The first major issue at hand is to figure out how to get the keyboard functional so we can at least have a full and proper Linux environment to poke around in to slowly address the other issue. As of yet, I have been unsuccessful in get a functional keyboard including trying external USB ones. It makes it very challenging to dig and fix because my dmesg access is currently via videos captured on my phone...haha
<hexdump0815>
it looks like the acer aspire 1 has a design following quite closely to the dev board, but the galaxy book go seems to be a different design, so the acer aspire 1 stuff might not help us much on the samsung
<hexdump0815>
but all is just guessing from reading and some experiments ... regarding working without kbd i was thinking about maybe just adding lines to write interesting dmesg, sysfs, procfs info out via rc.local
<aceridus>
I will read through that. I have been trying to piece together a dts for the galaxybook go, largely based on sc7180.dtsi and some of the trogdor chromebook dts files. I have the regulator sections pulled over an presumably working based on boot messages, but don't know for sure. I have enable all of the i2c devices because I know the keyboard is behind one, but can't really know if my attempts are succeeding.
<hexdump0815>
this would give you a fully running debian system for such rc.local experiments as mentioned above
<aceridus>
I have a USB that I made myself including a custom grub, grub.cfg, 6.1.0-rc1 upstream kernel, Ubuntu jammy rootfs. It boots and drops me to the (initramfs) shell due to not find the rootfs UUID and the keyboard doesn't work yet.
<aceridus>
I still need an effective way to prove that my dts is in fact enabling the regulator, that the i2c devices are in fact enabled. If I can verify those items then maybe all I am missing is getting the keyboard driver wired to the correct i2c. I speak generally because I don't really understand how that should look in a dts
<hexdump0815>
aceridus: i think there is some i2cdetect command - maybe it can be helpful and watching out for i2c stuff in /sys/class and /sys/bus, /sys/classes and maybe /sys/devices? without a keyboard maybe making the system write all interesting info to rootfs, syncing and rebooting via rc.local or similar?
<aceridus>
Yea, I had considered an approach like that but USB is not operational so I can't write back to it. The running environment is purely the kernel and initrd in RAM, so capturing output appears to be limited to screen output currently.
<hexdump0815>
oh right - i forgot
<aceridus>
I am currently trying to design a very directed approach, namely poking into very specific areas, via initrd scripts, to figure out why the keyboard is setup. Once I can get the keyboard working then it opens up the entire find and fix process dramatically
<aceridus>
Why the keyboard isn't setup, rather
<hexdump0815>
then initially there most probably only the option to print stuff out and film it - there is some boot delay kernel option to slow down boot printk - might be helpful in such cases
<aceridus>
I tried boot_delay without any noticeable effect, however the efifb moves sluggishly anyway. Now that I am past the smmu crash issue on a 6.1.0 kernel I am at least at a steady state screen, so I can dump relevant information and screenshot it. I might need help tracking down what the relevant bits are though, like what should I be checking to figure out why the i2c keyboard isn't registered?
<hexdump0815>
i think for boot delay to work a kernel option has to be enabled - otherwise it gets ignored
<aceridus>
Ok, finally I have a way to get some visibility via initrd scripts. I can now see that there is nothing populated under /sys/class/i2c-dev nor under /sys/class/i2c-adapter. So, apparently the geni-i2c driver that handles i2c7 isn't loaded. I can see it is built as a module based on arch/arm64/configs/defconfig and I can see the .ko in my initrd image, so not sure why that isn't loading...
<jenneron[m]>
aceridus: you need a device tree binding for i2c to show up
<jenneron[m]>
check other dts:es using hid-over-i2c for examples
<aceridus>
There is a dt binding for i2c as a result of including sc7180.dtsi. I added a &i2c7 { status="okay"; }; to my own dts to make sure it is enabled. I can see from greping /proc/modules before and after a modprobe that the i2c_qcom_geni module was not automatically loaded but is after the modprobe. Still, no entries in /sys/class/i2c-dev
<aceridus>
A 'dmesg | tail' after the modprobe shows no module activity from i2c_qcom_geni either
<aceridus>
Is the smmu a prerequisite for the i2c and keyboard to work?
derzahl has quit [Remote host closed the connection]
<bamse>
aceridus: dma-transactions in the i2c controller goes through the smmu
<bamse>
aceridus: so if you can avoid the dma code path, you should be fine without smmu
derzahl has joined #aarch64-laptops
<aceridus>
bamse: Ok, so message like "arm-smmu: probe of 5040000.iommu failed with error -110" are a problem and will lead to i2c not working?
<bamse>
aceridus: 5040000.iommu is likely the gpu-specific smmu, so that should not be an issue
<aceridus>
Yes, I just realized that from searching 5040000 in sc7180.dtsi
<jenneron[m]>
aceridus: please push your code somewhere
<jenneron[m]>
at least on something like dpaste.com
<aceridus>
bamse: Are there any other prerequisite devices that I need to verify are working before the i2c keyboard can?
<aceridus>
jenneron[m]: Which code, my dts?
<jenneron[m]>
yes
<jenneron[m]>
my guess is that you don't have a &qupv3_id_1 { status = "enabled"; };
<bamse>
aceridus: should just be pinctrl-sc7180 and the geni drivers, if you have interconnects references in your i2c master node, remove those for now to remove the dependency on interconnect providers
<aceridus>
jenneron[m]: You are correct I don't have that enabled
<aceridus>
Ahh, yes, of course. I said from the beginning I am quite a novice at device tree. Thank you for pointing that out, I just learned a very important part of interpreting other device tree files!
<aceridus>
That has moved things forward some. It is also why the i2c_qcom_geni module wasn't being auto loaded. Still no i2c devices in /sys but I do see a message "geni_i2c a84000.i2c: Bus frequency not specified, default to 100kHz.
<aceridus>
There is also a "platform a84000.i2c: deferred probe pending" message
<aceridus>
A number of deferred probe pending messages actually.
<jenneron[m]>
some kernel config stuff
<jenneron[m]>
i can send you a config which should work
<aceridus>
jenneron[m]: Thanks, let me try that. Can you explain in simple terms what is happening here? For example, how you know there are related to kernel config stuff?
<jenneron[m]>
aceridus: deffered probe means that some of depending hardware is not yet probed. e.g. when i2c depends on smmu, but smmu is not yet probed, so i2c is deffered
<jenneron[m]>
in your case it has to be either missing device tree something or missing some kernel config
<aceridus>
What about missing firmware blobs like .mbn files?
<jenneron[m]>
they are not needed for i2c
<jenneron[m]>
you can find them on your drive C in windows
<jenneron[m]>
you will need them eventually
<aceridus>
Ok, hopefully I'll cross that bridge later then. Just like in the phone world, the mbn components are largely a mystery to me. As in, I know they are closed source blobs, but don't really understand what they are typically dependencies of
<aceridus>
I know they are firmware for qcom modems and other proprietary chips, just don't know how to decipher what roles they provide to the OS
<jenneron[m]>
they are uploaded into remote processors by driver
<aceridus>
I guess it is a matter of following through error messages to realize something like the adreno gpu will depend on having an mbn file loaded?
<jenneron[m]>
well.. yeah, this way should be good enough
<hexdump0815>
aceridus: btw. how is your initrd script setup to print out stuff right now? just curious what kind of solution you found - seems to work quite well actually ...
<javierm>
aceridus: there's a /sys/kernel/debug/devices_deferred entry too that list the devices that are still in the deferred list after booting
<aceridus>
hexdump0815: I setup a panic initrd script under my arm64 rootfs (built using debootstrap) since the initramfs currently always panics due to not finding the rootfs (obviously it can't due to no USB yet). https://dpaste.com/38U75HLWD
<hexdump0815>
aceridus: clever :)
<aceridus>
hexdump0815: The only limit is the screen real estate and the commands available in the initrd
<aceridus>
jenneron[m]: Your config seems to be doing more, but now I am getting stalled CPUs/tasks. I don't get to my initramfs anymore, so can't really dump dmesg. The screen gets garbled with boot messages and the stack trace interleaved, fun...
<jenneron[m]>
trace intervealed? ehh
<jenneron[m]>
do you have clk_ignore_unused pd_ignore_unused?
<jenneron[m]>
oh, i see
<aceridus>
The clearest I can see is a __switch_to+0xe4/0x160p compression: deflate
<jenneron[m]>
stack trace intervealed*, sorry. what does it tell?
<aceridus>
Yes, I do have that set
<jenneron[m]>
it's travmurav's config which he uses on his 7c windows on arm laptop with device tree
<jenneron[m]>
maybe he can tell you more about it
SSJ_GZ has quit [Ping timeout: 480 seconds]
<hexdump0815>
aceridus: maybe try again with you kernel from before which worked and cat /sys/kernel/debug/devices_deferred to see what is maybe missing - just an idea ...
<steev>
maybe disable secureboot? or is secureboot disabled?
<aceridus>
steev: It is disabled
<bamse>
doesn't matter, there will be certain resources that are reserved for trustzone in the non-chrome versions of sc7180...
<bamse>
it's quite likely that you at least need to mark some gpios as protected (as is done in most other devices) and there might be some clocks that the non-chrome firmware handles for us, so the OS isn't allowed to touch them
<aceridus>
Wooooo, big step forward, I see i2c devices now! I went back to using my kernel since I knew it would boot and I could see info. A bit more digging and cross referencing .config, Kconfig and Makefiles I was able to figure out that qnoc-sc7180 driver was being built as a module. I switched that to built-in and now I can see i2c devices! https://imgur.com/a/4BSXYD0
<aceridus>
jenneron[m]: If you can help me understand how to create a hid-over-i2c binding for i2c7 the keyboard just might work
<jenneron[m]>
aceridus: check my info from that message
<jenneron[m]>
and check how it's binded on other devices
<aceridus>
jenneron[m]: From your previous explanation does "0x05 address" mean something like keyboard@5 { ... }? Also, when you said "0x140 active-low pulled-up interrupt" I don't understand what that means nor how to properly encode that to an interrupt = <...>; value.
<jenneron[m]>
yes, node-name@5 and reg = <0x05>
<jenneron[m]>
0x140 is hex value, convert it to decimal
<aceridus>
So, why the literal 0x140? Most of the other examples I see are using a &... reference of some sort
<aceridus>
jenneron[m]: "interrupt = <320 active-low pulled-up>;" generates a compile error, so I have no clue how to correctly define the interrupt = <...>; part
<jenneron[m]>
no
<jenneron[m]>
use syntax of others
<jenneron[m]>
320 is just a number of pin
<jenneron[m]>
those message just my description of hardware, it's not exactly what should be in DT