PPC to PowerPC Migration

PPC to PowerPC Migration

[Andy Schmidt]

I am wondering if anyone has seen any good documentation for migrating
from the arch/ppc to arch/powerpc.  Specifically, I am working with a
Xilinx board so I am more accustom to the xparamters.h vs. device
trees.  I am very willing to build a (or multiple) tutorials to help
others in my situation, I just need some initial help getting started.
 If anyone can point me in the right direction, I will be sure to keep
the group (or those interested) updated on the documentation.

Thank you,
Andrew

RE: PPC to PowerPC Migration

[John Linn]

Hi Andrew,

We have a git server with the kernel running on the ML405 (V4) and ML507
(V5) Xilinx boards with arch/powerpc at git://git.xilinx.com.

The default configuration, using ml507_defconfig or ml405_defconfig,
uses a static device tree located in the arch/powerpc/boot/dts
directory.

>make ARCH=3Dpowerpc zImage
>make ARCH=3Dpowerpc zImage.initrd (for a ramdisk image, after putting
ramdisk image in arch/powerpc/boot directory)

zImage file is located in arch/powerpc/boot directory.

On the http://git.xilinx.com site, there's some tar files with a bit
stream to match the default kernel configuration.

Maybe this is not what you're looking for, but thought I'd offer. Others
have used this to get their own boards running with Linux.

Look at Documentation/powerpc/booting-without-of.txt for some device
tree information.

Thanks,
John Linn
Linux Development & Strategy

Xilinx is looking for more embedded Linux developers.

-----Original Message-----
From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org] On
Behalf Of Andy Schmidt
Sent: Tuesday, June 10, 2008 11:49 AM
To: linuxppc-embedded@ozlabs.org
Subject: PPC to PowerPC Migration

I am wondering if anyone has seen any good documentation for migrating
from the arch/ppc to arch/powerpc.  Specifically, I am working with a
Xilinx board so I am more accustom to the xparamters.h vs. device
trees.  I am very willing to build a (or multiple) tutorials to help
others in my situation, I just need some initial help getting started.
 If anyone can point me in the right direction, I will be sure to keep
the group (or those interested) updated on the documentation.

Thank you,
Andrew
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

RE: PPC to PowerPC Migration

[Mike Timmons]

Great Idea Andrew. I am no long-serving expert, but over the past few
years I've had some ARM-linux and more recently mpc5200 Linux exposure.
For the mpc5200 we started as ppc under 2.6.16 a few months ago. I
recently migrated to 2.6.24 with ARCH=3Dpowerpc.

These were the conceptual difficulties I had at first:

1) Where the *%$# are the register address defines?
	-Ahhh, the register definition header file maps to HW via the
device tree. Cool. Now how the $%# do I interface to the tree from my
drivers?
3) How do I request an IRQ?
  You need to create a "device" in the device tree. This is
non-intuitive because most of what you see in the tree when you start
represents actual, "devices": SOC peripherals and such. I looked and
looked for how to request
IRQ3. It was so easy when I created a, "device" and specified the
interrupt according to instructions in
Documentation/powerpc/mpc5200xx-device-tree-bindings.txt.txt
4) How do I traverse the device tree from my code: my device drivers?
  -functions like mpc52xx_find_and_map("name_from_dev_tree") are used to
map peripheral registers to the relevant defined struct from your
register definition header file.
 - Also look for, "open firmware" (of) functions like
irq_of_parse_and_map(node,0).
- basically, the "find_and_map", and "parse_and_map" means your driver
is traversing the device tree data. Grep on this sort of thing to find
examples
Of how various drivers interface to the device tree info.

This is all very simple for so many of you, but I did wrestle with some
conceptual difficulties. Andrew, if this makes any sense to you perhaps
you
Can roll it into your HOWTO. Perhaps we can collaborate offline and
publish something more useful than what I just wrote above.

-Mike

=20
-----Original Message-----
From: linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org]
On Behalf Of Andy Schmidt
Sent: Tuesday, June 10, 2008 12:49 PM
To: linuxppc-embedded@ozlabs.org
Subject: PPC to PowerPC Migration

