[5/5] include tuning options into Makefile
This patch finally adds mcpu/mtune options to the Makefile using the previous introduced tuning mechanism. Subject: [PATCH] include tuning options into Makefile --- arch/powerpc/Makefile | 41 +++-- 1 files changed, 23 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 9629c5e..09f81a7 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -75,30 +75,35 @@ CPP = $(CC) -E $(KBUILD_CFLAGS) CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__ ifeq ($(CONFIG_PPC64),y) -GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo y; fi) -ifeq ($(CONFIG_TUNE_POWER4),y) -ifeq ($(CONFIG_OPT_EXCLUSIVE),y) -ifeq ($(CONFIG_ALTIVEC),y) -ifeq ($(GCC_BROKEN_VEC),y) - KBUILD_CFLAGS += $(call cc-option,-mcpu=970) +ifeq ($(shell if [ $(call cc-version) -lt 0400 ] ; then echo y; fi),y) +P4CPU := power4 else - KBUILD_CFLAGS += $(call cc-option,-mcpu=power4) +P4CPU := 970 endif -else - KBUILD_CFLAGS += $(call cc-option,-mcpu=power4) -endif -else - KBUILD_CFLAGS += $(call cc-option,-mtune=power4) -endif - KBUILD_CFLAGS += $(call cc-option,-mtune=power4) + +# optimize for specific cpu +ifeq ($(CONFIG_TUNE_RS64),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=rs64) +else ifeq ($(CONFIG_TUNE_POWER3),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=power3) +else ifeq ($(CONFIG_TUNE_POWER4),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=$(P4CPU)) +else ifeq ($(CONFIG_TUNE_CELL),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=cell,-mtune=cell) +else ifeq ($(CONFIG_TUNE_POWER5),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=power5,-mtune=power5) +else ifeq ($(CONFIG_TUNE_POWER6),y) +KBUILD_CFLAGS += $(call cc-option,-mcpu=power6,-mtune=power6) endif -else -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o + +ifneq ($(CONFIG_OPT_EXCLUSIVE),y) +KBUILD_CFLAGS := $(subst mcpu,mtune,$(KBUILD_CFLAGS)) endif -ifeq ($(CONFIG_TUNE_CELL),y) - KBUILD_CFLAGS += $(call cc-option,-mtune=cell) +else +# !PPC64 +LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o endif # No AltiVec instruction when building kernel -- 1.5.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[1/5] add tune options to Kconfig.cputypes
This patch adds tuning options similar to ppc32. In addition one can choose to compile exclusive for the selected (and higher) cpus. Subject: [PATCH] add tune options to Kconfig.cputypes --- arch/powerpc/platforms/Kconfig.cputype | 79 --- 1 files changed, 61 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 5bc4b61..88e6ce2 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -54,35 +54,78 @@ config E200 endchoice -config POWER4_ONLY - bool Optimize for POWER4 +choice + prompt Processor Type depends on PPC64 + default TUNE_POWER4 + help + There are serveral families of 64 bit PowerPC chips supported. + These include the RS64, Power3 to Power6 series, 970, and + Cell BE based CPUs made be IBM. + + If unsure, select Power4. + +config TUNE_RS64 + bool RS64 + +config TUNE_POWER3 + bool Power3 + +config TUNE_POWER4 + bool Power4 + +config TUNE_970 + bool 970/G5 + +config TUNE_POWER5 + bool Power5 + +config TUNE_POWER6 + bool Power6 + +config TUNE_CELL + bool Cell Broadband Engine + help + Cause the compiler to optimize for the PPE of the Cell Broadband + Engine. This will make the code run considerably faster on Cell + but somewhat slower on other machines. If the resulting kernel is + built to run only on Cell BE machines, select also OPT_EXCLUSIVE. + +endchoice + +config OPT_EXCLUSIVE + bool Optimize to run exclusive on selected CPU default n - ---help--- - Cause the compiler to optimize for POWER4/POWER5/PPC970 processors. - The resulting binary will not work on POWER3 or RS64 processors - when compiled with binutils 2.15 or later. + help + Cause the compiler to optimize to run exclusive on the selected + CPU. The resulting binary will probably not work on older CPUs, + but should work on newer ones. + + See the following chart for supported PPC64 CPU generations. + + older -- newer + + RS64 - POWER3 - POWER4 - POWER5 - POWER6 + 970/G5 + CELL BE + PA6T + + If the compiler/binutils combination does not support the exclusive + optimization, it will try to tune only or fail. + + If you are unsure, select no. config POWER3 - bool depends on PPC64 - default y if !POWER4_ONLY + def_bool y if !POWER4_ONLY config POWER4 depends on PPC64 def_bool y -config TUNE_CELL - bool Optimize for Cell Broadband Engine +config POWER4_ONLY depends on PPC64 - help - Cause the compiler to optimize for the PPE of the Cell Broadband - Engine. This will make the code run considerably faster on Cell - but somewhat slower on other machines. This option only changes - the scheduling of instructions, not the selection of instructions - itself, so the resulting kernel will keep running on all other - machines. When building a kernel that is supposed to run only - on Cell, you should also select the POWER4_ONLY option. + def_bool y if TUNE_POWER4 OPT_EXCLUSIVE config 6xx bool -- 1.5.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[3/5] replace CONFIG_POWER4 by CONFIG_PPC64
This patch replaces all occurrences of CONFIG_POWER4 by CONFIG_PPC64 since it is redundant. Subject: [PATCH] replace CONFIG_POWER4 by CONFIG_PPC64 --- arch/powerpc/Makefile |2 +- arch/powerpc/configs/cell_defconfig |1 - arch/powerpc/configs/celleb_defconfig |1 - arch/powerpc/configs/g5_defconfig |1 - arch/powerpc/configs/iseries_defconfig|1 - arch/powerpc/configs/maple_defconfig |1 - arch/powerpc/configs/pasemi_defconfig |1 - arch/powerpc/configs/ppc64_defconfig |1 - arch/powerpc/configs/ps3_defconfig|1 - arch/powerpc/configs/pseries_defconfig|1 - arch/powerpc/mm/ppc_mmu_32.c |2 +- arch/powerpc/platforms/Kconfig.cputype|4 --- arch/powerpc/platforms/powermac/feature.c | 42 +--- include/asm-powerpc/cputable.h|2 +- include/asm-powerpc/mmu_context.h |6 +--- 15 files changed, 25 insertions(+), 42 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 9155c93..624a896 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -118,7 +118,7 @@ endif cpu-as-$(CONFIG_4xx) += -Wa,-m405 cpu-as-$(CONFIG_6xx) += -Wa,-maltivec -cpu-as-$(CONFIG_POWER4)+= -Wa,-maltivec +cpu-as-$(CONFIG_PPC64) += -Wa,-maltivec cpu-as-$(CONFIG_E500) += -Wa,-me500 cpu-as-$(CONFIG_E200) += -Wa,-me200 diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig index 579e996..42290e8 100644 --- a/arch/powerpc/configs/cell_defconfig +++ b/arch/powerpc/configs/cell_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/celleb_defconfig b/arch/powerpc/configs/celleb_defconfig index c2761a7..a405836 100644 --- a/arch/powerpc/configs/celleb_defconfig +++ b/arch/powerpc/configs/celleb_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 0ccc6e4..747088a 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -9,7 +9,6 @@ CONFIG_PPC64=y # Processor support # CONFIG_POWER4_ONLY=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig index 5237a6b..1b46033 100644 --- a/arch/powerpc/configs/iseries_defconfig +++ b/arch/powerpc/configs/iseries_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig index 7a166a3..4becb7b 100644 --- a/arch/powerpc/configs/maple_defconfig +++ b/arch/powerpc/configs/maple_defconfig @@ -9,7 +9,6 @@ CONFIG_PPC64=y # Processor support # CONFIG_POWER4_ONLY=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig index 199e5f5..d816a3a 100644 --- a/arch/powerpc/configs/pasemi_defconfig +++ b/arch/powerpc/configs/pasemi_defconfig @@ -9,7 +9,6 @@ CONFIG_PPC64=y # Processor support # CONFIG_POWER4_ONLY=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 953d840..22276d2 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig index 2015c69..52a0895 100644 --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index e163059..e0194e7 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -10,7 +10,6 @@ CONFIG_PPC64=y # # CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y -CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c index c53145f..c3509c8 100644 --- a/arch/powerpc/mm/ppc_mmu_32.c +++
[2/5] replace all occurrences of CONFIG_POWER3 by CONFIG_BATS64
This patch replaces all occurrences of CONFIG_POWER3 by CONFIG_BATS64. It should have no effect on the output kernel. Subject: [PATCH] replace all occurrences of CONFIG_POWER3 by CONFIG_BATS64 --- arch/powerpc/configs/cell_defconfig|2 +- arch/powerpc/configs/celleb_defconfig |2 +- arch/powerpc/configs/iseries_defconfig |2 +- arch/powerpc/configs/ppc64_defconfig |2 +- arch/powerpc/configs/ps3_defconfig |2 +- arch/powerpc/configs/pseries_defconfig |2 +- arch/powerpc/mm/pgtable_32.c |2 +- arch/powerpc/platforms/Kconfig.cputype |2 +- include/asm-powerpc/cputable.h |3 +-- 9 files changed, 9 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig index c420e47..579e996 100644 --- a/arch/powerpc/configs/cell_defconfig +++ b/arch/powerpc/configs/cell_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/celleb_defconfig b/arch/powerpc/configs/celleb_defconfig index 9ba3c6f..c2761a7 100644 --- a/arch/powerpc/configs/celleb_defconfig +++ b/arch/powerpc/configs/celleb_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig index 63f0bdb..5237a6b 100644 --- a/arch/powerpc/configs/iseries_defconfig +++ b/arch/powerpc/configs/iseries_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index ce250bc..953d840 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig index 71d79e4..2015c69 100644 --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index fe6ffa6..e163059 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -9,7 +9,7 @@ CONFIG_PPC64=y # Processor support # # CONFIG_POWER4_ONLY is not set -CONFIG_POWER3=y +CONFIG_BATS64=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index c758407..c4e8d86 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -38,7 +38,7 @@ unsigned long ioremap_base; unsigned long ioremap_bot; EXPORT_SYMBOL(ioremap_bot);/* aka VMALLOC_END */ -#if defined(CONFIG_6xx) || defined(CONFIG_POWER3) +#if defined(CONFIG_6xx) || defined(CONFIG_BATS64) #define HAVE_BATS 1 #endif diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 88e6ce2..b343fdb 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -115,7 +115,7 @@ config OPT_EXCLUSIVE If you are unsure, select no. -config POWER3 +config BATS64 depends on PPC64 def_bool y if !POWER4_ONLY diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h index 2a3e907..0ef9abc 100644 --- a/include/asm-powerpc/cputable.h +++ b/include/asm-powerpc/cputable.h @@ -257,8 +257,7 @@ extern void do_feature_fixups(unsigned long value, void *fixup_start, #endif #define CLASSIC_PPC (!defined(CONFIG_8xx) !defined(CONFIG_4xx) \ -!defined(CONFIG_POWER3) !defined(CONFIG_POWER4) \ -!defined(CONFIG_BOOKE)) +!defined(CONFIG_POWER4) !defined(CONFIG_BOOKE)) #define CPU_FTRS_PPC601(CPU_FTR_COMMON | CPU_FTR_601 | CPU_FTR_HPTE_TABLE | \ CPU_FTR_COHERENT_ICACHE | CPU_FTR_UNIFIED_ID_CACHE) -- 1.5.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [0/5] tuning options for PPC64
Hi, the following five patches should lay a foundation to more fine-grained tuning on PPC64 cpus. They must be applied in order. The motivation are the discussions of serveral cpu specific optimizations in the past on this list, cleanup of the wired Makefile/CONFIG_POWERx constructs and at least the ownership of a PS3. The patches intoduce CONFIG_TUNE_some_cpu and CONFIG_OPT_EXCLUSIVE, with the aim to cover two common cases: - distributions want a common kernel, bootable on all ppc64 machines and tune for a certain cpu - high end users don't care about older cpus and want to compile a kernel with their favorite mcpu option I know there is also the possibility of mcpu=x and mtune=y, yx but this can be tackled in the next step (hopefully). I know this will bring up some conserns, but my initial findings grepping the defconfigs show: - CONFIG_POWER3 enables BATS only it is also used the enable some configs it is used always in combination with CONFIG_POWER4 - CONFIG_POWER4 is always combined with CONFIG_PPC64 and vice versa all POWER3 || POWER4 || PPC64 can be replaced by PPC64 - There seems to be no support for 32-bit kernels on ppc64 machines I hope for some feedback, so this new scheme (or some other) can be included to mainstream kernel. Greetings Marvin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[4/5] replace CONFIG_POWER4_ONLY by new tuning mechanism
This patch replaces CONFIG_POWER4_ONLY by (CONFIG_OPT_EXCLUSIVE CONFIG_TUNE_POWER4). This gets overwritten in the next patch. It also introduces integer values of CPU generations. This is useful to enable features available only since a certain CPU gen (see last hunk). Unfortunately, kbuild system can't (yet) compare int values, so MIN_POWERn is also defined (but not used yet). Subject: [PATCH] replace CONFIG_POWER4_ONLY by new tuning mechanism --- arch/powerpc/Kconfig|2 +- arch/powerpc/Makefile |5 - arch/powerpc/configs/cell_defconfig |1 - arch/powerpc/configs/celleb_defconfig |1 - arch/powerpc/configs/g5_defconfig |3 ++- arch/powerpc/configs/iseries_defconfig |1 - arch/powerpc/configs/maple_defconfig|3 ++- arch/powerpc/configs/pasemi_defconfig |3 ++- arch/powerpc/configs/ppc64_defconfig|1 - arch/powerpc/configs/ps3_defconfig |1 - arch/powerpc/configs/pseries_defconfig |1 - arch/powerpc/platforms/Kconfig.cputype | 31 --- arch/powerpc/platforms/powermac/Kconfig |2 +- include/asm-powerpc/asm-compat.h|2 +- 14 files changed, 37 insertions(+), 20 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index de88972..9b2aaf5 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -528,7 +528,7 @@ config ZONE_DMA config GENERIC_ISA_DMA bool - depends on PPC64 || POWER4 || 6xx !CPM2 + depends on PPC64 || 6xx !CPM2 default y config PPC_INDIRECT_PCI diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 624a896..9629c5e 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -77,7 +77,8 @@ CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE) ifeq ($(CONFIG_PPC64),y) GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo y; fi) -ifeq ($(CONFIG_POWER4_ONLY),y) +ifeq ($(CONFIG_TUNE_POWER4),y) +ifeq ($(CONFIG_OPT_EXCLUSIVE),y) ifeq ($(CONFIG_ALTIVEC),y) ifeq ($(GCC_BROKEN_VEC),y) KBUILD_CFLAGS += $(call cc-option,-mcpu=970) @@ -90,6 +91,8 @@ endif else KBUILD_CFLAGS += $(call cc-option,-mtune=power4) endif + KBUILD_CFLAGS += $(call cc-option,-mtune=power4) +endif else LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o endif diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig index 42290e8..7e8e581 100644 --- a/arch/powerpc/configs/cell_defconfig +++ b/arch/powerpc/configs/cell_defconfig @@ -8,7 +8,6 @@ CONFIG_PPC64=y # # Processor support # -# CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/celleb_defconfig b/arch/powerpc/configs/celleb_defconfig index a405836..e11e991 100644 --- a/arch/powerpc/configs/celleb_defconfig +++ b/arch/powerpc/configs/celleb_defconfig @@ -8,7 +8,6 @@ CONFIG_PPC64=y # # Processor support # -# CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 747088a..e2c92ed 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -8,7 +8,8 @@ CONFIG_PPC64=y # # Processor support # -CONFIG_POWER4_ONLY=y +CONFIG_TUNE_POWER4=y +CONFIG_OPT_EXCLUSIVE=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig index 1b46033..abe72fd 100644 --- a/arch/powerpc/configs/iseries_defconfig +++ b/arch/powerpc/configs/iseries_defconfig @@ -8,7 +8,6 @@ CONFIG_PPC64=y # # Processor support # -# CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig index 4becb7b..6dee9f2 100644 --- a/arch/powerpc/configs/maple_defconfig +++ b/arch/powerpc/configs/maple_defconfig @@ -8,7 +8,8 @@ CONFIG_PPC64=y # # Processor support # -CONFIG_POWER4_ONLY=y +CONFIG_TUNE_POWER4=y +CONFIG_OPT_EXCLUSIVE=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig index d816a3a..adef0fe 100644 --- a/arch/powerpc/configs/pasemi_defconfig +++ b/arch/powerpc/configs/pasemi_defconfig @@ -8,7 +8,8 @@ CONFIG_PPC64=y # # Processor support # -CONFIG_POWER4_ONLY=y +CONFIG_TUNE_POWER4=y +CONFIG_OPT_EXCLUSIVE=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 22276d2..7f14276 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -8,7 +8,6 @@ CONFIG_PPC64=y # # Processor support # -# CONFIG_POWER4_ONLY is not set CONFIG_BATS64=y #
Re: [RFC v3 PATCH 4/4] Relocation support
Segher Boessenkool wrote: This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE to make sure that we load the correct address. Did you figure out _why_ LOAD_REG_ADDR doesn't work? Using LOAD_REG_IMMEDIATE is actually a step back, it makes the kernel binary non-PIC. And LOAD_REG_ADDR _should_ work just fine with your scheme. Hi Segher, I was going through the output generated by objdump -D vmlinux and readelf -h vmlinux. Snip objdump of vmlinux Disassembly of section .got: c0805010 __toc_start: c0805010: c0 00 00 00 lfs f0,0(0) c0805014: 00 80 d0 10 .long 0x80d010 c0805018: c0 00 00 00 lfs f0,0(0) c080501c: 00 00 83 58 .long 0x8358 c0805020: c0 00 00 00 lfs f0,0(0) c0805024: 00 85 1f e8 .long 0x851fe8 c0805028: c0 00 00 00 lfs f0,0(0) c080502c: 00 00 8d 84 .long 0x8d84 c0805030: c0 00 00 00 lfs f0,0(0) c0805034: 00 85 03 38 .long 0x850338 c0805038: c0 00 00 00 lfs f0,0(0) c080503c: 00 85 28 b8 .long 0x8528b8 c0805040: c0 00 00 00 lfs f0,0(0) c0805044: 00 85 28 b0 .long 0x8528b0 c0805048: c0 00 00 00 lfs f0,0(0) c080504c: 00 6d ef 60 .long 0x6def60 All of the variables references through @got translated into relocation type R_PPC64_GOT16_DS entries. All these entries correspond to one of the above entries in the .got section. But none of the entries in .got section are relocated. For example the instruction with relocation type R_PPC64_GOT16_DS, c000830c: e8 62 80 10 ld r3,-32752(r2) refers to current_set variable. r2 will be pointing to 0xc280d010 (relocated __toc_start + 0x8000). So the instruction loads r3 with the content 0xc0851fe8 at location 0xc2805020, but which is not a relocated entry (0xc0851fe8) But when there is a relocation type of R_PPC64_ADDR16_HI, like c0008110: 64 84 00 00 orisr4,r4,0 we could easily get more info about this relocation from readelf like: c0008112 00010005 R_PPC64_ADDR16_HI c000 .text + 8124 So from above output we can identify that instruction at address c0008112 needs to be patched with the relocation delta. Now I have two options left: 1. Check for R_PPC64_GOT16_DS entries and check whether the contents addressed by r2+offset is relocated or not and apply relocation if its not. 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have already done. Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] elf loader support for auxvec base platform string
Andrew, we have one other patch (the powerpc bits) on top of that one. Do you want to carry both in -mm on top of John's patch ? We would like that in .27 though, I don't know what your merge plans are for John's patch. How about I send John's patch Linuswards right now? No objection. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [3/5] replace CONFIG_POWER4 by CONFIG_PPC64
On Monday 21 July 2008, Marvin wrote:
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..c3509c8 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -74,7 +74,7 @@ unsigned long p_mapped_by_bats(phys_addr_t pa)
unsigned long __init mmu_mapin_ram(void)
{
-#ifdef CONFIG_POWER4
+#ifdef CONFIG_PPC64
return 0;
#else
unsigned long tot, bl, done;
ppc_mmu_32 is 32-bit only, so you can kill this #ifdef.
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 0ef9abc..97fdbaf 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -257,7 +257,7 @@ extern void do_feature_fixups(unsigned long value, void
*fixup_start,
#endif
#define CLASSIC_PPC (!defined(CONFIG_8xx) !defined(CONFIG_4xx) \
- !defined(CONFIG_POWER4) !defined(CONFIG_BOOKE))
+ !defined(CONFIG_PPC64) !defined(CONFIG_BOOKE))
This would be more logical in the opposite way:
#define CLASSIC_PPC (defined(CONFIG_PPC32) !defined(CONFIG_8xx)
!defined(CONFIG_4xx) !defined(CONFIG_BOOKE))
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [4/5] replace CONFIG_POWER4_ONLY by new tuning mechanism
On Monday 21 July 2008, Marvin wrote: --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -115,13 +115,30 @@ config OPT_EXCLUSIVE If you are unsure, select no. -config BATS64 +config PPC64_GEN depends on PPC64 - def_bool y if !POWER4_ONLY + int + default 1 if !OPT_EXCLUSIVE + default 2 if TUNE_RS64 + default 3 if TUNE_POWER3 + default 4 if TUNE_POWER4 || TUNE_CELL || TUNE_970 + default 5 if TUNE_POWER5 + default 6 if TUNE_POWER6 Unfortunately, the world is not this easy, e.g. POWER5 doesn't have all the features that Cell and 970 have (or vice versa), and PA6T doesn't fit in here either. If you want to model this correctly, you need to have each CPU as a separate option, and then deduce the feature set from that, like: menuconfig CPU selection config MIN_POWER3 bool Power 3 support config MIN_POWER4 bool Power 4 support config MIN_CELL bool Cell Broadband Engine support and so on. All this has nothing to do with the tuning option, except that you may want to make sure a CPU is enabled if you want to be able to tune for it. @@ -185,7 +202,7 @@ config PHYS_64BIT config ALTIVEC bool AltiVec Support - depends on CLASSIC32 || POWER4 + depends on CLASSIC32 || PPC64 ---help--- This option enables kernel support for the Altivec extensions to the PowerPC processor. The kernel currently supports saving and restoring If you know exactly what CPUs are supported, you can do this automatically: Altivec works only on G4 (mpc74xx and mpc86xx), G5 (970), Cell, Power6 and PA6T. @@ -201,7 +218,7 @@ config ALTIVEC config VSX bool VSX Support - depends on POWER4 ALTIVEC PPC_FPU + depends on PPC64 ALTIVEC PPC_FPU ---help--- This option enables kernel support for the Vector Scaler extensions Similarly, VSX is available only on Power6. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [5/5] include tuning options into Makefile
On Monday 21 July 2008, Marvin wrote: +# optimize for specific cpu +ifeq ($(CONFIG_TUNE_RS64),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=rs64) +else ifeq ($(CONFIG_TUNE_POWER3),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=power3) +else ifeq ($(CONFIG_TUNE_POWER4),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=$(P4CPU)) +else ifeq ($(CONFIG_TUNE_CELL),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=cell,-mtune=cell) +else ifeq ($(CONFIG_TUNE_POWER5),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=power5,-mtune=power5) +else ifeq ($(CONFIG_TUNE_POWER6),y) + KBUILD_CFLAGS += $(call cc-option,-mcpu=power6,-mtune=power6) endif -else -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o I think it would be easier to express this logic in Kconfig than in Makefile. + +ifneq ($(CONFIG_OPT_EXCLUSIVE),y) + KBUILD_CFLAGS := $(subst mcpu,mtune,$(KBUILD_CFLAGS)) endif This still doesn't allow the most interesting case where you want to optimize for a modern CPU but still allow older ones, e.g. -mcpu=power4 -mtune=power6. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
Hi Benjamin * Benjamin Herrenschmidt [EMAIL PROTECTED] [2008-07-19 08:05:30]: With the original patch, the pending batch does get flushed in a non-preemptable region. I am resending the original with just adding the necesary comments. Your comment isn't what I meant. What I meant is that if the process is context switched while walking the page tables, the low level powerpc context switch code should also perform a ???__flush_tlb_pending. Sorry, I misunderstood. The powerpc context switch code does perform a __flush_tlb_pending. Here is the patch http://marc.info/?l=linux-kernelm=119752629222720w=2 BTW. Is the pte_lock also not a real spinlock anymore ? That may break other assumptions the powerpc mm code is doing. pte_lock is a not a real spinlock anymore. This -rt stuff is just too scary, it changes some fundamental semantics of the spinlocks. yuck. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] IB/ehca: Two minor circumventions
[1/2] fixes spurious PATH_MIG events with certain FW versions [2/2] inserts a default value for Local CA ACK Delay Please review these patches and queue them for inclusion into the kernel if you think they're okay. Thanks! Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] IB/ehca: Filter PATH_MIG events if QP was never armed
Certain firmware versions sometimes cause spurious PATH_MIG events to occur
during QP creation. Filter these events by making sure PATH_MIG events are
only handed down when they actually make sense (i.e. when the QP has been
armed at least once).
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_classes.h |1 +
drivers/infiniband/hw/ehca/ehca_irq.c |4
drivers/infiniband/hw/ehca/ehca_qp.c |2 ++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 1e9e99a..0b0618e 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -194,6 +194,7 @@ struct ehca_qp {
u32 packet_count;
atomic_t nr_events; /* events seen */
wait_queue_head_t wait_completion;
+ int mig_armed;
};
#define IS_SRQ(qp) (qp-ext_type == EQPT_SRQ)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index 0792d93..99642a6 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -178,6 +178,10 @@ static void dispatch_qp_event(struct ehca_shca *shca,
struct ehca_qp *qp,
{
struct ib_event event;
+ /* PATH_MIG without the QP ever having been armed is false alarm */
+ if (event_type == IB_EVENT_PATH_MIG !qp-mig_armed)
+ return;
+
event.device = shca-ib_device;
event.event = event_type;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index 3f59587..ea13efd 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -1460,6 +1460,8 @@ static int internal_modify_qp(struct ib_qp *ibqp,
goto modify_qp_exit2;
}
mqpcb-path_migration_state = attr-path_mig_state + 1;
+ if (attr-path_mig_state == IB_MIG_REARM)
+ my_qp-mig_armed = 1;
update_mask |=
EHCA_BMASK_SET(MQPCB_MASK_PATH_MIGRATION_STATE, 1);
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] IB/ehca: Default value for Local CA ACK Delay
Some firmware versions report a Local CA ACK Delay of 0. In that case, return a more sensible default value of 12 (- 16 msec) instead. Signed-off-by: Joachim Fenkes [EMAIL PROTECTED] --- drivers/infiniband/hw/ehca/ehca_hca.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c index bc3b37d..4628822 100644 --- a/drivers/infiniband/hw/ehca/ehca_hca.c +++ b/drivers/infiniband/hw/ehca/ehca_hca.c @@ -114,7 +114,9 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props) } props-max_pkeys = 16; - props-local_ca_ack_delay = min_t(u8, rblock-local_ca_ack_delay, 255); + /* Some FW versions say 0 here; insert sensible value in that case */ + props-local_ca_ack_delay = rblock-local_ca_ack_delay ? + min_t(u8, rblock-local_ca_ack_delay, 255) : 12; props-max_raw_ipv6_qp = limit_uint(rblock-max_raw_ipv6_qp); props-max_raw_ethy_qp = limit_uint(rblock-max_raw_ethy_qp); props-max_mcast_grp = limit_uint(rblock-max_mcast_grp); -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add more register definitions for the MPC52xx PSC
Add more register definitions for the MPC52xx PSC
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
include/asm-powerpc/mpc52xx_psc.h |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/mpc52xx_psc.h
b/include/asm-powerpc/mpc52xx_psc.h
index 0985dc8..4639598 100644
--- a/include/asm-powerpc/mpc52xx_psc.h
+++ b/include/asm-powerpc/mpc52xx_psc.h
@@ -162,8 +162,12 @@ struct mpc52xx_psc {
u8 reserved5[3];
u8 ctlr; /* PSC + 0x1c */
u8 reserved6[3];
- u16 ccr;/* PSC + 0x20 */
- u8 reserved7[14];
+ /* BitClkDiv field of CCR is byte swapped in
+* the hardware for mpc5200/b compatibility */
+ u32 ccr;/* PSC + 0x20 */
+ u32 ac97_slots; /* PSC + 0x24 */
+ u32 ac97_cmd; /* PSC + 0x28 */
+ u32 ac97_data; /* PSC + 0x2c */
u8 ivr;/* PSC + 0x30 */
u8 reserved8[3];
u8 ip; /* PSC + 0x34 */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
On Mon, 21 Jul 2008 14:09:46 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: I think you must be thinking of mdelay(). Correct you are! I didn't even know there was an msleep() so I just mapped it to mdelay() ;) I'll have to look at msleep() though, there are places we could use it. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [1/5] add tune options to Kconfig.cputypes
Hi, On Sun, Jul 20, 2008 at 07:48:24PM +0200, Marvin wrote: + RS64 - POWER3 - POWER4 - POWER5 - POWER6 + 970/G5 + CELL BE + PA6T + + If the compiler/binutils combination does not support the exclusive + optimization, it will try to tune only or fail. PA6T implements 2.04 and a few pieces of 2.05, so it sits between POWER5+ and POWER6 feature-wise. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: radeonfb, dedicate memory to something else
On 7/20/08, Matt Sealey [EMAIL PROTECTED] wrote: Hi guys, I know this isn't a PPC question, but since some of the RadeonFB developers live here I thought best (and it's about a PPC platform). Is there any way to hack up the RadeonFB driver - or anything related - to reserve portions of the memory for a fake MTD or so, and still use the Radeon as a graphics device? What I am talking about basically is turning a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB card.. Somebody write this long ago. Maybe around 2000. That's all I remember. I think they made the video memory into a ram disk. I believe there is more to it, the GART window may be smaller than the total RAM on the card. You need to use the GART to map in the appropriate pieces. I think this can be done by hacking a PCI fixup perhaps, for Efika only in my case, whereby the memory ranges are fiddled. Perhaps, a better solution is to use some kind of in-kernel subsystem to allocate and return a 32MB segment of PCI memory (and put it in an named rheap) but I assume other drivers can and will simply walk all over it? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
On Wed, Jul 16, 2008 at 05:57:45PM -0400, Dave Jones wrote: On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote: On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote: If we don't enable FS_ENET we get build issues: arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe': arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang' arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register' How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG. If CONFIG_PHYLIB=m however, that doesn't make any difference, because vmlinuz is trying to use a symbol which now lives in a module. Yuck. If FOO selects BAR, and FOO is 'y', then BAR should be 'y', not 'm'. If BAR depends on other symbols that are 'm', they should be changed to 'y'. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
On Wed, Jul 16, 2008 at 05:55:17PM -0500, Kumar Gala wrote: It looks like the simplest solution at this point is to unconditionally select the PHYLIB for this board. We should look at moving the low level mdio bitbang ops out so they can be built as a module. Or exporting the MDIO/MDC pins through the GPIO API. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Remove fsl-soc.c from mpc5200 build, it is not needed.
Remove fsl-soc.c from mpc5200 build, it is not needed. Signed-off-by: Jon Smirl [EMAIL PROTECTED] --- arch/powerpc/platforms/52xx/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig index e91a0d2..76a3411 100644 --- a/arch/powerpc/platforms/52xx/Kconfig +++ b/arch/powerpc/platforms/52xx/Kconfig @@ -1,7 +1,6 @@ config PPC_MPC52xx bool 52xx-based boards depends on PPC_MULTIPLATFORM PPC32 - select FSL_SOC select PPC_CLOCK config PPC_MPC5200_SIMPLE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Networkl problems with lastest kernel....
I just did a git pull of Linus' kernel. It seems to be mainly network changes... and I get the following oops. Anybody else seeing this? I really don't have time to look at the problem right now, maybe tonight. Cheers, Sean [ cut here ] Kernel BUG at c01ba650 [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] Warp Modules linked in: NIP: c01ba650 LR: c015e240 CTR: c0011f84 REGS: cf821d60 TRAP: 0700 Not tainted (2.6.26-pika) MSR: 00029000 EE,ME CR: 4482 XER: 005f TASK = cf81f900[1] 'swapper' THREAD: cf82 GPR00: cf821e10 cf81f900 c02fd5a8 8000 c0010684 GPR08: c02fd5a8 0001 0001 2428 0004 c02a GPR16: 00400684 0080 c02e c027 c02e c02e c03206c0 0001 GPR24: c02e cf984000 cf984438 cf984380 00029000 cf9843d0 cf984000 NIP [c01ba650] __netif_schedule+0x28/0x84 LR [c015e240] emac_open+0x3d8/0x470 Call Trace: [cf821e10] [cf984000] 0xcf984000 (unreliable) [cf821e30] [c015e240] emac_open+0x3d8/0x470 [cf821e60] [c01bc2b4] dev_open+0xa8/0x118 [cf821e80] [c01bc1b4] dev_change_flags+0x168/0x1c0 [cf821ea0] [c02d3e48] ip_auto_config+0x19c/0xecc [cf821f60] [c02ba83c] kernel_init+0x84/0x274 [cf821ff0] [c000c518] kernel_thread+0x48/0x64 Instruction dump: 4e800020 4bfffe48 7c0802a6 3d60c030 9421ffe0 396bd5a8 90010024 bfa10014 7c681b78 7c6b5a78 200b 7d605914 0f0b 3922 38030024 7d600028 ---[ end trace be4338b61948e802 ]--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Networkl problems with lastest kernel....
From: Sean MacLennan [EMAIL PROTECTED] Date: Mon, 21 Jul 2008 12:18:29 -0400 I just did a git pull of Linus' kernel. It seems to be mainly network changes... and I get the following oops. Anybody else seeing this? I really don't have time to look at the problem right now, maybe tonight. If I had a penny for every driver with broken TX queue handling... Please try this patch, thanks: diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index 2e720f2..4e01d29 100644 --- a/drivers/net/ibm_newemac/core.c +++ b/drivers/net/ibm_newemac/core.c @@ -1157,6 +1157,7 @@ static int emac_open(struct net_device *ndev) mal_enable_rx_channel(dev-mal, dev-mal_rx_chan); emac_tx_enable(dev); emac_rx_enable(dev); + netif_start_queue(dev); emac_netif_start(dev); mutex_unlock(dev-link_lock); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] IB/ehca: Default value for Local CA ACK Delay
thanks, applied 1 and 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
This doesn't look right for how it's coded. This would be the CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405. That has a different bit layout among the DBCR registers. Namely, on 405 you would be clearing the TDE and IAC1 events because the DAC events are in DBCR1, not DBCR0. Maybe guarding the 405-specific parts in a separate #if defined(CONFIG_40x) block will do? Do you think it's worth to support this facility on 405's processors? If so, i'll gladly work on a solution to it. Regards, Luis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
Here's a repost of the patch with the suggested changes.
This patch changes the EEH_MAX_FAILS action from panic to printing an
error message. Panicking under under this condition is too harsh.
Although performance will be affected and the device may not recover,
the system is still running, which at the very least should allow for a
more graceful shutdown. The patch also removes the msleep() within a
spinlock, which can lead to a deadlock and is not recommended.
Signed-off-by: Mike Mason [EMAIL PROTECTED]
Acked-by: Linas Vepstas [EMAIL PROTECTED]
--- powerpc.git/arch/powerpc/platforms/pseries/eeh.c2008-07-18
08:51:42.0 -0700
+++ powerpc.git-new/arch/powerpc/platforms/pseries/eeh.c2008-07-21
03:25:43.0 -0700
@@ -75,9 +75,9 @@
*/
/* If a device driver keeps reading an MMIO register in an interrupt
- * handler after a slot isolation event has occurred, we assume it
- * is broken and panic. This sets the threshold for how many read
- * attempts we allow before panicking.
+ * handler after a slot isolation event, it might be broken.
+ * This sets the threshold for how many read attempts we allow
+ * before printing an error message.
*/
#define EEH_MAX_FAILS 210
@@ -470,6 +470,7 @@ int eeh_dn_check_failure(struct device_n
unsigned long flags;
struct pci_dn *pdn;
int rc = 0;
+ const char *location;
total_mmio_ffs++;
@@ -509,18 +510,15 @@ int eeh_dn_check_failure(struct device_n
rc = 1;
if (pdn-eeh_mode EEH_MODE_ISOLATED) {
pdn-eeh_check_count ++;
- if (pdn-eeh_check_count = EEH_MAX_FAILS) {
- printk (KERN_ERR EEH: Device driver ignored %d bad reads,
panicing\n,
- pdn-eeh_check_count);
+ if (pdn-eeh_check_count % EEH_MAX_FAILS == 0) {
+ location = of_get_property(dn, ibm,loc-code, NULL);
+ printk (KERN_ERR EEH: %d reads ignored for recovering
device at
+ location=%s driver=%s pci addr=%s\n,
+ pdn-eeh_check_count, location,
+ dev-driver-name, pci_name(dev));
+ printk (KERN_ERR EEH: Might be infinite loop in %s
driver\n,
+ dev-driver-name);
dump_stack();
- msleep(5000);
-
- /* re-read the slot reset state */
- if (read_slot_reset_state(pdn, rets) != 0)
- rets[0] = -1; /* reset state unknown */
-
- /* If we are here, then we hit an infinite loop. Stop.
*/
- panic(EEH: MMIO halt (%d) on device:%s\n, rets[0],
pci_name(dev));
}
goto dn_unlock;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [HOW] binutils-2.17 breaks the 2.6.26 kernel
From: Segher Boessenkool Previous threads have mentioned that binutil-2.17 is broken for building powerpc kernels. It is fixed in binutils-2.18. I have a working (tested! thanks Milton) workaround for the current problem, will send it later today. This problem funnily is hidden by the presence of build-id :-) Did you ever send this patch? I'd like to try it as I cannot compile a arch/powerpc 2.6.265 kernel right now. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Networkl problems with lastest kernel....
On Mon, 21 Jul 2008 09:31:10 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: If I had a penny for every driver with broken TX queue handling... Please try this patch, thanks: diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index 2e720f2..4e01d29 100644 --- a/drivers/net/ibm_newemac/core.c +++ b/drivers/net/ibm_newemac/core.c @@ -1157,6 +1157,7 @@ static int emac_open(struct net_device *ndev) mal_enable_rx_channel(dev-mal, dev-mal_rx_chan); emac_tx_enable(dev); emac_rx_enable(dev); + netif_start_queue(dev); emac_netif_start(dev); I had to change the dev to an ndev. dev is an struct emac_instance and ndev is the struct net_device. It still crashes, but in a different way. I think the problem is deeper than I thought. The kernel has been OOPSing on a reboot in the nfs_remount or there abouts for a few days. I thought the problem was in a debug driver I was using... so I ignored it for now. But it does it without the debug driver so I think I have a corruption somewhere in the kernel. But I have attached the new OOPS anyway. Cheers, Sean [ cut here ] Kernel BUG at c01ba66c [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] Warp Modules linked in: NIP: c01ba66c LR: c015da58 CTR: REGS: cf839e90 TRAP: 0700 Not tainted (2.6.26-pika) MSR: 00029000 EE,ME CR: 4442 XER: 005f TASK = cf81e880[5] 'events/0' THREAD: cf838000 GPR00: cf839f40 cf81e880 c02fd5a8 cf97856a 0002 0002 GPR08: c02fd5a8 0001 0001 2448 0ffac000 007fff9c GPR16: 00400684 0080 007fff00 0ffa93c4 0002 c02e95f8 c02f c02e95f8 GPR24: c02f c003 cf984404 cf9843d0 cf984000 cf984380 cf984000 NIP [c01ba66c] __netif_schedule+0x28/0x84 LR [c015da58] emac_link_timer+0x704/0x754 Call Trace: [cf839f40] [c015c9f4] __emac_set_multicast_list+0x5c/0xb0 (unreliable) [cf839f60] [c015da58] emac_link_timer+0x704/0x754 [cf839f80] [c002db54] run_workqueue+0x9c/0x138 [cf839fa0] [c002df54] worker_thread+0x50/0xb4 [cf839fd0] [c0031424] kthread+0x84/0x8c [cf839ff0] [c000c518] kernel_thread+0x48/0x64 Instruction dump: 4e800020 4bfffe48 7c0802a6 3d60c030 9421ffe0 396bd5a8 90010024 bfa10014 7c681b78 7c6b5a78 200b 7d605914 0f0b 3922 38030024 7d600028 ---[ end trace 3e8d5079b3c922db ]--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
On Mon, 21 Jul 2008 13:36:33 -0300 Luis Machado [EMAIL PROTECTED] wrote: This doesn't look right for how it's coded. This would be the CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405. That has a different bit layout among the DBCR registers. Namely, on 405 you would be clearing the TDE and IAC1 events because the DAC events are in DBCR1, not DBCR0. Maybe guarding the 405-specific parts in a separate #if defined(CONFIG_40x) block will do? That, or adding a small function to move the bits to the appropriate registers (set_dbcr or set_dac_events). Do you think it's worth to support this facility on 405's processors? If so, i'll gladly work on a solution to it. I would think so. There's really no difference from a userspace perspective, so gdb watchpoints could be valuable there too. I'll leave it up to you though. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Networkl problems with lastest kernel....
From: Sean MacLennan [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 13:05:36 -0400
But I have attached the new OOPS anyway.
The same problem is still there, this driver will
unfortunately require quite a bit more surgery.
You can instead add the following patch, it will
warn instead of BUG on you, and try to continue.
From 867d79fb9a4d5929ad8335c896fcfe11c3b2ef14 Mon Sep 17 00:00:00 2001
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 09:54:18 -0700
Subject: [PATCH] net: In __netif_schedule() use WARN_ON instead of BUG_ON
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
net/core/dev.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7e2d527..cbc34c0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1327,7 +1327,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb,
struct net_device *dev)
void __netif_schedule(struct Qdisc *q)
{
- BUG_ON(q == noop_qdisc);
+ if (WARN_ON_ONCE(q == noop_qdisc))
+ return;
if (!test_and_set_bit(__QDISC_STATE_SCHED, q-state)) {
struct softnet_data *sd;
--
1.5.6.4.433.g09651
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Networkl problems with lastest kernel....
On Mon, 21 Jul 2008 10:16:50 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: The same problem is still there, this driver will unfortunately require quite a bit more surgery. You can instead add the following patch, it will warn instead of BUG on you, and try to continue. Ok, that lets me boot. Thanks. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PIXIS gpio controller and gpio flags
On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
On Fri, 18 Jul 2008, Anton Vorontsov wrote:
+int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
+ const void *gpio_spec)
+{
+ if (gpio[1] PX_GPIO_FLAG_ACTIVE_LOW)
+ px_gc-active_low |= pin2mask(*gpio);
You have a race here. What if px_gpio_xlate() is called at the same time
for different gpios? This is an easy one to fix, since you can use the
atomic bitops.
Thanks, I'll fix this. But I think spinlock would be less cryptic here,
since we have one, and the xlate is called quite rarely anyway.
It doesn't look like you have any way to unset the active low flag. What if
I unload the leds-gpio driver (or another gpio user) and then try to use the
gpio with something else? The active low flag is stuck on!
Why would you want to unset the flags? It is specified in the device
tree, and can't be changed. Specifying different flags for the same GPIO
would be an error (plus, Linux forbids shared gpios, so you simply can't
specify one gpio for several devices).
It doesn't show
in sysfs or debugfs either. That could be very confusing.
It is in the /proc/device-tree. But I agree, it would be great if
/sys/debug/gpio would show active-low gpios. But this would need gpiolib
changes, with which David will not agree, I suppose. But I didn't try.
I also wonder if it's ok to have the xlate function do flag setting?
Why not? Of course, we can implement of_gpio_is_active_low(device_node,
gpion), but this is just less convenient than handling active-low gpios
transparently (i.e. for pure OF drivers you don't have to do all
this if (active_low) in the drivers themselves).
of_get_property() just gets the property, it doesn't allocate it. Same with
of_get_address() and of_get_pci_address(), they don't actually allocate or
map an address, they just get the value. of_get_gpio() doesn't allocate the
gpio, that gets done later with gpio_request(). It seems like what it's
supposed to do is just get the translated value of the gpio property.
Yes, it translates gpio value, and its flags, it also caches the flag
so that further gpio_ calls could use it. But the flags for the
particular gpio is constant. So each xlate must end up with the same
active-low flag, otherwise you did something wrong.
Except, your pixis gpio xlate function sets the gpio's flags. What if one
wants to just look up a gpio number, but not allocate it? The flags will
still get set.
Nothing is allocated.
Most gpio users, including leds-gpio, can handle gpios being busy. If
leds-gpio can't get one of the gpios, it rolls back all the leds it did
create, doesn't drive the device and returns EBUSY. Except with
of_get_gpio() setting the flags, it will change the flags out from under
whatever had the gpio already allocated!
You're still assuming that something was allocated. It wasn't. The flag
was set, and it should not change. It is irrelevant if request() failed
or not.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] elf loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value power5+. This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be power5+ and AT_BASE_PLATFORM will be power6. The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
Andrew Morton wrote:
OK.
But it conflicts directly with the already-queued
execve-filename-document-and-export-via-auxiliary-vector.patch (which
various potential reviewers blithely deleted - don't come complaining
to me!):
Rebased to -mm to resolve conflicts with
execve-filename-document-and-export-via-auxiliary-vector.patch, and
changed AT_BASE_PLATFORM to lowest unclaimed value (24).
fs/binfmt_elf.c| 28
include/linux/auxvec.h |6 +-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index bad7d87..180f92b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,15 @@ static int padzero(unsigned long elf_bss)
#define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
#endif
+#ifndef ELF_BASE_PLATFORM
+/*
+ * AT_BASE_PLATFORM indicates the real hardware/microarchitecture.
+ * If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
+ * will be copied to the user stack in the same manner as AT_PLATFORM.
+ */
+#define ELF_BASE_PLATFORM NULL
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -142,7 +151,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
elf_addr_t __user *envp;
elf_addr_t __user *sp;
elf_addr_t __user *u_platform;
+ elf_addr_t __user *u_base_platform;
const char *k_platform = ELF_PLATFORM;
+ const char *k_base_platform = ELF_BASE_PLATFORM;
int items;
elf_addr_t *elf_info;
int ei_index = 0;
@@ -172,6 +183,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
return -EFAULT;
}
+ /*
+* If this architecture has a base platform capability
+* string, copy it to userspace.
+*/
+ u_base_platform = NULL;
+ if (k_base_platform) {
+ size_t len = strlen(k_base_platform) + 1;
+
+ u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
+ if (__copy_to_user(u_base_platform, k_base_platform, len))
+ return -EFAULT;
+ }
+
/* Create the ELF interpreter info */
elf_info = (elf_addr_t *)current-mm-saved_auxv;
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
@@ -209,6 +233,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
}
+ if (k_base_platform) {
+ NEW_AUX_ENT(AT_BASE_PLATFORM,
+ (elf_addr_t)(unsigned long)u_base_platform);
+ }
if (bprm-interp_flags BINPRM_FLAGS_EXECFD) {
NEW_AUX_ENT(AT_EXECFD, bprm-interp_data);
}
diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
index 0da17d1..d7afa9d 100644
--- a/include/linux/auxvec.h
+++ b/include/linux/auxvec.h
@@ -26,9 +26,13 @@
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_BASE_PLATFORM 24/* string identifying real platform, may
+* differ from AT_PLATFORM. */
+
#define AT_EXECFN 31 /* filename of program */
+
#ifdef __KERNEL__
-#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
+#define AT_VECTOR_SIZE_BASE 18 /* NEW_AUX_ENT entries in auxiliary table */
/* number of #define AT_.* above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */
#endif
--
1.5.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
Hi Milton,
I am resending the patches generated against latest powerpc git tree.
I am facing kdump kernel hang issue with the git tree. It hangs in
unflatten_devicetree call in prom.c
Note: These patches are not fully tested.
Regards,
Mohan.
Extract list of relocation offsets
Extract list of offsets in the vmlinux file for which the relocation
delta has to be patched. Currently only following type of relocation
types are considered: R_PPC64_ADDR16_HI, R_PPC64_TOC and R_PPC64_ADDR64
The offsets are sorted according to the relocation type and this
information is appended to the normal vmlinux file by using the patch
relocation_build.patch
Signed-off-by: Mohan Kumar M [EMAIL PROTECTED]
---
arch/powerpc/boot/relocs.c | 865
1 files changed, 865 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/relocs.c
diff --git a/arch/powerpc/boot/relocs.c b/arch/powerpc/boot/relocs.c
new file mode 100644
index 000..31ca903
--- /dev/null
+++ b/arch/powerpc/boot/relocs.c
@@ -0,0 +1,865 @@
+#include stdio.h
+#include stdarg.h
+#include stdlib.h
+#include stdint.h
+#include string.h
+#include errno.h
+#include unistd.h
+#include elf.h
+#include byteswap.h
+#define USE_BSD
+#include endian.h
+
+#define MAX_SHDRS 100
+static Elf64_Ehdr ehdr;
+static Elf64_Shdr shdr[MAX_SHDRS];
+static Elf64_Sym *symtab[MAX_SHDRS];
+static Elf64_Rel *reltab[MAX_SHDRS];
+static Elf64_Rela *reltaba[MAX_SHDRS];
+static char *strtab[MAX_SHDRS];
+static unsigned long reloc_count, reloc_idx;
+
+struct reloc_info {
+ unsigned int rel_type;
+ unsigned long long offset;
+};
+
+static struct reloc_info *relocs;
+
+/*
+ * Following symbols have been audited. There values are constant and do
+ * not change if bzImage is loaded at a different physical address than
+ * the address for which it has been compiled. Don't warn user about
+ * absolute relocations present w.r.t these symbols.
+ */
+static const char* safe_abs_relocs[] = {
+ __kernel_vsyscall,
+ __kernel_rt_sigreturn,
+ __kernel_sigreturn,
+ SYSENTER_RETURN,
+};
+
+static int is_safe_abs_reloc(const char* sym_name)
+{
+ int i, array_size;
+
+ array_size = sizeof(safe_abs_relocs)/sizeof(char*);
+
+ for(i = 0; i array_size; i++) {
+ if (!strcmp(sym_name, safe_abs_relocs[i]))
+ /* Match found */
+ return 1;
+ }
+ if (strncmp(sym_name, __crc_, 6) == 0)
+ return 1;
+ return 0;
+}
+
+static void die(char *fmt, ...)
+{
+ va_list ap;
+ va_start(ap, fmt);
+ vfprintf(stderr, fmt, ap);
+ va_end(ap);
+ exit(1);
+}
+
+static const char *sym_type(unsigned type)
+{
+ static const char *type_name[] = {
+#define SYM_TYPE(X) [X] = #X
+ SYM_TYPE(STT_NOTYPE),
+ SYM_TYPE(STT_OBJECT),
+ SYM_TYPE(STT_FUNC),
+ SYM_TYPE(STT_SECTION),
+ SYM_TYPE(STT_FILE),
+ SYM_TYPE(STT_COMMON),
+ SYM_TYPE(STT_TLS),
+#undef SYM_TYPE
+ };
+ const char *s_type = unknown sym type name;
+ if (type sizeof(type_name)/sizeof(type_name[0])) {
+ s_type = type_name[type];
+ }
+ return s_type;
+}
+
+static const char *sym_bind(unsigned bind)
+{
+ static const char *bind_name[] = {
+#define SYM_BIND(X) [X] = #X
+ SYM_BIND(STB_LOCAL),
+ SYM_BIND(STB_GLOBAL),
+ SYM_BIND(STB_WEAK),
+#undef SYM_BIND
+ };
+ const char *s_bind = unknown sym bind name;
+ if (bind sizeof(bind_name)/sizeof(bind_name[0])) {
+ s_bind = bind_name[bind];
+ }
+ return s_bind;
+}
+
+static const char *sym_visibility(unsigned visibility)
+{
+ static const char *visibility_name[] = {
+#define SYM_VISIBILITY(X) [X] = #X
+ SYM_VISIBILITY(STV_DEFAULT),
+ SYM_VISIBILITY(STV_INTERNAL),
+ SYM_VISIBILITY(STV_HIDDEN),
+ SYM_VISIBILITY(STV_PROTECTED),
+#undef SYM_VISIBILITY
+ };
+ const char *name = unknown sym visibility name;
+ if (visibility sizeof(visibility_name)/sizeof(visibility_name[0])) {
+ name = visibility_name[visibility];
+ }
+ return name;
+}
+
+static const char *rel_type(unsigned type)
+{
+ static const char *type_name[] = {
+#define REL_TYPE(X) [X] = #X
+ REL_TYPE(R_PPC64_NONE),
+ REL_TYPE(R_PPC64_ADDR32),
+ REL_TYPE(R_PPC64_ADDR24),
+ REL_TYPE(R_PPC64_ADDR16),
+ REL_TYPE(R_PPC64_ADDR16_LO),
+ REL_TYPE(R_PPC64_ADDR16_HI),
+ REL_TYPE(R_PPC64_ADDR16_HA),
+ REL_TYPE(R_PPC64_ADDR14 ),
+ REL_TYPE(R_PPC64_ADDR14_BRTAKEN),
+ REL_TYPE(R_PPC64_ADDR14_BRNTAKEN),
+ REL_TYPE(R_PPC64_REL24),
+ REL_TYPE(R_PPC64_REL14),
+ REL_TYPE(R_PPC64_REL14_BRTAKEN),
+ REL_TYPE(R_PPC64_REL14_BRNTAKEN),
+ REL_TYPE(R_PPC64_GOT16),
+ REL_TYPE(R_PPC64_GOT16_LO),
+ REL_TYPE(R_PPC64_GOT16_HI),
+ REL_TYPE(R_PPC64_GOT16_HA),
+ REL_TYPE(R_PPC64_COPY),
+ REL_TYPE(R_PPC64_GLOB_DAT),
+ REL_TYPE(R_PPC64_JMP_SLOT),
+ REL_TYPE(R_PPC64_RELATIVE),
+ REL_TYPE(R_PPC64_UADDR32),
+ REL_TYPE(R_PPC64_UADDR16),
+ REL_TYPE(R_PPC64_REL32),
+ REL_TYPE(R_PPC64_PLT32),
+ REL_TYPE(R_PPC64_PLTREL32),
+ REL_TYPE(R_PPC64_PLT16_LO),
+ REL_TYPE(R_PPC64_PLT16_HI),
+ REL_TYPE(R_PPC64_PLT16_HA),
+ REL_TYPE(R_PPC64_SECTOFF),
+ REL_TYPE(R_PPC64_SECTOFF_LO),
+ REL_TYPE(R_PPC64_SECTOFF_HI),
+
Re: [RFC v3 PATCH 2/4] Build files needed for relocation
Build files needed for relocation This patch builds vmlinux file with relocation sections and contents so that relocs user space program can extract the required relocation offsets. This packs final relocatable vmlinux kernel as following: earlier part of relocation apply code, vmlinux, rest of relocation apply code. TODO: Relocatable vmlinux image is built in arch/powerpc/boot as vmlinux.reloc. But it should be built in top level directory of kernel source as vmlinux instead of vmlinux.reloc Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- arch/powerpc/Kconfig| 15 ++-- arch/powerpc/Makefile |9 ++- arch/powerpc/boot/Makefile | 39 -- arch/powerpc/boot/vmlinux.lds.S | 28 + arch/powerpc/boot/vmlinux.reloc.scr |8 +++ 5 files changed, 91 insertions(+), 8 deletions(-) create mode 100644 arch/powerpc/boot/vmlinux.lds.S create mode 100644 arch/powerpc/boot/vmlinux.reloc.scr diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index f2a0f50..366a622 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -317,6 +317,15 @@ config CRASH_DUMP Don't change this unless you know what you are doing. +config RELOCATABLE_PPC64 + bool Build a relocatable kernel (EXPERIMENTAL) + depends on PPC_MULTIPLATFORM PPC64 CRASH_DUMP EXPERIMENTAL + help + Build a kernel suitable for use as regular kernel and kdump capture + kernel. + + Don't change this unless you know what you are doing. + config PHYP_DUMP bool Hypervisor-assisted dump (EXPERIMENTAL) depends on PPC_PSERIES EXPERIMENTAL @@ -662,7 +671,7 @@ config LOWMEM_SIZE default 0x3000 config RELOCATABLE - bool Build a relocatable kernel (EXPERIMENTAL) + bool Build relocatable kernel (EXPERIMENTAL) depends on EXPERIMENTAL ADVANCED_OPTIONS FLATMEM FSL_BOOKE help This builds a kernel image that is capable of running at the @@ -782,11 +791,11 @@ config PAGE_OFFSET default 0xc000 config KERNEL_START hex - default 0xc200 if CRASH_DUMP + default 0xc200 if CRASH_DUMP !RELOCATABLE_PPC64 default 0xc000 config PHYSICAL_START hex - default 0x0200 if CRASH_DUMP + default 0x0200 if CRASH_DUMP !RELOCATABLE_PPC64 default 0x endif diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 59ae7d9..58ccb7f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -63,7 +63,7 @@ override CC += -m$(CONFIG_WORD_SIZE) override AR := GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR) endif -LDFLAGS_vmlinux := -Bstatic +LDFLAGS_vmlinux := --emit-relocs CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple @@ -146,11 +146,16 @@ core-$(CONFIG_KVM) += arch/powerpc/kvm/ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ # Default to zImage, override when needed + +ifneq ($(CONFIG_RELOCATABLE_PPC64),y) all: zImage +else +all: zImage vmlinux.reloc +endif CPPFLAGS_vmlinux.lds := -Upowerpc -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.% +BOOT_TARGETS = zImage vmlinux.reloc zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.% PHONY += $(BOOT_TARGETS) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 751a6e6..1a62036 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -17,7 +17,7 @@ # CROSS32_COMPILE is setup as a prefix just like CROSS_COMPILE # in the toplevel makefile. -all: $(obj)/zImage +all: $(obj)/zImage $(obj)/vmlinux.reloc BOOTCFLAGS:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -Os -msoft-float -pipe \ @@ -122,18 +122,51 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S FORCE $(obj)/wrapper.a: $(obj-wlib) FORCE $(call if_changed,bootar) -hostprogs-y := addnote addRamDisk hack-coff mktree dtc +hostprogs-y := addnote addRamDisk hack-coff mktree dtc relocs targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a) extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \ $(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds +ifeq ($(CONFIG_RELOCATABLE_PPC64),y) +extra-y += $(obj)/vmlinux.lds +endif + dtstree := $(srctree)/$(src)/dts wrapper :=$(srctree)/$(src)/wrapper -wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \ +wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc relocs) \ $(wrapper) FORCE +ifeq ($(CONFIG_RELOCATABLE_PPC64),y) + +targets += vmlinux.offsets vmlinux.bin vmlinux.bin.all vmlinux.reloc.elf vmlinux.reloc reloc_apply.o vmlinux.lds + +OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S +$(obj)/vmlinux.bin: vmlinux FORCE + $(call if_changed,objcopy) + +quiet_cmd_relocbin = BUILD $@ + cmd_relocbin = cat $(filter-out FORCE,$^) $@ +
Re: [RFC v3 PATCH 3/4] Apply relocation
Apply relocation This code is a wrapper around regular kernel. This checks whether the kernel is loaded at 32MB, if its not loaded at 32MB, its treated as a regular kernel and the control is given to the kernel immediately. If the kernel is loaded at 32MB, it applies relocation delta to each offset in the list which was generated and appended by patch 1 and 2. After updating all offsets, control is given to relocatable kernel. Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- arch/powerpc/boot/reloc_apply.S | 229 +++ 1 files changed, 229 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/reloc_apply.S diff --git a/arch/powerpc/boot/reloc_apply.S b/arch/powerpc/boot/reloc_apply.S new file mode 100644 index 000..4049976 --- /dev/null +++ b/arch/powerpc/boot/reloc_apply.S @@ -0,0 +1,229 @@ +#include asm/ppc_asm.h + +#define RELOC_DELTA 0x4200 + +#define LOADADDR(rn,name) \ + lis rn,[EMAIL PROTECTED]; \ + ori rn,rn,[EMAIL PROTECTED]; \ + rldicr rn,rn,32,31; \ + orisrn,rn,[EMAIL PROTECTED]; \ + ori rn,rn,[EMAIL PROTECTED] + + +/* + * Layout of vmlinux.reloc file + * Minimal part of relocation applying code + + * vmlinux + + * Rest of the relocation applying code + */ + +.section .text.head + +.globl start_wrap +start_wrap: + /* Get relocation offset in r15 */ + bl 1f +1: mflr r15 + LOAD_REG_IMMEDIATE(r16,1b) + subf r15,r16,r15 + + LOAD_REG_IMMEDIATE(r17, _reloc) + add r17,r17,r15 + mtctr r17 + bctr /* Jump to start_reloc in section .text.reloc */ + +/* Secondary cpus spin code */ +. = 0x60 + /* Get relocation offset in r15 */ + bl 1f +1: mflr r15 + LOAD_REG_IMMEDIATE(r16,1b) + subf r15,r16,r15 + + LOADADDR(r18, __spinloop) + add r18,r18,r15 +100: ld r19,0(r18) + cmpwi 0,r19,1 + bne 100b + + LOAD_REG_IMMEDIATE(r17, _reloc) + add r17,r17,r15 + addi r17,r17,0x60 + mtctr r17 + /* Jump to start_reloc + 0x60 in section .text.reloc */ + bctr + +/* + * Layout of vmlinux.reloc file + * Minimal part of relocation applying code + + * vmlinux + + * Rest of the relocation applying code + */ + + +.section .text.reloc + +start_reloc: + b master + +.org start_reloc + 0x60 + LOADADDR(r18, __spinloop) + add r18,r18,r15 +100: ld r19,0(r18) + cmpwi 0,r19,2 + bne 100b + + /* Now vmlinux is at _head */ + LOAD_REG_IMMEDIATE(r17, _head) + add r17,r17,r15 + addi r17,r17,0x60 + mtctr r17 + bctr + +master: + LOAD_REG_IMMEDIATE(r16, output_len) + add r16,r16,r15 + + /* + * Load the delimiter to distinguish between different relocation + * types + */ + LOAD_REG_IMMEDIATE(r24, __delimiter) + add r24,r24,r15 + ld r24,0(r24) + + LOAD_REG_IMMEDIATE(r17, _head) + LOAD_REG_IMMEDIATE(r21, _ehead) + sub r21,r21,r17 /* Number of bytes in head section */ + + sub r16,r16,r21 /* Original output_len */ + + /* Destination address */ + LOAD_REG_IMMEDIATE(r17, _head) /* KERNELBASE */ + add r17,r17,r15 + + /* Source address */ + LOAD_REG_IMMEDIATE(r18, _text) /* Regular vmlinux */ + add r18,r18,r15 + + /* Number of bytes to copy */ + LOAD_REG_IMMEDIATE(r19, _etext) + add r19,r19,r15 + sub r19,r19,r18 + + /* Move cpu spin code to text.reloc section */ + LOADADDR(r23, __spinloop) + add r23,r23,r15 + li r25,1 + stw r25,0(r23) + + /* Copy vmlinux code to physical address 0 */ + bl .copy /* copy(_head, _text, _etext-_text) */ + + /* + * If its not running at 32MB, assume it to be a normal kernel. + * Copy the vmlinux code to KERNELBASE and jump to KERNELBASE + */ + LOAD_REG_IMMEDIATE(r21, RELOC_DELTA) + cmpd r15,r21 + beq apply_relocation + li r6,0 + b skip_apply +apply_relocation: + + /* Kernel is running at 32MB */ + mr r22,r15 + xor r23,r23,r23 + addi r23,r23,16 + srw r22,r22,r23 + + li r25,0 + + LOAD_REG_IMMEDIATE(r26, _head) + + /* + * Start reading the relocation offset list from end of file + * Based on the relocation type either add the relocation delta + * or do logical ORing the relocation delta + */ +3: + addi r16,r16,-8 + ld r18,0(r16) + cmpdi r18,0 /* Processed all offsets */ + beq 4f /* Start vmlinux */ + /* Are we processing reloction type R_PPC64_ADDR16_HI */ + cmpdi r25,1 + beq rel_hi + cmpd r18,r24 + beq set_rel_hi + /* Process 64bit absolute relocation update */ +rel_addr64: + add r18,r18,r15 + ld r28,0(r18) + cmpdi r28,0 + beq next + add r28,r28,r15 /* add relocation offset */ + add r28,r28,r26 /* add KERNELBASE */ + std r28,0(r18) + b next +set_rel_hi: /* Enable R_PPC64_ADDR16_HI flag */ + addi r25,r25,1 + b 3b +rel_hi: + add r18,r18,r15 + lhz r28,0(r18) + or r28,r28,r22 + sth r28,0(r18) +next: + b 3b +4: + mr r6,r15 + + +skip_apply: + isync + sync + + /* Now vmlinux is at _head */ + LOAD_REG_IMMEDIATE(r17, _head) + add r17,r17,r15 + mtctr r17 + + /* Move cpu spin code to text.reloc section */ + LOADADDR(r23, __spinloop) + add r23,r23,r15 + li r25,2 + stw r25,0(r23) + + bctr + +/* r17 destination, r18 source, r19 size */ +.copy: + addi r19,r19,-8 + li r22,-8 +4: li r21,8 /* Use the smallest common */ + /* denominator cache
using -initrd with qemu-system-ppc
Hi, I'm struggling to get initrd working with qemu-system-ppc. The kernel doesn't seem to be find initrd image passed to qemu-system-ppc. I added printfs in qemu, ppc_rom and in the kernel source code..Looks like qemu is passing the intird to Hackware and hackware rom seems to be setting the bootinfos structure with the initrd information but when it comes to the kernel it doesn't seem to get it. qemu logs show..it read the initrd image ppc_prep_init: START linux boot ppc_prep_init: INSIDE linux boot: /tmp/initrd.img ppc_prep_init: INSIDE INITRD ppc_prep_init: INSIDE INITRD filename: /tmp/initrd.img size: 31457280 hackware logs i added also shows initrd is read from nvram and its put in the bootinfos and passed. bootinfos..initrd: 31457280 bootinfos..memsize:0x2f40 Boot: 0004 32eb1500 Bootinfos at : 30 But the kernel didn;t find the BI_INITRD tag (0x1014). But it found the BI_CMDLINE and BI_MEMSIZE tags but not initrd. Now booting the kernel RAMDISK platform_init..calling boot_info RAMDISK find_bootinfo RAMDISK parser_booinfo RAMDISK BI tag: 0x1010 RAMDISK BI tag: 0x1017 RAMDISK memsize: 0x2f40 RAMDISK BI tag: 0x1012 RAMDISK cmdline: console=ttyS0 ip=dhcp rw netdev=9,0x300,eth0 netdev=10,0x320,eth1 netdev=11,0x340,eth2 netdev=3,0x360,eth3 netdev=4,0x280,eth4 netdev=5,0x380,eth5 RAMDISK parser_booinfo end IP-Config: Got DHCP answer from 10.0.2.2, my address is 10.0.2.15 IP-Config: Complete: device=eth0, addr=10.0.2.15, mask=255.255.255.0, gw=10.0.2.2, host=10.0.2.15, domain=, nis-domain=(none), bootserver=10.0.2.2, rootserver=10.0.2.2, rootpath= RAMDISK: no file foundi No filesystem could mount root, tried: ext3 ext2 iso9660 I'm stumped..May be the kernel is reading a different bootinfos..I'm not sure where the problem is. I made sure the CONFIG_BLK_DEV_INITRD is enabled and the printfs I added are outside of the CONFIG_BLK_DEV_INITRD check. I'm using the 0.9.1 version and the kernel is 2.6.18 Please help me figure this out..I have attached the complete log. thanks Suresh [EMAIL PROTECTED] ~]$/ws/skaliann/opt/qemu-0.9.1/ppc-softmmu/qemu-system-ppc -L /users/skaliann/qemu/share/qemu -M prep -kernel /tmp/zImage.prep -nographic -m 756 -redir tcp:1122::22 -redir tcp:2345::2345 -initrd /tmp/initrd.img -append root=/dev/ram ppc_prep_init: START linux boot ppc_prep_init: INSIDE linux boot: /tmp/initrd.img ppc_prep_init: INSIDE INITRD ppc_prep_init: INSIDE INITRD filename: /tmp/initrd.img size: 31457280 ppc_prep_init: OUTSIDE base=0x180 Size: 31457280NVRAM set: base: 0x180 size: 31457280 register PCI host 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' register 'pci-bridge' 'pci' 'null' 'PREP Host PCI Bridge - Motorola Raven' 0x8000 in 'device-tree' 0x Done 582a000 582a900 register pci device 'Qemu VGA' 000c 'display' 'VGA' 'Qemu VGA' register 'Qemu VGA' 'display' 'VGA' 'Qemu VGA' 0x000c in 'pci-bridge' 0x8000 Done 582a900 582aa00 PPC Open Hack'Ware BIOS for qemu version 0.4.1 Build 2008-07-18 22:17:00 Copyright 2003-2005 Jocelyn Mayer Memory size: 756 MB. Booting from device m ide0: drive 0: none ide0: drive 1: CD-ROM ERROR: OF_property_copy cannot get property 'cd' for aliases ERROR: ATAPI TEST_UNIT_READY : status 48 != 0x08 ide1: drive 0: none ide1: drive 1: none Probe partitions for device m ERROR: No MSDOS signature (38 0 0 0) New bootfile ERROR: OF_property_copy cannot get property 'alias' for null boot device: 5831080 image 100 size 1436466 New bootfile New bootfile Fix bootfile boot device: 5831080 ERROR: Found boot partition : 5831200 582d6c0 ERROR: Not a MACH-O file ERROR: Not an Apple CHRP boot file ! dest 10 entry 0200 = 100200 Load raw file into memory at 10 1436466 (0015eb32) 0 () bootinfos..initrd: 31457280 bootinfos..memsize:0x2f40 Boot: 0004 32eb1500 Bootinfos at : 30 Now boot it... (0) stack: 5bfff80 malloc_base: 0 0x0580 0x0600 PREP boot... 100200 10 loaded at: 00100200 00265D4C relocated to: 0080 00965B4C zimage at: 00805F64 0095CC98 avail ram: 0040 0080 Linux/PPC load: decompress_kernel: new cmd_line='console=ttyS0 ip=dhcp rw netdev=9,0x300,eth0 netdev=10,0x320,eth1 netdev=11,0x340,eth2 netdev=3,0x360,eth3 netdev=4,0x280,eth4 netdev=5,0x380,eth5 root=/dev/ram' console=ttyS0 ip=dhcp rw netdev=9,0x300,eth0 netdev=10,0x320,eth1 netdev=11,0x340,eth2 netdev=3,0x360,eth3 netdev=4,0x280,eth4 netdev=5,0x380,eth5 root=/dev/ram Uncompressing Linux...done. Now booting the kernel RAMDISK platform_init..calling boot_info RAMDISK find_bootinfo RAMDISK parser_booinfo RAMDISK BI tag: 0x1010 RAMDISK BI tag: 0x1017 RAMDISK memsize: 0x2f40 RAMDISK BI tag: 0x1012 RAMDISK cmdline: console=ttyS0 ip=dhcp rw netdev=9,0x300,eth0 netdev=10,0x320,eth1 netdev=11,0x340,eth2 netdev=3,0x360,eth3 netdev=4,0x280,eth4 netdev=5,0x380,eth5 root=/dev/ram RAMDISK parser_booinfo end Total memory = 756MB;
Re: [RFC v3 PATCH 4/4] Relocation support
I split the patch 4: Relocation support into 3 patches 1. Generic kernel support for relocatable 2. Kdump kernel support for relocatable 3. LOAD_REG_IMMEDIATE macro replacement Relocation support Add relocatable kernel support like take care when accessing absolute symbols in the code by adding the relocation kernel base address. Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- arch/powerpc/kernel/head_64.S | 53 ++- arch/powerpc/kernel/machine_kexec_64.c |4 +- arch/powerpc/kernel/prom_init.c| 27 ++-- arch/powerpc/kernel/prom_init_check.sh |2 +- arch/powerpc/kernel/setup_64.c |5 +-- arch/powerpc/mm/init_64.c |7 ++-- arch/powerpc/mm/mem.c |3 +- include/asm-powerpc/prom.h |2 + include/asm-powerpc/sections.h |4 ++- include/asm-powerpc/system.h |5 +++ 10 files changed, 95 insertions(+), 17 deletions(-) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index ecced1e..8adf3b5 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -102,6 +102,12 @@ __secondary_hold_acknowledge: .llong hvReleaseData-KERNELBASE #endif /* CONFIG_PPC_ISERIES */ +#ifdef CONFIG_RELOCATABLE_PPC64 + /* Used as static variable to initialize the reloc_delta */ +__initialized: + .long 0x0 +#endif + . = 0x60 /* * The following code is used to hold secondary processors @@ -1247,6 +1253,38 @@ _STATIC(__mmu_off) * */ _GLOBAL(__start_initialization_multiplatform) +#ifdef CONFIG_RELOCATABLE_PPC64 + mr r21,r3 + mr r22,r4 + mr r23,r5 + bl .reloc_offset + mr r26,r3 + mr r3,r21 + mr r4,r22 + mr r5,r23 + + LOAD_REG_IMMEDIATE(r27, __initialized) + add r27,r26,r27 + ld r7,0(r27) + cmpdi r7,0 + bne 4f + + li r7,1 + stw r7,0(r27) + + cmpdi r6,0 + beq 4f + LOAD_REG_IMMEDIATE(r27, reloc_delta) + add r27,r27,r26 + std r6,0(r27) + + LOAD_REG_IMMEDIATE(r27, KERNELBASE) + add r7,r6,r27 + LOAD_REG_IMMEDIATE(r27, kernel_base) + add r27,r27,r26 + std r7,0(r27) +4: +#endif /* * Are we booted from a PROM Of-type client-interface ? */ @@ -1322,6 +1360,19 @@ _INIT_STATIC(__boot_from_prom) trap _STATIC(__after_prom_start) + bl .reloc_offset + mr r26,r3 +#ifdef CONFIG_RELOCATABLE_PPC64 + /* + * If its a relocatable kernel, no need to copy the kernel + * to PHYSICAL_START. Continue running from the same location + */ + LOAD_REG_IMMEDIATE(r27, reloc_delta) + add r27,r27,r26 + ld r28,0(r27) + cmpdi r28,0 + bne .start_here_multiplatform +#endif /* * We need to run with __start at physical address PHYSICAL_START. @@ -1335,8 +1386,6 @@ _STATIC(__after_prom_start) * r26 == relocation offset * r27 == KERNELBASE */ - bl .reloc_offset - mr r26,r3 LOAD_REG_IMMEDIATE(r27, KERNELBASE) LOAD_REG_IMMEDIATE(r3, PHYSICAL_START) /* target addr */ diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c index 631dfd6..09ce39d 100644 --- a/arch/powerpc/kernel/machine_kexec_64.c +++ b/arch/powerpc/kernel/machine_kexec_64.c @@ -43,7 +43,7 @@ int default_machine_kexec_prepare(struct kimage *image) * overlaps kernel static data or bss. */ for (i = 0; i image-nr_segments; i++) - if (image-segment[i].mem __pa(_end)) + if (image-segment[i].mem (__pa(_end) + kernel_base)) return -ETXTBSY; /* @@ -317,7 +317,7 @@ static void __init export_htab_values(void) if (!node) return; - kernel_end = __pa(_end); + kernel_end = __pa(_end) + kernel_base; prom_add_property(node, kernel_end_prop); /* On machines with no htab htab_address is NULL */ diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 1ea8c8d..1b67219 100644 --- a/arch/powerpc/kernel/prom_init.c +++ b/arch/powerpc/kernel/prom_init.c @@ -91,11 +91,9 @@ extern const struct linux_logo logo_linux_clut224; * fortunately don't get interpreted as two arguments). */ #ifdef CONFIG_PPC64 -#define RELOC(x)(*PTRRELOC((x))) #define ADDR(x) (u32) add_reloc_offset((unsigned long)(x)) #define OF_WORKAROUNDS 0 #else -#define RELOC(x) (x) #define ADDR(x) (u32) (x) #define OF_WORKAROUNDS of_workarounds int of_workarounds; @@ -1073,7 +1071,12 @@ static void __init prom_init_mem(void) } } +#ifndef CONFIG_RELOCATABLE_PPC64 RELOC(alloc_bottom) = PAGE_ALIGN((unsigned long)RELOC(_end) + 0x4000); +#else + RELOC(alloc_bottom) = PAGE_ALIGN((unsigned long)RELOC(_end) + 0x4000 + + RELOC(reloc_delta)); +#endif /* Check if we have an initrd after the kernel, if we do move our bottom * point to after it @@ -1337,10 +1340,19 @@ static void __init prom_hold_cpus(void) unsigned int cpu_threads, hw_cpu_num; int propsize; struct prom_t *_prom = RELOC(prom); + +#ifndef CONFIG_RELOCATABLE_PPC64 unsigned long *spinloop = (void *) LOW_ADDR(__secondary_hold_spinloop); unsigned long *acknowledge = (void *) LOW_ADDR(__secondary_hold_acknowledge); +#else +
Re: [RFC v3 PATCH 5/4] Relocation support for kdump kernel
Relocation support for kdump kernel
This patch adds relocation support for the kdump kernel path
Signed-off-by: Mohan Kumar M [EMAIL PROTECTED]
---
arch/powerpc/kernel/crash_dump.c | 19 +++
arch/powerpc/kernel/iommu.c|7 -
arch/powerpc/kernel/machine_kexec.c|6
arch/powerpc/kernel/misc.S | 40 +--
arch/powerpc/kernel/prom.c | 13 +-
arch/powerpc/mm/hash_utils_64.c|5 ++-
arch/powerpc/platforms/pseries/iommu.c |5 +++-
7 files changed, 81 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index e0debcc..91d5ad2 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -29,7 +29,12 @@
void __init reserve_kdump_trampoline(void)
{
+#ifdef CONFIG_RELOCATABLE_PPC64
+ if (RELOC(reloc_delta))
+ lmb_reserve(0, KDUMP_RESERVE_LIMIT);
+#else
lmb_reserve(0, KDUMP_RESERVE_LIMIT);
+#endif
}
static void __init create_trampoline(unsigned long addr)
@@ -45,7 +50,11 @@ static void __init create_trampoline(unsigned long addr)
* two instructions it doesn't require any registers.
*/
patch_instruction(p, PPC_NOP_INSTR);
+#ifndef CONFIG_RELOCATABLE_PPC64
patch_branch(++p, addr + PHYSICAL_START, 0);
+#else
+ patch_branch(++p, addr + RELOC(reloc_delta), 0);
+#endif
}
void __init setup_kdump_trampoline(void)
@@ -54,13 +63,23 @@ void __init setup_kdump_trampoline(void)
DBG( - setup_kdump_trampoline()\n);
+#ifdef CONFIG_RELOCATABLE_PPC64
+ if (!RELOC(reloc_delta))
+ return;
+#endif
+
for (i = KDUMP_TRAMPOLINE_START; i KDUMP_TRAMPOLINE_END; i += 8) {
create_trampoline(i);
}
#ifdef CONFIG_PPC_PSERIES
+#ifndef CONFIG_RELOCATABLE_PPC64
create_trampoline(__pa(system_reset_fwnmi) - PHYSICAL_START);
create_trampoline(__pa(machine_check_fwnmi) - PHYSICAL_START);
+#else
+ create_trampoline(__pa(system_reset_fwnmi) - RELOC(reloc_delta));
+ create_trampoline(__pa(machine_check_fwnmi) - RELOC(reloc_delta));
+#endif
#endif /* CONFIG_PPC_PSERIES */
DBG( - setup_kdump_trampoline()\n);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 0c66366..ccd98c2 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -473,7 +473,7 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
spin_lock_init(tbl-it_lock);
#ifdef CONFIG_CRASH_DUMP
- if (ppc_md.tce_get) {
+ if (reloc_delta ppc_md.tce_get) {
unsigned long index;
unsigned long tceval;
unsigned long tcecount = 0;
@@ -499,7 +499,10 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
index tbl-it_size; index++)
__clear_bit(index, tbl-it_map);
}
- }
+ } else
+ /* Clear the hardware table in case firmware left allocations
+ in it */
+ ppc_md.tce_free(tbl, tbl-it_offset, tbl-it_size);
#else
/* Clear the hardware table in case firmware left allocations in it */
ppc_md.tce_free(tbl, tbl-it_offset, tbl-it_size);
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index 29a0e03..f2ed554 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -67,6 +67,12 @@ void __init reserve_crashkernel(void)
unsigned long long crash_size, crash_base;
int ret;
+#ifdef CONFIG_RELOCATABLE_PPC64
+ /* Return if its kdump kernel */
+ if (reloc_delta)
+ return;
+#endif
+
/* this is necessary because of lmb_phys_mem_size() */
lmb_analyze();
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 85cb6f3..28718ed 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -20,6 +20,8 @@
#include asm/asm-compat.h
#include asm/asm-offsets.h
+#define RELOC_DELTA 0x4200
+
.text
/*
@@ -33,6 +35,17 @@ _GLOBAL(reloc_offset)
1: mflr r3
LOAD_REG_IMMEDIATE(r4,1b)
subf r3,r4,r3
+#ifdef CONFIG_RELOCATABLE_PPC64
+ LOAD_REG_IMMEDIATE(r5, RELOC_DELTA)
+ cmpd r3,r5
+ bne 2f
+ /*
+ * Don't return the offset if the difference is
+ * RELOC_DELTA
+ */
+ li r3,0
+2:
+#endif
mtlr r0
blr
@@ -40,14 +53,25 @@ _GLOBAL(reloc_offset)
* add_reloc_offset(x) returns x + reloc_offset().
*/
_GLOBAL(add_reloc_offset)
- mflr r0
- bl 1f
-1: mflr r5
- LOAD_REG_IMMEDIATE(r4,1b)
- subf r5,r4,r5
- add r3,r3,r5
- mtlr r0
- blr
+mflrr0
+bl 1f
+1: mflrr5
+LOAD_REG_IMMEDIATE(r4,1b)
+subfr5,r4,r5
+#ifdef CONFIG_RELOCATABLE_PPC64
+ LOAD_REG_IMMEDIATE(r4, RELOC_DELTA)
+ cmpd r5,r4
+ bne 2f
+ /*
+ * Don't add the offset if the difference is
+ * RELOC_DELTA
+ */
+ li r5,0
+2:
+#endif
+add r3,r3,r5
+mtlrr0
+blr
_GLOBAL(kernel_execve)
li r0,__NR_execve
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 87d83c5..453dc98 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -65,6 +65,9 @@
Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
Use LOAD_REG_IMMEDIATE macros This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE to make sure that we load the correct address. Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- arch/powerpc/kernel/entry_64.S |4 ++-- arch/powerpc/mm/hash_low_64.S |8 arch/powerpc/mm/slb_low.S |2 +- arch/powerpc/platforms/pseries/hvCall.S |2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index 12eb95a..37e5d95 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -714,7 +714,7 @@ _GLOBAL(enter_rtas) std r6,PACASAVEDMSR(r13) /* Setup our real return addr */ - LOAD_REG_ADDR(r4,.rtas_return_loc) + LOAD_REG_IMMEDIATE(r4,.rtas_return_loc) clrldi r4,r4,2 /* convert to realmode address */ mtlr r4 @@ -730,7 +730,7 @@ _GLOBAL(enter_rtas) sync/* disable interrupts so SRR0/1 */ mtmsrd r0 /* don't get trashed */ - LOAD_REG_ADDR(r4, rtas) + LOAD_REG_IMMEDIATE(r4, rtas) ld r5,RTASENTRY(r4) /* get the rtas-entry value */ ld r4,RTASBASE(r4) /* get the rtas-base value */ diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S index a719f53..e9ba872 100644 --- a/arch/powerpc/mm/hash_low_64.S +++ b/arch/powerpc/mm/hash_low_64.S @@ -83,7 +83,7 @@ _GLOBAL(__hash_page_4K) std r29,STK_REG(r29)(r1) std r30,STK_REG(r30)(r1) std r31,STK_REG(r31)(r1) - + /* Step 1: * * Check permissions, atomically mark the linux PTE busy @@ -168,7 +168,7 @@ END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FTR_COHERENT_ICACHE, CPU_FTR_NOEXECUTE) std r3,STK_PARM(r4)(r1) /* Get htab_hash_mask */ - ld r4,[EMAIL PROTECTED](2) + LOAD_REG_IMMEDIATE(r4, htab_hash_mask) ld r27,0(r4) /* htab_hash_mask - r27 */ /* Check if we may already be in the hashtable, in this case, we @@ -461,7 +461,7 @@ END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FTR_COHERENT_ICACHE, CPU_FTR_NOEXECUTE) std r3,STK_PARM(r4)(r1) /* Get htab_hash_mask */ - ld r4,[EMAIL PROTECTED](2) + LOAD_REG_IMMEDIATE(r4, htab_hash_mask) ld r27,0(r4) /* htab_hash_mask - r27 */ /* Check if we may already be in the hashtable, in this case, we @@ -792,7 +792,7 @@ END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FTR_COHERENT_ICACHE, CPU_FTR_NOEXECUTE) std r3,STK_PARM(r4)(r1) /* Get htab_hash_mask */ - ld r4,[EMAIL PROTECTED](2) + LOAD_REG_IMMEDIATE(r4, htab_hash_mask) ld r27,0(r4) /* htab_hash_mask - r27 */ /* Check if we may already be in the hashtable, in this case, we diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S index bc44dc4..502099e 100644 --- a/arch/powerpc/mm/slb_low.S +++ b/arch/powerpc/mm/slb_low.S @@ -128,7 +128,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_1T_SEGMENT) /* Now get to the array and obtain the sllp */ ld r11,PACATOC(r13) - ld r11,[EMAIL PROTECTED](r11) + LOAD_REG_IMMEDIATE(r11, mmu_psize_defs) add r11,r11,r9 ld r11,MMUPSIZESLLP(r11) ori r11,r11,SLB_VSID_USER diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S index c1427b3..43c18f0 100644 --- a/arch/powerpc/platforms/pseries/hvCall.S +++ b/arch/powerpc/platforms/pseries/hvCall.S @@ -55,7 +55,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_PURR);\ /* calculate address of stat structure r4 = opcode */ \ srdi r4,r4,2; /* index into array */ \ mulli r4,r4,HCALL_STAT_SIZE;\ - LOAD_REG_ADDR(r7, per_cpu__hcall_stats); \ + LOAD_REG_IMMEDIATE(r7, per_cpu__hcall_stats); \ add r4,r4,r7; \ ld r7,PACA_DATA_OFFSET(r13); /* per cpu offset */ \ add r4,r4,r7; \ -- 1.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
UIO not working on ppc405 onchip registers
Hi,
I'm unable to get UIO working on the ppc405ep onchip registers (e.g. gpio/iic)
however it's working fine on peripherals.
It seems to me to be a problem with UIO on powerpc, because if I change the
address (and nothing more) to point to a external FPGA it's working fine.
I also tried the generic uio_pdrv which had the same problems.
Sometimes I get a bus error sometimes it only produces wrong results.
The bus error occurred when not a full 32 bit register was read (e.g. only a
byte of it), but I'm not sure if it doesn't occur for other reasons as well.
Here is a simple example against 2.6.26. It should toggle the GPIO pin 0 on
ppc405ep, but can be changed easily to work on other ppc variants.
Can anyone reproduce this problem, did anyone already succeed in writing a UIO
driver for the onchip registers? How can I fix this?
Might this be something like commit c9698d6b1a90929e427a165bd8283f803f57d9bd
which
added pgprot_noncached() to UIO mmap code to get it work on ppc?
Regards
Markus
diff -upNr linux-2.6.26/drivers/uio-orig/Kconfig
linux-2.6.26/drivers/uio/Kconfig
--- linux-2.6.26/drivers/uio-orig/Kconfig 2008-07-18 09:15:51.0
+0200
+++ linux-2.6.26/drivers/uio/Kconfig2008-07-18 09:16:18.0 +0200
@@ -39,4 +39,12 @@ config UIO_SMX
If you compile this as a module, it will be called uio_smx.
+config UIO_GPIO
+ tristate Driver for PPC_4xx GPIO
+ depends on UIO
+ default n
+ help
+ Driver for PPC_4xx GPIO Registers
+
endif
+
diff -upNr linux-2.6.26/drivers/uio-orig/Makefile
linux-2.6.26/drivers/uio/Makefile
--- linux-2.6.26/drivers/uio-orig/Makefile 2008-07-18 09:27:18.0
+0200
+++ linux-2.6.26/drivers/uio/Makefile 2008-07-18 09:16:50.0 +0200
@@ -1,3 +1,4 @@
obj-$(CONFIG_UIO) += uio.o
obj-$(CONFIG_UIO_CIF) += uio_cif.o
obj-$(CONFIG_UIO_SMX) += uio_smx.o
+obj-$(CONFIG_UIO_GPIO) += uio_ppc_4xx-gpio.o
diff -upNr linux-2.6.26/drivers/uio-orig/uio-gpio.c
linux-2.6.26/drivers/uio/uio-gpio.c
--- linux-2.6.26/drivers/uio-orig/uio-gpio.c1970-01-01 01:00:00.0
+0100
+++ linux-2.6.26/drivers/uio/uio-gpio.c 2008-07-18 09:18:56.0 +0200
@@ -0,0 +1,59 @@
+#include sys/types.h
+#include sys/time.h
+#include sys/stat.h
+#include sys/mman.h
+#include fcntl.h
+#include unistd.h
+#include stdio.h
+#include stdlib.h
+
+const unsigned long pin_mask( unsigned int pin) { return (0x8000
(pin));}
+
+const char UIO_DEV[] = /dev/uio0;
+const unsigned int UIO_SIZE = 0x1000;
+const unsigned int UIO_ADDR = 0xef600700;
+
+const int or = 0;
+const int tcr = 1;
+
+const unsigned int gpio_pin = 0;/* What gpio pin do you want to
toggle? */
+
+volatile unsigned long *gpio_regs;
+
+int main(int argc, char *argv[])
+{
+ int uiofd = open(UIO_DEV,O_RDWR);
+ if (uiofd 0)
+ return uiofd;
+
+ unsigned long* map_addr = mmap(NULL,
+ UIO_SIZE,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED,
+ uiofd,
+ 0);
+ if (map_addr == ((unsigned long*) -1))
+ return -1;
+gpio_regs = (volatile unsigned long*) map_addr;
+ printf(Mapped %0lx bytes from %08lx to %08lx\n, UIO_SIZE, UIO_ADDR,
(unsigned long)map_addr);
+
+printf(TCR = %08lx\n, gpio_regs[tcr]);
+printf(TCR = %08lx\n, gpio_regs[tcr]);
+printf(setting TCR\n);
+gpio_regs[tcr] = gpio_regs[tcr] | pin_mask( gpio_pin ); // set tcr
for pin to 1
+printf(TCR = %08lx\n, gpio_regs[tcr]);
+printf(TCR = %08lx\n, gpio_regs[tcr]);
+
+printf(OR = %08lx\n, gpio_regs[or]);
+printf(OR = %08lx\n, gpio_regs[or]);
+printf(setting OR\n);
+gpio_regs[or] = gpio_regs[or] | pin_mask( gpio_pin ); // set tcr
for pin to 1
+printf(OR = %08lx\n, gpio_regs[or]);
+printf(OR = %08lx\n, gpio_regs[or]);
+sleep( 3 );
+printf(setting OR\n);
+gpio_regs[or] = gpio_regs[or] ~pin_mask( gpio_pin ); // set tcr
for pin to 0
+printf(OR = %08lx\n, gpio_regs[or]);
+printf(OR = %08lx\n, gpio_regs[or]);
+
+}
diff -upNr linux-2.6.26/drivers/uio-orig/uio_ppc_4xx-gpio.c
linux-2.6.26/drivers/uio/uio_ppc_4xx-gpio.c
--- linux-2.6.26/drivers/uio-orig/uio_ppc_4xx-gpio.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.26/drivers/uio/uio_ppc_4xx-gpio.c 2008-07-18 09:23:32.0
+0200
@@ -0,0 +1,74 @@
+/*
+ * simple UIO GPIO driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+static struct uio_info info = {
+
Re: going to OLS?
Becky Bruce [EMAIL PROTECTED] wrote: On Jul 18, 2008, at 11:33 AM, Wolfgang Denk wrote: BTW: will there a pre-OLS beer evening on Tuesday, or will Stefan and me have to sit alone in some bar? Gosh, that would be so sad :) If someone can pick a place and time, and just announce it, maybe we can all hook up. I'd give it a go, but I've only been to Ottawa once, and I'm afraid my drinking habits during said trip left me with unreliable memories of drinking establishments :) I'm game, but I'll have to bail sometime around 9:00. BTW, if anyone else wants to receive the contact phone list, then send me your phone number ASAP. I'll be sending it out this evening. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: going to OLS?
On Mon, 21 Jul 2008 14:15:53 -0600 Grant Likely [EMAIL PROTECTED] wrote: BTW, if anyone else wants to receive the contact phone list, then send me your phone number ASAP. I'll be sending it out this evening. My home phone number is 613-728-1680. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PIXIS gpio controller and gpio flags
On Mon, 21 Jul 2008, Anton Vorontsov wrote: On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote: It doesn't look like you have any way to unset the active low flag. What if I unload the leds-gpio driver (or another gpio user) and then try to use the gpio with something else? The active low flag is stuck on! Why would you want to unset the flags? It is specified in the device tree, and can't be changed. Specifying different flags for the same GPIO would be an error (plus, Linux forbids shared gpios, so you simply can't specify one gpio for several devices). You can't use the same gpio for two different things at the same time, but you can load a driver, unload it, and then load another. Most gpio users, including leds-gpio, can handle gpios being busy. If leds-gpio can't get one of the gpios, it rolls back all the leds it did create, doesn't drive the device and returns EBUSY. Except with of_get_gpio() setting the flags, it will change the flags out from under whatever had the gpio already allocated! You're still assuming that something was allocated. It wasn't. The flag was set, and it should not change. It is irrelevant if request() failed or not. Another driver has requested the gpio with active low NOT set. Then the led driver looks up the property with active low set, which changes the flags. When it tries to request the gpio it fails since the gpio is already in use. The led driver handles this failure. Except the active low flag is now set and the driver that was using the gpio before will now mysteriously stop working. Perhaps by erasing flash instead of reading it or something nasty like that. Is this the proper way to handle a dts mistake that has two drivers trying to use the same gpio? Without the gpio flags getting set when looking up the gpio, this situation is handled without any difficulty. And is having a gpio used twice in the device tree really a mistake? What if there are two different devices that can be attached to the gpios? For example, an LED bank that can be unplugged and a serial console attached in its place, sharing the same connector and gpios. Other than gpio flags getting set when looking up a gpio, it works fine to list both devices in the device tree as long as userspace has the correct driver loaded first. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote: I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than using a bootwrapper for obvious reasons. The u-boot implementation takes the blob as a boot parameter and passes it along to the kernel after doing appropriate (optional) fixups. And if those fixups expect a malformed device tree? Other than that quibble, I agree that burning the blob into the firmware so that the firmware must be recompiled and reburned to change the blob is very undesirable. I thought the device tree was *supposed* to be an interface between the firmware and the kernel? What if the firmware produces the tree dynamically? What if the firmware itself depends on having the device tree in order to operate? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
Other than that quibble, I agree that burning the blob into the firmware so that the firmware must be recompiled and reburned to change the blob is very undesirable. I thought the device tree was *supposed* to be an interface between the firmware and the kernel? What if the firmware produces the tree dynamically? What if the firmware itself depends on having the device tree in order to operate? Sure. But in the case where the firmware just passes the kernel some fixed blob, it is easier for everyone to include that blob with the kernel instead. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
On Fri, 2008-07-18 at 14:10 +0200, Sebastian Siewior wrote: Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping] changed the phydev-lock from spinlock into a mutex. Now, the following code path got triggered while NFS was unavailable: [snip] |[ 194.864733] BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87 |[ 194.875529] in_atomic():1, irqs_disabled():0 |[ 194.879805] Call Trace: |[ 194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable) |[ 194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4 |[ 194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c |[ 194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70 |[ 194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4 |[ 194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60 |[ 194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144 Hmm.. I'm not sure what the best solution is to this. Make the stop_gfar() call happen in a workqueue, and make a similar change to ucc_geth, fec_mpc52xx, and fs_enet? Modify phy_stop() to do the work in a workqueue conditionally if in interrupt context? Between these two I'd lean toward the latter. Does anyone have any better ideas? -- Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix build bug with binutils 2.18 and GCC 4.2
binutils 2.18 has a bug that makes it misbehave when taking an
ELF file with all segments at load address 0 as input. This
happens when running strip on vmlinux, because of the AT() magic
in this linker script. People using GCC = 4.2 won't run into
this problem, because the build-id support will put some data
into the notes segment (at a non-zero load address).
To work around this, we force some data into both the dummy
segment and the kernel segment, so the dummy segment will get a
non-zero load address. It's not enough to always create the
notes segment, since if nothing gets assigned to it, its load
address will be zero.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
Tested-By: Milton Miller [EMAIL PROTECTED]
---
arch/powerpc/kernel/vmlinux.lds.S | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 87a72c6..a914411 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -9,6 +9,25 @@
ENTRY(_stext)
+PHDRS {
+ kernel PT_LOAD FLAGS(7); /* RWX */
+ notes PT_NOTE FLAGS(0);
+ dummy PT_NOTE FLAGS(0);
+
+ /* binutils 2.18 has a bug that makes it misbehave when taking an
+ ELF file with all segments at load address 0 as input. This
+ happens when running strip on vmlinux, because of the AT() magic
+ in this linker script. People using GCC = 4.2 won't run into
+ this problem, because the build-id support will put some data
+ into the notes segment (at a non-zero load address).
+
+ To work around this, we force some data into both the dummy
+ segment and the kernel segment, so the dummy segment will get a
+ non-zero load address. It's not enough to always create the
+ notes segment, since if nothing gets assigned to it, its load
+ address will be zero. */
+}
+
#ifdef CONFIG_PPC64
OUTPUT_ARCH(powerpc:common64)
jiffies = jiffies_64;
@@ -50,7 +69,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
_etext = .;
PROVIDE32 (etext = .);
- }
+ } :kernel
/* Read-only data */
RODATA
@@ -62,7 +81,13 @@ SECTIONS
__stop___ex_table = .;
}
- NOTES
+ NOTES :kernel :notes
+
+ /* The dummy segment contents for the bug workaround mentioned above
+ near PHDRS. */
+ .dummy : {
+ LONG(0xf177)
+ } :kernel :dummy
/*
* Init sections discarded at runtime
@@ -74,7 +99,7 @@ SECTIONS
_sinittext = .;
INIT_TEXT
_einittext = .;
- }
+ } :kernel
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
--
1.5.6.4.gf1ba5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Networkl problems with lastest kernel....
On Mon, 2008-07-21 at 10:16 -0700, David Miller wrote:
From: Sean MacLennan [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 13:05:36 -0400
But I have attached the new OOPS anyway.
The same problem is still there, this driver will
unfortunately require quite a bit more surgery.
You can instead add the following patch, it will
warn instead of BUG on you, and try to continue.
Argh, EMAC ! I suppose I need to go have a look fix it :-)
EMAC does some strange things such as sharing one NAPI instance for
multiple devices. Dunno if that's related to the problem. I need to dig
a bit.
Cheers,
Ben.
From 867d79fb9a4d5929ad8335c896fcfe11c3b2ef14 Mon Sep 17 00:00:00 2001
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 09:54:18 -0700
Subject: [PATCH] net: In __netif_schedule() use WARN_ON instead of BUG_ON
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
net/core/dev.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7e2d527..cbc34c0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1327,7 +1327,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb,
struct net_device *dev)
void __netif_schedule(struct Qdisc *q)
{
- BUG_ON(q == noop_qdisc);
+ if (WARN_ON_ONCE(q == noop_qdisc))
+ return;
if (!test_and_set_bit(__QDISC_STATE_SCHED, q-state)) {
struct softnet_data *sd;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Correct CMO entitlement accounting for map_sg
The ibmvscsi driver maps pages via map_sg and frees the sg list by calling unmap_single. This exposes a problem where the code had been using the length field in the scatterlist to account for the allocation when the mapping was created but the dma_length would be used when the mapping was destroyed. The iommu code does coalesce the pages so the dma_length can be smaller and would result in an entitlement accounting leak. This patch frees up the entitlement after calling the iommu map_sg code when pages have been coalesced so that freeing entitlement based on dma_length is correct. Signed-off-by: Robert Jennings [EMAIL PROTECTED] --- This applies on top of the existing CMO patchset. --- arch/powerpc/kernel/vio.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: b/arch/powerpc/kernel/vio.c === --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -571,6 +571,11 @@ static int vio_dma_iommu_map_sg(struct d atomic_inc(viodev-cmo.allocs_failed); } + for (sgl = sglist, count = 0; count ret; count++, sgl++) + alloc_size -= roundup(sgl-dma_length, PAGE_SIZE); + if (alloc_size) + vio_cmo_dealloc(viodev, alloc_size); + return ret; } @@ -584,7 +589,7 @@ static void vio_dma_iommu_unmap_sg(struc int count = 0; for (sgl = sglist; count nelems; count++, sgl++) - alloc_size += roundup(sgl-length, PAGE_SIZE); + alloc_size += roundup(sgl-dma_length, PAGE_SIZE); dma_iommu_ops.unmap_sg(dev, sglist, nelems, direction); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] serial: fix struct uart_info change fallout
Hi Linus, Alan,
Today's linux-next (actually just Linus' tree) build (powerpc
ppc64_defconfig) failed like this:
drivers/serial/serial_txx9.c: In function 'receive_chars':
drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named
'tty'
drivers/serial/icom.c: In function 'recv_interrupt':
drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
drivers/serial/icom.c|2 +-
drivers/serial/serial_txx9.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/icom.c b/drivers/serial/icom.c
index 9c2df5c..2b7531d 100644
--- a/drivers/serial/icom.c
+++ b/drivers/serial/icom.c
@@ -730,7 +730,7 @@ static void xmit_interrupt(u16 port_int_reg, struct
icom_port *icom_port)
static void recv_interrupt(u16 port_int_reg, struct icom_port *icom_port)
{
short int count, rcv_buff;
- struct tty_struct *tty = icom_port-uart_port.info-tty;
+ struct tty_struct *tty = icom_port-uart_port.info-port.tty;
unsigned short int status;
struct uart_icount *icount;
unsigned long offset;
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 7ad2192..8fcb4c5 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -272,7 +272,7 @@ static void serial_txx9_initialize(struct uart_port *port)
static inline void
receive_chars(struct uart_txx9_port *up, unsigned int *status)
{
- struct tty_struct *tty = up-port.info-tty;
+ struct tty_struct *tty = up-port.info-port.tty;
unsigned char ch;
unsigned int disr = *status;
int max_count = 256;
--
1.5.6.2
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
On Tue, Jul 22, 2008 at 10:25:20AM +1000, Stephen Rothwell wrote: Hi Linus, Alan, Today's linux-next (actually just Linus' tree) build (powerpc ppc64_defconfig) failed like this: drivers/serial/serial_txx9.c: In function 'receive_chars': drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty' drivers/serial/icom.c: In function 'recv_interrupt': drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty' That's the same pair of patches I sent earlier, which apparently were Already in the ttydev tree which should be in linux-next ? Dave -- http://www.codemonkey.org.uk ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
Hi Dave, On Mon, 21 Jul 2008 20:38:14 -0400 Dave Jones [EMAIL PROTECTED] wrote: That's the same pair of patches I sent earlier, which apparently were Already in the ttydev tree which should be in linux-next ? Indeed. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpnBKkryofKZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] elf loader support for auxvec base platform string
On Mon, 2008-07-21 at 13:48 -0500, Nathan Lynch wrote:
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value power5+. This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be power5+ and AT_BASE_PLATFORM will be power6. The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
Andrew, I'll merge that after John patch shows up if you give me your
Ack :-)
Cheers,
Ben.
---
Andrew Morton wrote:
OK.
But it conflicts directly with the already-queued
execve-filename-document-and-export-via-auxiliary-vector.patch (which
various potential reviewers blithely deleted - don't come complaining
to me!):
Rebased to -mm to resolve conflicts with
execve-filename-document-and-export-via-auxiliary-vector.patch, and
changed AT_BASE_PLATFORM to lowest unclaimed value (24).
fs/binfmt_elf.c| 28
include/linux/auxvec.h |6 +-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index bad7d87..180f92b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,15 @@ static int padzero(unsigned long elf_bss)
#define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
#endif
+#ifndef ELF_BASE_PLATFORM
+/*
+ * AT_BASE_PLATFORM indicates the real hardware/microarchitecture.
+ * If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
+ * will be copied to the user stack in the same manner as AT_PLATFORM.
+ */
+#define ELF_BASE_PLATFORM NULL
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -142,7 +151,9 @@ create_elf_tables(struct linux_binprm *bprm, struct
elfhdr *exec,
elf_addr_t __user *envp;
elf_addr_t __user *sp;
elf_addr_t __user *u_platform;
+ elf_addr_t __user *u_base_platform;
const char *k_platform = ELF_PLATFORM;
+ const char *k_base_platform = ELF_BASE_PLATFORM;
int items;
elf_addr_t *elf_info;
int ei_index = 0;
@@ -172,6 +183,19 @@ create_elf_tables(struct linux_binprm *bprm, struct
elfhdr *exec,
return -EFAULT;
}
+ /*
+ * If this architecture has a base platform capability
+ * string, copy it to userspace.
+ */
+ u_base_platform = NULL;
+ if (k_base_platform) {
+ size_t len = strlen(k_base_platform) + 1;
+
+ u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
+ if (__copy_to_user(u_base_platform, k_base_platform, len))
+ return -EFAULT;
+ }
+
/* Create the ELF interpreter info */
elf_info = (elf_addr_t *)current-mm-saved_auxv;
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
@@ -209,6 +233,10 @@ create_elf_tables(struct linux_binprm *bprm, struct
elfhdr *exec,
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
}
+ if (k_base_platform) {
+ NEW_AUX_ENT(AT_BASE_PLATFORM,
+ (elf_addr_t)(unsigned long)u_base_platform);
+ }
if (bprm-interp_flags BINPRM_FLAGS_EXECFD) {
NEW_AUX_ENT(AT_EXECFD, bprm-interp_data);
}
diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
index 0da17d1..d7afa9d 100644
--- a/include/linux/auxvec.h
+++ b/include/linux/auxvec.h
@@ -26,9 +26,13 @@
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_BASE_PLATFORM 24 /* string identifying real platform, may
+ * differ from AT_PLATFORM. */
+
#define AT_EXECFN 31/* filename of program */
+
#ifdef __KERNEL__
-#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
+#define AT_VECTOR_SIZE_BASE 18 /* NEW_AUX_ENT entries in auxiliary table */
/* number of #define AT_.* above, minus {AT_NULL, AT_IGNORE, AT_NOTELF}
*/
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
On Tue, 22 Jul 2008 10:25:20 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: Hi Linus, Alan, Today's linux-next (actually just Linus' tree) build (powerpc ppc64_defconfig) failed like this: Yes I know. I've been trying to get the other patches merged but each of the five pulls of Linus tree I have done has broken the tty patch merges *AGAIN* so I still don't have them tested and ready to merge despite it being 3AM. So much for the linux-next tree. Please give it until tomorrow or you are just going to break the tree again and mean I have to run another set of tests and regressions. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
Scott Wood wrote: On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote: I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than using a bootwrapper for obvious reasons. The u-boot implementation takes the blob as a boot parameter and passes it along to the kernel after doing appropriate (optional) fixups. And if those fixups expect a malformed device tree? Oops, very bad choice of terms on my part. :-( The fixups I referred to are mostly fill in the blank things like setting the various clocks, MAC information, PCI information, etc. to the correct values based on hardware probing or a priori knowledge. U-boot does not (should not / will not!) fix broken device trees. A broken tree w/ the u-boot methodology is fixed by loading a corrected one, not requiring a full rebuild and reload of the firmware. Note that the blobs are (should be) made from the *.dts files that are part of the linux kernel source, so having correct ones has not been a problem. Since replacement ones are easily loaded, broken blobs are fixed by replacement, not by contorted fixups a'la the start of this thread. Since blobs are well defined, even if some boneheaded company didn't release their blob source, it is trivial to dump it (e.g. fdt print /), fixed, and then replaced. Other than that quibble, I agree that burning the blob into the firmware so that the firmware must be recompiled and reburned to change the blob is very undesirable. I thought the device tree was *supposed* to be an interface between the firmware and the kernel? What if the firmware produces the tree dynamically? What if the firmware itself depends on having the device tree in order to operate? -Scott Well, yes and no on dynamically generated blobs. There isn't much point dynamically generating the static parts of the blob - if you have static code dynamically generating the static parts of the blob, is it dynamic or static? That is probably exactly where Mikrotik has problems. The truly dynamic parts are a small part of the blob. If all else fails, u-boot is GPLed and the user is able to get the source and fix it (well, at least for 3 years after purchasing the hardware). There are advantages and disadvantages to u-boot and boot-wrapper methods. There are nothing but disadvantages to having the blob physically a part of the firmware (with a double whammy if the firmware source is not readily available). Best regards, gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
Hi Alan, On Tue, 22 Jul 2008 02:58:50 +0100 Alan Cox [EMAIL PROTECTED] wrote: Yes I know. Indeed, you knew before you pushed the breaking patches to Linus. I've been trying to get the other patches merged but each of the five pulls of Linus tree I have done has broken the tty patch merges *AGAIN* so I still don't have them tested and ready to merge despite it being 3AM. Then why weren't the fixes rolled back into the original patch or at least submitted at the same time? So much for the linux-next tree. Please give it until tomorrow or you are What is your problem with the linux-next tree. The problem was discovered and reported when I first merged the ttydev tree into linux-next on July 1. The fixes were in linux-next on July 2. just going to break the tree again and mean I have to run another set of tests and regressions. Please give what until tomorrow? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQXlK9cpkjp.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
Mohan Kumar M writes: @@ -714,7 +714,7 @@ _GLOBAL(enter_rtas) stdr6,PACASAVEDMSR(r13) /* Setup our real return addr */ - LOAD_REG_ADDR(r4,.rtas_return_loc) + LOAD_REG_IMMEDIATE(r4,.rtas_return_loc) If LOAD_REG_ADDR doesn't work, then how are all the TOC loads in gcc-generated code going to work? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigantci pages patches
On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote: Hi all, Could people take one last look at these patches and if there are no issues, please send Ack-bys to Andrew who will push them to Linus for 2.6.27. [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages http://patchwork.ozlabs.org/linuxppc/patch?id=18437 Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages http://patchwork.ozlabs.org/linuxppc/patch?id=18438 Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations http://patchwork.ozlabs.org/linuxppc/patch?id=18439 Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages http://patchwork.ozlabs.org/linuxppc/patch?id=18440 Patch: [PATCH 5/6 v2] check for overflow http://patchwork.ozlabs.org/linuxppc/patch?id=18441 Patch: [PATCH 6/6] powerpc: support multiple huge page sizes http://patchwork.ozlabs.org/linuxppc/patch?id=18442 Sorry, I should have looked at these properly when they went past in May, but obviously I missed them. They mostly look ok. I'm a bit confused on 2/6 though - it seems the new powerpc alloc_bootmem_huge_page() function is specific to the 16G gigantic pages. But can't that function also get called for the normal 16M hugepages depending on how the hugepage pool is initialized. Or am I missing something (wouldn't surprise me given my brain's sluggishness today)? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
On Mon, Jul 21, 2008 at 10:54:58PM -0400, Jerry Van Baren wrote: Scott Wood wrote: On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote: I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than using a bootwrapper for obvious reasons. The u-boot implementation takes the blob as a boot parameter and passes it along to the kernel after doing appropriate (optional) fixups. And if those fixups expect a malformed device tree? Oops, very bad choice of terms on my part. :-( The fixups I referred to are mostly fill in the blank things like setting the various clocks, MAC information, PCI information, etc. to the correct values based on hardware probing or a priori knowledge. U-boot does not (should not / will not!) fix broken device trees. A broken tree w/ the u-boot methodology is fixed by loading a corrected one, not requiring a full rebuild and reload of the firmware. Note that the blobs are (should be) made from the *.dts files that are part of the linux kernel source, so having correct ones has not been a problem. Since replacement ones are easily loaded, broken blobs are fixed by replacement, not by contorted fixups a'la the start of this thread. Since blobs are well defined, even if some boneheaded company didn't release their blob source, it is trivial to dump it (e.g. fdt print /), fixed, and then replaced. Other than that quibble, I agree that burning the blob into the firmware so that the firmware must be recompiled and reburned to change the blob is very undesirable. I thought the device tree was *supposed* to be an interface between the firmware and the kernel? What if the firmware produces the tree dynamically? What if the firmware itself depends on having the device tree in order to operate? -Scott Well, yes and no on dynamically generated blobs. There isn't much point dynamically generating the static parts of the blob - if you have static code dynamically generating the static parts of the blob, is it dynamic or static? That is probably exactly where Mikrotik has problems. The truly dynamic parts are a small part of the blob. Well.. they often are, particularly for embedded boards. If there really is a large part of the tree which is dynamic, then certainly it makes sense for the firmware to generate it and supply a blob to the kernel. Of course in this sort of situation it would also make sense to have a full OF firmware. Likewise, if the firmware is sufficiently complex to want to make substantial internal use of the device tree, it makes sense for it to pass it to the kernel. If you have a firmware of this sort of sophistication, though, please, please try to get the tree *right*. A lot of firmwares however, as gvb says just take a skeleton device tree and do nothing more than poke a few integers into specific places into it. Maybe either leave in or remove a subtree representing an optional peripheral. This is the common case for embedded systems where something in the installed software stack has to Just Know what the hardware looks like. In this case, in theory, it's pretty much arbitrary whether the the devtree is bundled into the piece of the stack labelled firmware/bootloader, or the piece labelled kernel, or even (as with u-boot) yet another device tree section. In practice however, it makes sense for the tree to be bundled with the most-easily-updated section of the stack, because that way it's easier to correct errors in it. And usually, that means putting it with the kernel (using the zImage wrapper). In particular this makes sense because the kernel is the only real user of the device tree, and this way platform specific bugs can just be fixed in the device tree, without needing code to deal with both broken device trees from old firmwares and fixed device trees from newer firmwares. If all else fails, u-boot is GPLed and the user is able to get the source and fix it (well, at least for 3 years after purchasing the hardware). There are advantages and disadvantages to u-boot and boot-wrapper methods. There are nothing but disadvantages to having the blob physically a part of the firmware (with a double whammy if the firmware source is not readily available). Well, nothing but disadvantages isn't strictly true. In theory boards with this arrangement which are sufficiently similar to existing systems could run a generic kernel without any porting work. In practice, board firmwares get things right so exceedingly rarely that the kernel will need workarounds anyway, so it might as well just include the device tree itself. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list
Re: [PATCH 01/16 v3] powerpc: Remove extraneous error reporting for hcall failures in lparcfg
Robert Jennings writes: From: Nathan Fontenot [EMAIL PROTECTED] Remove the extraneous error reporting used when a hcall made from lparcfg fails. Signed-off-by: Nathan Fontenot [EMAIL PROTECTED] Signed-off-by: Robert Jennings [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
Paul Mackerras wrote: Mohan Kumar M writes: @@ -714,7 +714,7 @@ _GLOBAL(enter_rtas) stdr6,PACASAVEDMSR(r13) /* Setup our real return addr */ - LOAD_REG_ADDR(r4,.rtas_return_loc) + LOAD_REG_IMMEDIATE(r4,.rtas_return_loc) If LOAD_REG_ADDR doesn't work, then how are all the TOC loads in gcc-generated code going to work? Hi Paul, We have a problem only when there is a reference to a variable through got. Following mail sent to Segher yesterday may explain it. I was going through the output generated by objdump -D vmlinux and readelf -h vmlinux. Snip objdump of vmlinux Disassembly of section .got: c0805010 __toc_start: c0805010: c0 00 00 00 lfs f0,0(0) c0805014: 00 80 d0 10 .long 0x80d010 c0805018: c0 00 00 00 lfs f0,0(0) c080501c: 00 00 83 58 .long 0x8358 c0805020: c0 00 00 00 lfs f0,0(0) c0805024: 00 85 1f e8 .long 0x851fe8 c0805028: c0 00 00 00 lfs f0,0(0) c080502c: 00 00 8d 84 .long 0x8d84 c0805030: c0 00 00 00 lfs f0,0(0) c0805034: 00 85 03 38 .long 0x850338 c0805038: c0 00 00 00 lfs f0,0(0) c080503c: 00 85 28 b8 .long 0x8528b8 c0805040: c0 00 00 00 lfs f0,0(0) c0805044: 00 85 28 b0 .long 0x8528b0 c0805048: c0 00 00 00 lfs f0,0(0) c080504c: 00 6d ef 60 .long 0x6def60 All of the variables references through @got translated into relocation type R_PPC64_GOT16_DS entries. All these entries correspond to one of the above entries in the .got section. But none of the entries in .got section are relocated. For example the instruction with relocation type R_PPC64_GOT16_DS, c000830c: e8 62 80 10 ld r3,-32752(r2) refers to current_set variable. r2 will be pointing to 0xc280d010 (relocated __toc_start + 0x8000). So the instruction loads r3 with the content 0xc0851fe8 at location 0xc2805020, but which is not a relocated entry (0xc0851fe8) But when there is a relocation type of R_PPC64_ADDR16_HI, like c0008110: 64 84 00 00 orisr4,r4,0 we could easily get more info about this relocation from readelf like: c0008112 00010005 R_PPC64_ADDR16_HI c000 .text + 8124 So from above output we can identify that instruction at address c0008112 needs to be patched with the relocation delta. Now I have two options left: 1. Check for R_PPC64_GOT16_DS entries and check whether the contents addressed by r2+offset is relocated or not and apply relocation if its not. 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have already done. Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/16 v3] [v2] powerpc: iommu enablement for CMO
Robert Jennings writes:
From: Robert Jennings [EMAIL PROTECTED]
Minor change to add a call to align the return from the device's
get_desired_dma() function with IOMMU_PAGE_ALIGN(). Also removed a
comment referring to a non-existent structure member.
This is a large patch but the normal code path is not affected. For
non-pSeries platforms the code is ifdef'ed out and for non-CMO enabled
pSeries systems this does not affect the normal code path. Devices that
do not perform DMA operations do not need modification with this patch.
The function get_desired_dma was renamed from get_io_entitlement for
clarity.
This patch is actually a new version of [PATCH 11/16 v3] powerpc: vio
bus support for CMO, not a new version of [PATCH 10/16 v3] powerpc:
iommu enablement for CMO as the subject would indicate, which tripped
me up. Anyway, my first comment is that the first paragraph of the
description (Minor change to ...) is not appropriate for the git
tree and will have to be edited before the patch is applied. If the
extra changes are worth describing, describe them (in stand-alone
fashion) in the description; otherwise put things like this after the
line of three dashes, which terminates the description.
+static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist
*sglist,
+int nelems, enum dma_data_direction
direction)
This function, and the related unmap_sg, map_single and unmap_single
functions, now take an extra struct dma_attrs *attrs argument since
Mark Nelson's patch powerpc/dma: implement new dma_*map*_attrs()
interfaces went in (and it's now in Linus' tree). You need to roll
something like the patch below in with the 11/16 patch.
Paul.
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index ad818d1..e05baea 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -518,7 +518,8 @@ static void vio_dma_iommu_free_coherent(struct device *dev,
size_t size,
static dma_addr_t vio_dma_iommu_map_single(struct device *dev, void *vaddr,
size_t size,
- enum dma_data_direction direction)
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
dma_addr_t ret = DMA_ERROR_CODE;
@@ -528,7 +529,7 @@ static dma_addr_t vio_dma_iommu_map_single(struct device
*dev, void *vaddr,
return ret;
}
- ret = dma_iommu_ops.map_single(dev, vaddr, size, direction);
+ ret = dma_iommu_ops.map_single(dev, vaddr, size, direction, attrs);
if (unlikely(dma_mapping_error(ret))) {
vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
atomic_inc(viodev-cmo.allocs_failed);
@@ -539,17 +540,18 @@ static dma_addr_t vio_dma_iommu_map_single(struct device
*dev, void *vaddr,
static void vio_dma_iommu_unmap_single(struct device *dev,
dma_addr_t dma_handle, size_t size,
- enum dma_data_direction direction)
+ enum dma_data_direction direction, struct dma_attrs *attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
- dma_iommu_ops.unmap_single(dev, dma_handle, size, direction);
+ dma_iommu_ops.unmap_single(dev, dma_handle, size, direction, attrs);
vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
}
static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
-int nelems, enum dma_data_direction direction)
+int nelems, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
struct scatterlist *sgl;
@@ -564,7 +566,7 @@ static int vio_dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
return 0;
}
- ret = dma_iommu_ops.map_sg(dev, sglist, nelems, direction);
+ ret = dma_iommu_ops.map_sg(dev, sglist, nelems, direction, attrs);
if (unlikely(!ret)) {
vio_cmo_dealloc(viodev, alloc_size);
@@ -581,7 +583,7 @@ static int vio_dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
static void vio_dma_iommu_unmap_sg(struct device *dev,
struct scatterlist *sglist, int nelems,
- enum dma_data_direction direction)
+ enum dma_data_direction direction, struct dma_attrs *attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
struct scatterlist *sgl;
@@ -591,7 +593,7 @@ static void vio_dma_iommu_unmap_sg(struct device *dev,
for (sgl = sglist; count nelems; count++, sgl++)
alloc_size += roundup(sgl-dma_length, PAGE_SIZE);
- dma_iommu_ops.unmap_sg(dev, sglist, nelems, direction);
+ dma_iommu_ops.unmap_sg(dev, sglist,
Re: [PATCH 07/16 v3] powerpc: Add collaborative memory manager
Robert Jennings writes:
From: Brian King [EMAIL PROTECTED]
Adds a collaborative memory manager, which acts as a simple balloon driver
for System p machines that support cooperative memory overcommitment
(CMO).
+config CMM
+ tristate Collaborative memory management
+ depends on PPC_PSERIES
So CMM doesn't depend on LPARCFG, yet h_get_mpp is only defined if
LPARCFG=y, which makes this blow up if CMM=y and LPARCFG=n:
+static void cmm_get_mpp(void)
+{
+ int rc;
+ struct hvcall_mpp_data mpp_data;
+ unsigned long active_pages_target;
+ signed long page_loan_request;
+
+ rc = h_get_mpp(mpp_data);
Similarly, the call to h_get_mpp in vio_cmo_bus_init fails to link if
PPC_PSERIES=y and LPARCFG=n, which is a possible configuration.
Please think about and fix up the config dependencies.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/16 v3] powerpc: iommu enablement for CMO
Robert Jennings writes:
To support Cooperative Memory Overcommitment (CMO), we need to check
for failure from some of the tce hcalls.
This patch runs into context mismatches because of changes made by
Michael Ellerman's patch Fix sparse warnings in
arch/powerpc/platforms/pseries (now in Linus' tree), which changed
code like
if (condition)
return function_returning_void(args);
into
if (condition) {
function_returning_void(args);
return;
}
which will cause problems for your patch. Please check if any of
these changes need to be undone again.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/16 v3] powerpc: Split retrieval of processor entitlement data into a helper routine
Robert Jennings writes: Split the retrieval of processor entitlement data returned in the H_GET_PPP hcall into its own helper routine. This seems to change the value reported for pool_capacity radically: /* report pool_capacity in percentage */ - seq_printf(m, pool_capacity=%ld\n, -((h_resource 2 * 8) 0x) * 100); + seq_printf(m, pool_capacity=%d\n, ppp_data.group_num * 100); On a Power6 partition here with your patch series applied, I see pool_capacity=3277200 in /proc/ppc64/lparcfg. Without your patches, I get pool_capacity=400 pool_idle_time=0 pool_num_procs=0 This looks like an incompatible user-visible change to me, and we haven't even changed the lparcfg version number at the beginning of the /proc/ppc64/lparcfg output. Why is the pool_capacity so different, and why do the pool_idle_time and pool_num_procs lines disappear? Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
