* Please pull from 'for-2.6.25' [updated]
From: Kumar Gala @ 2008-03-10 18:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8379_mds.dts | 70 ++
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/wrapper | 6
arch/powerpc/configs/adder875-redboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875-uboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875_defconfig | 813 ++++++++++++++++++++++++
arch/powerpc/kernel/head_8xx.S | 30
arch/powerpc/platforms/83xx/mpc837x_mds.c | 8
arch/powerpc/platforms/Kconfig | 1
arch/powerpc/platforms/Kconfig.cputype | 7
arch/powerpc/sysdev/qe_lib/qe.c | 7
arch/ppc/kernel/head_8xx.S | 30
include/asm-powerpc/pgtable-ppc32.h | 8
include/asm-ppc/pgtable.h | 8
16 files changed, 1105 insertions(+), 1635 deletions(-)
Andy Fleming (1):
[POWERPC] 83xx: Make 83xx perfmon support selectable
Ionut Nicu (1):
[POWERPC] QE: Make qe_get_firmware_info reentrant
Jeremy McNicoll (1):
[POWERPC] 85xx: sbc8548 - Fix incorrect PCI-X and PCI interrupt map
Li Yang (2):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
[POWERPC] 83xx: Add local bus device nodes to MPC837xMDS device trees.
Scott Wood (1):
[POWERPC] 8xx: Fix wrapper platform for adder875, and combine defconfigs.
Timur Tabi (1):
[POWERPC] QE: Fix QE firmware uploading limit
Vitaly Bordug (1):
[POWERPC] 8xx: fix swap
Yuri Tikhonov (1):
[PPC] 8xx: swap bug-fix
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Darrick J. Wong @ 2008-03-10 18:13 UTC (permalink / raw)
To: Roel Kluin; +Cc: Colin Leroy, lkml, linuxppc-dev
In-Reply-To: <47D5068F.8050709@tiscali.nl>
On Mon, Mar 10, 2008 at 10:59:43AM +0100, Roel Kluin wrote:
> > The & 0xff here is bogus anyway; temp is only ever used as an u8,
> > so just declare it as that, or do proper overflow/underflow checking
> > on it. The patch will need testing on hardware too, since it changes
> > behaviour (it should be a bugfix, but who knows).
>
> Maybe someone can test this?
I did. No regressions observed and it fixes that bug as well. Sorry I
didn't catch it earlier... :/
Acked-by: Darrick J. Wong <djwong@us.ibm.com>
--D
^ permalink raw reply
* Xilinx EDK 9.2i and current Linux src tree(s)
From: Phil Hochstetler @ 2008-03-10 18:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
Thanks to responses from this group, I'm using Ubuntu and ELDK 4.1, I
have a working environment to build a linux kernel for a Xilinx ML403
board. I pulled the kernel source at
git://git.xilinx.com/linux-2.6-xlnx.git
<http://git.xilinx.com/cgi-bin/gitweb.cgi?p=linux-2.6-xlnx.git;a=summary
> and while it will compile using "make ARCH=ppc ml403_defconfig" and
"make ARCH=ppc CROSS_COMPILE=ppc_4xx- bzImage", when I use the EDK 9.2i
to create a bitstream for the ML403 board, the BSP based header files
(xparam*) files are out of sync with the kernel source. The files in
the linux-2.6-xlnx tree appear to have been build with EDK 7.1 and I am
using the current EDK release 9.2i. The major diff seems to be that the
new EDK release moves all the periphials off the OPB bus and uses the
XPS bus instead. Any ideas on how best to resolve this? Is there a
linux tree out there that is synced with the current EDK release? Is
it sufficient to had edit in the hardware address in the existing OPB
based file and ignore the differences between OPB and XPS? Is the
difference in name only? Should I just try to pick up the entire linux
tree from the EDK release and drop it on the linux kernel? Has anyone
else been down this path already? Thanks for any words of wisdom.
--phil
[-- Attachment #2: Type: text/html, Size: 3053 bytes --]
^ permalink raw reply
* RE: Xilinx EDK 9.2i and current Linux src tree(s)
From: Stephen Neuendorffer @ 2008-03-10 18:57 UTC (permalink / raw)
To: Phil Hochstetler, linuxppc-embedded
In-Reply-To: <ADA5878BA63680469C75C14CEEE2FE28012F4DBA@mail.serveron.com>
You should copy the xparameters file into the Linux kernel tree.
Although the overall structure of the file is very different from EDK
7.1, and many names are different when using the xps* IP in EDK 9.2, the
names that are used by the kernel (in arch/ppc/syslib/virtex_devices.c)
should be defined correctly (as long as you use the linux-2.6 BSP).
Under no circumstances would I ever recommend editing that file by hand.
If you modify the design, you should regenerate the xparameters file and
copy it into your kernel. Furthermoe, the file that is in the kernel is
for a standard reference design, and unless you are using this reference
design, you *must* copy the xparameters file for your design. The
kernel from git.xilinx.com already has all the drivers, all you need is
the one file.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Phil
Hochstetler
> Sent: Monday, March 10, 2008 11:34 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Xilinx EDK 9.2i and current Linux src tree(s)
>=20
> Thanks to responses from this group, I'm using Ubuntu and ELDK 4.1, I
have a working environment to
> build a linux kernel for a Xilinx ML403 board. I pulled the kernel
source at
> git://git.xilinx.com/linux-2.6-xlnx.git
<http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-
> xlnx.git;a=3Dsummary> and while it will compile using "make =
ARCH=3Dppc
ml403_defconfig" and "make
> ARCH=3Dppc CROSS_COMPILE=3Dppc_4xx- bzImage", when I use the EDK 9.2i =
to
create a bitstream for the ML403
> board, the BSP based header files (xparam*) files are out of sync with
the kernel source. The files
> in the linux-2.6-xlnx tree appear to have been build with EDK 7.1 and
I am using the current EDK
> release 9.2i. The major diff seems to be that the new EDK release
moves all the periphials off the
> OPB bus and uses the XPS bus instead. Any ideas on how best to
resolve this? Is there a linux tree
> out there that is synced with the current EDK release? Is it
sufficient to had edit in the hardware
> address in the existing OPB based file and ignore the differences
between OPB and XPS? Is the
> difference in name only? Should I just try to pick up the entire
linux tree from the EDK release and
> drop it on the linux kernel? Has anyone else been down this path
already? Thanks for any words of
> wisdom.
>=20
> --phil
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Roland McGrath @ 2008-03-10 19:19 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <200803101501.34439.jens@de.ibm.com>
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
forgotten. This bug has been reproduced on G5's, which do not have DABRX
as I understand it.
Thanks,
Roland
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-10 19:36 UTC (permalink / raw)
To: Roland McGrath
Cc: Jan Kratochvil, Paul Mackerras, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20080310191957.0B42626F991@magilla.localdomain>
On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > already did this. Uli Weigand found this back in November. I submitted
> > a patch for this which went into 2.6.25-rc4.
> > Can you please try again with rc4 ?
>
> This is not the problem. This came up before and everyone seems have
> forgotten. This bug has been reproduced on G5's, which do not have DABRX
> as I understand it.
Yes, now that you mentioned, i've been able to reproduce this on 970FX's
blades, which i don't think have DABRX registers. I guess it's the
almost the same CPU as G5's.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Olof Johansson @ 2008-03-10 19:50 UTC (permalink / raw)
To: Luis Machado
Cc: Paul Mackerras, Jan Kratochvil, Arnd Bergmann, Roland McGrath,
linuxppc-dev
In-Reply-To: <1205177797.23926.21.camel@gargoyle.br.ibm.com>
On Mon, Mar 10, 2008 at 04:36:37PM -0300, Luis Machado wrote:
> On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > > already did this. Uli Weigand found this back in November. I submitted
> > > a patch for this which went into 2.6.25-rc4.
> > > Can you please try again with rc4 ?
> >
> > This is not the problem. This came up before and everyone seems have
> > forgotten. This bug has been reproduced on G5's, which do not have DABRX
> > as I understand it.
>
> Yes, now that you mentioned, i've been able to reproduce this on 970FX's
> blades, which i don't think have DABRX registers. I guess it's the
> almost the same CPU as G5's.
What Apple called G5 were during the production runs three different
CPUs:
970
970FX
970MP
970 was only used in the very first models. 970MP was used in the last
(the models with pci-express and up to 4 cpus). 970FX was used on almost
everything else inbetween.
-Olof
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Roland McGrath @ 2008-03-10 19:54 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, Paul Mackerras, Jan Kratochvil, Arnd Bergmann
In-Reply-To: <20080310195057.GA28140@lixom.net>
The G5 that I have says:
cpu : PPC970FX, altivec supported
revision : 3.0 (pvr 003c 0300)
and it does indeed reproduce this bug.
It also strange for it to be the DABRX issue given the failure mode.
That is, it works sometimes but unreliably (as if the context switch
sometimes fails to install the value).
Thanks,
Roland
^ permalink raw reply
* issue about CONFIG_PPC_MMU and CONFIG_SMP define
From: jie han @ 2008-03-10 20:15 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi guys,
I want to simulate compile mutli-core using sequoia(IBM/AMCC 44x processor) source code under kernel arch/powerpc directory.I want to define CONFIG_SMP, I sould define CONFIG_STD_MMU at first,but AMCC 44x don't need to config CONFIG_STD_MMU.Is CONFIG_STD_MMU just for freescale chip? How can I do next? Thanks ahead for your help,
Best regards
Jie Han
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 541 bytes --]
^ permalink raw reply
* RE: Xilinx Temac link detect
From: khollan @ 2008-03-10 20:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333FA3CF03@XMBIL132.northgrum.com>
Koss, Mike (Mission Systems) wrote:
>
> Here's a snippet from a program I use to debug an ethernet driver that I
> have using ioctl's. The ethernet ioctl interface is slightly different
> from a "normal" ioctl in that it uses sockets and not a file descriptor.
> The ioctl's I use are added to the ioctl interface in the driver, using
> the defined device-specific range (that was supposed to disappear in
> 2.5.x or 2.6.x). With this I read/write my phy register's to test out
> the interface between my TEMAC and my PHY.
>
>
Thanks for the example, everything working great now.
Kevin
--
View this message in context: http://www.nabble.com/Xilinx-Temac-link-detect-tp15616042p15954121.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 21:17 UTC (permalink / raw)
To: Segher Boessenkool, akpm; +Cc: Colin Leroy, Darrick J. Wong, lkml, linuxppc-dev
In-Reply-To: <64d5b5e6dfd0d1820d21db323ef88e25@kernel.crashing.org>
Andrew, I think you may want this patch instead of the other
adt746x-logical-bitwise-confusion-in-set_max_duty_at_crit.patch
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) & 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Segher Boessenkool @ 2008-03-10 21:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: lkml, linuxppc-dev, Colin Leroy, akpm, Darrick J. Wong
In-Reply-To: <47D5A585.8050107@tiscali.nl>
> It includes suggested changes by Segher Boessenkool and I think this
> version was tested by Darrick J. Wong
> - u8 reg;
> + u8 reg, temp;
> struct i2c_client *client = to_i2c_client(dev);
> struct adt7473_data *data = i2c_get_clientdata(client);
> - int temp = simple_strtol(buf, NULL, 10);
> - temp = temp && 0xFF;
> +
> + temp = simple_strtol(buf, NULL, 10) & 0xFF;
It still does this superfluous "& 0xff", which hides the lack of
range checking.
Segher
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-10 22:06 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080310191957.0B42626F991@magilla.localdomain>
>> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
>> already did this. Uli Weigand found this back in November. I submitted
>> a patch for this which went into 2.6.25-rc4.
>> Can you please try again with rc4 ?
>
> This is not the problem. This came up before and everyone seems have
> forgotten. This bug has been reproduced on G5's, which do not have
> DABRX
> as I understand it.
970 (all versions) _does_ have a DABRX register. Dunno if it has
the same register definition (I cannot find DABRX in the Cell docs).
Segher
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 22:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: lkml, linuxppc-dev, Colin Leroy, akpm, Darrick J. Wong
In-Reply-To: <1dd996a5ad3a455c91886cacd3243128@kernel.crashing.org>
Segher Boessenkool wrote:
>> It includes suggested changes by Segher Boessenkool and I think this
>> version was tested by Darrick J. Wong
>
>> - u8 reg;
>> + u8 reg, temp;
>> struct i2c_client *client = to_i2c_client(dev);
>> struct adt7473_data *data = i2c_get_clientdata(client);
>> - int temp = simple_strtol(buf, NULL, 10);
>> - temp = temp && 0xFF;
>> +
>> + temp = simple_strtol(buf, NULL, 10) & 0xFF;
>
> It still does this superfluous "& 0xff", which hides the lack of
> range checking.
Sorry didn't quite grep that
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..98937d3 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10);
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* dtc: Add some documentation for the dts formta
From: David Gibson @ 2008-03-10 23:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Yoder Stuart
This patch adds a dts-format.txt in the Documentation directory, with
an introduction to the dtc source format. Note that this
documentation is also going into the upcoming ePAPR specification.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Documentation/dts-format.txt | 110 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
I wrote this documentation based on an earlier draft from Stuart
Yoder. Stuart, can you please reply with a Signed-off-by line?
Index: dtc/Documentation/dts-format.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/Documentation/dts-format.txt 2008-03-11 10:42:17.000000000 +1100
@@ -0,0 +1,110 @@
+Device Tree Source Format (version 1)
+=====================================
+
+The Device Tree Source (DTS) format is a textual representation of a
+device tree in a form that can be processed by dtc into a binary
+device tree in the form expected by the kernel. The description below
+is not a formal syntax definition of DTS, but describes the basic
+constructs used to represent device trees.
+
+Node and property definitions
+-----------------------------
+
+Device tree nodes are defined with a node name and unit address with
+braces marking the start and end of the node definition. They may be
+preceded by a label.
+
+ [label:] node-name[@unit-address] {
+ [properties definitions]
+ [child nodes]
+ }
+
+Nodes may contain property definitions and/or child node
+definitions. If both are present, properties must come before child
+nodes.
+
+Property definitions are name value pairs in the form:
+ [label:] property-name = value;
+except for properties with empty (zero length) value which have the
+form:
+ [label:] property-name;
+
+Property values may be defined as an array of 32-bit integer cells, as
+NUL-terminated strings, as bytestrings or a combination of these.
+
+* Arrays of cells are represented by angle brackets surrounding a
+ space separated list of C-style integers
+
+ e.g. interrupts = <17 0xc>;
+
+* A 64-bit value is represented with two 32-bit cells.
+
+ e.g. clock-frequency = <0x00000001 0x00000000>;
+
+* A NUL-terminated string value is represented using double quotes
+ (the property value is considered to include the terminating NUL
+ character).
+
+ e.g. compatible = "simple-bus";
+
+* A bytestring is enclosed in square brackets [] with each byte
+ represented by two hexadecimal digits. Spaces between each byte are
+ optional.
+
+ e.g. local-mac-address = [00 00 12 34 56 78]; or equivalently
+ local-mac-address = [000012345678];
+
+* Values may have several comma-separated components, which are
+ concatenated together.
+ e.g. compatible = "ns16550", "ns8250";
+ example = <0xf00f0000 19>, "a strange property format";
+
+* In a cell array a reference to another node will be expanded to that
+ node's phandle. References may by '&' followed by a node's label:
+ e.g. interrupt-parent = < &mpic >;
+ or they may be '&' followed by a node's full path in braces:
+ e.g. interrupt-parent = < &{/soc/interrupt-controller@40000} >;
+
+* Outside a cell array, a reference to another node will be expanded
+ to that node's full path.
+ e.g. ethernet0 = &EMAC0;
+
+* Labels may also appear before or after any component of a property
+ value, or between cells of a cell array, or between bytes of a
+ bytestring.
+ e.g. reg = reglabel: <0 sizelabel: 0x1000000>;
+ e.g. prop = [ab cd ef byte4: 00 ff fe];
+ e.g. str = start: "string value" end: ;
+
+
+File layout
+-----------
+
+Version 1 DTS files have the overall layout:
+ /dts-v1/;
+
+ [memory reservations]
+
+ / {
+ [property definitions]
+ [child nodes]
+ };
+
+* The "/dts-v1/;" must be present to identify the file as a version 1
+ DTS (dts files without this tag will be treated by dtc as being in
+ the obsolete "version 0", which uses a different format for integers
+ amongst other small but incompatible changes).
+
+* Memory reservations define an entry for the device tree blob's
+ memory reservation table. They have the form:
+ e.g. /memreserve/ <address> <length>;
+ Where <address> and <length> are 64-bit C-style integers.
+
+* The / { ... }; section defines the root node of the device tree.
+
+* C style (/* ... */) and C++ style (// ...) comments are supported.
+
+
+
+ -- David Gibson <david@gibson.dropbear.id.au>
+ -- Yoder Stuart <stuart.yoder@freescale.com>
--
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
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: David Gibson @ 2008-03-10 23:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <9f7d0248e911f6fa1a2d4292c96ef72e@kernel.crashing.org>
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > This isn't a problem with this device tree, but it's probably time we
> > started establishing some conventional generic names for nand flash
> > and board-control devices.
> >
> > So, to start the ball rolling, I've seen several names for nand flash
> > nodes, I'd suggest we standardise on "nand-flash".
>
> What's wrong with the already well-established generic name "flash"?
I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise. I am quite open to being
convinced otherwise, though.
> > I've seen several variants for board control devices (cpld, bcsr,
> > fpga, etc.) I suggest we standardise on "board-control"
>
> Fine with me, but it's very vague (hard to avoid though).
Yes.
--
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
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: David Gibson @ 2008-03-11 0:32 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080309223109.GA3989@netgate.macqel>
On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> Hi Ben,
>
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
>
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems to be recognized. Could it be a problem with the phy ?
> I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> Do I need to give the phy type in the dts file, and how ?
>
> I would also like to know if it is possible to still get in linux the mac
> address known by uboot when using a dts file, and how ?
This chiefly depends on whether you're using an old u-boot that
doesn't know about the device tree, or a new u-boot which itself
supplies a device tree to the kernel.
If the old u-boot, you'll need to write a bootwrapper for your
platform which reads the bd_t and pokes the right mac addresses into
the device tree.
If the new u-boot, u-boot itself should put the address into the
device tree. If it's not, why it's not is a u-boot question rather
than a device tree question.
--
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: David Gibson @ 2008-03-11 0:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0803071055200.8522@blarg.am.freescale.net>
On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
> Normally we assume kernel images will be loaded at offset 0. However
> there are situations, like when the kernel itself is running at a non-zero
> physical address, that we don't want to load it at 0.
>
> Allow the wrapper to take an offset. We use this when building u-boot images.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Hrm. It concerns me that with the patch as it stands,
CONFIG_MEMORY_START looks like a fairly universal option, but it will
only be respected on u-boot platforms (and only new u-boot, not cuboot
at that).
--
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
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Arnd Bergmann @ 2008-03-11 0:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Li Yang, paulus, David Gibson
In-Reply-To: <20080310235429.GC11559@localhost.localdomain>
On Tuesday 11 March 2008, David Gibson wrote:
> On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > This isn't a problem with this device tree, but it's probably time we
> > > started establishing some conventional generic names for nand flash
> > > and board-control devices.
> > >
> > > So, to start the ball rolling, I've seen several names for nand flash
> > > nodes, I'd suggest we standardise on "nand-flash".
> >=20
> > What's wrong with the already well-established generic name "flash"?
>=20
> I was concerned that using "flash" for both NOR flash (which it
> already is) and NAND flash might be unwise. =A0I am quite open to being
> convinced otherwise, though.
One argument for just using "flash" is that there are much finer differences
than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
being further types of flash that don't fit the categories exactly, though
each one for different reasons.
=46or SD/MMC, there are good reasons to use something completely different,
for the others, calling them all "flash" sounds better than fitting them
into "nand" and "nor".
Arnd <><
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: David Gibson @ 2008-03-11 0:45 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-mtd, ben
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0418505E@ismail.innsys.innovsys.com>
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > Hi everybody,
> >
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> >
> > On the platform_device based ppc architecture, the
> > drivers/mtd/maps/plat-ram.c
> > driver handled "mtd-ram" platform devices. There is no such
> > driver for the
> > OF-based powerpc architecture.
> >
> > As a temporary workaround I hacked the physmap_of driver to
> > handle "direct-mapped" OF devices oh type "ram" by adding a
> > corresponding entry in the of_flash_match[] array. This seems to work
> > fine.
> >
> > What would be the preferred way to handle OF-compatible RAM-based MTD
> > devices ? The 3 ways I can think of are
> >
> > 1. porting the plat-ram driver to OF (the driver isn't used
> > in the kernel tree
> > but I suspect it is used by out-of-tree boards)
> >
> > 2. creating a new plat-ram-of driver, much like the
> > physmap_of driver comes
> > from the physmap driver
> >
> > 3. extending the physmap_of driver to handle RAM devices (in
> > which case
> > references to "flash" in the function names should probably
> > be replaced
> > by "mtd")
> >
> > I live option 3 better so far.
> >
> > Has anyone already worked on this ? Is there any defined
> > device tree mapping
> > for MTD RAM devices ?
>
> We ran ito the same issue.
> We did option 3, as it was efinetly the easiest,
I think this is the best option in principle.
> here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the "probe-type"
field. The solution should be adapted to the new approach which uses
values in the "compatible" field to indicate various sorts of flash
device.
--
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
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-03-11 1:02 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47C750CE.7050202@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6762 bytes --]
On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
>
> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
Hi Manish,
A few comments inline ..
> Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 21:57:52.000000000 -0600
> @@ -0,0 +1,105 @@
> +/*
> + * Hypervisor-assisted dump
> + *
> + * Linas Vepstas, Manish Ahuja 2008
> + * Copyright 2008 IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/mm.h>
> +#include <linux/pfn.h>
> +#include <linux/swap.h>
> +
> +#include <asm/page.h>
> +#include <asm/phyp_dump.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +
> +/* Global, used to communicate data between early boot and late boot */
> +static struct phyp_dump phyp_dump_global;
> +struct phyp_dump *phyp_dump_info = &phyp_dump_global;
I don't see the point of this. You have a static (ie. non-global) struct
called phyp_dump_global, then you create a pointer to it and pass that
around. It could just be:
phyp_dump.h:
extern struct phyp_dump phyp_dump_info;
phyp_dump.c:
struct phyp_dump phyp_dump_info;
phyp_dump_info.foo = bar;
I also think the struct should be called phyp_dump_info, not phyp_dump -
it contains info about phyp_dump, not the dump itself.
> +
> +/**
> + * release_memory_range -- release memory previously lmb_reserved
> + * @start_pfn: starting physical frame number
> + * @nr_pages: number of pages to free.
> + *
> + * This routine will release memory that had been previously
> + * lmb_reserved in early boot. The released memory becomes
> + * available for genreal use.
> + */
> +static void
> +release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +{
> + struct page *rpage;
> + unsigned long end_pfn;
> + long i;
> +
> + end_pfn = start_pfn + nr_pages;
> +
> + for (i = start_pfn; i <= end_pfn; i++) {
> + rpage = pfn_to_page(i);
> + if (PageReserved(rpage)) {
> + ClearPageReserved(rpage);
> + init_page_count(rpage);
> + __free_page(rpage);
> + totalram_pages++;
> + }
> + }
> +}
> +
> +static int __init phyp_dump_setup(void)
> +{
> + unsigned long start_pfn, nr_pages;
> +
> + /* If no memory was reserved in early boot, there is nothing to do */
> + if (phyp_dump_info->init_reserve_size == 0)
> + return 0;
> +
> + /* Release memory that was reserved in early boot */
> + start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
> + nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
> + release_memory_range(start_pfn, nr_pages);
> +
> + return 0;
> +}
> +machine_subsys_initcall(pseries, phyp_dump_setup);
> +
> +int __init early_init_dt_scan_phyp_dump(unsigned long node,
> + const char *uname, int depth, void *data)
> +{
> +#ifdef CONFIG_PHYP_DUMP
> + const unsigned int *sizes;
> +
> + phyp_dump_info->phyp_dump_configured = 0;
> + phyp_dump_info->phyp_dump_is_active = 0;
> +
> + if (depth != 1 || strcmp(uname, "rtas") != 0)
> + return 0;
> +
> + if (of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL))
> + phyp_dump_info->phyp_dump_configured++;
> +
> + if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
> + phyp_dump_info->phyp_dump_is_active++;
> +
> + sizes = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + NULL);
> + if (!sizes)
> + return 0;
> +
> + if (sizes[0] == 1)
> + phyp_dump_info->cpu_state_size = *((unsigned long *)&sizes[1]);
> +
> + if (sizes[3] == 2)
> + phyp_dump_info->hpte_region_size =
> + *((unsigned long *)&sizes[4]);
> +#endif
This doesn't need to be inside #ifdef, you have a dummy version already
defined in the header file.
> Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
> ===================================================================
> --- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c 2008-02-28 21:54:57.000000000 -0600
> +++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-02-28 21:55:27.000000000 -0600
> @@ -1039,6 +1040,51 @@ static void __init early_reserve_mem(voi
> #endif
> }
>
> +#ifdef CONFIG_PHYP_DUMP
> +/**
> + * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
> + *
> + * This routine may reserve memory regions in the kernel only
> + * if the system is supported and a dump was taken in last
> + * boot instance or if the hardware is supported and the
> + * scratch area needs to be setup. In other instances it returns
> + * without reserving anything. The memory in case of dump being
> + * active is freed when the dump is collected (by userland tools).
> + */
> +static void __init reserve_crashed_mem(void)
This could do with a name change IMO, eg. phyp_dump_reserve_mem() or
something.
> +{
> + unsigned long base, size;
> + if (!phyp_dump_info->phyp_dump_configured) {
> + printk(KERN_ERR "Phyp-dump not supported on this hardware\n");
> + return;
> + }
> +
> + if (phyp_dump_info->phyp_dump_is_active) {
> + /* Reserve *everything* above RMR.Area freed by userland tools*/
> + base = PHYP_DUMP_RMR_END;
> + size = lmb_end_of_DRAM() - base;
> +
> + /* XXX crashed_ram_end is wrong, since it may be beyond
> + * the memory_limit, it will need to be adjusted. */
> + lmb_reserve(base, size);
> +
> + phyp_dump_info->init_reserve_start = base;
> + phyp_dump_info->init_reserve_size = size;
> + } else {
> + size = phyp_dump_info->cpu_state_size +
> + phyp_dump_info->hpte_region_size +
> + PHYP_DUMP_RMR_END;
> + base = lmb_end_of_DRAM() - size;
> + lmb_reserve(base, size);
> + phyp_dump_info->init_reserve_start = base;
> + phyp_dump_info->init_reserve_size = size;
> + }
> +}
> +#else
> +static inline void __init reserve_crashed_mem(void) {}
> +#endif /* CONFIG_PHYP_DUMP && CONFIG_PPC_RTAS */
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: David Gibson @ 2008-03-11 1:32 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <200803110143.50561.arnd@arndb.de>
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote:
> On Tuesday 11 March 2008, David Gibson wrote:
> > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > > This isn't a problem with this device tree, but it's probably time we
> > > > started establishing some conventional generic names for nand flash
> > > > and board-control devices.
> > > >
> > > > So, to start the ball rolling, I've seen several names for nand flash
> > > > nodes, I'd suggest we standardise on "nand-flash".
> > >
> > > What's wrong with the already well-established generic name "flash"?
> >
> > I was concerned that using "flash" for both NOR flash (which it
> > already is) and NAND flash might be unwise. I am quite open to being
> > convinced otherwise, though.
>
> One argument for just using "flash" is that there are much finer differences
> than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
> being further types of flash that don't fit the categories exactly, though
> each one for different reasons.
>
> For SD/MMC, there are good reasons to use something completely different,
> for the others, calling them all "flash" sounds better than fitting them
> into "nand" and "nor".
Ok, I'm convinced. "flash" it is.
--
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
^ permalink raw reply
* The question about the QUICC ENGINE microcode for freescale PowerPC?
From: 郭劲 @ 2008-03-11 1:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I want to realize the high speed TCP package on GETH of MPC8360E,I would like the
speed on both UCC1 and UCC2 for both send and receive TCP package(big package) up
to 1000M bits/sec, so the total internet speed is 4000M bits/sec for MPC8360E.
I tested the internet performance by IPERF test software with the condition that
the core cpu deal with the TCP package,without microcode. I config the UCC2 down,
config UCC1 to send package out to an server PC,no receive,the speed for UCC1 just
only sending package is about 300M bits/sec, and CPU is 100% used. This speed is
so slow, is too slow. If I send and recieve at the same time, the speed is much
slower, if I make the UCC2 up, the speed is much slower and slower.
I do not know how to incrase the internet speed for MPC8360E, somebody told me, we
must use the microcode for QUICC ENGINE.
My question is that where can I download the microcode for QUICC ENGINE and how to
use it? Whether or not this microcode can help me to realize the 4000M bits/sec
for TCP package?
^ permalink raw reply
* Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-03-11 4:19 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080311003705.GH11559@localhost.localdomain>
On Mar 10, 2008, at 7:37 PM, David Gibson wrote:
> On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
>> Normally we assume kernel images will be loaded at offset 0. However
>> there are situations, like when the kernel itself is running at a
>> non-zero
>> physical address, that we don't want to load it at 0.
>>
>> Allow the wrapper to take an offset. We use this when building u-
>> boot images.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Hrm. It concerns me that with the patch as it stands,
> CONFIG_MEMORY_START looks like a fairly universal option, but it will
> only be respected on u-boot platforms (and only new u-boot, not cuboot
> at that).
Nothing stops anyone from submitting patches that makes it work for
other platforms. CONFIG_MEMORY_START is only of utility on book-e
class machines at this point and from a Freescale point of view that's
85xx and thus means u-boot. IBM, AMCC, or a random Joe is free to
submit patches to make it work on 44x. :)
- k
^ permalink raw reply
* [PATCH] [POWERPC] Remove Kconfig option BOOT_LOAD
From: Kumar Gala @ 2008-03-11 5:00 UTC (permalink / raw)
To: linuxppc-dev
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
---
in my powerpc-next branch.
- k
arch/powerpc/Kconfig | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4e13e0..803415e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -663,22 +663,6 @@ config CONSISTENT_SIZE
hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
default "0x00200000" if NOT_COHERENT_CACHE
-config BOOT_LOAD_BOOL
- bool "Set the boot link/load address"
- depends on ADVANCED_OPTIONS && !PPC_MULTIPLATFORM
- help
- This option allows you to set the initial load address of the zImage
- or zImage.initrd file. This can be useful if you are on a board
- which has a small amount of memory.
-
- Say N here unless you know what you are doing.
-
-config BOOT_LOAD
- hex "Link/load address for booting" if BOOT_LOAD_BOOL
- default "0x00400000" if 40x || 8xx || 8260
- default "0x01000000" if 44x
- default "0x00800000"
-
config PIN_TLB
bool "Pinned Kernel TLBs (860 ONLY)"
depends on ADVANCED_OPTIONS && 8xx
--
1.5.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox