* [PATCH 3/3] Initial cut to add __read_mostly support for powerpc.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1183521871.36329.499255149967.qpush@thor>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
This didn't get musch feedback the first time I posted it, so it's either
perfect ;P or it got missed.
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
include/asm-powerpc/cache.h | 2 ++
2 files changed, 8 insertions(+)
Index: working/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- working.orig/arch/powerpc/kernel/vmlinux.lds.S
+++ working/arch/powerpc/kernel/vmlinux.lds.S
@@ -7,6 +7,7 @@
#define PROVIDE32(x) PROVIDE(x)
#endif
#include <asm-generic/vmlinux.lds.h>
+#include <asm/cache.h>
ENTRY(_stext)
@@ -211,6 +212,11 @@ SECTIONS
*(.data.cacheline_aligned)
}
+ . = ALIGN(L1_CACHE_BYTES);
+ .data.read_mostly : {
+ *(.data.read_mostly)
+ }
+
. = ALIGN(PAGE_SIZE);
__data_nosave : {
__nosave_begin = .;
Index: working/include/asm-powerpc/cache.h
===================================================================
--- working.orig/include/asm-powerpc/cache.h
+++ working/include/asm-powerpc/cache.h
@@ -34,5 +34,9 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
#endif /* __powerpc64__ && ! __ASSEMBLY__ */
+#if !defined(__ASSEMBLY__)
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
^ permalink raw reply
* [PATCH 1/3] Create a dummy zImage if no valid platform has been selected.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1183521871.36329.499255149967.qpush@thor>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/boot/Makefile | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: working/arch/powerpc/boot/Makefile
===================================================================
--- working.orig/arch/powerpc/boot/Makefile
+++ working/arch/powerpc/boot/Makefile
@@ -184,6 +184,11 @@ $(obj)/zImage.initrd.%: vmlinux $(wrappe
$(obj)/zImage.%: vmlinux $(wrapperbits)
$(call if_changed,wrap,$*)
+# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
+# prefix
+$(obj)/vmlinux.strip: vmlinux
+ $(STRIP) -s -R .comment $< -o $@
+
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
@@ -215,6 +220,11 @@ $(obj)/treeImage.initrd.%: vmlinux $(dts
$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dts))
+# If there isn't a platform selected then just strip the vmlinux.
+ifeq (,$(image-y))
+image-y := vmlinux.strip
+endif
+
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
^ permalink raw reply
* [PATCH 2/3] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1183521871.36329.499255149967.qpush@thor>
When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll
see messages like:
[ 0.000000] time_init: decrementer frequency = 188.044000 MHz
[ 0.000000] time_init: processor frequency = 1504.352000 MHz
[3712914.436297] Console: colour dummy device 80x25
This cause by the initialisation of tb_to_ns_scale in time_init(), suddenly the
multiplication in sched_clock() now does something :). This patch modifies
sched_clock() to report the offset since the machine booted so the same
printk's now look like:
[ 0.000000] time_init: decrementer frequency = 188.044000 MHz
[ 0.000000] time_init: processor frequency = 1504.352000 MHz
[ 0.000135] Console: colour dummy device 80x25
Effectivly including the uptime in printk()s.
This patch makes tb_to_ns_scale and tb_to_ns_shift static and read_mostly for
good meassure.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
There looks to be other variables that could be made static, I think
that's a job for another day though.
arch/powerpc/kernel/time.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: working/arch/powerpc/kernel/time.c
===================================================================
--- working.orig/arch/powerpc/kernel/time.c
+++ working/arch/powerpc/kernel/time.c
@@ -113,8 +113,9 @@ u64 ticklen_to_xs; /* 0.64 fraction */
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL_GPL(rtc_lock);
-u64 tb_to_ns_scale;
-unsigned tb_to_ns_shift;
+static u64 tb_to_ns_scale __read_mostly;
+static unsigned tb_to_ns_shift __read_mostly;
+static unsigned long boot_tb __read_mostly;
struct gettimeofday_struct do_gtod;
@@ -735,7 +736,7 @@ unsigned long long sched_clock(void)
{
if (__USE_RTC())
return get_rtc();
- return mulhdu(get_tb(), tb_to_ns_scale) << tb_to_ns_shift;
+ return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
}
int do_settimeofday(struct timespec *tv)
@@ -960,6 +961,8 @@ void __init time_init(void)
}
tb_to_ns_scale = scale;
tb_to_ns_shift = shift;
+ /* Save the current timebase to pretty up CONFIG_PRINTK_TIME */
+ boot_tb = get_tb();
tm = get_boot_time();
^ permalink raw reply
* [PATCH 0/3] Patches for consideration for 2.6.23.
From: Tony Breeds @ 2007-07-04 4:04 UTC (permalink / raw)
To: linuxppc-dev
This is set of 3 patches that have been sent through the list as RFCs. I
believe that I've addressed any feedback that was raised. Each of the patches
is independant of the other and order is not important.
More feedback is always welcome.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Paul Mackerras @ 2007-07-04 3:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <468ABF4A.60001@freescale.com>
Scott Wood writes:
> Is there any particular reason that of_device_is_compatible uses
> strncasecmp()? Besides the OF spec saying that names (and thus
> compatibles) are case sensitive, the "n" part screws up matching when a
> subset of a string is not a more generic version thereof. For example,
> ucc_geth v. ucc_geth_phy, or fsl,cpm v. fsl,cpm-enet.
>
> Does anything actually rely on this behavior?
Things did in the past rely on the case-insensitive comparison but
probably don't any more. I recall an issue with "ata" vs. "ATA" on
the powerbook 3400.
As for the "n" part, I don't recall exactly why that was done. I
think we should change it to use strcmp and fix any drivers that
break.
Paul.
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Ishizaki Kou @ 2007-07-04 0:38 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
Paul-san,
Could you add these two patches?
[PATCH] of_serial: ignore unknown serial port
http://patchwork.ozlabs.org/linuxppc/patch?id=11421
[PATCH] of_serial: add port type checking
http://patchwork.ozlabs.org/linuxppc/patch?id=11422
Best regards,
Kou Ishizaki
^ permalink raw reply
* [patch v4] PS3: Bootwrapper support.
From: Geoff Levand @ 2007-07-03 23:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <467D719F.6000002@am.sony.com>
Subject: PS3: Bootwrapper support.
Add support to build the PS3 flash rom image and remove some unneeded
lmb calls.
The PS3's lv1 loader supports loading gzipped binary images from flash
rom to addr zero. The loader enters the image at addr 0x100.
In this implementation a bootwrapper overlay is use to arrange for the kernel to
be loaded to addr zero and to have a suitable bootwrapper entry at 0x100. To
construct the rom image, 0x100 bytes from offset 0x100 in the kernel is copied
to the bootwrapper symbol __system_reset_kernel. The 0x100 bytes at the
bootwrapper symbol __system_reset_overlay is then copied to offset 0x100. At
runtime the bootwrapper program copies the 0x100 bytes at __system_reset_kernel
to addr 0x100.
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, and an optional initrd. otheros.bld is the gzip
compresed rom image built from zImage.ps3. otheros.bld is suitable for
programming into the PS3 boot flash memory.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Hi Paul.
I rebased this to your latest for-2.6.23 branch. Please
apply.
-Geoff
v4 changes:
o Rebase to for-2.6.23 branch of powerpc.git.
v3 changes:
o Add details about PS3 loader to patch description.
v2 changes:
o Make platform specific files build for all platforms.
o Remove use of __secondary_hold_acknowledge.
o Change patch comment about zImage entry.
o Add comment about lv1_panic() to ps3_exit().
o Make room for bss section in otheros.bld.
arch/powerpc/boot/Makefile | 21 ++--
arch/powerpc/boot/ps3-head.S | 80 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 161 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 542 insertions(+), 11 deletions(-)
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -46,7 +46,8 @@ src-wlib := string.S crt0.S stdio.c main
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c
+ cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ ps3-head.S ps3-hvcall.S ps3.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -75,11 +76,11 @@ $(addprefix $(obj)/,$(zliblinuxheader)):
$(obj)/empty.c:
@touch $@
-$(obj)/zImage.lds $(obj)/zImage.coff.lds: $(obj)/%: $(srctree)/$(src)/%.S
+$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds: $(obj)/%: $(srctree)/$(src)/%.S
@cp $< $@
clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
- empty.c zImage.coff.lds zImage.lds
+ empty.c zImage zImage.coff.lds zImage.ps3.lds zImage.lds
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
@@ -102,7 +103,7 @@ hostprogs-y := addnote addRamDisk hack-c
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.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
@@ -179,11 +180,12 @@ $(obj)/zImage.%: vmlinux $(wrapperbits)
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux
- $(STRIP) -s -R .comment $< -o $@
+$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
+ $(STRIP) -s -R .comment $< -o vmlinux.strip
+ $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-$(obj)/zImage.initrd.ps3: vmlinux
- @echo " WARNING zImage.initrd.ps3 not supported (yet)"
+$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
+ $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
@@ -206,7 +208,8 @@ install: $(CONFIGURE) $(addprefix $(obj)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
# anything not in $(targets)
-clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.*
+clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \
+ otheros.bld
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
--- /dev/null
+++ b/arch/powerpc/boot/ps3-head.S
@@ -0,0 +1,80 @@
+/*
+ * PS3 bootwrapper entry.
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "ppc_asm.h"
+
+ .text
+
+/*
+ * __system_reset_overlay - The PS3 first stage entry.
+ *
+ * The bootwraper build script copies the 0x100 bytes at symbol
+ * __system_reset_overlay to offset 0x100 of the rom image.
+ *
+ * The PS3 has a single processor with two threads.
+ */
+
+ .globl __system_reset_overlay
+__system_reset_overlay:
+
+ /* Switch to 32-bit mode. */
+
+ mfmsr r9
+ clrldi r9,r9,1
+ mtmsrd r9
+ nop
+
+ /* Get thread number in r3 and branch. */
+
+ mfspr r3, 0x88
+ cntlzw. r3, r3
+ li r4, 0
+ li r5, 0
+ beq 1f
+
+ /* Secondary goes to __secondary_hold in kernel. */
+
+ li r4, 0x60
+ mtctr r4
+ bctr
+
+ /* Primary delays then goes to _zimage_start in wrapper. */
+1:
+ or 31, 31, 31 /* db16cyc */
+ or 31, 31, 31 /* db16cyc */
+
+ lis r4, _zimage_start@ha
+ addi r4, r4, _zimage_start@l
+ mtctr r4
+ bctr
+
+/*
+ * __system_reset_kernel - Place holder for the kernel reset vector.
+ *
+ * The bootwrapper build script copies 0x100 bytes from offset 0x100
+ * of the rom image to the symbol __system_reset_kernel. At runtime
+ * the bootwrapper program copies the 0x100 bytes at __system_reset_kernel
+ * to ram address 0x100. This symbol must occupy 0x100 bytes.
+ */
+
+ .globl __system_reset_kernel
+__system_reset_kernel:
+
+ . = __system_reset_kernel + 0x100
--- /dev/null
+++ b/arch/powerpc/boot/ps3-hvcall.S
@@ -0,0 +1,184 @@
+/*
+ * PS3 bootwrapper hvcalls.
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "ppc_asm.h"
+
+/*
+ * The PS3 hypervisor uses a 64 bit "C" language calling convention.
+ * The routines here marshal arguments between the 32 bit wrapper
+ * program and the 64 bit hvcalls.
+ *
+ * wrapper lv1
+ * 32-bit (h,l) 64-bit
+ *
+ * 1: r3,r4 <-> r3
+ * 2: r5,r6 <-> r4
+ * 3: r7,r8 <-> r5
+ * 4: r9,r10 <-> r6
+ * 5: 8(r1),12(r1) <-> r7
+ * 6: 16(r1),20(r1) <-> r8
+ * 7: 24(r1),28(r1) <-> r9
+ * 8: 32(r1),36(r1) <-> r10
+ *
+ */
+
+.macro GLOBAL name
+ .section ".text"
+ .balign 4
+ .globl \name
+\name:
+.endm
+
+.macro NO_SUPPORT name
+ GLOBAL \name
+ b ps3_no_support
+.endm
+
+.macro HVCALL num
+ li r11, \num
+ .long 0x44000022
+ extsw r3, r3
+.endm
+
+.macro SAVE_LR offset=4
+ mflr r0
+ stw r0, \offset(r1)
+.endm
+
+.macro LOAD_LR offset=4
+ lwz r0, \offset(r1)
+ mtlr r0
+.endm
+
+.macro LOAD_64_REG target,high,low
+ sldi r11, \high, 32
+ or \target, r11, \low
+.endm
+
+.macro LOAD_64_STACK target,offset
+ ld \target, \offset(r1)
+.endm
+
+.macro LOAD_R3
+ LOAD_64_REG r3,r3,r4
+.endm
+
+.macro LOAD_R4
+ LOAD_64_REG r4,r5,r6
+.endm
+
+.macro LOAD_R5
+ LOAD_64_REG r5,r7,r8
+.endm
+
+.macro LOAD_R6
+ LOAD_64_REG r6,r9,r10
+.endm
+
+.macro LOAD_R7
+ LOAD_64_STACK r7,8
+.endm
+
+.macro LOAD_R8
+ LOAD_64_STACK r8,16
+.endm
+
+.macro LOAD_R9
+ LOAD_64_STACK r9,24
+.endm
+
+.macro LOAD_R10
+ LOAD_64_STACK r10,32
+.endm
+
+.macro LOAD_REGS_0
+ stwu 1,-16(1)
+ stw 3, 8(1)
+.endm
+
+.macro LOAD_REGS_5
+ LOAD_R3
+ LOAD_R4
+ LOAD_R5
+ LOAD_R6
+ LOAD_R7
+.endm
+
+.macro LOAD_REGS_6
+ LOAD_REGS_5
+ LOAD_R8
+.endm
+
+.macro LOAD_REGS_8
+ LOAD_REGS_6
+ LOAD_R9
+ LOAD_R10
+.endm
+
+.macro STORE_REGS_0_1
+ lwz r11, 8(r1)
+ std r4, 0(r11)
+ mr r4, r3
+ li r3, 0
+ addi r1,r1,16
+.endm
+
+.macro STORE_REGS_5_2
+ lwz r11, 16(r1)
+ std r4, 0(r11)
+ lwz r11, 24(r1)
+ std r5, 0(r11)
+.endm
+
+.macro STORE_REGS_6_1
+ lwz r11, 24(r1)
+ std r4, 0(r11)
+.endm
+
+GLOBAL lv1_get_logical_ppe_id
+ SAVE_LR
+ LOAD_REGS_0
+ HVCALL 69
+ STORE_REGS_0_1
+ LOAD_LR
+ blr
+
+GLOBAL lv1_get_logical_partition_id
+ SAVE_LR
+ LOAD_REGS_0
+ HVCALL 74
+ STORE_REGS_0_1
+ LOAD_LR
+ blr
+
+GLOBAL lv1_get_repository_node_value
+ SAVE_LR
+ LOAD_REGS_5
+ HVCALL 91
+ STORE_REGS_5_2
+ LOAD_LR
+ blr
+
+GLOBAL lv1_panic
+ SAVE_LR
+ LOAD_REGS_8
+ HVCALL 255
+ LOAD_LR
+ blr
--- /dev/null
+++ b/arch/powerpc/boot/ps3.c
@@ -0,0 +1,161 @@
+/*
+ * PS3 bootwrapper support.
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+
+extern s64 lv1_panic(u64 in_1);
+extern s64 lv1_get_logical_partition_id(u64 *out_1);
+extern s64 lv1_get_logical_ppe_id(u64 *out_1);
+extern s64 lv1_get_repository_node_value(u64 in_1, u64 in_2, u64 in_3,
+ u64 in_4, u64 in_5, u64 *out_1, u64 *out_2);
+
+#ifdef DEBUG
+#define DBG(fmt...) printf(fmt)
+#else
+static inline int __attribute__ ((format (printf, 1, 2))) DBG(
+ const char *fmt, ...) {return 0;}
+#endif
+
+BSS_STACK(4096);
+
+/* A buffer that may be edited by tools operating on a zImage binary so as to
+ * edit the command line passed to vmlinux (by setting /chosen/bootargs).
+ * The buffer is put in it's own section so that tools may locate it easier.
+ */
+static char cmdline[COMMAND_LINE_SIZE]
+ __attribute__((__section__("__builtin_cmdline")));
+
+static void prep_cmdline(void *chosen)
+{
+ if (cmdline[0] == '\0')
+ getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
+ else
+ setprop_str(chosen, "bootargs", cmdline);
+
+ printf("cmdline: '%s'\n", cmdline);
+}
+
+static void ps3_console_write(const char *buf, int len)
+{
+}
+
+static void ps3_exit(void)
+{
+ printf("ps3_exit\n");
+
+ /* lv1_panic will shutdown the lpar. */
+
+ lv1_panic(0); /* zero = do not reboot */
+ while (1);
+}
+
+static int ps3_repository_read_rm_size(u64 *rm_size)
+{
+ s64 result;
+ u64 lpar_id;
+ u64 ppe_id;
+ u64 v2;
+
+ result = lv1_get_logical_partition_id(&lpar_id);
+
+ if (result)
+ return -1;
+
+ result = lv1_get_logical_ppe_id(&ppe_id);
+
+ if (result)
+ return -1;
+
+ /*
+ * n1: 0000000062690000 : ....bi..
+ * n2: 7075000000000000 : pu......
+ * n3: 0000000000000001 : ........
+ * n4: 726d5f73697a6500 : rm_size.
+ */
+
+ result = lv1_get_repository_node_value(lpar_id, 0x0000000062690000ULL,
+ 0x7075000000000000ULL, ppe_id, 0x726d5f73697a6500ULL, rm_size,
+ &v2);
+
+ printf("%s:%d: ppe_id %lu \n", __func__, __LINE__,
+ (unsigned long)ppe_id);
+ printf("%s:%d: lpar_id %lu \n", __func__, __LINE__,
+ (unsigned long)lpar_id);
+ printf("%s:%d: rm_size %llxh \n", __func__, __LINE__, *rm_size);
+
+ return result ? -1 : 0;
+}
+
+void ps3_copy_vectors(void)
+{
+ extern char __system_reset_kernel[];
+
+ memcpy((void *)0x100, __system_reset_kernel, 0x100);
+ flush_cache((void *)0x100, 0x100);
+}
+
+void platform_init(void)
+{
+ extern char _end[];
+ extern char _dtb_start[];
+ extern char _initrd_start[];
+ extern char _initrd_end[];
+ const u32 heapsize = 0x1000000 - (u32)_end; /* 16MiB */
+ void *chosen;
+ unsigned long ft_addr;
+ u64 rm_size;
+
+ console_ops.write = ps3_console_write;
+ platform_ops.exit = ps3_exit;
+
+ printf("\n-- PS3 bootwrapper --\n");
+
+ simple_alloc_init(_end, heapsize, 32, 64);
+ ft_init(_dtb_start, 0, 4);
+
+ chosen = finddevice("/chosen");
+
+ ps3_repository_read_rm_size(&rm_size);
+ dt_fixup_memory(0, rm_size);
+
+ if (_initrd_end > _initrd_start) {
+ setprop_val(chosen, "linux,initrd-start", (u32)(_initrd_start));
+ setprop_val(chosen, "linux,initrd-end", (u32)(_initrd_end));
+ }
+
+ prep_cmdline(chosen);
+
+ ft_addr = dt_ops.finalize();
+
+ ps3_copy_vectors();
+
+ printf(" flat tree at 0x%lx\n\r", ft_addr);
+
+ ((kernel_entry_t)0)(ft_addr, 0, NULL);
+
+ ps3_exit();
+}
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -144,6 +144,15 @@ miboot|uboot)
cuboot*)
gzip=
;;
+ps3)
+ platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
+ lds=$object/zImage.ps3.lds
+ gzip=
+ ext=bin
+ objflags="-O binary --set-section-flags=.bss=contents,alloc,load,data"
+ ksection=.kernel:vmlinux.bin
+ isection=.kernel:initrd
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
@@ -239,4 +248,50 @@ treeboot*)
fi
exit 0
;;
+ps3)
+ # The ps3's loader supports loading gzipped binary images from flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in the
+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
+
+ system_reset_overlay=0x`${CROSS}nm "$ofile" \
+ | grep ' __system_reset_overlay$' \
+ | cut -d' ' -f1`
+ system_reset_overlay=`printf "%d" $system_reset_overlay`
+ system_reset_kernel=0x`${CROSS}nm "$ofile" \
+ | grep ' __system_reset_kernel$' \
+ | cut -d' ' -f1`
+ system_reset_kernel=`printf "%d" $system_reset_kernel`
+ overlay_dest="256"
+ overlay_size="256"
+
+ rm -f "$object/otheros.bld"
+
+ ${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
+
+ msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$overlay_dest seek=$system_reset_kernel \
+ count=$overlay_size bs=1 2>&1)
+
+ if [ $? -ne "0" ]; then
+ echo $msg
+ exit 1
+ fi
+
+ msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$system_reset_overlay seek=$overlay_dest \
+ count=$overlay_size bs=1 2>&1)
+
+ if [ $? -ne "0" ]; then
+ echo $msg
+ exit 2
+ fi
+
+ gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
+ ;;
esac
--- /dev/null
+++ b/arch/powerpc/boot/zImage.ps3.lds.S
@@ -0,0 +1,50 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_zimage_start)
+EXTERN(_zimage_start)
+SECTIONS
+{
+ _vmlinux_start = .;
+ .kernel:vmlinux.bin : { *(.kernel:vmlinux.bin) }
+ _vmlinux_end = .;
+
+ . = ALIGN(4096);
+ _dtb_start = .;
+ .kernel:dtb : { *(.kernel:dtb) }
+ _dtb_end = .;
+
+ . = ALIGN(4096);
+ _initrd_start = .;
+ .kernel:initrd : { *(.kernel:initrd) }
+ _initrd_end = .;
+
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+ }
+
+ . = ALIGN(4096);
+ _edata = .;
+
+ . = ALIGN(4096);
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ . = ALIGN(4096);
+ _end = . ;
+}
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -1213,8 +1213,6 @@ void __init ps3_mm_init(void)
BUG_ON(map.rm.base);
BUG_ON(!map.rm.size);
- lmb_add(map.rm.base, map.rm.size);
- lmb_analyze();
/* arrange to do this in ps3_mm_add_memory */
ps3_mm_region_create(&map.r1, map.total - map.rm.size);
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-03 23:02 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707032356270.3876@poirot.grange>
>> Just use "compatible" exactly the way it is meant to be
>> used and your life will be so much simpler. And don't
>> even think about using a very generic property like "model"
>> for a purpose totally different from its intended purpose.
>
> AFAIU, the only way currently to attach an i2c device to a driver
> is to
> match against driver's name. Let's take the rtc-rs5c372.c example. It
> services rs5c372a, rs5c372b, rv5c386, rv5c387a. And it registers
> itself
> with the name "rtc-rs5c372". We want to just specify in our dts, e.g.,
> 'compatible = "rs5c372b";', right? And ask the i2c layer to find a
> suitable driver for us. Which means a pretty big change to i2c
> core. Is
> this what you think is the proper solution? I could try to think
> about it
> / discuss on i2c and eventually cook up a patch, just want to make
> sure I
> understand you right.
Your device is an rs5c372b. So, that's what you put in
your device tree. Simple so far, right?
Now some OF I2C code goes looking for IIC devices in the
device tree. It finds this thing, and from a table or
something it derives that it has to tell the kernel I2C
layer this is an "rtc-rs5c372". [It would be nicer if it
could just instantiate the correct driver directly, but
if that's how the Linux I2C layer works, so be it].
No change in the I2C "core" needed, just an OF "compatible"
matching thing like is needed *everywhere else* too.
Segher
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Segher Boessenkool @ 2007-07-03 22:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <468ACEC1.5000805@freescale.com>
>> What's the value add in doing this? The code to handle both cases
>> still
>> has to be in there (just under ifdef now). Is there actually any harm
>> in doing case-insensitive matching today, where things break because
>> there are conflicting properties with different cases?
>
> Not for case insensitivity (that I know of), but the whole reason I
> posted this was because of time spent trying to figure out why my
> serial port recently stopped working -- apparently, it's checking
> nodes in a different order now (or something along those lines),
> causing the substring match to match against the wrong thing.
Substring matching is WRONG WRONG WRONG.
> It's even more idiotic to break valid device trees just because the
> kernel has always done so. Putting it under ifdef, especially once
> the default is conformant behavior, will make it more likely that
> future device trees are compliant in that regrad, as long as Linux
> is involved in the testing process.
We should just implement *targeted* workarounds, not say
"oh, some trees use bad upper/lower casing? Let's just match
case-insensitive then".
>> Even with the dts files, there are several of them
>> that have errors in them. There will be more in the future as well.
>
> And the earlier we implement stricter checking, the fewer of them
> there will be.
Yes, unfortunately.
Segher
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Segher Boessenkool @ 2007-07-03 22:41 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070703223612.GA27682@lixom.net>
>> How about a CONFIG_NOT_BROKEN_DEVICE_TREE that disables this and
>> other
>> legacy stuff? If unset, warnings will be printed whenever broken
>> things
>> are detected. Boards which need proper device tree parsing can
>> select
>> the config option.
>>
>> I'd prefer the other way around (CONFIG_BROKEN_DEVICE_TREE), but it'd
>> need to default y at first, and kconfig has no unselect command
>> that I
>> can see...
>
> What's the value add in doing this?
None. The kernel should either allow or not allow certain
classes of brokenness; and if it does allow it, it is better
to only allow it in those cases where it expects the brokenness
(i.e., on certain platforms, in this case).
> The code to handle both cases still
> has to be in there (just under ifdef now). Is there actually any harm
> in doing case-insensitive matching today, where things break because
> there are conflicting properties with different cases?
There is a big potential harm in not looking at case for the
part of the name before the comma (upper case is stock symbol,
lower case isn't). An actual real life example? Dunno, I'm
sure we'll find some if we change to case-sensitive matching.
> Device trees will never be perfect,
But the kernel applies workarounds _way_ too generously. This
is starting to cause more problems than it solves.
> and it's idiotic of the kernel to
> expect them to be. Even with the dts files, there are several of them
> that have errors in them. There will be more in the future as well.
Sure, especially since the kernel allows all kinds of wrong
things and second guesses what is meant. Sometimes it guesses
right, and then the device tree is shipped, since "it works so
it must be right".
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-03 22:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <2055bb54b9816faaf5b2ceedc9cfa039@kernel.crashing.org>
On Tue, 3 Jul 2007, Segher Boessenkool wrote:
> Just use "compatible" exactly the way it is meant to be
> used and your life will be so much simpler. And don't
> even think about using a very generic property like "model"
> for a purpose totally different from its intended purpose.
AFAIU, the only way currently to attach an i2c device to a driver is to
match against driver's name. Let's take the rtc-rs5c372.c example. It
services rs5c372a, rs5c372b, rv5c386, rv5c387a. And it registers itself
with the name "rtc-rs5c372". We want to just specify in our dts, e.g.,
'compatible = "rs5c372b";', right? And ask the i2c layer to find a
suitable driver for us. Which means a pretty big change to i2c core. Is
this what you think is the proper solution? I could try to think about it
/ discuss on i2c and eventually cook up a patch, just want to make sure I
understand you right.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Scott Wood @ 2007-07-03 22:33 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070703223612.GA27682@lixom.net>
Olof Johansson wrote:
> On Tue, Jul 03, 2007 at 05:15:11PM -0500, Scott Wood wrote:
>
>
>>How about a CONFIG_NOT_BROKEN_DEVICE_TREE that disables this and other
>>legacy stuff? If unset, warnings will be printed whenever broken things
>>are detected. Boards which need proper device tree parsing can select
>>the config option.
>>
>>I'd prefer the other way around (CONFIG_BROKEN_DEVICE_TREE), but it'd
>>need to default y at first, and kconfig has no unselect command that I
>>can see...
>
>
> What's the value add in doing this? The code to handle both cases still
> has to be in there (just under ifdef now). Is there actually any harm
> in doing case-insensitive matching today, where things break because
> there are conflicting properties with different cases?
Not for case insensitivity (that I know of), but the whole reason I
posted this was because of time spent trying to figure out why my serial
port recently stopped working -- apparently, it's checking nodes in a
different order now (or something along those lines), causing the
substring match to match against the wrong thing.
I'd really rather not have to go out of my way to avoid picking
compatible names that break Linux.
> Device trees will never be perfect, and it's idiotic of the kernel to
> expect them to be.
It's even more idiotic to break valid device trees just because the
kernel has always done so. Putting it under ifdef, especially once the
default is conformant behavior, will make it more likely that future
device trees are compliant in that regrad, as long as Linux is involved
in the testing process.
> Even with the dts files, there are several of them
> that have errors in them. There will be more in the future as well.
And the earlier we implement stricter checking, the fewer of them there
will be.
-Scott
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Olof Johansson @ 2007-07-03 22:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <468ACA6F.5010107@freescale.com>
On Tue, Jul 03, 2007 at 05:15:11PM -0500, Scott Wood wrote:
> How about a CONFIG_NOT_BROKEN_DEVICE_TREE that disables this and other
> legacy stuff? If unset, warnings will be printed whenever broken things
> are detected. Boards which need proper device tree parsing can select
> the config option.
>
> I'd prefer the other way around (CONFIG_BROKEN_DEVICE_TREE), but it'd
> need to default y at first, and kconfig has no unselect command that I
> can see...
What's the value add in doing this? The code to handle both cases still
has to be in there (just under ifdef now). Is there actually any harm
in doing case-insensitive matching today, where things break because
there are conflicting properties with different cases?
Device trees will never be perfect, and it's idiotic of the kernel to
expect them to be. Even with the dts files, there are several of them
that have errors in them. There will be more in the future as well.
-Olof
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Scott Wood @ 2007-07-03 22:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <513A555F-5C7F-4FEF-B215-E0E683FEF9E1@kernel.crashing.org>
Segher Boessenkool wrote:
> Huh? Are you saying things are matching on substrings?
> That's even more wrong!
Yes, unfortunately. I tried getting the BRG frequency from the fsl,cpm
node and I got the fsl,cpm-enet node instead. :-P
ucc_geth requires device_type == network to avoid matching ucc_geth phy.
>> Does anything actually rely on this behavior?
>
>
> Yeah I'm pretty sure some things do. Those are bugs that
> need fixing. My plan was to print a big fat warning whenever
> a case-insensitive match wouldn't match when following the
> rules; I never got around to actually implementing that though.
> Maybe some day ;-)
How about a CONFIG_NOT_BROKEN_DEVICE_TREE that disables this and other
legacy stuff? If unset, warnings will be printed whenever broken things
are detected. Boards which need proper device tree parsing can select
the config option.
I'd prefer the other way around (CONFIG_BROKEN_DEVICE_TREE), but it'd
need to default y at first, and kconfig has no unselect command that I
can see...
-Scott
^ permalink raw reply
* Re: Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Segher Boessenkool @ 2007-07-03 21:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <468ABF4A.60001@freescale.com>
> Is there any particular reason that of_device_is_compatible uses
> strncasecmp()?
It always has, so some things might break with certain
device trees when we make the matching more strict/correct.
> Besides the OF spec saying that names (and thus
> compatibles) are case sensitive, the "n" part screws up matching
> when a
> subset of a string is not a more generic version thereof. For
> example,
> ucc_geth v. ucc_geth_phy, or fsl,cpm v. fsl,cpm-enet.
Huh? Are you saying things are matching on substrings?
That's even more wrong!
> Does anything actually rely on this behavior?
Yeah I'm pretty sure some things do. Those are bugs that
need fixing. My plan was to print a big fat warning whenever
a case-insensitive match wouldn't match when following the
rules; I never got around to actually implementing that though.
Maybe some day ;-)
Segher
^ permalink raw reply
* Should of_device_is_compatible() use strcmp() rather than strncasecmp()?
From: Scott Wood @ 2007-07-03 21:27 UTC (permalink / raw)
To: linuxppc-dev
Is there any particular reason that of_device_is_compatible uses
strncasecmp()? Besides the OF spec saying that names (and thus
compatibles) are case sensitive, the "n" part screws up matching when a
subset of a string is not a more generic version thereof. For example,
ucc_geth v. ucc_geth_phy, or fsl,cpm v. fsl,cpm-enet.
Does anything actually rely on this behavior?
-Scott
^ permalink raw reply
* request for linux preview kit for ML403
From: mouli @ 2007-07-03 20:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
Dear all,
I am working on Virtex-4 Fx12LC (ML 403 ) Fpga that has powerpc
hard core.
I would want to load Linux RTOS onto it and try and access the on chip
memory and Fpga logic from that.
May I know if any body has the preview kit for Linux for that version of the
VIrtex-4 FPGA.
I am not able to access the montavista linux preview kit from monta vista
website.
thanks and regards
---------------------------------------------------------------------
To save the world is the simplest thing in the world. All one has to do is
think. Leonard Peikoff
vijay chandra mouli N.
ECE department,
NC state univeristy,
Raleigh,NC-27606.
[-- Attachment #2: Type: text/html, Size: 743 bytes --]
^ permalink raw reply
* Re: patches pushed to powerpc.git for-2.6.23 branch
From: Scott Wood @ 2007-07-03 19:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18051.44968.28667.678931@cargo.ozlabs.ibm.com>
On Thu, Jun 28, 2007 at 10:55:04PM +1000, Paul Mackerras wrote:
> I have just pushed some more patches to the for-2.6.23 branch of
> powerpc.git. There are still more to go, of course. :)
>
> If anyone has a patch that was posted more than a couple of weeks ago
> that they want to go in and that isn't in, it would be a good idea to
> remind me (or Kumar for 8xxx stuff, or Arnd for cell stuff) of it.
I'd like to see following patches from the May 8 power management series
make it in:
[PATCH 06/13] Make swsusp_32.S usable for suspend-to-RAM
[PATCH 08/13] pm: Handle HID0_SLEEP in the TLF_NAPPING hack
I'll submit a version of patch 7 that ppc_md-izes the the hook, for
platforms that need to do more than disabling the decrementer (as
requested by Johannes Berg).
-Scott
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Scott Wood @ 2007-07-03 18:29 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20070626171811.GD31457@mag.az.mvista.com>
On Tue, Jun 26, 2007 at 10:18:11AM -0700, Mark A. Greer wrote:
> Actually, I wouldn't have a problem with getting rid of arch/ppc right
> now. It won't really be lost, just git checkout your favorite tag that
> still has it. It'll get rid of code people shouldn't be worrying about
> anymore anyway.
>
> I realize, I'm probably the only one with this opinion so you don't have
> to tell me all the reasons I'm wrong. :)
Not at all -- it'd save me a lot of "#ifdef CONFIG_PPC_MERGE"s in my CPM
driver patches. :-)
-Scott
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Grant Likely @ 2007-07-03 18:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183486153.3590.24.camel@weaponx.rchland.ibm.com>
On 7/3/07, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > Please don't; us 4xx folks aren't yet ready. Active support for
> > Xilinx Virtex in arch/ppc only right now. I want to move over to
> > arch/powerpc; but end of year is rather aggressive.
>
> Selfishly, that's why I listed it as June 2008 to begin with. We've got
> base 440 support in arch/powerpc now, but it needs more work. And I
> just started 405 this morning.
>
> However, I definitely want some date present when arch/ppc will go away.
> Otherwise it will languish on indefinitely, more so than it already has.
I agree.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Josh Boyer @ 2007-07-03 18:09 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <fa686aa40707031003q7d4b40dan220a8a5ac31bbc69@mail.gmail.com>
On Tue, 2007-07-03 at 11:03 -0600, Grant Likely wrote:
> On 7/3/07, Tom Gall <tgall.foo@gmail.com> wrote:
> > June 2008 is a long time away to let this linger. Why not say by End of the
> > year 2007? That should give folks essentially two more 2.6 releases.
>
> Please don't; us 4xx folks aren't yet ready. Active support for
> Xilinx Virtex in arch/ppc only right now. I want to move over to
> arch/powerpc; but end of year is rather aggressive.
Selfishly, that's why I listed it as June 2008 to begin with. We've got
base 440 support in arch/powerpc now, but it needs more work. And I
just started 405 this morning.
However, I definitely want some date present when arch/ppc will go away.
Otherwise it will languish on indefinitely, more so than it already has.
josh
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Grant Likely @ 2007-07-03 17:03 UTC (permalink / raw)
To: tgall; +Cc: linuxppc-dev, paulus
In-Reply-To: <26d387970707030747u69ee8d2axb79452e5e1b7fa2d@mail.gmail.com>
On 7/3/07, Tom Gall <tgall.foo@gmail.com> wrote:
> June 2008 is a long time away to let this linger. Why not say by End of the
> year 2007? That should give folks essentially two more 2.6 releases.
Please don't; us 4xx folks aren't yet ready. Active support for
Xilinx Virtex in arch/ppc only right now. I want to move over to
arch/powerpc; but end of year is rather aggressive.
cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [patch 2/3] Add missing DATA_DATA in powerpc
From: Mathieu Desnoyers @ 2007-07-03 16:45 UTC (permalink / raw)
To: akpm, linux-kernel; +Cc: paulus, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20070703164534.492133618@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: paulus@samba.org
CC: linuxppc-dev@ozlabs.org
--
arch/powerpc/kernel/vmlinux.lds.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6-lttng.orig/arch/powerpc/kernel/vmlinux.lds.S 2007-06-16 22:17:53.000000000 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S 2007-06-16 22:18:32.000000000 -0400
@@ -173,7 +173,9 @@
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH v2] Schedule removal of arch/ppc
From: Geert Uytterhoeven @ 2007-07-03 16:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183474821.3590.13.camel@weaponx.rchland.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 890 bytes --]
On Tue, 3 Jul 2007, Josh Boyer wrote:
> And Segher had made a suggestion that it could be officially killed
> during the PowerPC BOF at OLS 2008 for fun. But honestly, it doesn't
^^^
Or perhaps TLS/MLS/VLS/... (forgot about the 4th alternative location)? ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: OF devices and non OF devices
From: John Rigby @ 2007-07-03 16:31 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-embedded
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB020D3B9D@is-hdq-exchange.marel.net>
[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]
One place to find binding between OF devices and non OF devices is in
arch/powerpc/sysdev/fsl_soc.c
The typical pattern is:
if of_find_compatible_node "of-device-name"
platform_device_register_simple ""platform-device-name"
platform_device_add_data ...
On 7/3/07, Kári Davíðsson <kari.davidsson@marel.is> wrote:
>
> Hi,
>
> I am attempting to get some non OF devices working for an mpc 5200 board,
> in particular
> PCF8563 RTC.
>
> This device has an non OF device interface which I believe is correct.
> After all it should work
> on non OF platforms.
>
> I have managed to get the board to run the i2c initialization (and probe)
> for the fsl-mpc i2c driver by
> converting the fsl-mpc i2c driver to OF driver (I found some patch here
> that I based this work on).
fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need to
change anything to
make it work in the latest kernel. CONFIG_FSL_SOC was only added to
lite5200_defconfig recently so
that may explain why it's not on in your kernel.
Since the PCF8563 driver is not OF driver only its initaliziation code is
> run but the .probe function
> of the driver is never run. Basically (as far as I can understand) the
> .probe is never run because the
> driver is not an OF driver.
>
> I could convert the PCF8563 driver to OF driver and make it work for our
> puposes but I feel this is
> 1) Wrong
> 2) therefore wasted work.
Since the driver must run on non OF platforms then it should not be
converted. You just need to add a platform_device_register somewhere.
I don't think fsl_soc.c is the right place since it is not part of an
freescale SOC.
You could probably put it in a board specific startup routine.
What seems to elude me is some glue that glues together the OF part of the
> driver space to the non OF part
> of the driver space.
>
> Any hints or pointers on where to find this glue?
>
> Regards,
> kd
>
> P.S. Kernel is post 2.6.20.
>
> --
> Kári Davíðsson | kari.davidsson@marel.is
> Hugbúnaðargerð | www.marel.com
> Tel: 563-8156 Fax: +354 563 8001
> Iceland
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3482 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox