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)
<qzed>
I think the location shouldn't really matter on this kind of platform
<qzed>
maybe give good old grub a try...
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
Lucanis0 has quit [Read error: Connection reset by peer]
flowriser has quit [Remote host closed the connection]
SallyAhaj has quit [Ping timeout: 480 seconds]
iivanov has quit []
iivanov has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
Lucanis has quit [Read error: Connection reset by peer]
Lucanis has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
SallyAhaj has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<qzed>
oh right, you'll also need to specify that somehow... in grub there's a devicetree command and I think steev and bamse use dtbloader for that
<qzed>
oh right, the kernel also has an option for that
<qzed>
so I think normally, dtbs should be provided by firmware... which isn't going to happen on WoA devices
<qzed>
that's why DtbLoader exists, which AFAIK replicates what firmware should do
<qzed>
and I think the grub command does something similar
<qzed>
but DtbLoader is designed to work with multiple devices and the intended solution for WoA
<qzed>
I've never really looked at it though and just used the grub command because it was easier xD
<qzed>
I've briefly tried archboot and archiso, but things didn't want to work for me... so I did a custom thing for that... which isn't really that great either, but it seems to do the trick
<qzed>
(didn't want to work meaning I didn't manage to make it run on my x86 desktop)
<qzed>
yeah... I don't have trouble with arch itself, just the iso stuff seemed to break on x86, which is a bit unfortunate for me since the spx is my only aarch64 device
<qzed>
in the end I ended up chrooting and using qemu anyways... so might as well have set up a vm for that...
falk689_ has joined #aarch64-laptops
<qzed>
look into qemu-user-static and binfmt_misc
<qzed>
essentially, the kernel lets you register an executable handler for some binary formats, so you can set up to run x86 stuff automagically via qemu, but I'm not sure how well that will work with libraries and so on
<qzed>
(mostly thinking of path conflicts and so on, which you could probably work around with LD_PRELOAD, but might need some fiddling)
falk689 has quit [Ping timeout: 480 seconds]
<HdkR>
If you're wanting non-static x86 executables then look in to box86/box64/fex-emu
<steev>
is this a thing where i cant see the other half of the conversation because clover's name isn't registered or something?
<HdkR>
Likely, I just see qzed speaking in to the void :)
<steev>
same
<qzed>
huh, possibly... you guys aren't using matrix, right?
<steev>
robclark: maybe now that spammers have died down on things, we can remove the requirement?
<steev>
qzed: correct :D
<HdkR>
Aye, irssi all the way
<bamse>
which flag is it that i'm supposed to drop?
<steev>
n i think
<bamse>
"n - no external messages"
<steev>
maybe it's M then?
<HdkR>
It's M
<HdkR>
Not allowed to speak unless identified with Nickserv, and most Matrix users aren't. Client doesn't show Matrix users that their messages are getting rejected but it is still shared on the Matrix side.
<bamse>
would have been wonderful if matrix forced people to identify, given that it's a strict requirement to do anything useful on the irc side
<qzed>
yeah...
<bamse>
but now we'll know if qzed is talking to himself or not ;)
<qzed>
heh, maybe I'm getting crazy starring at ghidra all day
<qzed>
trying to make sense of scm calls...
amstan has joined #aarch64-laptops
<amstan>
I hear the permissions here have been relaxed a little bit?
<amstan>
steev: nvm, i'm here
<amstan>
steev: which one's `Thinkpad x13s` again?
<amstan>
$2000 windows ARM laptop :O
<steev>
ye
<steev>
32gb of ram tho
<steev>
i cheaped out and only got 16 tho :(
<klardotsh>
I saw it for $1400 the other day, though I think that's just introductory promo pricing
<steev>
yeah, they're always "on sale"
<bamse>
today they seem to be $2169 and up...
<bamse>
probably because arnd merged the first pull request
<clover[m]>
steev: can you hear me? just a test
<steev>
clover[m]: yes we can
<clover[m]>
oh ok, hi :)
<steev>
hi :D
<steev>
i promise, if you tried contributing to the conversation before, we weren't purposely ignoring you!
<steev>
i noticed qzed talking to clover the other day... just didn't think anything of it at first
<steev>
yes, grub supports the "devicetree" command, you can manually enter it in the grub config with "devicetree /path/to/the/full/dtb/file.dtb"
<steev>
that actually overrides what dtbloader does too, if you want/need to test something that way
<clover[m]>
is there a difference between grub and systemd-boot?
<clover[m]>
i come from pinebook pros where we just use uboot
<steev>
grub isn't part of systemd
<steev>
(thankfully)
<steev>
systemd-boot is/was gummiboot
<steev>
and i have no idea how to use it :(
<clover[m]>
oh ok. its what mkarchiso uses by default to generate an ISO. to catch you up I am making an archiso for anyone to flash to a USB to install arch on x13s. or at least i am trying ahah
<clover[m]>
kernel initramfs, and maybe dtb is put into an efi system partition, and i think thats how the usb boots
<clover[m]>
i dont think there is anything in /boot at all
<clover[m]>
* kernel, initramfs,
<steev>
a quick look and i think systemd-boot should also support it
<clover[m]>
i think you can just follow the ui pretty much
<klardotsh>
steev: check out whatever commit should be the tag, "git tag -am 'whatever message here' v1.2.3",git push --tags
<klardotsh>
er, -asm is what I use. whatever.
<steev>
yeah i'll keep the s off, since i don't have my keys on the x13s yet since i'm still testing things
<steev>
oh lord what have i done
<steev>
why is it pushing like 200MB of stuff just for a tag
<klardotsh>
o_o is it pushing **all** the tags in the history of forever? wouldn't github already have those?
<steev>
apparently not
<steev>
luckily i didn't do this on the one where i have.... 18 remotes
<clover[m]>
i might be able to just pull it by the commit, if you can't get the tag working
<clover[m]>
nbd
Evaia63 has quit [Quit: Hack the Gibson]
<steev>
oh it should be there now
<steev>
best not to pull by commit
<steev>
because i force push, because i'm an asshole
<clover[m]>
yep i see it. that should work ty
<steev>
np :)
<steev>
does the tag stick around even if i force push (fwiw, the force push was ditching the kali wifi patches)
<steev>
once we reach a point where wifi works properly, i'll try again
<steev>
clover[m]: also the "laptop_defconfig" is closer to what debian expects than anything, so might want to start with that one, and not the defconfig, and just turn on the various bits that arch likes... like, uhh, compressing the modules
<steev>
clover[m]: if you read through the .dts file though, or even just grep for the word firmware, you will see the files it will want from the windows partition. assuming yours came with windows 11 pro like mine did, you'll want to disable bitlocker, either temporarily, or permanently
<steev>
so you can mount the partition in linux, or just install wsl and copy the files across to a different machine you might have (or usb)
<steev>
and then put them in that path in /lib/firmware/
<steev>
which, again, that path will likely change in the future
<bamse>
and the new files are expected to be part of the linux-firmware-qcom package
<steev>
oh <3 you guys are actually making progress there
<bamse>
yes
<steev>
clover[m]: currently there's no battery driver, but you should get roughly 10 hours of life
<steev>
you'll just have to wing it for remembering how long it's been up
<bamse>
make sure you have the qcadsp8280.mbn firmware in place though...so that it charges
<bamse>
and can know if you have that by connecting the charger and see that the LED next to the power button blinks 3 times
<bamse>
and you can*
<steev>
oh, that's right, yeah that's important
<bamse>
well, it makes things slightly less exciting at least
<bamse>
steev: there, now i've seen proper output of i2cdetect
<steev>
woohoo
<steev>
man
<bamse>
on db845c though...on sc8180x it isn't able to detect any of the i2c devices
<steev>
the performance of this is vnice
<steev>
admittedly, just the default defconfig of next, but only 10 minutes? to build a debian kernel package
<bamse>
do you have sync_state in the interconnect driver?
<bamse>
or perhaps, how much ddr throughput do you have?
<qzed>
and that service calls a tz-app syscall again
<qzed>
so this thing looks like something that another service would call, and the tree driver plays manager for all of that
<qzed>
so what I'm thinking is: what if the uefi runtime service provides function stubs that call back to that service via the tree interface, which relays those calls to uefisecapp (what seems to be actually implementing that stuff)