00:20 <Dylanger> Hey, hm, if it's not working you might need the kernel patches for the GDSC stuff

00:20 <Dylanger> Did you enable dev mode?

00:34 <amstan> ajhalaney: what do you mean by not recognize? did you get a loud beep or? what?

00:35 <amstan> was this while pressing ctrl+U or "boot from usb"? it should have been

00:36 <amstan> `cgpt show` should print all the usb partitions so you can check that everything's ok

00:53 <robclark> another matrix user not identified w/ NickServ?

00:59 <amstan> robclark: possibly? did you not see him talk? at 9am today?

01:00 <amstan> did we get back the +v stuff for identified?

01:00 <robclark> nope.. only you and Dylanger replying so I guess Dylanger is a matrix user too

01:00 <robclark> I was going to drop it a while back but then started seeing bot spam in other channels

01:00 <amstan> can we just prevent join if not identified instead, it's much easier to tell if this is happening

01:01 <amstan> the voice thing is really easy to miss

01:01 <amstan> more like shadowbanning

01:01 <Dylanger> Agree

01:02 <amstan> ajhalaney: go talk to @_oftc_NickServ:matrix.org

01:02 <robclark> I suppose we could.. would be nice if matrix at least showed some hint to other matrix users that other person wasn't visible to non-matrix folks

01:03 <amstan> robclark: i agree, there is a concept of voice in matrix too, so it could easily be mapped as well

01:03 <amstan> but given that there isn't such a map in the bridge, i suggest we workaround by just changing channel settings

01:03 <amstan> most other channels have the registered to join requirement

01:14 <Dylanger> <strongtz[m]> "yup" <- What does `pactl list` return?

01:14 <Dylanger> I have a feeling you're hitting the same thing I am

01:14 <amstan> speaking test

01:15 <robclark> that worked

01:15 <amstan> wow, even over irssi the +M warning is super easy to miss

01:16 <amstan> alright everyone, sorry if you get kicked, until now you probably couldn't speak anyway, talk to NickServ to identify before rejoining

01:17 <amstan> weird, nobody got kicked, maybe next time they reconnect?

01:17 <amstan> which isn't really a thing over matrix, sigh

01:18 <Dylanger> Lol, yeah I didn't see much change there

01:18 <Guest415> Dylanger: you're identified though

01:18 <Dylanger> Ah right

01:19 <Guest415> and it seems like it's working well: `17:18 -!- #aarch64-laptops Cannot join channel (Need to be identified and verified to join this channel, '/msg NickServ help' to learn how to register and verify.)`

01:19 <Guest415> robclark: fixed!

01:19 <robclark> \o/

01:21 <Dylanger> I think I've asked this before, but does anyone know why rmtfs is required on QC 7c platforms when no modem exists? From what I understand rmt is a daemon that allows the modem/qc sub-system to read/write NV, however if there's no modem it shouldn't need to exist, wouldn't NV for WNCSS sub-systems just be somewhere on rootfs?

01:22 <Dylanger> It seems rmts is simply 'kicking' WNCSS on

01:22 <Dylanger> I need to run strace and see what it's actually doing

01:23 <Guest415> Dylanger: good question, lol

01:23 <Guest415> from what i understand the 2 functionalities are super intertwined

01:24 <Guest415> (wifi and modem)

01:24 <Guest415> it wouldn't surprise me if the majority of the modem code needs to be running

01:24 <Dylanger> Hm, would be nice to echo 1 into a /proc file and just have WiFi come up/don't need rmtfs

01:24 <Guest415> bamse i think knows a lot about this

01:26 <Dylanger> The Duet 5 is non-modem, same SoC tho, then there's an Acer with the same SoC that has modem in it

01:26 <Dylanger> I wonder if the modem is just fuse'd OFF

01:26 <Dylanger> Would prob also be missing RF Front ends as well th

01:26 <Dylanger> s/th/tho/

01:28 <amstan> yes to both

01:29 <Dylanger> I wonder where the WiFi MAC address is stored on the non-modem variants

01:32 <Dylanger> Perhaps the WiFi subsystem stays in an invalid state until it detects rmtfs is running on the AP

01:32 <Dylanger> Could just be a left over from the modem

01:34 <amstan> the mac address is in the vpd

01:34 <amstan> something in userspace is supposed to copy it over, forgot what

01:36 <amstan> run `vpd -l`, see "{wifi|bluetooth}_mac0=" entries

01:37 <amstan> mine has a hilarious wifi_mac0_is_fake entry too with a bug number created by dianders , but i don't think you have to worry about that

01:40 <Dylanger> Ah that's right

01:40 <Dylanger> vpd has all of that info

01:40 <Dylanger> iirc it has Google based identifiers too right?

01:40 <amstan> idk, probably

01:41 <amstan> stable device secret

01:41 <amstan> i think that's used for stuff like device attestation if you enroll it in a domain

01:41 <Dylanger> Huh, I thought that woulda been in the H1

