Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Tue, 2006-12-05 at 18:37 +0100, Wolfgang Grandegger wrote: Jan Kiszka wrote: Wolfgang Grandegger wrote: Benjamin Zores wrote: On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new "genirq" interface, in contrast to the powerpc tree (that's what you have realized as well). Well, i guess the old "ppc" arch is bound to die sooner or later. New developments should always be done against "powerpc" arch imho. Well, the powerpc tree is still highly experimental and only a few embedded boards are already supported. I guess it will take a long time before the ppc tree finally gets buried, especially because porting is not really trivial (due to OF, IRQ layer, etc.), Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? Unfortunately, "generic" applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. How comes? I haven't found time to analyse this for the latest x86 patch, but there it should be "more generic" than before. Do you think this is a genirq issue or an I-pipe problem? Well, it's nothing serious and we should discuss this issue in a separated thread. I just wanted to have a closer look to the new port before asking. At a first glance I saw that the irq_chip structure has two new elements, ipipe_ack and ipipe_eoi. This requires patching of every PIC interface. There are a few for x86 but plenty for PowerPC. Philippe, is this really necessary? I would prefer the old style using "#ifndef CONFIG_IPIPE" around the "chip->ack" in common code. As just replied to Jan, this is a matter of the arch maintainer's taste. If you ask me, I would see no issue changing kernel/irq/chip.c on a per-port basis, for implementing the best/safest approach. Changes in the I-pipe core layer are not likely to happen there, anyway, so I don't see any maintenance hell showing up because we fork the implementation there. OK, I actually prefer a common solution. When I have my Icecube board up and running with the powerpc tree (I'm fighting hard), I'm going to work on this topic. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Tue, 2006-12-05 at 18:37 +0100, Wolfgang Grandegger wrote: > Jan Kiszka wrote: > > Wolfgang Grandegger wrote: > >> Benjamin Zores wrote: > >>> On Tue, 05 Dec 2006 11:17:07 +0100 > >>> Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >>> > I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The > porting was rather straight-forward, as the ppc tree does not use the > new "genirq" interface, in contrast to the powerpc tree (that's what > you have realized as well). > >>> Well, i guess the old "ppc" arch is bound to die sooner or later. > >>> New developments should always be done against "powerpc" arch imho. > >> Well, the powerpc tree is still highly experimental and only a few > >> embedded boards are already supported. I guess it will take a long time > >> before the ppc tree finally gets buried, especially because porting is > >> not really trivial (due to OF, IRQ layer, etc.), > >> > Therefore the port of the powerpc tree should be based on Philippe's > new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not > have a board by hand supported by the powerpc tree. > >>> I haven't had much much time investigating the problem till now. > >>> But from what i've seen from Philippe's splitted patches, many of them > >>> that were supposed to be generic (i.e. don't have i386 in their name) > >>> still have references to x86 changes. > >>> Is it a normal behavior ? > >> Unfortunately, "generic" applies only to the Linux part. I realized, > >> that the new IPIPE support for the genirqs requires even more > >> arch-specific modifications than the old interface :-( on PowerPC. > > > > How comes? I haven't found time to analyse this for the latest x86 > > patch, but there it should be "more generic" than before. Do you think > > this is a genirq issue or an I-pipe problem? > > Well, it's nothing serious and we should discuss this issue in a > separated thread. I just wanted to have a closer look to the new port > before asking. At a first glance I saw that the irq_chip structure has > two new elements, ipipe_ack and ipipe_eoi. This requires patching of > every PIC interface. There are a few for x86 but plenty for PowerPC. > Philippe, is this really necessary? I would prefer the old style using > "#ifndef CONFIG_IPIPE" around the "chip->ack" in common code. As just replied to Jan, this is a matter of the arch maintainer's taste. If you ask me, I would see no issue changing kernel/irq/chip.c on a per-port basis, for implementing the best/safest approach. Changes in the I-pipe core layer are not likely to happen there, anyway, so I don't see any maintenance hell showing up because we fork the implementation there. > > Wolfgang, > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Tue, 05 Dec 2006 14:09:38 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Unfortunately, "generic" applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. That's pretty bad news :-( Well, but that part is not really tricky. Have you ever worked with that board under 2.6? It is not even well supported by the old ppc tree and you need patches, which are available somewhere but still require extra tweaking. I have such a board on my table and if I'm lucky, I will get U-Boot with OF support up and booting Linux PowerPC 2.6.19 ... but I need plenty of luck. Nope, but i've seen recent commits for better support on kernel git for upcoming 2.6.20. Yes, but till now it was not working out of the box. Btw, Freescale have GIT trees for UBoot with support for many of their CPUs (and support for OF as well). See http://opensource.freescale.com/ OK, Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Jan Kiszka wrote: Wolfgang Grandegger wrote: Benjamin Zores wrote: On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new "genirq" interface, in contrast to the powerpc tree (that's what you have realized as well). Well, i guess the old "ppc" arch is bound to die sooner or later. New developments should always be done against "powerpc" arch imho. Well, the powerpc tree is still highly experimental and only a few embedded boards are already supported. I guess it will take a long time before the ppc tree finally gets buried, especially because porting is not really trivial (due to OF, IRQ layer, etc.), Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? Unfortunately, "generic" applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. How comes? I haven't found time to analyse this for the latest x86 patch, but there it should be "more generic" than before. Do you think this is a genirq issue or an I-pipe problem? Well, it's nothing serious and we should discuss this issue in a separated thread. I just wanted to have a closer look to the new port before asking. At a first glance I saw that the irq_chip structure has two new elements, ipipe_ack and ipipe_eoi. This requires patching of every PIC interface. There are a few for x86 but plenty for PowerPC. Philippe, is this really necessary? I would prefer the old style using "#ifndef CONFIG_IPIPE" around the "chip->ack" in common code. Wolfgang, ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Wolfgang Grandegger wrote: > Benjamin Zores wrote: >> On Tue, 05 Dec 2006 11:17:07 +0100 >> Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> >>> I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The >>> porting was rather straight-forward, as the ppc tree does not use the >>> new "genirq" interface, in contrast to the powerpc tree (that's what >>> you have realized as well). >> >> Well, i guess the old "ppc" arch is bound to die sooner or later. >> New developments should always be done against "powerpc" arch imho. > > Well, the powerpc tree is still highly experimental and only a few > embedded boards are already supported. I guess it will take a long time > before the ppc tree finally gets buried, especially because porting is > not really trivial (due to OF, IRQ layer, etc.), > >>> Therefore the port of the powerpc tree should be based on Philippe's >>> new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not >>> have a board by hand supported by the powerpc tree. >> >> I haven't had much much time investigating the problem till now. >> But from what i've seen from Philippe's splitted patches, many of them >> that were supposed to be generic (i.e. don't have i386 in their name) >> still have references to x86 changes. >> Is it a normal behavior ? > > Unfortunately, "generic" applies only to the Linux part. I realized, > that the new IPIPE support for the genirqs requires even more > arch-specific modifications than the old interface :-( on PowerPC. How comes? I haven't found time to analyse this for the latest x86 patch, but there it should be "more generic" than before. Do you think this is a genirq issue or an I-pipe problem? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Tue, 05 Dec 2006 14:09:38 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > Unfortunately, "generic" applies only to the Linux part. I realized, > that the new IPIPE support for the genirqs requires even more > arch-specific modifications than the old interface :-( on PowerPC. That's pretty bad news :-( > Have you ever worked with that board under 2.6? It is not even well > supported by the old ppc tree and you need patches, which are available > somewhere but still require extra tweaking. I have such a board on my > table and if I'm lucky, I will get U-Boot with OF support up and booting > Linux PowerPC 2.6.19 ... but I need plenty of luck. Nope, but i've seen recent commits for better support on kernel git for upcoming 2.6.20. Btw, Freescale have GIT trees for UBoot with support for many of their CPUs (and support for OF as well). See http://opensource.freescale.com/ Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new "genirq" interface, in contrast to the powerpc tree (that's what you have realized as well). Well, i guess the old "ppc" arch is bound to die sooner or later. New developments should always be done against "powerpc" arch imho. Well, the powerpc tree is still highly experimental and only a few embedded boards are already supported. I guess it will take a long time before the ppc tree finally gets buried, especially because porting is not really trivial (due to OF, IRQ layer, etc.), Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? Unfortunately, "generic" applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. (about dev board, no one's developing on lite5200 or sth like that ?) Have you ever worked with that board under 2.6? It is not even well supported by the old ppc tree and you need patches, which are available somewhere but still require extra tweaking. I have such a board on my table and if I'm lucky, I will get U-Boot with OF support up and booting Linux PowerPC 2.6.19 ... but I need plenty of luck. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The > porting was rather straight-forward, as the ppc tree does not use the > new "genirq" interface, in contrast to the powerpc tree (that's what you > have realized as well). Well, i guess the old "ppc" arch is bound to die sooner or later. New developments should always be done against "powerpc" arch imho. > Therefore the port of the powerpc tree should be based on Philippe's new > adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a > board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? (about dev board, no one's developing on lite5200 or sth like that ?) Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. OK. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new "genirq" interface, in contrast to the powerpc tree (that's what you have realized as well). (i.e. something i can work from to adapt my new patch) Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: > On Sat, 2006-12-02 at 18:37 +0100, Wolfgang Grandegger wrote: >> Philippe Gerum wrote: >>> On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: > On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: >> On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: >> >>> Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 >>> by Philippe. I recently had the chance to test it and hack a bit on the >>> SMP IO-APIC part. It seems to work fine under UP, but SMP had some >>> issues that are identified, but still need to be addressed - thanks to >>> genirq, now in a widely arch-independent way. >>> >>> Philippe, I know you are very busy, but shouldn't we make a pre-release >>> available already, also to discuss further how to deal best with genirq >>> on other platforms beyond x86? >> Actually, the draft patch I sent you did not boot on my SMP box today, >> so qemu seems to have been a bit too friendly. Knowing that, issuing a >> half-baked patch would have made no sense, so I finally refrained from >> doing that. Since I'm now basically in love with the genirq layer (at >> least for x86) compared to the utter mess that we had to endure >> previously, I've decided to tackle the issue completely, and rewrite the >> I-pipe interrupt flow in order to leverage it. Will post something asap. >> > Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been > tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron > 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, > and even passed the horrid "dohell" test on the SMP box, just smiling. > However, I don't have the required hw at hand to check if our friend the > MSI support is not killing us once more. This said, the MSI support in > 2.6.19 also conforms to the genirq specs, so there's hope. > > The patch is available from the Adeos download area, and I've also > committed it to the SVN trunk/. > > Feedback welcome, > > PS: I have the corresponding quilt-managed patches available upon > request, to the people who want to use this work as a reference for > porting to other archs. You mean that you have separate patches for the common and arch dependent part. >>> Mostly, yes. The patches are split by function, but this usually >>> correlates with the noarch / arch-specific break down view too. >>> That would be nice. I'm interested! >>> http://download.gna.org/adeos/patches/v2.6/i386/split/ >>> As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. >>> Problem is that we would have to store a set of patches for each Adeos >>> version/arch combo, instead of a single one. What advantage do you see >>> in breaking the Adeos patches down for prepare-kernel.sh? >> Maintenance issues for the noarch part, e.g., if you fix a bug in the >> common part or add new features it's available for all arch. > > I think this should be easier once we have moved to git, pulling commits > is made simple (yeah, I'm late on this too...) Ah, I just read the keyword: git! ;) Rough idea from my side on a potential organisation of the git trees: o A generic I-pipe core tree that primarily targets git head (i.e. 2.6) o One branch for git head, pulls both from Linus' tree and the I-pipe core o One tree for each major 2.6 version in maintenance mode, pulls from related stable branch and I-pipe core (when applicable) o Only if required: a generic I-pipe core tree for 2.4 o One tree for 2.4 head to maintain x86 o One tree for 2.4 ELDK to maintain PPC Quite a lot trees... Do you this this may work? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sat, 2006-12-02 at 18:37 +0100, Wolfgang Grandegger wrote: > Philippe Gerum wrote: > > On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: > >> Philippe Gerum wrote: > >>> On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: > On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: > > > Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 > > by Philippe. I recently had the chance to test it and hack a bit on the > > SMP IO-APIC part. It seems to work fine under UP, but SMP had some > > issues that are identified, but still need to be addressed - thanks to > > genirq, now in a widely arch-independent way. > > > > Philippe, I know you are very busy, but shouldn't we make a pre-release > > available already, also to discuss further how to deal best with genirq > > on other platforms beyond x86? > Actually, the draft patch I sent you did not boot on my SMP box today, > so qemu seems to have been a bit too friendly. Knowing that, issuing a > half-baked patch would have made no sense, so I finally refrained from > doing that. Since I'm now basically in love with the genirq layer (at > least for x86) compared to the utter mess that we had to endure > previously, I've decided to tackle the issue completely, and rewrite the > I-pipe interrupt flow in order to leverage it. Will post something asap. > > >>> Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been > >>> tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron > >>> 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, > >>> and even passed the horrid "dohell" test on the SMP box, just smiling. > >>> However, I don't have the required hw at hand to check if our friend the > >>> MSI support is not killing us once more. This said, the MSI support in > >>> 2.6.19 also conforms to the genirq specs, so there's hope. > >>> > >>> The patch is available from the Adeos download area, and I've also > >>> committed it to the SVN trunk/. > >>> > >>> Feedback welcome, > >>> > >>> PS: I have the corresponding quilt-managed patches available upon > >>> request, to the people who want to use this work as a reference for > >>> porting to other archs. > >> You mean that you have separate patches for the common and arch > >> dependent part. > > > > Mostly, yes. The patches are split by function, but this usually > > correlates with the noarch / arch-specific break down view too. > > > >> That would be nice. I'm interested! > > > > http://download.gna.org/adeos/patches/v2.6/i386/split/ > > > >> As a consequence we > >> could provide separated patches in general and prepare-kernel.sh applies > >> them in sequence. Just an idea for the future. > >> > > > > Problem is that we would have to store a set of patches for each Adeos > > version/arch combo, instead of a single one. What advantage do you see > > in breaking the Adeos patches down for prepare-kernel.sh? > > Maintenance issues for the noarch part, e.g., if you fix a bug in the > common part or add new features it's available for all arch. I think this should be easier once we have moved to git, pulling commits is made simple (yeah, I'm late on this too...) > But I see > your point. It's a bit more complicated and there are also patch version > numbers. > > Wolfgang. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid "dohell" test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Maintenance issues for the noarch part, e.g., if you fix a bug in the common part or add new features it's available for all arch. But I see your point. It's a bit more complicated and there are also patch version numbers. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: > Philippe Gerum wrote: > > On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: > >> On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: > >> > >>> Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 > >>> by Philippe. I recently had the chance to test it and hack a bit on the > >>> SMP IO-APIC part. It seems to work fine under UP, but SMP had some > >>> issues that are identified, but still need to be addressed - thanks to > >>> genirq, now in a widely arch-independent way. > >>> > >>> Philippe, I know you are very busy, but shouldn't we make a pre-release > >>> available already, also to discuss further how to deal best with genirq > >>> on other platforms beyond x86? > >> Actually, the draft patch I sent you did not boot on my SMP box today, > >> so qemu seems to have been a bit too friendly. Knowing that, issuing a > >> half-baked patch would have made no sense, so I finally refrained from > >> doing that. Since I'm now basically in love with the genirq layer (at > >> least for x86) compared to the utter mess that we had to endure > >> previously, I've decided to tackle the issue completely, and rewrite the > >> I-pipe interrupt flow in order to leverage it. Will post something asap. > >> > > > > Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been > > tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron > > 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, > > and even passed the horrid "dohell" test on the SMP box, just smiling. > > However, I don't have the required hw at hand to check if our friend the > > MSI support is not killing us once more. This said, the MSI support in > > 2.6.19 also conforms to the genirq specs, so there's hope. > > > > The patch is available from the Adeos download area, and I've also > > committed it to the SVN trunk/. > > > > Feedback welcome, > > > > PS: I have the corresponding quilt-managed patches available upon > > request, to the people who want to use this work as a reference for > > porting to other archs. > > You mean that you have separate patches for the common and arch > dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. > That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ > As a consequence we > could provide separated patches in general and prepare-kernel.sh applies > them in sequence. Just an idea for the future. > Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? > Wolfgang. > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid "dohell" test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. That would be nice. I'm interested! As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: > On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: > > > Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 > > by Philippe. I recently had the chance to test it and hack a bit on the > > SMP IO-APIC part. It seems to work fine under UP, but SMP had some > > issues that are identified, but still need to be addressed - thanks to > > genirq, now in a widely arch-independent way. > > > > Philippe, I know you are very busy, but shouldn't we make a pre-release > > available already, also to discuss further how to deal best with genirq > > on other platforms beyond x86? > > Actually, the draft patch I sent you did not boot on my SMP box today, > so qemu seems to have been a bit too friendly. Knowing that, issuing a > half-baked patch would have made no sense, so I finally refrained from > doing that. Since I'm now basically in love with the genirq layer (at > least for x86) compared to the utter mess that we had to endure > previously, I've decided to tackle the issue completely, and rewrite the > I-pipe interrupt flow in order to leverage it. Will post something asap. > Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid "dohell" test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: > Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 > by Philippe. I recently had the chance to test it and hack a bit on the > SMP IO-APIC part. It seems to work fine under UP, but SMP had some > issues that are identified, but still need to be addressed - thanks to > genirq, now in a widely arch-independent way. > > Philippe, I know you are very busy, but shouldn't we make a pre-release > available already, also to discuss further how to deal best with genirq > on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Paul wrote: > On Thursday 30 November 2006 13:19, Jan Kiszka wrote: >> Philippe, I know you are very busy, but shouldn't we make a pre-release >> available already, also to discuss further how to deal best with genirq >> on other platforms beyond x86? > > I have an x86_64 box waiting for a Xenomai port - I don't see much point in > hacking 2.6.17 and earlier when 2.6.19 is going to be a major change in key > areas.. It also looks like there is a closer integration of x86_64 and plain > old ix86 code in the 2.6.19 tree, so this may simplify the task of > maintaining a 64bit patch. For sure, there is not much point in starting on old code (the "stable" 2.6.16 series /may/ turn out to be an exception one day). An x86_64 port will be highly welcome! Feel invited to post I-pipe related topics also to [EMAIL PROTECTED] One hint that may ease testing/debugging: Have a look at qemu for x86_64. At least on x86, it already helped me a lot to debug weird kernel issues without long run-instrument-build-rerun cycles. All it takes is a minimal system image for a target. You can easily attach a debugger to the kernel, and you can even emulate SMP (though debugging is not perfect in that case). Of course, you cannot identify latency issues this way, but you will likely already be happy when things don't crash anymore. :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Thursday 30 November 2006 13:19, Jan Kiszka wrote: > Philippe, I know you are very busy, but shouldn't we make a pre-release > available already, also to discuss further how to deal best with genirq > on other platforms beyond x86? I have an x86_64 box waiting for a Xenomai port - I don't see much point in hacking 2.6.17 and earlier when 2.6.19 is going to be a major change in key areas.. It also looks like there is a closer integration of x86_64 and plain old ix86 code in the 2.6.19 tree, so this may simplify the task of maintaining a 64bit patch. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Benjamin Zores wrote: >>> On Mon, 27 Nov 2006 13:11:23 +0100 >>> Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >>> Benjamin Zores wrote: > On Mon, 27 Nov 2006 12:21:25 +0100 > Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >>> Well, I hack a bit my patch to make it compile and the kernel >>> already booted. >>> Though it hangs when loading the SATA driver. >>> I have no idea why atm. >> Problems with IRQs? > Probably, as when unplugging the SATA drive, the boot goes further > but then hang at USB detection (both are handlign IRQs a lot i guess). > Would be interesting if someone could test on other board than just > mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. >>> The 2.6.19 having been released out, and working much better on my card >>> than the vanilla 2.6.18 used to be, I'm now more kind to adapt my >>> patch to >>> this latest kernel. >>> >>> However the IRQ handling API seem to have changed a lot >>> and i was wondering if some work on porting Adeos >>> (x86/ppc, not yet powerpc of course) patches already have been started >>> by someone here ? >> >> I don't see that PPC is converted to genirq, that new API. And I'm not >> sure (while not being a PPC expert) if it ever will be, specifically as >> PowerPC is already on genirq and should obsolete PPC one day, right? > > No, or at least partially wrong. I have to check what the new, fully > implemented genirq does. But I realized, that the common IRQ structure > is used now (resulting in some name changes, w.g. ->handler ->chip). > Likely, PPC and PowerPC already use the new genirq. It is likely used under PPC as far it has to be: renamed structures, moved information. But the core issue is if the flow handling (edge, level, simple etc.) also moved to kernel/irq/chip.c, and that looks to me like only being the case for PowerPC. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. I know this problem very well. The PowerPC Linux kernel is currently a fast moving target and 2.6.19 breaks the Adeos-IPIPE ppc patch again, grrr. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? (i.e. something i can work from to adapt my new patch) I will have a look when time permits. Hopefully end of this week. If I'm lucky, I may get the PowerPC tree up and running on my Lite5200. There are already some promising patches around. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Jan Kiszka wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? I don't see that PPC is converted to genirq, that new API. And I'm not sure (while not being a PPC expert) if it ever will be, specifically as PowerPC is already on genirq and should obsolete PPC one day, right? No, or at least partially wrong. I have to check what the new, fully implemented genirq does. But I realized, that the common IRQ structure is used now (resulting in some name changes, w.g. ->handler ->chip). Likely, PPC and PowerPC already use the new genirq. Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: > On Mon, 27 Nov 2006 13:11:23 +0100 > Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >> Benjamin Zores wrote: >>> On Mon, 27 Nov 2006 12:21:25 +0100 >>> Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >>> > Well, I hack a bit my patch to make it compile and the kernel already > booted. > Though it hangs when loading the SATA driver. > I have no idea why atm. Problems with IRQs? >>> Probably, as when unplugging the SATA drive, the boot goes further >>> but then hang at USB detection (both are handlign IRQs a lot i guess). >>> Would be interesting if someone could test on other board than just mine. >> As I pointed out in my previous mail, the IRQ handling is not yet >> correct for powerpc. Try to correct his first. > > The 2.6.19 having been released out, and working much better on my card > than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to > this latest kernel. > > However the IRQ handling API seem to have changed a lot > and i was wondering if some work on porting Adeos > (x86/ppc, not yet powerpc of course) patches already have been started > by someone here ? I don't see that PPC is converted to genirq, that new API. And I'm not sure (while not being a PPC expert) if it ever will be, specifically as PowerPC is already on genirq and should obsolete PPC one day, right? Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > Benjamin Zores wrote: > > On Mon, 27 Nov 2006 12:21:25 +0100 > > Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > > > >>> Well, I hack a bit my patch to make it compile and the kernel already > >>> booted. > >>> Though it hangs when loading the SATA driver. > >>> I have no idea why atm. > >> Problems with IRQs? > > > > Probably, as when unplugging the SATA drive, the boot goes further > > but then hang at USB detection (both are handlign IRQs a lot i guess). > > Would be interesting if someone could test on other board than just mine. > > As I pointed out in my previous mail, the IRQ handling is not yet > correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? (i.e. something i can work from to adapt my new patch) Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > > Well, I hack a bit my patch to make it compile and the kernel already > > booted. > > Though it hangs when loading the SATA driver. > > I have no idea why atm. > > Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Sun, 26 Nov 2006 20:10:17 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: - NR_IRQS is not defined. This is a problem with the include weirdness due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh, that's overkill (but not our problem for the time being). Indeed it seemed so. On my private tree, i've fixed/redefined it to 512 to have it compile (ugly hack though). Yes, beause you need "irq.h" sooner than later in IPIPE files. _ipipe_grab_irq(): special IRQ numbers have changed. Check for NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a more detailed review (check irq.c in the powerpc tree). - disarm_decr[] has disappeared. It was used to disable the programming of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs an appropriate replacement in the powerpc tree. A quick, untested hack is in the attached patch. I'll try to check on that. Hope this helps you to get a bit further (kernel booted). Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sun, 26 Nov 2006 20:10:17 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > - NR_IRQS is not defined. This is a problem with the include weirdness > due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh, > that's overkill (but not our problem for the time being). Indeed it seemed so. On my private tree, i've fixed/redefined it to 512 to have it compile (ugly hack though). > _ipipe_grab_irq(): special IRQ numbers have changed. Check for > NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a > more detailed review (check irq.c in the powerpc tree). > > - disarm_decr[] has disappeared. It was used to disable the programming > of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs > an appropriate replacement in the powerpc tree. A quick, untested hack > is in the attached patch. I'll try to check on that. > Hope this helps you to get a bit further (kernel booted). Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Forgot to attach the patch, sorry.
Wolfgang.
Wolfgang Grandegger wrote:
Benjamin Zores wrote:
On Fri, 24 Nov 2006 11:13:03 +0100
Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
Yes, the PowerPC tree is not yet supported.
Yes but as i need it now i've decided to port it ;-)
Or at least of a try.
Good, :-)
You might have realized my hack to get ride of radix-tree.h for the
ppc tree.
Actually not, have some patch ?
For the ppc tree, I have added
#ifdef CONFIG_PPC_MERGE
#include
#endif
to include/powerpc/irq.h to get rid of the trouble with radix-tree.h.
What defconfig do you use? Unfortunately I do not have a board by
hand supported by the PowerPC tree.
mpc834x_itx_defconfig
I briefly reviewed your patch. At a first glance, it looks OK, but it is
not yet complete and it does not compile. Quickly, I spotted the
following problems:
- NR_IRQS is not defined. This is a problem with the include weirdness
due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh,
that's overkill (but not our problem for the time being).
_ipipe_grab_irq(): special IRQ numbers have changed. Check for
NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a
more detailed review (check irq.c in the powerpc tree).
- disarm_decr[] has disappeared. It was used to disable the programming
of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs
an appropriate replacement in the powerpc tree. A quick, untested hack
is in the attached patch.
There might be more issues.
We should also avoid code duplication of IPIPE files, but that's
something I will fix later-on.
Hope this helps you to get a bit further (kernel booted).
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Index: linux-2.6.18/arch/powerpc/kernel/time.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/time.c
+++ linux-2.6.18/arch/powerpc/kernel/time.c
@@ -699,9 +699,15 @@ void timer_interrupt(struct pt_regs * re
}
write_sequnlock(&xtime_lock);
}
-
+#ifdef CONFIG_IPIPE
+ if (__ipipe_decr_ticks == tb_ticks_per_jiffy) {
+ next_dec = tb_ticks_per_jiffy - ticks;
+ set_dec(next_dec);
+ }
+#else /* !CONFIG_IPIPE */
next_dec = tb_ticks_per_jiffy - ticks;
set_dec(next_dec);
+#endif /* CONFIG_IPIPE */
#ifdef CONFIG_PPC_ISERIES
if (hvlpevent_is_pending())
Index: linux-2.6.18/arch/powerpc/kernel/ipipe-core.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/ipipe-core.c
+++ linux-2.6.18/arch/powerpc/kernel/ipipe-core.c
@@ -224,7 +224,6 @@ static void __ipipe_set_decr(void)
ipipe_load_cpuid();
- disarm_decr[cpuid] = (__ipipe_decr_ticks != tb_ticks_per_jiffy);
#ifdef CONFIG_40x
/* Enable and set auto-reload. */
mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
Index: linux-2.6.18/arch/powerpc/kernel/ipipe-root.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/ipipe-root.c
+++ linux-2.6.18/arch/powerpc/kernel/ipipe-root.c
@@ -314,7 +314,9 @@ int __ipipe_grab_irq(struct pt_regs *reg
ipipe_declare_cpuid;
int irq;
- if ((irq = ppc_md.get_irq(regs)) >= 0) {
+ irq = ppc_md.get_irq(regs);
+
+ if (irq != NO_IRQ && irq != NO_IRQ_IGNORE) {
#ifdef CONFIG_IPIPE_TRACE_IRQSOFF
ipipe_trace_begin(irq);
#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */
@@ -323,7 +325,7 @@ int __ipipe_grab_irq(struct pt_regs *reg
ipipe_trace_end(irq);
#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */
}
- else if (irq != -2)
+ else if (irq != NO_IRQ_IGNORE)
ppc_spurious_interrupts++;
ipipe_load_cpuid();
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Fri, 24 Nov 2006 11:13:03 +0100 Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Yes, the PowerPC tree is not yet supported. Yes but as i need it now i've decided to port it ;-) Or at least of a try. Good, :-) You might have realized my hack to get ride of radix-tree.h for the ppc tree. Actually not, have some patch ? For the ppc tree, I have added #ifdef CONFIG_PPC_MERGE #include #endif to include/powerpc/irq.h to get rid of the trouble with radix-tree.h. What defconfig do you use? Unfortunately I do not have a board by hand supported by the PowerPC tree. mpc834x_itx_defconfig I briefly reviewed your patch. At a first glance, it looks OK, but it is not yet complete and it does not compile. Quickly, I spotted the following problems: - NR_IRQS is not defined. This is a problem with the include weirdness due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh, that's overkill (but not our problem for the time being). _ipipe_grab_irq(): special IRQ numbers have changed. Check for NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a more detailed review (check irq.c in the powerpc tree). - disarm_decr[] has disappeared. It was used to disable the programming of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs an appropriate replacement in the powerpc tree. A quick, untested hack is in the attached patch. There might be more issues. We should also avoid code duplication of IPIPE files, but that's something I will fix later-on. Hope this helps you to get a bit further (kernel booted). Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: Hi, I've downloaded latest Adeos/Ipipe patch for PPC and unfortunately this latest doesn't (yet) support the ARCH=powerpc architecture from kernel but only the PPC one. Yes, the PowerPC tree is not yet supported. I've tried porting the changes to support the PPC_MERGE and be able to still use Xenomai on 2.6.18 with ARCH=powerpc. Nice. Attached is a patch that has to be applied after regular adeos-2.6.18-ppc patch to extends supports for PowerPC. Please consider it for review only right now as it might not yet compiles to the end (i'm facing problems with includes inter-race which required me to change the radix-tree.h header file which is something i don't want to). You might have realized my hack to get ride of radix-tree.h for the ppc tree. I also have problems booting my latest kernel with this patch on (but booting regular 2.6.18 in merged PowerPC architecture already is a hassle atm) and I'd like you to help me know whether it cames from my patch's content or not. What defconfig do you use? Unfortunately I do not have a board by hand supported by the PowerPC tree. FYI, I've tried to port all Adeos architecture dependant parts but i only focused on PPC32 (PPC64 support might be in but i won't test on it). I'm also trying to boot an MPC8349 chip but i don't think I'll have to address anything with it as it used to work with Xenomai on 2.6.14. Thanks for the review, I will have a look a.s.s.p. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
