| Message ID | alpine.LFD.2.02.1210221041450.16518@xanadu.home (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 30 October 2012, Simon Horman wrote: > 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. Yes, no problem. This seemed like a low-hanging fruit initially but has turned into something much bigger now. Instead of attacking all these at ones, we can leave them as something worthwhile doing later. I noticed that out of the 11 shmobile defconfigs, only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START. Maybe it's possible to consolidate all or some of the others first, since they should still work with the same uImage at the expense of just making the early debugging a little harder, as we discussed earlier. For all I know, these three boards are also the ones seeing the most ongoing development, so you could start by using a shared defconfig for the oldest (ARM11 based) boards at first that are also less likely to impact new development starting from the defconfig. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 30, 2012 at 09:41:27PM +0000, Arnd Bergmann wrote: > On Tuesday 30 October 2012, Simon Horman wrote: > > 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. > > Yes, no problem. This seemed like a low-hanging fruit initially but has > turned into something much bigger now. > > Instead of attacking all these at ones, we can leave them as something > worthwhile doing later. I noticed that out of the 11 shmobile defconfigs, > only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START. > > Maybe it's possible to consolidate all or some of the others first, since > they should still work with the same uImage at the expense of just making > the early debugging a little harder, as we discussed earlier. > > For all I know, these three boards are also the ones seeing the most > ongoing development, so you could start by using a shared defconfig > for the oldest (ARM11 based) boards at first that are also less likely > to impact new development starting from the defconfig. Thanks, good observations. I will look into that. My expectation is that marzen and kzm9g will continue to see heavy development in the near future. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);