01:42 <amstan> h1 might have some stuff too, but it's more volatile there i think, you can always clear it

01:42 <amstan> vpd is a very informal place that chromeos uses to store data, once you boot gnu/linux it's nothing more than just a text file

01:42 <amstan> so in the case of this mac address, you need something that parses the vpd and puts it in the right place for the kernel to use

01:43 <Dylanger> Yeah I'm running Debian currently, I think I may have wiped away vpd if it's stored in eMMC

01:43 <Dylanger> amstan: I'd assume Debian is using some default MAC

01:44 <amstan> it's not stored on emmc, it's part of the RO portion of firmware

01:44 <amstan> (though some vpd entries can be in RW)

01:44 <amstan> idk, install the vpd tool and check

01:44 <Dylanger> RO is just eMMC isn't it? With Write-Protect?

01:44 <amstan> no, firmware is stored on spi flash

01:45 <Dylanger> Ah my bad that's right

01:45 <Dylanger> Sorry it's been a while since I played with this

01:45 <Dylanger> You're right, I remember dumping the SPI Flash via the H1

01:45 <amstan> if you want to put your own firmware, really the only thing you need to worry about is saving your contents vpd (if you care)

01:47 <Dylanger> Yeah that's the first thing I backed up, interesting that's where Google popped keys, I know Google is pushing Secure Elements in Android, I wonder if we'll see the H1 be replaced by the Titan M2

01:47 <Dylanger> ^ And strongbox attestation keys pre-provisioned

01:48 <amstan> hmmm: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/src/board/trogdor/board.c?q=wifi_mac%20vpd

01:49 <amstan> looks like depthcharge copies that stuff in the DT?

01:49 <Dylanger> heh

01:49 <amstan> so maybe do more searches based on that

01:50 <amstan> yeah, looks like lots of ath drivers do of_get_property(.."local-mac-address"..)

01:51 <Dylanger> Yeah that's right

01:51 <amstan> there you have it!

01:51 <amstan> if you want to change it, it's just a vpd call away

01:51 <amstan> then a reboot

01:51 <Dylanger> If you hexdump -C `/sys/firmware/devicetree/base/soc@0/wifi@18800000/local-mac-address`

01:51 <Dylanger> You get the MAC

01:52 <Dylanger> And according to `ip addr`, it matches

01:52 <Dylanger> Cool, so that's how that works 👍️

01:53 <amstan> Dylanger: there were so many meetings about this where everyone was confused

01:53 <amstan> i'm glad it's solved in a rather neat fashion

01:54 <Dylanger> I'm gonna try replace the vboot key in depthcharge with one I control

01:54 <Dylanger> Haha yeah 💯, so rmtfs is a weird one

01:54 <Dylanger> I feel like it's just there as a remnant of modem

01:56 <amstan> i wish i could help more (for the purpose of getting more distros working), those meetings about modem bringup were so specialized that I did not partake

01:56 <amstan> i remember at one point it was quite a shock that a tftp server daemon was needed to get any wifi working

01:56 <amstan> and for a while apparently it had to be a special tftp server from qcom, it couldn't just be any tftp server

01:57 <amstan> so.... in summary: black magic

01:57 <amstan> once it works stop touching it, here be dragons

02:00 <Dylanger> amstan: Oh gawd

02:01 <Dylanger> Really unhappy with Qualcomm, they're stifling innovation in the virt scene

02:48 <robclark> idk, we're doing some interesting this w/ virt on qcom.. https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/693 .. and really the qc chromebooks are the first snapdragon things that you *could* do virt on

02:50 <HdkR> Chromebooks beat ProX to virt? =O

02:51 <robclark> we launched with virt.. old news ;-)

02:51 <robclark> ie. crostini

02:52 <robclark> but with push to move android into vm, we are stepping it up a bit

02:52 <HdkR> Also, gpu passthrough with virgl. That sounds awesome

02:52 <robclark> :-)

02:52 <Dylanger> robclark: The 7c/compute platform is the only platform Qualcomm haven't fucked

02:52 <HdkR> What's the performance overhead on that like?

02:53 <robclark> yeah, I know the situation w/ hyp.img .. and unfortunate that they use the same scheme on win.. but for CrOS that was always a non-starter

02:53 <robclark> HdkR: mostly within a few percent of native.. there are a few things that are merely ~92% of native but there is room to improve

02:54 <Dylanger> <robclark> "idk, we're doing some interestin..." <- Oooo, I've managed to boot Fedora Silverblue with libvirt on this Duet 5, I noticed graphics perf was laggy, I'm guessing this fixes that?

02:54 <Dylanger> Google has gfxstream too

02:54 <HdkR> What I can glean from the MR message, buffer uploads have some overhead?

02:55 <robclark> there are some things that will require new host drm/msm uabi but I think we should come pretty close to native.. closer than virgl or gfxstream

02:55 <Dylanger> ❤️