I am wondering if anyone has seen any good documentation for migrating
from the arch/ppc to arch/powerpc.  Specifically, I am working with a
Xilinx board so I am more accustom to the xparamters.h vs. device
trees.  I am very willing to build a (or multiple) tutorials to help
others in my situation, I just need some initial help getting started.
 If anyone can point me in the right direction, I will be sure to keep
the group (or those interested) updated on the documentation.

Thank you,
Andrew
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: PPC to PowerPC Migration

[vb]

I recently ported two platforms (8245 and 8541) from ppc tree in
earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
little the device tree contents are described, a lot of things
required reverse engineering of the kernel code to understand the
meaning of some numbers in the  tree.

I am also willing to contribute into a document describing this
transition, please keep me in the loop,

regards,
Vadim



On Tue, Jun 10, 2008 at 6:19 PM, Mike Timmons <mike_timmons@trimble.com> wrote:
> Great Idea Andrew. I am no long-serving expert, but over the past few
> years I've had some ARM-linux and more recently mpc5200 Linux exposure.
> For the mpc5200 we started as ppc under 2.6.16 a few months ago. I
> recently migrated to 2.6.24 with ARCH=powerpc.
>
> These were the conceptual difficulties I had at first:
>
> 1) Where the *%$# are the register address defines?
>        -Ahhh, the register definition header file maps to HW via the
> device tree. Cool. Now how the $%# do I interface to the tree from my
> drivers?
> 3) How do I request an IRQ?
>  You need to create a "device" in the device tree. This is
> non-intuitive because most of what you see in the tree when you start
> represents actual, "devices": SOC peripherals and such. I looked and
> looked for how to request
> IRQ3. It was so easy when I created a, "device" and specified the
> interrupt according to instructions in
> Documentation/powerpc/mpc5200xx-device-tree-bindings.txt.txt
> 4) How do I traverse the device tree from my code: my device drivers?
>  -functions like mpc52xx_find_and_map("name_from_dev_tree") are used to
> map peripheral registers to the relevant defined struct from your
> register definition header file.
>  - Also look for, "open firmware" (of) functions like
> irq_of_parse_and_map(node,0).
> - basically, the "find_and_map", and "parse_and_map" means your driver
> is traversing the device tree data. Grep on this sort of thing to find
> examples
> Of how various drivers interface to the device tree info.
>
> This is all very simple for so many of you, but I did wrestle with some
> conceptual difficulties. Andrew, if this makes any sense to you perhaps
> you
> Can roll it into your HOWTO. Perhaps we can collaborate offline and
> publish something more useful than what I just wrote above.
>
> -Mike
>
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org]
> On Behalf Of Andy Schmidt
> Sent: Tuesday, June 10, 2008 12:49 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: PPC to PowerPC Migration
>
> I am wondering if anyone has seen any good documentation for migrating
> from the arch/ppc to arch/powerpc.  Specifically, I am working with a
> Xilinx board so I am more accustom to the xparamters.h vs. device
> trees.  I am very willing to build a (or multiple) tutorials to help
> others in my situation, I just need some initial help getting started.
>  If anyone can point me in the right direction, I will be sure to keep
> the group (or those interested) updated on the documentation.
>
> Thank you,
> Andrew
> _______________________________________________
> 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
>

Re: PPC to PowerPC Migration

[Jon Loeliger]

vb wrote:
> I recently ported two platforms (8245 and 8541) from ppc tree in
> earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
> little the device tree contents are described, a lot of things
> required reverse engineering of the kernel code to understand the
> meaning of some numbers in the  tree.
> 
> I am also willing to contribute into a document describing this
> transition, please keep me in the loop,
> 
> regards,
> Vadim


Well, perhaps as a starting point you could tell us
which things required reverse engineering or what you
were not able to find in a document?

Thanks,
jdl

Re: PPC to PowerPC Migration

[vb]

