* [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
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-19 5:26 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080317195305.GA13298@aepfle.de>
Olaf Hering writes:
> I cant reproduce this bug on my board, but:
>
> 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:
Is this needed for 2.6.25? Is the system at all usable if ipic_init
fails?
Paul.
^ permalink raw reply
* Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Grant Likely @ 2008-03-19 5:05 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080319043205.12E1F11E0071@mail67-dub.bigfish.com>
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.
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. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer @ 2008-03-19 4:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803182115k241050f0meafccc29b4ef16@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3322 bytes --]
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.
I do dislike the hodgepodge of different configuration dependencies (such as Sysace)... It makes sense to me to have them be uniformly available. If they are all going to be PPC32 || microblaze, then it seems to me like there should be an intermediate configuration option that expresses exactly that set.
Would you feel differently if we flipped the dependencies around, like XILINX_DRIVERS depends on PPC32 || MICROBLAZE?
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Tue 3/18/2008 9:15 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.
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> 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>
>
> ---
>
> Grant,
>
> This is the patch, updated for all of the drivers that I think are in
> the tree. I think the problematic parts may be 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.
>
> It may also be better to clean up the Kconfig lines for Sysace and
> framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS.
> My understanding is that those config options are there because of
> people using external PPCs with those devices in the FPGA.
Hey Steve;
I haven't forgotten about this patch, but I've been thinking about it
some more and I'm coming to the conclusion that it might just be
better to eliminate driver dependence on XILINX_DRIVERS and
XILINX_VIRTEX entirely and instead just make each of them "depends on
PPC32 || MICROBLAZE". There's no reason to restrict compiling these
drivers to platforms that are known to have xilinx parts on them.
I know that in most cases they will not be used, but by relaxing the
dependencies they will get compile tested on more platforms than they
are now and they'll get picked up for make allyesconfigs builds. In
my mind this means greater chances of compile bugs getting found and
reported.
In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency
too; but I think the drivers are using io primitives at the moment
that are not portable to x86.
Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[-- Attachment #2: Type: text/html, Size: 4229 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Grant Likely @ 2008-03-19 4:15 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080212213120.D51157F806B@mail176-sin.bigfish.com>
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> 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>
>
> ---
>
> Grant,
>
> This is the patch, updated for all of the drivers that I think are in
> the tree. I think the problematic parts may be 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.
>
> It may also be better to clean up the Kconfig lines for Sysace and
> framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS.
> My understanding is that those config options are there because of
> people using external PPCs with those devices in the FPGA.
Hey Steve;
I haven't forgotten about this patch, but I've been thinking about it
some more and I'm coming to the conclusion that it might just be
better to eliminate driver dependence on XILINX_DRIVERS and
XILINX_VIRTEX entirely and instead just make each of them "depends on
PPC32 || MICROBLAZE". There's no reason to restrict compiling these
drivers to platforms that are known to have xilinx parts on them.
I know that in most cases they will not be used, but by relaxing the
dependencies they will get compile tested on more platforms than they
are now and they'll get picked up for make allyesconfigs builds. In
my mind this means greater chances of compile bugs getting found and
reported.
In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency
too; but I think the drivers are using io primitives at the moment
that are not portable to x86.
Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Paul Mackerras @ 2008-03-19 3:57 UTC (permalink / raw)
To: skumar; +Cc: Poornima Nayak, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080318052921.GA32259@in.ibm.com>
Sudhir Kumar writes:
> Unable to handle kernel paging request for data at address
> 0xd00008000000002e
Looks like some driver tried to access I/O port 0x2e without checking
whether there was possibly anything there first.
> Faulting instruction address: 0xc00000000074ded8
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
> enter ? for help
> [c00000003e073dc0] c00000000074e1f8 .f71805f_init+0x38/0x194
Looks like it might be the f71805f driver, whatever that is...
Hmmm, drivers/hwmon/f71805f.c looks like it, and indeed it does go
poking around in PCI I/O space with no checks whatever.
I suggest you turn off CONFIG_SENSORS_F71805F.
It doesn't help, of course, that CONFIG_HWMON defaults to y. :(
Paul.
^ permalink raw reply
* Re: Hi,friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-19 1:22 UTC (permalink / raw)
To: Scott Wood; +Cc: u-boot-users, linuxppc-embedded
Hi,Scott
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.
If I fill the frequency to zero on mpc836x_mds.dts, then the linux-2.6.22 is
crashed, the output of serial is nothing. if I fill the right frequency value same
as the HRCW on mpc836x_mds.dts, the linux is normal. So I think if the frequency
is zero on mpc836x_mds.dts, the u-boot did not pass the right frequency value to
dtb.
I think maybe that we need to define some on u-boot, then the u-boot can pass the
parameter to linux dtb?
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.
Thank you very much.
>From: Scott Wood <scottwood@freescale.com>
>Reply-To:
>To: <guojin02@tsinghua.org.cn>
>Subject: Re: Hi,friends, the question about the u-boot and device tree?
>Date:Tue, 18 Mar 2008 13:28:41 -0500
>
>On Thu, Mar 13, 2008 at 11:31:11PM +0800, wrote:
>> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency)
value
>> on device tree file equal to zero, I think those frequency will filled by
u-boot
>> during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
>> crashed. Why?
>
>What board? Are you using a device-tree-aware u-boot and the three-argument
>form of bootm? What sort of crash? How do you know it's not filling in the
>frequencies?
>
>> Why so many document point out that the zero value will be filled by u-boot?
>
>Because it does. :-)
>If it's not doing so on your board, that needs to be fixed.
>
>-Scott
>
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: David Gibson @ 2008-03-18 23:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847466-17854-1-git-send-email-sr@denx.de>
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.
> + 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.
--
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
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