Skip to contentSkip to conversation

ARM: shmobile: Per-board memory size fixups

PATCH New Magnus Damm 3 participants 14 messages Jun 5, 2013 – Jun 10, 2013

Subsystems (4)
lore
Share & tools
lore

Magnus Damm

author maintainer
#0 lore raw

cover ARM: shmobile: Per-board memory size fixups

ARM: shmobile: Per-board memory size fixups

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper [PATCH 02/06] ARM: shmobile: AG5EVM memory config via ATAGS fixup [PATCH 03/06] ARM: shmobile: AP4EVB memory config via ATAGS fixup [PATCH 04/06] ARM: shmobile: Bonito memory config via ATAGS fixup [PATCH 05/06] ARM: shmobile: Kota2 memory config via ATAGS fixup [PATCH 06/06] ARM: shmobile: Marzen memory config via ATAGS fixup

This series adds memory size and base address fixups to non-DT mach-shmobile boards. This way the ATAGS code in arch/arm/kernel/atags_parse.c can be overriden on a per- board basis without the need of any global MEM_SIZE or PHYS_OFFSET settings.

This is one of several series of code that reworks code not to rely on CONFIG_MEMORY_START/SIZE which in turn is needed for ARCH_MULTIPLATFORM.

---

Written against renesas.git renesas-next-20130604v2

 arch/arm/mach-shmobile/Kconfig               |    5 +++++
 arch/arm/mach-shmobile/board-ag5evm.c        |    4 ++++
 arch/arm/mach-shmobile/board-ap4evb.c        |    3 +++
 arch/arm/mach-shmobile/board-bonito.c        |    4 ++++
 arch/arm/mach-shmobile/board-kota2.c         |    4 ++++
 arch/arm/mach-shmobile/board-marzen.c        |    4 ++++
 arch/arm/mach-shmobile/include/mach/common.h |   13 +++++++++++++
 7 files changed, 37 insertions(+)
author maintainer
#1 lore raw

cover ARM: shmobile: Per-board memory size fixups

Quoted 8 lines · Magnus Damm

ARM: shmobile: Per-board memory size fixups

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper [PATCH 02/06] ARM: shmobile: AG5EVM memory config via ATAGS fixup [PATCH 03/06] ARM: shmobile: AP4EVB memory config via ATAGS fixup [PATCH 04/06] ARM: shmobile: Bonito memory config via ATAGS fixup [PATCH 05/06] ARM: shmobile: Kota2 memory config via ATAGS fixup [PATCH 06/06] ARM: shmobile: Marzen memory config via ATAGS fixup

Oh, ok, the above turned out to be an old version of the patch names. Before I cause more confusion, the patch names are supposed to be like this:

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper [PATCH 02/06] ARM: shmobile: AG5EVM memory size fixup [PATCH 03/06] ARM: shmobile: AP4EVB memory size fixup [PATCH 04/06] ARM: shmobile: Bonito memory size fixup [PATCH 05/06] ARM: shmobile: Kota2 memory size fixup [PATCH 06/06] ARM: shmobile: Marzen memory size fixup

Thanks,

/ magnus

author maintainer
#2 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Introduce SHMOBILE_FIXUP() as a helper function to allow boards to specify their memory base and size.

---

 arch/arm/mach-shmobile/include/mach/common.h |   13 +++++++++++++
 1 file changed, 13 insertions(+)
arch/arm/mach-shmobile/include/mach/common.h +13 -0
@@ -37,4 +37,17 @@ static inline void __init shmobile_init_
 	shmobile_cpuidle_init();
 }
 
+#define SHMOBILE_FIXUP(boardname, mem_start, mem_size)			\
+static void __init boardname##_fixup(struct tag *tag, char **cmdline,	\
+				struct meminfo *mi)			\
+{									\
+	for (; tag->hdr.size; tag = tag_next(tag)) {			\
+		if (tag->hdr.tag == ATAG_MEM) {				\
+			tag->u.mem.start = (mem_start);			\
+			tag->u.mem.size = (mem_size);			\
+			break;						\
+		}							\
+	}								\
+}
+
 #endif /* __ARCH_MACH_COMMON_H */
#3 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Quoted 4 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Introduce SHMOBILE_FIXUP() as a helper function to allow boards to specify their memory base and size.

No. I really don't like this idea (we've had people doing this in the past and I went around removing all that crap, and adding command line options into the defconfig files for those boards.)

I also fail to understand why in 2013, some 11 years after ATAG stuff was created, people _still_ can't get pass correct information into the kernel.

It's exactly this kind of issue which makes me believe that stuff like ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem constantly crops up time and time again. People have seem to have this total inability to get the pre-kernel environment right.