On Wed, Jun 11, 2008 at 7:03 AM, Jon Loeliger <jdl@freescale.com> wrote:
> vb wrote:
>>
>> I recently ported two platforms (8245 and 8541) from ppc tree in
>> earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
>> little the device tree contents are described, a lot of things
>> required reverse engineering of the kernel code to understand the
>> meaning of some numbers in the  tree.
>>
>> I am also willing to contribute into a document describing this
>> transition, please keep me in the loop,
>>
>> regards,
>> Vadim
>
>
> Well, perhaps as a starting point you could tell us
> which things required reverse engineering or what you
> were not able to find in a document?
>


wow, where do I begin here :-)

my favorite was interrupt-map in PCI section:  A typical value would
look like this:

                interrupt-map = <

                        /* IDSEL 0x10 */
                        08000 0 0 1 &mpic 0 1
                        08000 0 0 2 &mpic 1 1
                        08000 0 0 3 &mpic 2 1
                        08000 0 0 4 &mpic 3 1


                        [ repeated per IDSEL ]

               >

I don't see 'interrupt-map' mentioned anywhere in the ./Documentation
tree - it took me a while to find out what these numbers actually
meant.

cheers,
Vadim



> Thanks,
> jdl
>

RE: PPC to PowerPC Migration

[Darcy Watkins]

Hello,

And ... for mini PCI, you only have two entries per IDSEL instead of the
usual four.

Regards,

Darcy


--snip!--

my favorite was interrupt-map in PCI section:  A typical value would
look like this:

                interrupt-map =3D <

                        /* IDSEL 0x10 */
                        08000 0 0 1 &mpic 0 1
                        08000 0 0 2 &mpic 1 1
                        08000 0 0 3 &mpic 2 1
                        08000 0 0 4 &mpic 3 1


                        [ repeated per IDSEL ]

               >

I don't see 'interrupt-map' mentioned anywhere in the ./Documentation
tree - it took me a while to find out what these numbers actually
meant.

cheers,
Vadim

--snip!--

Re: PPC to PowerPC Migration

[vb]

On Wed, Jun 11, 2008 at 8:45 AM, Darcy Watkins <DWatkins@tranzeo.com> wrote:
> Hello,
>
> And ... for mini PCI, you only have two entries per IDSEL instead of the
> usual four.
>
And of course in reality you need just one! :-)
/vb

> Regards,
>
> Darcy
>
>
> --snip!--
>
> my favorite was interrupt-map in PCI section:  A typical value would
> look like this:
>
>                interrupt-map = <
>
>                        /* IDSEL 0x10 */
>                        08000 0 0 1 &mpic 0 1
>                        08000 0 0 2 &mpic 1 1
>                        08000 0 0 3 &mpic 2 1
>                        08000 0 0 4 &mpic 3 1
>
>
>                        [ repeated per IDSEL ]
>
>               >
>
> I don't see 'interrupt-map' mentioned anywhere in the ./Documentation
> tree - it took me a while to find out what these numbers actually
> meant.
>
> cheers,
> Vadim
>
> --snip!--
>

Re: PPC to PowerPC Migration

[Scott Wood]

On Wed, Jun 11, 2008 at 08:33:57AM -0700, vb wrote:
> my favorite was interrupt-map in PCI section:  A typical value would
> look like this:
> 
>                 interrupt-map = <
> 
>                         /* IDSEL 0x10 */
>                         08000 0 0 1 &mpic 0 1
>                         08000 0 0 2 &mpic 1 1
>                         08000 0 0 3 &mpic 2 1
>                         08000 0 0 4 &mpic 3 1
> 
> 
>                         [ repeated per IDSEL ]
> 
>                >
> 
> I don't see 'interrupt-map' mentioned anywhere in the ./Documentation
> tree - it took me a while to find out what these numbers actually
> meant.

It's documented here:
http://playground.sun.com/1275/practice/#imap

Once the ePAPR document is released, there'll be an all-in-one document,
but for now the documentation is somewhat scattered.

-Scott

RE: PPC to PowerPC Migration

[Darcy Watkins]

Hello,

