05:50 <JensGlathe[m]> I‘ve put the ACPI dump and HWInfo log on aarch64-laptops/build, lumag already merged it. Good to know re ASUS BIOS update. And from peeking into hp and acer BIOS files I had the impression they support both variants.

05:52 <travmurav[m]> I wonder if anyone with uart (or at least earlycon=efifb) tried to boot purwa

06:04 <JensGlathe[m]> Not yet.

06:41 <JensGlathe[m]> Just done so, it goes over earlycon (looking very normal), starts booting up further and resets. Video time I guess. But breakfast first.

07:08 <travmurav[m]> interesting, perhaps different gpu then?

07:09 <travmurav[m]> as we discussed with robclark recently

07:11 <travmurav[m]> or ah you mean "time to make a video to look at the logs closer" not "seems like logs get to the video init", though still I think we kinda guessed that cpu/gpu clusters are the only different thing it seems

07:12 <travmurav[m]> inb4 just wrong gpu firmware/microcode

07:31 <JensGlathe[m]> Probably. I just took the Snapdragon Dev Kit stick and booted with it. Ofc it has its firmwares in the initramfs.

07:31 <JensGlathe[m]> The GPU names itself X1-45, the SoC SnapDragon 8cx nextgen. But for a first try it at least comes over earlycon, so any missing cores don‘t seem to stop it.

07:31 <travmurav[m]> for cpu the firmware should just reject psci_on(8..11)

07:32 <travmurav[m]> so it's fine, but I think gpu wise the os touches registers which can easily break things if the registers are different

07:32 <travmurav[m]> and/or if the microcode/firmware is different I guess

07:34 <JensGlathe[m]> Will do another try without specific firmwares. Later.

07:34 <JensGlathe[m]> Will do the video, thouhg

07:46 <travmurav[m]> oh, interconnect related, fun

07:46 <JensGlathe[m]> Its trapping with iommu_read

07:47 <JensGlathe[m]> When starting systemd-udevd

07:48 <JensGlathe[m]> Later more tries

07:48 <travmurav[m]> well I think after the first error like ^^, can assume the system is dead

07:48 <JensGlathe[m]> as in never?

07:49 <travmurav[m]> never?

07:49 <JensGlathe[m]> never ever going to work

07:49 <travmurav[m]> I mean I believe if you catch an oops in linux, it's safe to assume the internal state is broken so all later errors could be attributed to the first

07:50 <JensGlathe[m]> that would be my assumption.

07:50 <travmurav[m]> well I guess time to disable bwmon and try again? :D

07:51 <JensGlathe[m]> bwmon?

07:51 <travmurav[m]> [icc_bwmon], the thing that oopsed on the photo

07:52 <travmurav[m]> a module even, should be easy :D

07:52 <JensGlathe[m]> oh okay. Yeah but now its family day, no time for a rabbit hole like this now

07:53 <travmurav[m]> yeah :D

07:53 <travmurav[m]> iirc bwmon is for optimizing the performance levels of interconnects (speeding them up/slowing down on demand)

07:54 <travmurav[m]> ohhhhhh

07:54 <travmurav[m]> ohhhhhhhhhh

07:54 <travmurav[m]> there is three bwmons for each cluster

07:54 <travmurav[m]> that would make a lot of sense

07:54 <travmurav[m]> https://elixir.bootlin.com/linux/v6.11-rc4/source/arch/arm64/boot/dts/qcom/x1e80100.dtsi#L5613-L5679

07:54 <travmurav[m]> need to kill one of those

07:55 <JensGlathe[m]> so disable one, be in the clear?

07:55 <travmurav[m]> since one of those certainly doesn't exist in hw

07:55 <travmurav[m]> yeah

07:55 <travmurav[m]> and thus you get sync abort due to touching non-existent registers

07:55 <travmurav[m]> that makes sense to me

07:56 <travmurav[m]> well maybe there is more stuff to be killed like this later but probably need to handle those one-at-a-time

07:59 <JensGlathe[m]> nice, will look into this... later. Thank you for the pointer!

07:59 <JensGlathe[m]> Looks like we need a purwa dtsi, though

08:06 <travmurav[m]> tbh, I'd argue it might be better designed as overlays even, so we can build x1e and x1p dtb from the same sources easily, like it's done for db410c and rb5 right now for example, but have whole x1p-40.dtbo

08:06 <travmurav[m]> so like we'd just have a makefile change to add x1p variant of the device

08:07 <travmurav[m]> and smart tools like dtbloader could then detect and do whatever (apply overlay/ pick by suffix/ fixup via code...)

08:08 <travmurav[m]> but well, need to make it work first :D

08:09 <JensGlathe[m]> Can we delete nodes in a dtbo? Or set it disabled?

08:09 <travmurav[m]> Only set disabled

08:09 <travmurav[m]> Should be enough for most cases tho

08:10 <travmurav[m]> We fixed GPU zap shader node for that for example

08:10 <JensGlathe[m]> Good point

15:31 <robclark> JensGlathe[m]: for sure the gpu is different (3 SP vs 6 SP), I suspect various OPP tables will be different and a lot of other various x1e80100.dtsi type things.. you could try disabling ICC and DRM_MSM and see how far you get, but I suspect we'll need patches from qc

15:32 <robclark> probably the part is pin compatible and "identical" from OEM/ODM PoV but that doesn't mean there aren't differences in core dtsi