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)
<steev> you could always restore (again) and start over :P
<steev> are you trying to point at the dtb on your encrypted root that isn't decrypted yet?
<derzahl> yeh, thats what im tryingto avoid:)
<derzahl> no, dtb is just on the normal efi partition
<derzahl> and im just using debian, not even the distro that shall not be names
<derzahl> *named
<derzahl> but like i was saying, i dont *think* its a dtb problem. even when i boot dtbloader, which uses the old dtb that 5.12 cant boot with. i can still boot 5.12 if i specify the proper dtb with devicetree
<steev> why not copy in the correct dtb?
<derzahl> for dtbloader?
<derzahl> i could try that
<derzahl> not sure how it works
<derzahl> theres a /boot/dtb dir
<derzahl> that contains 3 dtbs with uuids for file names
<derzahl> i think
<robclark> derzahl: https://github.com/aarch64-laptops/edk2/blob/dtbloader-app/EmbeddedPkg/Application/ConfigTableLoader/install-dtbs.py#L44 .. you could hack up that script to print out the chid's instead.. fwupd should also have a tool (iirc steev mentioned what it was somewhere in the scrollback) that would print out the chid's
<steev> 2 of the dtbs are for the c630s and 1 is for the flex 5g
<shawnguo> derzahl: the dtbloader in the latest Debian cdimage does more than loading dtb - it also marks those broken efi runtime services disabled.
<shawnguo> so if you are not using dtbloader, you need to add `efi=novamap` back to kernel cmdline. otherwise, kernel doesn't boot.
<robclark> *ahh*.. yeah, ok, I'd forgotten about that
FizzBuzz has joined #aarch64-laptops
<derzahl> shawnguo: ah, good to know. thanks. but what is the "windows boot manager" entry set to by default?
<derzahl> yup, that was it! efi=novamap
<steev> do you mean what should it be pointed at? that should be EFI\Microsoft\Boot\bootmgrfw.efi ? (or bootmgr.efi but i think they do fw)
<shawnguo> derzahl: iirc, that's \EFI\Microsoft\Boot\bootmgfw.efi
<derzahl> oh, i seem to recall the system booting into linux after the install
<derzahl> maybe i remembered wrong
<shawnguo> if you ever installed Linux before, that could be the case, since bootorder editing is needed for the first time when you install Linux
<derzahl> yeh, im talking about since the first time i installed it
<derzahl> but i was just grasping at straws. pretty sure now i remembered it wrong
iivanov has joined #aarch64-laptops
<derzahl> whelp. finally got the c630 booting from encrypted zfs root!
<derzahl> and i was just about ready to give up
<derzahl> and hot damn, its got sound too!
<derzahl> weird. its also showing two wireless adapters
FizzBuzz has quit []
derzahl has quit [Ping timeout: 480 seconds]
pg12 has joined #aarch64-laptops
pg12_ has quit [Ping timeout: 480 seconds]
FizzBuzz has joined #aarch64-laptops
<steev> shawnguo: how do you feel about making CONFIG_HZ_1000 the default instead of CONFIG_HZ_250?
<robclark> fwiw, CONFIG_HZ_1000 is what fedora and CrOS use.. afaiu you really only want to use lower for server use cases where interactivity doesn't matter as much
<steev> robclark: yeah, i was kinda surprised that arm64 doesn't set it by default... but then again... arm64 servers are quite common these days
<steev> but i figure since shawn has the distro_defconfig (and i've added it there in my fork), it's a decent place to put it
FizzBuzz has quit []
<bamse> look at that...if i just turn on the right bus the adreno driver doesn't crash on sc8180x
<bamse> robclark: MESA: error: unsupported GPU: a680 :(
<HdkR> =o
<robclark> bamse: I can give you a quick patch that "should just work"..
<robclark> if you don't mind rebuilding mesa
<bamse> i'd be happy to try it out
<bamse> what a massive patch ;)
<robclark> well, fortunately I refactored things recently when adding a660/a635.. which makes it a nice small patch to add new devices of an already known sub-generation
<bamse> anything particular i need to do to build mesa btw?
<bamse> flags etc
<robclark> defaults should be ok if you are compiling natively but if you give me a sec I'll pastebin what I use (which is a bit more trimmed down than defaults)
<bamse> presumably i can save some time by not building !freedreno?
<robclark> right
<robclark> and then `ninja -C release && sudo ninja -C release install` should work
<robclark> (I normally don't install to /usr but I guess that is probably what you want to do at this point)
<robclark> oh, you might want to uncomment glvnd if arch uses it
derzahl has joined #aarch64-laptops
<bamse> robclark: patching up the mesa-git arch package, so that i don't trash my installation...and it seems to be building now
<robclark> cool
<HdkR> I've still been fighting with my install. Haven't had GPU acceleration for a while now
<HdkR> Trying to figure out why DRI2 can't authenticate is always a nightmare
<robclark> is that even still needed with dri3? I thought dri3 was using dma-buf fd's instead of flink names?
<HdkR> This is a level of the stack I'm don't know enough about to know
derzahl has quit [Ping timeout: 480 seconds]
<HdkR> Updating the OS, maybe I got a bad set of packages
FizzBuzz has joined #aarch64-laptops
<HdkR> yay. Updated the OS and it fixed the issue
<steev> that makes one of us :(
<steev> jk, i don't have 3d issues
<bamse> robclark: glxinfo says "freedreno and FD680...
<robclark> ship it!
<robclark> does it actually work?
<bamse> now that i finally rebuilt the package again with proper prefix :)
<bamse> glxgears are spinning!
<robclark> \o/
<bamse> webgl aquarium gives me 30-35 fps
<robclark> that is kinda low, but there could be other reasons for that..
<bamse> but compiling mesa only got me to ~40C on the cpus...so i'm missing something on my side...
<bamse> like bus bandwidth
<robclark> heh, yeah, that could certainly do it
<bamse> running aquarium for a few minutes now...cpus are 33-38C
<bamse> anyway, i will polish up the driver patch that i came up with and send that out
<bamse> what's needed to get the mesa change landed?
<robclark> I guess if aquarium works, then it is at least not completely broken..
<robclark> I guess wouldn't hurt to do a bit more sanity checking.. but I think a680 should be closely related to a640 which is pretty well tested
<bamse> yeah, but i guess landing it will increase the number of people testing it dramatically?
<bamse> either way, i'll continue to throw my kernel pieces out there...so that you and others can reproduce this
<robclark> well, I guess there aren't a lot of people yet who have setup to test it without kernel patches ;-)
<bamse> yeah, and i presume anyone that has my kernel patches would prefer to have mesa+your patch, even though the stability etc is somewhat unknown
<bamse> but how does mesa releases work? when is the next one?
<robclark> It doesn't have to be *perfect*.. a660/a635 are passing all of deqp-gles2/gles3, but only 95% or so of deqp-gles31.. but if things like desktop + chrome or firefox, etc are working, that is good enough
<robclark> we are already past the branchpoint for 21.2.. so I guess this won't be in distros until 21.3 in a few months
<bamse> okay, but i'll continue testing this as we land the other kernel patches and the displayport patches and we can do some more testing in the coming weeks
<bamse> and then merge it, well in time for 21.3
<robclark> *maybe* I can talk folks into a backport since it is a small patch, but the release managers probably won't go for it.. at least the series that the patch depends on got in before the 21.2 brnchpoint
<robclark> hopefully we can get kernel side in for this upcoming merge window
<bamse> i'm hoping we can reach a point where shawn can update the debian image with something useful before "a few months"
<bamse> but i presume we have some means for dealing with such things
<robclark> if debian package builds from git (or at least regenerates the .py generated tables) it should be easy enough to add that patch to deb pkg once 21.2 is released
<robclark> (I think it is on ~rc2 atm)
<robclark> (tbh, I don't follow the release branches too closely, we've been using ToT in CrOS)
<bamse> anyway, i have more dpu and dp patches that i need to convince you to pick, before this is a real problem
<robclark> I think we are pretty interested in getting the eDP bits landed ;-)
<bamse> i know
<bamse> cleaning out my tree right now, that's why i noticed that i forgot to turn the busses on
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit []
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
_ has joined #aarch64-laptops
FizzBuzz has quit [Ping timeout: 480 seconds]