I recently migrated an AMCC PPC405EP system from arch/ppc to
arch/powerpc and found that in kernel 2.6.25, my board support patches
have reduced to just the board support patches - approx 20k bytes in
size (and one small one-line fix needed when using RT Preemption
kernel).  Compare this with 2.6.24 and earlier where I had to apply
patches to complete the PPC405EP and/or arch/powerpc support.
   Prior to 2.6.23 had to use non kernel.org kernel sources and
arch/ppc.
   2.6.23 --> patch file size 400k+
   2.6.24 --> patch file size ~80k
   2.6.25 --> patch file size ~20k
   2.6.26 --> patch file size ~20k

I think that with 2.6.25 (and upcoming 2.6.26) this means that 4xx is
ready for prime time in arch/powerpc.

One other note though, for IBM I2C Driver 2.2 you need to use 2.6.26
release candidates (or apply a patch to back port it).  The 2.1 driver
appears to be arch/ppc (IBM_OCP based) only.

The only real downer is that the native posix thread library (NPTL)
being added to the upcoming uclibc won't support PowerPC (at least not
yet).

Getting more to the topic, when you get into preparing this document,
keep me in the loop too please.  I may be able to contribute something
to it as well.  Thanks in advance.

Regards,

Darcy


-----Original Message-----
From: linuxppc-embedded-bounces+dwatkins=3Dtranzeo.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+dwatkins=3Dtranzeo.com@ozlabs.org] On
Behalf Of vb
Sent: Wednesday, June 11, 2008 6:56 AM
To: Mike Timmons
Cc: Andy Schmidt; linuxppc-embedded@ozlabs.org
Subject: Re: PPC to PowerPC Migration

I recently ported two platforms (8245 and 8541) from ppc tree in
earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
little the device tree contents are described, a lot of things
required reverse engineering of the kernel code to understand the
meaning of some numbers in the  tree.

I am also willing to contribute into a document describing this
transition, please keep me in the loop,

regards,
Vadim



On Tue, Jun 10, 2008 at 6:19 PM, Mike Timmons <mike_timmons@trimble.com>
wrote:
> Great Idea Andrew. I am no long-serving expert, but over the past few
> years I've had some ARM-linux and more recently mpc5200 Linux
exposure.
> For the mpc5200 we started as ppc under 2.6.16 a few months ago. I
> recently migrated to 2.6.24 with ARCH=3Dpowerpc.

--snip!--

Re: PPC to PowerPC Migration

[Josh Boyer]

On Wed, 11 Jun 2008 07:38:44 -0700
"Darcy Watkins" <DWatkins@tranzeo.com> wrote:

> Hello,
> 
> I recently migrated an AMCC PPC405EP system from arch/ppc to
> arch/powerpc and found that in kernel 2.6.25, my board support patches
> have reduced to just the board support patches - approx 20k bytes in
> size (and one small one-line fix needed when using RT Preemption
> kernel).  Compare this with 2.6.24 and earlier where I had to apply
> patches to complete the PPC405EP and/or arch/powerpc support.
>    Prior to 2.6.23 had to use non kernel.org kernel sources and
> arch/ppc.
>    2.6.23 --> patch file size 400k+
>    2.6.24 --> patch file size ~80k
>    2.6.25 --> patch file size ~20k
>    2.6.26 --> patch file size ~20k
> 
> I think that with 2.6.25 (and upcoming 2.6.26) this means that 4xx is
> ready for prime time in arch/powerpc.

Did you post your patch for your board port?  If not, please do.  If
so, kindly point me to it so I can look at merging it into mainline?

josh

RE: PPC to PowerPC Migration

[Darcy Watkins]

Hi Josh,

I think it would be more helpful if I were to tidy it a bit and add AMCC
Taihu boot support to it first.  Then submit it.  People are more likely
to have access to a Taihu than one of our boards.

What I mean by "AMCC Taihu boot support" is that the board would come up
just like our Taihushui/Kolsch family of boards, but would not include
the extra drivers, etc needed for USB gadgets, the LCD and other like
items that are on the AMCC board.

Once I get this done, I can submit BSP patch sets for kernel 2.6.25 and
2.6.26.  If there is demand, I could submit a BSP patch set for 2.6.24
as well.

