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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jgowdy has quit [Quit: _]
jgowdy has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
deathmist1 has joined #aarch64-laptops
deathmist has quit [Read error: Connection reset by peer]
<baozich>
Hello everyone, I have a Lenovo Xiaoxin 14s (Snapdragon X1P64100). It looks like it is a simplified version of the X1E, with 4 fewer CPU cores. I wrote an 8-core version of the device tree from the existing x1e80100 laptop, but the kernel booted up for a while and immediately rebooted without further info. Any ideas?
<travmurav[m]>
x1p-64 should be 10 core (hamoa like 12 core x1e) and x1p-42 should be 8 core, which is a completely different chip (purwa), you might want to double check that firs
<baozich>
Oh, it is X1P42100
<travmurav[m]>
purwa is more fun, no one tried to run it I think and firmware might be different, though my impression was that it's still supposed to be drop-in hw/sw wise
<baozich>
I dumped its ACPI table, it looks like it has 12 cores in 3 clusters and there is one cluster disabled.
<travmurav[m]>
does dsdt say SCP_PURWA somewhere on top?
<baozich>
let me check...
<travmurav[m]>
(or SCP_HAMOA for higher end silicon)
<baozich>
Yes, DSDT says "SCP_PURWA"
chrisl has joined #aarch64-laptops
<baozich>
Is there anyway to debug? The system reboot very soon after kernel has just outputed some info.
<baozich>
(I had to use my phone to record the boot and play it back to see the few kernel logs.)
<travmurav[m]>
depends on what's the issue: touching reserved memory/protected gpios or something like that would be hard, not sure where reserved gpios are in acpi (though I'd hope at least uefi memory map carves out all protected stuff)
<baozich>
However, considering it's purwa, the device tree where I reuse x1e80100 may have access to the reserved address?
<baozich>
maybe need rework the DT?
<travmurav[m]>
for ram, uefi is /supposed/ to provide os with correct reserved/missing memory, for IP blocks - sure thing, I have no idea if purwa has different mmio memory map
<travmurav[m]>
baozich: do you have your changes uploaded somewhere?
<travmurav[m]>
I assume you've just copied x1e dtsi and disabled some cpus?
<baozich>
not yet.
<baozich>
travmurav[m]: yes, I reused most of the DT from a lenovo x1e laptop and disabled the last cpu cluster.
<travmurav[m]>
is it yoga or t14s?
<baozich>
yoga
<travmurav[m]>
as in, the one you used as a base
<travmurav[m]>
right
<travmurav[m]>
hm
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
which kernel did you start from? mainline or some wip fork? (i.e. johan's )
<baozich>
I use the Ubuntu concept (installer) image
<travmurav[m]>
mhm
<baozich>
And modify the grub.cfg with the customized DT
<baozich>
I think maybe I should disabled some mmio device to see if it can boot further
<travmurav[m]>
you could try to use the boot_delay=<milliseconds> to slow down the logs
<travmurav[m]>
I think I've looked /very quickly and loosely/ at some point at some purwa dsdt and got an impression it's drop-in but could easily miss something obvious
<travmurav[m]>
and not like I have any actual documentation so that question is probably better asked to someone @ quic/linaro who actually has some docs
<baozich>
I have recorded the boot process with my phone. Which confused me most is that it rebooted without any oops message.
<travmurav[m]>
firmware can just kill the system like this if it doesn't like something, that's sadly normal on modern things
<baozich>
I see.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<baozich>
travmurav[m]: do you know any x1e dsdt that uploaded somewhere? I guess there might be some clues to comparing the device tree with x1e with x1p.
copticcurse has joined #aarch64-laptops
<travmurav[m]>
baozich: in the laptops repo there is a big collection
<travmurav[m]>
(To which i encourage to contribute your acpi dump too)
<baozich>
travmurav[m]: just create a PR to upload the dump.
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<SpieringsAE>
fixed up a python venv so I can run with CHECK_DTBS=y, but jeah, it doesn't seem to have any opinions about pinctrl-0 = <&1 &2>; vs <&1>, <&2>;
<SpieringsAE>
I will go for option 2 though
<SpieringsAE>
it does complain about a usb thingy in x1e80100.dtsi though
<SpieringsAE>
interrupt-names too short in usb_2
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
SpieringsAE: check dtbs only check compiled stuff, so the <> are lost at that point, but it should've complained that you have -1 and -2 but single names= entry
<travmurav[m]>
at least I think it should
<SpieringsAE>
Jeah I didn't check that one, lets try that out
<SpieringsAE>
nope it seems perfectly fine with that for some reason
<travmurav[m]>
sad I guess bindings don't constrain that
<travmurav[m]>
perhaps adding W=1 and dtc could have some internal warnings for it, not sure
deathmist1 is now known as deathmist
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
sally has quit [Quit: sally]
alfredo has quit [Ping timeout: 480 seconds]
sally has joined #aarch64-laptops
user_anoz has joined #aarch64-laptops
anozetsubou has quit [Ping timeout: 480 seconds]
kalebris- has joined #aarch64-laptops
kalebris1 has joined #aarch64-laptops
kalebris_ has quit [Ping timeout: 480 seconds]
kalebris has quit [Ping timeout: 480 seconds]
kalebris- is now known as kalebris
<robclark>
travmurav[m]: fwiw, I guess purwa probably has a different gpu (probably one fewer SP?).. idk, dpu might be stripped down a bit too (support fewer external displays?) Idk how much everything else differs.
<travmurav[m]>
hm I guess that would make sense
<travmurav[m]>
I wonder if qcom has some official spec sheet somewhere
<robclark>
I based that guess on # of gpu gflops they list in the table of x1 parts.. hamoa has 3 SP, so purwa with 2 SP and lower clocks seemed about right
<robclark>
we do know that the die size is physically smaller, but not sure if that shrink comes entirely down to dropping a cpu cluster
<travmurav[m]>
the spec sheets seem to be same apart from cpu and gpu speed (i.e. both says 3 displays)
<robclark>
hmm, ok.. that is easier if only the gpu is diff
<travmurav[m]>
so I guess it might as well be same base platform minus one cpu cluster minus one gpu SP
<robclark>
yeah, could be.. I guess we'll see what happens as soon as someone tries to enable gpu
<travmurav[m]>
would probably make most sense from ""pc style"" designs where one'd hope it to be (mostly) sw/hw compatible to make common boards/os images
<travmurav[m]>
but then weird that purwa thing decided to crash