* Re: emac/zmii link warnings
From: Sean MacLennan @ 2008-01-15 4:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115152748.d0a05e1b.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> I keep getting these link(?) warnings:
>>
>> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>>
>
> emac_of_bus_notify is marked __devinit and is referred to by
> emac_of_bus_notifier (which is not marked thus) (in
> drivers/net/ibm_newemac/core.c).
>
Adding the __devinit to emacs_of_bus_notifier causes a problem with
emac_phy_map_lock (a mutex). But removing the __devinit from
emac_of_bus_notify cleans up that warning. Is the __devinit really
necessary?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-15 5:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <478BC05C.2080007@pikatech.com>
On Monday 14 January 2008, Sean MacLennan wrote:
> Stefan Roese wrote:
> > And the EBC0_BxCR & EBC0BxAP registers for the CS where the NAND is
> > connected? How are they configured?
>
> EBC0_B1CR d001c000
> EBC0_B1AP 18003c0
>
> Which matches the defines in include/configs/warp.h:
>
> #define CFG_EBC_PB1AP 0x018003c0
> #define CFG_EBC_PB1CR (CFG_NAND_ADDR | 0x1c000)
>
> It also matches the defines in sequoia.h except that we are on CS1 and
> the sequoia is on CS3.
Right. One thing I noticed though is, that you map the NAND to 0xd0000000,
which is reserved for PCI in the 440EP address space. I suggest you map it to
0x90000000 as done on Bamboo. Please give it a try and let me know if this
changes the 32bit access behavior.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Kumar Gala @ 2008-01-15 5:22 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080114000113.GA14801@localhost.localdomain>
On Jan 13, 2008, at 6:01 PM, David Gibson wrote:
> On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> [snip]
>> + aliases {
>> + console = &console;
>> + enet0 = ð0;
>> + enet1 = ð1;
>
> I think most other boards are settling on aliases "ethernet0"
> etc. instead of "enet0" (though there's no reason you couldn't have
> both.
We should use ethernet0 since its based on the standard naming
convention.
- k
^ permalink raw reply
* Re: emac/zmii link warnings
From: Stephen Rothwell @ 2008-01-15 5:26 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478C3A5D.5080209@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Mon, 14 Jan 2008 23:45:17 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> Stephen Rothwell wrote:
> > On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
> >
> >> I keep getting these link(?) warnings:
> >>
> >> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>
> > emac_of_bus_notify is marked __devinit and is referred to by
> > emac_of_bus_notifier (which is not marked thus) (in
> > drivers/net/ibm_newemac/core.c).
>
> Adding the __devinit to emacs_of_bus_notifier causes a problem with
> emac_phy_map_lock (a mutex). But removing the __devinit from
> emac_of_bus_notify cleans up that warning. Is the __devinit really
> necessary?
What problem do you get. The correct fix is to mark emac_of_bus_notifier
as __devinitdata. The __devinit marking of emac_of_bus_notify is not
strictly necessary, but some people care about the size of their kernels.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: emac/zmii link warnings
From: Sean MacLennan @ 2008-01-15 5:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115152748.d0a05e1b.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> I keep getting these link(?) warnings:
>>
>> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>>
>
> emac_of_bus_notify is marked __devinit and is referred to by
> emac_of_bus_notifier (which is not marked thus) (in
> drivers/net/ibm_newemac/core.c).
>
>
The __devinitdata solves this.
>> WARNING: vmlinux.o(.init.text+0x16ba8): Section mismatch: reference to .exit.text:zmii_detach (between 'emac_probe' and 'zmii_probe')
>> WARNING: vmlinux.o(.init.text+0x16bb4): Section mismatch: reference to .exit.text:mal_unregister_commac (between 'emac_probe' and 'zmii_probe')
>>
>
> These will be similar but function calls.
>
>
The problem here is that emac_probe calls zmii_detach. emacs_probe is a
__devinit and zmii_detach is a __devexit. At least I assume that is the
problem.
I am a long time emacs (actually xemacs) user. If I had a nickel for
every time I typed emacs rather than emac, I would be a very rich man.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-15 6:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801150615.19910.sr@denx.de>
Stefan Roese wrote:
>
> Right. One thing I noticed though is, that you map the NAND to 0xd0000000,
> which is reserved for PCI in the 440EP address space. I suggest you map it to
> 0x90000000 as done on Bamboo. Please give it a try and let me know if this
> changes the 32bit access behavior.
>
I think I changed it right. The following code is obviously a hack:
static int warp_setup_nand_flash(void)
{
unsigned data;
mfebc(0x1, data);
printk("EBC0_B1CR %x\n", data); // SAM DBG
data = 0x9001c000;
mtebc(0x1, data);
mfebc(0x1, data);
printk("after EBC0_B1CR %x\n", data); // SAM DBG
mfebc(0x11, data);
printk("EBC0_B1AP %x\n", data); // SAM DBG
platform_device_register(&warp_ndfc_device);
platform_device_register(&warp_nand_device);
return 0;
}
device_initcall(warp_setup_nand_flash);
Then change the NAND base offset to 90000000. This change made no
difference. It still works with 8-bit access and fails with 32-bit. The
mtebc and mfebc macros where taken from u-boot.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-15 6:39 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478C5309.7040805@pikatech.com>
On Tuesday 15 January 2008, Sean MacLennan wrote:
> Stefan Roese wrote:
> > Right. One thing I noticed though is, that you map the NAND to
> > 0xd0000000, which is reserved for PCI in the 440EP address space. I
> > suggest you map it to 0x90000000 as done on Bamboo. Please give it a try
> > and let me know if this changes the 32bit access behavior.
>
> I think I changed it right. The following code is obviously a hack:
>
> static int warp_setup_nand_flash(void)
> {
> unsigned data;
>
> mfebc(0x1, data);
> printk("EBC0_B1CR %x\n", data); // SAM DBG
>
> data = 0x9001c000;
> mtebc(0x1, data);
>
> mfebc(0x1, data);
> printk("after EBC0_B1CR %x\n", data); // SAM DBG
>
> mfebc(0x11, data);
> printk("EBC0_B1AP %x\n", data); // SAM DBG
>
> platform_device_register(&warp_ndfc_device);
> platform_device_register(&warp_nand_device);
>
> return 0;
> }
> device_initcall(warp_setup_nand_flash);
>
>
> Then change the NAND base offset to 90000000. This change made no
> difference. It still works with 8-bit access and fails with 32-bit. The
> mtebc and mfebc macros where taken from u-boot.
Bummer! Was worth a try though. I still don't see why this should fail on your
platform. What error/exception do you get upon 32bit access btw?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-15 7:09 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 277 +++++++++++++++++++++++++++++++++++
1 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..b8ac021
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,277 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * 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 = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ 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 = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "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-405exr","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-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 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 = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* 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 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Stefan Roese @ 2008-01-15 7:09 UTC (permalink / raw)
To: linuxppc-dev
This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
is a 405EX with only one EMAC and only one PCIe interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/kernel/cputable.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index f1928af..dfb84c8 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1178,8 +1178,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.platform = "ppc405",
},
{ /* 405EX */
- .pvr_mask = 0xffff0000,
- .pvr_value = 0x12910000,
+ .pvr_mask = 0xffff0004,
+ .pvr_value = 0x12910004,
.cpu_name = "405EX",
.cpu_features = CPU_FTRS_40X,
.cpu_user_features = PPC_FEATURE_32 |
@@ -1189,6 +1189,18 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ { /* 405EXr */
+ .pvr_mask = 0xffff0004,
+ .pvr_value = 0x12910000,
+ .cpu_name = "405EXr",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ },
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
--
1.5.4.rc3
^ permalink raw reply related
* Re: Problem booting Linux 2.6 on Virtex-4
From: Enno Lübbers @ 2008-01-15 7:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <440abda90801141614u777edfbndc5d2c61f927dd4f@mail.gmail.com>
Hi David,
Am 15.01.2008 um 01:14 schrieb David Baird:
> Today, I tried a completely fresh design in EDK 9.2i (whereas I had
> been using 9.1i). I tried the design found in
> EDKexamples/Virtex4_PPC_Example_9_2.zip. This design works :-) I am
> not sure why it works (or rather, why the other one did not work), but
> it works.
I'm using EDK 9.1i with the reference design from the Xilinx website (www.xilinx.com/ml403)
. This one is using a PLB BRAM controller for the bootup code section,
not an OCM BRAM. Maybe there's something wrong with the OCM
controller? Though OCM is not cached at all...
Anyway, glad it worked out.
Regards
- Enno
--
Dipl.-Ing. Enno Luebbers
Computer Engineering Group
University of Paderborn
Warburger Str. 100
33098 Paderborn
http://wwwcs.upb.de/cs/ag-platzner
phone: 05251 / 60-5397
fax: 05251 / 60-5377
^ permalink raw reply
* Problems with serial and DHCP when booting from NFS
From: lipeng @ 2008-01-15 8:09 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all,
I am porting a MontaVista Linux for PPC405 and encountering some problems. I hope someone can help me find it out.
1. About the serial port. I have solved this problem, but I don't know why. If I set "Initial Kernel Command String" as "console=ttyS0,19200 ip=on nfsroot=[my_nfsroot] rw", after outputing "Now booting the kernel" in the booting process, the booting kernel seems hanging there. In fact, when I checked the log of DHCP server, I found the PPC had already sent DHCP requests. It can be infered that the kernel had been booted but serial had something wrong, so no other information was output after "Now booting the kernel". If I set "Initial Kernel Command String" as "ip=on nfsroot=[my_nfsroot] rw", the booting information will appear on the terminal window correctly after "Now booting the kernel". I don't know why. I use Uart Lite and the baud rate is 19200.
2. About the DHCP. The kernel is boot from NFS, so I enabled the DHCP. From the information on terminal window, I knew that DHCP requests were always time out and the client kept retrying. But when I checked the log of DHCP server, I found the server had already offered IP to the client kernel. It seems the client kernel has some problem to receive the DHCP offer, has anyone encountered similar problems? How to solve this problem?
Thanks.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-01-15 10:19 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug fixes for powerpc. One is a fix for a recently
introduced regression which means that the kernel doesn't boot on
POWER6 machines. The other is a fix for something that got broken
back in the 2.6.19 timeframe.
Thanks,
Paul.
arch/powerpc/kernel/iommu.c | 17 ++++++++++++++---
arch/powerpc/mm/slb.c | 10 ++--------
arch/powerpc/platforms/pseries/lpar.c | 1 -
include/asm-powerpc/mmu-hash64.h | 1 -
4 files changed, 16 insertions(+), 13 deletions(-)
commit dfbe0d3b6be52596b5694b1bb75b19562e769021
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Jan 15 17:29:33 2008 +1100
[POWERPC] Fix boot failure on POWER6
Commit 473980a99316c0e788bca50996375a2815124ce1 added a call to clear
the SLB shadow buffer before registering it. Unfortunately this means
that we clear out the entries that slb_initialize has previously set in
there. On POWER6, the hypervisor uses the SLB shadow buffer when doing
partition switches, and that means that after the next partition switch,
each non-boot CPU has no SLB entries to map the kernel text and data,
which causes it to crash.
This fixes it by reverting most of 473980a9 and instead clearing the
3rd entry explicitly in slb_initialize. This fixes the problem that
473980a9 was trying to solve, but without breaking POWER6.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d262c32a4bcc3e5fda0325a64e53c25fe1e999d7
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Jan 8 10:34:22 2008 +1100
[POWERPC] Workaround for iommu page alignment
Commit 5d2efba64b231a1733c4048d1708d77e07f26426 changed our iommu code
so that it always uses an iommu page size of 4kB. That means with our
current code, drivers may do a dma_map_sg() of a 64kB page and obtain
a dma_addr_t that is only 4k aligned.
This works fine in most cases except for some infiniband HW it seems,
where they tell the HW about the page size and it ignores the low bits
of the DMA address.
This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
for mappings of objects that are page aligned in the first place and whose
size is larger or equal to a page.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* USB Mass Storare (PCI Based)
From: Ansari @ 2008-01-15 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
Hi,
I want to configure linux kernel for USB Mass Storage device (PCI Based).In that i have few doubts. Can u pls calrify it.
Hardware
---------------
MPC8560 (PCI Host Mode )
MPC8540 (PCI Agent Mode )
ISP1564 (PCI Target - USB Host Controller)
Software
---------------
Uboot 1.1.2
Linux Kernel 2.4.10
Problem
--------------
I am using default pci & usb driver given in uboot and linux kernel.
In my board both MPC8560 (PCI Host), MPC8540 (PCI Agent) should access the ISP1564 USB host controller (PCI Target). All the three PCI devices connected in a single pci bus.
My problem is when i load uboot (with PCI Config) and kernel (with PCI,USB-EHCI,USB Mass storage Config) in MPC8560. Its working properly.
After MPC8560 booted , when i try to load uboot (with PCI support disabled) and kernel (with PCI,USB-EHCI,USB Mass storage Config).
The mass storage is not working in MPC8540 . But its working in MPC8560.
Few oberservation while testing :
1. When i enable PCI support in MPC8540 uboot and not booting kernel. The usb mass storage not working in MPC8560 kernel.
2. When i disable PCI support in MPC8540 uboot and not booting kernel(even if i boot kernel also). The usb mass storage working in MPC8560 kernel.
3. In both the case /proc/bus/pci and /proc/pci not created in MPC8540 kernel.( Note : I have enabled the option of proc file system , virtual file system support in MPC8540 kernel).
Questions
---------------
1. By the above problem defintion can u able to guess . Wht would be the problem ???
2. Why proc entry for pci is not created in MPC8540 kernel ??? . Whether PCI agent mode has any impact on it.??
3. Whether any special changes required in pci uboot/kernel driver of MPC8540. Since PCI of MPC8540 is in Agent Mode.
4. Whether any special changes required in USB kernel driver of MPC8540. Since PCI of MPC8540 is in Agent Mode.
Thanks in Advance
Regards
Haroun Ansari
[-- Attachment #2: Type: text/html, Size: 3081 bytes --]
^ permalink raw reply
* Re: PPC vs POWERPC
From: Matias Sundman @ 2008-01-15 10:38 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <fa686aa40801110652s67b2a05al79f78144c5b527bd@mail.gmail.com>
>>Documentation/powerpc/booting-without-of.txt to find out what is
>>expected in the device tree.
Is there any more information on how the "of_*" ( e.g. of_node_put ,
of_find_node_by_type ) functions should be implemented in the
"arch/powerpc/platforms/myplatform/myboard_setup.c" file
or is the documentation the existing "*.c" c files under
arch/powerpc/platforms ?
Since I have a 82xx board I assume that "myboard_setup.c" file shall be
put under arch/powerpc/platforms/82xx.
Cheers // Matias
Grant Likely skrev:
> On 1/11/08, samppa@sundmangroup.com <samppa@sundmangroup.com> wrote:
>
>> Hi,
>> I want to port a board ( WRS SBC8265 ) from the PPC branch to the POWERPC
>> branch in the Linux Kernel -- do you have any good starting points that
>> describes what I need to pay attention to?
>>
>> I've already made a port of U-boot-1.3.1 and enabled CONFIG_OF_LIBFDT.
>>
>> So I need to create a DTS file, compile it with the DTC compiler and port
>> the current PPC branch to the POWERPC branch to my understanding.
>>
>
> Yes, you're exactly right. Use one of the dts files in
> arch/powerpc/boot/dts as a starting point and read
> Documentation/powerpc/booting-without-of.txt to find out what is
> expected in the device tree.
>
> Cheers,
> g.
>
>
^ permalink raw reply
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-15 12:40 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
platforms and not only the TAH equipped ones (440GX). This enables an
MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
Eugene & Ben, do you see any problems with this patch? If not, then I'll
send another version for the newemac driver too.
Thanks.
drivers/net/ibm_emac/ibm_emac_core.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..198de44 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,9 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
--
1.5.4.rc3
^ permalink raw reply related
* psc and spi
From: S. Fricke @ 2008-01-15 13:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hello friends,
I have on the psc3 the spi-interface of a fpga connected.
psc3-0 - MOSI
psc3-1 - MISO
psc3-2 - CLK
psc3-3 - SlaveSelect
psc3-4 - CS-FPGA
psc3-5 - CS Another device
psc3-6 - SPI-SEL0
psc3-7 - SPI-SEL1
psc3-8/9 - Not connected
Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
driver? Or must I write a own spi-master/slave thing? Can anyone point me
to a good start-position?
Best regards,
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] sbc8560: Add device tree source for Wind River SBC8560 board
From: Kumar Gala @ 2008-01-15 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20080110025622.GE17816@localhost.localdomain>
On Jan 9, 2008, at 8:56 PM, David Gibson wrote:
> On Mon, Jan 07, 2008 at 09:25:29AM -0500, Paul Gortmaker wrote:
>> This adds the device tree source for the Wind River SBC8560 board.
>> The
>> biggest difference between this and the MPC8560ADS reference platform
>> dts is the use of an external 16550 compatible UART instead of the
>> CPM2.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> arch/powerpc/boot/dts/sbc8560.dts | 285 +++++++++++++++++++++++++++
>> ++++++++++
>
> [snip]
>> + epld@fc000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "localbus";
>
> This compatible doesn't look specific enough. It should at least have
> a vendor prefix.
>
>> + ranges = <0 fc000000 00c00000>;
>
> Typically, we've been doing these external bust controller type
> gadgets with address-cells = <2>, the first cell explicitly encoding
> the chipselect. This gets us closer to the ideal of the device tree
> encoding only hardware information, not how the bridge controller is
> configured (although "ranges" will still have to contain configuration
> dependent information).
>
>
>> +
>> + serial0: serial@700000 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <700000 100>;
>> + clock-frequency = <1C2000>;
>> + interrupts = <9 2>;
>> + interrupt-parent = <&mpic>;
>> + };
>> +
>> + serial1: serial@800000 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <800000 100>;
>> + clock-frequency = <1C2000>;
>> + interrupts = <a 2>;
>> + interrupt-parent = <&mpic>;
>> + };
>> +
>> + rtc@900000 {
>> + compatible = "m48t59";
>> + reg = <900000 2000>;
>> + };
>> + };
>> +};
Paul,
any updates here based on David's comments on how we are representing
localbus nodes?
- k
^ permalink raw reply
* Re: [PATCH 1/3] sbc834x: Add support for Wind River SBC834x boards
From: Kumar Gala @ 2008-01-15 14:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20080109180105.7c745bde.sfr@canb.auug.org.au>
On Jan 9, 2008, at 1:01 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> On Wed, 9 Jan 2008 00:49:30 -0500 Paul Gortmaker <paul.gortmaker@windriver.com
> > wrote:
>>
>> +static void __init sbc834x_init_IRQ(void)
>> +{
>> + struct device_node *np;
>> +
>> + np = of_find_node_by_type(NULL, "ipic");
>> + if (!np)
>> + return;
>> +
>> + ipic_init(np, 0);
>> +
>> + /* Initialize the default interrupt mapping priorities,
>> + * in case the boot rom changed something on us.
>> + */
>> + ipic_set_default_priority();
>> +}
>
> This needs an of_node_put(np) somewhere.
>
>> +static struct of_device_id sbc834x_ids[] = {
>
> __initdata
>
>> +static int __init sbc834x_declare_of_platform_devices(void)
>> +{
>> + if (!machine_is(sbc834x))
>> + return 0;
>> +
>> + of_platform_bus_probe(NULL, sbc834x_ids, NULL);
>> + return 0;
>> +}
>> +device_initcall(sbc834x_declare_of_platform_devices);
>
> machine_device_initcall(sbc834x, ...
Any updates here? While David's .dts comments are probably valid I'm
not going to make you have to deal with them to get into the tree. We
need to fix all the other 83xx platforms w/respect to those things.
- k
^ permalink raw reply
* Re: [PATCH] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
From: Kumar Gala @ 2008-01-15 14:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <119992170854-git-send-email-timur@freescale.com>
On Jan 9, 2008, at 5:35 PM, Timur Tabi wrote:
> Add file ucc_uart.c, a serial device driver for the Freescale
> QUICCEngine.
> Update the Kconfig and Makefile accordingly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> drivers/serial/Kconfig | 10 +
> drivers/serial/Makefile | 1 +
> drivers/serial/ucc_uart.c | 1507 ++++++++++++++++++++++++++++++++++++
> +++++++++
> 3 files changed, 1518 insertions(+), 0 deletions(-)
> create mode 100644 drivers/serial/ucc_uart.c
>
>
> diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
> new file mode 100644
> index 0000000..6fe4cfc
> --- /dev/null
> +++ b/drivers/serial/ucc_uart.c
> @@ -0,0 +1,1507 @@
> +/*
> + * Freescale QUICC Engine UART device driver
> + *
> + * Author: Timur Tabi <timur@freescale.com>
> + *
> + * Copyright 2007 Freescale Semiconductor, Inc. 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.
> + *
> + * This driver adds support for UART devices via Freescale's QUICC
> Engine
> + * found on some Freescale SOCs.
> + *
> + * If Soft-UART support is needed but not already present, then
> this driver
> + * will request and upload the "Soft-UART" microcode upon probe. The
> + * filename of the microcode should be fsl_qe_ucode_uart_X_YZ.bin,
> where "X"
> + * is the name of the SOC (e.g. 8323), and YZ is the revision of
> the SOC,
> + * (e.g. "11" for 1.1).
> + */
> +
what is the define for? you commented all the others :)
>
> +#define UCC_WAIT_CLOSING 100
> +
> +struct ucc_uart_pram {
> + struct ucc_slow_pram common;
> + u8 res1[8]; /* reserved */
> + __be16 maxidl; /* Maximum idle chars */
> + __be16 idlc; /* temp idle counter */
> + __be16 brkcr; /* Break count register */
> + __be16 parec; /* receive parity error counter */
> + __be16 frmec; /* receive framing error counter */
> + __be16 nosec; /* receive noise counter */
> + __be16 brkec; /* receive break condition counter */
> + __be16 brkln; /* last received break length */
> + __be16 uaddr[2]; /* UART address character 1 & 2 */
> + __be16 rtemp; /* Temp storage */
> + __be16 toseq; /* Transmit out of sequence char */
> + __be16 cchars[8]; /* control characters 1-8 */
> + __be16 rccm; /* receive control character mask */
> + __be16 rccr; /* receive control character register */
> + __be16 rlbc; /* receive last break character */
> + __be16 res2; /* reserved */
> + __be32 res3; /* reserved, should be cleared */
> + u8 res4; /* reserved, should be cleared */
> + u8 res5[3]; /* reserved, should be cleared */
> + __be32 res6; /* reserved, should be cleared */
> + __be32 res7; /* reserved, should be cleared */
> + __be32 res8; /* reserved, should be cleared */
> + __be32 res9; /* reserved, should be cleared */
> + __be32 res10; /* reserved, should be cleared */
> + __be32 res11; /* reserved, should be cleared */
> + __be32 res12; /* reserved, should be cleared */
> + __be32 res13; /* reserved, should be cleared */
> +/* The rest is for Soft-UART only */
> + __be16 supsmr; /* 0x90, Shadow UPSMR */
> + __be16 res92; /* 0x92, reserved, initialize to 0 */
> + __be32 rx_state; /* 0x94, RX state, initialize to 0 */
> + __be32 rx_cnt; /* 0x98, RX count, initialize to 0 */
> + u8 rx_length; /* 0x9C, Char length, set to 1+CL+PEN+1+SL */
> + u8 rx_bitmark; /* 0x9D, reserved, initialize to 0 */
> + u8 rx_temp_dlst_qe; /* 0x9E, reserved, initialize to 0 */
> + u8 res14[0xBC - 0x9F]; /* reserved */
> + __be32 dump_ptr; /* 0xBC, Dump pointer */
> + __be32 rx_frame_rem; /* 0xC0, reserved, initialize to 0 */
> + u8 rx_frame_rem_size; /* 0xC4, reserved, initialize to 0 */
> + u8 tx_mode; /* 0xC5, mode, 0=AHDLC, 1=UART */
> + u16 tx_state; /* 0xC6, TX state */
__be16?
>
> + u8 res15[0xD0 - 0xC8]; /* reserved */
> + __be32 resD0; /* 0xD0, reserved, initialize to 0 */
> + u8 resD4; /* 0xD4, reserved, initialize to 0 */
> + __be16 resD5; /* 0xD5, reserved, initialize to 0 */
> +} __attribute__ ((packed));
> +
>
>
> +/*
> + * Set the modem control lines
> + *
> + * We currently don't support setting modem control lines, but this
> function
> + * needs to exist, otherwise the kernel will panic.
> + */
> +void qe_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +}
What's the issue w/support of this? (maybe a comment related to why
its not supported -- if not here in the git commit message)
> +/*
> + * Enable status change interrupts
> + *
> + * We don't support status change interrupts, but we need to define
> this
> + * function otherwise the kernel will panic.
> + */
> +static void qe_uart_enable_ms(struct uart_port *port)
> +{
same question as above.
- k
^ permalink raw reply
* Re: [PATCH] Fix carry bug in 128-bit unsigned integer adding
From: Kumar Gala @ 2008-01-15 14:37 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev
In-Reply-To: <6EBEC19BF4A8F843BCD6B9155BBE2515D1B58B@zch01exm26.fsl.freescale.net>
On Jan 8, 2008, at 9:05 PM, Liu Yu wrote:
>
>>
>> take a look at how include/math-emu/op-4.h implements
>> __FP_FRAC_ADD_4 & __FP_FRAC_SUB_4. Will that fix the bug, if
>> so we should make the code match how its done there.
>>
>> - k
>>
>>
>
> The macro define __FP_FRAC_ADD_4 is below. It can fix the carry bug.
> But still exist a problem that r[0-2] and x[0-2] cannot be referred to
> the same variable.
> If r0 and x0 are the same variable, the comparison ( r0 < x0 ) will
> always fail.
> I don't know whether we need to fix this problem.
Not sure. Probably worth asking this on the glibc list and see if
they have theories. (For the short term I'd say lets use the version
from include/math-emu/op-4.h as a fix. If r0 & x0 can be the same
variable the bug exists in a lot more places (glibc soft-fp and
generic kernel mathemu)
- k
^ permalink raw reply
* Re: psc and spi
From: Grant Likely @ 2008-01-15 14:51 UTC (permalink / raw)
To: S. Fricke; +Cc: linuxppc-dev
In-Reply-To: <20080115135306.GE14333@sfrouter>
On 1/15/08, S. Fricke <silvio.fricke@googlemail.com> wrote:
> Hello friends,
>
> I have on the psc3 the spi-interface of a fpga connected.
>
> psc3-0 - MOSI
> psc3-1 - MISO
> psc3-2 - CLK
> psc3-3 - SlaveSelect
> psc3-4 - CS-FPGA
> psc3-5 - CS Another device
> psc3-6 - SPI-SEL0
> psc3-7 - SPI-SEL1
> psc3-8/9 - Not connected
>
> Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
> driver? Or must I write a own spi-master/slave thing? Can anyone point me
> to a good start-position?
Yes, you should be able to use the mpc52xx_psc_spi driver. You'' need
to add the activate_cs and deactivate_cs hooks in your platform code
to activate your SPI CS lines. You'll also need to set port_config to
have the PSC3 pins in "CODEC3" mode.
Cheers,
g.
>
> Best regards,
> Silvio Fricke
>
> --
> -- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
> Diplom-Informatiker (FH)
> Linux-Entwicklung
> ----------------------------------------------------------------------------
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* problem with CF
From: raul.moreno @ 2008-01-15 14:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to use a compact Flash (CF) throu PCMCIA. So I selected the=
CONFIG_BLK_DEV_IDECS and CONFIG_PCMCIA_M8XX kernel options, but not the=
CONFIG_BLK_DEV_MPC8xx_IDE one.
The problem occurs when I insert the CF, because the ide_config fails:=
ide-cs: ide_register() 0x 0 & 0x e, irq 7 failed
I think the issue is in the idecs_register function that always returns=
-1.
I guess the problem is the two first parameter of this function (io_bas=
e
and ctl_base are 0x0 and 0xe respectively), but I don't know if it must=
be
so or what values they must have.
I am using a MPC866 with a linux kernel 2.6.22.
I would thank some help.
Ra=FAl Moreno=
^ permalink raw reply
* Re: [PATCH] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
From: Timur Tabi @ 2008-01-15 15:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <1CFD37C9-F06C-4C7E-836D-31C94EF464DF@kernel.crashing.org>
Kumar Gala wrote:
> what is the define for? you commented all the others :)
I thought you said there were no more issues? :-)
>> +#define UCC_WAIT_CLOSING 100
This is how long to wait after receiving a close request for characters to be
sent out before actually closing the device. I just used the same value as the
CPM serial driver.
>> + u16 tx_state; /* 0xC6, TX state */
>
> __be16?
Oops.
>> +/*
>> + * Set the modem control lines
>> + *
>> + * We currently don't support setting modem control lines, but this
>> function
>> + * needs to exist, otherwise the kernel will panic.
>> + */
>> +void qe_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
>> +{
>> +}
>
> What's the issue w/support of this? (maybe a comment related to why its
> not supported -- if not here in the git commit message)
I didn't want to add any serial functionality that wasn't in the CPM serial
driver, mostly because I don't really understand the technical details of serial
communication at this level. I figured if it's okay for the CPM driver not to
handle modem control, then the QE driver doesn't have to do it either.
>> +static void qe_uart_enable_ms(struct uart_port *port)
>> +{
>
> same question as above.
Same answer!
I suppose you want me to post another version of this patch?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add of_find_matching_node() helper function
From: Grant Likely @ 2008-01-15 15:09 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, Benjamin Herrenschmidt,
Stephen Rothwell
In-Reply-To: <20080108192040.9556.28899.stgit@trillian.secretlab.ca>
Ben, Paul, Stephen,
Any comments/concerns on this patch? I've got a series of patches
which I haven't published yet as they depend on this one. If this
patch doesn't go in then I need to rework the series, in which case
I'd like to know sooner rather than later so that I've got time for
the rework..
Paul, if everyone is okay with this one, can you please pick it up
into your 2.6.25 branch? Or if you prefer, I can add it to the front
of my 5200 patch series so that it is part of my next pull request.
Thanks,
g.
On 1/8/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Similar to of_find_compatible_node(), of_find_matching_node() and
> for_each_matching_node() allow you to iterate over the device tree
> looking for specific nodes except that it accepts a of_device_id
> table instead of strings.
>
> This patch also moves of_match_node() from driver/of/device.c to
> driver/of/base.c to colocate it with the of_find_matching_node which
> depends on it.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/kernel/ibmebus.c | 1
> arch/powerpc/kernel/of_platform.c | 1
> arch/powerpc/platforms/celleb/io-workarounds.c | 1
> arch/powerpc/platforms/celleb/pci.c | 1
> drivers/net/ibm_newemac/core.c | 1
> drivers/of/base.c | 58 ++++++++++++++++++++++++
> drivers/of/device.c | 29 ------------
> drivers/serial/mpc52xx_uart.c | 3 +
> include/linux/of.h | 8 +++
> include/linux/of_device.h | 2 -
> 10 files changed, 73 insertions(+), 32 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index caae49f..3b70844 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -41,6 +41,7 @@
> #include <linux/kobject.h>
> #include <linux/dma-mapping.h>
> #include <linux/interrupt.h>
> +#include <linux/of.h>
> #include <linux/of_platform.h>
> #include <asm/ibmebus.h>
> #include <asm/abs_addr.h>
> diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
> index de36e23..7a3cafb 100644
> --- a/arch/powerpc/kernel/of_platform.c
> +++ b/arch/powerpc/kernel/of_platform.c
> @@ -19,6 +19,7 @@
> #include <linux/mod_devicetable.h>
> #include <linux/slab.h>
> #include <linux/pci.h>
> +#include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_platform.h>
>
> diff --git a/arch/powerpc/platforms/celleb/io-workarounds.c b/arch/powerpc/platforms/celleb/io-workarounds.c
> index b939c0e..423339b 100644
> --- a/arch/powerpc/platforms/celleb/io-workarounds.c
> +++ b/arch/powerpc/platforms/celleb/io-workarounds.c
> @@ -22,6 +22,7 @@
>
> #undef DEBUG
>
> +#include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/irq.h>
>
> diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
> index 5d399e0..51b390d 100644
> --- a/arch/powerpc/platforms/celleb/pci.c
> +++ b/arch/powerpc/platforms/celleb/pci.c
> @@ -31,6 +31,7 @@
> #include <linux/init.h>
> #include <linux/bootmem.h>
> #include <linux/pci_regs.h>
> +#include <linux/of.h>
> #include <linux/of_device.h>
>
> #include <asm/io.h>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..fced441 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -37,6 +37,7 @@
> #include <linux/mii.h>
> #include <linux/bitops.h>
> #include <linux/workqueue.h>
> +#include <linux/of.h>
>
> #include <asm/processor.h>
> #include <asm/io.h>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 9377f3b..b306fef 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -273,3 +273,61 @@ struct device_node *of_find_compatible_node(struct device_node *from,
> return np;
> }
> EXPORT_SYMBOL(of_find_compatible_node);
> +
> +/**
> + * of_match_node - Tell if an device_node has a matching of_match structure
> + * @matches: array of of device match structures to search in
> + * @node: the of device structure to match against
> + *
> + * Low level utility function used by device matching.
> + */
> +const struct of_device_id *of_match_node(const struct of_device_id *matches,
> + const struct device_node *node)
> +{
> + while (matches->name[0] || matches->type[0] || matches->compatible[0]) {
> + int match = 1;
> + if (matches->name[0])
> + match &= node->name
> + && !strcmp(matches->name, node->name);
> + if (matches->type[0])
> + match &= node->type
> + && !strcmp(matches->type, node->type);
> + if (matches->compatible[0])
> + match &= of_device_is_compatible(node,
> + matches->compatible);
> + if (match)
> + return matches;
> + matches++;
> + }
> + return NULL;
> +}
> +EXPORT_SYMBOL(of_match_node);
> +
> +/**
> + * of_find_matching_node - Find a node based on an of_device_id match
> + * table.
> + * @from: The node to start searching from or NULL, the node
> + * you pass will not be searched, only the next one
> + * will; typically, you pass what the previous call
> + * returned. of_node_put() will be called on it
> + * @matches: array of of device match structures to search in
> + *
> + * Returns a node pointer with refcount incremented, use
> + * of_node_put() on it when done.
> + */
> +struct device_node *of_find_matching_node(struct device_node *from,
> + const struct of_device_id *matches)
> +{
> + struct device_node *np;
> +
> + read_lock(&devtree_lock);
> + np = from ? from->allnext : allnodes;
> + for (; np; np = np->allnext) {
> + if (of_match_node(matches, np) && of_node_get(np))
> + break;
> + }
> + of_node_put(from);
> + read_unlock(&devtree_lock);
> + return np;
> +}
> +EXPORT_SYMBOL(of_find_matching_node);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 6245f06..29681c4 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -10,35 +10,6 @@
> #include <asm/errno.h>
>
> /**
> - * of_match_node - Tell if an device_node has a matching of_match structure
> - * @ids: array of of device match structures to search in
> - * @node: the of device structure to match against
> - *
> - * Low level utility function used by device matching.
> - */
> -const struct of_device_id *of_match_node(const struct of_device_id *matches,
> - const struct device_node *node)
> -{
> - while (matches->name[0] || matches->type[0] || matches->compatible[0]) {
> - int match = 1;
> - if (matches->name[0])
> - match &= node->name
> - && !strcmp(matches->name, node->name);
> - if (matches->type[0])
> - match &= node->type
> - && !strcmp(matches->type, node->type);
> - if (matches->compatible[0])
> - match &= of_device_is_compatible(node,
> - matches->compatible);
> - if (match)
> - return matches;
> - matches++;
> - }
> - return NULL;
> -}
> -EXPORT_SYMBOL(of_match_node);
> -
> -/**
> * of_match_device - Tell if an of_device structure has a matching
> * of_match structure
> * @ids: array of of device match structures to search in
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index ec36ad7..7e3ba8b 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -72,7 +72,8 @@
> #include <asm/io.h>
>
> #if defined(CONFIG_PPC_MERGE)
> -#include <asm/of_platform.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> #else
> #include <linux/platform_device.h>
> #endif
> diff --git a/include/linux/of.h b/include/linux/of.h
> index c65af7b..b5f33ef 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -17,6 +17,7 @@
> */
> #include <linux/types.h>
> #include <linux/bitops.h>
> +#include <linux/mod_devicetable.h>
>
> #include <asm/prom.h>
>
> @@ -41,6 +42,11 @@ extern struct device_node *of_find_compatible_node(struct device_node *from,
> #define for_each_compatible_node(dn, type, compatible) \
> for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
> dn = of_find_compatible_node(dn, type, compatible))
> +extern struct device_node *of_find_matching_node(struct device_node *from,
> + const struct of_device_id *matches);
> +#define for_each_matching_node(dn, matches) \
> + for (dn = of_find_matching_node(NULL, matches); dn; \
> + dn = of_find_matching_node(dn, matches))
> extern struct device_node *of_find_node_by_path(const char *path);
> extern struct device_node *of_find_node_by_phandle(phandle handle);
> extern struct device_node *of_get_parent(const struct device_node *node);
> @@ -60,5 +66,7 @@ extern const void *of_get_property(const struct device_node *node,
> int *lenp);
> extern int of_n_addr_cells(struct device_node *np);
> extern int of_n_size_cells(struct device_node *np);
> +extern const struct of_device_id *of_match_node(
> + const struct of_device_id *matches, const struct device_node *node);
>
> #endif /* _LINUX_OF_H */
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index 212bffb..6dc1195 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -10,8 +10,6 @@
>
> #define to_of_device(d) container_of(d, struct of_device, dev)
>
> -extern const struct of_device_id *of_match_node(
> - const struct of_device_id *matches, const struct device_node *node);
> extern const struct of_device_id *of_match_device(
> const struct of_device_id *matches, const struct of_device *dev);
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* crash in kmem_cache_init
From: Olaf Hering @ 2008-01-15 15:09 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Current linus tree crashes in kmem_cache_init, as shown below. The
system is a 8cpu 2.2GHz POWER5 system, model 9117-570, with 4GB ram.
Firmware is 240_332, 2.6.23 boots ok with the same config.
There is a series of mm related patches in 2.6.24-rc1:
commit 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 seems to break it,
==> .git/BISECT_LOG <==
git-bisect start
# good: [0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d] Linux 2.6.23
git-bisect good 0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d
# bad: [cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2] Linux 2.6.24-rc1
git-bisect bad cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2
# good: [9ac52315d4cf5f561f36dabaf0720c00d3553162] sched: guest CPU accounting: add guest-CPU /proc/<pid>/stat fields
git-bisect good 9ac52315d4cf5f561f36dabaf0720c00d3553162
# bad: [b9ec0339d8e22cadf2d9d1b010b51dc53837dfb0] add consts where appropriate in fs/nls/Kconfig fs/nls/Makefile fs/nls/nls_ascii.c fs/nls/nls_base.c fs/nls/nls_cp1250.c fs/nls/nls_cp1251.c fs/nls/nls_cp1255.c fs/nls/nls_cp437.c fs/nls/nls_cp737.c fs/nls/nls_cp775.c fs/nls/nls_cp850.c fs/nls/nls_cp852.c fs/nls/nls_cp855.c fs/nls/nls_cp857.c fs/nls/nls_cp860.c fs/nls/nls_cp861.c fs/nls/nls_cp862.c fs/nls/nls_cp863.c fs/nls/nls_cp864.c fs/nls/nls_cp865.c fs/nls/nls_cp866.c fs/nls/nls_cp869.c fs/nls/nls_cp874.c fs/nls/nls_cp932.c fs/nls/nls_cp936.c fs/nls/nls_cp949.c fs/nls/nls_cp950.c fs/nls/nls_euc-jp.c fs/nls/nls_iso8859-1.c fs/nls/nls_iso8859-13.c fs/nls/nls_iso8859-14.c fs/nls/nls_iso8859-15.c fs/nls/nls_iso8859-2.c fs/nls/nls_iso8859-3.c fs/nls/nls_iso8859-4.c fs/nls/nls_iso8859-5.c fs/nls/nls_iso8859-6.c fs/nls/nls_iso8859-7.c fs/nls/nls_iso8859-9.c fs/nls/nls_koi8-r.c fs/nls/nls_koi8-ru.c fs/nls/nls_koi8-u.c fs/nls/nls_utf8.c
git-bisect bad b9ec0339d8e22cadf2d9d1b010b51dc53837dfb0
# bad: [78a26e25ce4837a03ac3b6c32cdae1958e547639] uml: separate timer initialization
git-bisect bad 78a26e25ce4837a03ac3b6c32cdae1958e547639
# good: [4acad72ded8e3f0211bd2a762e23c28229c61a51] [IPV6]: Consolidate the ip6_pol_route_(input|output) pair
git-bisect good 4acad72ded8e3f0211bd2a762e23c28229c61a51
# good: [64da82efae0d7b5f7c478021840fd329f76d965d] Add support for PCMCIA card Sierra WIreless AC850
git-bisect good 64da82efae0d7b5f7c478021840fd329f76d965d
# bad: [37b07e4163f7306aa735a6e250e8d22293e5b8de] memoryless nodes: fixup uses of node_online_map in generic code
git-bisect bad 37b07e4163f7306aa735a6e250e8d22293e5b8de
# good: [64649a58919e66ec21792dbb6c48cb3da22cbd7f] mm: trim more holes
git-bisect good 64649a58919e66ec21792dbb6c48cb3da22cbd7f
# good: [fb53b3094888be0cf8ddf052277654268904bdf5] smbfs: convert to new aops
git-bisect good fb53b3094888be0cf8ddf052277654268904bdf5
# good: [13808910713a98cc1159291e62cdfec92cc94d05] Memoryless nodes: Generic management of nodemasks for various purposes
.............
Please wait, loading kernel...
Allocated 00a00000 bytes for kernel @ 00200000
Elf64 kernel loaded...
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: panic=1 debug xmon=on
memory layout at init:
alloc_bottom : 0000000000ac1000
alloc_top : 0000000010000000
alloc_top_hi : 00000000da000000
rmo_top : 0000000010000000
ram_top : 00000000da000000
Looking for displays
found display : /pci@800000020000002/pci@2/pci@1/display@0, opening ... done
instantiating rtas at 0x000000000f6a1000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000000cc2000 -> 0x0000000000cc34e4
Device tree struct 0x0000000000cc4000 -> 0x0000000000cd6000
Calling quiesce ...
returning from prom_init
Partition configured for 8 cpus.
Starting Linux PPC64 #2 SMP Tue Jan 15 14:23:02 CET 2008
-----------------------------------------------------
ppc64_pft_size = 0x1c
physicalMemorySize = 0xda000000
htab_hash_mask = 0x1fffff
-----------------------------------------------------
Linux version 2.6.24-rc7-ppc64 (olaf@lingonberry) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #2 SMP Tue Jan 15 14:23:02 CET 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 8192 bytes
Zone PFN ranges:
DMA 0 -> 892928
Normal 892928 -> 892928
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0 -> 892928
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 880720
Policy zone: DMA
Kernel command line: panic=1 debug xmon=on
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 275.070000 MHz
time_init: processor frequency = 2197.800000 MHz
clocksource: timebase mult[e8ab05] shift[22] registered
clockevent: decrementer mult[466a] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg-1] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 1
Memory: 3496632k/3571712k available (6188k kernel code, 75080k reserved, 1324k data, 1220k bss, 304k init)
Unable to handle kernel paging request for data at address 0x00000040
Faulting instruction address: 0xc000000000437470
cpu 0x0: Vector: 300 (Data Access) at [c00000000075b830]
pc: c000000000437470: ._spin_lock+0x20/0x88
lr: c0000000000f78a8: .cache_grow+0x7c/0x338
sp: c00000000075bab0
msr: 8000000000009032
dar: 40
dsisr: 40000000
current = 0xc000000000665a50
paca = 0xc000000000666380
pid = 0, comm = swapper
enter ? for help
[c00000000075bb30] c0000000000f78a8 .cache_grow+0x7c/0x338
[c00000000075bbf0] c0000000000f7d04 .fallback_alloc+0x1a0/0x1f4
[c00000000075bca0] c0000000000f8544 .kmem_cache_alloc+0xec/0x150
[c00000000075bd40] c0000000000fb1c0 .kmem_cache_create+0x208/0x478
[c00000000075be20] c0000000005e670c .kmem_cache_init+0x218/0x4f4
[c00000000075bee0] c0000000005bf8ec .start_kernel+0x2f8/0x3fc
[c00000000075bf90] c000000000008590 .start_here_common+0x60/0xd0
0:mon>
^ 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