fel: h616: support alternative die variant

[apritzel]

The Allwinner H616 ships in at least two die variants, sometime under a different name (H618, T507), but sometimes labeled as a normal "H616". The die variants differ in their CPU cluster control subsystem, which affects the location of the RVBAR shadow register used to reset the core into 64-bit mode. We use that in the "reset64" command, but also as part of the boot process using the "uboot" command, on ARMv8 cores.

Add code to detect the die variant by reading the VER_REG MMIO register, where the original die reports 0x00 in the lower 8 bits, but the newer die variants apparently 0x02. In the latter case let the aw_rmr_request() function use the alternative RVBAR address to do the 64-bit switch. This matches what we do in U-Boot and Trusted Firmware.

[paulkocialkowski]

Looks good to me, should I merge this?

[paulkocialkowski]

Also I found this list which has a clear mapping between the version registers and the die revisions: sunxi-sid.h

[apritzel]

Thanks @paulkocialkowski for having a look, and yes, if that looks reasonable to you, please merge it!
That source you point to is interesting, though I don't know if the low 16 bits point to the VER_REG register here, as all "other" H616 chips we found read "0x02" in the low eight bits.
But we definitely are positive about the relationship between the version register and the location of the RVBAR shadow registers, that has been "proven" experimentally to be the case across several H616, H618 and T507 chips. Plus BSP code elsewhere was seen explicitly testing the low 8 bits of the version register to decide between the addresses.
And we merged code to that effect in U-Boot and TF-A.

I just tested it again: the very same sunxi-fel binary successfully booted into U-Boot on a X96 Mate ("old" H616), OrangePi Zero3 ("new" H616), and Pine64-LTS (A64, regression test).

[paulkocialkowski]

So I looked a bit at the matching sunxi-sid.c file to try and figure out what it's doing. It reads a "soc id" register at offset 0x200 from the SID base (0x3006000) and extracts bit 22, then reads the first 3 bits of the usual version register at offset 0x24 from SYSCON base (same as what this patch is looking at, except only 3 bits instead of 8).

It then uses these values to match in soc_ver_map but value 2 for the low bits of 0x24 SYSCON looks invalid. Well there's a chance this piece of code is just copy-pasta and since it's not really used anywhere I wouldn't trust it much.

So all in all your approach is probably the most reliable one. Did you find some reference Allwinner boot/atf code that is doing the same?