[PATCH 1/2] arm64: Reduce add_map() complexity

[Fabio Estevam]

Hi Pierre,

On Fri, Mar 15, 2024 at 12:13 PM Pierre-Clément Tosi <ptosi at google.com> wrote:

> I had a quick look through your logs and notice that U-Boot master attempts to
> map addresses in the high VA range e.g.
>
>   Checking if pte fits for virt=ffffffffe4000000 [...]
>
> while the logs that boot successfully only use the low VA range e.g.
>
>   Checking if pte fits for virt=80193000 [...]
>
> Unless that has recently changed (since I last worked with U-Boot), U-Boot on
> AArch64 only supports identity mappings and therefore was only taught how to
> program TTBR0_ELx (i.e. is only able to map low virtual addresses). This means
> that the code - with or without 41e2787f5ec4 - would be unable to map addresses
> such as 0xffffffffe4000000.

Yes, I found it strange too. I may have done something wrong the last
time I instrumented the code.

I tried it again and no longer see these unexpected high virtual addresses.

Please find the new logs here:

https://pastebin.com/raw/qF3GbJry

> Now, given that 41e2787f5ec4 only affects implementation details of add_map(),
> I am surprised that reverting that commit changes the arguments received by the
> function such as virt. As a reminder, add_map() is exclusively used on mem_map:
>
>   for (i = 0; mem_map[i].size || mem_map[i].attrs; i++)
>           add_map(&mem_map[i]);
>
> >
> > That's the only issue preventing colibri-imx8x from booting mainline U-Boot.
>
> If I read the U-Boot configs right i.e.
>
>  - configs/colibri-imx8x_defconfig: CONFIG_ARCH_IMX8=y
>  - arch/arm/mach-imx/imx8/Makefile: obj-y += cpu.o
>  - arch/arm/mach-imx/imx8/cpu.c: struct mm_region *mem_map = imx8_mem_map;

Correct, these are the relevant files for the i.MXQ8XP.

> There is a possibility that your mem_map is getting modified by MACH-specific
> code. In particular, enable_caches() seems to dynamically get the MMU mappings
> from some RPC mechanism (see get_owned_memreg() and sc_rm_get_memreg_info()).
>
> Could it be that whatever services those requests might be returning unexpected
> values? Instrumenting arch/arm/mach-imx/imx8/cpu.c and dumping mem_map (and
> the RPC messages) with/without the patch would help clear this up.

I tried dumping the page table entries, but could not notice anything
that looked suspicious.

Please let me know if you have any suggestions.

Thanks