| Message ID | 20210907102722.47543-5-bert@biot.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for Airoha EN7523 SoC | expand |
Hi Bert, On Tue, 7 Sept 2021 at 19:30, Bert Vermeulen <bert@biot.com> wrote: > > From: John Crispin <john@phrozen.org> > > 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 <daniel@0x0f.com> wrote: > On Tue, 7 Sept 2021 at 19:30, Bert Vermeulen <bert@biot.com> wrote: > > > > From: John Crispin <john@phrozen.org> > > > > 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 <arnd@arndb.de> 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
On Tue, Sep 7, 2021 at 2:27 PM Daniel Palmer <daniel@0x0f.com> wrote: > On Tue, 7 Sept 2021 at 20:52, Arnd Bergmann <arnd@arndb.de> 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
Hi Arnd, On Tue, 7 Sept 2021 at 23:12, Arnd Bergmann <arnd@arndb.de> 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 4:32 PM Daniel Palmer <daniel@0x0f.com> wrote: > On Tue, 7 Sept 2021 at 23:12, Arnd Bergmann <arnd@arndb.de> 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
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