Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On 11/30/11 20:11, Josh Boyer wrote: On Mon, Nov 28, 2011 at 5:59 PM, Scott Woodscottw...@freescale.com wrote: On 11/23/2011 10:47 AM, Josh Boyer wrote: On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulosesuz...@in.ibm.com wrote: The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. Should reword the config help to make it clear what the alignment restriction is, or where to find the information for a particular platform. Someone reading page aligned without any context that we're talking about special large pages is going to think 4K -- and on e500, many large page sizes are supported, so the required alignment is found in Linux init code rather than a CPU manual. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. Booted OK for me on e500v2 with RAM starting at 256M. Tested-by: Scott Woodscottw...@freescale.com We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART blah select NONSTATIC_KERNEL ... config RELOCATABLE blah select NONSTATIC_KERNEL I agree. Suzie do you think you could respin this patch with the suggested changes and include Scott's Tested-by? The rest of the series looks fine and I'd like to get it included in my next branch. Josh, I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU setup. However I am facing problems getting the my boards booted with the network cards (even without the patches). Here is what I see : Creating 2 MTD partitions on 1ff80.large-flash: 0x-0x0038 : fs 0x0038-0x0040 : firmware PPC 4xx OCP EMAC driver, version 3.54 mal0: failed to map interrupts ! ZMII /plb/opb/emac-zmii@4780 initialized /plb/opb/ethernet@4800: Timeout waiting for dependent devices /plb/opb/ethernet@4900: Timeout waiting for dependent devices TCP cubic registered NET: Registered protocol family 17 Root-NFS: no NFS server address VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device (null) or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: 1f00 512 mtdblock0 (driver?) 1f013584 mtdblock1 (driver?) 1f02 512 mtdblock2 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Have you come across this message ? Thanks Suzuki ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Wed, Dec 7, 2011 at 7:40 AM, Suzuki Poulose suz...@in.ibm.com wrote: Josh, I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU setup. However I am facing problems getting the my boards booted with the network cards (even without the patches). Here is what I see : Creating 2 MTD partitions on 1ff80.large-flash: 0x-0x0038 : fs 0x0038-0x0040 : firmware PPC 4xx OCP EMAC driver, version 3.54 mal0: failed to map interrupts ! That's the problem. There was a bogus commit that was added to the generic OF code that prevented the normal mapping that the MAL nodes do from working. It was later reverted after Benh told Linus it was bogus. I don't remember which -rc that wound up in, but if you move to 3.2-rc4 that should help. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Mon, Nov 28, 2011 at 5:59 PM, Scott Wood scottw...@freescale.com wrote: On 11/23/2011 10:47 AM, Josh Boyer wrote: On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose suz...@in.ibm.com wrote: The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. Should reword the config help to make it clear what the alignment restriction is, or where to find the information for a particular platform. Someone reading page aligned without any context that we're talking about special large pages is going to think 4K -- and on e500, many large page sizes are supported, so the required alignment is found in Linux init code rather than a CPU manual. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. Booted OK for me on e500v2 with RAM starting at 256M. Tested-by: Scott Wood scottw...@freescale.com We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART blah select NONSTATIC_KERNEL ... config RELOCATABLE blah select NONSTATIC_KERNEL I agree. Suzie do you think you could respin this patch with the suggested changes and include Scott's Tested-by? The rest of the series looks fine and I'd like to get it included in my next branch. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On 11/23/2011 10:47 AM, Josh Boyer wrote: On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose suz...@in.ibm.com wrote: The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. Should reword the config help to make it clear what the alignment restriction is, or where to find the information for a particular platform. Someone reading page aligned without any context that we're talking about special large pages is going to think 4K -- and on e500, many large page sizes are supported, so the required alignment is found in Linux init code rather than a CPU manual. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. Booted OK for me on e500v2 with RAM starting at 256M. Tested-by: Scott Wood scottw...@freescale.com We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART blah select NONSTATIC_KERNEL ... config RELOCATABLE blah select NONSTATIC_KERNEL I agree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose suz...@in.ibm.com wrote: The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. Suggested-by: Scott Wood scottw...@freescale.com Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com Cc: Scott Wood scottw...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: linux ppc dev linuxppc-dev@lists.ozlabs.org --- arch/powerpc/Kconfig | 50 - arch/powerpc/configs/44x/iss476-smp_defconfig | 2 + arch/powerpc/include/asm/kdump.h | 5 ++- arch/powerpc/include/asm/page.h | 4 +- arch/powerpc/kernel/crash_dump.c | 4 +- arch/powerpc/kernel/head_44x.S | 4 ++ arch/powerpc/kernel/head_fsl_booke.S | 2 + arch/powerpc/kernel/machine_kexec.c | 2 + arch/powerpc/kernel/prom_init.c | 2 + arch/powerpc/mm/44x_mmu.c | 2 + 10 files changed, 47 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d7c2d1a..8d4f789 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -363,7 +363,8 @@ config KEXEC config CRASH_DUMP bool Build a kdump crash kernel depends on PPC64 || 6xx || FSL_BOOKE - select RELOCATABLE if PPC64 || FSL_BOOKE + select RELOCATABLE if PPC64 + select DYNAMIC_MEMSTART if FSL_BOOKE help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump @@ -841,23 +842,36 @@ config LOWMEM_CAM_NUM int Number of CAMs to use to map low memory if LOWMEM_CAM_NUM_BOOL default 3 -config RELOCATABLE - bool Build a relocatable kernel (EXPERIMENTAL) +config DYNAMIC_MEMSTART OK, so my one bikeshed comment here. We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART blah select NONSTATIC_KERNEL ... config RELOCATABLE blah select NONSTATIC_KERNEL Then you can do this kind of thing: default 0x0200 if PPC_STD_MMU CRASH_DUMP !(NONSTATIC_KERNEL) #if defined(CONFIG_CRASH_DUMP) !(defined(CONFIG_NONSTATIC_KERNEL)) instead of this: default 0x0200 if PPC_STD_MMU CRASH_DUMP !(RELOCATABLE || DYNAMIC_MEMSTART) #if defined(CONFIG_CRASH_DUMP) !(defined(CONFIG_RELOCATABLE) || \ defined(CONFIG_DYNAMIC_MEMSTART)) while still allowing for differences between RELOCATABLE and DYNAMIC_MEMSTART. Thoughts? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Suggested-by: Scott Wood scottw...@freescale.com Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com Cc: Scott Wood scottw...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: linux ppc dev linuxppc-dev@lists.ozlabs.org --- arch/powerpc/Kconfig | 50 - arch/powerpc/configs/44x/iss476-smp_defconfig |2 + arch/powerpc/include/asm/kdump.h |5 ++- arch/powerpc/include/asm/page.h |4 +- arch/powerpc/kernel/crash_dump.c |4 +- arch/powerpc/kernel/head_44x.S|4 ++ arch/powerpc/kernel/head_fsl_booke.S |2 + arch/powerpc/kernel/machine_kexec.c |2 + arch/powerpc/kernel/prom_init.c |2 + arch/powerpc/mm/44x_mmu.c |2 + 10 files changed, 47 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d7c2d1a..8d4f789 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -363,7 +363,8 @@ config KEXEC config CRASH_DUMP bool Build a kdump crash kernel depends on PPC64 || 6xx || FSL_BOOKE - select RELOCATABLE if PPC64 || FSL_BOOKE + select RELOCATABLE if PPC64 + select DYNAMIC_MEMSTART if FSL_BOOKE help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump @@ -841,23 +842,36 @@ config LOWMEM_CAM_NUM int Number of CAMs to use to map low memory if LOWMEM_CAM_NUM_BOOL default 3 -config RELOCATABLE - bool Build a relocatable kernel (EXPERIMENTAL) +config DYNAMIC_MEMSTART + bool Enable page aligned dynamic load address for kernel (EXPERIMENTAL) depends on EXPERIMENTAL ADVANCED_OPTIONS FLATMEM (FSL_BOOKE || PPC_47x) help - This builds a kernel image that is capable of running at the - location the kernel is loaded at (some alignment restrictions may - exist). - - One use is for the kexec on panic case where the recovery kernel - must live at a different physical address than the primary - kernel. - - Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address - it has been loaded at and the compile time physical addresses - CONFIG_PHYSICAL_START is ignored. However CONFIG_PHYSICAL_START - setting can still be useful to bootwrappers that need to know the - load location of the kernel (eg. u-boot/mkimage). + This option enables the kernel to be loaded at any page aligned + physical address. The kernel creates a mapping from KERNELBASE to + the address where the kernel is loaded. + + DYNAMIC_MEMSTART is an easy way of implementing pseudo-RELOCATABLE + kernel image, where the only restriction is the page aligned kernel + load address. When this option is enabled, the compile time physical + address CONFIG_PHYSICAL_START is ignored. + +# Mapping based RELOCATABLE is moved to DYNAMIC_MEMSTART +# config RELOCATABLE +# bool Build a relocatable kernel (EXPERIMENTAL) +# depends on EXPERIMENTAL ADVANCED_OPTIONS FLATMEM (FSL_BOOKE || PPC_47x) +# help +#This builds a kernel image that is capable of running at the +#location the kernel is loaded at, without any alignment restrictions. +# +#One use is for the kexec on panic case where the recovery kernel +#must live at a different physical address than the primary +#kernel. +# +#Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address +#it has been loaded at and the compile time physical addresses +#CONFIG_PHYSICAL_START is ignored. However CONFIG_PHYSICAL_START +#setting can still be useful to bootwrappers that need to know the +#load location of the kernel (eg. u-boot/mkimage). config PAGE_OFFSET_BOOL bool Set custom page offset address @@ -887,7 +901,7 @@ config KERNEL_START_BOOL config KERNEL_START hex