Please send me (or URL to) summarized patch submission instructions /
guidelines.


Regards,


Darcy

-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com] On Behalf Of Josh Boyer
Sent: Wednesday, June 11, 2008 9:33 AM
To: Darcy Watkins
Cc: vb; Mike Timmons; Andy Schmidt; linuxppc-embedded@ozlabs.org
Subject: Re: PPC to PowerPC Migration

On Wed, 11 Jun 2008 07:38:44 -0700
"Darcy Watkins" <DWatkins@tranzeo.com> wrote:

> Hello,
>=20
> I recently migrated an AMCC PPC405EP system from arch/ppc to
> arch/powerpc and found that in kernel 2.6.25, my board support patches
> have reduced to just the board support patches - approx 20k bytes in
> size (and one small one-line fix needed when using RT Preemption
> kernel).  Compare this with 2.6.24 and earlier where I had to apply
> patches to complete the PPC405EP and/or arch/powerpc support.
>    Prior to 2.6.23 had to use non kernel.org kernel sources and
> arch/ppc.
>    2.6.23 --> patch file size 400k+
>    2.6.24 --> patch file size ~80k
>    2.6.25 --> patch file size ~20k
>    2.6.26 --> patch file size ~20k
>=20
> I think that with 2.6.25 (and upcoming 2.6.26) this means that 4xx is
> ready for prime time in arch/powerpc.

Did you post your patch for your board port?  If not, please do.  If
so, kindly point me to it so I can look at merging it into mainline?

josh

No virus found in this incoming message.
Checked by AVG.=20
Version: 8.0.100 / Virus Database: 270.2.0/1497 - Release Date:
6/11/2008 8:32 AM

Re: PPC to PowerPC Migration

[Josh Boyer]

On Wed, 11 Jun 2008 10:15:03 -0700
"Darcy Watkins" <DWatkins@tranzeo.com> wrote:

> Hi Josh,
> 
> I think it would be more helpful if I were to tidy it a bit and add AMCC
> Taihu boot support to it first.  Then submit it.  People are more likely
> to have access to a Taihu than one of our boards.
> 
> What I mean by "AMCC Taihu boot support" is that the board would come up
> just like our Taihushui/Kolsch family of boards, but would not include
> the extra drivers, etc needed for USB gadgets, the LCD and other like
> items that are on the AMCC board.

That sounds like a fine plan.  If you'd like, you can submit both at
the same time (as separate patches).  More board ports are always
welcome, particularly for stock eval boards.

> Once I get this done, I can submit BSP patch sets for kernel 2.6.25 and
> 2.6.26.  If there is demand, I could submit a BSP patch set for 2.6.24
> as well.

Preferably, you'd submit to the tip of the git tree for 4xx.  With the
pace of kernel development, releasing patches for "old" kernels just
means that someone has to forward port them to the latest tree.  That
might be a small effort, but in practice it's best to work with
bleeding edge if you're going to submit a patch for inclusion.

Don't be discouraged by that.  There are those that will help you if
you run into obstacles.

> Please send me (or URL to) summarized patch submission instructions /
> guidelines.

The easiest place to start is Documentation/SubmittingPatches in the
kernel tree.

josh

RE: PPC to PowerPC Migration

[Darcy Watkins]

Hi Josh,

Is there a special git tree for 4xx or are you referring to kernel.org?
... or do I just post the patches to this list?

Regards,

Darcy


--snip!--
> Once I get this done, I can submit BSP patch sets for kernel 2.6.25
and
> 2.6.26.  If there is demand, I could submit a BSP patch set for 2.6.24
> as well.

Preferably, you'd submit to the tip of the git tree for 4xx.  With the
pace of kernel development, releasing patches for "old" kernels just
means that someone has to forward port them to the latest tree.  That
might be a small effort, but in practice it's best to work with
bleeding edge if you're going to submit a patch for inclusion.

Don't be discouraged by that.  There are those that will help you if
you run into obstacles.
--snip!--

Re: PPC to PowerPC Migration

[Josh Boyer]

On Wed, 11 Jun 2008 10:52:13 -0700
"Darcy Watkins" <DWatkins@tranzeo.com> wrote:

