Hello!
This patchset adds support for 32-bit Meson A1 board.
We describe device tree with following components:
CPU, GIC, IRQ, Timer, UART, PIN controller.
It's capable of booting up into the serial console.
We have tested this DTS and used drivers at our
32-bit Meson A1 board and it works correctly.
Alexey Romanov (3):
meson: pinctrl: use CONFIG_PINCTRL_A1 with CONFIG_ARM
firmware: meson: use CONFIG_MESON_SM with CONFIG_ARM
arch/arm: dts: introduce meson-a1 device tree
arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
drivers/firmware/meson/Kconfig | 2 +-
drivers/pinctrl/meson/Kconfig | 2 +-
3 files changed, 153 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/meson-a1.dtsi
--
2.38.1
Tested A1 pinctrl support for ARM and it works.
Signed-off-by: Alexey Romanov <[email protected]>
---
drivers/pinctrl/meson/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index 64fb9e074ac6..fad688cabd05 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -57,7 +57,7 @@ config PINCTRL_MESON_G12A
config PINCTRL_MESON_A1
tristate "Meson a1 Soc pinctrl driver"
- depends on ARM64
+ depends on ARM || ARM64
select PINCTRL_MESON_AXG_PMX
default y
--
2.38.1
Meson SM driver has one strong disturbing requirement.
It's size of the memory page, it should be equal to 4K.
ARM 32-bit arch always uses 4K page and doesn't support
bigger sizes. So it's not a stop factor.
Anyway, meson sm driver was tested in the meson-a1 ARM
board and it works correctly.
Signed-off-by: Alexey Romanov <[email protected]>
---
drivers/firmware/meson/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/meson/Kconfig b/drivers/firmware/meson/Kconfig
index f2fdd3756648..20303b7394fb 100644
--- a/drivers/firmware/meson/Kconfig
+++ b/drivers/firmware/meson/Kconfig
@@ -6,6 +6,6 @@ config MESON_SM
tristate "Amlogic Secure Monitor driver"
depends on ARCH_MESON || COMPILE_TEST
default y
- depends on ARM64_4K_PAGES
+ depends on ARM || ARM64_4K_PAGES
help
Say y here to enable the Amlogic secure monitor driver
--
2.38.1
Add basic support for the 32-bit Amlogic A1. This device tree
describes following compontents: CPU, GIC, IRQ, Timer, UART,
PIN controller. It's capable of booting up into
the serial console.
This is based on arm64 version of meson-a1.dtsi.
Signed-off-by: Alexey Romanov <[email protected]>
---
arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
1 file changed, 151 insertions(+)
create mode 100644 arch/arm/boot/dts/meson-a1.dtsi
diff --git a/arch/arm/boot/dts/meson-a1.dtsi b/arch/arm/boot/dts/meson-a1.dtsi
new file mode 100644
index 000000000000..1d900fe86f8e
--- /dev/null
+++ b/arch/arm/boot/dts/meson-a1.dtsi
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 SberDevices.
+ * Author: Alexey Romanov <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/gpio/meson-a1-gpio.h>
+
+/ {
+ compatible = "amlogic,a1";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ sm: secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ apb: bus@fe000000 {
+ compatible = "simple-bus";
+ reg = <0xfe000000 0x1000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xfe000000 0x1000000>;
+
+ reset: reset-controller@0 {
+ compatible = "amlogic,meson-a1-reset";
+ reg = <0x0 0x8c>;
+ #reset-cells = <1>;
+ };
+
+ periphs_pinctrl: pinctrl@400 {
+ compatible = "amlogic,meson-a1-periphs-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio: bank@400 {
+ reg = <0x0400 0x003c>,
+ <0x0480 0x0118>;
+ reg-names = "mux", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&periphs_pinctrl 0 0 62>;
+ };
+
+ };
+
+ uart_AO: serial@1c00 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x1c00 0x18>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_AO_B: serial@2000 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x2000 0x18>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ gpio_intc: interrupt-controller@0440 {
+ compatible = "amlogic,meson-a1-gpio-intc",
+ "amlogic,meson-gpio-intc";
+ reg = <0x0440 0x14>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ amlogic,channel-interrupts =
+ <49 50 51 52 53 54 55 56>;
+ };
+ };
+
+ gic: interrupt-controller@ff901000 {
+ compatible = "arm,gic-400";
+ reg = <0xff901000 0x1000>,
+ <0xff902000 0x2000>,
+ <0xff904000 0x2000>,
+ <0xff906000 0x2000>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
+};
--
2.38.1
On 22/02/2023 12:50, Alexey Romanov wrote:
> Add basic support for the 32-bit Amlogic A1. This device tree
Use subject prefixes matching the subsystem (which you can get for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching).
> describes following compontents: CPU, GIC, IRQ, Timer, UART,
> PIN controller. It's capable of booting up into
> the serial console.
>
> This is based on arm64 version of meson-a1.dtsi.
>
> Signed-off-by: Alexey Romanov <[email protected]>
> ---
> arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
There is such file and there is such DTS/hardware support. I don't see
any reason why entire DTSI should be duplicated. What's more, your
commit does not explain it - does not justify duplication.
Best regards,
Krzysztof
On 23/02/2023 10:08, Krzysztof Kozlowski wrote:
> On 22/02/2023 12:50, Alexey Romanov wrote:
>> Add basic support for the 32-bit Amlogic A1. This device tree
>
> Use subject prefixes matching the subsystem (which you can get for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching).
>
>> describes following compontents: CPU, GIC, IRQ, Timer, UART,
>> PIN controller. It's capable of booting up into
>> the serial console.
>>
>> This is based on arm64 version of meson-a1.dtsi.
>>
>> Signed-off-by: Alexey Romanov <[email protected]>
>> ---
>> arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
>
> There is such file and there is such DTS/hardware support. I don't see
> any reason why entire DTSI should be duplicated. What's more, your
> commit does not explain it - does not justify duplication.
One more comment - I think you just added dead code. It's
uncompilable/untestable. Otherwise, please share how to build this DTSI
without DTS.
Best regards,
Krzysztof
On 22/02/2023 12:50, Alexey Romanov wrote:
> Hello!
>
> This patchset adds support for 32-bit Meson A1 board.
Hi Alexev,
I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
of memory, but those processors are ARMv8 and the arm64 arch code
has been designed for those CPUs.
So far I didn't find a single good reason to add 32bit support for
ARMv8 Amlogic based SoCs, if you have a solid reason please share.
And as Krzysztof stated, the support is incomplete and cannot work
without a dts file.
Neil
> We describe device tree with following components:
> CPU, GIC, IRQ, Timer, UART, PIN controller.
> It's capable of booting up into the serial console.
>
> We have tested this DTS and used drivers at our
> 32-bit Meson A1 board and it works correctly.
>
> Alexey Romanov (3):
> meson: pinctrl: use CONFIG_PINCTRL_A1 with CONFIG_ARM
> firmware: meson: use CONFIG_MESON_SM with CONFIG_ARM
> arch/arm: dts: introduce meson-a1 device tree
>
> arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
> drivers/firmware/meson/Kconfig | 2 +-
> drivers/pinctrl/meson/Kconfig | 2 +-
> 3 files changed, 153 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/meson-a1.dtsi
>
Hello Neil!
On Mon, Feb 27, 2023 at 09:15:04AM +0100, [email protected] wrote:
[...]
> I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
> of memory, but those processors are ARMv8 and the arm64 arch code
> has been designed for those CPUs.
>
> So far I didn't find a single good reason to add 32bit support for
> ARMv8 Amlogic based SoCs, if you have a solid reason please share.
I totally agree with you, but I suppose it's fully related to 'big'
Amlogic SoC like S905_ or A311_ series. A113L (aka 'a1') is
a cost-efficient dual-core SoC which is used for small, cheap solutions
with cheap components. Every cent is important during BoM development.
That's why usually ODMs install small ROM and RAM capacity, and each
megabyte is important for RAM/ROM kernel and rootfs footprints.
Why am I talking about rootfs? For such small projects a good
choice is buildroot rootfs assembling framework. Unfortunatelly,
buildroot doesn't support 'compat' mode when kernel and userspace have
a different bitness. In the internal project, we save several
percents of ROM/RAM free space using 32-bit configuration (mostly rootfs
ROM space, to be honest). Therefore, for such 'little' cost-efficient
SoCs we can make an exception and support 32-bit configuration, from my
point of view.
What do you think about that?
>
> And as Krzysztof stated, the support is incomplete and cannot work
> without a dts file.
Agreed, we shouldn't merge dead code. But there are several question to
discuss there. Please check my reply to Krzysztof message.
[...]
--
Thank you,
Dmitry
Hello Krzysztof!
On Thu, Feb 23, 2023 at 10:09:25AM +0100, Krzysztof Kozlowski wrote:
[...]
> >> describes following compontents: CPU, GIC, IRQ, Timer, UART,
> >> PIN controller. It's capable of booting up into
> >> the serial console.
> >>
> >> This is based on arm64 version of meson-a1.dtsi.
> >>
> >> Signed-off-by: Alexey Romanov <[email protected]>
> >> ---
> >> arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
> >
> > There is such file and there is such DTS/hardware support. I don't see
> > any reason why entire DTSI should be duplicated. What's more, your
> > commit does not explain it - does not justify duplication.
>
> One more comment - I think you just added dead code. It's
> uncompilable/untestable. Otherwise, please share how to build this DTSI
> without DTS.
You are right, Alexey doesn't provide any exact *.dts file for any
board, and *.dtsi file should be included somewhere, otherwise this is
dead code.
Unfortunately, our internal board *.dts file is useless for kernel
community, cause there is not any chance to burn locally compiled kernel
to our product due to secureboot protection.
But I think there is one possible option. We have reference Amlogic
boards somewhere in the office. So we can test 32-bit configuration on
it and prepare proper *.dts file for that. What do you think, it
reasanoble?
--
Thank you,
Dmitry
On 27/02/2023 15:39, Dmitry Rokosov wrote:
> Hello Krzysztof!
>
> On Thu, Feb 23, 2023 at 10:09:25AM +0100, Krzysztof Kozlowski wrote:
>
> [...]
>
>>>> describes following compontents: CPU, GIC, IRQ, Timer, UART,
>>>> PIN controller. It's capable of booting up into
>>>> the serial console.
>>>>
>>>> This is based on arm64 version of meson-a1.dtsi.
>>>>
>>>> Signed-off-by: Alexey Romanov <[email protected]>
>>>> ---
>>>> arch/arm/boot/dts/meson-a1.dtsi | 151 ++++++++++++++++++++++++++++++++
>>>
>>> There is such file and there is such DTS/hardware support. I don't see
>>> any reason why entire DTSI should be duplicated. What's more, your
>>> commit does not explain it - does not justify duplication.
>>
>> One more comment - I think you just added dead code. It's
>> uncompilable/untestable. Otherwise, please share how to build this DTSI
>> without DTS.
>
> You are right, Alexey doesn't provide any exact *.dts file for any
> board, and *.dtsi file should be included somewhere, otherwise this is
> dead code.
> Unfortunately, our internal board *.dts file is useless for kernel
> community, cause there is not any chance to burn locally compiled kernel
> to our product due to secureboot protection.
> But I think there is one possible option. We have reference Amlogic
> boards somewhere in the office. So we can test 32-bit configuration on
> it and prepare proper *.dts file for that. What do you think, it
> reasanoble?
You just need to provide valid board which works in 32-bit mode. Anyway
duplicating DTSI is a no-go and we do not do it in other platforms.
Best regards,
Krzysztof
On 27/02/2023 15:28, Dmitry Rokosov wrote:
> Hello Neil!
>
> On Mon, Feb 27, 2023 at 09:15:04AM +0100, [email protected] wrote:
>
> [...]
>
>> I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
>> of memory, but those processors are ARMv8 and the arm64 arch code
>> has been designed for those CPUs.
>>
>> So far I didn't find a single good reason to add 32bit support for
>> ARMv8 Amlogic based SoCs, if you have a solid reason please share.
>
> I totally agree with you, but I suppose it's fully related to 'big'
> Amlogic SoC like S905_ or A311_ series. A113L (aka 'a1') is
> a cost-efficient dual-core SoC which is used for small, cheap solutions
> with cheap components. Every cent is important during BoM development.
> That's why usually ODMs install small ROM and RAM capacity, and each
> megabyte is important for RAM/ROM kernel and rootfs footprints.
Do you have figures ? is 32bit ARM kernel really lighter when ARM64 one is correctly configured ?
> Why am I talking about rootfs? For such small projects a good
> choice is buildroot rootfs assembling framework. Unfortunatelly,
> buildroot doesn't support 'compat' mode when kernel and userspace have
> a different bitness.
well this is a buildroot problem... the kernel itself is perfectly capable
of running an AArch32 userspace.
> In the internal project, we save several
> percents of ROM/RAM free space using 32-bit configuration (mostly rootfs
> ROM space, to be honest). Therefore, for such 'little' cost-efficient
> SoCs we can make an exception and support 32-bit configuration, from my
> point of view.
32bit ARM is now "legacy", I would need to have an advice from the ARM SoC
maintainers, but AFAIK new ARMv8 SoCs should stay in arm64 arch.
Arnd ? Olof ? do you have an opinion on this ?
>
> What do you think about that?
>>
>> And as Krzysztof stated, the support is incomplete and cannot work
>> without a dts file.
>
> Agreed, we shouldn't merge dead code. But there are several question to
> discuss there. Please check my reply to Krzysztof message.
>
> [...]
>
On Mon, Feb 27, 2023, at 15:28, Dmitry Rokosov wrote:
> Hello Neil!
>
> On Mon, Feb 27, 2023 at 09:15:04AM +0100, [email protected] wrote:
>
> [...]
>
>> I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
>> of memory, but those processors are ARMv8 and the arm64 arch code
>> has been designed for those CPUs.
>>
>> So far I didn't find a single good reason to add 32bit support for
>> ARMv8 Amlogic based SoCs, if you have a solid reason please share.
>
> I totally agree with you, but I suppose it's fully related to 'big'
> Amlogic SoC like S905_ or A311_ series. A113L (aka 'a1') is
> a cost-efficient dual-core SoC which is used for small, cheap solutions
> with cheap components. Every cent is important during BoM development.
> That's why usually ODMs install small ROM and RAM capacity, and each
> megabyte is important for RAM/ROM kernel and rootfs footprints.
> Why am I talking about rootfs? For such small projects a good
> choice is buildroot rootfs assembling framework. Unfortunatelly,
> buildroot doesn't support 'compat' mode when kernel and userspace have
> a different bitness. In the internal project, we save several
> percents of ROM/RAM free space using 32-bit configuration (mostly rootfs
> ROM space, to be honest). Therefore, for such 'little' cost-efficient
> SoCs we can make an exception and support 32-bit configuration, from my
> point of view.
>
> What do you think about that?
I would argue that is a problem with buildroot, and using a 32-bit
kernel is not something we should encourage over fixing buildroot
to do it right, or building the kernel separately from the rootfs.
We do allow building support for a couple of ARMv8 SoCs in 32-bit
mode, but that is usually because they ship with a 32-bit bootrom
and cannot actually run a 64-bit kernel.
The overhead of running a 64-bit kernel is usually a few megabytes
compared to a 32-bit kernel, to store the larger kernel .text/.data
segments, per-thread stack and page tables as well as 'page',
and 'inode' structures. I see that A1 only supports DDR3 and DDR4
memory, so I assume that there are always at least 128MB
of total RAM available, or 512MB for the most cost-effective
size with a single memory chip.
My feeling is that for the 256MB configuration, it is very hard to
argue for a 32-bit kernel because of the countless downsides,
and even for the 128MB configuration, I would still try to avoid
it out of principle.
Arnd
Hello Arnd,
On Mon, Feb 27, 2023 at 03:58:50PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 15:28, Dmitry Rokosov wrote:
> > Hello Neil!
> >
> > On Mon, Feb 27, 2023 at 09:15:04AM +0100, [email protected] wrote:
> >
> > [...]
> >
> >> I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
> >> of memory, but those processors are ARMv8 and the arm64 arch code
> >> has been designed for those CPUs.
> >>
> >> So far I didn't find a single good reason to add 32bit support for
> >> ARMv8 Amlogic based SoCs, if you have a solid reason please share.
> >
> > I totally agree with you, but I suppose it's fully related to 'big'
> > Amlogic SoC like S905_ or A311_ series. A113L (aka 'a1') is
> > a cost-efficient dual-core SoC which is used for small, cheap solutions
> > with cheap components. Every cent is important during BoM development.
> > That's why usually ODMs install small ROM and RAM capacity, and each
> > megabyte is important for RAM/ROM kernel and rootfs footprints.
> > Why am I talking about rootfs? For such small projects a good
> > choice is buildroot rootfs assembling framework. Unfortunatelly,
> > buildroot doesn't support 'compat' mode when kernel and userspace have
> > a different bitness. In the internal project, we save several
> > percents of ROM/RAM free space using 32-bit configuration (mostly rootfs
> > ROM space, to be honest). Therefore, for such 'little' cost-efficient
> > SoCs we can make an exception and support 32-bit configuration, from my
> > point of view.
> >
> > What do you think about that?
>
> I would argue that is a problem with buildroot, and using a 32-bit
> kernel is not something we should encourage over fixing buildroot
> to do it right, or building the kernel separately from the rootfs.
>
> We do allow building support for a couple of ARMv8 SoCs in 32-bit
> mode, but that is usually because they ship with a 32-bit bootrom
> and cannot actually run a 64-bit kernel.
To be honest, I didn't know about this principle. It looks like a very
rational approach "start from max supported bitness".
Based on overall maintainers opinion, we have to prepare a patch for
buildroot to support compat mode :)
[...]
--
Thank you,
Dmitry
On Mon, Feb 27, 2023 at 03:46:50PM +0100, [email protected] wrote:
> On 27/02/2023 15:28, Dmitry Rokosov wrote:
> > Hello Neil!
> >
> > On Mon, Feb 27, 2023 at 09:15:04AM +0100, [email protected] wrote:
> >
> > [...]
> >
> > > I'm aware Amlogic also runs their kernel as 32bit to gain a few kbytes
> > > of memory, but those processors are ARMv8 and the arm64 arch code
> > > has been designed for those CPUs.
> > >
> > > So far I didn't find a single good reason to add 32bit support for
> > > ARMv8 Amlogic based SoCs, if you have a solid reason please share.
> >
> > I totally agree with you, but I suppose it's fully related to 'big'
> > Amlogic SoC like S905_ or A311_ series. A113L (aka 'a1') is
> > a cost-efficient dual-core SoC which is used for small, cheap solutions
> > with cheap components. Every cent is important during BoM development.
> > That's why usually ODMs install small ROM and RAM capacity, and each
> > megabyte is important for RAM/ROM kernel and rootfs footprints.
>
> Do you have figures ? is 32bit ARM kernel really lighter when ARM64 one is correctly configured ?
As I mentioned in the previous message, we have reached good results for
userspace profile. For the kernel, we have disabled heavy cost memory
features (like dynamic tracing) at both configurations, and get more or
less the same results for memory footprint (pre-allocated for kernel
sections).
I can provide rootfs figures/results, but I'm afraid it's so workload
dependent and very custom for us.
>
> > Why am I talking about rootfs? For such small projects a good
> > choice is buildroot rootfs assembling framework. Unfortunatelly,
> > buildroot doesn't support 'compat' mode when kernel and userspace have
> > a different bitness.
>
> well this is a buildroot problem... the kernel itself is perfectly capable
> of running an AArch32 userspace.
Based on your and Arnd arguments, agree, this is a buildroot problem
with compat mode definition.
Buildroot must have it for such configurations with mainline kernel.
[...]
--
Thank you,
Dmitry
On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
> On Mon, Feb 27, 2023 at 03:58:50PM +0100, Arnd Bergmann wrote:
>>
>> I would argue that is a problem with buildroot, and using a 32-bit
>> kernel is not something we should encourage over fixing buildroot
>> to do it right, or building the kernel separately from the rootfs.
>>
>> We do allow building support for a couple of ARMv8 SoCs in 32-bit
>> mode, but that is usually because they ship with a 32-bit bootrom
>> and cannot actually run a 64-bit kernel.
>
> To be honest, I didn't know about this principle. It looks like a very
> rational approach "start from max supported bitness".
> Based on overall maintainers opinion, we have to prepare a patch for
> buildroot to support compat mode :)
That would be great, thanks a lot!
For what it's worth, the main arguments in favor of running a 64-bit
kernel with compat user space over a 32-bit kernel are support for:
- larger RAM sizes without highmem (most 32-bit kernels only
support 768MB of lowmem, and highmem sucks)
- larger virtual address space (4GB vs 3GB or less)
- CPU specific errata workarounds (arch/arm/ only has those for 32-bit cpus)
- mitigations for common attacks such as spectre
- security hardening that depends on larger address space
(KASLR, BTI, ptrauth, PAN, ...)
- emulating instructions that were removed in Armv8 (setend, swp, ...)
Most of these don't apply in userspace, so the incentive to
run smaller 32-bit userland on systems with less than 1GB of
RAM usually outweighs the benefits of 64-bit userspace.
Arnd
On Mon, Feb 27, 2023 at 05:15:58PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
> > On Mon, Feb 27, 2023 at 03:58:50PM +0100, Arnd Bergmann wrote:
> >>
> >> I would argue that is a problem with buildroot, and using a 32-bit
> >> kernel is not something we should encourage over fixing buildroot
> >> to do it right, or building the kernel separately from the rootfs.
> >>
> >> We do allow building support for a couple of ARMv8 SoCs in 32-bit
> >> mode, but that is usually because they ship with a 32-bit bootrom
> >> and cannot actually run a 64-bit kernel.
> >
> > To be honest, I didn't know about this principle. It looks like a very
> > rational approach "start from max supported bitness".
> > Based on overall maintainers opinion, we have to prepare a patch for
> > buildroot to support compat mode :)
>
> That would be great, thanks a lot!
>
> For what it's worth, the main arguments in favor of running a 64-bit
> kernel with compat user space over a 32-bit kernel are support for:
>
> - larger RAM sizes without highmem (most 32-bit kernels only
> support 768MB of lowmem, and highmem sucks)
> - larger virtual address space (4GB vs 3GB or less)
> - CPU specific errata workarounds (arch/arm/ only has those for 32-bit cpus)
> - mitigations for common attacks such as spectre
> - security hardening that depends on larger address space
> (KASLR, BTI, ptrauth, PAN, ...)
> - emulating instructions that were removed in Armv8 (setend, swp, ...)
>
> Most of these don't apply in userspace, so the incentive to
> run smaller 32-bit userland on systems with less than 1GB of
> RAM usually outweighs the benefits of 64-bit userspace.
Thank you very for the detailed clarification! It's strong arguments.
--
Thank you,
Dmitry
On 27/02/2023 17:15, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
>> On Mon, Feb 27, 2023 at 03:58:50PM +0100, Arnd Bergmann wrote:
>>>
>>> I would argue that is a problem with buildroot, and using a 32-bit
>>> kernel is not something we should encourage over fixing buildroot
>>> to do it right, or building the kernel separately from the rootfs.
>>>
>>> We do allow building support for a couple of ARMv8 SoCs in 32-bit
>>> mode, but that is usually because they ship with a 32-bit bootrom
>>> and cannot actually run a 64-bit kernel.
>>
>> To be honest, I didn't know about this principle. It looks like a very
>> rational approach "start from max supported bitness".
>> Based on overall maintainers opinion, we have to prepare a patch for
>> buildroot to support compat mode :)
>
> That would be great, thanks a lot!
>
> For what it's worth, the main arguments in favor of running a 64-bit
> kernel with compat user space over a 32-bit kernel are support for:
>
> - larger RAM sizes without highmem (most 32-bit kernels only
> support 768MB of lowmem, and highmem sucks)
> - larger virtual address space (4GB vs 3GB or less)
> - CPU specific errata workarounds (arch/arm/ only has those for 32-bit cpus)
> - mitigations for common attacks such as spectre
> - security hardening that depends on larger address space
> (KASLR, BTI, ptrauth, PAN, ...)
> - emulating instructions that were removed in Armv8 (setend, swp, ...)
>
> Most of these don't apply in userspace, so the incentive to
> run smaller 32-bit userland on systems with less than 1GB of
> RAM usually outweighs the benefits of 64-bit userspace.
Thanks for the details!
Neil
>
> Arnd
On Mon, Feb 27, 2023 at 05:38:49PM +0100, Neil Armstrong wrote:
> On 27/02/2023 17:15, Arnd Bergmann wrote:
> > On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
> > > On Mon, Feb 27, 2023 at 03:58:50PM +0100, Arnd Bergmann wrote:
> > > >
> > > > I would argue that is a problem with buildroot, and using a 32-bit
> > > > kernel is not something we should encourage over fixing buildroot
> > > > to do it right, or building the kernel separately from the rootfs.
> > > >
> > > > We do allow building support for a couple of ARMv8 SoCs in 32-bit
> > > > mode, but that is usually because they ship with a 32-bit bootrom
> > > > and cannot actually run a 64-bit kernel.
> > >
> > > To be honest, I didn't know about this principle. It looks like a very
> > > rational approach "start from max supported bitness".
> > > Based on overall maintainers opinion, we have to prepare a patch for
> > > buildroot to support compat mode :)
> >
> > That would be great, thanks a lot!
> >
> > For what it's worth, the main arguments in favor of running a 64-bit
> > kernel with compat user space over a 32-bit kernel are support for:
> >
> > - larger RAM sizes without highmem (most 32-bit kernels only
> > support 768MB of lowmem, and highmem sucks)
> > - larger virtual address space (4GB vs 3GB or less)
> > - CPU specific errata workarounds (arch/arm/ only has those for 32-bit cpus)
> > - mitigations for common attacks such as spectre
> > - security hardening that depends on larger address space
> > (KASLR, BTI, ptrauth, PAN, ...)
> > - emulating instructions that were removed in Armv8 (setend, swp, ...)
> >
> > Most of these don't apply in userspace, so the incentive to
> > run smaller 32-bit userland on systems with less than 1GB of
> > RAM usually outweighs the benefits of 64-bit userspace.
>
> Thanks for the details!
Looks like Thomas has already prepared a basic patch series for buildroot,
but maintainers declined it.
https://lore.kernel.org/all/20220730194331.GA2515056@scaer/
--
Thank you,
Dmitry
On Mon, Feb 27, 2023, at 17:50, Dmitry Rokosov wrote:
> On Mon, Feb 27, 2023 at 05:38:49PM +0100, Neil Armstrong wrote:
>> On 27/02/2023 17:15, Arnd Bergmann wrote:
>> > On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
>> >
>> > Most of these don't apply in userspace, so the incentive to
>> > run smaller 32-bit userland on systems with less than 1GB of
>> > RAM usually outweighs the benefits of 64-bit userspace.
>>
>> Thanks for the details!
>
> Looks like Thomas has already prepared a basic patch series for buildroot,
> but maintainers declined it.
>
> https://lore.kernel.org/all/20220730194331.GA2515056@scaer/
I see. I know very little about buildroot, but it sounds like
there are other ways of doing the same thing here. In general,
this is pretty much an Arm specific problem. While you clearly
want compat mode for small userland on any architecture but don't
want 32-bit kernels, arm is the only one that has a different
kernel "ARCH=" value and needs a separate gcc toolchain.
If the problem is only the toolchain, an easy way out may
be to use clang instead of gcc as your compiler, as a single
clang binary can target both 32-bit userland and 64-bit kernel
on all supported architectures.
Arnd
On Mon, Feb 27, 2023 at 07:19:38PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 17:50, Dmitry Rokosov wrote:
> > On Mon, Feb 27, 2023 at 05:38:49PM +0100, Neil Armstrong wrote:
> >> On 27/02/2023 17:15, Arnd Bergmann wrote:
> >> > On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
> >> >
> >> > Most of these don't apply in userspace, so the incentive to
> >> > run smaller 32-bit userland on systems with less than 1GB of
> >> > RAM usually outweighs the benefits of 64-bit userspace.
> >>
> >> Thanks for the details!
> >
> > Looks like Thomas has already prepared a basic patch series for buildroot,
> > but maintainers declined it.
> >
> > https://lore.kernel.org/all/20220730194331.GA2515056@scaer/
>
> I see. I know very little about buildroot, but it sounds like
> there are other ways of doing the same thing here. In general,
> this is pretty much an Arm specific problem. While you clearly
> want compat mode for small userland on any architecture but don't
> want 32-bit kernels, arm is the only one that has a different
> kernel "ARCH=" value and needs a separate gcc toolchain.
>
> If the problem is only the toolchain, an easy way out may
> be to use clang instead of gcc as your compiler, as a single
> clang binary can target both 32-bit userland and 64-bit kernel
> on all supported architectures.
Agreed with you. We will try different local approaches to support
compat build configurations. For now, prebuilt toolchain (buildroot make
sdk goal) is best way from my point of view. Anyway, we will try to
solve this problem in the our sandbox and stay on the 64-bit kernel.
Thank you for all the helpful details you shared, appreciate it!
--
Thank you,
Dmitry
On Wed, Feb 22, 2023 at 12:50 PM Alexey Romanov
<[email protected]> wrote:
> Tested A1 pinctrl support for ARM and it works.
>
> Signed-off-by: Alexey Romanov <[email protected]>
This patch applied to the pinctrl tree for v6.4.
Have you considered also adding || COMPILE_TEST?
Or does that break builds?
Yours,
Linus Walleij
Hi Linus,
On 06/03/2023 14:45, Linus Walleij wrote:
> On Wed, Feb 22, 2023 at 12:50 PM Alexey Romanov
> <[email protected]> wrote:
>
>> Tested A1 pinctrl support for ARM and it works.
>>
>> Signed-off-by: Alexey Romanov <[email protected]>
>
> This patch applied to the pinctrl tree for v6.4.
Erf, this serie is something we would avoid, so no need to apply it for v6.4
>
> Have you considered also adding || COMPILE_TEST?
It would be great to have || COMPILE_TEST for sure
Neil
>
> Or does that break builds?
>
> Yours,
> Linus Walleij
On Mon, Mar 6, 2023 at 2:49 PM <[email protected]> wrote:
> On 06/03/2023 14:45, Linus Walleij wrote:
> > On Wed, Feb 22, 2023 at 12:50 PM Alexey Romanov
> > <[email protected]> wrote:
> >
> >> Tested A1 pinctrl support for ARM and it works.
> >>
> >> Signed-off-by: Alexey Romanov <[email protected]>
> >
> > This patch applied to the pinctrl tree for v6.4.
>
> Erf, this serie is something we would avoid, so no need to apply it for v6.4
OK I take that as "Neil says NACK" and backed out the patch.
Yours,
Linus Walleij
Dmitry Rokosov <[email protected]> writes:
> On Mon, Feb 27, 2023 at 07:19:38PM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 27, 2023, at 17:50, Dmitry Rokosov wrote:
>> > On Mon, Feb 27, 2023 at 05:38:49PM +0100, Neil Armstrong wrote:
>> >> On 27/02/2023 17:15, Arnd Bergmann wrote:
>> >> > On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
>> >> >
>> >> > Most of these don't apply in userspace, so the incentive to
>> >> > run smaller 32-bit userland on systems with less than 1GB of
>> >> > RAM usually outweighs the benefits of 64-bit userspace.
>> >>
>> >> Thanks for the details!
>> >
>> > Looks like Thomas has already prepared a basic patch series for buildroot,
>> > but maintainers declined it.
>> >
>> > https://lore.kernel.org/all/20220730194331.GA2515056@scaer/
>>
>> I see. I know very little about buildroot, but it sounds like
>> there are other ways of doing the same thing here. In general,
>> this is pretty much an Arm specific problem. While you clearly
>> want compat mode for small userland on any architecture but don't
>> want 32-bit kernels, arm is the only one that has a different
>> kernel "ARCH=" value and needs a separate gcc toolchain.
>>
>> If the problem is only the toolchain, an easy way out may
>> be to use clang instead of gcc as your compiler, as a single
>> clang binary can target both 32-bit userland and 64-bit kernel
>> on all supported architectures.
>
> Agreed with you. We will try different local approaches to support
> compat build configurations. For now, prebuilt toolchain (buildroot make
> sdk goal) is best way from my point of view. Anyway, we will try to
> solve this problem in the our sandbox and stay on the 64-bit kernel.
> Thank you for all the helpful details you shared, appreciate it!
Just to clarify one thing...
More specifically, this is a buildroot *build system* problem. If you
build the kernel separately from the rootfs, it works fine.
I use 32-bit buildroot (and debian) rootfs images all the time on
Amlogic SoCs with 64-bit kernels and it works fine.
Kevin
Hello Kevin,
On Thu, Mar 09, 2023 at 01:52:41PM -0800, Kevin Hilman wrote:
> Dmitry Rokosov <[email protected]> writes:
>
> > On Mon, Feb 27, 2023 at 07:19:38PM +0100, Arnd Bergmann wrote:
> >> On Mon, Feb 27, 2023, at 17:50, Dmitry Rokosov wrote:
> >> > On Mon, Feb 27, 2023 at 05:38:49PM +0100, Neil Armstrong wrote:
> >> >> On 27/02/2023 17:15, Arnd Bergmann wrote:
> >> >> > On Mon, Feb 27, 2023, at 16:51, Dmitry Rokosov wrote:
> >> >> >
> >> >> > Most of these don't apply in userspace, so the incentive to
> >> >> > run smaller 32-bit userland on systems with less than 1GB of
> >> >> > RAM usually outweighs the benefits of 64-bit userspace.
> >> >>
> >> >> Thanks for the details!
> >> >
> >> > Looks like Thomas has already prepared a basic patch series for buildroot,
> >> > but maintainers declined it.
> >> >
> >> > https://lore.kernel.org/all/20220730194331.GA2515056@scaer/
> >>
> >> I see. I know very little about buildroot, but it sounds like
> >> there are other ways of doing the same thing here. In general,
> >> this is pretty much an Arm specific problem. While you clearly
> >> want compat mode for small userland on any architecture but don't
> >> want 32-bit kernels, arm is the only one that has a different
> >> kernel "ARCH=" value and needs a separate gcc toolchain.
> >>
> >> If the problem is only the toolchain, an easy way out may
> >> be to use clang instead of gcc as your compiler, as a single
> >> clang binary can target both 32-bit userland and 64-bit kernel
> >> on all supported architectures.
> >
> > Agreed with you. We will try different local approaches to support
> > compat build configurations. For now, prebuilt toolchain (buildroot make
> > sdk goal) is best way from my point of view. Anyway, we will try to
> > solve this problem in the our sandbox and stay on the 64-bit kernel.
> > Thank you for all the helpful details you shared, appreciate it!
>
> Just to clarify one thing...
>
> More specifically, this is a buildroot *build system* problem. If you
> build the kernel separately from the rootfs, it works fine.
>
> I use 32-bit buildroot (and debian) rootfs images all the time on
> Amlogic SoCs with 64-bit kernels and it works fine.
You are totally right. It's one of the possible ways. But in the our
internal project we build kernel + roofs + uboot together in the one
buildroot project ('repo' based). So we will try to stay in the such
paradigm, but will use multi-arch toolchain, maybe.
Anyway, thanks a lot for sharing your experience.
--
Thank you,
Dmitry