| Message ID | 20130605073418.15758.93704.sendpatchset@w520 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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
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
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
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
--- 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 */