ARM: shmobile: Per-board memory size fixups
Magnus Damm
maintainercover 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(+)
Magnus Damm
maintainercover 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
Magnus Damm
maintainerPATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper
In reply to Magnus DammFrom: 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 */
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.
Magnus Damm
maintainerPATCH 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
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
Magnus Damm
maintainerPATCH 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
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_SIZEandPHYS_OFFSETchange inarch/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
PATCH 1/6 ARM: shmobile: Introduce SHMOBILE_FIXUP() helper
In reply to Russell King - ARM LinuxQuoted 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
Magnus Damm
maintainerPATCH 2/6 ARM: shmobile: AG5EVM memory size fixup
In reply to Magnus DammFrom: 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,
Magnus Damm
maintainerPATCH 3/6 ARM: shmobile: AP4EVB memory size fixup
In reply to Magnus DammFrom: 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,
Magnus Damm
maintainerPATCH 4/6 ARM: shmobile: Bonito memory size fixup
In reply to Magnus DammFrom: 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_devir8a7740_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,
Magnus Damm
maintainerPATCH 5/6 ARM: shmobile: Kota2 memory size fixup
In reply to Magnus DammFrom: 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,
Magnus Damm
maintainerPATCH 6/6 ARM: shmobile: Marzen memory size fixup
In reply to Magnus DammFrom: 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,