04:48 <Dylanger> Cheers 🍻

04:53 <Dylanger> Does anyone know why rmtfs is required for nonlte versions of trogdor (QC 7c Gen 1) is required to get the WiFi remoteproc running?

04:53 <Dylanger> There's no modem so there shouldn't be any rmtfs/NV at all

04:53 <Dylanger> I assume it's kicking the WiFi remoteproc somewhere, I'd prefer to just do that without rmtfs

04:54 <Dylanger> Also does anyone know if `qcom/a630_sqe.fw` is super low level firmware required to run freedreno or if it's a full alternative/closed to freedreno

14:59 <steev> Dylanger: it isn't required unless you want 3d accel afaik

15:01 <bamse> Dylanger: the wifi firmware runs in something similar to a guest virtual machine on the modem hexagon and even in the non-lte case the host os needs to be booted and for some reason that still requires access to storage

15:03 <bamse> Dylanger: certainly annoying though...

15:03 <bamse> Dylanger: and a630_sqe.fw is firmware that goes into the gpu, regardless of which driver/userspace you're using

16:12 <robclark> Dylanger: wifi is still a modem.. and a630_sqe.fw (and gmu fw) are required for the gpu to work

16:13 <robclark> ahh, bamse already answered

16:42 <hexdump0815> is there a lit of minimal required firmware to run a sc7180 with gpu, wifi, bt? - i tried to reduce it to ony the essential files, but then strange things started to happen - using all the fw around on cros it works, so it looks a bit to me as if there is more needed than only a630_sqe.fw

16:42 <hexdump0815> lit=list

16:56 <robclark> on gpu side of things, for chromebooks, you need a630_sqe.fw and a630_gmu.bin .. both of which you can take from linux-firmware (which should be identical to what is in CrOS builds).. on non-chromebooks you also need a630_zap.mbn

16:57 <robclark> it's possible that things aren't super well tested if you have, for ex, sqe but not gmu fw

16:57 <robclark> for wifi/bt.. you need a bit more.. which I think is signed (meaning you need to take it from CrOS filesys)

16:59 <macc24> robclark "CrOS filesys" why not https://googlesource.com/chromiumos/linux-firmware ?

17:00 <macc24> * https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/ close enough :v

17:01 <robclark> well, yes, the fw in the CrOS filesys does in fact come from a git tree ;-)

18:33 <hexdump0815> robclark: btw. is suspend/resume supposed to work on lazor? i'm currently still running it with its rootfs on usb and after resume it always switched to a readonly filesystem - looked like something is not fully ok

18:34 <hexdump0815> kernel is v5.15.14 with a config based on the lazor cros config

18:34 <hexdump0815> v5.15.4 i mean :)

18:38 <robclark> hexdump0815: I'd *expect* it to work.. but there could be some usb related issue, rootfs on usb is perhaps only tested enough to use for recovery/install

19:05 <hexdump0815> robclark: ok - i'll test a bit more during the next days and report back

19:06 <hexdump0815> macc24: Dylanger: is suspend/resume working well for you? on emmc or usb?

19:07 <robclark> hexdump0815: dianders_ may know something about suspend/resume... I assume we have tests covering s/r running in lab on kernelnext (but likely without usb involved)

22:40 <Dylanger> <hexdump0815> "macc24: Dylanger: is suspend/..." <- I haven't tested yet

22:41 <Dylanger> <robclark> "on gpu side of things, for..." <- I'm definitely missing gmu (`a630_gmu.bin`), any idea what this is/how it differs from `a630_sqe.fw`?

22:42 <Dylanger> <robclark> "Dylanger: wifi is still a modem...." <- Yeah iirc the WNCSS runs on the same Hexagon cores the modem does, I want to look into this more, shouldn't need rmt

22:42 <Dylanger> iirc the MAC address maybe stored in NV along with other radio/wifi related calib data

22:44 <Dylanger> But there's no place/partition where this data is stored

22:45 <Dylanger> So I think rmtfs is kicking the WNCSS subsystem to continue booting

22:45 <Dylanger> If we can just 'do that', as apposed to having the full rmtfs stack

22:45 <Dylanger> That'd be nicer

