Re: [PATCH v2] MIPS: Allow using more than 32-bit addresses for reset vectors when possible

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Fri, Oct 11, 2024 at 03:34:08PM +0200, Gregory CLEMENT wrote:
> While most MIPS64 CPUs use 32-bit values for their VP Local Reset
> Exception Base registers, some I6500 CPUs can utilize a 64-bit value,
> allowing addressing up to 47 bits of physical memory.
> 
> For the EyeQ6H CPU, where physical memory addresses exceed the 4GB
> limit, utilizing this feature is mandatory to enable SMP support.
> 
> Unfortunately, there is no way to detect this capability based solely
> on the ID of the CPU. According to Imagination, which designed the
> CPU, the only reliable method is to fill the reset base field with
> 0xFF and then read back its value. If the upper part of the read-back
> value is zero, it indicates that the address space is limited to 32
> bits.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
> Hello,
> 
> The following patch enables SMP on EyeQ6H SoCs.
> 
> It was successfully tested on EyeQ5 and EyeQ6H, as well as on MIPS32
> CPUs such as ocelot on board PCB123 and JZ4780 on CI20. However, I
> must admit that none of these platforms ran SMP. The ocelot has only
> one core, and while the JZ4780 does have SMP capabilities, its support
> is not yet available in the mainline kernel.
> 
> In the first version, I forgot to remove a line from
> check_64bit_reset() that was originally used to print debug
> information, but is no longer required. Sorry for the inconvenience.
> 
> Gregory
> ---
> Changes in v2:
> - Removed a leftover line of code that was used during development
> - Link to v1: https://lore.kernel.org/r/20241011-eyeq6h-smp-v1-1-866417772cd7@bootlin.com
> ---
>  arch/mips/include/asm/mips-cm.h |  2 ++
>  arch/mips/kernel/smp-cps.c      | 46 ++++++++++++++++++++++++++++++++++-------
>  2 files changed, 41 insertions(+), 7 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]