author maintainer
#4 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Hi Russell,

Quoted 10 lines · Russell King - ARM Linux
Quoted 4 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Introduce SHMOBILE_FIXUP() as a helper function to allow boards to specify their memory base and size.

No. I really don't like this idea (we've had people doing this in the past and I went around removing all that crap, and adding command line options into the defconfig files for those boards.)

Quoted 8 lines

I also fail to understand why in 2013, some 11 years after ATAG stuff was created, people _still_ can't get pass correct information into the kernel.

It's exactly this kind of issue which makes me believe that stuff like ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem constantly crops up time and time again. People have seem to have this total inability to get the pre-kernel environment right.

Thanks for your comments. As you probably saw in patch 00/06, the goal with this series is to remove CONFIG_MEMORY_START/SIZE from mach-shmobile.

I myself am quite happy to keep on using the kernel configuration to describe the main memory window like today, this is exactly how we used to do it on SH as well. What is a bit difficult is that we for mach-shmobile are requested to consolidate the kernel configurations and move to CONFIG_MULTIPLATFORM.

My main concern is that I'd like to keep per-board memory configuration somewhere, just removing it seems like a regression in usefulness to me. Do you have any recommendation for me how to proceed?

Thanks,

/ magnus

#5 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Quoted 10 lines · Magnus Damm

Thanks for your comments. As you probably saw in patch 00/06, the goal with this series is to remove CONFIG_MEMORY_START/SIZE from mach-shmobile.

I myself am quite happy to keep on using the kernel configuration to describe the main memory window like today, this is exactly how we used to do it on SH as well. What is a bit difficult is that we for mach-shmobile are requested to consolidate the kernel configurations and move to CONFIG_MULTIPLATFORM.

Quoted 4 lines

My main concern is that I'd like to keep per-board memory configuration somewhere, just removing it seems like a regression in usefulness to me. Do you have any recommendation for me how to proceed?

Actually I think with an appended DTB file, you should be able to pass the correct memory configuration per board just like everyone else, even when booting directly from mask ROM. I understand that you still have a long way to go before you can go DT-only for all shmobile SoCs, so what we need is a way to bridge the mid-term where you want to support that boot method on SoCs with incomplete or missing DT support.

The easiest way is probably to declare that multiplatform booting on shmobile is only supported for DT-enabled boards and that support for non-DT booting will be removed at the same time as non-multiplatform booting on shmobile. This is the same thing we are doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP) chips. The time line for this not set yet, and I think that will be one of the hot topics at this year's ARM subarch maintainer summit that I hope we will have the chance to do during the kernel summit. FWIW, my take on this is that at some point we will require both DT and multiplatform for all ARMv6 and ARMv7 platforms anyway (not for the older ones, in particular StrongARM and XScale), but we have to come up with a timing that works for everyone.

Arnd

author maintainer
#6 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Hi Arnd,

Quoted 16 lines · Arnd Bergmann
Quoted 10 lines · Magnus Damm

Thanks for your comments. As you probably saw in patch 00/06, the goal with this series is to remove CONFIG_MEMORY_START/SIZE from mach-shmobile.

I myself am quite happy to keep on using the kernel configuration to describe the main memory window like today, this is exactly how we used to do it on SH as well. What is a bit difficult is that we for mach-shmobile are requested to consolidate the kernel configurations and move to CONFIG_MULTIPLATFORM.

Quoted 4 lines

My main concern is that I'd like to keep per-board memory configuration somewhere, just removing it seems like a regression in usefulness to me. Do you have any recommendation for me how to proceed?

Quoted 7 lines

Actually I think with an appended DTB file, you should be able to pass the correct memory configuration per board just like everyone else, even when booting directly from mask ROM. I understand that you still have a long way to go before you can go DT-only for all shmobile SoCs, so what we need is a way to bridge the mid-term where you want to support that boot method on SoCs with incomplete or missing DT support.

The only two boards where we today boot from the reset vector and actually need to provide this information to the kernel are Mackerel and AP4EVB.

My approach with this series was more to make sure all boards keep on working regardless what their boot loader pass. This since I too do not trust the boot loader - especially on older boards. Perhaps the more acceptable approach is to pretend to start trusting the information by the boot loader and deal with the fallout if that happens. Things may break when removing CONFIG_MEMORY_START/SIZE since the MEM_SIZE and PHYS_OFFSET change in arch/arm/kernel/atags_parse.c

Anyway I can update my romImage series so it uses appended DTB with both AP4EVB and Mackerel. Then this series can simply be thrown away.

Quoted 4 lines

The easiest way is probably to declare that multiplatform booting on shmobile is only supported for DT-enabled boards and that support for non-DT booting will be removed at the same time as non-multiplatform booting on shmobile. This is the same thing we are

