06:50 <cyrozap> apritzel: BinDiff first matches functions between the two binaries, and then it compares just those functions to each other--both the CFG and the instructions themselves. So, it's more of a function-level diff, and that should probably reduce that problem you're seeing.

10:01 <hexdump0815> i just noticed that there are now two h6 tv box dts in v5.18

10:01 <hexdump0815> is any of the two having that 100mb eth which required some workarounds in the past?

10:01 <hexdump0815> i.e. are there still extra patches required to make this eth phy work or is the support in mainline meanwhile?

10:02 <hexdump0815> and while i'm at asking questions - another one: i remember there was some effort to make an mainline wifi driver work with xr819

10:03 <hexdump0815> did that result at some working solution in the end which is in mainline now or is there some latest state of the experiments back then somewhere on github?

10:14 <apritzel> hexdump0815: re: AC200 (embedded 100MBit Ethernet PHY in later SoCs): I wouldn't be aware of recent activities, but it's on my list, still

10:16 <apritzel> hexdump0815: re: xr819: there was some activity flaring up a few months ago, but I don't think anything came from it, mainline-wise

10:16 <cyrozap> apritzel: btw, here are some screenshots of what BinDiff shows you: https://imgur.com/a/gAjNdOL

10:18 <apritzel> cyrozap: ah, OK, so it's somewhat clever in ignoring minor differences, like different addresses and branch targets

10:19 <apritzel> I wonder if it can deal with different register allocations

11:02 <hexdump0815> jernej: i think you were working back then on both topics i mentioned above

13:12 <apritzel> cyrozap: can you try to change the ".word 0x00000000" at the end of arch/arm/cpu/armv8/fel_utils.S into ".quad 0x00000000"?

13:15 <apritzel> probably doesn't make a difference, because it's padded to align the next word anyway, and this is assembly, but it looks like a bug, regardless

13:21 <apritzel> (or not, ignore me)

13:23 <apritzel> that part is just what puzzles me: I see debug output from spl_board_load_image(), in both versions outputting the very same values from fel_stash (extended to print all members), and from then on it's only assembly

13:24 <apritzel> the other thing I see is that GCC 12 uses an "ldp" in spl_board_load_image(), where we had two "ldr"s before, but the alignment looks alright in any case

14:53 <jernej> hexdump0815: as apritzel said

14:53 <jernej> in the meantime, I received TX6 mini, with XR819, so I can debug suspend issue

14:53 <jernej> but I still didn't manage to make crust work

14:54 <jernej> on that board

14:55 <jernej> anyway, I don't work on those two features at this time

17:43 <hexdump0815> jernej: thanks for the update

17:43 <jernej> np

17:44 <jernej> apritzel: any idea about DT solution for AC200? that's the only reason why this driver is not mainlined yet

17:45 <apritzel> jernej: I know, but I forgot the details, need to have a look tomorrow

17:46 <apritzel> jernej: do you have a pointer to your latest patches / branch?

17:47 <jernej> in short, AC200 MFD needs to be configured over I2C first and only then can be eth phy probed over mdio

17:49 <jernej> well, latest working patches are always on LibreELEC github (currently for 5.18): https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Allwinner/patches/linux

17:50 <jernej> patches 28, 29, 49 and 51

17:50 <apritzel> jernej: thanks!

17:51 <jernej> apritzel: but I also send patches on ML in the past: https://patchwork.kernel.org/project/linux-arm-kernel/cover/20200416185758.1388148-1-jernej.skrabec@siol.net/

18:02 <apritzel> I remember, indeed tricky. One thing I was just wondering about is to have a reset controller, controlled by I2C, and the PHY just refers to this via its reset property

18:03 <apritzel> or use some syscon trick, to refer to the I2C child from the PHY node?

18:03 <apritzel> I guess just a reset controller wouldn't cut it, as we need to configure more via I2C, which only a PHY driver knows about

18:05 <apritzel> I will have a think, and a look at the datasheet again. I guess broonie would be a good person to ask about this ...

19:28 <cyrozap> apritzel: I tried changing that .word to .quad, and still got the same problem. Like you said, since it was getting padded anyways it probably wouldn't make a difference, but it was worth a shot. I don't think it's a bug, though, since "STR Wn, ..." should only be writing 4 bytes, and I think the alignment is there just because the following constants are dwords (which IMO is a bug since only the

19:28 <cyrozap> lower word is ever used) and it wants to keep them dword-aligned.

19:31 <cyrozap> Err, I meant to say that the CPU hotplug magic being loaded as a dword is a bug--of course the CPU hotplug _address_ should remain a dword.

19:49 <cyrozap> apritzel: And regarding the "ldp", I think that shouldn't matter--like you said, the exact same values are printed from fel_stash in both versions, which means the values are getting passed to the function correctly.

19:52 <cyrozap> Maybe it could be something caching-related? Or maybe there's some boot ROM state that needs to be saved that we're not currently saving, and some GCC 12-optimized code is clobbering it.

20:18 <cyrozap> Maybe the USB traffic can give us more clues? With the broken SPL, when it returns to FEL mode, the device is able to receive the aw_send_usb_request() packet sent to it ("AWUC"), but the FEL request sent with usb_bulk_send() is the one that times out.

20:19 <cyrozap> So, I'm wondering if the device is successfully returning to the boot ROM and the boot ROM is just getting stuck somewhere, or if the boot ROM is failing to run at all.

20:20 <cyrozap> apritzel: Is there a way to dump the boot ROM, possibly over FEL?

20:24 <apritzel> cyrozap: sure, it's at address 0, but you can just use that here: https://github.com/smaeul/sunxi-blobs/tree/master/sun50iw9p1/nbrom

20:27 <apritzel> I just saw that the (working) build for my TV box is below 32K, but the OPiZero2 build is bigger than that (both with GCC 11.2.0)

20:27 <apritzel> so maybe there is something funny with 0x28000 ...

20:32 <apritzel> maybe something corrupts the backed up BROM stack copy?

20:50 <cyrozap> apritzel: But the working SPL is _also_ 40K, and both the working and broken SPLs end at 0x28210, at least in terms of non-zero data.

20:51 <apritzel> cyrozap: yeah, that's the weak point, but that was with a different compiler

23:03 <cyrozap> apritzel: What I'm saying is that both the working SPL compiled with GCC 10 and the broken SPL compiled with GCC 12 result in binaries of the same size (40K), with the end of the non-zero data being 0x28210 in both binaries.

23:05 <apritzel> cyrozap: yes, I understand, but GCC 12 creates a working copy for my H616 TV box, which is below 32K (because it skips those DRAM training parts)

23:06 <apritzel> cyrozap: also I confirmed that it's not the ldp: replaced that with two ldr's: same behaviour

23:08 <apritzel> cyrozap: also caches are off all the time, including the SCTLR.I bit