* [PATCH] [RFC][v2] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer @ 2008-03-19 17:24 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, jacmet, git-dev
In the future, this will be used to provide similar configuration for
PowerPC and Microblaze. It may also be convenient for those using
Xilinx cores as peripherals for external processors, rather than
explicitly having a dependance on the processor architecture.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
[V2] Updated to depend on PPC32, rather than just XILINX_VIRTEX, to let
these drivers be compiled in more configurations.
---
Grant,
There is still the issue of the ppc part, which is
required for backward compatibility. If this has to wait until ppc
dies, then that's fine with me, I guess.
Steve
---
drivers/block/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
drivers/misc/Kconfig | 17 +++++++++++++++++
drivers/serial/Kconfig | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/video/Kconfig | 2 +-
6 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 4d0119e..7f55ba4 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -412,7 +412,7 @@ source "drivers/s390/block/Kconfig"
config XILINX_SYSACE
tristate "Xilinx SystemACE support"
- depends on 4xx
+ depends on XILINX_DRIVERS
help
Include support for the Xilinx SystemACE CompactFlash interface
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 157ae2a..8230ad1 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -833,7 +833,7 @@ config DTLK
config XILINX_HWICAP
tristate "Xilinx HWICAP Support"
- depends on XILINX_VIRTEX
+ depends on XILINX_DRIVERS
help
This option enables support for Xilinx Internal Configuration
Access Port (ICAP) driver.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..89f9309 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -233,3 +233,20 @@ config ATMEL_SSC
If unsure, say N.
endif # MISC_DEVICES
+endmenu
+
+
+#
+# Xilinx devices and common device driver infrastructure
+#
+
+config XILINX_DRIVERS
+ bool
+ depends on PPC32
+ default y
+ ---help---
+ This option is used to enable all of the Xilinx drivers on
+ supported architectures. This is often useful if you have a
+ Xilinx FPGA in a system, either using embedded processors
+ internal to the FPGA or external processors.
+
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index d7e1996..d4e8879 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -757,7 +757,7 @@ config SERIAL_IMX_CONSOLE
config SERIAL_UARTLITE
tristate "Xilinx uartlite serial port support"
- depends on PPC32
+ depends on XILINX_DRIVERS
select SERIAL_CORE
help
Say Y here if you want to use the Xilinx uartlite serial controller.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index abf0504..c66838f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -183,7 +183,7 @@ config SPI_TXX9
config SPI_XILINX
tristate "Xilinx SPI controller"
- depends on SPI_MASTER && XILINX_VIRTEX && EXPERIMENTAL
+ depends on SPI_MASTER && XILINX_DRIVERS && EXPERIMENTAL
select SPI_BITBANG
help
This exposes the SPI controller IP from the Xilinx EDK.
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5b3dbcf..a66ff4b 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1871,7 +1871,7 @@ config FB_PS3_DEFAULT_SIZE_M
config FB_XILINX
tristate "Xilinx frame buffer support"
- depends on FB && XILINX_VIRTEX
+ depends on FB && XILINX_DRIVERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.5.3.4-dirty
^ permalink raw reply related
* Uart(lite)/ELDK 4.1 section mismatch -> ML403
From: Phil Hochstetler @ 2008-03-19 17:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
I just booted the "git.xilinx.com/Linux-2.6-xlnx" source code to a login
prompt last week. I'm using Xilinx EDK 9.2 and ELDK 4.1 crosstools
(uclib version) and Ubuntu 7.10 workstation as my host OS (under
VMware). The easiest path is to use the Uartlite driver (and disable
the 82550 stuff because the stand directory will not compile currently,
there is a patch somewhere on the last from last Jan about what defines
are missing but you can just use uartlite instead). Be sure to use the
correct reference design (I started with the Virtex4_PPC_Example_9_2.zip
in EDK/EDKexamples directory). Add the sysace driver into the design
and (w/ interrupts on) and make sure you have uartlite selected (with
interrupts on). Build the design and use the xparameters_403.h file to
build your kernel. In this case, be sure to turn on uartlite console
support and turn off 82550 console support or your kernel will not work.
Also be sure to add Ext3 filesystem to your kernel config. Once you add
the sysace driver support, you can then create a ace file and replace
their kernel on the compact flash and boot it to their root filesystem
(works, I just did it). This gets you a full booted kernel on a working
root filesystem with min work.
For references see:
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
http://simfami.marlab.ac.uk/piprg/wiki/index.php?title=Installing_Linux_
Kernel_2.6.23_on_the_PPC405_core_of_a_Xilinx_ML403_board
--phil
[-- Attachment #2: Type: text/html, Size: 3591 bytes --]
^ permalink raw reply
* RE: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer @ 2008-03-19 17:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803182205n741c652ci1e1871707c5c3e13@mail.gmail.com>
My feeling is if the drivers should be consistently enabled or not, then
we should enforce that consistency by the structure of the code.
Steve
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Tuesday, March 18, 2008 10:06 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; jacmet@sunsite.dk
> Subject: Re: [PATCH] [RFC] Xilinx: Add generic configuration option to
enable all xilinx drivers.
>=20
> On Tue, Mar 18, 2008 at 10:32 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> >
> >
> > Hmm... interesting points. I guess my feeling was that
XILINX_DRIVERS could
> > be a more broadly configurable option, with some of these ideas in
mind.
> > Currently, it's hidden by default, but we could easily change this
to be
> > visible by default, or selected by a broader number of
architectures. I
> > tend to think about them as a group: What if x86 *did* support the
> > primitives needed by these drivers, then if the individual drivers
depend on
> > XILINX_DRIVERS, then the modification could be made in one spot. By
your
> > suggestion, we would have to modify each one independantly.
>=20
> Heh; it's not *that* many drivers and it's just Kconfig stuff which is
> real easy to change. My preference would be to eliminate
> XILINX_DRIVERS entirely, but I'm not going to fight about it. :-)
>=20
> Cheers,
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* muram in device tree for mpc8250 in arch/powerpc
From: James Black @ 2008-03-19 17:06 UTC (permalink / raw)
To: linuxppc-embedded
I am porting a proprietary mpc8250 board to 2.6.24. I have the 2.6.19
kernel from denx working. I have ported to u-boot 1.3.2 and have the
platform setup within the 2.6.24 kernel and used pq2fads.dts as an
example of the device tree.
Everything in u-boot is working. u-boot doesn't complain about the
device tree and fills in the clocks and memory using the "fdt
boardsetup" command. In fact, u-boot 1.3.2 can boot the 2.6.29 kernel,
no problem.
I turned on early kernel debugging in 2.6.24 and it looks like all the
device tree parsing is working. The boot hangs and or crashes while
trying to setup the paging. I drilled down the code from init/main.c
and found that it seems the muram device node is killing the
allocator.
I tried to fully describe the segments in muram node and it seems to
mess things up even worse. Can anyone give some pointers to help me
work out this issue?
I wanted to start with as simple a description as possible. The
following tree describes the flash, SDRAM, SCC1, SCC3 and FCC1.
/*
* Device Tree for the CTA5000S board with an MPC8250 chip.
* Device Tree for the PQ2FADS-ZU board with an MPC8280 chip.
*
* Copyright 2007 Freescale Semiconductor Inc.
*
* 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.
*/
/ {
model = "cta5000s";
compatible = "fsl,cta5000s";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8250@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <4000>;
i-cache-size = <4000>;
timebase-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
localbus@f0010100 {
compatible = "fsl,mpc8250-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 60>;
ranges = <0 0 fe000000 00200000>;
flash@fe000000,0 {
compatible = "amd", "cfi-flash";
reg = <0 fe000000 00200000>;
bank-width = <2>;
device-width = <1>;
};
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8250", "fsl,pq2-soc";
ranges = <00000000 f0000000 00014000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <f0000000 00014000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8250-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 4000 8000 4000>;
};
};
brg@119f0 {
compatible = "fsl,mpc8250-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8250-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
serial@11a40 {
device_type = "serial";
compatible = "fsl,mpc8250-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a40 20 8200 100>;
interrupts = <2a 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <5>;
fsl,cpm-command = <11800000>;
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8250-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100>;
interrupts = <20 8>;
interrupt-parent = <&PIC>;
linux,network-index = <0>;
fsl,cpm-command = <14000300>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8250-pic", "fsl,cpm2-pic";
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};
};
^ permalink raw reply
* Re: [PATCH] MPC8313 NAND fixes
From: Scott Wood @ 2008-03-19 17:02 UTC (permalink / raw)
To: Mike Hench; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <6629C06B144F5C4098DFF95C4FF9DAF702BA1D02@mailsrv.engagenet.com>
On Wed, Mar 19, 2008 at 10:28:19AM -0500, Mike Hench wrote:
>
> From: Mike Hench
> Sent: Wednesday, March 19, 2008 10:22 AM
> To: 'mhench@wi.rr.com'
> Subject: [PATCH] MPC813 NAND fixes
This patch is whitespace-mangled. Also, please don't post HTML.
> - unsigned int irq_status; /* status read from LTESR by irq
> handler */
>
> + volatile unsigned int irq_status; /* status read from LTESR
> by irq handler */
This change is not needed; both out_be32() and wait_event() act as
optimization barriers.
> @@ -379,13 +379,13 @@ static int fsl_elbc_run_command(struct m
>
> in_be32(&lbc->fbar), in_be32(&lbc->fpar),
>
> in_be32(&lbc->fbcr), priv->bank);
>
>
>
> + ctrl->irq_status = 0;
>
> /* execute special operation */
>
> out_be32(&lbc->lsor, priv->bank);
>
>
>
> /* wait for FCM complete flag or timeout */
>
> - ctrl->irq_status = 0;
ACK this change.
> wait_event_timeout(ctrl->irq_wait, ctrl->irq_status,
>
> - FCM_TIMEOUT_MSECS * HZ/1000);
>
> + (FCM_TIMEOUT_MSECS * HZ)/1000);
This change is a no-op. Multiplication and division are evaluated at the
same precedence, left-to-right.
> if (mtd->writesize == 512) {
>
> priv->page_size = 0;
>
> - clrbits32(&lbc->bank[priv->bank].or,
> ~OR_FCM_PGS);
>
> + clrbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
D'oh! Thanks for finding this.
ACK this change.
> - /* The default u-boot configuration on MPC8313ERDB causes
> errors;
>
> - * more delay is needed. This should be safe for other
> boards
>
> - * as well.
>
> - */
>
> - setbits32(&lbc->bank[priv->bank].or, 0x70);
And this one.
-Scott
^ permalink raw reply
* Re: Hi,friends, the question about the u-boot and device tree?
From: Scott Wood @ 2008-03-19 16:17 UTC (permalink / raw)
To: ????; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <405889728.25141@tsinghua.org.cn>
On Wed, Mar 19, 2008 at 09:22:08AM +0800, ???? wrote:
> My board is MPC8360EMDS, my bootm command is "bootm uImage ramdisk_ppc
> mpc836x_mds.dtb", I used the MPC8360E_PB_K26_20071012-LTIB.iso to generate above
> uImage, ramdisk_ppc,mpc836x_mds.dtb.
Could you try the latest upstream u-boot, dts, and kernel to see if
things are better?
> If I fill the frequency to zero on mpc836x_mds.dts,
Which frequency property? Did you get any device-tree-related error
messages from u-boot?
> I also has another question, I modified the HRCW to config the cpu as 660/330/400
> MHZ during power on, I used the "clocks" command on u-boot to see that the clock
> is real 660/330/400 MHZ, then I changed the frequency value on dts to 660/330/400,
> after the bootm command, the linux was not carshed after serial configuration, but
> the output is random.
>
> "
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> [output from serial is random]
> "
>
> I have config the frequency both on HRCW and devie tree is the same, why the
> frequency for serial on linux is not right? Why the 528/260/400 is Ok, the
> 660/330/400 has problem on serial.
What are you putting in the serial nodes' clock-frequency in each case?
-Scott
^ permalink raw reply
* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Stephen Neuendorffer @ 2008-03-19 16:16 UTC (permalink / raw)
To: Qin Lin, linuxppc-embedded
In-Reply-To: <16137363.post@talk.nabble.com>
>From the data sheet:
"The OPB BUS clock frequency must be greater than or equal to 65 MHz for
100 Mbs Ethernet operation and greater than or equal to 6.5 Mhz for 10
Mbs Ethernet operation"
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
> Sent: Tuesday, March 18, 2008 10:27 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>=20
>=20
> Hi,All
>=20
> I found out what the problem was from.
> When i set the Bus clock frequency to 50MHz and Processor clock
Frequency
> 200MHz, opb_ethernet does not work with the driver.
>=20
> And i check the driver,don't find the code base on the frequency .
Anyone
> knows the reason?
>=20
>=20
>=20
> --
> View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
> xlnx-tp16089631p16137363.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Stefan Roese @ 2008-03-19 16:15 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Glacier dts. The Glacier is nearly identical to the
Canyonlands (460EX). Here the differences:
- 4 ethernet ports instead of 2
- no SATA port
- no USB port
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/glacier.dts | 464 +++++++++++++++++++++++++++++++++++++
1 files changed, 464 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/glacier.dts
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
new file mode 100644
index 0000000..7381cdd
--- /dev/null
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -0,0 +1,464 @@
+/*
+ * Device Tree Source for AMCC Glacier (460GT)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,glacier";
+ compatible = "amcc,canyonlands";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ ethernet2 = &EMAC2;
+ ethernet3 = &EMAC3;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460GT";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460gt";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460gt";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460gt", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <20>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ desc-base-addr-high = <8>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460gt", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460gt", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460gt", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ RGMII1: emac-rgmii@ef601600 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601600 8>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC2: ethernet@ef601100 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC2>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 12 4
+ /*Wake*/ 1 &UIC2 16 4>;
+ reg = <ef601100 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2>;
+ mal-rx-channel = <10>;
+ cell-index = <2>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC3: ethernet@ef601200 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC3>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 13 4
+ /*Wake*/ 1 &UIC2 17 4>;
+ reg = <ef601200 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <3>;
+ mal-rx-channel = <18>;
+ cell-index = <3>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.4
^ permalink raw reply related
* mpc8568mds bootup problem
From: mike zheng @ 2008-03-19 15:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
My mpc8568mds board does not bootup. I am using Freescale's BSP on
kernel2.6.23. The following is the log from serial port. Any idea?
What is the next module to be initialized after the cfq? Where can I
comment it out for debugging purpose?
Thanks for your help,
Mike
=> bootm 1000000 2000000 400000
bootm 1000000 2000000 400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-03-18 20:48:11 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1283304 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-06-26 4:25:24 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3719970 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1f1c2000, end 1f54e322 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.0.2 20060628 (Wasabi)) #9 Tue
Mar 18 16:48:04 EDT 2008
Found initrd at 0xdf1c2000:0xdf54e322
-> find_legacy_serial_port()
stdout is /soc8568@e0000000/serial@4600
legacy_serial_console = 1
default console speed = 115340
<- find_legacy_serial_port()
console [udbg0] enabled
setup_arch: bootmem
mpc85xx_mds_setup_arch()
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
pio-handle not available
pio-handle not available
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists in Zone order. Total pages: 130048
Kernel command line: ramdisk_size=42000 root=/dev/ram rw console=ttyS1,115200
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 80, shift: 7, mask: 7f
mpic: Initializing for 80 sources
QEIC (64 IRQ sources) at fd6ed080
PID hash table entries: 2048 (order: 11, 8192 bytes)
-> check_legacy_serial_console()
console was specified !
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512896k/524288k available (2556k kernel code, 10952k reserved,
108k data, 102k bss, 144k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
rstcr compatible register does not exist!
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:02.0
PCI: Cannot allocate resource region 0 of device 0000:00:02.1
PCI: Cannot allocate resource region 0 of device 0000:00:02.2
PCI: Cannot allocate resource region 0 of device 0000:00:03.0
PCI: Cannot allocate resource region 0 of device 0000:00:03.1
PCI: Cannot allocate resource region 0 of device 0000:00:03.2
PCI: Cannot allocate resource region 0 of device 0000:00:04.0
...
PCI: Cannot allocate resource region 0 of device 0000:00:1f.0
PCI: Cannot allocate resource region 0 of device 0000:00:1f.1
PCI: Cannot allocate resource region 0 of device 0000:00:1f.2
Generic PHY: Registered new driver
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 4, 65536 bytes)
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 3632k freed
Fixing serial ports interrupts and IO ports ...
fixup_port_irq(0)
fixup_port_mmio(0)
fixup_port_irq(1)
fixup_port_mmio(1)
Registering platform serial ports
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
^ permalink raw reply
* mpc8568mds bootup problem
From: mike zheng @ 2008-03-19 15:48 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
My mpc8568mds board does not bootup. I am using Freescale's BSP on
kernel2.6.23. The following is the log from serial port. Any idea?
What is the next module to be initialized after the cfq? Where can I
comment it out for debugging purpose?
Thanks for your help,
Mike
=> bootm 1000000 2000000 400000
bootm 1000000 2000000 400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-03-18 20:48:11 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1283304 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-06-26 4:25:24 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3719970 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1f1c2000, end 1f54e322 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.0.2 20060628 (Wasabi)) #9 Tue
Mar 18 16:48:04 EDT 2008
Found initrd at 0xdf1c2000:0xdf54e322
-> find_legacy_serial_port()
stdout is /soc8568@e0000000/serial@4600
legacy_serial_console = 1
default console speed = 115340
<- find_legacy_serial_port()
console [udbg0] enabled
setup_arch: bootmem
mpc85xx_mds_setup_arch()
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
pio-handle not available
pio-handle not available
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists in Zone order. Total pages: 130048
Kernel command line: ramdisk_size=42000 root=/dev/ram rw console=ttyS1,115200
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 80, shift: 7, mask: 7f
mpic: Initializing for 80 sources
QEIC (64 IRQ sources) at fd6ed080
PID hash table entries: 2048 (order: 11, 8192 bytes)
-> check_legacy_serial_console()
console was specified !
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512896k/524288k available (2556k kernel code, 10952k reserved,
108k data, 102k bss, 144k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
rstcr compatible register does not exist!
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:02.0
PCI: Cannot allocate resource region 0 of device 0000:00:02.1
PCI: Cannot allocate resource region 0 of device 0000:00:02.2
PCI: Cannot allocate resource region 0 of device 0000:00:03.0
PCI: Cannot allocate resource region 0 of device 0000:00:03.1
PCI: Cannot allocate resource region 0 of device 0000:00:03.2
PCI: Cannot allocate resource region 0 of device 0000:00:04.0
...
PCI: Cannot allocate resource region 0 of device 0000:00:1f.0
PCI: Cannot allocate resource region 0 of device 0000:00:1f.1
PCI: Cannot allocate resource region 0 of device 0000:00:1f.2
Generic PHY: Registered new driver
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 4, 65536 bytes)
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 3632k freed
Fixing serial ports interrupts and IO ports ...
fixup_port_irq(0)
fixup_port_mmio(0)
fixup_port_irq(1)
fixup_port_mmio(1)
Registering platform serial ports
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
^ permalink raw reply
* [PATCH] MPC813 NAND fixes
From: Mike Hench @ 2008-03-19 15:28 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]
________________________________
From: Mike Hench
Sent: Wednesday, March 19, 2008 10:22 AM
To: 'mhench@wi.rr.com'
Subject: [PATCH] MPC813 NAND fixes
Fix a race condition in fsl_elbc_run_command
Declare a variable written by an interrupt volatile.
Added parentheses to make timeout non-zero
Fix incorrect usage of clearbits32 that bashed option register
Remove work around for bashed register
Signed-off-by: Mike Hench <mhench@elutions.com>
---
--- linux-2.6.25-rc5.orig/drivers/mtd/nand/fsl_elbc_nand.c 2008-03-10
00:22:27.000000000 -0500
+++ linux-2.6.25-rc5/drivers/mtd/nand/fsl_elbc_nand.c 2008-03-19
10:08:22.000000000 -0500
@@ -264,7 +264,7 @@ struct fsl_elbc_ctrl {
struct elbc_regs __iomem *regs;
int irq;
wait_queue_head_t irq_wait;
- unsigned int irq_status; /* status read from LTESR by irq
handler */
+ volatile unsigned int irq_status; /* status read from LTESR
by irq handler */
u8 __iomem *addr; /* Address of assigned FCM buffer
*/
unsigned int page; /* Last page written to / read from
*/
unsigned int read_bytes; /* Number of bytes read during
command */
@@ -379,13 +379,13 @@ static int fsl_elbc_run_command(struct m
in_be32(&lbc->fbar), in_be32(&lbc->fpar),
in_be32(&lbc->fbcr), priv->bank);
+ ctrl->irq_status = 0;
/* execute special operation */
out_be32(&lbc->lsor, priv->bank);
/* wait for FCM complete flag or timeout */
- ctrl->irq_status = 0;
wait_event_timeout(ctrl->irq_wait, ctrl->irq_status,
- FCM_TIMEOUT_MSECS * HZ/1000);
+ (FCM_TIMEOUT_MSECS * HZ)/1000);
ctrl->status = ctrl->irq_status;
/* store mdr value in case it was needed */
@@ -861,7 +861,7 @@ static int fsl_elbc_chip_init_tail(struc
/* adjust Option Register and ECC to match Flash page size
*/
if (mtd->writesize == 512) {
priv->page_size = 0;
- clrbits32(&lbc->bank[priv->bank].or,
~OR_FCM_PGS);
+ clrbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
} else if (mtd->writesize == 2048) {
priv->page_size = 1;
setbits32(&lbc->bank[priv->bank].or,
OR_FCM_PGS);
@@ -882,11 +882,6 @@ static int fsl_elbc_chip_init_tail(struc
return -1;
}
- /* The default u-boot configuration on MPC8313ERDB causes
errors;
- * more delay is needed. This should be safe for other
boards
- * as well.
- */
- setbits32(&lbc->bank[priv->bank].or, 0x70);
return 0;
}
[-- Attachment #2: Type: text/html, Size: 15881 bytes --]
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Olaf Hering @ 2008-03-19 15:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080317195305.GA13298@aepfle.de>
On Mon, Mar 17, Olaf Hering wrote:
> The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> ipic_init() fails. init_ipic_sysfs() will crash in that case.
>
> Something like this may fix it:
>
> Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
> ===================================================================
> --- linux-2.6.25-rc6.orig/arch/powerpc/sysdev/ipic.c
> +++ linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
> @@ -906,7 +906,7 @@ static int __init init_ipic_sysfs(void)
> {
> int rc;
>
> - if (!primary_ipic->regs)
> + if (!primary_ipic || !primary_ipic->regs)
> return -ENODEV;
> printk(KERN_DEBUG "Registering ipic with sysfs...\n");
ipic_init() is not called for every board.
This change for the used config fixes the crash as well.
@@ -168,14 +168,14 @@ CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_PPC_86xx is not set
CONFIG_CLASSIC32=y
CONFIG_PPC_CHRP=y
-CONFIG_PPC_MPC512x=y
-CONFIG_PPC_MPC5121=y
-CONFIG_MPC5121_ADS=y
+# CONFIG_PPC_MPC512x is not set
+# CONFIG_PPC_MPC5121 is not set
+# CONFIG_MPC5121_ADS is not set
CONFIG_PPC_MPC52xx=y
-CONFIG_PPC_MPC5200_SIMPLE=y
+# CONFIG_PPC_MPC5200_SIMPLE is not set
CONFIG_PPC_EFIKA=y
# CONFIG_PPC_LITE5200 is not set
-CONFIG_PPC_MPC5200_BUGFIX=y
+# CONFIG_PPC_MPC5200_BUGFIX is not set
CONFIG_PPC_PMAC=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
^ permalink raw reply
* RE: Uart(lite)/ELDK 4.1 section mismatch -> ML403
From: John Linn @ 2008-03-19 14:36 UTC (permalink / raw)
To: Rob Schalken, linuxppc-embedded
In-Reply-To: <2516330804619D4EA81F9AC9ACE9D874341E39@ADCSVR.adc.arcobel.nl>
[-- Attachment #1: Type: text/plain, Size: 3706 bytes --]
Hi Rob,
It sounds like your xparameters*.h with the #defines for the device
addresses is right for the uart as the bootstrap loader is working.
I don't believe early boot works was my experience with it.
What messages did you see in the __log_bug as this is the best tool, is
it booting all the way without a console or crashing during boot when it
tries to start the console?
Make sure the #define XPAR_DDR_0_SIZE 0x4000000 is in the
xparameters_ml403.h. It it's wrong the kernel will crash quickly based
on my experience.
Xilinx has a git server that I have been working on updating, not sure
how many changes there are in our git server as opposed to what you
have. I have been testing arch/ppc with the ML405 which is the same as
the ML403 except a larger FPGA, but my testing has been with the 550
UART as the default. I realize it's a tangent, but you can pull from
our server if you want as I know the state of it
(git://git.xilinx.com/linux-2.6-xlnx.git).
Thanks
John Linn
________________________________
From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
Behalf Of Rob Schalken
Sent: Wednesday, March 19, 2008 8:02 AM
To: linuxppc-embedded@ozlabs.org
Subject: Uart(lite)/ELDK 4.1 section mismatch -> ML403
I want to Port the Linux 2.6.24.3 to the ML403 board. I tried some
different configurations:
**UartLite
After changing some defines and creating some symbolic link, the simple
boot loader seems to
Work. My kernel also starts because when I read the memory (using XMD),
I could read the _log_buf and
Some information was put in. I used the kernel command line:
console=ttyUL0 ip=off root=/dev/ram rw.
But I did not get any kernel message on my serial console! When I
enabled the early boot text over
Serial port, the compiler gives some errors (gen550_init, RS_TABLE_SIZE,
etc.)!
**16550 Uart
After my disaster with the Uartlite, I started to use the 16550 uart.
But I immediately get the following
Error:
arch/ppc/boot/common/ns16550.c:22: error: 'RS_TABLE_SIZE' undeclared
here (not in a function)
arch/ppc/boot/common/ns16550.c:24: error: 'SERIAL_PORT_DFNS' undeclared
here (not in a function)
make[2]: *** [arch/ppc/boot/common/ns16550.o] Error 1
make[1]: *** [arch/ppc/boot/common] Error 2
make: *** [zImage] Error 2
I use ELDK 4.1 toolchain, which result in the following section mismatch
(warning)
WARNING: vmlinux.o(.text+0x223c): Section mismatch: reference to
.init.text:earl y_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2254): Section mismatch: reference to
.init.text:mach ine_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2258): Section mismatch: reference to
.init.text:MMU_ init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b2): Section mismatch: reference to
.init.text:star t_kernel (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b6): Section mismatch: reference to
.init.text:star t_kernel (between 'start_here' and 'initial_mmu')
By the way, the hardware is working, this has been tested!!
Could someone help to get a uart work! I only want to receive a message
from the kernel!!!!
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 18550 bytes --]
^ permalink raw reply
* Uart(lite)/ELDK 4.1 section mismatch -> ML403
From: Rob Schalken @ 2008-03-19 14:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]
I want to Port the Linux 2.6.24.3 to the ML403 board. I tried some
different configurations:
**UartLite
After changing some defines and creating some symbolic link, the simple
boot loader seems to
Work. My kernel also starts because when I read the memory (using XMD),
I could read the _log_buf and
Some information was put in. I used the kernel command line:
console=ttyUL0 ip=off root=/dev/ram rw.
But I did not get any kernel message on my serial console! When I
enabled the early boot text over
Serial port, the compiler gives some errors (gen550_init, RS_TABLE_SIZE,
etc.)!
**16550 Uart
After my disaster with the Uartlite, I started to use the 16550 uart.
But I immediately get the following
Error:
arch/ppc/boot/common/ns16550.c:22: error: 'RS_TABLE_SIZE' undeclared
here (not in a function)
arch/ppc/boot/common/ns16550.c:24: error: 'SERIAL_PORT_DFNS' undeclared
here (not in a function)
make[2]: *** [arch/ppc/boot/common/ns16550.o] Error 1
make[1]: *** [arch/ppc/boot/common] Error 2
make: *** [zImage] Error 2
I use ELDK 4.1 toolchain, which result in the following section mismatch
(warning)
WARNING: vmlinux.o(.text+0x223c): Section mismatch: reference to
.init.text:earl y_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2254): Section mismatch: reference to
.init.text:mach ine_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2258): Section mismatch: reference to
.init.text:MMU_ init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b2): Section mismatch: reference to
.init.text:star t_kernel (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b6): Section mismatch: reference to
.init.text:star t_kernel (between 'start_here' and 'initial_mmu')
By the way, the hardware is working, this has been tested!!
Could someone help to get a uart work! I only want to receive a message
from the kernel!!!!
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 7293 bytes --]
^ permalink raw reply
* RE: [PATCH] [POWERPC] Xilinx: Serial: Adding 8250 console support to OFserial (resolve)
From: John Linn @ 2008-03-19 13:54 UTC (permalink / raw)
To: linuxppc-dev, jwboyer
In-Reply-To: <20080317190924.3B2C0A4807A@mail109-dub.bigfish.com>
Thru more console debugging, I have found the real problem that kept the
OF console from working with the 8250.
It was a combination of the broken bootstrap loader with the 16550
together with reg-shift not being pulled from the OF device tree in the
of_serial.c and the base address of the device needing to be +3 due to
the reg-shift.
I believe there's been a patch for the reg-shift not being pulled from
the OF device tree in of_serial.c and I'll check on that.
Bottom line: this patch is not needed I believe. Thanks for the
patience as I learn how the console works as it's definitely tough to
get the hang of.
-- John
-----Original Message-----
From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org] On =
Behalf
Of John Linn
Sent: Monday, March 17, 2008 1:09 PM
To: linuxppc-dev@ozlabs.org; jwboyer@linux.vnet.ibm.com
Cc: John Linn
Subject: [PATCH] [POWERPC] Xilinx: Serial: Adding 8250 console support
to OFserial
This change adds code to serial_of.c to support the 8250 console.
Initialization was added to get the UART data from the device tree
and setup the UART and console for the 8250.
The cmd line was not being used for the baud rate and is still not
being used as the speed for the uart is being pulled from the UART
properties in the device tree. The input clock frequency for the
UART must be specified in the device tree so the baud rate generator
can be setup.
<Signed-off-by: John Linn <john.linn@xilinx.com>
---
Please pull this patch for 2.6.26.
---
drivers/serial/8250.c | 20 ++++++--
drivers/serial/of_serial.c | 128
++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 144 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..7b32af1 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2366,7 +2366,7 @@ serial8250_type(struct uart_port *port)
return uart_config[type].name;
}
=20
-static struct uart_ops serial8250_pops =3D {
+struct uart_ops serial8250_pops =3D {
.tx_empty =3D serial8250_tx_empty,
.set_mctrl =3D serial8250_set_mctrl,
.get_mctrl =3D serial8250_get_mctrl,
@@ -2519,10 +2519,13 @@ serial8250_console_write(struct console *co,
const char *s, unsigned int count)
static int __init serial8250_console_setup(struct console *co, char
*options)
{
struct uart_port *port;
+
+#ifndef CONFIG_SERIAL_OF_PLATFORM
int baud =3D 9600;
int bits =3D 8;
int parity =3D 'n';
int flow =3D 'n';
+#endif
=20
/*
* Check whether an invalid uart number has been specified, and
@@ -2535,10 +2538,13 @@ static int __init
serial8250_console_setup(struct console *co, char *options)
if (!port->iobase && !port->membase)
return -ENODEV;
=20
+#ifndef CONFIG_SERIAL_OF_PLATFORM
if (options)
uart_parse_options(options, &baud, &parity, &bits,
&flow);
-
return uart_set_options(port, co, baud, parity, bits, flow);
+#else
+ return 0;
+#endif
}
=20
static int serial8250_console_early_setup(void)
@@ -2547,7 +2553,7 @@ static int serial8250_console_early_setup(void)
}
=20
static struct uart_driver serial8250_reg;
-static struct console serial8250_console =3D {
+struct console serial8250_console =3D {
.name =3D "ttyS",
.write =3D serial8250_console_write,
.device =3D uart_console_device,
@@ -2558,13 +2564,19 @@ static struct console serial8250_console =3D {
.data =3D &serial8250_reg,
};
=20
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
{
serial8250_isa_init_ports();
register_console(&serial8250_console);
return 0;
}
+
+/* when OF is being used with the 8250 console, the OF hooks in the=20
+ 8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) &&
!defined(CONFIG_SERIAL_OF_PLATFORM)
console_initcall(serial8250_console_init);
+#endif
=20
int serial8250_find_port(struct uart_port *p)
{
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..eed245a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
#include <linux/module.h>
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
+#include <linux/console.h>
=20
#include <asm/of_platform.h>
#include <asm/prom.h>
+#include <asm/io.h>
=20
struct of_serial_info {
int type;
@@ -158,6 +160,132 @@ static void __exit of_platform_serial_exit(void)
};
module_exit(of_platform_serial_exit);
=20
+#if defined(CONFIG_SERIAL_8250_CONSOLE)
+
+/* when an 8250 console is being used and OF, the OF needs to
+ setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int early_serial_console_setup(struct uart_port *);
+extern struct uart_ops serial8250_pops;
+
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] =3D {
+ { .type =3D "serial", .compatible =3D "ns16550", },
+ {},
+};
+
+static unsigned int *spd;
+
+/*
+ * Setup the uart based on OF properties
+ */
+static int __init uart_of_setup(struct device_node *np,
+ struct uart_port *port)
+{
+ struct resource resource;
+ const unsigned int *clk, *regshift;
+ int ret;
+
+ memset(port, 0, sizeof *port);
+ spd =3D of_get_property(np, "current-speed", NULL);
+ regshift =3D of_get_property(np, "reg-shift", NULL);
+ clk =3D of_get_property(np, "clock-frequency", NULL);
+ if (!clk) {
+ return -ENODEV;
+ }
+
+ ret =3D of_address_to_resource(np, 0, &resource);
+ if (ret) {
+ return ret;
+ }
+
+ spin_lock_init(&port->lock);
+ port->irq =3D irq_of_parse_and_map(np, 0);
+ port->iotype =3D UPIO_MEM;
+ port->type =3D PORT_16550;
+ port->uartclk =3D *clk;
+ port->flags =3D UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
+ | UPF_FIXED_PORT;
+ if (!spd)
+ *spd =3D 9600;
+ =09
+ port->custom_divisor =3D *clk / (16 * (*spd));
+
+ if (regshift) {
+ port->regshift =3D *regshift;
+ port->mapbase =3D resource.start + ((1 << *regshift) - 1);
+ } else {
+ port->mapbase =3D resource.start;
+ }
+ return 0;
+}
+
+static struct device_node __init *console_of_find_device(int id)
+{
+ struct device_node *np;
+ const struct of_device_id *matches =3D uart_of_match;
+
+ while (matches->compatible[0]) {
+ for_each_compatible_node(np, NULL, matches->compatible)
{
+ if (!of_match_node(matches, np))
+ continue;
+
+ of_node_put(np);
+ return np;
+ }
+ matches++;
+ }
+ return 0;
+}
+
+static int __init console_setup(struct console *co)
+{
+ struct device_node *np;
+ int bits =3D 8;
+ int parity =3D 'n';
+ int flow =3D 'n';
+
+ /* Find a matching uart port in the device tree */
+ np =3D console_of_find_device(co->index);
+ if (!np)
+ return -ENODEV;
+ =09
+ if (uart_of_setup(np, &of_uart_port))
+ return -ENODEV;
+
+ /* registers mapped yet? */
+ if (!of_uart_port.membase) {
+ of_uart_port.membase =3D ioremap(of_uart_port.mapbase,
64);
+ if (!of_uart_port.membase)
+ return -ENODEV;
+ }
+
+ of_uart_port.ops =3D &serial8250_pops;
+ uart_set_options(&of_uart_port, co, *spd, parity, bits, flow);
+
+ return 0;
+}
+
+/* This function sets up the 8250 console by getting the OF data at=20
+ console init time and then setting up the 8250 uart and console.=20
+ This solves the problem of the OF uart not being setup in time=20
+ for the 8250 console to use it.
+*/
+static int __init of_console_init(void)
+{
+ if (!console_setup(&serial8250_console)) {
+ early_serial_setup(&of_uart_port);=09
+ serial8250_console_init();=09
+ }
+ return 0;
+}
+
+console_initcall(of_console_init);
+#endif
+
MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Serial Port driver for Open Firmware platform
devices");
--=20
1.5.2.1
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply related
* RE: Kernel stack overflow in process xxxx
From: jay_chen @ 2008-03-19 12:59 UTC (permalink / raw)
To: 'Nicholas Mc Guire'; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.58.0803180908270.1963@vlab.hofr.at>
Hi,
My kernel version is 2.6.14.5
I don't see these options.
Jay...
-----Original Message-----
From: Nicholas Mc Guire [mailto:hofrat@hofr.at]
Sent: Wednesday, March 19, 2008 2:13 AM
To: jay_chen
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: Kernel stack overflow in process xxxx
> By the way, is there any skill/tool to avoid/detect/check this kind of
> problem?
>
did you try:
Kernel hacking --->
...
[*] Kernel debugging
...
[*] Check for stack overflows
[*] Stack utilization instrumentation
the last one depends on SysRq though.
In any case it would be interesting to know if these tools can help find
problems of this kind - so if it does not help - pleas let me/us know.
hofrat
^ permalink raw reply
* [PATCH] ehea: Fix IPv6 support
From: Thomas Klein @ 2008-03-19 12:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, Hannes Hering, linux-kernel, linux-ppc,
Christoph Raisch, Stefan Roscher
Indicate that HEA calculates IPv4 checksums only
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.25-rc6/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.25-rc6/drivers/net/ehea/ehea.h 2008-03-17 00:32:14.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-03-19 08:58:07.000000000 +0100
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0087"
+#define DRV_VERSION "EHEA_0089"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.25-rc6/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.25-rc6/drivers/net/ehea/ehea_main.c 2008-03-17 00:32:14.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-03-19 08:58:07.000000000 +0100
@@ -3108,7 +3108,7 @@ struct ehea_port *ehea_setup_single_port
dev->vlan_rx_add_vid = ehea_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ehea_vlan_rx_kill_vid;
dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO
- | NETIF_F_HIGHDMA | NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_TX
+ | NETIF_F_HIGHDMA | NETIF_F_IP_CSUM | NETIF_F_HW_VLAN_TX
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->tx_timeout = &ehea_tx_watchdog;
^ permalink raw reply
* Carol Dann is out of the office.
From: Sheau-Jiuan Dann @ 2008-03-19 8:01 UTC (permalink / raw)
To: linuxppc-dev
I will be out of the office starting 03/19/2008 and will not return
until 03/22/2008.
Should you need any assistance on RS6000/AIX/TSM , please contact :
Mr. Obaid Farghani at 201-413-8028 (ofarghani@us.mufg.jp), Mr. Paul
Giglio at 201-413-8280 (pgiglio@us.mufg.jp) or Mr. Gary Fatone at
201-413-8955 (gfatone@us.mufg.jp )
I will respond to your message when I return.
Regards,
Carol
-----------------------------------------
This electronic mail message, and any of the accompanying
documents, may contain confidential or privileged information. Any
unauthorized disclosure or distribution of such information is
strictly prohibited. If you are not the intended recipient of this
message, please notify the sender immediately and destroy the
message. Messages sent through electronic media may be subject to
delays or unauthorized alterations. Neither The Bank of
Tokyo-Mitsubishi UFJ, Ltd. nor any of its affiliates is responsible
for any such delay or alteration. This message may contain a
commercial advertisement or promotion of a commercial product or
service. If you do not wish to receive messages of this kind from
the sender in the future, please reply to this message and type
"REMOVE MY EMAIL ADDRESS" in the subject field, or write to the
sender at 1251 Avenue of the Americas, New York, NY 10020-1104.
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Heiko Schocher @ 2008-03-19 6:51 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Scott Wood, Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080318191918.6505ba41@kernel.crashing.org>
Hello Vitaly,
Vitaly Bordug wrote:
> On Tue, 18 Mar 2008 09:04:14 +0100
> Heiko Schocher wrote:
[...]
>> OK. Another thought about this. Shouldnt this table go in the dts?
>> A device node like
>>
>> cpm_pin {
>> pins = <port pin flags>;
>> };
>>
>> would be nice, or?
>>
> This has been a disputable question some time ago, and decided (or it looks like decided) that devtree describes hardware, and not the way it is configured at the moment. Therefor, best way for pin stuff is considered, as Scott mentioned, to set up stuff inside the firmware.
OK, I dont want to start a new discusion about that, but I always thought
(maybe learned, not sure anymore ;-) Linux should be as much independent
as possible from the bootloader(=firmware). If the firmware doesnt make
things right Linux maybe hang ... :-(
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Stefan Roese @ 2008-03-19 6:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <23bc1271d080c41ab54a4917d256a76b@kernel.crashing.org>
On Tuesday 18 March 2008, Segher Boessenkool wrote:
> > + L2C0: l2c@30 {
> > + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> > + dcr-reg = <20 8 /* Internal SRAM DCR's */
> > + 30 8>; /* L2 cache DCR's */
>
> The unit address is based on the _first_ entry in "reg".
I'll remove the unit address.
> No2 this
> is "dcr-reg", but you don't really want to be more incompatible than
> necessary...
Sorry, I'm not sure what you're trying to tell me here.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Stefan Roese @ 2008-03-19 6:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080318232418.GA3323@localhost.localdomain>
On Wednesday 19 March 2008, David Gibson wrote:
> On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
> > This patch adds the L2 cache node to the Taishan 440GX dts file.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > arch/powerpc/boot/dts/taishan.dts | 10 ++++++++++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/taishan.dts
> > b/arch/powerpc/boot/dts/taishan.dts index 8278068..d0bff33 100644
> > --- a/arch/powerpc/boot/dts/taishan.dts
> > +++ b/arch/powerpc/boot/dts/taishan.dts
> > @@ -104,6 +104,16 @@
> > // FIXME: anything else?
> > };
> >
> > + L2C0: l2c@30 {
>
> A node with no reg property shouldn't have a unit address.
OK, I'll remove the unit address.
> > + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> > + dcr-reg = <20 8 /* Internal SRAM DCR's */
> > + 30 8>; /* L2 cache DCR's */
> > + cache-line-size = <20>; /* 32 bytes */
> > + cache-size = <40000>; /* L2, 256K */
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <17 1>;
> > + };
>
> Now.. usually cache nodes are given as descendents of the CPU node.
> In this case you have the DCR control registers though, so I guess
> this is representing a control interface rather than the cache
> itself. Hrm.. not really sure how to do this.
So should I change the location then?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] Hide resources on Axon PCIE root complex nodes
From: Benjamin Herrenschmidt @ 2008-03-19 6:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <62a10dda33b8e6b790f13057daea1430ed81ef1c.1205907051.git.michael@ellerman.id.au>
On Wed, 2008-03-19 at 17:10 +1100, Michael Ellerman wrote:
> The PCI bridge representing the PCIE root complex on Axon, contains device
> BARs for a memory range and ROM that define inbound accesses. This confuses
> the kernel resource management code, the resources need to be hidden when
> Axon is a host bridge.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* [PATCH] Hide resources on Axon PCIE root complex nodes
From: Michael Ellerman @ 2008-03-19 6:10 UTC (permalink / raw)
To: linuxppc-dev
The PCI bridge representing the PCIE root complex on Axon, contains device
BARs for a memory range and ROM that define inbound accesses. This confuses
the kernel resource management code, the resources need to be hidden when
Axon is a host bridge.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/setup.c | 36 +++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index dda3465..5c531e8 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -81,6 +81,42 @@ static void cell_progress(char *s, unsigned short hex)
printk("*** %04x : %s\n", hex, s ? s : "");
}
+static void cell_fixup_pcie_rootcomplex(struct pci_dev *dev)
+{
+ struct pci_controller *hose;
+ const char *s;
+ int i;
+
+ if (!machine_is(cell))
+ return;
+
+ /* We're searching for a direct child of the PHB */
+ if (dev->bus->self != NULL || dev->devfn != 0)
+ return;
+
+ hose = pci_bus_to_host(dev->bus);
+ if (hose == NULL)
+ return;
+
+ /* Only on PCIE */
+ if (!of_device_is_compatible(hose->dn, "pciex"))
+ return;
+
+ /* And only on axon */
+ s = of_get_property(hose->dn, "model", NULL);
+ if (!s || strcmp(s, "Axon") != 0)
+ return;
+
+ for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
+ dev->resource[i].start = dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+
+ printk(KERN_DEBUG "PCI: Hiding resources on Axon PCIE RC %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, cell_fixup_pcie_rootcomplex);
+
static int __init cell_publish_devices(void)
{
int node;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [Fwd: [Cbe-oss-dev] [PATCH] Fix cell IOMMU code to cope with empty dma-ranges, and non-PCI devices]
From: Michael Ellerman @ 2008-03-19 6:10 UTC (permalink / raw)
To: linuxppc-dev list
-------- Forwarded Message --------
From: Michael Ellerman <michael@ellerman.id.au>
To: Paul Mackerras <paulus@samba.org>
Cc: cbe-oss-dev@ozlabs.org
Subject: [Cbe-oss-dev] [PATCH] Fix cell IOMMU code to cope with empty
dma-ranges, and non-PCI devices
Date: Fri, 14 Mar 2008 16:47:39 +1100 (EST)
The cell IOMMU code to parse the dma-ranges properties, used for the fixed
mapping, was broken in two ways for some devices.
Firstly it didn't cope with empty dma-ranges properties. An empty property
implies no translation so can be safely skipped.
The code also wrongly assumed it would be looking at PCI devices, and hard
coded the address cells and size cells.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 41 +++++++++++++++++++++-------------
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 20ea0e1..d75ccde 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -802,17 +802,24 @@ static int __init cell_iommu_init_disabled(void)
static u64 cell_iommu_get_fixed_address(struct device *dev)
{
- u64 cpu_addr, size, best_size, pci_addr = OF_BAD_ADDR;
+ u64 cpu_addr, size, best_size, dev_addr = OF_BAD_ADDR;
struct device_node *np;
const u32 *ranges = NULL;
- int i, len, best;
+ int i, len, best, naddr, nsize, pna, range_size;
np = of_node_get(dev->archdata.of_node);
- while (np) {
+ while (1) {
+ naddr = of_n_addr_cells(np);
+ nsize = of_n_size_cells(np);
+ np = of_get_next_parent(np);
+ if (!np)
+ break;
+
ranges = of_get_property(np, "dma-ranges", &len);
- if (ranges)
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
break;
- np = of_get_next_parent(np);
}
if (!ranges) {
@@ -822,15 +829,17 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)
len /= sizeof(u32);
+ pna = of_n_addr_cells(np);
+ range_size = naddr + nsize + pna;
+
/* dma-ranges format:
- * 1 cell: pci space
- * 2 cells: pci address
- * 2 cells: parent address
- * 2 cells: size
+ * child addr : naddr cells
+ * parent addr : pna cells
+ * size : nsize cells
*/
- for (i = 0, best = -1, best_size = 0; i < len; i += 7) {
- cpu_addr = of_translate_dma_address(np, ranges +i + 3);
- size = of_read_number(ranges + i + 5, 2);
+ for (i = 0, best = -1, best_size = 0; i < len; i += range_size) {
+ cpu_addr = of_translate_dma_address(np, ranges + i + naddr);
+ size = of_read_number(ranges + i + naddr + pna, nsize);
if (cpu_addr == 0 && size > best_size) {
best = i;
@@ -838,15 +847,15 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)
}
}
- if (best >= 0)
- pci_addr = of_read_number(ranges + best + 1, 2);
- else
+ if (best >= 0) {
+ dev_addr = of_read_number(ranges + best, naddr);
+ } else
dev_dbg(dev, "iommu: no suitable range found!\n");
out:
of_node_put(np);
- return pci_addr;
+ return dev_addr;
}
static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
^ permalink raw reply related
* Re: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-19 5:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <16089631.post@talk.nabble.com>
Hi,All
I found out what the problem was from.
When i set the Bus clock frequency to 50MHz and Processor clock Frequency
200MHz, opb_ethernet does not work with the driver.
And i check the driver,don't find the code base on the frequency . Anyone
knows the reason?
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16137363.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox