08:17 <DavidHeidelberg[m]> jstultz: hehe, if you want to, it still alive in https://github.com/apq8064-mainline/linux (based on `-next`)

14:22 <jhugo> I'll try to give it a run in the next week. Still on 5.7 actually. Its been way too long since I touched the laptop :(

15:04 <lumag> DavidHeidelberg[m]: wow. Does riva work for you?

15:05 <DavidHeidelberg[m]> lumag: wlan? yes

15:06 <DavidHeidelberg[m]> but when it gets started, it kills usb (but also unplugging USB kills usb and light breeze kills usb...)

15:08 <lumag> DavidHeidelberg[m]: strange, didn't work for me. But maybe I missed something in defconfig. And ifc6410 uses external wi-fi chip.

15:09 <DavidHeidelberg[m]> lumag: long time ago, I had lot issues with just a small defconfig changes. Since then I rather not touch apq8064_qcom_defconfig (we keep our own in repo)

15:10 <DavidHeidelberg[m]> .. btw. that could be cause different chip..

15:10 <lumag> I switched to the inforce board as my mdp4 testbed, it fits better into the lab setup.

15:10 <lumag> Which fw do you use? The latest one?

15:14 <lumag> Also... It would be nice to see schema files land in the upstream.

15:18 <lumag> Btw: I think there is no ext_p3v3 on flo/deb

15:18 <lumag> It is disabled in asus kernels

15:27 <DavidHeidelberg[m]> lumag: feel free to join https://matrix.to/#/#linux-apq8064:matrix.org if you're Matrix user. Currently I haven't worked on my deb for few months, but I'll get back to it soon again

15:41 <lumag> Another messenger...

15:45 <DavidHeidelberg[m]> :D u don't have to. I guess also people from there are here

15:47 <DavidHeidelberg[m]> but I think for newbies it's better place to ask various questions and not to spam "production" chats as this one. About firmware, we use the FW bundled in pmOS firmware package

15:48 <DavidHeidelberg[m]> not `-next` but `5.10` from this repo is packaged for pmOS, so you can just install it without compiling. After 5.10 there is few issues [ https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_600_(APQ8064) ] which make the tablet less usable

16:01 <lumag> Well... My main point of interest is testing mdp4. Getting something else would also be good, but it's definitely not a top priority.

18:38 <jstultz> DavidHeidelberg[m]: sadly passed my n7 devices on.

18:41 <DavidHeidelberg[m]> lumag_: if I was able to connect mine into CI, it would solve the issue (I bought mine with damaged screen, so it was never meant to be used in prod)

18:42 <DavidHeidelberg[m]> but the challenge would be ethernet + remote pwroff

18:56 <Mis012[m]> David Heidelberg: does your router not have a USB port? ;)

18:56 <Mis012[m]> what a better use for it

18:56 <Mis012[m]> *what better user for it

18:56 <Mis012[m]> *use

18:57 <Mis012[m]> David Heidelberg: and I bet you can find some spare GPIO to hook up to the power button as well :P

18:58 <DavidHeidelberg[m]> if there is a interest, I can connect it

18:59 <Mis012[m]> I have some interest in seeing that frankenstain, but that's not what you meant is it? :P

18:59 <DavidHeidelberg[m]> yeah

19:00 <DavidHeidelberg[m]> if I connect it to kernelCI, you have to keep availability, it has to be reliable etc etc.

19:01 <DavidHeidelberg[m]> * I have to

19:01 <Mis012[m]> I guess I also have interest in a CI which complains when someone tries to break old platforms, but not sure if it can run that often :P

19:02 <Mis012[m]> best to catch them before it's merged so they have to fix it themselves as the good lord intended

19:06 <lumag_> DavidHeidelberg[m], i'm using Laurent-128 relay in my lab setup

19:06 <lumag_> works pretty nice

19:07 <lumag_> And RPi powered hubs provide best PPS experience

19:08 <lumag_> UUGear MEGA4

19:08 <Mis012[m]> is RPi the maker product with signed bootloader?

19:08 <Mis012[m]> *isn't

19:09 <Mis012[m]> 🤡

19:09 <lumag_> It's not on-RPi hub,

19:09 <lumag_> I should have said for-RPi.

19:09 <Mis012[m]> I see

19:10 <lumag_> I got a pair of UUGear MEGA4 hubs and they rock.

19:11 <Mis012[m]> lumag_: btw would you happen to know if MSA fuses override unblown XBL_SEC_AUTH?

19:11 <lumag_> no idea unfortunately :-(

19:12 <Mis012[m]> it definitely seems that my device with unblown XBL_SEC_AUTH refuses unsigned/test_signed XBL_SEC, unless the random unsigned XBL_SEC I found somewhere is broken

19:26 <flto> Mis012[m]: at least on sm8250 the fuse is a disable (it needs to be blown to disable the signature check. but it doesn't seem to be possible to blow it from software, qcom blows the relevant write permission fuse)

19:27 <Mis012[m]> hm, guess I should check the write permission fuse then

19:28 <Mis012[m]> when did qcom decide to become assholes?

19:29 <flto> you haven't seen sm8450 yet ;-)

19:30 <aka_[m]> And he won't see lol

19:31 <Mis012[m]> is it too much to ask that they keep their bloody fingers off those fuses

19:31 <aka_[m]> Their chips their rules

19:31 <DavidHeidelberg[m]> Mis012: you just to get defuse kit :D

19:33 <Mis012[m]> if those fuses were a few orders of magnitude larger, me de facto owning the chip under the standard meaning would be enough...

19:33 <Mis012[m]> just solder a wire across the blown hole

19:34 <Mis012[m]> but with the size of the fuses, de facto ownership has to mean that qcom and oem keep their grubby fingers off the fuses