From: John Crispin <[email protected]>
EN7523 is an armv7 based silicon used inside broadband access type devices
such as xPON and xDSL. It shares various silicon blocks with MediaTek
silicon such as the MT7622.
Signed-off-by: John Crispin <[email protected]>
Signed-off-by: Bert Vermeulen <[email protected]>
---
arch/arm/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82f908fa5676..4c210df05c77 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -580,6 +580,20 @@ config ARCH_VIRT
select HAVE_ARM_ARCH_TIMER
select ARCH_SUPPORTS_BIG_ENDIAN
+config ARCH_AIROHA
+ bool "Airoha SoC Support"
+ depends on ARCH_MULTI_V7
+ select ARM_AMBA
+ select ARM_GIC
+ select ARM_GIC_V3
+ select ARM_DMA_USE_IOMMU
+ select ARM_PSCI
+ select HAVE_ARM_ARCH_TIMER
+ select IOMMU_DMA
+ select COMMON_CLK
+ help
+ Support for Airoha EN7523 SoCs
+
#
# This is sorted alphabetically by mach-* pathname. However, plat-*
# Kconfigs may be included either alphabetically (according to the
--
2.25.1
Hi Bert,
On Tue, 7 Sept 2021 at 19:30, Bert Vermeulen <[email protected]> wrote:
>
> From: John Crispin <[email protected]>
>
> EN7523 is an armv7 based silicon used inside broadband access type devices
> such as xPON and xDSL. It shares various silicon blocks with MediaTek
> silicon such as the MT7622.
This is a Cortex A53 isn't it? So it's ARMv8. I thought the issue is
that it's actually a 64bit system but you only have a 32bit
bootloader, firmware etc?
Off-topic but related: Another MediaTek spin off, SigmaStar, seems to
have done exactly the same thing. Cortex A53 chip running as a 32bit
system to avoid having to fix their software. I'm interested to see if
this makes it into arm or arm64. :)
Cheers,
Daniel
On Tue, Sep 7, 2021 at 12:48 PM Daniel Palmer <[email protected]> wrote:
> On Tue, 7 Sept 2021 at 19:30, Bert Vermeulen <[email protected]> wrote:
> >
> > From: John Crispin <[email protected]>
> >
> > EN7523 is an armv7 based silicon used inside broadband access type devices
> > such as xPON and xDSL. It shares various silicon blocks with MediaTek
> > silicon such as the MT7622.
>
> This is a Cortex A53 isn't it? So it's ARMv8. I thought the issue is
> that it's actually a 64bit system but you only have a 32bit
> bootloader, firmware etc?
>
> Off-topic but related: Another MediaTek spin off, SigmaStar, seems to
> have done exactly the same thing. Cortex A53 chip running as a 32bit
> system to avoid having to fix their software. I'm interested to see if
> this makes it into arm or arm64. :)
Maybe it's best to just add them to both at the same time? The boot
loader situation might take a bit to work out, but in theory this should
be fixable.
You can generally include .dtsi files from one in the other, as you can
see from e.g. arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts.
For new files, I think I would prefer having the .dts files in arm64 and
including them from arch/arm/ rather than the other way round, but
others may come up with a good reason to keep doing the reverse.
This would help encourage the thought that running a 64-bit
kernel is the better setup, rather than propagate the 32-bit kernel
nonsense on 64-bit machines.
Arnd
Hi Arnd,
On Tue, 7 Sept 2021 at 20:52, Arnd Bergmann <[email protected]> wrote:
> > Off-topic but related: Another MediaTek spin off, SigmaStar, seems to
> > have done exactly the same thing. Cortex A53 chip running as a 32bit
> > system to avoid having to fix their software. I'm interested to see if
> > this makes it into arm or arm64. :)
>
> Maybe it's best to just add them to both at the same time? The boot
> loader situation might take a bit to work out, but in theory this should
> be fixable.
I wonder how fixable it would be..
I haven't gotten a board with the chip in question (SSD268G) yet but
from looking at some firmware binaries I can see that even u-boot is a
6 year old 32bit version.
As far as I can tell there's no PSCI, ATF etc that I think would be
expected for an arm64 machine.
I think the broken memory controller is still there so somehow I'd
need to get the heavy barrier to work in arm64. I haven't yet worked
out if that's even possible.
I think they are advertising that it supports up to 2GB of DDR. So
it's a hobbled 64bit capable system with highmem.
Putting most of the DT bits under arm64 even though it's so broken
it'll only ever boot a 32bit kernel makes sense to me.
Better than having lots of arm64 typical stuff like a newer GIC in a
file under arm and confusing everyone that comes across it.
Cheers,
Daniel
Hi Arnd,
On Tue, 7 Sept 2021 at 23:12, Arnd Bergmann <[email protected]> wrote:
> > I think the broken memory controller is still there so somehow I'd
> > need to get the heavy barrier to work in arm64. I haven't yet worked
> > out if that's even possible.
>I think I missed that part of the discussion, or I forgot about it already.
>What is the issue you are referring to here?
Sorry. I should have put a bit more context. This is for the SSD268G
not the original target of this series. But a similar situation.
The SSD268G (according to the decompiled device tree) is the same
hardware as the MSTAR_V7 chips but with a Cortex A53 instead of the
Cortex A7.
So it probably has the same memory controller as the MSTAR_V7 stuff
and that memory controller is not coherent so it needs the kernel to
make sure memory requests are flushed out to memory before DMA
happens[0]. For arm I fixed that with the heavy mb callback. With
arm64 I have no idea how to fix that.
I'm interested to see how this Airoha EN7523 series goes as if/when I
push anything for the SSD268G it'll probably only be for a 32bit
kernel.
0 - https://elixir.bootlin.com/linux/latest/source/arch/arm/mach-mstar/mstarv7.c#L61
On Tue, Sep 7, 2021 at 2:27 PM Daniel Palmer <[email protected]> wrote:
> On Tue, 7 Sept 2021 at 20:52, Arnd Bergmann <[email protected]> wrote:
> > > Off-topic but related: Another MediaTek spin off, SigmaStar, seems to
> > > have done exactly the same thing. Cortex A53 chip running as a 32bit
> > > system to avoid having to fix their software. I'm interested to see if
> > > this makes it into arm or arm64. :)
> >
> > Maybe it's best to just add them to both at the same time? The boot
> > loader situation might take a bit to work out, but in theory this should
> > be fixable.
>
> I wonder how fixable it would be..
>
> I haven't gotten a board with the chip in question (SSD268G) yet but
> from looking at some firmware binaries I can see that even u-boot is a
> 6 year old 32bit version.
> As far as I can tell there's no PSCI, ATF etc that I think would be
> expected for an arm64 machine.
If the source code is available, creating a minimal PSCI implementation
in u-boot should be possible, and it would make it work well for both
32-bit and 64-bit kernels. There is no need for ATF here.
> I think the broken memory controller is still there so somehow I'd
> need to get the heavy barrier to work in arm64. I haven't yet worked
> out if that's even possible.
I think I missed that part of the discussion, or I forgot about it already.
What is the issue you are referring to here?
Arnd
On Tue, Sep 7, 2021 at 4:32 PM Daniel Palmer <[email protected]> wrote:
> On Tue, 7 Sept 2021 at 23:12, Arnd Bergmann <[email protected]> wrote:
>
> > > I think the broken memory controller is still there so somehow I'd
> > > need to get the heavy barrier to work in arm64. I haven't yet worked
> > > out if that's even possible.
> >I think I missed that part of the discussion, or I forgot about it already.
> >What is the issue you are referring to here?
>
> Sorry. I should have put a bit more context. This is for the SSD268G
> not the original target of this series. But a similar situation.
> The SSD268G (according to the decompiled device tree) is the same
> hardware as the MSTAR_V7 chips but with a Cortex A53 instead of the
> Cortex A7.
> So it probably has the same memory controller as the MSTAR_V7 stuff
> and that memory controller is not coherent so it needs the kernel to
> make sure memory requests are flushed out to memory before DMA
> happens[0]. For arm I fixed that with the heavy mb callback. With
> arm64 I have no idea how to fix that.
Ok, got it. I do remember the Mstar SoCs having this problem. My feeling
is that this should be possible to implement on arm64 as well using
an erratum fixup with a configuration option, and possibly dynamic patching
to avoid the worst effects when the workaround is built into the kernel
but not needed.
Whether this is acceptable or not is up to the arm64 architecture maintainers
of course.
Arnd