Earlycon fails to initialize on arcv2 properly if uncached region is below default 0xc0000000

[iguryanov]

Hi,

I've got a complaint about missing boot output (at least with 5.10.80 version).
System has UART mapped 0xac002000, and "earlycon=uart8250,mmio32,0xac002000,115200n" boot args don't help.

default perip_base is set to ARC_UNCACHED_ADDR_SPACE, i.e. 0xc0000000
That value is updated to actual value from BCR quite late in setup_arch() -> setup_processor() -> read_arc_build_cfg_regs() -> read_decode_cache_bcr() -> read_decode_cache_bcr_arcv2() .

The problem is that early_con() is configured before that step. earlycon_map() fails and returns 0.
I guess this happens because earlycon_map() -> ioremap() -> arc_unacched_addr_space() returns NULL (requested address is below default perip_base) and slab_is_available() there returns error as well because MMU is not initialized yet.

Would it make sense to call read_arc_build_cfg_regs() before configuring earlycon?

Regards,
Igor.

[VVIsaev]

Hi @iguryanov ,

We definitely can configure peripheral space before earlycon initialization, no problem here.

Point is that this configuration is not officially supported, see HS4x databook D.2.3.5 Total Size of External Memory Supported:

The kernel assumes everything above peripheral space to 0xffff_ffff to be uncached -
peripheral only space. The start address (256 MB aligned) is programmable (through the
AUX_VOLATILE register) and may be 0xC000_0000 , 0xD000_0000 , 0xE000_0000 or
0xF000_0000.

This change will require some work to make sure that kernel space does not cross this new bigger peripheral space and it can take some time to make such change.

[iguryanov]

Hi @VVIsaev,

that quote is reflecting Linux kernel implementation existed long time ago. Vineet and I worked on that section to help customers configure ARC core in Architect in some suitable way for the kernel - make sure needed extensions present, most efficient options used, etc.

So customer just ignored that piece...

We also wrote that for HS3x - at that time hardware did not support Limit and other new fields in AUX_VOLATILE.
E section were copied into 4x as it its and "E.2.3.5 Total Size of External Memory Supported" was not updated to reflect preferred settings for LIMIT, S and D fields...

I agree that customer did not see or ignored that section.
Their simplest workaround at the moment (and it looks ok for me) is to adjust ARC_UNCACHED_ADDR_SPACE to 0xa0000000.

About kernel space crossing peripherals - that still might happen later with current implementation if it does not happen safety checks later. (read_decode_cache_bcr_arcv2() definitely does not care, I did not look into other places).
So it is either up to some mechanism which we might have already (and probably it will complaint later when MMU is enabled, or something like that), or user would just shoot his feet off as usual. I think reading bcr and updating perip_base before earlycon would not make things much worse as it happened before MMU configuration anyway.

Regards,
Igor.

[VVIsaev]

The workaround looks good to me.

I don't want to make such change because current implementation matches databook. With this change more customers will think that this configuration is supported, which is not true. So if it is OK for customer to apply the patch, lets do this.

If you think it is useful for other customers to move peripheral space below 0xc000_0000, we can add support for this. I'll add border checks and do some testing to make sure it doesn't break anything.

[iguryanov]

Databook says it for historical reasons (best reasonable performance) - we just did such implementation long time ago to make sure kernel has enough space. This is not hardware limitation - we (kernel developers) just imposed it on users long time ago
In reality nothing stops volatile region to start even from 0x90000000... even 256mb might be enough for some users.