* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-20 7:48 UTC (permalink / raw)
To: Wolfgang Denk, Andre Schwarz, linux-ppc list
In-Reply-To: <20080320002149.GD19616@localhost.localdomain>
David Gibson schrieb:
> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>> I've pulled the latest git and built a mpc5200_simple system with a=20
>>> minimal dts.
>>> There's not a single char put on the console ....
>> You did build your device tree with "-b 0", didn't you?
>=20
> Ugh.. I really need to fix dtc to pick the default boot cpu value more
> sensibly, don't I.
>=20
I didn't specify "-b 0". This shouldn't be neccessary on a single=20
processor system ! After all it's an option ... "0" should be default.
-->"./dtc -I dts -O dtb -o /mnt/tftpboot/mvbc.dtb -S 8192 dts/mvbc.dts"
The system is running fine (please see discussions with Grant).
regards,
Andr=E9 Schwarz
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Roland McGrath @ 2008-03-20 8:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Richard Henderson
In-Reply-To: <alpine.LFD.1.00.0803191935080.3020@woody.linux-foundation.org>
> Hmm.. I see the whole series, and I see this patch, but I think it adds
> new code and new complexity, and I don't really see *why*.
The motivation is to get the arch function out of the code path for the
machine-independent request handling. I want to be able to change the
implementation later without touching the arch code again.
The arguments passed down to arch_ptrace are sufficient for what the arch
code itself needs and for the current implementation in ptrace_request.
In future, I'd like the option of changing the code for the standard
requests to use a local data structure set up at the start of ptrace, and
such like (so more pointers and the like would need to be passed down to
ptrace_request). These patches let me remove ptrace_request or change
its calling convention without touching the arch code again.
> Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> whether it handled things or not?
It would certainly be nicer. I would prefer:
extern int arch_ptrace(struct task_struct *child, long request,
long addr, long data, long *retval);
where it returns an error code or it returns 0 and *retval is the value
or it returns 1 and it didn't do anything.
The reason I took the approach I did instead is incrementalism.
I can't change that signature without breaking about 22 arch builds.
I'm only really prepared to thoroughly verify a change on 2 of those
myself. It should be a simple enough change to make blind and get
right. But I've gotten a lot of things wrong before. On principle,
I wouldn't really expect anyone to sign off on stuff I won't even
claim to have tried. I did the forced_successful_syscall_return()
macro for arch's I don't try to build, and was just awful sure golly
that I hadn't got them wrong, because the generic change would break
those few arch's (not 20) without it.
So this ugliness seemed like a better bet than waiting for 20 more
arch sign-offs before any of it could go in. You are certainly in a
position to just change the generic signature and make every arch do
the update (or fix your typos if you just tweak them all blind), and
let them grumble. I did not presume to do so.
If you'd like a patch that changes this signature, updates all arch
implementations, and is actually verified to compile and work only
on x86 and powerpc, I'll be happy to provide that.
Thanks,
Roland
^ permalink raw reply
* Re: simple MPC5200B system
From: David Gibson @ 2008-03-20 8:20 UTC (permalink / raw)
To: André Schwarz; +Cc: linux-ppc list
In-Reply-To: <47E216DA.8080602@matrix-vision.de>
On Thu, Mar 20, 2008 at 08:48:42AM +0100, André Schwarz wrote:
> David Gibson schrieb:
>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>>> I've pulled the latest git and built a mpc5200_simple system with a
>>>> minimal dts.
>>>> There's not a single char put on the console ....
>>> You did build your device tree with "-b 0", didn't you?
>> Ugh.. I really need to fix dtc to pick the default boot cpu value more
>> sensibly, don't I.
>
> I didn't specify "-b 0". This shouldn't be neccessary on a single processor
> system ! After all it's an option ... "0" should be default.
Should, yes. But dtc's pretty new, and a sensible default for -b is
one thing that isn't there.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 43, Issue 31
From: Antoine BRUNET @ 2008-03-20 8:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.838.1205857983.869.linuxppc-embedded@ozlabs.org>
I respond to the message numero 3, see and of the mail.
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Qin Lin)
2. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Qin Lin)
3. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Stephen Neuendorffer)
4. [PATCH] Add Fixed PHY support for ucc_geth (Joakim Tjernlund)
5. Re: [PATCH] Add Fixed PHY support for ucc_geth (Vitaly Bordug)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Mar 2008 19:03:38 -0700 (PDT)
From: Qin Lin <linkinge@gmail.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: linuxppc-embedded@ozlabs.org
Message-ID: <16112213.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hi Steve,
I think the booting message tell me that the interrupt line is connect
OK,isn't it ?
> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
0xD0020000, irq=2
and if you can tell me what should be care about in hard design and in
kernel config with net?
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board) Did you remember
> to connect the interrupt line in your design?
>
> Steve
>
> .....
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000, irq=2
> ......
>
--
View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-
tp16089631p16112213.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Mon, 17 Mar 2008 19:17:01 -0700 (PDT)
From: Qin Lin <linkinge@gmail.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: linuxppc-embedded@ozlabs.org
Message-ID: <16112415.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
>> Sent: Monday, March 17, 2008 12:36 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>>
>>
>> HI all,
>>
>> Is anyone have the opb_emac (no DMA) work with the kernel
> linux-2.6-xlnx
>> from git.xilinx.com.
>> the message seams that it does work ,but the command ping return
> nothing!
>>
>> Could you kindly suggest me what to do?
>>
>> ps:
>> the kernel booting message
>> [ 0.258674] net_namespace: 64 bytes
>> [ 0.269780] NET: Registered protocol family 16
>> [ 0.290415] Registering device xilinx_emac:0
>> [ 0.381687] NET: Registered protocol family 2
>> [ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [ 0.399556] TCP established hash table entries: 8192 (order: 4,
> 65536
>> bytes)
>> [ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
> bytes)
>> [ 0.405409] TCP: Hash tables configured (established 8192 bind
> 8192)
>> [ 0.405489] TCP reno registered
>> [ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [ 0.413189] Call Trace:
>> [ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
> (unreliable)
>> [ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
>> [ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
>> [ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
>> [ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
>> [ 0.414141] [cf41ff70] [c01e4b1c]
> register_ppc_htab_sysctl+0x18/0x2c
>> [ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
>> [ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>>
>> [ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0:
> 0: 0:
>> 0
>> [ 1.123790] XEmac: using fifo mode.
>> [ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
>> 0x78e2.
>> [ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000,
>> irq=2
>> [ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
>> [ 1.194661] TCP cubic registered
>> [ 1.198647] NET: Registered protocol family 1
>> [ 1.203728] NET: Registered protocol family 17
>>
>>
>> #ping 192.168.26.1 &
>> # ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
>> inet addr:192.168.26.127 Bcast:192.168.26.255
> Mask:255.255.255.0
>> UP BROADCAST RUNNING MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
>> Interrupt:2 Memory:40c00000-40c0ffff
>>
>> Regards
>>
>> Qin Lin
>> --
>> View this message in context:
> http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
>> xlnx-tp16089631p16089631.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-
tp16089631p16112415.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
------------------------------
Message: 3
Date: Mon, 17 Mar 2008 21:30:23 -0700
From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: "Qin Lin" <linkinge@gmail.com>, <linuxppc-embedded@ozlabs.org>
Message-ID: <20080318043128.DDDA0ED005E@mail85-dub.bigfish.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes that should work...
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on
behalf of Qin Lin
Sent: Mon 3/17/2008 7:17 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Hi,
I use ml403 board and Edk 9.1 and kernel linux-2.6-xlnx 2.6.24rc8.
My emac runs normally with this kernel 2.6.24rc8.
My emac is dysigned on my bsp project with interruption and reset :
.MHS :
BEGIN opb_ethernet
PARAMETER INSTANCE = Ethernet_MAC
PARAMETER HW_VER = 1.04.a
PARAMETER C_DMA_PRESENT = 1
PARAMETER C_IPIF_RDFIFO_DEPTH = 32768
PARAMETER C_IPIF_WRFIFO_DEPTH = 32768
PARAMETER C_OPB_CLK_PERIOD_PS = 10000
PARAMETER C_BASEADDR = 0x40c00000
PARAMETER C_HIGHADDR = 0x40c0ffff
BUS_INTERFACE SOPB = opb
PORT IP2INTC_Irpt = Ethernet_MAC_IP2INTC_Irpt
PORT PHY_tx_data = fpga_0_Ethernet_MAC_PHY_tx_data
PORT PHY_tx_en = fpga_0_Ethernet_MAC_PHY_tx_en
PORT PHY_tx_clk = fpga_0_Ethernet_MAC_PHY_tx_clk
PORT PHY_tx_er = fpga_0_Ethernet_MAC_PHY_tx_er
PORT PHY_rx_er = fpga_0_Ethernet_MAC_PHY_rx_er
PORT PHY_rx_clk = fpga_0_Ethernet_MAC_PHY_rx_clk
PORT PHY_dv = fpga_0_Ethernet_MAC_PHY_dv
PORT PHY_rx_data = fpga_0_Ethernet_MAC_PHY_rx_data
PORT PHY_Mii_clk = fpga_0_Ethernet_MAC_PHY_Mii_clk
PORT PHY_Mii_data = fpga_0_Ethernet_MAC_PHY_Mii_data
PORT PHY_rst_n = fpga_0_Ethernet_MAC_PHY_rst_n
END
Be carreful the reset pin is mandatory, at first i have ommitedd this IO ans
my emac didn't work.
I have just add this reset IO and emac works properly...
I dont know if the tall of tje fifo are important but i have always done
32768.
I hope i can help you...
Antoine BRUNET
^ permalink raw reply
* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-20 9:11 UTC (permalink / raw)
To: linux-ppc list
In-Reply-To: <20080320082035.GA23860@localhost.localdomain>
David Gibson schrieb:
> On Thu, Mar 20, 2008 at 08:48:42AM +0100, Andr=E9 Schwarz wrote:
>> David Gibson schrieb:
>>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>>>> I've pulled the latest git and built a mpc5200_simple system with a=
=20
>>>>> minimal dts.
>>>>> There's not a single char put on the console ....
>>>> You did build your device tree with "-b 0", didn't you?
>>> Ugh.. I really need to fix dtc to pick the default boot cpu value mor=
e
>>> sensibly, don't I.
>> I didn't specify "-b 0". This shouldn't be neccessary on a single proc=
essor=20
>> system ! After all it's an option ... "0" should be default.
>=20
> Should, yes. But dtc's pretty new, and a sensible default for -b is
> one thing that isn't there.
>=20
ok - but this has not caused my (solved) problem. dtc is working fine=20
for me :-)
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Paul Mackerras @ 2008-03-20 9:23 UTC (permalink / raw)
To: Nathan Lynch; +Cc: Olof Johansson, linuxppc-dev, Jan-Bernd Themann
In-Reply-To: <20080320071858.GS4712@localdomain>
Nathan Lynch writes:
> Searching ibm,drc-names is necessary, but is it sufficient? That is,
> can there be a system that has an HEA adapter without that property
> being present? Thinking in particular about single-partition systems
> that run without an HMC attached.
PAPR doesn't seem to say clearly one way or the other. For 2.6.25,
the best thing is probably just to force 4k pages on all pSeries
machines. Given that this is only for access to PCI devices, the
actual access is going to be slow enough that an extra TLB miss here
or there won't matter too much.
Paul.
^ permalink raw reply
* Re: simple MPC5200B system
From: Stefan Roese @ 2008-03-20 9:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: André Schwarz, David Gibson
In-Reply-To: <20080320082035.GA23860@localhost.localdomain>
On Thursday 20 March 2008, David Gibson wrote:
> >>> You did build your device tree with "-b 0", didn't you?
> >>
> >> Ugh.. I really need to fix dtc to pick the default boot cpu value more
> >> sensibly, don't I.
> >
> > I didn't specify "-b 0". This shouldn't be neccessary on a single
> > processor system ! After all it's an option ... "0" should be default.
>
> Should, yes. But dtc's pretty new, and a sensible default for -b is
> one thing that isn't there.
ACK. I have run into a problem on the Sequoia (440EPx) lately, where the FPU
was not initialized correctly because of the missing "-b 0". Please add this
as default.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] [POWERPC] Add "amcc, haleakala" to the toplevel compatible property
From: Stefan Roese @ 2008-03-20 10:33 UTC (permalink / raw)
To: linuxppc-dev
Currently Haleakala uses the Kilauea platform code. This patch adds
"haleakala" to the compatible property, in case later kernel versions
will introduce a Haleakala platform code.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index ae68fef..02e4ba3 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -12,7 +12,7 @@
#address-cells = <1>;
#size-cells = <1>;
model = "amcc,haleakala";
- compatible = "amcc,kilauea";
+ compatible = "amcc,haleakala", "amcc,kilauea";
dcr-parent = <&/cpus/cpu@0>;
aliases {
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] Implement of_flat_dt_search() and use it for of_flat_dt_is_compatible.
From: Benjamin Herrenschmidt @ 2008-03-20 9:41 UTC (permalink / raw)
To: Tony Breeds
Cc: Olof Johansson, linuxppc-dev, Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <63cdefde19cb2a4adc17ed771f21261673428ce7.1205987625.git.tony@bakeyournoodle.com>
On Thu, 2008-03-20 at 15:33 +1100, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
What about a comment ? :-)
> arch/powerpc/kernel/prom.c | 21 ++++++++++++++-------
> include/asm-powerpc/prom.h | 2 ++
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index eac97f4..f73e18b 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -205,25 +205,32 @@ void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
> } while(1);
> }
>
> -int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
> +int __init of_flat_dt_search(unsigned long node, const char *str,
> + const char *prop_name)
> {
> - const char* cp;
> - unsigned long cplen, l;
> + const char *cp;
> + unsigned long plen, l;
>
> - cp = of_get_flat_dt_prop(node, "compatible", &cplen);
> + cp = of_get_flat_dt_prop(node, prop_name, &plen);
> if (cp == NULL)
> return 0;
> - while (cplen > 0) {
> - if (strncasecmp(cp, compat, strlen(compat)) == 0)
> + while (plen > 0) {
> + if (strncasecmp(cp, str, strlen(str)) == 0)
> return 1;
> l = strlen(cp) + 1;
> cp += l;
> - cplen -= l;
> + plen -= l;
> }
>
> return 0;
> }
>
> +int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
> +{
> +
> + return of_flat_dt_search(node, compat, "compatible");
> +}
> +
> static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
> unsigned long align)
> {
> diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
> index 78b7b0d..7b587f1 100644
> --- a/include/asm-powerpc/prom.h
> +++ b/include/asm-powerpc/prom.h
> @@ -134,6 +134,8 @@ extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
> void *data);
> extern void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
> unsigned long *size);
> +extern int __init of_flat_dt_search(unsigned long node, const char *str,
> + const char *prop_name);
> extern int __init of_flat_dt_is_compatible(unsigned long node, const char *name);
> extern unsigned long __init of_get_flat_dt_root(void);
>
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Matt Sealey @ 2008-03-20 11:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080319152722.GA9208@aepfle.de>
This was a good catch. IPIC is the controller on the MPC83xx type boards (and
MPC5121E) so building a kernel with this controller code in there, but without
the controller present, should gladly fail.
However removing the boards from the config does not fix this obvious error. I
like your patch better than changing the config options to disable entire
swathes of board support :D
What I'm concerned about is that the IPIC code is registering with sysfs even
though there is no controller present. How on EARTH does it even get that far?
If ipic_init fails, no further code should be run from this file, in my view.
subsys_initcall(init_ipic_sysfs); <-- this, in my eyes, is the culprit. If
init_ipic() runs, init_ipic_sysfs should be called from that, not left for
some further subsystem to blindly try and register sysfs nodes for devices
which may not even be present..
I'd love someone to explain to me how this works and why, and why it isn't
braindead? :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Olaf Hering wrote:
> 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
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Xenomai on TQ MPC5200
From: Thomas Häberle @ 2008-03-20 13:09 UTC (permalink / raw)
To: linuxppc-dev
Hello!
My target hardware is a MPC5200 on a TQ STK52xx.
I am developing in a Linked Setup with ELDK 3.1.1 under a Debian Linux
(Release 2.6.18-4-686 ; gcc 4.1.2).
The whole ELDK was already used in a former project with identical
hardware and some early tests I ran showed that it works fine (as far as
I can see).
My goal is to get a real time Linux OS running on the target (preferably
Xenomai) and establish a RT ethernet connection with a identical
hardware setup (planning to use RTnet). But I am somehow stuck in the
first place for I can't get the kernel built:
I tried quite a number of Kernel-Xenomai-Adeos-Version-combinations in
the past four days without any actual success.
Yesterday I downloaded the Linuxppc_2_4_develop-sources from the GIT
repository of the DENX site and set them to the exact point where the
Adeos-Patch coming along with Xenomai 2.4.2 is build for (commit # ).
The patch worked fine (ran trough), I configured the kernel and built
the dependencies, but I am still unable to crosscompile the kernel and
am also slowly running out of ideas.
I am relatively new to this part of the software world, so forgive me
for my maybe basic questions:
I found no explicit information on the web, whether Xenomai can be run
on my specific target at all:
Has anyone tried or knows something about that?
Or where could I check whether it is (besides asking TQ of course)?
Maybe the better way would be trying with RTAI?
Are there any known oddities of the STK52xx and/or MPC5200?
Do I have to adapt my ELDK in any further way to get things going and
using the DENX-sources (okay I guess this is hard to say without
detailed information about my ELDK setup...)?
Any other helpful experience, hints or tricks?
Thanks & Greetings,
Thomas
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-20 13:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080317153326.GA2644@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
Hi Scott,
On Monday 17 March 2008 16:33, Scott Wood wrote:
> On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> > On Friday 07 March 2008 17:21, Scott Wood wrote:
> > > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > > (unlike cpm1). This should probably be fixed, though then we'd have to
> > > deal with assigning SMC parameter RAM addresses ourselves.
> >
> > I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there
> > any reason not to rset the CPM in cpm2_reset() ?
>
> The only issue I'm aware of other than the SMC parameter RAM relocation is
> that the reset can't happen if the early udbg printk is being used.
>
> > How should SMC parameter RAM assignment be handled ? I'm not very
> > familiar with the CPM1,
>
> CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.
>
> > but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter
> > RAM.
>
> It can, yes. Patches welcome. :-)
I'm working on a patch. I'm not sure how to handle the early udbg printk
problem, so the first version will just ignore it.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xenomai on TQ MPC5200
From: Wolfgang Grandegger @ 2008-03-20 13:34 UTC (permalink / raw)
To: Thomas Häberle; +Cc: linuxppc-dev
In-Reply-To: <47E2620C.4020406@vipco.de>
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
Thomas Häberle wrote:
> Hello!
>
> My target hardware is a MPC5200 on a TQ STK52xx.
> I am developing in a Linked Setup with ELDK 3.1.1 under a Debian Linux
> (Release 2.6.18-4-686 ; gcc 4.1.2).
> The whole ELDK was already used in a former project with identical
> hardware and some early tests I ran showed that it works fine (as far as
> I can see).
>
> My goal is to get a real time Linux OS running on the target (preferably
> Xenomai) and establish a RT ethernet connection with a identical
> hardware setup (planning to use RTnet). But I am somehow stuck in the
> first place for I can't get the kernel built:
> I tried quite a number of Kernel-Xenomai-Adeos-Version-combinations in
> the past four days without any actual success.
>
> Yesterday I downloaded the Linuxppc_2_4_develop-sources from the GIT
> repository of the DENX site and set them to the exact point where the
> Adeos-Patch coming along with Xenomai 2.4.2 is build for (commit # ).
> The patch worked fine (ran trough), I configured the kernel and built
> the dependencies, but I am still unable to crosscompile the kernel and
> am also slowly running out of ideas.
>
> I am relatively new to this part of the software world, so forgive me
> for my maybe basic questions:
> I found no explicit information on the web, whether Xenomai can be run
> on my specific target at all:
> Has anyone tried or knows something about that?
> Or where could I check whether it is (besides asking TQ of course)?
> Maybe the better way would be trying with RTAI?
> Are there any known oddities of the STK52xx and/or MPC5200?
> Do I have to adapt my ELDK in any further way to get things going and
> using the DENX-sources (okay I guess this is hard to say without
> detailed information about my ELDK setup...)?
> Any other helpful experience, hints or tricks?
I have a STK52xx on my desk running Xenomai and RTnet under DENX Linux
2.4.25. I have attached my installation README. But your request is
off-topic here. Please switch to an appropriate list for further
questions, e.g. Xenomai-help of RTnet.
Wolfgang.
[-- Attachment #2: README.rtnet --]
[-- Type: text/plain, Size: 3768 bytes --]
README on how to configure, build, install and use RTnet with Linux 2.4.25
==========================================================================
For cross development, please use the ELDK version 3.1.1. For further
information check http://www.denx.de/wiki/DULG/ELDK.
This README is for the TQM5200 evaluation board. I actually use an
EEPRO100 PCI NIC to boot Linux and mount the root file system via NFS.
Get and unfold sources:
-----------------------
$ cd <work-dir>
$ export WORKDIR=$PWD
- DENX Linux 2.4.25
$ cd $WORKDIR
$ git clone git://www.denx.de/git/linuxppc_2_4_devel.git
$ export KERNELDIR=$PWD/linuxppc_2_4_devel
- Xenomai 2.3.5
$ cd $WORKDIR
$ wget http://download.gna.org/xenomai/stable/xenomai-2.3.5.tar.bz2
$ tar xjf xenomai-2.3.5.tar.bz2
$ export XENODIR=$PWD/xenomai-2.3.5
- RTnet SVN trunk (>= 0.9.10rc1):
$ cd $WORKDIR
$ svn co https://rtnet.svn.sourceforge.net/svnroot/rtnet/trunk
$ export RTNETDIR=$PWD/trunk/rtnet
Configure, build and install kernel and user space binaries:
------------------------------------------------------------
- Required environment settings
$ export CROSS_COMPILE=ppc_6xx-
$ export DESTDIR=/opt/eldk/ppc_6xx
- Configure and build Xenomai patched kernel
$ cd $KERNELDIR
$ patch -p1 < <path>/linuxppc_2_4_devel-wait-event.patch
$ patch -p1 < <path>/linuxppc_2_4_devel-fec.patch
$ make TQM5200_config
$ cd $XENODIR
$ ./scripts/prepare-kernel.sh --linux=$KERNELDIR --arch=ppc --verbose
$ cd $KERNELDIR
$ make menuconfig
... check loadable module support ...
... disable FEC driver ...
MPC5xxx I/O Options --->
[*] Use USE Motorola BestComm API Implementation
[ ] FEC Ethernet
... enable EEPRO100 PCI driver ...
Network device support --->
Ethernet (10 or 100Mbit) --->
[*] EISA, VLB, PCI and on board controllers
<*> EtherExpressPro/100 support (eepro100, ...
... exit and save default configuration ...
$ make dep
$ make uImage
$ cp -pv arch/ppc/boot/images/uImage /tftpboot
- Configure, build and install Xenomai user space stuff
$ cd $XENODIR
$ ./configure --host=ppc-linux --prefix=/root/xenomai
$ make
$ make install
- Configure, build and install RTnet
$ cd $RTNETDIR
$ patch -p1 < <path>rt-mpc52xx-fec.patch
$ ./configure --host=ppc-linux \
--with-linux=$KERNELDIR \
--with-rtext-config=$DESTDIR/root/xenomai/bin/xeno-config \
--disable-e1000 --disable-8139 --disable-8139too \
--enable-mpc52xx-fec --enable-eepro100 \
--prefix=/root/xenomai --enable-proxy
$ make
$ make install
Load, configure and run RTnet on the target:
--------------------------------------------
Check if the device file /dev/rtnet exists. If not, create it with:
# mknod /dev/rtnet c 10 240
I use the following script to load the RTnet modules and to startup the
network:
# cat load-rtnet
export RTNET=/root/xenomai
moddir=$RTNET/modules
export PATH=$PATH:$RTNET/sbin:$RTNET/bin:$RTNET/examples/xenomai/posix
export LD_LIBRARY_PATH=$RTNET/lib
insmod -m $moddir/rtnet.o > /root/insmod.log
insmod -m $moddir/rtipv4.o >> /root/insmod.log
insmod -m $moddir/rt_mpc52xx_fec.o >> /root/insmod.log
rtifconfig rteth0 up 172.16.0.20
rtroute solicit 172.16.0.1 dev rteth0
rtifconfig
rtroute
Then you can use "rtping" to check the connection:
# rtping 172.16.0.1
Testing:
--------
For testing RTnet communication and response time, the example RTnet
applications rtt_sender and rtt_responder are quite useful. You can make
and install them as shown below:
$ cd $RTNETDIR/examples/xenomai/posix/
$ make
$ make install
In $DISTDIR/rtt-examples are the corresponding programs for plain
Linux.
^ permalink raw reply
* Oops with TQM5200 on TQM5200
From: Wolfgang Grandegger @ 2008-03-20 14:18 UTC (permalink / raw)
To: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
Hello,
I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
oops. Are there any known patches fixing the problems?
TIA.
Wolfgang.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: oops.log --]
[-- Type: text/x-log; name="oops.log", Size: 6537 bytes --]
## Booting image at 00200000 ...
Image Name: Linux-2.6.25-rc6-01058-gf8937ce-
Created: 2008-03-20 13:19:36 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1697503 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x400000
[ 0.000000] Using mpc5200-simple-platform machine description
[ 0.000000] Linux version 2.6.25-rc6-01058-gf8937ce-dirty (wolf@lancy.lan.de) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #14 Thu Mar 20 14:19:25 CET 2008
[ 0.000000] PCI host bridge /pci@f0000d00 (primary) ranges:
[ 0.000000] MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
[ 0.000000] MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
[ 0.000000] IO 0x00000000a0000000..0x00000000a0ffffff -> 0x0000000000000000
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/nfs rw nfsroot=10.0.30.2:/opt/eldk/ppc_6xx ip=10.0.30.210:10.0.30.2:::tqm5200:eth0:off panic=1 console=ttyPSC0,115200
[ 0.000000] MPC52xx PIC is up and running!
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000014] clocksource: timebase mult[79364d9] shift[22] registered
[ 0.000241] console [ttyPSC0] enabled
[ 0.004376] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.008573] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.021186] Memory: 61236k/65536k available (3328k kernel code, 4236k reserved, 120k data, 149k bss, 180k init)
[ 0.024179] SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
[ 0.120160] Mount-cache hash table entries: 512
[ 0.128111] net_namespace: 152 bytes
[ 0.133162] NET: Registered protocol family 16
[ 0.150957] PCI: Probing PCI hardware
[ 0.168836] SCSI subsystem initialized
[ 0.174379] usbcore: registered new interface driver usbfs
[ 0.176629] usbcore: registered new interface driver hub
[ 0.180942] usbcore: registered new device driver usb
[ 0.200000] Time: timebase clocksource has been installed.
[ 0.208268] NET: Registered protocol family 2
[ 0.252350] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.260660] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.268181] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.272125] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.276028] TCP reno registered
[ 0.338145] JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[ 0.342627] io scheduler noop registered
[ 0.344114] io scheduler anticipatory registered (default)
[ 0.348032] io scheduler deadline registered
[ 0.352847] io scheduler cfq registered
[ 0.778513] Generic RTC Driver v1.07
[ 0.780658] Serial: MPC52xx PSC UART driver
[ 0.784474] f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
[ 0.793028] f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
[ 0.797297] f0002400.serial: ttyPSC2 at MMIO 0xf0002400 (irq = 131) is a MPC52xx PSC
[ 0.814501] brd: module loaded
[ 0.823106] loop: module loaded
[ 0.824132] vcan: Virtual CAN interface driver
[ 0.828033] slcan: serial line CAN interface driver
[ 0.832030] slcan: 10 dynamic interface channels.
[ 0.840408] mpc52xx-mscan mpc52xx-mscan.0: probe for port at 0xC5062900 done (irq 145)
[ 0.846001] mpc52xx-mscan mpc52xx-mscan.1: probe for port at 0xC5064980 done (irq 146)
[ 0.852251] Unable to handle kernel paging request for data at address 0x0000000c
[ 0.860026] Faulting instruction address: 0xc0017fec
[ 0.864036] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.868000] mpc5200-simple-platform
[ 0.868000] Modules linked in:
[ 0.868000] NIP: c0017fec LR: c0019064 CTR: 00000010
[ 0.868000] REGS: c381fd20 TRAP: 0300 Not tainted (2.6.25-rc6-01058-gf8937ce-dirty)
[ 0.868000] MSR: 00009032 <EE,ME,IR,DR> CR: 28000028 XER: 2000005f
[ 0.868000] DAR: 0000000c, DSISR: 20000000
[ 0.868000] TASK = c3812400[1] 'swapper' THREAD: c381e000
[ 0.868000] GPR00: 00000010 c381fdd0 c3812400 00000100 00000008 00000008 fcff7000 c382ca00
[ 0.868000] GPR08: 00002000 00000000 00000000 f00035a9 f0003000 fefd7f7f 07fb3000 04000000
[ 0.868000] GPR16: 00000000 007fff00 00000000 c02c0000 c0340000 c0330000 07fb2678 00000000
[ 0.868000] GPR24: c0330000 00000008 c0360000 00000100 00000008 f0003184 000005f2 00000000
[ 0.868000] NIP [c0017fec] bcom_task_alloc+0x30/0x198
[ 0.868000] LR [c0019064] bcom_fec_rx_init+0x24/0x74
[ 0.868000] Call Trace:
[ 0.868000] [c381fdd0] [c006863c] __get_vm_area_node+0x80/0x1b8 (unreliable)
[ 0.868000] [c381fe00] [c0019064] bcom_fec_rx_init+0x24/0x74
[ 0.868000] [c381fe20] [c028428c] 0xc028428c
[ 0.868000] [c381fe60] [c01ea26c] of_platform_device_probe+0x58/0x80
[ 0.868000] [c381fe80] [c017ddd0] driver_probe_device+0xb8/0x1cc
[ 0.868000] [c381fea0] [c017e0bc] __driver_attach+0xcc/0xf8
[ 0.868000] [c381fec0] [c017c93c] bus_for_each_dev+0x58/0x94
[ 0.868000] [c381fef0] [c017db00] driver_attach+0x24/0x34
[ 0.868000] [c381ff00] [c017d9c0] bus_add_driver+0x188/0x250
[ 0.868000] [c381ff20] [c017e598] driver_register+0x48/0x130
[ 0.868000] [c381ff40] [c01ea48c] of_register_driver+0x54/0x70
[ 0.868000] [c381ff50] [c032c6b4] mpc52xx_fec_init+0x64/0x80
[ 0.868000] [c381ff70] [c0313858] kernel_init+0x98/0x28c
[ 0.868000] [c381fff0] [c001229c] kernel_thread+0x44/0x60
[ 0.868000] Instruction dump:
[ 0.868000] 7c0802a6 9421ffd0 bf210014 3f40c036 7c7b1b78 7c992378 90010034 38000010
[ 0.868000] 7cbc2b78 813a5224 7c0903a6 3be00000 <8129000c> 80090004 57fd2834 2f800000
[ 0.868081] ---[ end trace ab0c326e02602f58 ]---
[ 0.872036] Kernel panic - not syncing: Attempted to kill init!
[ 0.876034] Rebooting in 1 seconds..
U-Boot 1.3.1-g5f7f945a-dirty (Dec 19 2007 - 16:58:01)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz
Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
Board: TQM5200 (TQ-Components GmbH)
on a STK52xx carrier board
I2C: 85 kHz, ready
DRAM: 128 MB
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Grant Likely @ 2008-03-20 14:41 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: ppc-dev
In-Reply-To: <47E2723D.1090101@grandegger.com>
On Thu, Mar 20, 2008 at 8:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hello,
>
> I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
> oops. Are there any known patches fixing the problems?
>
> TIA.
Hmm, I haven't seen this issue on any of my 5200 boards. To state the
obvious, it's an issue in the bestcomm code. What source line is
"bcom_task_alloc+0x30/0x198" on?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/3] [POWERPC] [RFC] of_serial and boot patches introduction
From: John Linn @ 2008-03-20 14:42 UTC (permalink / raw)
To: linuxppc-dev, grant.likely, jwboyer
In-Reply-To: <12060236493879-git-send-email-john.linn@xilinx.com>
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
^ permalink raw reply
* [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-03-20 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <12060242324116-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550, because it uses
word-based addressing rather than byte-based addressing. As a result,
it is not compatible with the open firmware 'ns16550' compatible
binding. This code introduces new bindings, which pass the correct
register base and regshift properties to the uart driver to enable
this core to be used. Doing this cleanly required some refactoring of
the existing code.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 47 ++++++++++++++++++++++++++++++-------------
1 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..910c94f 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -20,13 +20,15 @@
struct of_serial_info {
int type;
int line;
+ int regshift;
+ int regoffset;
};
/*
* Fill a struct uart_port for a given device node
*/
static int __devinit of_platform_serial_setup(struct of_device *ofdev,
- int type, struct uart_port *port)
+ struct of_serial_info *info, struct uart_port *port)
{
struct resource resource;
struct device_node *np = ofdev->node;
@@ -48,17 +50,16 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
}
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
+ port->mapbase = resource.start + info->regoffset;
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
- port->type = type;
+ port->type = info->type;
+ port->regshift = info->regshift;
port->uartclk = *clk;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- /* If current-speed was set, then try not to change it. */
- if (spd)
- port->custom_divisor = *clk / (16 * (*spd));
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
@@ -81,8 +82,9 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
if (info == NULL)
return -ENOMEM;
- port_type = (unsigned long)id->data;
- ret = of_platform_serial_setup(ofdev, port_type, &port);
+ memcpy(info, id->data, sizeof(struct of_serial_info));
+ port_type = info->type;
+ ret = of_platform_serial_setup(ofdev, info, &port);
if (ret)
goto out;
@@ -100,7 +102,6 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
if (ret < 0)
goto out;
- info->type = port_type;
info->line = ret;
ofdev->dev.driver_data = info;
return 0;
@@ -128,15 +129,33 @@ static int of_platform_serial_remove(struct of_device *ofdev)
return 0;
}
+static struct of_serial_info __devinitdata ns8250_info = { .type = PORT_8250 };
+static struct of_serial_info __devinitdata ns16450_info = { .type = PORT_16450 };
+static struct of_serial_info __devinitdata ns16550_info = { .type = PORT_16550 };
+static struct of_serial_info __devinitdata ns16750_info = { .type = PORT_16750 };
+static struct of_serial_info __devinitdata xilinx_16550_info = {
+ .type = PORT_16550,
+ .regshift = 2,
+ .regoffset = 3,
+};
+static struct of_serial_info __devinitdata unknown_info = { .type = PORT_UNKNOWN };
+
/*
* A few common types, add more as needed.
*/
static struct of_device_id __devinitdata of_platform_serial_table[] = {
- { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
- { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
- { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
- { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
- { .type = "serial", .data = (void *)PORT_UNKNOWN, },
+ { .type = "serial", .compatible = "ns8250", .data = &ns8250_info, },
+ { .type = "serial", .compatible = "ns16450", .data = &ns16450_info, },
+ { .type = "serial", .compatible = "ns16550", .data = &ns16550_info, },
+ { .type = "serial", .compatible = "ns16750", .data = &ns16750_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.c", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.d", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.e", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,plb-uart16550-1.00.c", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-1.00.a", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.a", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b", .data = &xilinx_16550_info, },
+ { .type = "serial", .data = &unknown_info, },
{ /* end of list */ },
};
--
1.5.2.1
^ permalink raw reply related
* [PATCH 1/3] [POWERPC] of_serial: Fix possible null dereference.
From: John Linn @ 2008-03-20 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..2efb892 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- port->custom_divisor = *clk / (16 * (*spd));
+ /* If current-speed was set, then try not to change it. */
+ if (spd)
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
--
1.5.2.1
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] Xilinx: boot support for Xilinx uart 16550.
From: John Linn @ 2008-03-20 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <1206024232655-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550, because it uses
word-based addressing rather than byte-based addressing. As a result,
it is not compatible with the open firmware 'ns16550' compatible
binding.
This code adds the Xilinx uart 16550 to the serial console
of the boot. A new initialization function for the Xilinx 16550 uart
is added to the ns16550 driver. It sets up the correct register base
and regshift properties specific to the Xilinx 16550.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/powerpc/boot/ns16550.c | 24 ++++++++++++++++++++++++
arch/powerpc/boot/ops.h | 1 +
arch/powerpc/boot/serial.c | 8 ++++++++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..5385255 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -77,3 +77,27 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
return 0;
}
+
+int xilinx16550_console_init(void *devp, struct serial_console_data *scdp)
+{
+ int n;
+ unsigned long reg_phys;
+
+ n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
+ if (n != sizeof(reg_base)) {
+ if (!dt_xlate_reg(devp, 0, ®_phys, NULL))
+ return -1;
+
+ reg_base = (void *)reg_phys + 3;
+ }
+
+ reg_shift = 2;
+
+ scdp->open = ns16550_open;
+ scdp->putc = ns16550_putc;
+ scdp->getc = ns16550_getc;
+ scdp->tstc = ns16550_tstc;
+ scdp->close = NULL;
+
+ return 0;
+}
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index a180b65..d8b864b 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -86,6 +86,7 @@ int mpsc_console_init(void *devp, struct serial_console_data *scdp);
int cpm_console_init(void *devp, struct serial_console_data *scdp);
int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp);
int uartlite_console_init(void *devp, struct serial_console_data *scdp);
+int xilinx16550_console_init(void *devp, struct serial_console_data *scdp);
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 7fa5078..fb5c91e 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -131,6 +131,14 @@ int serial_console_init(void)
else if (dt_is_compatible(devp, "xlnx,opb-uartlite-1.00.b") ||
dt_is_compatible(devp, "xlnx,xps-uartlite-1.00.a"))
rc = uartlite_console_init(devp, &serial_cd);
+ else if (dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.c") ||
+ dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.d") ||
+ dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.e") ||
+ dt_is_compatible(devp, "xlnx,plb-uart16550-1.00.c") ||
+ dt_is_compatible(devp, "xlnx,xps-uart16550-1.00.a") ||
+ dt_is_compatible(devp, "xlnx,xps-uart16550-2.00.a") ||
+ dt_is_compatible(devp, "xlnx,xps-uart16550-2.00.b"))
+ rc = xilinx16550_console_init(devp, &serial_cd);
/* Add other serial console driver calls here */
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH 3/3] [POWERPC] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-20 14:54 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080320144402.695C1518064@mail63-sin.bigfish.com>
On Thu, Mar 20, 2008 at 8:43 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550, because it uses
> word-based addressing rather than byte-based addressing. As a result,
> it is not compatible with the open firmware 'ns16550' compatible
> binding.
>
> This code adds the Xilinx uart 16550 to the serial console
> of the boot. A new initialization function for the Xilinx 16550 uart
> is added to the ns16550 driver. It sets up the correct register base
> and regshift properties specific to the Xilinx 16550.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> --- a/arch/powerpc/boot/ops.h
> +++ b/arch/powerpc/boot/ops.h
> @@ -86,6 +86,7 @@ int mpsc_console_init(void *devp, struct serial_console_data *scdp);
> int cpm_console_init(void *devp, struct serial_console_data *scdp);
> int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp);
> int uartlite_console_init(void *devp, struct serial_console_data *scdp);
> +int xilinx16550_console_init(void *devp, struct serial_console_data *scdp);
> void *simple_alloc_init(char *base, unsigned long heap_size,
> unsigned long granularity, unsigned long max_allocs);
> extern void flush_cache(void *, unsigned long);
> diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
> index 7fa5078..fb5c91e 100644
> --- a/arch/powerpc/boot/serial.c
> +++ b/arch/powerpc/boot/serial.c
> @@ -131,6 +131,14 @@ int serial_console_init(void)
> else if (dt_is_compatible(devp, "xlnx,opb-uartlite-1.00.b") ||
> dt_is_compatible(devp, "xlnx,xps-uartlite-1.00.a"))
> rc = uartlite_console_init(devp, &serial_cd);
> + else if (dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.c") ||
> + dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.d") ||
> + dt_is_compatible(devp, "xlnx,opb-uart16550-1.00.e") ||
> + dt_is_compatible(devp, "xlnx,plb-uart16550-1.00.c") ||
> + dt_is_compatible(devp, "xlnx,xps-uart16550-1.00.a") ||
> + dt_is_compatible(devp, "xlnx,xps-uart16550-2.00.a") ||
> + dt_is_compatible(devp, "xlnx,xps-uart16550-2.00.b"))
> + rc = xilinx16550_console_init(devp, &serial_cd);
I'll review this whole patch set today, but I need to make this
comment now. Adding to this ever increasing list of xilinx device
versions is not sustainable. A common base compatible value needs to
be chosen instead. Way back in the mists of time something line
"sparse16550" was suggested and I think it is a good one. xilinx uart
nodes should claim compatibility with their specific version *and*
"sparse16550". Then all this code should only match with
"sparse16550" and documentation should be added to
Documentation/powerpc/booting-without-of.txt to describe what
sparse16550 means.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Scott Wood @ 2008-03-20 15:08 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803201439.59806.laurentp@cse-semaphore.com>
On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> I'm working on a patch. I'm not sure how to handle the early udbg printk
> problem, so the first version will just ignore it.
udbg printk is extremely useful... I'd not be fond of it breaking.
Perhaps we should stick more initialization into the cpm udbg code, so it
isn't so dependent on the bootloader setup... though we'd have push the
CPM reset and SMC allocation earlier in such a case.
-Scott
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Mauro Carvalho Chehab @ 2008-03-20 15:14 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Theodore Tso, Greg KH, LKML, linuxppc-dev,
linux-next, Paul Mackerras, v4l-dvb-maintainer, Dan Williams
In-Reply-To: <20080319212121.9705ca9a.randy.dunlap@oracle.com>
On Wed, 19 Mar 2008 21:21:21 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Thu, 20 Mar 2008 14:39:53 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > (tar balls at
> > http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
>
> gcc doesn't like nested /* comments:
>
> next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3030:38: warning: "/*" within comment
> next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3032:20: warning: "/*" within comment
Andrew already did a patch for this. I'll import on my tree.
>
> ---
> ~Randy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Mauro
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Kumar Gala @ 2008-03-20 15:15 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080317195305.GA13298@aepfle.de>
On Mar 17, 2008, at 2:53 PM, Olaf Hering wrote:
>
> 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:
>
> 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");
We should look and see if we can change init_ipic_sysfs() from a
subsys_initcall() to just getting called at the end of ipic_init().
- k
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-20 15:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080320150823.GB31587@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Thursday 20 March 2008 16:08, Scott Wood wrote:
> On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> > I'm working on a patch. I'm not sure how to handle the early udbg printk
> > problem, so the first version will just ignore it.
>
> udbg printk is extremely useful... I'd not be fond of it breaking.
I don't want to kill it either. What I meant is that my first patch will not
care about udbg so that I can get feedback about the CPM serial driver part.
I'll then see how to make udbg fit into that.
> Perhaps we should stick more initialization into the cpm udbg code, so it
> isn't so dependent on the bootloader setup... though we'd have push the
> CPM reset and SMC allocation earlier in such a case.
When SMC1 is used as a serial console, SMC1 is the first CPM dpram allocation
user. This means the CPM dpram allocator will allocate a buffer at the
beginning of the dpram. As he SMC controller will already be using the 64
first bytes of the dpram, it will not see any difference when being
reinitialized.
This of course depends on the boot loader allocating parameter ram at the
beginning of the dpram for SMC1, but we already depend on that if I'm not
mistaken.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Anatolij Gustschin @ 2008-03-20 15:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <47E2723D.1090101@grandegger.com>
Hello Wolfgang,
Wolfgang Grandegger wrote:
> I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
> oops. Are there any known patches fixing the problems?
try the patch below for tqm5200.dts, rebuild dtb and boot
again. Not sure if it works for Linux 2.6.25-rc6, but for
2.6.25-rc3 it does.
Anatolij
--
diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
index c86464f..7c23bb3 100644
--- a/arch/powerpc/boot/dts/tqm5200.dts
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -83,6 +83,7 @@
};
dma-controller@1200 {
+ device_type = "dma-controller";
compatible = "fsl,mpc5200-bestcomm";
reg = <1200 80>;
interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
@@ -127,10 +128,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
ata@3a00 {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox