Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC

[Kumar Gala]

On Sep 24, 2007, at 12:07 AM, David Gibson wrote:

 On Fri, Sep 21, 2007 at 09:35:03AM +0200, Peter Korsgaard wrote:
 Scott == Scott Wood [EMAIL PROTECTED] writes:

 Hi,

  Scott #size-cells is zero on i2c, so it should just be reg = 68.

  Scott You'll probably need to add #address-cells and #size-cells  
 to the
  Scott controller node, as well.

 Uh.. yes.. i2c interfaces should really always have #a and #s.

 Ahh - Thanks. This should be better.
 ---

 [PATCH] mpc8349emitx.dts: Add ds1339 RTC

 Add ds1339 I2C RTC chip as child of 2nd I2C controller.

 Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
 ---
  arch/powerpc/boot/dts/mpc8349emitx.dts |9 +
  1 file changed, 9 insertions(+)

 Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts
 ===
 --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
 +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts
 @@ -62,12 +62,21 @@
  };

  [EMAIL PROTECTED] {
 +#address-cells = 1;
 +#size-cells = 0;
  device_type = i2c;

 Hrm... we probably want an i2c device_type class, but I don't think
 we've actually defined one, which is a prob

suggestions on how to handle this?  We've described that fsl-i2c  
nodes in booting-without-of.txt should have it. (which may have been  
wrong at the time).

- k


  compatible = fsl-i2c;
  reg = 3100 100;
  interrupts = f 8;
  interrupt-parent =  ipic ;
  dfsrr;


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16

[Milton Miller]

On Sep 23, 2007, at 10:36 PM, David Gibson wrote:

 On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
 kexec-tools still produces a version 2 device tree, while the
 libraries in the wrapper only support version 16 and later.

 Add a routine to convert a v2 flat device tree to a v16 one inplace
 by inserting OF_DT_NOP and chomping full path.  Make space for new
 headers by moving and then chomping the OF_DT_NOPs.

 Signed-off-by: Milton Miller [EMAIL PROTECTED]
 ---
 vs 12175
 Rediffed Makefile, ops, kexec.c

 Index: kernel/arch/powerpc/boot/flatdevtree_conv.c
 ===
 --- /dev/null1970-01-01 00:00:00.0 +
 +++ kernel/arch/powerpc/boot/flatdevtree_conv.c  2007-09-20 
 17:49:04.0 -0500
 @@ -0,0 +1,280 @@
 +/*
 + * 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; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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, 51 Franklin Street, Fifth Floor, Boston, MA  
 02110-1301, USA.
 + *
 + * Copyright IBM Corporation 2007
 + *
 + * Authors: Milton Miller [EMAIL PROTECTED]
 + */
 +#include flatdevtree.h
 +#include stdio.h
 +#include ops.h
 +
 +#define MIN_VERSION 2
 +#define OUT_VERSION 16

 Should output version 17.  In any case, don't try to be so general -
 just convert v123 (all basically the same) to latest (i.e. v17)
 without all the #if nonsense.

Outputing v17 instead of 16 requires more words to be added to the 
header, and the library does fine with v16.  Actually the v1 trees has 
some other differences such as initrd addresses were kernel linear not 
real, cpus were assigned logical numbers  ... so while the structure 
didn't change except for the header field, the contents did.  Actually, 
when converting v3 to v16 some of the code issn't needed, the ifs allow 
the code size to be reduced.


 +#define OUT_COMPAT 16
 +
 +#ifdef NO_CHECK
 +static int check_v123_tree(u32 *start, u32 *limit)
 +{
 +return 0;
 +}
 +#else
 +/**
 + * check_v123_tree - check integrety of a version 1, 2, or 3 tree
 + * @start: the start of the device tree struct
 + * @limit: the end of the region for the struct
 + * structural checks on device_tree
 + */
 +static int check_v123_tree(u32 *start, u32 *limit)

 What is the point of this check?  If the device tree is corrupt, we're
 stuffed anyway, so why bother?

Hence the ifdef NO_CHECK.   When developing, sometimes its nice to know 
if its your input or your program.  These functions are destructive to 
an improperlly formed tree, and in non-obvious ways.  When debugging, 
it's not hard to hardcode console write or read the printf string 
buffer with a hardware debugger to see error messages.  That said, it 
could be removed.


 +{
 +u32 len;
 +int depth = 0;
 +u32 *dtp = start;
 +
 +while (dtp  limit)
 +switch (*dtp) {
 +case OF_DT_END:
 +if (depth)
 +return -1;
 +return ++dtp - start;
 +case OF_DT_NOP:
 +dtp++;
 +break;
 +case OF_DT_END_NODE:
 +dtp++;
 +depth--;
 +break;
 +case OF_DT_BEGIN_NODE:
 +len = strlen((char *)(++dtp));
 +/* check path is suffix to previous? */
 +dtp += 1 + (len / 4);
 +depth++;
 +break;
 +case OF_DT_PROP:
 +len = dtp[1];
 +dtp += 3;
 +if ((len = 8)  ((long)dtp  4))
 +dtp++;
 +dtp += (len + 3) / 4;
 +break;
 +default:
 +return -1;
 +}
 +return -1;  /* no OF_DT_END */
 +}
 +#endif
 +
 +/**
 + * nop_to_v16 - add %OF_DT_NOP to hide alignment differences
 + * @dtp: pointer to the beginning of the struct area to modify
 + * insert %OF_DT_NOP into the dt_struct @dtp to make it v16 from v1, 
 2, or 3.
 + */
 +static int nop_to_v16(u32 *dtp)
 +{
 +int nops = 0;
 +char *p, *s;
 +int len;
 +u32 *next;
 +
 +while (*dtp != OF_DT_END)
 +switch (*dtp) {
 +case OF_DT_BEGIN_NODE:
 +/* v2  v3 names are full path, v16+ is relative */
 +p = (char *)(++dtp);
 +len = 

Re: [PATCH 1/15] boot: find initrd location from device-tree

[Milton Miller]

On Sep 23, 2007, at 9:58 PM, David Gibson wrote:

 On Fri, Sep 21, 2007 at 06:03:24PM -0500, Milton Miller wrote:
 Some platforms have a boot agent that can create or modify properties 
 in
 the device-tree and load images into memory.  Provide a helper to set
 loader_info used by prep_initrd().

 Signed-off-by: Milton Miller [EMAIL PROTECTED]
 Acked-by: David Gibson [EMAIL PROTECTED]

 Hrm, despite my earlier ack, I'm going to whinge about a few nits
 here.

 ---
 re 12168
 rediffed types.h, offset in ops.h

 Index: kernel/arch/powerpc/boot/ops.h
 ===
 --- kernel.orig/arch/powerpc/boot/ops.h  2007-09-17 22:12:47.0 
 -0500
 +++ kernel/arch/powerpc/boot/ops.h   2007-09-17 22:12:51.0 -0500
 @@ -163,6 +163,7 @@ void dt_fixup_clock(const char *path, u3
  void __dt_fixup_mac_addresses(u32 startindex, ...);
  #define dt_fixup_mac_addresses(...) \
  __dt_fixup_mac_addresses(0, __VA_ARGS__, NULL)
 +void dt_find_initrd(void);


  static inline void *find_node_by_linuxphandle(const u32 linuxphandle)
 Index: kernel/arch/powerpc/boot/types.h
 ===
 --- kernel.orig/arch/powerpc/boot/types.h2007-09-17 
 22:12:47.0 -0500
 +++ kernel/arch/powerpc/boot/types.h 2007-09-17 22:12:51.0 
 -0500
 @@ -12,6 +12,8 @@ typedef short  s16;
  typedef int s32;
  typedef long long   s64;

 +#define UINT_MAX0x

 I actually don't like this constant - at the point you compare you
 care, explicitly, about the value not being over 32-bits, rather than
 whether it fits a uint, so the named constant is more misleading than
 helpful.

Arguable, I don't like counting F's or zeros in C code.

It is used as the max address that the wrapper deals with, both here 
and memranges, which happens to be 32 bits.

Actually it cares about overflowing the unsigned long in loader_info, 
not that the address fits in 32 bits.

So it should be ULONG_MAX now (malloc and all the address code was 
changed to use unsigned long instead of unsigned int since the patch 
was written).

And dt_xlate needs the same information.  Its is using a hardcoded 64 
bit constant to provide the a simiar check.


 +
  #define min(x,y) ({ \
  typeof(x) _x = (x); \
  typeof(y) _y = (y); \
 Index: kernel/arch/powerpc/boot/devtree.c
 ===
 --- kernel.orig/arch/powerpc/boot/devtree.c  2007-09-17 
 22:12:47.0 -0500
 +++ kernel/arch/powerpc/boot/devtree.c   2007-09-17 22:12:51.0 
 -0500
 @@ -1,6 +1,7 @@
  /*
   * devtree.c - convenience functions for device tree manipulation
   * Copyright 2007 David Gibson, IBM Corporation.
 + * Copyright 2007 Milton Miller, IBM Corporation.
   * Copyright (c) 2007 Freescale Semiconductor, Inc.
   *
   * Authors: David Gibson [EMAIL PROTECTED]
 @@ -333,3 +334,68 @@ int dt_is_compatible(void *node, const c

  return 0;
  }
 +
 +/**
 + * dt_find_initrd - set loader initrd location based on existing 
 properties
 + *
 + * finds the linux,initrd-start and linux,initrd-end properties in
 + * the /chosen node and sets the loader initrd fields accordingly.
 + *
 + * Use this if your loader sets the properties to allow other code to
 + * relocate the tree and/or cause r3 and r4 to be set on true OF
 + * platforms.

 I am unable to make sense of the paragraph above.

The phrase relocate the tree should be relocate the initrd, which 
the wrapper will do if it located below vmlinux.size.  Also, r3 and r4 
need to be set when booting the kernel from a client interface with an 
initrd so it can take it into consideration when choosing the location 
to build the flat tree.

How about:

Filling in the loader info allows main.c to be aware of the initrd, 
meaning prep_initrd will move the initrd if it will be overwritten when 
the kernel is copied to its runtime location.  In addition, if you are 
booting the kernel from a client interface instead of a flat device 
tree, this also causes r3 and r4 to be set so the kernel can avoid 
overwriting the initrd when creating the flat tree.


 + */
 +void dt_find_initrd(void)
 +{
 +int rc;
 +unsigned long long initrd_start, initrd_end;
 +void *devp;
 +static const char start_prop[] = linux,initrd-start;
 +static const char end_prop[] = linux,initrd-end;

 I think these constants are more obscuring than useful.

They are useful to the extent they reduce the number of source 
characters causing about 8 less line wraps.  Since they are used 
multiple places, the compiler only needs to emit one copy of this byte 
sequence.  Admitedly you made this point in a prior review.


 +
 +devp = finddevice(/chosen);
 +if (! devp) {
 +return;
 +}

 CodingStyle would not put { } here.

Yea, nit.  not sure why I have the braces there, I usually follow that 
one.  And what's 

[PATCH] fix mace_handle_misc_intrs compilation

[Olaf Hering]

Fix compilation after incomplete struct net_device changes.

Signed-off-by: Olaf Hering [EMAIL PROTECTED]

---
 drivers/net/mace.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/net/mace.c
+++ b/drivers/net/mace.c
@@ -633,7 +633,7 @@ static void mace_set_multicast(struct ne
 spin_unlock_irqrestore(mp-lock, flags);
 }
 
-static void mace_handle_misc_intrs(struct mace_data *mp, int intr)
+static void mace_handle_misc_intrs(struct mace_data *mp, int intr, struct 
net_device *dev)
 {
 volatile struct mace __iomem *mb = mp-mace;
 static int mace_babbles, mace_jabbers;
@@ -669,7 +669,7 @@ static irqreturn_t mace_interrupt(int ir
 spin_lock_irqsave(mp-lock, flags);
 intr = in_8(mb-ir);  /* read interrupt register */
 in_8(mb-xmtrc);  /* get retries */
-mace_handle_misc_intrs(mp, intr);
+mace_handle_misc_intrs(mp, intr, dev);
 
 i = mp-tx_empty;
 while (in_8(mb-pr)  XMTSV) {
@@ -682,7 +682,7 @@ static irqreturn_t mace_interrupt(int ir
 */
intr = in_8(mb-ir);
if (intr != 0)
-   mace_handle_misc_intrs(mp, intr);
+   mace_handle_misc_intrs(mp, intr, dev);
if (mp-tx_bad_runt) {
fs = in_8(mb-xmtfs);
mp-tx_bad_runt = 0;
@@ -817,7 +817,7 @@ static void mace_tx_timeout(unsigned lon
goto out;
 
 /* update various counters */
-mace_handle_misc_intrs(mp, in_8(mb-ir));
+mace_handle_misc_intrs(mp, in_8(mb-ir), dev);
 
 cp = mp-tx_cmds + NCMDS_TX * mp-tx_empty;
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/15] bootwrapper: occuppied memory ranges

[Milton Miller]

On Sep 23, 2007, at 10:09 PM, David Gibson wrote:
 On Fri, Sep 21, 2007 at 06:04:18PM -0500, Milton Miller wrote:
 Add a set of library routines to manage gross memory allocations.

 This code uses an array in bss to store upto 32 entrys with merging
 representing a range of memory below rma_end (aka end of real mode
 memory at 0).

 To use this code, a platform would set rma_end (find_rma_end), mark
 memory ranges occupied (add_known_ranges et al), initialize malloc in
 the spaces between (ranges_init_malloc), and optionally use the 
 supplied
 vmlinux_alloc may be used.

 Urg.  It's an awful lot of code for the bootwrapper.  Am I right in
 understanding that the only reason to use the ranges code is for the
 ranges based malloc() and vmlinux_alloc() you get out of it?

Yes.

The ranges based malloc is simple_alloc after finding a sutable chunk 
to operate in.

When doing a kexec, there are several chunks of memory to avoid.  There 
are at least the wrapper, the initrd, the input device tree, and 
possibly rtas and tce tables.  The last two are avoided by parsing the 
memory resrve list in the flat tree blob.

In practice, on 64 bit powerpc kexec-tools loads the kernel (in this 
case zImage) immediately following the old kernel _end (becauset the 
kernel doesnt' allow otherwise, like 32 bit and most other platforms 
do).  If the kernel being execd is larger than the kernel invoking 
kexec, then the vmlinux will not fit below the wrapper, but when they 
are the same it will fit.  So in the malloc region we need space for 
random temps, the final device tree, the kernel, and possibly the 
initrd -- especially if its attached to the zImage instead of supplied 
by kexec-tools.

While I titled this platform kexec, in reality, it is a generic chain 
looading platform for flat device trees in that it is invoked with the 
same calling conveintions as it calls the kernel.  With the current 
policy of run-where-loadeed, the wrapper has to be able to find out 
what memory is available.  It may be above or below itself, and the 
bulk of available memory may be after any of the above mentioned 
ranges.  The only information is the the flat device tree and its 
knowledge of itself.  Most of this code deals with building the sorted 
list of what memory is used.

Actually, there is a hole in that malloc may be initialzed below the 
vmlinux.size and the initrd and deviece tree could end up overwritten.  
This can't be eliminated without doing something like prpmc2800 where 
the kernel decompression is started and the elf header is read before 
initializing malloc.  In practice has not  triggered because the 
vmlinux will be malloced before the device tree without an initrd, and 
with it the kernel is likely smaller than the wrapper (since the memory 
chunk at 0 is avoided, it requires the end of some other chunk to be 
low in memory).

At one point you had mentioned considering changes to run out of bss 
and handling the initrd and kernel with calls to memmove; any such 
movement would requrie similar information to what is being built into 
the storted structure in this code to support externally loaded initrds 
and device-trees, which could not be allocated into the bss wihout 
arbitrarilly limiting their size.

I've made several changes to the split btween memranges.c and kexec.c 
over time.  Perhaps there are more left.  There is a bit of policy in 
the ranges malloc initialilzation; that could probably be eliminated by 
query functions for the largest chunk. The vmlinux alloc could try just 
0 and malloc().  And the area from the last occupied range to roa_end 
should be available for malloc as well as the kernel.

milton

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] qemu platform, v2

[Milton Miller]

On Sep 24, 2007, at 2:46 AM, Christoph Hellwig wrote:
 On Mon, Sep 24, 2007 at 02:00:47PM +1000, David Gibson wrote:
 Basically because PReP support doesn't work under arch/powerpc.
 Getting it working properly is something that should happen, but will
 take a while.  In the meantime, getting something that's sufficient to
 get working under just qemu's version of prep, without using the
 abominable openhackware is a quicker path to a usable arch/powerpc
 kernel under qemu.

 Sounds fair.  Care to add something like this to the Kconfig help
 text?

I suppose I could, but actually I wasn't asking for the two qemu 
patches to be merged.  Instead I was posting here's something that 
provides minimal function for me, hope you can use it too.  For 
instance, someone should track down pci memory so that ohci and/or 
video works.  Then test the isa ne2ks, or better yet get qemu to change 
them to pci (except then it only works on the latest qemu).

I didn't put it under prep because it could be changed for the other 
qemu platforms and doesn't use any thing that makes the machine prep 
other than some memory map information.  I kept prep because I didn't 
want to deal with io to the scc on bw G3, the other long-term platform 
(or with hackware to see if that would just boot as pmac).

milton

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2] bootwrapper: adds cuboot for MPC7448HPC2 platform

[Zang Roy-r61911]

From: Roy Zang [EMAIL PROTECTED]

This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.

Signed-off-by: Roy Zang [EMAIL PROTECTED]
---
This is the third time for me to generate the patch.
I do not get any negative comment since my previous commit .
Hope your guys can pick it up and merge it into 2.6.24.
The original were pasted at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038952.html

Cheers

 arch/powerpc/boot/Makefile |3 +-
 arch/powerpc/boot/cuboot-hpc2.c|   48 
 arch/powerpc/boot/dts/mpc7448hpc2.dts  |5 +++
 arch/powerpc/platforms/embedded6xx/Kconfig |1 +
 4 files changed, 56 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-hpc2.c

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cffef14..6ed1415 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c 
flatdevtree_misc.c \
 src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
-   cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
+   cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-hpc2.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,6 +146,7 @@ image-$(CONFIG_8260)+= cuImage.pq2
 image-$(CONFIG_PPC_83xx)   += cuImage.83xx
 image-$(CONFIG_PPC_85xx)   += cuImage.85xx
 image-$(CONFIG_EBONY)  += treeImage.ebony cuImage.ebony
+image-$(CONFIG_MPC7448HPC2)+= cuImage.hpc2
 image-$(CONFIG_BAMBOO) += treeImage.bamboo
 image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
 image-$(CONFIG_WALNUT) += treeImage.walnut
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
new file mode 100644
index 000..d333898
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang [EMAIL PROTECTED]
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood [EMAIL PROTECTED]
+ * for 83xx and 85xx.
+ *
+ * This 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;  either version 2 of the  License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include ops.h
+#include stdio.h
+#include cuboot.h
+
+#define TARGET_HAS_ETH1
+#include ppcboot.h
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+   void *tsi;
+
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+   dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+   dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+   tsi = find_node_by_devtype(NULL, tsi-bridge);
+   if (tsi)
+   setprop(tsi, bus-frequency, bd.bi_busfreq,
+   sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+   unsigned long r6, unsigned long r7)
+{
+   CUBOOT_INIT();
+   ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+   serial_console_init();
+   platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts 
b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 70e8a2e..0b58136 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -79,6 +79,7 @@
};
 
[EMAIL PROTECTED] {
+   linux,network-index = 0;
#size-cells = 0;
device_type = network;
compatible = tsi109-ethernet, tsi108-ethernet;
@@ -91,6 +92,7 @@
};
 
[EMAIL PROTECTED] {
+   linux,network-index = 1;
#address-cells = 1;
#size-cells = 0;
device_type = network;
@@ -184,5 +186,8 @@
};
};
};
+   chosen {
+   linux,stdout-path = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
+   };
 
 };
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig 
b/arch/powerpc/platforms/embedded6xx/Kconfig
index 2d12f77..6d10e84 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -20,6 +20,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+  

Re: [PATCH 0/3] usb: ehci ppc device-tree-aware driver

[Valentine Barshak]

Hollis Blanchard wrote:
 On Mon, 17 Sep 2007 16:50:39 +0400, Valentine Barshak wrote:
 
 Some PowerPC systems have a built-in EHCI controller.
 This is a device tree aware version of the EHCI controller driver.
 Currently it's been tested on the PowerPC 440EPx Sequoia board.
 Other platforms can be added later.
 The code is based on the ehci-ppc-soc driver by Stefan Roese [EMAIL 
 PROTECTED].
 
 We're having a strange issue on our Sequoia where the network stops
 functioning when USB is active. Jerone can supply more detail...

OK.
This possibly could be caused by the plb write pipelining errata.
Please, take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042999.html

 
 Have you seen anything like that?

No, I haven't.

 

Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Sequoia kernel crash workaround.

[Valentine Barshak]

Benjamin Herrenschmidt wrote:
 On Thu, 2007-09-20 at 12:29 -0500, Josh Boyer wrote:
 On Thu, 20 Sep 2007 12:25:06 -0500
 Olof Johansson [EMAIL PROTECTED] wrote:

 On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
 I was thinking about it. Looks like it's the best place, but the code that 
 actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of 
 cpu_setup functions are defined for ppc32 processors.
 Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
 Sounds like something that went wrong at the merge of ppc and ppc64.

 Take out the ifdef, even if there's fallout we should deal with it
 instead of adding more complex ifdefs.
 Yeah.  Looks like BenH did this in commit:

 42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc

 Ben, any reason you ifdef'd it for ppc64?
 
 I'll have to check on monday what's up there, but isn't setup_cpu called
 from a different place on 32 bits? There are some subtle difference with
 the way the cpu feature stuff is initialized /done between 32 and 64
 bits that we haven't fully reconciled yet. 
 
 Ben.
 

 From what I've seen, setup_cpu is never called for BOOKE.
Currently It's called from cputable.c for PPC64 and from head_32.S for 6xx.
Thanks,
Valentine.

 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c

[Mel Gorman]

On (22/09/07 08:20), Satyam Sharma didst pronounce:
 Hi,
 
 
 On Thu, 20 Sep 2007, Alan Cox wrote:
  
  On Thu, 20 Sep 2007 14:13:15 +0100
  [EMAIL PROTECTED] (Mel Gorman) wrote:
  
   PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
   doesn't show up on other arches because this driver is specific to the
   architecture.
   
   drivers/ata/pata_scc.c: In function `scc_bmdma_status'
  
  Its not been updated to match the libata core changes. Try something like
  this. Whoever is maintaining it should also remove the prereset cable 
  handling
  code and use the proper cable detect method.
 
 It appears you forgot to fix scc_std_softreset() and one of its callsites
 in scc_bdma_stop(). A complete patch is attempted below -- please review.
 

I can confirm it builds without warnings or errors, so thanks. I'm not in
the position to review it for correctness.

 
 [PATCH -mm] pata_scc: Keep up with libata core API changes
 
 Little fixlets, that the build started erroring / warning about:
 
 drivers/ata/pata_scc.c: In function 'scc_bmdma_status':
 drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag'
 drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
 drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from 
 incompatible pointer type
 drivers/ata/pata_scc.c: In function 'scc_error_handler':
 drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' 
 from incompatible pointer type
 drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' 
 from incompatible pointer type
 drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' 
 from incompatible pointer type
 make[2]: *** [drivers/ata/pata_scc.o] Error 1
 
 Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
 Cc: Alan Cox [EMAIL PROTECTED]
 Cc: Mel Gorman [EMAIL PROTECTED]
 
 ---
 
 Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
 
  drivers/ata/pata_scc.c |   21 -
  1 file changed, 12 insertions(+), 9 deletions(-)
 
 diff -ruNp a/drivers/ata/pata_scc.c b/drivers/ata/pata_scc.c
 --- a/drivers/ata/pata_scc.c  2007-09-22 06:26:37.0 +0530
 +++ b/drivers/ata/pata_scc.c  2007-09-22 08:04:42.0 +0530
 @@ -594,16 +594,17 @@ static unsigned int scc_bus_softreset(st
   *   Note: Original code is ata_std_softreset().
   */
  
 -static int scc_std_softreset (struct ata_port *ap, unsigned int *classes,
 -  unsigned long deadline)
 +static int scc_std_softreset(struct ata_link *link, unsigned int *classes,
 + unsigned long deadline)
  {
 + struct ata_port *ap = link-ap;
   unsigned int slave_possible = ap-flags  ATA_FLAG_SLAVE_POSS;
   unsigned int devmask = 0, err_mask;
   u8 err;
  
   DPRINTK(ENTER\n);
  
 - if (ata_link_offline(ap-link)) {
 + if (ata_link_offline(link)) {
   classes[0] = ATA_DEV_NONE;
   goto out;
   }
 @@ -692,7 +693,7 @@ static void scc_bmdma_stop (struct ata_q
   printk(KERN_WARNING %s: Internal Bus Error\n, 
 DRV_NAME);
   out_be32(bmid_base + SCC_DMA_INTST, INTSTS_BMSINT);
   /* TBD: SW reset */
 - scc_std_softreset(ap, classes, deadline);
 + scc_std_softreset(ap-link, classes, deadline);
   continue;
   }
  
 @@ -731,7 +732,7 @@ static u8 scc_bmdma_status (struct ata_p
   void __iomem *mmio = ap-ioaddr.bmdma_addr;
   u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
   u32 int_status = in_be32(mmio + SCC_DMA_INTST);
 - struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap-active_tag);
 + struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap-link.active_tag);
   static int retry = 0;
  
   /* return if IOS_SS is cleared */
 @@ -860,10 +861,10 @@ static void scc_bmdma_freeze (struct ata
   *   @deadline: deadline jiffies for the operation
   */
  
 -static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
 +static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
  {
 - ap-cbl = ATA_CBL_PATA80;
 - return ata_std_prereset(ap, deadline);
 + link-ap-cbl = ATA_CBL_PATA80;
 + return ata_std_prereset(link, deadline);
  }
  
  /**
 @@ -874,8 +875,10 @@ static int scc_pata_prereset(struct ata_
   *   Note: Original code is ata_std_postreset().
   */
  
 -static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
 +static void scc_std_postreset(struct ata_link *link, unsigned int *classes)
  {
 + struct ata_port *ap = link-ap;
 +
   DPRINTK(ENTER\n);
  
   /* is double-select really necessary? */
 

-- 
-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
___
Linuxppc-dev mailing list

Re: AMCC yosemite 440ep PCI slot doesn't work.

[Stefan Roese]

On Monday 24 September 2007, Andrew Liu wrote:
 By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE

And that should be correct for PCI interrupts.

  I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE  or
 IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
 It  displays:
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
 eth2: no IPv6 routers present
 NETDEV WATCHDOG: eth2: transmit timed out
 eth2: Transmit timeout, status 0c 0005 c07f media 10.
 eth2: Tx queue start entry 4  dirty entry 0.
 eth2:  Tx descriptor 0 is 0008a05a. (queue head)
 eth2:  Tx descriptor 1 is 0008a04e.
 eth2:  Tx descriptor 2 is 0008a046.
 eth2:  Tx descriptor 3 is 0008a05a.
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1

 and
 [EMAIL PROTECTED]:/root ifconfig  eth2
 eth2  Link encap:Ethernet  HWaddr 00:0E:2E:7E:F5:E6
   inet addr:128.224.149.13  Bcast:128.224.255.255  Mask:255.255.0.0
   inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
   Interrupt:25 Base address:0x6f00


 and
 [EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0
   2:  0  UIC0 Edge  IBM IIC
   7:  0  UIC0 Edge  IBM IIC
  10:  11961  UIC0 Edge  MAL TX EOB
  11:  18471  UIC0 Edge  MAL RX EOB
  25:  0  UIC0 Edge  eth2
  32:  0  UIC1 Edge  MAL SERR
  33:  0  UIC1 Edge  MAL TX DE
  34:  0  UIC1 Edge  MAL RX DE
  40: 32  UIC1 Edge  ohci_hcd:usb1
  60:  0  UIC1 Edge  EMAC
 BAD:  0


 Can PCI slot use level trigger?

 give me some advice.

Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even 
earlier? Please give it a try and let us know if the same problem occurs.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: AMCC yosemite 440ep PCI slot doesn't work.

[Valentine Barshak]

Stefan Roese wrote:
 On Monday 24 September 2007, Andrew Liu wrote:
 By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
 
 And that should be correct for PCI interrupts.
 
  I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE  or
 IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
 It  displays:
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
 eth2: no IPv6 routers present
 NETDEV WATCHDOG: eth2: transmit timed out
 eth2: Transmit timeout, status 0c 0005 c07f media 10.
 eth2: Tx queue start entry 4  dirty entry 0.
 eth2:  Tx descriptor 0 is 0008a05a. (queue head)
 eth2:  Tx descriptor 1 is 0008a04e.
 eth2:  Tx descriptor 2 is 0008a046.
 eth2:  Tx descriptor 3 is 0008a05a.
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1

 and
 [EMAIL PROTECTED]:/root ifconfig  eth2
 eth2  Link encap:Ethernet  HWaddr 00:0E:2E:7E:F5:E6
   inet addr:128.224.149.13  Bcast:128.224.255.255  Mask:255.255.0.0
   inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
   Interrupt:25 Base address:0x6f00


 and
 [EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0
   2:  0  UIC0 Edge  IBM IIC
   7:  0  UIC0 Edge  IBM IIC
  10:  11961  UIC0 Edge  MAL TX EOB
  11:  18471  UIC0 Edge  MAL RX EOB
  25:  0  UIC0 Edge  eth2
  32:  0  UIC1 Edge  MAL SERR
  33:  0  UIC1 Edge  MAL TX DE
  34:  0  UIC1 Edge  MAL RX DE
  40: 32  UIC1 Edge  ohci_hcd:usb1
  60:  0  UIC1 Edge  EMAC
 BAD:  0


 Can PCI slot use level trigger?

 give me some advice.

This could be caused by misseting the IRQ_lEVEL flag in desc-status.
There have been a commit 4dc7b4b0405fd7320940849b6e31ea8ea68fd0df that 
fixes the problem.
Thanks,
Valentine.

 
 Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even 
 earlier? Please give it a try and let us know if the same problem occurs.
 
 Best regards,
 Stefan
 
 =
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
 =

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Valentine Barshak]

Currently zImage is linked at the 4MB base address.
Some platforms (using cuboot, treeboot) need the zImage's
entry point and base address. They place zImage exactly
at the base address it's been linked to. Sometimes 4MB left
at the start of the memory is simply not enough to unpack zImage.
This could happen with initramfs enabled, since the kernel image
packed along with initramfs.cpio could be over 5MB in size.
This patch checks vmlinux image size and links zImage at
the base address that is equal to the unpacked image size
aligned to 4MB boundary. This way zImage base address is 4MB
only if unpacked kernel image size is less then 4MB.

Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
 arch/powerpc/boot/wrapper  |6 --
 arch/powerpc/boot/zImage.lds.S |2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff -ruN linux-2.6.orig/arch/powerpc/boot/wrapper 
linux-2.6/arch/powerpc/boot/wrapper
--- linux-2.6.orig/arch/powerpc/boot/wrapper2007-09-22 00:48:08.0 
+0400
+++ linux-2.6/arch/powerpc/boot/wrapper 2007-09-22 04:03:40.0 +0400
@@ -215,8 +215,10 @@
 fi
 
 if [ $platform != miboot ]; then
-${CROSS}ld -m elf32ppc -T $lds -o $ofile \
-   $platformo $tmp $object/wrapper.a
+kstart=0x`${CROSS}nm $kernel | grep ' _start$' | cut -d' ' -f1`
+kend=0x`${CROSS}nm $kernel | grep ' _end$' | cut -d' ' -f1`
+${CROSS}ld -m elf32ppc --defsym _kstart=$kstart --defsym _kend=$kend \
+   -T $lds -o $ofile $platformo $tmp $object/wrapper.a
 rm $tmp
 fi
 
diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 
linux-2.6/arch/powerpc/boot/zImage.lds.S
--- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S   2007-09-22 
00:48:08.0 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S2007-09-22 04:03:58.0 
+0400
@@ -3,7 +3,7 @@
 EXTERN(_zimage_start)
 SECTIONS
 {
-  . = (4*1024*1024);
+  . = ALIGN((_kend - _kstart), (4*1024*1024));
   _start = .;
   .text  :
   {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 6/6] Walnut zImage wrapper

[Josh Boyer]

On Mon, 24 Sep 2007 09:49:33 +0200
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
 
 The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for 
 the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
 
MODPOST vmlinux.o
 WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to 
 .init.text:prom_init (between '__start' and '__after_mmu_off')
 WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to 
 .init.text:early_init (between '__start' and '__after_mmu_off')
 WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to 
 .init.text:machine_init (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to 
 .init.text:MMU_init (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to 
 .init.text:start_kernel (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to 
 .init.text:start_kernel (between 'start_here' and 'set_context')
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC  init/version.o
LD  init/built-in.o
LD  vmlinux
SYSMAP  System.map
BOOTAS  arch/powerpc/boot/string.o
BOOTAS  arch/powerpc/boot/crt0.o
BOOTCC  arch/powerpc/boot/stdio.o
BOOTCC  arch/powerpc/boot/main.o
BOOTCC  arch/powerpc/boot/flatdevtree.o
BOOTCC  arch/powerpc/boot/flatdevtree_misc.o
BOOTCC  arch/powerpc/boot/ns16550.o
BOOTCC  arch/powerpc/boot/serial.o
BOOTCC  arch/powerpc/boot/simple_alloc.o
BOOTAS  arch/powerpc/boot/div64.o
BOOTAS  arch/powerpc/boot/util.o
BOOTCC  arch/powerpc/boot/gunzip_util.o
BOOTCC  arch/powerpc/boot/elf_util.o
BOOTCC  arch/powerpc/boot/inffast.o
BOOTCC  arch/powerpc/boot/inflate.o
BOOTCC  arch/powerpc/boot/inftrees.o
BOOTCC  arch/powerpc/boot/devtree.o
BOOTCC  arch/powerpc/boot/oflib.o
BOOTCC  arch/powerpc/boot/ofconsole.o
BOOTCC  arch/powerpc/boot/4xx.o
BOOTCC  arch/powerpc/boot/ebony.o
BOOTCC  arch/powerpc/boot/mv64x60.o
BOOTCC  arch/powerpc/boot/mpsc.o
BOOTCC  arch/powerpc/boot/mv64x60_i2c.o
BOOTCC  arch/powerpc/boot/cuboot.o
BOOTCC  arch/powerpc/boot/bamboo.o
BOOTAR  arch/powerpc/boot/wrapper.a
BOOTCC  arch/powerpc/boot/of.o
BOOTCC  arch/powerpc/boot/cuboot-83xx.o
BOOTCC  arch/powerpc/boot/cuboot-85xx.o
BOOTCC  arch/powerpc/boot/holly.o
BOOTCC  arch/powerpc/boot/cuboot-ebony.o
BOOTCC  arch/powerpc/boot/treeboot-ebony.o
BOOTCC  arch/powerpc/boot/prpmc2800.o
BOOTAS  arch/powerpc/boot/ps3-head.o
BOOTAS  arch/powerpc/boot/ps3-hvcall.o
BOOTCC  arch/powerpc/boot/ps3.o
BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
BOOTCC  arch/powerpc/boot/treeboot-walnut.o
 {standard input}: Assembler messages:
 {standard input}:184: Error: Unrecognized opcode: `mfdcr'
 {standard input}:185: Error: Unrecognized opcode: `mfdcr'
 {standard input}:186: Error: Unrecognized opcode: `mfdcr'
 {standard input}:217: Error: Unrecognized opcode: `mtdcr'
 make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
 make: *** [uImage] Error 2

 It looks like the ppc_6xx toolchain does not know the opcode above. I 
 wonder why files for other PowerPC sub-archs like 4xx are compiled with 
 the wrong compiler. Have I missed something?

No, you haven't missed anything.  I need a one line patch to fix it.
Could you try the patch below to make sure it works for you?

 And the WARNING above on Section mismatch looks strange as well (still 
 present in 2.6.23-rc7).

Those warnings should be gone with Paul's latest tree.  (They will
remain for 2.6.23.)

josh

Pass the correct -mcpu option for treeboot-walnut.o to avoid
unrecognized opcodes.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..8e6d36b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,6 +33,7 @@ BOOTCFLAGS+= -I$(obj) -I$(srctree)/$(obj)
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
 
 zlib   := inffast.c inflate.c inftrees.c
 zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 6/6] Walnut zImage wrapper

[Wolfgang Grandegger]

Josh Boyer wrote:
 On Mon, 24 Sep 2007 09:49:33 +0200
 Wolfgang Grandegger [EMAIL PROTECTED] wrote:
 The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for 
 the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:

MODPOST vmlinux.o
 WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to 
 .init.text:prom_init (between '__start' and '__after_mmu_off')
 WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to 
 .init.text:early_init (between '__start' and '__after_mmu_off')
 WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to 
 .init.text:machine_init (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to 
 .init.text:MMU_init (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to 
 .init.text:start_kernel (between 'start_here' and 'set_context')
 WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to 
 .init.text:start_kernel (between 'start_here' and 'set_context')
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC  init/version.o
LD  init/built-in.o
LD  vmlinux
SYSMAP  System.map
BOOTAS  arch/powerpc/boot/string.o
BOOTAS  arch/powerpc/boot/crt0.o
BOOTCC  arch/powerpc/boot/stdio.o
BOOTCC  arch/powerpc/boot/main.o
BOOTCC  arch/powerpc/boot/flatdevtree.o
BOOTCC  arch/powerpc/boot/flatdevtree_misc.o
BOOTCC  arch/powerpc/boot/ns16550.o
BOOTCC  arch/powerpc/boot/serial.o
BOOTCC  arch/powerpc/boot/simple_alloc.o
BOOTAS  arch/powerpc/boot/div64.o
BOOTAS  arch/powerpc/boot/util.o
BOOTCC  arch/powerpc/boot/gunzip_util.o
BOOTCC  arch/powerpc/boot/elf_util.o
BOOTCC  arch/powerpc/boot/inffast.o
BOOTCC  arch/powerpc/boot/inflate.o
BOOTCC  arch/powerpc/boot/inftrees.o
BOOTCC  arch/powerpc/boot/devtree.o
BOOTCC  arch/powerpc/boot/oflib.o
BOOTCC  arch/powerpc/boot/ofconsole.o
BOOTCC  arch/powerpc/boot/4xx.o
BOOTCC  arch/powerpc/boot/ebony.o
BOOTCC  arch/powerpc/boot/mv64x60.o
BOOTCC  arch/powerpc/boot/mpsc.o
BOOTCC  arch/powerpc/boot/mv64x60_i2c.o
BOOTCC  arch/powerpc/boot/cuboot.o
BOOTCC  arch/powerpc/boot/bamboo.o
BOOTAR  arch/powerpc/boot/wrapper.a
BOOTCC  arch/powerpc/boot/of.o
BOOTCC  arch/powerpc/boot/cuboot-83xx.o
BOOTCC  arch/powerpc/boot/cuboot-85xx.o
BOOTCC  arch/powerpc/boot/holly.o
BOOTCC  arch/powerpc/boot/cuboot-ebony.o
BOOTCC  arch/powerpc/boot/treeboot-ebony.o
BOOTCC  arch/powerpc/boot/prpmc2800.o
BOOTAS  arch/powerpc/boot/ps3-head.o
BOOTAS  arch/powerpc/boot/ps3-hvcall.o
BOOTCC  arch/powerpc/boot/ps3.o
BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
BOOTCC  arch/powerpc/boot/treeboot-walnut.o
 {standard input}: Assembler messages:
 {standard input}:184: Error: Unrecognized opcode: `mfdcr'
 {standard input}:185: Error: Unrecognized opcode: `mfdcr'
 {standard input}:186: Error: Unrecognized opcode: `mfdcr'
 {standard input}:217: Error: Unrecognized opcode: `mtdcr'
 make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
 make: *** [uImage] Error 2

 It looks like the ppc_6xx toolchain does not know the opcode above. I 
 wonder why files for other PowerPC sub-archs like 4xx are compiled with 
 the wrong compiler. Have I missed something?
 
 No, you haven't missed anything.  I need a one line patch to fix it.
 Could you try the patch below to make sure it works for you?

It works for me with one typo corrected (see below).

 
 And the WARNING above on Section mismatch looks strange as well (still 
 present in 2.6.23-rc7).
 
 Those warnings should be gone with Paul's latest tree.  (They will
 remain for 2.6.23.)

OK.

 Pass the correct -mcpu option for treeboot-walnut.o to avoid
 unrecognized opcodes.
 
 Signed-off-by: Josh Boyer [EMAIL PROTECTED]
 
 diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
 index c1582b6..8e6d36b 100644
 --- a/arch/powerpc/boot/Makefile
 +++ b/arch/powerpc/boot/Makefile
 @@ -33,6 +33,7 @@ BOOTCFLAGS+= -I$(obj) -I$(srctree)/$(obj)
  
  $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
  $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
 +$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
  ^ typo, should be BOOTCFLAGS

Thanks.

Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 6/6] Walnut zImage wrapper

[Josh Boyer]

On Mon, 24 Sep 2007 14:20:36 +0200
Wolfgang Grandegger [EMAIL PROTECTED] wrote:

 Josh Boyer wrote:
  On Mon, 24 Sep 2007 09:49:33 +0200
  Wolfgang Grandegger [EMAIL PROTECTED] wrote:
  The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for 
  the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
 
 MODPOST vmlinux.o
  WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to 
  .init.text:prom_init (between '__start' and '__after_mmu_off')
  WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to 
  .init.text:early_init (between '__start' and '__after_mmu_off')
  WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to 
  .init.text:machine_init (between 'start_here' and 'set_context')
  WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to 
  .init.text:MMU_init (between 'start_here' and 'set_context')
  WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to 
  .init.text:start_kernel (between 'start_here' and 'set_context')
  WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to 
  .init.text:start_kernel (between 'start_here' and 'set_context')
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  vmlinux
 SYSMAP  System.map
 BOOTAS  arch/powerpc/boot/string.o
 BOOTAS  arch/powerpc/boot/crt0.o
 BOOTCC  arch/powerpc/boot/stdio.o
 BOOTCC  arch/powerpc/boot/main.o
 BOOTCC  arch/powerpc/boot/flatdevtree.o
 BOOTCC  arch/powerpc/boot/flatdevtree_misc.o
 BOOTCC  arch/powerpc/boot/ns16550.o
 BOOTCC  arch/powerpc/boot/serial.o
 BOOTCC  arch/powerpc/boot/simple_alloc.o
 BOOTAS  arch/powerpc/boot/div64.o
 BOOTAS  arch/powerpc/boot/util.o
 BOOTCC  arch/powerpc/boot/gunzip_util.o
 BOOTCC  arch/powerpc/boot/elf_util.o
 BOOTCC  arch/powerpc/boot/inffast.o
 BOOTCC  arch/powerpc/boot/inflate.o
 BOOTCC  arch/powerpc/boot/inftrees.o
 BOOTCC  arch/powerpc/boot/devtree.o
 BOOTCC  arch/powerpc/boot/oflib.o
 BOOTCC  arch/powerpc/boot/ofconsole.o
 BOOTCC  arch/powerpc/boot/4xx.o
 BOOTCC  arch/powerpc/boot/ebony.o
 BOOTCC  arch/powerpc/boot/mv64x60.o
 BOOTCC  arch/powerpc/boot/mpsc.o
 BOOTCC  arch/powerpc/boot/mv64x60_i2c.o
 BOOTCC  arch/powerpc/boot/cuboot.o
 BOOTCC  arch/powerpc/boot/bamboo.o
 BOOTAR  arch/powerpc/boot/wrapper.a
 BOOTCC  arch/powerpc/boot/of.o
 BOOTCC  arch/powerpc/boot/cuboot-83xx.o
 BOOTCC  arch/powerpc/boot/cuboot-85xx.o
 BOOTCC  arch/powerpc/boot/holly.o
 BOOTCC  arch/powerpc/boot/cuboot-ebony.o
 BOOTCC  arch/powerpc/boot/treeboot-ebony.o
 BOOTCC  arch/powerpc/boot/prpmc2800.o
 BOOTAS  arch/powerpc/boot/ps3-head.o
 BOOTAS  arch/powerpc/boot/ps3-hvcall.o
 BOOTCC  arch/powerpc/boot/ps3.o
 BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
 BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
 BOOTCC  arch/powerpc/boot/treeboot-walnut.o
  {standard input}: Assembler messages:
  {standard input}:184: Error: Unrecognized opcode: `mfdcr'
  {standard input}:185: Error: Unrecognized opcode: `mfdcr'
  {standard input}:186: Error: Unrecognized opcode: `mfdcr'
  {standard input}:217: Error: Unrecognized opcode: `mtdcr'
  make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
  make: *** [uImage] Error 2
 
  It looks like the ppc_6xx toolchain does not know the opcode above. I 
  wonder why files for other PowerPC sub-archs like 4xx are compiled with 
  the wrong compiler. Have I missed something?
  
  No, you haven't missed anything.  I need a one line patch to fix it.
  Could you try the patch below to make sure it works for you?
 
 It works for me with one typo corrected (see below).

Ah, yes.  That's what I get for coding before coffee.

Thanks Wolfgang.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

2.6.23-rc7-mm1 -- powerpc rtas panic

[Andy Whitcroft]

Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:

Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047ac8
cpu 0x0: Vector: 300 (Data Access) at [c058f750]
pc: c0047ac8: .pSeries_log_error+0x364/0x420
lr: c0047a4c: .pSeries_log_error+0x2e8/0x420
sp: c058f9d0
   msr: 80001032
   dar: 0
 dsisr: 4200
  current = 0xc04a9b30
  paca= 0xc04aa700
pid   = 0, comm = swapper
enter ? for help
[c058faf0] c0021164 .rtas_call+0x200/0x250
[c058fba0] c0049cd0 .early_enable_eeh+0x168/0x360
[c058fc70] c002f674 .traverse_pci_devices+0x8c/0x138
[c058fd10] c0460ce8 .eeh_init+0x1a8/0x200
[c058fdb0] c045fb70 .pSeries_setup_arch+0x128/0x234
[c058fe40] c044f830 .setup_arch+0x214/0x24c
[c058fee0] c0446a38 .start_kernel+0xd4/0x3e4
[c058ff90] c0373194 .start_here_common+0x54/0x58

This machine is a:

processor   : 0
cpu : POWER4+ (gq)
clock   : 1703.965296MHz
revision: 19.0

[...]

timebase: 212995662
machine : CHRP IBM,7040-681

-apw
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC

[Scott Wood]

David Gibson wrote:
  [EMAIL PROTECTED] {
 +#address-cells = 1;
 +#size-cells = 0;
  device_type = i2c;
 
 Hrm... we probably want an i2c device_type class, but I don't think
 we've actually defined one, which is a problem

Right... but we need to get the kernel to stop expecting the device type 
to be there before we yell at people for including it. :-)

 The fact that NVRAM+RTC chips are so common is a bit of an issue from
 the point of view of defining a device class binding - a device can't
 have type rtc and nvram.

This is one of the reasons that I'd prefer to use compatible for such 
things.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Problems compiling Linux for MPC8272ADS

[Manil Gaouar]

Hi there,

I am trying to compile the latest Linux from the git repos: git clone
git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
the code a few weeks ago and was able to build my uImage no problems. I
did a git pull this morning and I can not compile anymore, here is the
error message I have:

  BOOTCC  arch/powerpc/boot/ps3.o
  BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
  BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
  BOOTCC  arch/powerpc/boot/treeboot-walnut.o
{standard input}: Assembler messages:
{standard input}:184: Error: Unrecognized opcode: `mfdcr'
{standard input}:185: Error: Unrecognized opcode: `mfdcr'
{standard input}:186: Error: Unrecognized opcode: `mfdcr'
{standard input}:217: Error: Unrecognized opcode: `mtdcr'
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
make: *** [uImage] Error 2

here are the commands I am using:

make mrproper
make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage

Do you have any ideas, or I should check out the 2.6.22 stable release
instead and try again???

Thx
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems compiling Linux for MPC8272ADS

[Josh Boyer]

On Mon, 24 Sep 2007 12:26:24 -0400
Manil Gaouar [EMAIL PROTECTED] wrote:

 Hi there,
 
 I am trying to compile the latest Linux from the git repos: git clone
 git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
 the code a few weeks ago and was able to build my uImage no problems. I
 did a git pull this morning and I can not compile anymore, here is the
 error message I have:
 
   BOOTCC  arch/powerpc/boot/ps3.o
   BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
   BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
   BOOTCC  arch/powerpc/boot/treeboot-walnut.o
 {standard input}: Assembler messages:
 {standard input}:184: Error: Unrecognized opcode: `mfdcr'
 {standard input}:185: Error: Unrecognized opcode: `mfdcr'
 {standard input}:186: Error: Unrecognized opcode: `mfdcr'
 {standard input}:217: Error: Unrecognized opcode: `mtdcr'
 make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
 make: *** [uImage] Error 2
 
 here are the commands I am using:
 
 make mrproper
 make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
 make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage
 
 Do you have any ideas, or I should check out the 2.6.22 stable release
 instead and try again???

Apply this:


[POWERPC] 4xx: Fix Walnut wrapper compile errors

Pass the appropriate -mcpu flag to the treeboot-walnut.o object to prevent
some toolchains from erroring out with unknown opcodes

Signed-off-by: Josh Boyer [EMAIL PROTECTED]

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..ac516a1 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,6 +33,7 @@ BOOTCFLAGS+= -I$(obj) -I$(srctree)/$(obj)
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
 
 zlib   := inffast.c inflate.c inftrees.c
 zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [EMAIL PROTECTED]: 2.6.23-rc6-mm1 -- powerpc pSeries_log_error panic in rtas_call/early_enable_eeh]

[Linas Vepstas]

I just got back from vacation.

I'll give this a whirl shortly.

--linas

On Sun, Sep 23, 2007 at 11:17:40AM -0500, Anton Blanchard wrote:
 
 Hi Linas,
 
 Looks like EEH could be involved :)
 
 Anton
 
 - Forwarded message from Andy Whitcroft [EMAIL PROTECTED] -
 
 From: Andy Whitcroft [EMAIL PROTECTED]
 To: Andrew Morton [EMAIL PROTECTED]
 Subject: 2.6.23-rc6-mm1 -- powerpc pSeries_log_error panic in
   rtas_call/early_enable_eeh
 X-SPF-Guess: neutral
 Cc: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 X-BeenThere: linuxppc-dev@ozlabs.org
 X-Mailman-Version: 2.1.9
 List-Id: Linux on PowerPC Developers Mail List linuxppc-dev.ozlabs.org
 List-Unsubscribe: https://ozlabs.org/mailman/listinfo/linuxppc-dev,
   mailto:[EMAIL PROTECTED]
 List-Archive: http://ozlabs.org/pipermail/linuxppc-dev
 List-Post: mailto:linuxppc-dev@ozlabs.org
 List-Help: mailto:[EMAIL PROTECTED]
 List-Subscribe: https://ozlabs.org/mailman/listinfo/linuxppc-dev,
   mailto:[EMAIL PROTECTED]
 
 Seeing the following panic booting an old powerpc LPAR:
 
 Unable to handle kernel paging request for data at address 0x
 Faulting instruction address: 0xc0047b48
 cpu 0x0: Vector: 300 (Data Access) at [c06a3750]
 pc: c0047b48: .pSeries_log_error+0x364/0x420
 lr: c0047acc: .pSeries_log_error+0x2e8/0x420
 sp: c06a39d0
msr: 80001032
dar: 0
  dsisr: 4200
   current = 0xc05acab0
   paca= 0xc05ad700
 pid   = 0, comm = swapper
 enter ? for help
 [c06a3af0] c0021164 .rtas_call+0x200/0x250
 [c06a3ba0] c0049d50 .early_enable_eeh+0x168/0x360
 [c06a3c70] c002f674 .traverse_pci_devices+0x8c/0x138
 [c06a3d10] c0560ce8 .eeh_init+0x1a8/0x200
 [c06a3db0] c055fb70 .pSeries_setup_arch+0x128/0x234
 [c06a3e40] c054f830 .setup_arch+0x214/0x24c
 [c06a3ee0] c0546a38 .start_kernel+0xd4/0x3e4
 [c06a3f90] c045adc4 .start_here_common+0x54/0x58
 0:mon
 
 This machine is:
 
 # cat /proc/cpuinfo
 processor   : 0
 cpu : POWER4+ (gq)
 clock   : 1703.965296MHz
 revision: 19.0
 
 [...]
 machine : CHRP IBM,7040-681
 
 -apw
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 
 - End forwarded message -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/3] usb: add device-tree-aware ehci driver

[Valentine Barshak]

This adds device-tree-aware ehci-ppc-of driver.
The code is based on the ehci-ppc-soc driver by
Stefan Roese [EMAIL PROTECTED].

Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
 drivers/usb/host/Kconfig   |8 +
 drivers/usb/host/ehci-hcd.c|   16 ++
 drivers/usb/host/ehci-ppc-of.c |  243 +
 drivers/usb/host/ehci.h|2 
 4 files changed, 267 insertions(+), 2 deletions(-)

diff -ruN linux-2.6.orig/drivers/usb/host/ehci.h 
linux-2.6/drivers/usb/host/ehci.h
--- linux-2.6.orig/drivers/usb/host/ehci.h  2007-09-24 14:55:44.0 
+0400
+++ linux-2.6/drivers/usb/host/ehci.h   2007-09-24 23:07:16.0 +0400
@@ -725,7 +725,7 @@
  * definition below can die once the 4xx support is
  * finally ported over.
  */
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC)  !defined(CONFIG_PPC_MERGE)
 #define readl_be(addr) in_be32((__force unsigned *)addr)
 #define writel_be(val, addr)   out_be32((__force unsigned *)addr, val)
 #endif
diff -ruN linux-2.6.orig/drivers/usb/host/ehci-hcd.c 
linux-2.6/drivers/usb/host/ehci-hcd.c
--- linux-2.6.orig/drivers/usb/host/ehci-hcd.c  2007-09-24 14:55:44.0 
+0400
+++ linux-2.6/drivers/usb/host/ehci-hcd.c   2007-09-24 23:07:16.0 
+0400
@@ -944,11 +944,16 @@
 #definePS3_SYSTEM_BUS_DRIVER   ps3_ehci_driver
 #endif
 
-#ifdef CONFIG_440EPX
+#if defined(CONFIG_440EPX)  !defined(CONFIG_PPC_MERGE)
 #include ehci-ppc-soc.c
 #definePLATFORM_DRIVER ehci_ppc_soc_driver
 #endif
 
+#ifdef CONFIG_USB_EHCI_HCD_PPC_OF
+#include ehci-ppc-of.c
+#define OF_PLATFORM_DRIVER ehci_hcd_ppc_of_driver
+#endif
+
 #if !defined(PCI_DRIVER)  !defined(PLATFORM_DRIVER)  \
 !defined(PS3_SYSTEM_BUS_DRIVER)
 #error missing bus glue for ehci-hcd
@@ -963,6 +968,12 @@
 sizeof(struct ehci_qh), sizeof(struct ehci_qtd),
 sizeof(struct ehci_itd), sizeof(struct ehci_sitd));
 
+#ifdef OF_PLATFORM_DRIVER
+   retval = of_register_platform_driver(OF_PLATFORM_DRIVER);
+   if (retval  0)
+   return retval;
+#endif
+
 #ifdef PLATFORM_DRIVER
retval = platform_driver_register(PLATFORM_DRIVER);
if (retval  0)
@@ -998,6 +1009,9 @@
 
 static void __exit ehci_hcd_cleanup(void)
 {
+#ifdef OF_PLATFORM_DRIVER
+   of_unregister_platform_driver(OF_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
 #endif
diff -ruN linux-2.6.orig/drivers/usb/host/ehci-ppc-of.c 
linux-2.6/drivers/usb/host/ehci-ppc-of.c
--- linux-2.6.orig/drivers/usb/host/ehci-ppc-of.c   1970-01-01 
03:00:00.0 +0300
+++ linux-2.6/drivers/usb/host/ehci-ppc-of.c2007-09-24 23:13:31.0 
+0400
@@ -0,0 +1,243 @@
+/*
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * Bus Glue for PPC On-Chip EHCI driver on the of_platform bus
+ * Tested on AMCC PPC 440EPx
+ *
+ * Valentine Barshak [EMAIL PROTECTED]
+ *
+ * Based on ehci-ppc-soc.c by Stefan Roese [EMAIL PROTECTED]
+ * and ohci-ppc-of.c by Sylvain Munaut [EMAIL PROTECTED]
+ *
+ * This file is licenced under the GPL.
+ */
+
+#include linux/signal.h
+
+#include linux/of.h
+#include linux/of_platform.h
+
+/* called during probe() after chip reset completes */
+static int ehci_ppc_of_setup(struct usb_hcd *hcd)
+{
+   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+   int retval;
+
+   retval = ehci_halt(ehci);
+   if (retval)
+   return retval;
+
+   retval = ehci_init(hcd);
+   if (retval)
+   return retval;
+
+   ehci-sbrn = 0x20;
+   return ehci_reset(ehci);
+}
+
+
+static const struct hc_driver ehci_ppc_of_hc_driver = {
+   .description = hcd_name,
+   .product_desc = OF EHCI,
+   .hcd_priv_size = sizeof(struct ehci_hcd),
+
+   /*
+* generic hardware linkage
+*/
+   .irq = ehci_irq,
+   .flags = HCD_MEMORY | HCD_USB2,
+
+   /*
+* basic lifecycle operations
+*/
+   .reset = ehci_ppc_of_setup,
+   .start = ehci_run,
+   .stop = ehci_stop,
+   .shutdown = ehci_shutdown,
+
+   /*
+* managing i/o requests and associated device resources
+*/
+   .urb_enqueue = ehci_urb_enqueue,
+   .urb_dequeue = ehci_urb_dequeue,
+   .endpoint_disable = ehci_endpoint_disable,
+
+   /*
+* scheduling support
+*/
+   .get_frame_number = ehci_get_frame,
+
+   /*
+* root hub support
+*/
+   .hub_status_data = ehci_hub_status_data,
+   .hub_control = ehci_hub_control,
+#ifdef CONFIG_PM
+   .hub_suspend = ehci_hub_suspend,
+   .hub_resume = ehci_hub_resume,
+#endif
+};
+
+
+/*
+ * 440EPx Errata USBH_3
+ * Fix: Enable Break Memory Transfer (BMT) in INSNREG3
+ */
+#define PPC440EPX_EHCI0_INSREG_BMT (0x1  0)
+static int __devinit
+ppc44x_enable_bmt(struct device_node *dn)
+{
+   __iomem u32 *insreg_virt;
+
+  

Re: [linux-usb-devel] [PATCH 2/3] usb: ehci-ppc-of dts bindings.

[Valentine Barshak]

Valentine Barshak wrote:
 Segher Boessenkool wrote:
 +  Required properties:
 +  - device_type : should be usb.
 No device_type please.  The published USB binding doesn't define
 one on purpose.
 Could you please, explain why?
 Sorry, I don't think I get the concept of device description here.
 device_type is meant to be used only by OF for determining the OF
 programming model for a device.  No such thing has been defined for
 USB busses, so the USB binding does not define a device_type either.

 Nothing in a flat device tree should ever define a device_type, except
 perhaps for compatibility with legacy kernel code.

 +  - compatible : should be ehci.
 Just ehci isn't enough -- compare to OHCI, which is the name for
 a kind of USB host controller as well as for a kind of Firewire
 host controller.
 Actually, I though device type=usb + compatible=ehci would be enough.
 compatible values are their own namespace, you should in principle
 be able to find a driver for a device with them without having to look
 at other properties.

 Maybe usb-ehci is best -- can anyone think of a better name?
 Again, why not type=usb, compatible=ehci?
 Because an OF client (i.e., the Linux kernel) is not supposed to use
 device_type at all for its own driver matching.

 +  - interrupts : a b where a is the interrupt number and b is a
 +field that represents an encoding of the sense and level
 +information for the interrupt.
 This is incorrect; not all interrupt domains use two cells, and
 not all that do have this meaning for those cells.
 Well, this was just copied from other descriptions in 
 Documentation/powerpc/booting-without-of.txt
 Do we need to fix them all?
 Sounds like it, yes.

 +  If device registers are implemented in big endian mode, the device
 +  node should have big-endian property.
 +  If controller implementation operates with big endian descriptors,
 +  compatible should also have ehci-be-desc
 Ah, I understand what this is about, finally.
 Don't put this in compatible; instead, do a big-endian-descriptors
 property similar to the big-endian property.  That last one should
 maybe be big-endian-registers here then, to avoid confusion.
 Or make big-endian mean both big-endian registers *and* big-endian
 descriptors.
 But doesn't big-endian property actually mean big-endian-registers?
 Do we have to overload property meaning in this case?
 It doesn't *have* a standard meaning, it is defined per device binding
 that uses it.  Just make it mean whatever is most logical for this
 device.

 I have no opinion which is best; it depends on what configurations
 actually exist, and how popular those are.

 Segher

 
 OK, thanks a lot for the explanations.
 I'll modify the code.
 I think may be usb-ohci compatible values should be made properties as well,
 so that both drivers follow the same rules.
 Thanks,
 Valentine.
 
 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 [EMAIL PROTECTED]
 To unsubscribe, use the last form field at:
 https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

I've resubmitted the patches.
(http://ozlabs.org/pipermail/linuxppc-dev/2007-September/thread.html)
Please, take a look.
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.

[Scott Wood]

The existing OF glue code was crufty and broken.  Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.

The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
existing arch/powerpc boards that I wasn't able to test on for this
patchset get converted (which should be even sooner).

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Resent, with linux/of_platform.h instead of asm/of_platform.h

 drivers/net/fs_enet/Kconfig|1 +
 drivers/net/fs_enet/fs_enet-main.c |  259 ---
 drivers/net/fs_enet/fs_enet.h  |   55 +---
 drivers/net/fs_enet/mac-fcc.c  |   89 +
 drivers/net/fs_enet/mac-fec.c  |   19 +++-
 drivers/net/fs_enet/mac-scc.c  |   53 +--
 drivers/net/fs_enet/mii-bitbang.c  |  269 +++-
 drivers/net/fs_enet/mii-fec.c  |  143 +++-
 include/linux/fs_enet_pd.h |5 +
 9 files changed, 714 insertions(+), 179 deletions(-)

diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index e27ee21..2765e49 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -11,6 +11,7 @@ config FS_ENET_HAS_SCC
 config FS_ENET_HAS_FCC
bool Chip has an FCC usable for ethernet
depends on FS_ENET  CPM2
+   select MDIO_BITBANG
default y
 
 config FS_ENET_HAS_FEC
diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index a4b76cd..c5abdea 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -44,12 +44,18 @@
 #include asm/irq.h
 #include asm/uaccess.h
 
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include linux/of_platform.h
+#endif
+
 #include fs_enet.h
 
 /*/
 
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
 static char version[] __devinitdata =
 DRV_MODULE_NAME .c:v DRV_MODULE_VERSION  ( DRV_MODULE_RELDATE ) \n;
+#endif
 
 MODULE_AUTHOR(Pantelis Antoniou [EMAIL PROTECTED]);
 MODULE_DESCRIPTION(Freescale Ethernet Driver);
@@ -953,6 +959,7 @@ static int fs_ioctl(struct net_device *dev, struct ifreq 
*rq, int cmd)
 extern int fs_mii_connect(struct net_device *dev);
 extern void fs_mii_disconnect(struct net_device *dev);
 
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
 static struct net_device *fs_init_instance(struct device *dev,
struct fs_platform_info *fpi)
 {
@@ -1132,6 +1139,7 @@ static int fs_cleanup_instance(struct net_device *ndev)
 
return 0;
 }
+#endif
 
 
/**/
 
@@ -1140,35 +1148,250 @@ void *fs_enet_immap = NULL;
 
 static int setup_immap(void)
 {
-   phys_addr_t paddr = 0;
-   unsigned long size = 0;
-
 #ifdef CONFIG_CPM1
-   paddr = IMAP_ADDR;
-   size = 0x1; /* map 64K */
-#endif
-
-#ifdef CONFIG_CPM2
-   paddr = CPM_MAP_ADDR;
-   size = 0x4; /* map 256 K */
+   fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
+   WARN_ON(!fs_enet_immap);
+#elif defined(CONFIG_CPM2)
+   fs_enet_immap = cpm2_immr;
 #endif
-   fs_enet_immap = ioremap(paddr, size);
-   if (fs_enet_immap == NULL)
-   return -EBADF;  /* XXX ahem; maybe just BUG_ON? */
 
return 0;
 }
 
 static void cleanup_immap(void)
 {
-   if (fs_enet_immap != NULL) {
-   iounmap(fs_enet_immap);
-   fs_enet_immap = NULL;
-   }
+#if defined(CONFIG_CPM1)
+   iounmap(fs_enet_immap);
+#endif
 }
 
 
/**/
 
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+static int __devinit find_phy(struct device_node *np,
+  struct fs_platform_info *fpi)
+{
+   struct device_node *phynode, *mdionode;
+   struct resource res;
+   int ret = 0, len;
+
+   const u32 *data = of_get_property(np, phy-handle, len);
+   if (!data || len != 4)
+   return -EINVAL;
+
+   phynode = of_find_node_by_phandle(*data);
+   if (!phynode)
+   return -EINVAL;
+
+   mdionode = of_get_parent(phynode);
+   if (!phynode)
+   goto out_put_phy;
+
+   ret = of_address_to_resource(mdionode, 0, res);
+   if (ret)
+   goto out_put_mdio;
+
+   data = of_get_property(phynode, reg, len);
+   if (!data || len != 4)
+   goto out_put_mdio;
+
+   snprintf(fpi-bus_id, 16, PHY_ID_FMT, res.start, *data);
+
+out_put_mdio:
+   of_node_put(mdionode);
+out_put_phy:
+   of_node_put(phynode);
+   return ret;
+}
+
+#ifdef CONFIG_FS_ENET_HAS_FEC
+#define IS_FEC(match) ((match)-data == fs_fec_ops)
+#else
+#define IS_FEC(match) 0
+#endif
+
+static int __devinit fs_enet_probe(struct of_device *ofdev,
+   const struct of_device_id *match)
+{
+   struct 

Re: Sequoia kernel crash workaround.

[Benjamin Herrenschmidt]

On Mon, 2007-09-24 at 14:35 +0400, Valentine Barshak wrote:
 
  From what I've seen, setup_cpu is never called for BOOKE.
 Currently It's called from cputable.c for PPC64 and from head_32.S for
 6xx.
 Thanks,

Right. We need to fix/converge some of these but it's not totally
trivial.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Sequoia kernel crash workaround.

[Josh Boyer]

On Tue, 25 Sep 2007 06:55:50 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Mon, 2007-09-24 at 14:35 +0400, Valentine Barshak wrote:
  
   From what I've seen, setup_cpu is never called for BOOKE.
  Currently It's called from cputable.c for PPC64 and from head_32.S for
  6xx.
  Thanks,
 
 Right. We need to fix/converge some of these but it's not totally
 trivial.

Valentine has patches for adding this for BookE on the list.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC

[Segher Boessenkool]

  Scott #size-cells is zero on i2c, so it should just be reg = 68.

  Scott You'll probably need to add #address-cells and #size-cells to 
 the
  Scott controller node, as well.

 Uh.. yes.. i2c interfaces should really always have #a and #s.

More generally, every node that defines a bus needs it (unless the
defaults of 2 resp. 1 are correct for this bus, but even then you
might want it because it makes things more explicit).

  [EMAIL PROTECTED] {
 +#address-cells = 1;
 +#size-cells = 0;
  device_type = i2c;

 Hrm... we probably want an i2c device_type class, but I don't think
 we've actually defined one, which is a problem

By defining new device_type's, or new semantics for device_type,
you open the door to (accidentally) becoming incompatible with
real OF.

And you don't need to: real OF has a mechanism for specifying
the generic device class already, if you use the generic names
recommended practice (and you do, for both this node and the rtc
node): it's the generic name itself!

 +[EMAIL PROTECTED] {
 +device_type = rtc;
 +compatible = dallas,ds1339;
 +reg = 68;
 +};

 I think we want to think a bit more carefully about how to do bindings
 for RTC devices.  No rtc device_type is defined, but again we might
 want to.

Actually, device_type = rtc _is_ defined (in the device support
extensions recommended practice), and there is no useful way a flat
device tree can implement it (it merely defines get-time and set-time
methods).

 The fact that NVRAM+RTC chips are so common is a bit of an issue from
 the point of view of defining a device class binding - a device can't
 have type rtc and nvram.

You should match OS drivers on compatible only anyway.

Those cases where OS drivers don't nicely 1-1 match device nodes are a
bit of a headache; for RTC/NVRAM devices, these problems are nicely
side-stepped by handling this from platform code.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] usb: ehci-ppc-of dts bindings.

[Segher Boessenkool]

 Nothing in a flat device tree should ever define a device_type, except
 perhaps for compatibility with legacy kernel code.

 This is not necessarily true.  As Segher says, device_type originally
 indicated the OF programming model for a device.  However, we've
 extended the notion for the flat device tree to allow device_type to
 cover device classes which could have certain common properties and
 semantics.

Such device classes are already handled by the generic names
recommended practice.

Reusing device_type for a different purpose is dangerous: before you
know it, you'll end up with a conflict, as was nicely demonstrated
today with device_type rtc.

 However, in this case, a meaningful class binding must
 already be defined: it might make sense for usb to have a defined
 device_type, but it's not been defined so far, so for now you must
 omit device_type (if a device_type is defined in future, it's easier
 to add legacy hooks that will include devices which are missing the
 relevant device_type marker than to work around devices which *do*
 have the marker, but pre-date and don't follow the defined class
 binding).

Nothing in the kernel should assume it can find all devices of a
certain class any other way than by exhaustively matching on
possible compatible values.  I'm not sure why you would want to,
anyway: you need compatible to select which driver to use, already.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

[Roland McGrath]

This restores the CHECK_FULL_REGS sanity check to every place that can
access the nonvolatile GPRs for ptrace.  This is already done for
native-bitwidth PTRACE_PEEKUSR, but was omitted for many other cases
(32-bit ptrace, PTRACE_GETREGS, etc.); I think there may have been more
uniform checks before that were lost in the recent cleanup of GETREGS et al.

Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
 arch/powerpc/kernel/ptrace.c   |4 
 arch/powerpc/kernel/ptrace32.c |8 
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8a177bd..40d34b3 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -331,6 +331,7 @@ static long arch_ptrace_old(struct task_struct *child, long 
request, long addr,
unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
unsigned long __user *tmp = (unsigned long __user *)addr;
 
+   CHECK_FULL_REGS(child-thread.regs);
for (i = 0; i  32; i++) {
ret = put_user(*reg, tmp);
if (ret)
@@ -346,6 +347,7 @@ static long arch_ptrace_old(struct task_struct *child, long 
request, long addr,
unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
unsigned long __user *tmp = (unsigned long __user *)addr;
 
+   CHECK_FULL_REGS(child-thread.regs);
for (i = 0; i  32; i++) {
ret = get_user(*reg, tmp);
if (ret)
@@ -517,6 +519,7 @@ long arch_ptrace(struct task_struct *child, long request, 
long addr, long data)
ret = -EIO;
break;
}
+   CHECK_FULL_REGS(child-thread.regs);
ret = 0;
for (ui = 0; ui  PT_REGS_COUNT; ui ++) {
ret |= __put_user(ptrace_get_reg(child, ui),
@@ -537,6 +540,7 @@ long arch_ptrace(struct task_struct *child, long request, 
long addr, long data)
ret = -EIO;
break;
}
+   CHECK_FULL_REGS(child-thread.regs);
ret = 0;
for (ui = 0; ui  PT_REGS_COUNT; ui ++) {
ret = __get_user(tmp, (unsigned long __user *) data);
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index 9e6baea..6b86960 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -53,6 +53,7 @@ static long compat_ptrace_old(struct task_struct *child, long 
request,
unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
unsigned int __user *tmp = (unsigned int __user *)addr;
 
+   CHECK_FULL_REGS(child-thread.regs);
for (i = 0; i  32; i++) {
ret = put_user(*reg, tmp);
if (ret)
@@ -68,6 +69,7 @@ static long compat_ptrace_old(struct task_struct *child, long 
request,
unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
unsigned int __user *tmp = (unsigned int __user *)addr;
 
+   CHECK_FULL_REGS(child-thread.regs);
for (i = 0; i  32; i++) {
ret = get_user(*reg, tmp);
if (ret)
@@ -164,6 +166,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr  3) || (index  PT_FPSCR32))
break;
 
+   CHECK_FULL_REGS(child-thread.regs);
if (index  PT_FPR0) {
tmp = ptrace_get_reg(child, index);
} else {
@@ -210,6 +213,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr  3) || numReg  PT_FPSCR)
break;
 
+   CHECK_FULL_REGS(child-thread.regs);
if (numReg = PT_FPR0) {
flush_fp_to_thread(child);
tmp = ((unsigned long int *)child-thread.fpr)[numReg - 
PT_FPR0];
@@ -270,6 +274,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr  3) || (index  PT_FPSCR32))
break;
 
+   CHECK_FULL_REGS(child-thread.regs);
if (index  PT_FPR0) {
ret = ptrace_put_reg(child, index, data);
} else {
@@ -307,6 +312,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
 */
if ((addr  3) || (numReg  PT_FPSCR))
break;
+   CHECK_FULL_REGS(child-thread.regs);
if (numReg  PT_FPR0) {
unsigned long freg = ptrace_get_reg(child, numReg);
if (index % 2)
@@ -342,6 +348,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,

[PATCH 2/2] powerpc: FULL_REGS on exec

[Roland McGrath]

When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, gdb --args /bin/sh -c 'exec /bin/true' and run at
the (gdb) prompt is sufficient to produce this.  I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.

This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again.  This is correct since all of
the GPRs that full refers to are cleared in start_thread.

Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
 arch/powerpc/kernel/process.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e477c9d..fd799d2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -605,6 +605,13 @@ void start_thread(struct pt_regs *regs, unsigned long 
start, unsigned long sp)
regs-ccr = 0;
regs-gpr[1] = sp;
 
+   /*
+* We have just cleared all the nonvolatile GPRs, so make
+* FULL_REGS(regs) return true.  This is necessary to allow
+* ptrace to examine the thread immediately after exec.
+*/
+   regs-trap = ~1UL;
+
 #ifdef CONFIG_PPC32
regs-mq = 0;
regs-nip = start;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

[Benjamin Herrenschmidt]

On Mon, 2007-09-24 at 16:50 -0700, Roland McGrath wrote:
 This restores the CHECK_FULL_REGS sanity check to every place that can
 access the nonvolatile GPRs for ptrace.  This is already done for
 native-bitwidth PTRACE_PEEKUSR, but was omitted for many other cases
 (32-bit ptrace, PTRACE_GETREGS, etc.); I think there may have been more
 uniform checks before that were lost in the recent cleanup of GETREGS et al.

Yup, I think I ditched most of them.. for some reason I decided it
couldn't happen, but maybe I'm wrong ?

Cheers,
Ben.

 Signed-off-by: Roland McGrath [EMAIL PROTECTED]
 ---
  arch/powerpc/kernel/ptrace.c   |4 
  arch/powerpc/kernel/ptrace32.c |8 
  2 files changed, 12 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
 index 8a177bd..40d34b3 100644
 --- a/arch/powerpc/kernel/ptrace.c
 +++ b/arch/powerpc/kernel/ptrace.c
 @@ -331,6 +331,7 @@ static long arch_ptrace_old(struct task_struct *child, 
 long request, long addr,
   unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
   unsigned long __user *tmp = (unsigned long __user *)addr;
  
 + CHECK_FULL_REGS(child-thread.regs);
   for (i = 0; i  32; i++) {
   ret = put_user(*reg, tmp);
   if (ret)
 @@ -346,6 +347,7 @@ static long arch_ptrace_old(struct task_struct *child, 
 long request, long addr,
   unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
   unsigned long __user *tmp = (unsigned long __user *)addr;
  
 + CHECK_FULL_REGS(child-thread.regs);
   for (i = 0; i  32; i++) {
   ret = get_user(*reg, tmp);
   if (ret)
 @@ -517,6 +519,7 @@ long arch_ptrace(struct task_struct *child, long request, 
 long addr, long data)
   ret = -EIO;
   break;
   }
 + CHECK_FULL_REGS(child-thread.regs);
   ret = 0;
   for (ui = 0; ui  PT_REGS_COUNT; ui ++) {
   ret |= __put_user(ptrace_get_reg(child, ui),
 @@ -537,6 +540,7 @@ long arch_ptrace(struct task_struct *child, long request, 
 long addr, long data)
   ret = -EIO;
   break;
   }
 + CHECK_FULL_REGS(child-thread.regs);
   ret = 0;
   for (ui = 0; ui  PT_REGS_COUNT; ui ++) {
   ret = __get_user(tmp, (unsigned long __user *) data);
 diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
 index 9e6baea..6b86960 100644
 --- a/arch/powerpc/kernel/ptrace32.c
 +++ b/arch/powerpc/kernel/ptrace32.c
 @@ -53,6 +53,7 @@ static long compat_ptrace_old(struct task_struct *child, 
 long request,
   unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
   unsigned int __user *tmp = (unsigned int __user *)addr;
  
 + CHECK_FULL_REGS(child-thread.regs);
   for (i = 0; i  32; i++) {
   ret = put_user(*reg, tmp);
   if (ret)
 @@ -68,6 +69,7 @@ static long compat_ptrace_old(struct task_struct *child, 
 long request,
   unsigned long *reg = ((unsigned long *)child-thread.regs)[0];
   unsigned int __user *tmp = (unsigned int __user *)addr;
  
 + CHECK_FULL_REGS(child-thread.regs);
   for (i = 0; i  32; i++) {
   ret = get_user(*reg, tmp);
   if (ret)
 @@ -164,6 +166,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
 long addr,
   if ((addr  3) || (index  PT_FPSCR32))
   break;
  
 + CHECK_FULL_REGS(child-thread.regs);
   if (index  PT_FPR0) {
   tmp = ptrace_get_reg(child, index);
   } else {
 @@ -210,6 +213,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
 long addr,
   if ((addr  3) || numReg  PT_FPSCR)
   break;
  
 + CHECK_FULL_REGS(child-thread.regs);
   if (numReg = PT_FPR0) {
   flush_fp_to_thread(child);
   tmp = ((unsigned long int *)child-thread.fpr)[numReg - 
 PT_FPR0];
 @@ -270,6 +274,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
 long addr,
   if ((addr  3) || (index  PT_FPSCR32))
   break;
  
 + CHECK_FULL_REGS(child-thread.regs);
   if (index  PT_FPR0) {
   ret = ptrace_put_reg(child, index, data);
   } else {
 @@ -307,6 +312,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
 long addr,
*/
   if ((addr  3) || (numReg  PT_FPSCR))
   break;
 + CHECK_FULL_REGS(child-thread.regs);
   if (numReg  PT_FPR0) {
   unsigned long freg = 

Re: [PATCH 2/2] powerpc: FULL_REGS on exec

[Benjamin Herrenschmidt]

On Mon, 2007-09-24 at 16:52 -0700, Roland McGrath wrote:
 When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
 the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
 With recent versions, gdb --args /bin/sh -c 'exec /bin/true' and run at
 the (gdb) prompt is sufficient to produce this.  I also have written an
 isolated test case, see 
 https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
 
 This change fixes the problem by clearing the low bit of pt_regs.trap in
 start_thread so that FULL_REGS is true again.  This is correct since all of
 the GPRs that full refers to are cleared in start_thread.

Looks good, nice catch.

 Signed-off-by: Roland McGrath [EMAIL PROTECTED]

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

 ---
  arch/powerpc/kernel/process.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
 index e477c9d..fd799d2 100644
 --- a/arch/powerpc/kernel/process.c
 +++ b/arch/powerpc/kernel/process.c
 @@ -605,6 +605,13 @@ void start_thread(struct pt_regs *regs, unsigned long 
 start, unsigned long sp)
   regs-ccr = 0;
   regs-gpr[1] = sp;
  
 + /*
 +  * We have just cleared all the nonvolatile GPRs, so make
 +  * FULL_REGS(regs) return true.  This is necessary to allow
 +  * ptrace to examine the thread immediately after exec.
 +  */
 + regs-trap = ~1UL;
 +
  #ifdef CONFIG_PPC32
   regs-mq = 0;
   regs-nip = start;
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

[Roland McGrath]

 Yup, I think I ditched most of them.. for some reason I decided it
 couldn't happen, but maybe I'm wrong ?

Well, it's a BUG_ON.  It's supposed to be for something that can't happen.
That's why it's a sanity check, not a wild assertion. ;-)

The 2/2 patch is an example of a bug that CHECK_FULL_REGS catches.
In the status quo, using PTRACE_PEEKUSR in a bug case crashes while using
PTRACE_GETREGS in the same place might get bogus data.  (In the actual bug
thus found, the data is not bogus and only the bit that FULL_REGS checks is.)


Thanks,
Roland
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Make instruction dumping work in real mode.

[Olof Johansson]

On Mon, Sep 24, 2007 at 02:01:00PM -0500, Scott Wood wrote:
 On non-book-E, if a faulting PC is in the first few pages, and it's not an
 ITLB miss, it's likely executing in real mode, probably at an exception 
 vector.
 
 Rather than print a useless , it is assumed that this is the case, and
 the address is treated as physical.  This helps when debugging corruption at
 the beginning of memory.

Please use regs-msr  MSR_IR instead.


-Olof

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 15/40] bootwrapper: Factor out dt_set_mac_address().

[David Gibson]

On Mon, Sep 24, 2007 at 03:09:11PM -0500, Scott Wood wrote:
 This allows callers to set addresses one at a time when that would be more
 convenient.
 
 Signed-off-by: Scott Wood [EMAIL PROTECTED]

Sorry I've been such a pain about this previously.

Acked-by: David Gibson [EMAIL PROTECTED]

-- 
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
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] bootwrapper: Add PlanetCore firmware support.

[David Gibson]

On Mon, Sep 24, 2007 at 03:09:49PM -0500, Scott Wood wrote:
 This is a library that board code can use to extract information from the
 PlanetCore configuration keys.  PlanetCore is used on various boards from
 Embedded Planet.
 
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
Acked-by: David Gibson [EMAIL PROTECTED]

-- 
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
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems compiling Linux for MPC8272ADS

[Alan Bennett]

I added this to my boot/Makefile near the other mcpu=440 lines.  I
believe there may be a fix coming?

$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=440
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440


On 9/24/07, Manil Gaouar [EMAIL PROTECTED] wrote:
 Hi there,

 I am trying to compile the latest Linux from the git repos: git clone
 git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
 the code a few weeks ago and was able to build my uImage no problems. I
 did a git pull this morning and I can not compile anymore, here is the
 error message I have:

   BOOTCC  arch/powerpc/boot/ps3.o
   BOOTCC  arch/powerpc/boot/treeboot-bamboo.o
   BOOTCC  arch/powerpc/boot/cuboot-sequoia.o
   BOOTCC  arch/powerpc/boot/treeboot-walnut.o
 {standard input}: Assembler messages:
 {standard input}:184: Error: Unrecognized opcode: `mfdcr'
 {standard input}:185: Error: Unrecognized opcode: `mfdcr'
 {standard input}:186: Error: Unrecognized opcode: `mfdcr'
 {standard input}:217: Error: Unrecognized opcode: `mtdcr'
 make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
 make: *** [uImage] Error 2

 here are the commands I am using:

 make mrproper
 make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
 make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage

 Do you have any ideas, or I should check out the 2.6.22 stable release
 instead and try again???

 Thx
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: AMCC yosemite 440ep PCI slot doesn't work.

[Andrew Liu]

I have tested it on linux-2.6.19 which is from AMCC website ,  linux 
2.6.21.7 which is from linux mainline and  linux-2.6.23.rc7 which is
from git://www.denx.de/git/linux-2.6-denx.git
Have the same problem.
 I don't understand, why after enabling this PCI interrupts.  in so
short time, produce 100,000 interrupt request (25: 10  UIC0
Level eth2).


BRs,
Andrew.

Stefan Roese wrote:
 On Monday 24 September 2007, Andrew Liu wrote:
   
 By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
 

 And that should be correct for PCI interrupts.

   
  I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE  or
 IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
 It  displays:
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
 eth2: no IPv6 routers present
 NETDEV WATCHDOG: eth2: transmit timed out
 eth2: Transmit timeout, status 0c 0005 c07f media 10.
 eth2: Tx queue start entry 4  dirty entry 0.
 eth2:  Tx descriptor 0 is 0008a05a. (queue head)
 eth2:  Tx descriptor 1 is 0008a04e.
 eth2:  Tx descriptor 2 is 0008a046.
 eth2:  Tx descriptor 3 is 0008a05a.
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1

 and
 [EMAIL PROTECTED]:/root ifconfig  eth2
 eth2  Link encap:Ethernet  HWaddr 00:0E:2E:7E:F5:E6
   inet addr:128.224.149.13  Bcast:128.224.255.255  Mask:255.255.0.0
   inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
   Interrupt:25 Base address:0x6f00


 and
 [EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0
   2:  0  UIC0 Edge  IBM IIC
   7:  0  UIC0 Edge  IBM IIC
  10:  11961  UIC0 Edge  MAL TX EOB
  11:  18471  UIC0 Edge  MAL RX EOB
  25:  0  UIC0 Edge  eth2
  32:  0  UIC1 Edge  MAL SERR
  33:  0  UIC1 Edge  MAL TX DE
  34:  0  UIC1 Edge  MAL RX DE
  40: 32  UIC1 Edge  ohci_hcd:usb1
  60:  0  UIC1 Edge  EMAC
 BAD:  0


 Can PCI slot use level trigger?

 give me some advice.
 

 Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even 
 earlier? Please give it a try and let us know if the same problem occurs.

 Best regards,
 Stefan

 =
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
 =

   
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: AMCC yosemite 440ep PCI slot doesn't work.

[Andrew Liu]

Currently, ppc44x use ppc branch, not powerpc, especially for AMCC
yosemite 440ep.

Through adding printk in function ppc4xx_pic_init which is in
arch/ppc/syslib/ppc4xx_pic.c, whether setting  IRQ_LEVEL has no effect
on it.



BRs,
Andrew


Valentine Barshak wrote:
 Stefan Roese wrote:
 On Monday 24 September 2007, Andrew Liu wrote:
 By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE

 And that should be correct for PCI interrupts.

  I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE  or
 IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
 It  displays:
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
 eth2: no IPv6 routers present
 NETDEV WATCHDOG: eth2: transmit timed out
 eth2: Transmit timeout, status 0c 0005 c07f media 10.
 eth2: Tx queue start entry 4  dirty entry 0.
 eth2:  Tx descriptor 0 is 0008a05a. (queue head)
 eth2:  Tx descriptor 1 is 0008a04e.
 eth2:  Tx descriptor 2 is 0008a046.
 eth2:  Tx descriptor 3 is 0008a05a.
 eth2: link up, 100Mbps, full-duplex, lpa 0x45E1

 and
 [EMAIL PROTECTED]:/root ifconfig  eth2
 eth2  Link encap:Ethernet  HWaddr 00:0E:2E:7E:F5:E6
   inet addr:128.224.149.13  Bcast:128.224.255.255 
 Mask:255.255.0.0
   inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
   Interrupt:25 Base address:0x6f00


 and
 [EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0
   2:  0  UIC0 Edge  IBM IIC
   7:  0  UIC0 Edge  IBM IIC
  10:  11961  UIC0 Edge  MAL TX EOB
  11:  18471  UIC0 Edge  MAL RX EOB
  25:  0  UIC0 Edge  eth2
  32:  0  UIC1 Edge  MAL SERR
  33:  0  UIC1 Edge  MAL TX DE
  34:  0  UIC1 Edge  MAL RX DE
  40: 32  UIC1 Edge  ohci_hcd:usb1
  60:  0  UIC1 Edge  EMAC
 BAD:  0


 Can PCI slot use level trigger?

 give me some advice.

 This could be caused by misseting the IRQ_lEVEL flag in desc-status.
 There have been a commit 4dc7b4b0405fd7320940849b6e31ea8ea68fd0df that
 fixes the problem.
 Thanks,
 Valentine.


 Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or
 even earlier? Please give it a try and let us know if the same
 problem occurs.

 Best regards,
 Stefan

 =
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
 =


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems compiling Linux for MPC8272ADS

[David Gibson]

On Mon, Sep 24, 2007 at 10:46:41AM -0600, Alan Bennett wrote:
 I added this to my boot/Makefile near the other mcpu=440 lines.  I
 believe there may be a fix coming?

I believe there is.

 $(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=440

It should be -mcpu=405 for Walnut, though.

 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440

-- 
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
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[David Gibson]

On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
 Currently zImage is linked at the 4MB base address.
 Some platforms (using cuboot, treeboot) need the zImage's
 entry point and base address. They place zImage exactly
 at the base address it's been linked to. Sometimes 4MB left
 at the start of the memory is simply not enough to unpack zImage.
 This could happen with initramfs enabled, since the kernel image
 packed along with initramfs.cpio could be over 5MB in size.
 This patch checks vmlinux image size and links zImage at
 the base address that is equal to the unpacked image size
 aligned to 4MB boundary. This way zImage base address is 4MB
 only if unpacked kernel image size is less then 4MB.

Good plan.  However..

[snip]
 diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 
 linux-2.6/arch/powerpc/boot/zImage.lds.S
 --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 
 00:48:08.0 +0400
 +++ linux-2.6/arch/powerpc/boot/zImage.lds.S  2007-09-22 04:03:58.0 
 +0400
 @@ -3,7 +3,7 @@
  EXTERN(_zimage_start)
  SECTIONS
  {
 -  . = (4*1024*1024);
 +  . = ALIGN((_kend - _kstart), (4*1024*1024));

..I don't see any reason to keep the 4MB granularity.  I would just
align the address to say a 64k boundary (64k because that's the
granularity used in the normal ABI).

_start = .;
.text  :
{
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 

-- 
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
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/15] boot: find initrd location from device-tree

[David Gibson]

On Mon, Sep 24, 2007 at 03:02:36AM -0500, Milton Miller wrote:
 
 On Sep 23, 2007, at 9:58 PM, David Gibson wrote:
 
  On Fri, Sep 21, 2007 at 06:03:24PM -0500, Milton Miller wrote:
  Some platforms have a boot agent that can create or modify properties 
  in
  the device-tree and load images into memory.  Provide a helper to set
  loader_info used by prep_initrd().
 
  Signed-off-by: Milton Miller [EMAIL PROTECTED]
  Acked-by: David Gibson [EMAIL PROTECTED]
 
  Hrm, despite my earlier ack, I'm going to whinge about a few nits
  here.
 
  ---
  re 12168
  rediffed types.h, offset in ops.h
 
  Index: kernel/arch/powerpc/boot/ops.h
  ===
  --- kernel.orig/arch/powerpc/boot/ops.h2007-09-17 22:12:47.0 
  -0500
  +++ kernel/arch/powerpc/boot/ops.h 2007-09-17 22:12:51.0 -0500
  @@ -163,6 +163,7 @@ void dt_fixup_clock(const char *path, u3
   void __dt_fixup_mac_addresses(u32 startindex, ...);
   #define dt_fixup_mac_addresses(...) \
 __dt_fixup_mac_addresses(0, __VA_ARGS__, NULL)
  +void dt_find_initrd(void);
 
 
   static inline void *find_node_by_linuxphandle(const u32 linuxphandle)
  Index: kernel/arch/powerpc/boot/types.h
  ===
  --- kernel.orig/arch/powerpc/boot/types.h  2007-09-17 
  22:12:47.0 -0500
  +++ kernel/arch/powerpc/boot/types.h   2007-09-17 22:12:51.0 
  -0500
  @@ -12,6 +12,8 @@ typedef shorts16;
   typedef int   s32;
   typedef long long s64;
 
  +#define UINT_MAX  0x
 
  I actually don't like this constant - at the point you compare you
  care, explicitly, about the value not being over 32-bits, rather than
  whether it fits a uint, so the named constant is more misleading than
  helpful.
 
 Arguable, I don't like counting F's or zeros in C code.

So check if (addr  32) is non-zero.

 It is used as the max address that the wrapper deals with, both here 
 and memranges, which happens to be 32 bits.

Right and the reasons for that being the value it is are not because
it also hapeens to be the max uint *or* ulong.

 Actually it cares about overflowing the unsigned long in loader_info, 
 not that the address fits in 32 bits.
 
 So it should be ULONG_MAX now (malloc and all the address code was 
 changed to use unsigned long instead of unsigned int since the patch 
 was written).
 
 And dt_xlate needs the same information.  Its is using a hardcoded 64 
 bit constant to provide the a simiar check.
 
 
  +
   #define min(x,y) ({ \
 typeof(x) _x = (x); \
 typeof(y) _y = (y); \
  Index: kernel/arch/powerpc/boot/devtree.c
  ===
  --- kernel.orig/arch/powerpc/boot/devtree.c2007-09-17 
  22:12:47.0 -0500
  +++ kernel/arch/powerpc/boot/devtree.c 2007-09-17 22:12:51.0 
  -0500
  @@ -1,6 +1,7 @@
   /*
* devtree.c - convenience functions for device tree manipulation
* Copyright 2007 David Gibson, IBM Corporation.
  + * Copyright 2007 Milton Miller, IBM Corporation.
* Copyright (c) 2007 Freescale Semiconductor, Inc.
*
* Authors: David Gibson [EMAIL PROTECTED]
  @@ -333,3 +334,68 @@ int dt_is_compatible(void *node, const c
 
 return 0;
   }
  +
  +/**
  + * dt_find_initrd - set loader initrd location based on existing 
  properties
  + *
  + * finds the linux,initrd-start and linux,initrd-end properties in
  + * the /chosen node and sets the loader initrd fields accordingly.
  + *
  + * Use this if your loader sets the properties to allow other code to
  + * relocate the tree and/or cause r3 and r4 to be set on true OF
  + * platforms.
 
  I am unable to make sense of the paragraph above.
 
 The phrase relocate the tree should be relocate the initrd, which 
 the wrapper will do if it located below vmlinux.size.  Also, r3 and r4 
 need to be set when booting the kernel from a client interface with an 
 initrd so it can take it into consideration when choosing the location 
 to build the flat tree.
 
 How about:
 
 Filling in the loader info allows main.c to be aware of the initrd, 
 meaning prep_initrd will move the initrd if it will be overwritten when 
 the kernel is copied to its runtime location.  In addition, if you are 
 booting the kernel from a client interface instead of a flat device 
 tree, this also causes r3 and r4 to be set so the kernel can avoid 
 overwriting the initrd when creating the flat tree.

Clearer, but I still don't see that it says anything useful - finds
the initrd from the devtree and does all the things that are supposed
to be done with an initrd - which is implied in the previous
paragraph.

 
 
  + */
  +void dt_find_initrd(void)
  +{
  +  int rc;
  +  unsigned long long initrd_start, initrd_end;
  +  void *devp;
  +  static const char start_prop[] = linux,initrd-start;
  +  static const char end_prop[] = linux,initrd-end;
 
 

Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16

[David Gibson]

On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
 
 On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
 
  On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
[snip]
  +#define MIN_VERSION 2
  +#define OUT_VERSION 16
 
  Should output version 17.  In any case, don't try to be so general -
  just convert v123 (all basically the same) to latest (i.e. v17)
  without all the #if nonsense.
 
 Outputing v17 instead of 16 requires more words to be added to the 
 header, and the library does fine with v16.

For now.  libfdt will want v17.  Although it will (eventually) have
it's own v16-v17 conversion code.

  Actually the v1 trees has 
 some other differences such as initrd addresses were kernel linear not 
 real, cpus were assigned logical numbers  ... so while the structure 
 didn't change except for the header field, the contents did.

!? what's your source for this.  v2 and v3 were absolutely supposed to
be backwards compatible with v1 which would not be the case with
silent semantic changes such as this.

  Actually, 
 when converting v3 to v16 some of the code issn't needed, the ifs allow 
 the code size to be reduced.

Yes, but it never will be, because the only reason we'd include this
file is for converting old kexec-tools device trees which are v2 not
v3.

  +#define OUT_COMPAT 16
  +
  +#ifdef NO_CHECK
  +static int check_v123_tree(u32 *start, u32 *limit)
  +{
  +  return 0;
  +}
  +#else
  +/**
  + * check_v123_tree - check integrety of a version 1, 2, or 3 tree
  + * @start: the start of the device tree struct
  + * @limit: the end of the region for the struct
  + * structural checks on device_tree
  + */
  +static int check_v123_tree(u32 *start, u32 *limit)
 
  What is the point of this check?  If the device tree is corrupt, we're
  stuffed anyway, so why bother?
 
 Hence the ifdef NO_CHECK.   When developing, sometimes its nice to know 
 if its your input or your program.  These functions are destructive to 
 an improperlly formed tree, and in non-obvious ways.  When debugging, 
 it's not hard to hardcode console write or read the printf string 
 buffer with a hardware debugger to see error messages.  That said, it 
 could be removed.

Right.  Debugging code shouldn't pollute final patches.

[snip]
  +#if MIN_VERSION  3 || OUT_VERSION  16
  +/**
  + * move_nops_fwd - move nops in a v16 dt_struct to the beginning
  + * @start - device tree starting address
  + * @count - number of %OF_DT_NOP cells to move
  + */
  +static void move_nops_fwd(u32 *start, int count)
 
  What on earth is the point of this.  The NOPs are perfectly valid
  scattered within the tree, why go to all this trouble to shuffle them
  about.
 
 And if you notice, there is a how many to move argument.  The point 
 of moving them to the front of the tree is the v17 device tree header 
 takes more space than the v3 one, and the v2 header is smaller than 
 both v17 and v16 header.  Since I am converting the tree in place, the 
 space has to come from somewhere.  Since we are pretty much guaranteed 
 to get several nops, this function moves them forward so they can be 
 overwritten.  In practice we move 1-3 NOPS from the early properties  
 8 bytes and early grandchild nodes (eg /cpus/PowerPC,xxx).

This is a hell of a lot of bother to go to for a few bytes.
Allocating a big-enough buffer for any reasonable devtree in BSS and
memmove()ing into there would be far simpler.

Remember this is a hack for horrid old device trees produced by
kexec-tools.  It simply doesn't justify large amounts of code to work
around.

[snip]
  +  if (tree-last_comp_version  3)
  +  return; /* don't know what to do */
 
  Rather, don't need to do anything.
 
 If the tree is = 16 then we don't presently need to do anything.   If 
 there is a theoritical v4 tree we don't know what to do.  And if output 
 version is 17 but input is 16 we don't know what to do either, because 
 there likely aren't nops in the tree to consume.  I suppose we could 
 preceed it with a check for version == OUTPUT_VERSION, but then I'm 
 sure I'd get pointless differentation :-).

There will never be a v4.  Or anything between v3 and v16.

Again this is far too general.  It's a hack to deal with kexec-tools
old trees.  Therefore it doesn't need to deal with any general old
tree, just the minimum to deal with trees as produced by old
kexec-tools.

[snip]
  +  /*
  +   * move mem_rsvmap and dt_strings if they are before dt_struct
  +   * onto our nops .  Adjust start addresses for the 3 sections.
  +   */
 
  Hrm.  Do we really need to worry about this case.  You may be
  producing v2 trees in kexec-tools, but do they actually have the
  blocks out of order?  dtc certainly never produced them that way.
 
 Out of order?  There has never been a spec as to the order of the 
 blocks, only the implicit assumption that they follow the device tree 
 header in a reasonably packed sequence.  booting-without-of says it 
 must be in ram,; the 

Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

[Benjamin Herrenschmidt]

On Mon, 2007-09-24 at 17:59 -0700, Roland McGrath wrote:
  Yup, I think I ditched most of them.. for some reason I decided it
  couldn't happen, but maybe I'm wrong ?
 
 Well, it's a BUG_ON.  It's supposed to be for something that can't happen.
 That's why it's a sanity check, not a wild assertion. ;-)
 
 The 2/2 patch is an example of a bug that CHECK_FULL_REGS catches.
 In the status quo, using PTRACE_PEEKUSR in a bug case crashes while using
 PTRACE_GETREGS in the same place might get bogus data.  (In the actual bug
 thus found, the data is not bogus and only the bit that FULL_REGS checks is.)

Fair enough.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] add Altivec/VMX state to coredumps

[Mark Nelson]

Update dump_task_altivec() (that has so far never been put to use)
so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
and VRSAVE) in the same format as the ptrace get_vrregs() and add
the appropriate glue typedefs and #defines to
include/asm-powerpc/elf.h for it to work.

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 arch/powerpc/kernel/process.c |   28 +---
 include/asm-powerpc/elf.h |7 +++
 2 files changed, 32 insertions(+), 3 deletions(-)

Index: linux/arch/powerpc/kernel/process.c
===
--- linux.orig/arch/powerpc/kernel/process.c
+++ linux/arch/powerpc/kernel/process.c
@@ -149,10 +149,32 @@ void flush_altivec_to_thread(struct task
}
 }
 
-int dump_task_altivec(struct pt_regs *regs, elf_vrregset_t *vrregs)
+int dump_task_altivec(struct task_struct *tsk, elf_vrregset_t *vrregs)
 {
-   flush_altivec_to_thread(current);
-   memcpy(vrregs, current-thread.vr[0], sizeof(*vrregs));
+   /* ELF_NVRREG includes the VSCR and VRSAVE which we need to save
+* separately, see below */
+   const int nregs = ELF_NVRREG - 2;
+   elf_vrreg_t *reg;
+   u32 *dest;
+
+   if (tsk == current)
+   flush_altivec_to_thread(tsk);
+
+   reg = (elf_vrreg_t *)vrregs;
+
+   /* copy the 32 vr registers */
+   memcpy(reg, tsk-thread.vr[0], nregs * sizeof(*reg));
+   reg += nregs;
+
+   /* copy the vscr */
+   memcpy(reg, tsk-thread.vscr, sizeof(*reg));
+   reg++;
+
+   /* vrsave is stored in the high 32bit slot of the final 128bits */
+   memset(reg, 0, sizeof(*reg));
+   dest = (u32 *)reg;
+   *dest = tsk-thread.vrsave;
+
return 1;
 }
 #endif /* CONFIG_ALTIVEC */
Index: linux/include/asm-powerpc/elf.h
===
--- linux.orig/include/asm-powerpc/elf.h
+++ linux/include/asm-powerpc/elf.h
@@ -212,6 +212,13 @@ static inline int dump_task_regs(struct 
 extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *); 
 #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
 
+typedef elf_vrregset_t elf_fpxregset_t;
+
+#ifdef CONFIG_ALTIVEC
+extern int dump_task_altivec(struct task_struct *, elf_vrregset_t *vrregs);
+#define ELF_CORE_COPY_XFPREGS(tsk, regs) dump_task_altivec(tsk, regs)
+#endif
+
 #endif /* __KERNEL__ */
 
 /* ELF_HWCAP yields a mask that user programs can use to figure out what
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc: fix CONFIG_SWAP=n builds for 64-bit

[Jeremy Kerr]

Currently, 64-bit won't build with CONFIG_SWAP=n, as asm-generic/tlb.h
needs page_cache_release() and release_pages(), which are defined in
linux/pagemap.h.

We can't include linux/pagemap.h in asm-generic/tlb.h, as (apparently)
this breaks sparc. So, include it in the necessary places in the
powerpc mm code.

Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]

---
 arch/powerpc/mm/hash_native_64.c |1 +
 arch/powerpc/mm/hash_utils_64.c  |1 +
 arch/powerpc/mm/init_64.c|1 +
 arch/powerpc/mm/pgtable_64.c |1 +
 arch/powerpc/mm/tlb_64.c |1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 6ba9b47..dd1e9fb 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -16,6 +16,7 @@
 #include linux/bitops.h
 #include linux/threads.h
 #include linux/smp.h
+#include linux/pagemap.h
 
 #include asm/abs_addr.h
 #include asm/machdep.h
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index d525f2e..1ff0117 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -31,6 +31,7 @@
 #include linux/cache.h
 #include linux/init.h
 #include linux/signal.h
+#include linux/pagemap.h
 
 #include asm/processor.h
 #include asm/pgtable.h
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 9f27bb5..a1e8364 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -40,6 +40,7 @@
 #include linux/nodemask.h
 #include linux/module.h
 #include linux/poison.h
+#include linux/pagemap.h
 
 #include asm/pgalloc.h
 #include asm/page.h
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 60fd52c..4265eed 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -33,6 +33,7 @@
 #include linux/stddef.h
 #include linux/vmalloc.h
 #include linux/init.h
+#include linux/pagemap.h
 
 #include asm/pgalloc.h
 #include asm/page.h
diff --git a/arch/powerpc/mm/tlb_64.c b/arch/powerpc/mm/tlb_64.c
index cbd34fc..b51ca5b 100644
--- a/arch/powerpc/mm/tlb_64.c
+++ b/arch/powerpc/mm/tlb_64.c
@@ -26,6 +26,7 @@
 #include linux/init.h
 #include linux/percpu.h
 #include linux/hardirq.h
+#include linux/pagemap.h
 #include asm/pgalloc.h
 #include asm/tlbflush.h
 #include asm/tlb.h
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: AMCC yosemite 440ep PCI slot doesn't work.

[Stefan Roese]

On Tuesday 25 September 2007, Andrew Liu wrote:
 I have tested it on linux-2.6.19 which is from AMCC website ,  linux
 2.6.21.7 which is from linux mainline and  linux-2.6.23.rc7 which is
 from git://www.denx.de/git/linux-2.6-denx.git
 Have the same problem.
  I don't understand, why after enabling this PCI interrupts.  in so
 short time, produce 100,000 interrupt request (25: 10  UIC0
 Level eth2).

Because the interrupt is somehow not acknowledged in the PCI device.

I will test this on my Yosemite and let you know.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC

[Peter Korsgaard]

 David == David Gibson [EMAIL PROTECTED] writes:

Hi,

  The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM
  bytes either.

 David Incidentally how are you planning on instantiating the driver?  AFAIK
 David all the rtc-* drivers are platform drivers rather than of_platform
 David drivers.  I had been thinking of an rtc helper function that would go
 David through the tree instantiating platform devices for any RTCs based on
 David a compatible - platform device name table.

Please see patch #2 in the series:

http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html

That helper function more or less already exists in fsl_soc.c.

-- 
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC

[David Gibson]

On Tue, Sep 25, 2007 at 07:33:15AM +0200, Peter Korsgaard wrote:
  David == David Gibson [EMAIL PROTECTED] writes:
 
 Hi,
 
   The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM
   bytes either.
 
  David Incidentally how are you planning on instantiating the driver?  AFAIK
  David all the rtc-* drivers are platform drivers rather than of_platform
  David drivers.  I had been thinking of an rtc helper function that would go
  David through the tree instantiating platform devices for any RTCs based on
  David a compatible - platform device name table.
 
 Please see patch #2 in the series:
 
 http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html
 
 That helper function more or less already exists in fsl_soc.c.

Ah, I see.  Well... it exists for i2c devices (possibly including
RTCs).  Whereas I was thinking of a version for RTCs (possibly
including i2c devices).  Actually that won't quite work - looks like
the i2c RTC class drivers are probed differently from the RTC drivers
I was looking at which are pure platform devices.

-- 
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
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

jffs2 file system on MPC8272ADS board

[Nethra]

hi everyone,

I m using custom board similar to MPC8272ADS board...

1) For the first time it boots up properly in case if we overwrite any
existing binaries using nfs mounted file system on the board, after
rebooting it displays fallowing message...

Further such events for this erase block will not be printed
Eep. Child null (ino #1346) of dir ino #3 doesn't exist!
Eep. Child autocomm (ino #463) of dir ino #461 doesn't exist!
Eep. Child calibration (ino #464) of dir ino #461 doesn't exist!
Eep. Child coredsp_driver.ko (ino #939) of dir ino #336 doesn't exist!
Inode #1307 was a directory with children - removing those too...
Inode #564 was a directory with children - removing those too...
Inode #565 was a directory with children - removing those too...
Inode #1112 was a directory with children - removing those too...
Inode #1115 was a directory with children - removing those too...
Inode #1118 was a directory with children - removing those too...
Inode #1123 was a directory with children - removing those too...

after this board boots up properlybut it not be having overwritten files

2) while booting up for the first time itself it will display the falowing
message..

modprobe: FATAL: Could not load
/lib/modules/2.6.10_mvl401-8272ads/modules.dep: No such file or dire
ctory

but after this also board boots up properly

3) when board is running properly in between it starts printing on console
repeatedly...

Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x0254)
Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x0234)
Header CRC failed on REF_PRISTINE node at 0x00638ef4: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02c4)
Header CRC failed on REF_PRISTINE node at 0x006391b8: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b4)
Node totlen on flash (0x) != totlen from node ref (0x02c0)
Header CRC failed on REF_PRISTINE node at 0x0063972c: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02bc)
Header CRC failed on REF_PRISTINE node at 0x006399e8: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02ac)
Header CRC failed on REF_PRISTINE node at 0x00639c94: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b0)
Header CRC failed on REF_PRISTINE node at 0x00639f44: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02ac)
Header CRC failed on REF_PRISTINE node at 0x0063a1f0: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02c0)
Header CRC failed on REF_PRISTINE node at 0x0063a4b0: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b0)
Header CRC failed on REF_PRISTINE node at 0x0063a760: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b0)
Header CRC failed on REF_PRISTINE node at 0x0063aa10: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02c8)
Header CRC failed on REF_PRISTINE node at 0x0063acd8: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b0)
Header CRC failed on REF_PRISTINE node at 0x0063af88: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02c4)
Header CRC failed on REF_PRISTINE node at 0x0063b24c: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02b4)
Header CRC failed on REF_PRISTINE node at 0x0063b500: Read 0x,
calculated 0x44660075
Node totlen on flash (0x) != totlen from node ref (0x02c8)
Header CRC failed on REF_PRISTINE node at 0x0063b7c8: Read 0x,
calculated 0x44660075

are they debug messages or warnings...?

do they create more problem or can i neglet these errors..

plz reply..it is too urgent 


here is my kerenl configurations
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
#