02:55 <Dylanger> Exciting

02:56 <robclark> HdkR: the upload interface is mostly to reduce # of guest mappings.. but there is already upstream kvm patch to lift the restriction.. but still avoiding guest mappings for things that mesa only writes once and then uses many times is useful

02:56 <HdkR> Nice

02:56 <HdkR> This allows both Freedreno and turnip in the Linux VM guest then? :)

02:57 <robclark> in theory.. so far only implemented for gallium driver.. venus for vk so far doesn't appear to be that bad.. but could change once tu optimizes a couple things

02:58 <HdkR> I'm looking forward to testing this

02:59 <robclark> down side is it looks like qemu might take some work.. because it doesn't support some virtgpu things we need.. crosvm obv in better shape

02:59 <Dylanger> <robclark> "yeah, I know the situation w..." <- Given the news (Win 11 on Pixel 6/6 Pro) do you think Qualcomm will admit defeat and allow free EL2?

02:59 <robclark> I'm not entirely sure how that will play out.. qcom recently open src'd their hypervisor

03:00 <robclark> but that doesn't really fit w/ android's crosvm direction.. so idk what is going on there

03:00 <Dylanger> It's like Qualcomm is gaslighting everyone

03:00 <HdkR> I'd buy a flagship Chromebook just to play with crosvm msm integration

03:03 <Dylanger> robclark: Indeed it maybe open, but you'll never be able to compile it yourself and pop it on a qcom device that you own

03:04 <robclark> yeah, I suppose it is at least a bit interesting to look at and see how it works, but I'm not entirely sure the point

03:04 <robclark> fortunately I don't really have to care ;-)

03:05 <HdkR> I just got a Snapdragon 8 g1 device and I'm already frustrated with the android-isms

03:06 <robclark> same can be said about a lot of devices unfortunately ;-)

03:06 <HdkR> Running any sort of intensive graphical application under Termux? nah, not gonna happen.

03:12 <HdkR> Intensive like...Steam.

03:14 <HdkR> ...and zenity

09:54 <Dylanger> Does anyone know where the prod Google VB Cert is stored? I know it's in depthcharge somewhere

13:41 <ajhalaney[m]> Alright, re-verified my nick with matrix thanks for the tips was having trouble figuring out how to get a hold of NickServ via matrix. Back to my duet 5 question, I guess what I'm asking is how are people booting mainline? Cadmium? If so... I've tried generating an image and booting from developer mode (with dev_boot_usb == 1) but I keep getting "No valid image detected" when using that image via boot from external disk option in

13:41 <ajhalaney[m]> developer mode. The chromeos recovery image works, so I know that the USB hardware is at least working. But before I go down the Cadmium path more I just wanted to know if Dylanger was using Cadmium as well when successful on duet 5 or something else?

15:58 <javierm> ajhalaney[m]: have you seen https://github.com/eballetbo/chromebooks ?

16:01 <ajhalaney[m]> I have not, thank you!

16:02 <javierm> ajhalaney[m]: you are welcome. That's what I used to flash a USB disk and boot mainline kernel + distro on my hp x2 chromebook

16:03 <javierm> ajhalaney[m]: just sudo ./chromebook-setup.sh do_everything --architecture=arm64 --storage=/dev/sdb

16:03 <javierm> and then you can re-deploy the kernel with sudo ./chromebook-setup.sh deploy_kernel --architecture=arm64 --storage=/dev/sdb

16:03 <javierm> or just the modules with sudo ./chromebook-setup.sh deploy_modules --architecture=arm64 --storage=/dev/sdb

20:07 <Dylanger> Yeah I'm using Cadmium on my Duet 5

20:08 <Dylanger> It should boot for you

20:08 <Dylanger> Did you dd the resulting image directly on top of a USB?

20:11 <macc24> ajhalaney[m]: try these steps(copied directly from cadmium discord) https://bpa.st/4M5A

20:17 <macc24> for duet 5 disregard 2nd step - it's not supported before recent commit

20:26 <ajhalaney[m]> I think I've followed those steps properly from 972c155917e2a5246d65c2fd2f54eb0b95970f4e in Cadmium (flashed directly to the USB stick via ./build-all.sh /dev/sdc, didn't do the image + dd approach). I'm building with the chromebooks repo listed above right now. I'll come back to the Cadmium approach after I try that (and will head to the support channel for it to follow up). Thanks all!

20:28 <macc24> eh... did it break /again/

20:28 <macc24> ajhalaney[m]: what do you have in cadmium config file

20:29 <ajhalaney[m]> uh whatever is the default macc24 - if that was part of the instructions I definitely messed that up.

20:29 <ajhalaney[m]> yup

20:30 <macc24> ajhalaney[m]: switch ROOTFS to debian and it'll be fine, TARGET now is practically obsolete and will be dropped when i get around to it

20:31 <ajhalaney[m]> macc24: I'll do that and regenerate the image and let you know how it goes