Quoted 8 lines

doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP) chips. The time line for this not set yet, and I think that will be one of the hot topics at this year's ARM subarch maintainer summit that I hope we will have the chance to do during the kernel summit. FWIW, my take on this is that at some point we will require both DT and multiplatform for all ARMv6 and ARMv7 platforms anyway (not for the older ones, in particular StrongARM and XScale), but we have to come up with a timing that works for everyone.

Yeah, I agree with your idea but I wonder about the timing. Actually, I was thinking that the prime candidate boards for multiplatform are our DT -reference boards. Still blocked on common clock framework though... I will try to sort out the memory bits first.

Thanks,

/ magnus

#7 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Quoted 11 lines · Magnus Damm
Quoted 1 line · Arnd Bergmann

On Thursday 06 June 2013, Magnus Damm wrote:

My approach with this series was more to make sure all boards keep on working regardless what their boot loader pass. This since I too do not trust the boot loader - especially on older boards. Perhaps the more acceptable approach is to pretend to start trusting the information by the boot loader and deal with the fallout if that happens. Things may break when removing CONFIG_MEMORY_START/SIZE since the MEM_SIZE and PHYS_OFFSET change in arch/arm/kernel/atags_parse.c

Quoted 2 lines

Anyway I can update my romImage series so it uses appended DTB with both AP4EVB and Mackerel. Then this series can simply be thrown away.

That sounds like a good idea, but it seems that AP4EVB does not yet use DT_MACHINE_START, so I suspect you will need more work.

Quoted 13 lines
Quoted 4 lines

The easiest way is probably to declare that multiplatform booting on shmobile is only supported for DT-enabled boards and that support for non-DT booting will be removed at the same time as non-multiplatform booting on shmobile. This is the same thing we are

Quoted 8 lines

doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP) chips. The time line for this not set yet, and I think that will be one of the hot topics at this year's ARM subarch maintainer summit that I hope we will have the chance to do during the kernel summit. FWIW, my take on this is that at some point we will require both DT and multiplatform for all ARMv6 and ARMv7 platforms anyway (not for the older ones, in particular StrongARM and XScale), but we have to come up with a timing that works for everyone.

Quoted 4 lines

Yeah, I agree with your idea but I wonder about the timing. Actually, I was thinking that the prime candidate boards for multiplatform are our DT -reference boards. Still blocked on common clock framework though... I will try to sort out the memory bits first.

Ok.

Arnd

#8 lore raw

PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

In reply to Russell King - ARM Linux
Quoted 10 lines · Russell King - ARM Linux
Quoted 4 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Introduce SHMOBILE_FIXUP() as a helper function to allow boards to specify their memory base and size.

No. I really don't like this idea (we've had people doing this in the past and I went around removing all that crap, and adding command line options into the defconfig files for those boards.)

Quoted 8 lines

I also fail to understand why in 2013, some 11 years after ATAG stuff was created, people still can't get pass correct information into the kernel.

It's exactly this kind of issue which makes me believe that stuff like ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem constantly crops up time and time again. People have seem to have this total inability to get the pre-kernel environment right.

I think the problem in this case is that the pre-boot environment is essentially nothing but mask rom jumping into head-shmobile.S, which is something nobody else does.

My understanding is that you can also put a regular u-boot, kexec or some other boot loader into the same place and get a running system with correct ATAGS or DT information.

It's debatable whether booting the kernel directly without an upgradable boot loader is a good idea, but since Renesas have come to depend on this and it's been supported by Linux for ages (both on ARM and SH), I would certainly not ask them to remove support for that.

What I think we can do however is move all that configuration into one place of the kernel that is fairly separate from everything else. head-shmobile.S already contains most of the special case, so how about adding a configuration option that enables both the head-shmobile.S code and contains the configuration for that in a submenu?

Arnd

author maintainer
#9 lore raw

PATCH 2/6 ARM: shmobile: AG5EVM memory size fixup

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Specify the AG5EVM memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-ag5evm.c |    4 ++++
 2 files changed, 5 insertions(+)
arch/arm/mach-shmobile/Kconfig +1 -0
@@ -92,6 +92,7 @@ endchoice
 config MACH_AG5EVM
 	bool "AG5EVM board"
 	depends on ARCH_SH73A0
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
arch/arm/mach-shmobile/board-ag5evm.c +4 -0
@@ -53,6 +53,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Dummy supplies, where voltage doesn't matter */
@@ -660,7 +661,10 @@ static void __init ag5evm_init(void)
 	platform_add_devices(ag5evm_devices, ARRAY_SIZE(ag5evm_devices));
 }
 
