On 8/15/23 15:59, Andre Przywara wrote:
Hi Sam,
Hi Andre,
So that's a bit more nasty indeed. I don't even know if R_CPUCFG really makes sense here, as the _R_ term typically refers to the management processor, which the D1/R528 don't have. Or at least the always-on power domain, but then again this hardly relates to the secondary entry point. I think the name was just used because the address matches the one used in the H6.
Oh, no. That was my doing (and my reasoning) by suggesting that for inclusion in your series. Yours is good reasoning to be rid of it.
So taking a step back, I wonder if we should actually just define a CONFIG_SUNXI_CPU_SOFT_ENTRY (or so) *Kconfig* symbol, which holds that address, and let the per-SoC definition be solved in Kconfig instead. Because SUNXI_R_CPUCFG_BASE and also SUNXI_RTC_BASE seem to be just used as the base address for that purpose, with some magic offset added, across all of U-Boot (ARMv8 FEL and v7 PSCI).
Mmh, since this is a block of soft registers for managing several functions of both cores, I think I'd rather point to the base of the block and still use an offset to get to the specific soft register. Allwinner may keep this layout for a 4-core chip in the near future or U-Boot may want to add code that sets the CPU0 hotplug flag, for example.
I'm not unwilling to do the Kconfig route, but just out of curiosity, what would your fallback plan be?
So can you try to work on that base? I will take care of armv8/fel_utils.S, which uses some post-increment assembly trick to keep the code small, which wouldn't work anymore. But I have an idea how to solve this.
Before that, I think now might be a good time for me to send in the v2 that I have so far; I doubt the final patch of my v2 series will pass review, but I'd like to keep us synced up (and clear away any patches in that series that do pass review off from my mental desktop).
Cheers, Andre
Likewise, Sam
