diff mbox

[01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

Message ID 20130605073418.15758.93704.sendpatchset@w520 (mailing list archive)
State New, archived
Headers show

Commit Message

Magnus Damm June 5, 2013, 7:34 a.m. UTC
From: Magnus Damm <damm@opensource.se>

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

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/include/mach/common.h |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Russell King - ARM Linux June 5, 2013, 7:20 p.m. UTC | #1
On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> 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 June 5, 2013, 11:47 p.m. UTC | #2
Hi Russell,

On Thu, Jun 6, 2013 at 4:20 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> 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.

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
Arnd Bergmann June 6, 2013, 4:53 p.m. UTC | #3
On Wednesday 05 June 2013, Russell King - ARM Linux wrote:
> On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm@opensource.se>
> > 
> > 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.

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
Arnd Bergmann June 6, 2013, 5:17 p.m. UTC | #4
On Thursday 06 June 2013, Magnus Damm wrote:
> 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?

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 June 10, 2013, 7:22 a.m. UTC | #5
Hi Arnd,

On Fri, Jun 7, 2013 at 2:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 06 June 2013, Magnus Damm wrote:
>> 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?
>
> 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.

> 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.

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
Arnd Bergmann June 10, 2013, 3:27 p.m. UTC | #6
On Monday 10 June 2013, Magnus Damm wrote:
> On Fri, Jun 7, 2013 at 2:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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
> 
> 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.

> > 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.
> 
> 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
diff mbox

Patch

--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-06-04 13:01:40.000000000 +0900
@@ -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 */