From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Date: Tue, 30 Oct 2012 07:45:08 +0000 Subject: Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8 Message-Id: <20121030074508.GG12329@verge.net.au> List-Id: References: <1350448698-26985-1-git-send-email-horms@verge.net.au> <20121022003350.GL2509@verge.net.au> <20121022015126.GA10587@verge.net.au> <201210221412.19486.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Mon, Oct 22, 2012 at 02:20:31PM -0400, Nicolas Pitre wrote: > On Mon, 22 Oct 2012, Arnd Bergmann wrote: > > > (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET) > > > > On Monday 22 October 2012, Simon Horman wrote: > > > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote: > > > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote: > > > > > On Friday 19 October 2012, Simon Horman wrote: > > > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START > > > > > > to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h > > > > > > > > > > > > I'm not sure that I see an easy way to get around this one. > > > > > > > > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it? > > > > > > I believe that this leaves mach-shmobile with three areas > > > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used. > > > > Hmm, I just noticed that in fact shmobile is the only remaining > > platform that uses CONFIG_MEMORY_START with a per-board or per-soc > > setting. > > > > > * arch/arm/mach-shmobile/headsmp.S > > > > > > This uses PLAT_PHYS_OFFSET. > > > > > > I believe this can be replaced with a run-time calculation. Though I > > > haven't thought about the details yet. > > What about this (untested): Thanks. I have not managed to successfully test this yet, but I think something like this is the right direction. I will try and massage it into a working version. > > diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S > index b202c12725..9293319fcb 100644 > --- a/arch/arm/mach-shmobile/headsmp.S > +++ b/arch/arm/mach-shmobile/headsmp.S > @@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1) > mov pc, lr > ENDPROC(v7_invalidate_l1) > > -ENTRY(shmobile_invalidate_start) > +ENTRY(shmobile_secondary_entry) > bl v7_invalidate_l1 > b secondary_startup > -ENDPROC(shmobile_invalidate_start) > +ENDPROC(shmobile_secondary_entry) > > /* > * Reset vector for secondary CPUs. > * This will be mapped at address 0 by SBAR register. > * We need _long_ jump to the physical address. > + * the loaded address is initialized to the physical address of > + * shmobile_secondary_entry > + * in platform_secondary_init(). > */ > + .data > .align 12 > + .arm > ENTRY(shmobile_secondary_vector) > ldr pc, 1f > -1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET > +1: .long 0 > ENDPROC(shmobile_secondary_vector) > diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c > index fde0d23121..356f82da16 100644 > --- a/arch/arm/mach-shmobile/platsmp.c > +++ b/arch/arm/mach-shmobile/platsmp.c > @@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu) > > void __cpuinit platform_secondary_init(unsigned int cpu) > { > + long shmobile_secondary_address; > + > trace_hardirqs_off(); > > + shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1; > + *shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry); > + __cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long)); > + > if (is_sh73a0()) > sh73a0_secondary_init(cpu); > > > > > * arch/arm/boot/compressed/head-shmobile.S > > > > > > This makes use of CONFIG_MEMORY_START. > > > This is only used if CONFIG_ZBOOT_ROM is set. > > > > > > I'm unsure if this can be replaced with a run-time calculation or not. > > > But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not > > > the default at this time. > > This code is meant to be executed from ROM which means a very tailored > kernel configuration. In that case it makes little sense to have > CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway. Agreed. > > Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and > > CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT > > The right dependency would be CONFIG_AUTO_ZRELADDR, not > ARM_PATCH_PHYS_VIRT. The later concerns the final kernel image, not the > decompressor. Thanks. > > > * arch/arm/mach-shmobile/Makefile.boot > > > > > > This makes use of CONFIG_MEMORY_START to set zreladdr. > > > > > > I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR. > > > However, it is not yet clear to me how that can be used in conjunction > > > with a uImage. As I understand it the boot loader on many of our boards, > > > including the Marzen board which is my first target for this work, boot > > > uImage imagess. > > > > If this doesn't work, we probably also need to find a solution to > > build multiple uImage files from the same vmlinux when building a > > multiplatform kernel. > > The right solution to the U-Boot problem is to remove uImage creation > from the kernel entirely. The U-Boot image format should be created at > _installation_ time, not at build time. The fact that the U-Boot image > format is (or was until very recently) inflexible is not Linux's fault. > > If the uImage build target is to remain in the kernel, it should be > marked incompatible with a multi-arch config. There is no point > distributing a multi-arch kernel image when wrapped into a uImage > format. I agree with you reasoning, and that in the long term removing uImage as a target and having an install-time mechanism would be a nice goal. However, I wonder what the way forward is. Provide install-scripts in the kernel tree somewhere? Provide information on the start address under Documentation/ somewhere? While I am more than happy to help address the issues raised in this thread, and others that arise. There do seem to be a number of issues between where we are now and a more generic shmobile_defconfig. I would like consideration given to allowing the exixting, working, well-maintained, per-board defconfigs to be updated until these issues have been resolved. From mboxrd@z Thu Jan 1 00:00:00 1970 From: horms@verge.net.au (Simon Horman) Date: Tue, 30 Oct 2012 15:45:08 +0800 Subject: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8 In-Reply-To: References: <1350448698-26985-1-git-send-email-horms@verge.net.au> <20121022003350.GL2509@verge.net.au> <20121022015126.GA10587@verge.net.au> <201210221412.19486.arnd@arndb.de> Message-ID: <20121030074508.GG12329@verge.net.au> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 22, 2012 at 02:20:31PM -0400, Nicolas Pitre wrote: > On Mon, 22 Oct 2012, Arnd Bergmann wrote: > > > (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET) > > > > On Monday 22 October 2012, Simon Horman wrote: > > > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote: > > > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote: > > > > > On Friday 19 October 2012, Simon Horman wrote: > > > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START > > > > > > to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h > > > > > > > > > > > > I'm not sure that I see an easy way to get around this one. > > > > > > > > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it? > > > > > > I believe that this leaves mach-shmobile with three areas > > > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used. > > > > Hmm, I just noticed that in fact shmobile is the only remaining > > platform that uses CONFIG_MEMORY_START with a per-board or per-soc > > setting. > > > > > * arch/arm/mach-shmobile/headsmp.S > > > > > > This uses PLAT_PHYS_OFFSET. > > > > > > I believe this can be replaced with a run-time calculation. Though I > > > haven't thought about the details yet. > > What about this (untested): Thanks. I have not managed to successfully test this yet, but I think something like this is the right direction. I will try and massage it into a working version. > > diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S > index b202c12725..9293319fcb 100644 > --- a/arch/arm/mach-shmobile/headsmp.S > +++ b/arch/arm/mach-shmobile/headsmp.S > @@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1) > mov pc, lr > ENDPROC(v7_invalidate_l1) > > -ENTRY(shmobile_invalidate_start) > +ENTRY(shmobile_secondary_entry) > bl v7_invalidate_l1 > b secondary_startup > -ENDPROC(shmobile_invalidate_start) > +ENDPROC(shmobile_secondary_entry) > > /* > * Reset vector for secondary CPUs. > * This will be mapped at address 0 by SBAR register. > * We need _long_ jump to the physical address. > + * the loaded address is initialized to the physical address of > + * shmobile_secondary_entry > + * in platform_secondary_init(). > */ > + .data > .align 12 > + .arm > ENTRY(shmobile_secondary_vector) > ldr pc, 1f > -1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET > +1: .long 0 > ENDPROC(shmobile_secondary_vector) > diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c > index fde0d23121..356f82da16 100644 > --- a/arch/arm/mach-shmobile/platsmp.c > +++ b/arch/arm/mach-shmobile/platsmp.c > @@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu) > > void __cpuinit platform_secondary_init(unsigned int cpu) > { > + long shmobile_secondary_address; > + > trace_hardirqs_off(); > > + shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1; > + *shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry); > + __cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long)); > + > if (is_sh73a0()) > sh73a0_secondary_init(cpu); > > > > > * arch/arm/boot/compressed/head-shmobile.S > > > > > > This makes use of CONFIG_MEMORY_START. > > > This is only used if CONFIG_ZBOOT_ROM is set. > > > > > > I'm unsure if this can be replaced with a run-time calculation or not. > > > But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not > > > the default at this time. > > This code is meant to be executed from ROM which means a very tailored > kernel configuration. In that case it makes little sense to have > CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway. Agreed. > > Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and > > CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT > > The right dependency would be CONFIG_AUTO_ZRELADDR, not > ARM_PATCH_PHYS_VIRT. The later concerns the final kernel image, not the > decompressor. Thanks. > > > * arch/arm/mach-shmobile/Makefile.boot > > > > > > This makes use of CONFIG_MEMORY_START to set zreladdr. > > > > > > I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR. > > > However, it is not yet clear to me how that can be used in conjunction > > > with a uImage. As I understand it the boot loader on many of our boards, > > > including the Marzen board which is my first target for this work, boot > > > uImage imagess. > > > > If this doesn't work, we probably also need to find a solution to > > build multiple uImage files from the same vmlinux when building a > > multiplatform kernel. > > The right solution to the U-Boot problem is to remove uImage creation > from the kernel entirely. The U-Boot image format should be created at > _installation_ time, not at build time. The fact that the U-Boot image > format is (or was until very recently) inflexible is not Linux's fault. > > If the uImage build target is to remain in the kernel, it should be > marked incompatible with a multi-arch config. There is no point > distributing a multi-arch kernel image when wrapped into a uImage > format. I agree with you reasoning, and that in the long term removing uImage as a target and having an install-time mechanism would be a nice goal. However, I wonder what the way forward is. Provide install-scripts in the kernel tree somewhere? Provide information on the start address under Documentation/ somewhere? While I am more than happy to help address the issues raised in this thread, and others that arise. There do seem to be a number of issues between where we are now and a more generic shmobile_defconfig. I would like consideration given to allowing the exixting, working, well-maintained, per-board defconfigs to be updated until these issues have been resolved.