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)
<ardb> the bootorder stuff is a bit weird on those systems
<ardb> it seems the LoadOptions are always superseded by the firmware
<ardb> for Boot0000 i mean, which is the Windows Boot Manager on my C630
<steev> I wish they’d open the firmware up since they’re EOL
<rfs613> seems my x13s is "different" somehow. The 6.0.0-rc3 kernel included in DVD-2 debian image boots. But no luck with 6.1.0-next, neither self-build, nor abelvesa binaries. It starts booting but then power light flashes and display goes blank.
<steev> rfs613: oh, you probably need some extras with next- let me find
<steev> make sure your /etc/initramfs-tools/modules file has that, then rebuild the initramfs
<steev> or just reinstall the kernel deb
<rfs613> steev: I'll give it a shot tomorrow (if the winter storm doesn't knock out our power!)
<steev> relatable
<steev> it's 23 here and i'm in south texas and.... my neighbors were like, we were gonna give this to you on christmas but we think you're gonna needit before then... and they'd gotten me a winter coat
<rfs613> Oh I thought you were going to say a generator
<steev> hah
<steev> well i'm in an apartment so... no geneator
<steev> my hands are also already frozen, was just outside playing with their dog
<steev> he's loving it (grand pyreneese
<rfs613> hehe well good luck!
<steev> mani_s: btw, for the edac/llcc stuff, should we actually have any memory info?
<xypron> ardb: I have uploaded SCT results for the X13s to https://gist.github.com/xypron/d51d049e3b24d77a566707a9ad25b927 . It is not too bad.
<xypron> ardb: Boot0001 points to Windows. I set Boot0002 to /Pcie(0x80,0x0)/USB(0x1,0x0) and BootOrder to 0002,0001. The system boots reliably from the USB stick. With F12 I get the boot menu and can choose Windows.
<xypron> ardb: You just need an UEFI shell on a USB stick as /EFI/BOOT/BOOTAA64.EFI to edit the variables
<steev> yeah, but it would be nice to be able to edit them without such hacks
Lucanis0 has joined #aarch64-laptops
<xypron> steev: It would be good enough that after installing Linux we would have two new boot options: 2) Linux, 3) Boot Options Editor. Where 'Boot Options Editor' would be an EFI application that we still have to develop.
<xypron> But up to now I am out of luck building an EFI binary that is properly executed by the firmware.
Lucanis has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> there should already be one that runs on the debian iso
<steev> (i dunno how it's built, i just know there is one)
SSJ_GZ has joined #aarch64-laptops
apalos has joined #aarch64-laptops
alpernebbi_ has quit []
alpernebbi has joined #aarch64-laptops
<ardb> efibootmgr should work on the x13s once the efivars qtee patches are merged no?
<Caterpillar> is Linaro's Debian image updatable?
<apalos> ardb: We are going to send patches on that same thing for OP-TEE
<apalos> and yes efibootmgr works fine with those applied. The approach abstracts the qsee ones a bit,
<apalos> qtee*. But I only remember that qtee version a few months back, was there a newer one?
<apalos> We've basically added an abstraction layer in drivers/tee, so each TEE implementation has to provide it's own callbacks for SetVariable, GetNext etc
<apalos> and those callback we register on the EFI subsystem
<jhovold> apalos: do have a pointer to that work you've done? and who are "we"?
<jhovold> apalos: if you're referring to qzed series, I think there has only been one version:
<apalos> we = linaro, a colleague picked up the patches I linked and cleaned the up and submit and RFC
<apalos> jhovold: yea that's the series I remember, I commented on those emails
<apalos> jhovold: on the series I linked, I was installing an empty config table to trigger the kernel switching the RT calls.
<qzed> yeah sorry, been a bit busy lately but I'll try to re-spin it at some point in the next two or three weeks
<apalos> However people pointed out that we might not be able to have that table installed Arm laptops, sin ce we dont control the firmware
<jhovold> apalos: ok, thanks. I'll take a look at that too.
<apalos> So the change on the RFC we'll send is that we made the TEE responsible
<qzed> apalos: you're talking about an abstraction over qtee? I assume that's something I should build off of then?
<apalos> qzed: if you agree with the approach yes
<apalos> that would be awesome, because we'll have an abstraction in drivers/tee
<apalos> so that will work for all TEE implementations we currenlty have support for
<qzed> I do think that some kind of abstraction is good to have here, I was thinking about a similar thing for my v2
<qzed> do you have a pointer to your proposal?
<apalos> qzed: Think so, lemme find that repo
<apalos> qzed: can't find that repo now, but I can forward you the patches
<qzed> thanks, that would be great
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #aarch64-laptops
akaWolf0 has quit [Ping timeout: 480 seconds]
akaWolf0 has joined #aarch64-laptops
krzk has quit [Remote host closed the connection]
krzk has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
Lucanis0 has quit [Ping timeout: 480 seconds]
c00k has joined #aarch64-laptops
<c00k> Hi all, I've been reading the old irc logs but I can't find if the miix-630 should be able to do gpu accelerated graphics. Any clues?
akawolf[m] has joined #aarch64-laptops
<akawolf[m]> Lenovo postpone my order with x13s from 1th of January to the end of January, unfortunately, and there is a problem since the girl who should deliver it to me have a return ticket at 8th. so many problems with getting that laptop... hope I will finally get it :)
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> c00k: last i remember was that it was not supported, but some pmos sdm835 devices seem to have gotten it working, so maybe it is meanwhile working or at least possible to get there
<hexdump0815> c00k: you might try to boot your device with my image from https://github.com/hexdump0815/imagebuilder/tree/main/systems/snapdragon_835 after adjusting the dtb file name in /boot/boot/grub/grub.cfg (strange path is from the only working grub i took over from the debian image i think)
<hexdump0815> c00k: then you can try to help getting it forward from there :) ... this image at least boots fine on my sdm835 asus novago
<c00k> I have my device booting fedora 37 with a 5.17.1 kernel that i managed t build a while back, however I don't know how to get the gpu to work porperly. Fedora comes with an up to date mesa that should have som freedreno support for the 540
<rfs613> steev: trying the initramfs modules now... seeing a bunch of warnings about possible firmware missing, eg:
<rfs613> W: Possible missing firmware /lib/firmware/qcom/a630_zap.mbn for module msm
<rfs613> W: Possible missing firmware /lib/firmware/qcom/a630_zap.mbn for module msm
<rfs613> W: Possible missing firmware /lib/firmware/qcom/a630_zap.mbn for module msm
<steev> that's common
<steev> we don't use that
<rfs613> oops sorry for the multiple paste
<rfs613> a dozen more other files too
<rfs613> interrupted by kids wanting a snack... bbiab...
<steev> thats common, it's only important if we actually use that firmware, and we don't
<hexdump0815> c00k: i think the place where the most is happening for the sdm835/msm8998 is postmarketos - some info is here: https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)
<hexdump0815> c00k: the mainline git repo is https://gitlab.com/msm8998-mainline/linux
<hexdump0815> c00k: this is mostly for phones, so one should look into the phone dts and see what to maybe move over to the woa laptop dts - not sure how far this might help
<hexdump0815> c00k: please let me know in case you make any progress
<c00k> thanx hexdump, will do!
<rfs613> steev: it worked, runnnig 6.1.0-next now.
c00k has quit [Remote host closed the connection]
<steev> rfs613: glad to hear :)
jhovold has quit [Ping timeout: 480 seconds]
<hexdump0815> leezu: i spent quite a bit of time today diffing kernel configs, researching and trying out different kernel configs to find out the options really required beyond defconfig to run well on a trogdor chromebook
<hexdump0815> leezu: the result looks very promising - it is running well with v6.1.1 without any problems i could spot with a quick check - maybe you might give the config a try as well in case you still have problems with your lazors
<hexdump0815> leezu: these are the options on top of defconfig i found: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.cbq/options/additional-options-special.cfg - might not be perfect yet (i.e. maybe not all are strictly needed), but seems to work well so far
<hexdump0815> aceridus: those above options for sc7180 might also be a good base for out ongoing galaxy book go experiments - i plan to switch to v6.1 on it soon as a more stable base and will try to work on from there
<hexdump0815> out=our
SSJ_GZ has quit [Ping timeout: 480 seconds]
<dgilmore> I am failing to get any output after grub