+SHMOBILE_FIXUP(ag5evm, 0x40000000, 0x20000000)
+
 MACHINE_START(AG5EVM, "ag5evm")
+	.fixup		= ag5evm_fixup,
 	.smp		= smp_ops(sh73a0_smp_ops),
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_add_early_devices,
author maintainer
#10 lore raw

PATCH 3/6 ARM: shmobile: AP4EVB memory size fixup

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Specify the AP4EVB memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-ap4evb.c |    3 +++
 2 files changed, 4 insertions(+)
arch/arm/mach-shmobile/Kconfig +1 -0
@@ -71,6 +71,7 @@ comment "SH-Mobile Board Type"
 config MACH_AP4EVB
 	bool "AP4EVB board"
 	depends on ARCH_SH7372
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
arch/arm/mach-shmobile/board-ap4evb.c +3 -0
@@ -1321,7 +1321,10 @@ static void __init ap4evb_init(void)
 	pm_clk_add(&lcdc1_device.dev, "hdmi");
 }
 
+SHMOBILE_FIXUP(ap4evb, 0x40000000, 0x10000000)
+
 MACHINE_START(AP4EVB, "ap4evb")
+	.fixup		= ap4evb_fixup,
 	.map_io		= sh7372_map_io,
 	.init_early	= sh7372_add_early_devices,
 	.init_irq	= sh7372_init_irq,
author maintainer
#11 lore raw

PATCH 4/6 ARM: shmobile: Bonito memory size fixup

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Specify the Bonito memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-bonito.c |    4 ++++
 2 files changed, 5 insertions(+)
arch/arm/mach-shmobile/Kconfig +1 -0
@@ -120,6 +120,7 @@ config MACH_KOTA2
 config MACH_BONITO
 	bool "bonito board"
 	depends on ARCH_R8A7740
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
arch/arm/mach-shmobile/board-bonito.c +4 -0
@@ -37,6 +37,7 @@
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <mach/r8a7740.h>
 #include <mach/irqs.h>
 #include <video/sh_mobile_lcdc.h>
@@ -484,7 +485,10 @@ static void __init bonito_add_early_devi
 	r8a7740_add_early_devices();
 }
 
+SHMOBILE_FIXUP(bonito, 0x40000000, 0x20000000)
+
 MACHINE_START(BONITO, "bonito")
+	.fixup		= bonito_fixup,
 	.map_io		= bonito_map_io,
 	.init_early	= bonito_add_early_devices,
 	.init_irq	= r8a7740_init_irq,
author maintainer
#12 lore raw

PATCH 5/6 ARM: shmobile: Kota2 memory size fixup

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Specify the Kota2 memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

---

 arch/arm/mach-shmobile/Kconfig       |    1 +
 arch/arm/mach-shmobile/board-kota2.c |    4 ++++
 2 files changed, 5 insertions(+)
arch/arm/mach-shmobile/Kconfig +1 -0
@@ -114,6 +114,7 @@ config MACH_MACKEREL
 config MACH_KOTA2
 	bool "KOTA2 board"
 	depends on ARCH_SH73A0
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
arch/arm/mach-shmobile/board-kota2.c +4 -0
@@ -51,6 +51,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Dummy supplies, where voltage doesn't matter */
@@ -541,7 +542,10 @@ static void __init kota2_init(void)
 	platform_add_devices(kota2_devices, ARRAY_SIZE(kota2_devices));
 }
 
+SHMOBILE_FIXUP(kota2, 0x41000000, 0x1e000000)
+
 MACHINE_START(KOTA2, "kota2")
+	.fixup		= kota2_fixup,
 	.smp		= smp_ops(sh73a0_smp_ops),
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_add_early_devices,
author maintainer
#13 lore raw

PATCH 6/6 ARM: shmobile: Marzen memory size fixup

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

Specify the Marzen memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-marzen.c |    4 ++++
 2 files changed, 5 insertions(+)
arch/arm/mach-shmobile/Kconfig +1 -0
@@ -143,6 +143,7 @@ config MACH_BOCKW
 config MACH_MARZEN
 	bool "MARZEN board"
 	depends on ARCH_R8A7779
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
arch/arm/mach-shmobile/board-marzen.c +4 -0
@@ -46,6 +46,7 @@
 #include <mach/irqs.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Fixed 3.3V regulator to be used by SDHI0 */
@@ -409,7 +410,10 @@ static void __init marzen_init(void)
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
+SHMOBILE_FIXUP(marzen, 0x60000000, 0x10000000)
+
 MACHINE_START(MARZEN, "marzen")
+	.fixup		= marzen_fixup,
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= r8a7779_add_early_devices,