13:42 <marex> maybe we can have three PDs after all

14:29 <mntmn> marex: does it have a register/bit to swap endianness? :3

14:30 <marex> mntmn: I'm sure you invested a lot of thinking into making that question _this_ obvious ? :)

14:30 <marex> mntmn: yeah, it does have a few, but they are all set the same either way

14:31 <marex> there is however that ARM ADB-400 which is some bus bridge

14:31 <marex> I almost suspect it is the ADB side which is causing this effect

14:31 <mntmn> i was just curious if stuff like this is done in practice, today

14:32 <marex> mntmn: I suspect it has to be, because the core isn't isolated to ARM, so maybe someone could use it on MIPS or whatnot and implementing endian swap in hardware costs nothing

14:32 <mntmn> makes sense.

14:42 <marex> but still, the vivante GPU endian regs are the same

14:44 <marex> I _suspect_ that when the GPU2D PD comes up, the ADB-400 which is the DVFS bridge between , well ... CCI-400 and the GPU ... somehow randomly picks the byte order ... and the SRC reset in fact resets all the GPU2D, GPU3D, GPUMIX (is GPUMIX the ADB-400 ?) and puts those bits in order

14:44 <marex> so the question is, doesn't the ADB-400 have some configuration interface ?

14:45 <marex> I guess there should be ADB-400 per GPU

15:41 <marex> hm, the GPU does indicate VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR

15:42 <marex> but how does it get there, what does happen in the silicon ... grumb

15:42 <marex> is there some weird bug , where the ADB 400 doesn't correctly attach the GPU to the CCI-400 ?

16:01 <marex> hm ... looks like hitting the reset bit at the byte-swapped position does force sanity back into the system :)

16:02 <marex> maybe that is the solution

16:02 <marex> maybe that even returns all the PDs back into usable state, hmmmm