> Hi Josh,
> 
> Is there a special git tree for 4xx or are you referring to kernel.org?
> ... or do I just post the patches to this list?

http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=summary

You can clone it with:

git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git

The 'next' branch contains the current stuff heading into whatever is
the next merge window (which right now would be 2.6.27.

You can post patches here, but most of them go to the linuxppc-dev list
now.

josh

Re: PPC to PowerPC Migration

[Darcy Watkins]

Hello,

I am posting these patches mainly to test that my Linux email client can
handle preformat properly (without breaking the lines), but it may be of
use to anyone using 2.6.24 or 2.6.25 kernel with RT-Preemption on a 4xx
processor that has a UIC (just so I don't clutter the list with a
useless test post).  This is all that was left to carry forward from
some much larger patches I received a while back for use with 2.6.23.

Use this patch with kernel 2.6.24

Index: linux-2.6.24.4/arch/powerpc/sysdev/uic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux-2.6.24.4.orig/arch/powerpc/sysdev/uic.c
+++ linux-2.6.24.4/arch/powerpc/sysdev/uic.c
@@ -49,7 +49,7 @@ struct uic {
 	int index;
 	int dcrbase;
=20
-	spinlock_t lock;
+	raw_spinlock_t lock;
=20
 	/* The remapper for this UIC */
 	struct irq_host	*irqhost;
@@ -60,14 +60,19 @@ struct uic {
=20
 static void uic_unmask_irq(unsigned int virq)
 {
+	struct irq_desc *desc =3D get_irq_desc(virq);
 	struct uic *uic =3D get_irq_chip_data(virq);
 	unsigned int src =3D uic_irq_to_hw(virq);
 	unsigned long flags;
-	u32 er;
+	u32 er, sr;
=20
+	sr =3D 1 << (31-src);
 	spin_lock_irqsave(&uic->lock, flags);
+	/* ack level-triggered interrupts here */
+	if (desc->status & IRQ_LEVEL)
+		mtdcr(uic->dcrbase + UIC_SR, sr);
 	er =3D mfdcr(uic->dcrbase + UIC_ER);
-	er |=3D 1 << (31 - src);
+	er |=3D sr;
 	mtdcr(uic->dcrbase + UIC_ER, er);
 	spin_unlock_irqrestore(&uic->lock, flags);
 }
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
=20
 static void uic_mask_ack_irq(unsigned int virq)
 {
+	struct irq_desc *desc =3D get_irq_desc(virq);
 	struct uic *uic =3D get_irq_chip_data(virq);
 	unsigned int src =3D uic_irq_to_hw(virq);
 	unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
 	er =3D mfdcr(uic->dcrbase + UIC_ER);
 	er &=3D ~sr;
 	mtdcr(uic->dcrbase + UIC_ER, er);
-	mtdcr(uic->dcrbase + UIC_SR, sr);
+	/* On the UIC, acking (i.e. clearing the SR bit)
+	 * a level irq will have no effect if the interrupt
+	 * is still asserted by the device, even if
+	 * the interrupt is already masked. Therefore
+	 * we only ack the egde interrupts here, while
+	 * level interrupts are ack'ed after the actual
+	 * isr call in the uic_unmask_irq()
+	 */
+	if (!(desc->status & IRQ_LEVEL))
+		mtdcr(uic->dcrbase + UIC_SR, sr);
 	spin_unlock_irqrestore(&uic->lock, flags);
 }
=20
@@ -173,6 +188,7 @@ static struct irq_chip uic_irq_chip =3D {
 	.set_type	=3D uic_set_irq_type,
 };
=20
+#if 0
 /**
  *	handle_uic_irq - irq flow handler for UIC
  *	@irq:	the interrupt number
@@ -230,6 +246,7 @@ void fastcall handle_uic_irq(unsigned in
 out_unlock:
 	spin_unlock(&desc->lock);
 }
+#endif
=20
 static int uic_host_map(struct irq_host *h, unsigned int virq,
 			irq_hw_number_t hw)
@@ -239,7 +256,7 @@ static int uic_host_map(struct irq_host=20
 	set_irq_chip_data(virq, uic);
 	/* Despite the name, handle_level_irq() works for both level
 	 * and edge irqs on UIC.  FIXME: check this is correct */
-	set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
+	set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
=20
 	/* Set default irq type */
 	set_irq_type(virq, IRQ_TYPE_NONE);


Use this patch if using kernel 2.6.25


--- linux-2.6.25.4/arch/powerpc/sysdev/uic.c.theorig	2008-05-15 08:00:12.00=
0000000 -0700
+++ linux-2.6.25.4/arch/powerpc/sysdev/uic.c	2008-05-20 12:37:39.000000000 =
-0700
@@ -49,7 +49,7 @@ struct uic {
 	int index;
 	int dcrbase;
=20
-	spinlock_t lock;
+	raw_spinlock_t lock;
=20
 	/* The remapper for this UIC */
 	struct irq_host	*irqhost;

=EF=BB=BFApply the selected patch after applying the RT-Preemption patch to=
 your
kernel.

In terms of upstream projects - the 2.6.25 patch should eventually make
its way up into the RT preemption project patches (if not done already
for next release) but should not go to kernel.org since I don't know how
it would affect the kernel without RT-Preemption.  Why the change above
didn't make it with the rest of the changes, I don't know - perhaps the
kernel oops it solves affected only a narrow range of processors (e.g.
PPC405EP).

--=20


Regards,

Darcy

--------------
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com

Re: PPC to PowerPC Migration

[Andrew Schmidt]

First off, thank you everyone for replying, I must admit I was only  
expecting a few people to reply, but this is great.  I certainly am  
interested in any help I can get.  I suspect my first task is to go  
over the information given and then start to draft up a simple text  
file.  I am more experienced with the Xilinx PPC so initially the  
documentation may seems a little biased, but if anyone with other  
areas of expertise (as is evident from the emails received thus far)  
wants to help broaden it, that would be great.  I will get back to  
you shortly with my first "attempt."

Thanks,
Andrew

Re: PPC to PowerPC Migration

[Jens Wirth]

On Wed, Jun 11, 2008 at 9:36 PM, Andrew Schmidt
<andrewgschmidt@gmail.com> wrote:
> First off, thank you everyone for replying, I must admit I was only
> expecting a few people to reply, but this is great.  I certainly am
> interested in any help I can get.  I suspect my first task is to go over the
> information given and then start to draft up a simple text file.  I am more
> experienced with the Xilinx PPC so initially the documentation may seems a
> little biased, but if anyone with other areas of expertise (as is evident
> from the emails received thus far) wants to help broaden it, that would be
> great.  I will get back to you shortly with my first "attempt."

I'm currently working with a custom design on a Xilinx ML300 board
to evaluate the realtime capabilities of the linux kernel with rt-patches.
Since this is my first experience with embedded Linux I had the most
trouble with understanding the coherences of the most general stuff
like the difference between ppc and powerpc as well as the need for
a device tree within powerpc but not ppc. Everything is documented
very well for it's own, but I would appreciate to see a documentation
that gives a bit more overview to the subject which is important for
beginners.

Well, I'm going to document my work from the system design using
EDK and ISE through to creating a running linux from scratch based
on this design. I'd like to support your documentation as much as I can.

Regards,
Jens Wirth

Re: PPC to PowerPC Migration

[Grant Likely]

On Wed, Jun 11, 2008 at 1:36 PM, Andrew Schmidt
<andrewgschmidt@gmail.com> wrote:
> First off, thank you everyone for replying, I must admit I was only
> expecting a few people to reply, but this is great.  I certainly am
> interested in any help I can get.  I suspect my first task is to go over the
> information given and then start to draft up a simple text file.  I am more
> experienced with the Xilinx PPC so initially the documentation may seems a
> little biased, but if anyone with other areas of expertise (as is evident
> from the emails received thus far) wants to help broaden it, that would be
> great.  I will get back to you shortly with my first "attempt."

Documentation/powerpc/booting-without-of.txt is the place to start
adding additional documentation.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.