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)
klardotsh has quit [Remote host closed the connection]
<steev>
somewhat interestingly? the flex5g's recovery is only 9.8GB whereas the c630's is 12.5GB
<steev>
RIP aws
vkoul has joined #aarch64-laptops
srinik has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
<Dylanger>
Hey all, I'm trying to get the Acer Spin 513 (MT8195) working on Cadmium/Vanilla Linux Mainline, does anyone know what the general flow is? I'm guessing step 1 is cherrypicking the DTS from ChromiumOS's Kernel repo?
<Dylanger>
Why aren't these merged into mainline already?
<Dylanger>
Looking at Trogdor/Homestar, it looks like Linaro usually add initial support
<Dylanger>
Bjorn Andersson from Linaro did the initial commit
<Dylanger>
In Sept 22, 2021
<Dylanger>
I'm not sure what the rules are around this
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
Dylanger: trogdor is qcom and i think bjorn is qcom kernel maintainer - the mediatek stuff is usually sent in by some mediatek or google developers
<hexdump0815>
but in the end i guess there is still a lot of work to be done to get anywhere useable on mt8195 right now - maybe start with a self built chromeos kernel on top of a regular linux dist first
<Dylanger>
<hexdump0815> "Dylanger: trogdor is qcom and..." <- Is there any regulations around this? I'm assuming not, it's just of Google or MediaTek feel like it
<Dylanger>
I'm going to try cherrypick in the DTS and put together a cadmium build, using my SuzyQ I should be able to observe AP Kernel output and see where it breaks
<Dylanger>
I'm assuming the display won't work
<macc24>
hexdump0815: yeah i think so
derzahl has quit [Remote host closed the connection]
<macc24>
leezu: i don't think i tried it any since
<macc24>
also there's no S3 because we aren't using acpi
<macc24>
leezu: yeah just booted up my lazor running 5.17.0 and it works
<leezu>
And /sys/power/mem_sleep shows [deep]?
<macc24>
the led on the power button turns off
<leezu>
Do you mean that what EC calls S3 isn't the same as ACPI S3? Because my EC does say "power state 7 = S0->S3, in 0x001e", though shortly thereafter "Warning: Detected sleep hang! Waking host up!"
<leezu>
Great, you are using the deep suspend. With s2idle the led at the power button remains on.
<macc24>
"[ 24.143661] PM: suspend entry (deep)"
<macc24>
leezu: keep in mind that led on power button remained on with 'deep' suspend before 5.17 too
<macc24>
no idea why ¯\_(ツ)_/¯
<leezu>
I'll try with 5.17. Or do you have any userspace tricks to make this work? On 5.18 the system simply hangs and EC's "Warning: Detected sleep hang! Waking host up!" doesn't succeed in waking the system back up
<leezu>
Ok, great. Do you have plans to try 5.18? If it's indeed a regression, do you have any guess what may have introduced it? Or would we need git bisect?
<macc24>
i plan on testing 5.18 in couple of days
<macc24>
i have no idea, sorry. if amstan's here he might know
<macc24>
currently i'm sorta on a break from arm chromebooks to hack on some gaming handhelds
<leezu>
No rush. But once you try 5.18, I'm curious if deep suspend will also be broken for you
<macc24>
it may or may not depend on kernel config
<javierm>
macc24: interesting, what gaming handhelds are you hacking on ?
<macc24>
javierm: anbernic rg503, rg552, rg353p(arrives monday/tuesday), aya neo next pro and ayn odin(if i'm bored enough)
<macc24>
there are also odroid go advance and odroid go super but they are mostly done
<javierm>
macc24: pretty cool! I saw some of these to buy for my kids but the end we just built one using a rpi zero and a hat that has a SPI display and some GPIO buttons
<macc24>
nice
<macc24>
i personally hate raspberry pis
<javierm>
macc24: yeah, I can relate. But with my fedora developer hat I need to care because is quite popular for our users
<macc24>
aiming for "whatever anbernic you choose runs upstream"
<javierm>
macc24: awesome
<macc24>
i'm also working with couple distro devs on mainline support, besides my proof-of-concept distro
<javierm>
macc24: cool. What's their boot stack? u-boot ?
<macc24>
yeah
<javierm>
macc24: then should be easy to support it in fedora once there's good upstream support. Ping me if you need and I can do the fedora kernel packaging bits
<macc24>
javierm: keep in mind that some(rg552) have downstream u-boot on their emmc
<macc24>
and some others(their rk3326 devices) have downstream u-boot on their spi flash chips
<javierm>
macc24: I see. Wonder if are old enough that don't support uboot distro commands and EFI_STUB enabled
<macc24>
i don't know
<macc24>
i just use mainline u-boot
<macc24>
and wipe internal storage
<javierm>
macc24: and, there's mainline u-boot suppor then. Great
<javierm>
macc24: I see there's an anbernic rg99 that's quite cheap. But it has an Ingenic SoC and not rk
<macc24>
after rg351p/rg351m they started doing arm machines
<macc24>
i have no plans to support mips handhelds
<macc24>
and i'll likely do anbernic's rk3326 handhelds after rg353p/rg503(rk3566) and rg552(rk3399)
<javierm>
macc24: yeah, but I'm wondering now if I should buy and try to hack on this :)
<javierm>
I never hacked on a mips device and it's only ~40 euros here. Could be fun
<javierm>
but OTOH probably is going to end in the cemetery of never-started-projects :P
<steev>
Dylanger: for the record, bjorn is bamse
<steev>
macc24: ooh i might have to try your kernel out, i happen to have an advance here
<macc24>
steev: with my battery driver and adc-joystick fix it will run mainline just fine