| Message ID | 20210907102722.47543-1-bert@biot.com |
|---|---|
| Headers | show |
| Series | Add support for Airoha EN7523 SoC | expand |
07.09.2021 13:27, Bert Vermeulen пишет: > From: John Crispin <john@phrozen.org> > > This enables basic bootup support for the Airoha EN7523 SoC. > > Signed-off-by: John Crispin <john@phrozen.org> > Signed-off-by: Bert Vermeulen <bert@biot.com> > --- > arch/arm/configs/multi_v7_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig > index d9abaae118dd..a9370a95dc38 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -31,6 +31,7 @@ CONFIG_MACH_BERLIN_BG2=y > CONFIG_MACH_BERLIN_BG2CD=y > CONFIG_MACH_BERLIN_BG2Q=y > CONFIG_ARCH_DIGICOLOR=y > +CONFIG_ARCH_AIROHA=y > CONFIG_ARCH_EXYNOS=y > CONFIG_ARCH_HIGHBANK=y > CONFIG_ARCH_HISI=y > @@ -983,6 +984,7 @@ CONFIG_STAGING_BOARD=y > CONFIG_MFD_CROS_EC_DEV=m > CONFIG_CROS_EC_I2C=m > CONFIG_CROS_EC_SPI=m > +CONFIG_COMMON_CLK_EN7523=y If SoC doesn't work without clk support, then this option should be auto-selected by the arch option. It also doesn't look like upstream kernel has COMMON_CLK_EN7523 at all.
On 9/7/21 12:39 PM, Dmitry Osipenko wrote: > 07.09.2021 13:27, Bert Vermeulen пишет: >> From: John Crispin <john@phrozen.org> >> >> This enables basic bootup support for the Airoha EN7523 SoC. >> >> Signed-off-by: John Crispin <john@phrozen.org> >> Signed-off-by: Bert Vermeulen <bert@biot.com> >> --- >> arch/arm/configs/multi_v7_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig >> index d9abaae118dd..a9370a95dc38 100644 >> --- a/arch/arm/configs/multi_v7_defconfig >> +++ b/arch/arm/configs/multi_v7_defconfig >> @@ -31,6 +31,7 @@ CONFIG_MACH_BERLIN_BG2=y >> CONFIG_MACH_BERLIN_BG2CD=y >> CONFIG_MACH_BERLIN_BG2Q=y >> CONFIG_ARCH_DIGICOLOR=y >> +CONFIG_ARCH_AIROHA=y >> CONFIG_ARCH_EXYNOS=y >> CONFIG_ARCH_HIGHBANK=y >> CONFIG_ARCH_HISI=y >> @@ -983,6 +984,7 @@ CONFIG_STAGING_BOARD=y >> CONFIG_MFD_CROS_EC_DEV=m >> CONFIG_CROS_EC_I2C=m >> CONFIG_CROS_EC_SPI=m >> +CONFIG_COMMON_CLK_EN7523=y > > If SoC doesn't work without clk support, then this option should be > auto-selected by the arch option. > > It also doesn't look like upstream kernel has COMMON_CLK_EN7523 at all. Oops, you're right -- the clock driver is coming as soon as the base system is in. I guess this option (under ARCH_AIROHA) should come in at that time as well? I'll respin after some more comments.
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
07.09.2021 13:41, Bert Vermeulen пишет: > On 9/7/21 12:39 PM, Dmitry Osipenko wrote: >> 07.09.2021 13:27, Bert Vermeulen пишет: >>> From: John Crispin <john@phrozen.org> >>> >>> This enables basic bootup support for the Airoha EN7523 SoC. >>> >>> Signed-off-by: John Crispin <john@phrozen.org> >>> Signed-off-by: Bert Vermeulen <bert@biot.com> >>> --- >>> arch/arm/configs/multi_v7_defconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/arm/configs/multi_v7_defconfig >>> b/arch/arm/configs/multi_v7_defconfig >>> index d9abaae118dd..a9370a95dc38 100644 >>> --- a/arch/arm/configs/multi_v7_defconfig >>> +++ b/arch/arm/configs/multi_v7_defconfig >>> @@ -31,6 +31,7 @@ CONFIG_MACH_BERLIN_BG2=y >>> CONFIG_MACH_BERLIN_BG2CD=y >>> CONFIG_MACH_BERLIN_BG2Q=y >>> CONFIG_ARCH_DIGICOLOR=y >>> +CONFIG_ARCH_AIROHA=y >>> CONFIG_ARCH_EXYNOS=y >>> CONFIG_ARCH_HIGHBANK=y >>> CONFIG_ARCH_HISI=y >>> @@ -983,6 +984,7 @@ CONFIG_STAGING_BOARD=y >>> CONFIG_MFD_CROS_EC_DEV=m >>> CONFIG_CROS_EC_I2C=m >>> CONFIG_CROS_EC_SPI=m >>> +CONFIG_COMMON_CLK_EN7523=y >> >> If SoC doesn't work without clk support, then this option should be >> auto-selected by the arch option. >> >> It also doesn't look like upstream kernel has COMMON_CLK_EN7523 at all. > > Oops, you're right -- the clock driver is coming as soon as the base > system is in. I guess this option (under ARCH_AIROHA) should come in at > that time as well? I'll respin after some more comments. Probably. You may also make clk driver to use ARCH_AIROHA option directly if driver is supposed to be used only by that single arch, like some other platform do that.
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