22:45 <robclark> Dylanger: GMU is the thing that manages GPU power/freq/bandwidth.. it is some sort of cortex-m AFAIU.. the SQE is the custom microcontroller thing that deals with cmdstream parsing.. it is a totally custom thing, but also doesn't really look like a "normal" CPU.. it is kind of more like a FIFO processor

22:46 <Dylanger> This would make sense, I was pretty underwhelmed running GNOME at 1080p

22:46 <Dylanger> Infact dmesg complains it's missing power related GPU features

22:47 <robclark> yeah, without GMU we can't even really power on the GPU

22:48 <robclark> neither gmu or sqe fw is signed, fwiw.. so you can just use what is in linux-firmware for both of those

22:49 <Dylanger> I think it's signed, but not enforced/verified

22:49 <Dylanger> The AP Secure Boot isn't blown on these devices

22:49 <Dylanger> (I think)

22:49 <Dylanger> Only modem on LTE SKUs are signed with a Google QC key

22:50 <Dylanger> WiFi only, you can make changes to WNCSS, resign and everything is okay

22:51 <Dylanger> robclark: Oh you said neither

22:51 <robclark> neither gmu or sqe is signed.. (zap is.. but not used on chromebooks)... venus is, I think, signed but not enforced.. modem (defn lte+wifi, but I thought wifi-only as well) is signed

22:51 <Dylanger> Lol my bad

22:51 <Dylanger> Yes

22:51 <robclark> (zap is only used when qcom's tz thing is used.. which is not on chromebooks)

22:52 <Dylanger> The cert I pulled from the wifi-only firmware looked non-enforced

22:52 <Dylanger> robclark: The way... it should be.

22:52 <Dylanger> 💢

22:52 <Dylanger> Qualcomm needs to keep it's attack surface out of SoCs

22:55 <robclark> hmm.. well tbh I'm not entirely sure where the lte sig validation is happening.. I thought that was same for both lte+wifi.. but you should probably only believe what I say about gpu things :-P

22:56 <robclark> bamse would know more about modem/hexagon things

22:58 <bamse> Dylanger: you can modify modem.mbn (or mdt+bNN) and it will happily load it without a new signature?

23:01 <Dylanger> You'd need to re-sign it

23:01 <bamse> right

23:01 <Dylanger> But the sig isn't checked

23:01 <bamse> with a key or the key?

23:01 <bamse> hmm interesting

23:01 <Dylanger> Just that there's a valid sig

23:02 <Dylanger> (Non blown secboot behavior)

23:02 <bamse> right, i just didn't expect it for the modem.* itself

23:02 <Dylanger> You can't do this with LTE version's modem

23:03 <Dylanger> On the Duet 5 at least

23:03 <Dylanger> That's all I've checked

23:03 <bamse> that said, on sdm845 i've seen signed modem.* happily load a test-key signed wlanmdp.mbn

23:03 <Dylanger> But you can for WiFi firmware and other things like Venus

23:03 <bamse> but i don't think the chromebooks load the wlan firmware separately

23:25 <Dylanger> That's the modem CA

23:26 <Dylanger> `Subject: C = US, ST = California, L = Mountain View, OU = Chrome OS, O = Google, CN = Chrome OS Modem Root CA`

23:26 <Dylanger> I think it's controlled by Google, they're likely blowing secboot for the modem on LTE SKUs

23:47 <bamse> yeah, sounds like they skip that step on their wifi only device then

23:49 <Dylanger> I wonder how hard they disabled the actual modem on nonlte versions of the SoC

23:49 <Dylanger> Likely the RF Frontend/RF Path would be missing ICs

23:51 <Dylanger> The entire boot flow is totally different on Chromebooks too, does anyone know what actually starts executing first? Usually it's the PBL (Physically printed onto die), but the bootlog shows coreboot loading before PBL

23:51 <Dylanger> Perhaps this is simply cached logging

23:51 <Dylanger> Firmware is loaded from a physical(?) SPI IC

23:52 <Dylanger> Compiling my own depthcharge is the next step, but from what I can gather, bootflow looks like

23:52 <Dylanger> PBL -- Coreboot -- Depthcharge -- Linux Kernel