ARM32 / ARM64 separation

[carlocaione]

ARM32 and ARM64 (AArch64) currently share the same code space: arch/arm,include/arch/arm, soc/arm and boards/arm.

This was done at the beginning of the time because the hope was that the two architectures would have shared more code. Reality is that ARM32 and AArch64 are two different architectures which shares almost nothing. The only thing they share is the GIC driver that is hosted outside of arch/arm.

So my proposal is that we should split the two and treat them as two different architectures. We could start separating them in soc/{arm,arm64} and boards/{arm,arm64} but I think that we should push this forward and moving to have a separate arch/arm64 directory as well.

Any thoughts?

[carlocaione]

tagging the arm / arm64 people @ioannisg @npitre @stephanosio @galak @nashif @jharris-intel @sandeepbrcm @Abhishek-brcm

[ioannisg]

I am in favor of this separation. True that AARCH64 has little in common with other ARM 32-bit variants.

@carlocaione do the ARCHes share common build configuration code (e.g. cmake files, compiler options, etc)?

[carlocaione]

@carlocaione do the ARCHes share common build configuration code (e.g. cmake files, compiler options, etc)?

Nope, there is almost no overlap at all.

[npitre]

+1

[jharris-intel]

Any thoughts?

There are a few system registers that are (almost) shared between AArch32 and AArch64 (E.g. the ARMv8 generic timer), and they happen to share a memory model (...mostly), but yes, they have very little in common.

My one concern here is shared board/soc setup code - but I presume that there is somewhere I could put board setup code for board X that is shared between AArch32 and AArch64?

[npitre]

On Mon, 1 Mar 2021, jharris-intel wrote: My one concern here is shared board/soc setup code - but I presume that there is somewhere I could put board setup code for board X that _is_ shared between AArch32 and AArch64?

Do you have an actual example in mind? Beyond the basic CPU architecture that is not shared between Aarch32 and Aarch64, extra SOC setup is typically done as part of the driver that handles part of that SOC, and that code lives in a common location already.

[jharris-intel]

Do you have an actual example in mind?

Yes, but proprietary unfortunately. However, it fits into this:

extra SOC setup is typically done as part of the driver that handles part of that SOC, and that code lives in a common location
already.

so no worries.

[galak]

I have no issue with making this split/change.

[ioannisg]

Then I guess we could proceed with the idea,

Adding @carlescufi @MaureenHelm @erwango, to raise awareness across cortex-m vendors.

[MaureenHelm]

My one concern here is shared board/soc setup code - but I presume that there is somewhere I could put board setup code for board X that is shared between AArch32 and AArch64?

I wonder about this too, which gets into a more general question about how we support multicore SoCs with different architectures. Examples are i.MX RT600 (CM33+Xtensa), i.MX8MM (CA53+CM4), and Vegaboard (2xRISC-V + 2xCortexM). I've wondered if we should organize boards and SoCs by vendor instead of architecture.

cc: @MrVan

[carlocaione]

I wonder about this too, which gets into a more general question about how we support multicore SoCs with different architectures.

Why is this a problem? In this case you end up having the AArch64 core under {soc,boards}/arm64 and the other core under {soc,boards}/arm. After all Zephyr is usually running only on one of the two cores.

The only real problem I see is for the DTS files that sometimes share a common DTSI. In that case I think we can allow a bit of duplication between dts/arm64 and dts/arm.

[MrVan]

I wonder about this too, which gets into a more general question about how we support multicore SoCs with different architectures.

Why is this a problem? In this case you end up having the AArch64 core under {soc,boards}/arm64 and the other core under {soc,boards}/arm. After all Zephyr is usually running only on one of the two cores.

The only real problem I see is for the DTS files that sometimes share a common DTSI. In that case I think we can allow a bit of duplication between dts/arm64 and dts/arm.

Could we directly import device tree from Linux Kernel for arm64?

[MrVan]

My one concern here is shared board/soc setup code - but I presume that there is somewhere I could put board setup code for board X that is shared between AArch32 and AArch64?

I wonder about this too, which gets into a more general question about how we support multicore SoCs with different architectures. Examples are i.MX RT600 (CM33+Xtensa), i.MX8MM (CA53+CM4), and Vegaboard (2xRISC-V + 2xCortexM). I've wondered if we should organize boards and SoCs by vendor instead of architecture.

For i.MX8MM, I think it is ok to split A53 and M4. For CPU core, there is almost nothing shared, they only share some drivers.

[erwango]

Why is this a problem? In this case you end up having the AArch64 core under {soc,boards}/arm64 and the other core under {soc,boards}/arm. After all Zephyr is usually running only on one of the two cores.

Having both targets under a same directory is useful to share Kconfig and dts settings and hence avoid specific configuration issues, specifically about shared resources.
This being said, unless I missed something, I don't see the direct need of modifying boards/ organisation due to a modification under arch/.

[carlocaione]

Having both targets under a same directory is useful to share Kconfig and dts settings and hence avoid specific configuration issues, specifically about shared resources.

I can see the problem with DTS, with Kconfig definitely less assuming that we are talking about cores with different architectures. But also in that case I think we can survive with a bit of duplication.

This being said, unless I missed something, I don't see the direct need of modifying boards/ organisation due to a modification under arch/.

Because I'm planning to also split boards/arm in boards/{arm,arm64}, same for soc, otherwise it gets confusing. Also given that arm64 will be a new architecture I think having arm and arm64 in a common directory (but being now two different arch) can confuse twister and other tools.

[erwango]

[..] with Kconfig definitely less assuming that we are talking about cores with different architecture [...]

I don't think having different architecture totally exclude the possibility of having Kconfig options that could impact both cores (specifically in resource sharing domain). Anyway, this is only a configuration coherency problematic and not a blocker at all.

Because I'm planning to also split boards/arm in boards/{arm,arm64}, same for soc, otherwise it gets confusing. Also given that arm64 will be a new architecture I think having arm and arm64 in a common directory (but being now two different arch) can confuse twister and other tools.

Makes sense, txs.

[carlocaione]

update: this is currently on hold waiting for all the userspace work to be merged.

[ioannisg]

update: this is currently on hold waiting for all the userspace work to be merged.

That's ok.