00:22 <leezu> steev, I've just opened the merge request: https://github.com/aarch64-laptops/build/pull/83/

00:23 <steev> keyboard on the c630 is hid over i2c so could look at how it's done and get the addresses correct

00:24 <leezu> Are you referring to https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts ?

00:24 <steev> si

00:25 <steev> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts#L357

00:25 <steev> i2c3 is the touchpad(s) and i2c5 is the keyboard

00:26 <steev> and 11 is the touchscreen, iirc (not looking at it at the moment)

00:27 <leezu> Great. For this sc7180 laptop, do you think it's reasonable to include from sc7180.dtsi and take a look at what other sc7180-X.dts do? Do you know what IDP stands for in sc7180-idp.dts?

00:37 <steev> i think that's the dev board? idk

01:48 <robclark> idp is a sorta dev/reference device.. looks kinda like an oversized phone..

01:49 <robclark> and re-using sc7180.dtsi is the thing to do.. _that_ part of things should be more SoC specific than board specific

01:52 <robclark> also, fwiw, before you wipe the windows install, there is one extra gpu fw that windows (and android, but not CrOS) things need which is potentially signed with a vendor or device specific key that you'll need to copy.. on the sdm850 laptops (like yoga c630) it is qcdxkmsuc850.mbn so I guess the file you are looking for will follow a similar naming convention.. you'll need something similar to the

01:52 <robclark> gpu.zap-shader.firmware-name thing that sdm850-lenovo-yoga-c630.dts has to tell the driver what to load.. without that it will be insta-reboot when gpu driver loads

01:52 <robclark> (I think venus (video enc/dec) and maybe some other things have signed fw that you'll also have to copy.. I know less about those)

02:31 <steev> just grab everything in FileRepository that is *.elf, *.mdt, *.mbn, *.bXX

02:31 <steev> where XX are numbers

02:32 <steev> there is likely a .bin file as well, that is the actual UEFI bios

02:39 <robclark> does windows actually use split fw (ie. *.bXX stuff).. it seemed like they mostly realized those were just sections in an elf file

03:16 <leezu> Should such firmware files be added to linux-firmware?

03:36 <robclark> IANAL but I think qcom would have to send pull req for them (potentially indirectly via linaro)... but also I'm not entirely sure if that is really even scalable.. the fw's are really all the same other than signing key.. which could be per vendor or per device (although that isn't really clear to me.. we'd have to compare fw binaries from multiple (for ex) sc7180 windows laptops to be sure)

03:38 <robclark> there is, for ex, sdm845/850 zap fw in linux-firmware, which will work on dev boards.. but not sdm850 laptops, because what is in l-f is signed with a test key

08:11 <Dylanger> iirc a bunch of the 7c chromebooks are also signed with test keys, no QFPROM fuses are touched, except for mba, that's the only thing that's properly signed by Google

13:22 <robclark> Dylanger: we don't use qcom's tz so the thing that would use qfprom fuses is simply not there.. OTOH it is unneeded because the entire root partition, including the fw files, is signed (unless you are in dev mode, but in that case you won't get some things like protected content playback)

21:30 <bamse> robclark: do you remember why we uninstall the acpi tables in dtbloader at ExitBootServices, if we detect that the OS seems to care about the DT we passed? just to save a little bit of space or would there be some real reason?

21:30 <bamse> maz: ^^

21:31 <robclark> I think it was maz who advocated for that.. but IIRC it was more of just a correctness thing

21:31 <robclark> ie. dt boot should have acpi tables

21:33 <bamse> but we would have decided to go dt in linux already at that point?

21:52 <robclark> bamse: right, I don't think it actually hurts anything.. unless maybe you managed to boot windows after dt tables installed ??

21:52 <robclark> the argument at the time for removing acpi tables was simply that it was against spec

21:55 <bamse> robclark: the systemready ir spec?

21:56 <bamse> or perhaps ebbr would be the correct name for that part

21:57 <robclark> yeah, I think ebbr.. maz would be the one who knows for sure

21:57 <bamse> good, because i talked with Grant about that part, so then i have the backstory

21:58 <bamse> maz: if you have any additional input it's appreciated

22:08 <maz> bamse, robclark: I don't think I had anything to do with that. wasn't it Leif instead?

22:09 <bamse> maz: so you think there's an actual reason for doing it?

22:11 <robclark> oh, I guess then it was probably Leif

22:11 <bamse> maz: unrelated to this, but as you're here...what in an edk2 system causes a Filesystem to be attached to a Block IO device?

22:13 <maz> bamse: not that I can think of. the kernel should pick the DT unless the ACPI table is referenced in the DT, no?

22:14 <Dylanger> <robclark> "Dylanger: we don't use qcom's tz..." <- Do you know if the physical QFPROM IP block is there?

22:15 <Dylanger> I think it is right? Google squats over Modem's RoT

22:15 <bamse> maz: right, but then Leif has a ExitBootServices hook, that checks to see if the kernel modified the dtb and if so drops the acpi tables

22:15 <bamse> and yes it was part of Leif's original commit

22:16 <robclark> Dylanger: hw block should be there, but I don't think we use it.. I'm not entirely sure where the key to validate modem fw is.. maybe amstan or dianders knows?

22:17 <Dylanger> Iirc the cert I pulled from the modem was a legit Google one, cheers for clearing that up

22:18 <Dylanger> Really wish Qualcomm's 7c series was the default for all SoCs

23:10 <Dylanger> Does anyone know what/how VioS works?

23:10 <Dylanger> Looks like it's a ChromiumOS sound server?

23:18 <broonie> bamse: in general ACPI and DT have different enough models of things that it’s safer to prevent them both being in use at once - discarding the ACPI tables is a good way to provide a level of defence against anything getting it wrong.

23:23 <bamse> broonie: right, so it seems like good practice...was just wondering if it's a requirement

23:36 <dianders> robclark / Dylanger: not quite sure what all the questions are. We definitely have the fuses and we should have signed them with a Chrome OS key. We don't use all of the features that other Qualcomm-based products use though, since our root-of-trust is based on SPI flash write protection, not on a signing key...

23:37 <Dylanger> It would make sense for Google to lock down Qualcomm's modem

23:38 <Dylanger> Otherwise

23:38 <Dylanger> A) You'll have people bytepatching it, bringing down public infra

23:38 <Dylanger> B) Perfect lil place for an implant/malware