I-pipe for 2.6.32 PPC
Subsystems (25)
Philippe, all
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
TIA::Bernhard
Quoted 6 lines · Bernhard Pfund
Philippe, all
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
Likely not before January.
Quoted 7 lines
TIA::Bernhard_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Zitat von Philippe Gerum <[email protected]>:
Quoted 8 lines · Bernhard Pfund
Quoted 6 lines
Philippe, all
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
Quoted 8 lines
Likely not before January.
Quoted 3 lines
TIA::Bernhard--
Philippe.
OK, thanks.
Bernhard
Quoted 4 lines · Bernhard Pfund
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
I got ipipe-2.6.30 running the p2020ds with minimal effort. I can post a diff if that might help you.
I should have my own p2020rdb soon...
I have noticed some unexplained freezes running xenomai programs on the p2020ds in SMP mode, but I have not yet had time to look into it. I hope we can work together to get SMP working reliably.
Richard
Quoted 6 lines · Richard Cochran
Quoted 4 lines · Bernhard Pfund
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
Quoted 8 lines
I got ipipe-2.6.30 running the p2020ds with minimal effort. I can post a diff if that might help you.
I should have my own p2020rdb soon...
I have noticed some unexplained freezes running xenomai programs on the p2020ds in SMP mode, but I have not yet had time to look into it. I hope we can work together to get SMP working reliably.
I'm working on fixing the pipeline for 2.6.32/ppc64, which includes SMP mode. 32bit looks ok in UP mode, but I still need to validate SMP there. So it would be great if you could hammer that patch over your P2020 as well once it's ready. ETA, early next week. I'll keep you informed about this.
Quoted 7 lines
Richard
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Quoted 12 lines · Philippe Gerum
Quoted 10 lines · Richard Cochran
Quoted 1 line · Bernhard Pfund
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
I got ipipe-2.6.30 running the p2020ds with minimal effort. I can post a diff if that might help you.
I should have my own p2020rdb soon...
I have noticed some unexplained freezes running xenomai programs on the p2020ds in SMP mode, but I have not yet had time to look into it. I hope we can work together to get SMP working reliably.
Quoted 5 lines
I'm working on fixing the pipeline for 2.6.32/ppc64, which includes SMP mode. 32bit looks ok in UP mode, but I still need to validate SMP there. So it would be great if you could hammer that patch over your P2020 as well once it's ready. ETA, early next week. I'll keep you informed about this.
Philippe, Richard
Due to a change of project priorities I'm currently working on a PPC750GX based system (which will require the same kernel and pipeline), but I still have the P2020RDB available, so I can (an will) test whatever you come up with ;)
Thanx for the ongoing efforts!
Bernhard
Quoted 16 lines · Philippe Gerum
Quoted 6 lines · Richard Cochran
Quoted 4 lines · Bernhard Pfund
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
Quoted 8 lines
I got ipipe-2.6.30 running the p2020ds with minimal effort. I can post a diff if that might help you.
I should have my own p2020rdb soon...
I have noticed some unexplained freezes running xenomai programs on the p2020ds in SMP mode, but I have not yet had time to look into it. I hope we can work together to get SMP working reliably.
Quoted 5 lines
I'm working on fixing the pipeline for 2.6.32/ppc64, which includes SMP mode. 32bit looks ok in UP mode, but I still need to validate SMP there. So it would be great if you could hammer that patch over your P2020 as well once it's ready. ETA, early next week. I'll keep you informed about this.
As expected, upgrading from 2.6.30 to 2.6.32 for ppc64 was a real pain. Anyway, here is a patch which applies against 2.6.32.2 mainline; it is pretty large because it also includes DENX-originated bits, from v2.6.32 to DENX-v2.6.32.
http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.32.2-powerpc-2.8-00.patch
This is expected to work over Xenomai 2.5.0. Tested over 52xx, 85xx, 4xx for the 32bit support, pasemi for the 64bit part. I did not manage to put my hands on a working ppc32/SMP board to give it a shot yet, so, well, I wish you luck. This said, ppc64/SMP has been validated, so there is hope.
Sidenote: ftrace may induce a massive stack consumption on ppc64 under certain circumstances, causing kernel stack overflows. A way to work around this should be to enable CONFIG_IRQSTACKS, but this won't work with Xenomai over ppc64 yet, albeit this does work over ppc32.
This patch is in a staging directory for now; waiting for some feedback to go further.
HTH,
Signature · 1 line
Philippe.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 42 lines · Lennart Sorensen
Quoted 41 lines · Philippe Gerum
Quoted 16 lines · Philippe Gerum
Quoted 6 lines · Richard Cochran
Quoted 4 lines · Bernhard Pfund
I'm currently working with a fairly new ppc development board (P2020RDB) by Freescale. The board's BSP went mainline with 2.6.32 and I'd like to deploy an I-pipe enabled DENX kernel for testing. Now, is there an I-pipe patch for said kernel on the release schedule anywhere soon?
Quoted 8 lines
I got ipipe-2.6.30 running the p2020ds with minimal effort. I can post a diff if that might help you.
I should have my own p2020rdb soon...
I have noticed some unexplained freezes running xenomai programs on the p2020ds in SMP mode, but I have not yet had time to look into it. I hope we can work together to get SMP working reliably.
Quoted 5 lines
I'm working on fixing the pipeline for 2.6.32/ppc64, which includes SMP mode. 32bit looks ok in UP mode, but I still need to validate SMP there. So it would be great if you could hammer that patch over your P2020 as well once it's ready. ETA, early next week. I'll keep you informed about this.
As expected, upgrading from 2.6.30 to 2.6.32 for ppc64 was a real pain. Anyway, here is a patch which applies against 2.6.32.2 mainline; it is pretty large because it also includes DENX-originated bits, from v2.6.32 to DENX-v2.6.32.
http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.32.2-powerpc-2.8-00.patch
This is expected to work over Xenomai 2.5.0. Tested over 52xx, 85xx, 4xx for the 32bit support, pasemi for the 64bit part. I did not manage to put my hands on a working ppc32/SMP board to give it a shot yet, so, well, I wish you luck. This said, ppc64/SMP has been validated, so there is hope.
Sidenote: ftrace may induce a massive stack consumption on ppc64 under certain circumstances, causing kernel stack overflows. A way to work around this should be to enable
CONFIG_IRQSTACKS, but this won't work with Xenomai over ppc64 yet, albeit this does work over ppc32.
Quoted 7 lines
Quoted 2 lines
This patch is in a staging directory for now; waiting for some feedback to go further.
Any chance of getting it without the DENX bits since some of us really really don't care for those and want to apply against Linus's releases only. Having the patch always fail to apply is rather annoying.
It turns out that it really, really annoys me not to have the DENX bits in when working on embedded powerpc targets, but you do have the option of cloning git://git.denx.de/ipipe-2.6.git, and diff whatever you see fit with commit 9d81556f or later.
Signature · 1 line
Philippe.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Lennart Sorensen
Quoted 26 lines · Philippe Gerum
Quoted 18 lines
Quoted 18 lines
As expected, upgrading from 2.6.30 to 2.6.32 for ppc64 was a real pain. Anyway, here is a patch which applies against 2.6.32.2 mainline; it is pretty large because it also includes DENX-originated bits, from v2.6.32 to DENX-v2.6.32.
http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.32.2-powerpc-2.8-00.patch
This is expected to work over Xenomai 2.5.0. Tested over 52xx, 85xx, 4xx for the 32bit support, pasemi for the 64bit part. I did not manage to put my hands on a working ppc32/SMP board to give it a shot yet, so, well, I wish you luck. This said, ppc64/SMP has been validated, so there is hope.
Sidenote: ftrace may induce a massive stack consumption on ppc64 under certain circumstances, causing kernel stack overflows. A way to work around this should be to enable
CONFIG_IRQSTACKS, but this won't work with Xenomai over ppc64 yet, albeit this does work over ppc32.Quoted 7 lines
Quoted 2 lines
This patch is in a staging directory for now; waiting for some feedback to go further.
Any chance of getting it without the DENX bits since some of us really really don't care for those and want to apply against Linus's releases only. Having the patch always fail to apply is rather annoying.
Quoted 4 lines
It turns out that it really, really annoys me not to have the DENX bits in when working on embedded powerpc targets, but you do have the option of cloning
git://git.denx.de/ipipe-2.6.git, and diff whatever you see fit with commit9d81556for later.It seems to me that releasing xenomai and ipipe releases that don't apply cleanly to official linux release versions is just rediculous. The x86 parts seem to work fine with Linus's releases, why should any other architecture be different? It is rather inconvinient for a lot of people.
Quoted 5 lines
I don't believe there is any clean way to generate an ipipe patch for Linus's official releases when they contain bits intended to go with the DENX tree. There are just too many changes all over the place.
This is likely because your knowledge overwhelms mine. I'm only a moron, so git diff with a proper commit number, or even patch -R does work for me. Simple things always work for simple idiots, it's a fact of life.
Quoted 3 lines
Users of the DENX tree are a tiny minority compared to the users of the official kernel releases. That majority should be the target of releases.
If you do think that the situation for x86 must be applicable to any other architecture, then I really can't do anything for you, except perhaps suggest to get your feet a bit more wet with those, and probably do some reality check against your knowledge of the embedded world.
Aside of this, I don't intend to get dragged into such a discussion, it's a pure loss of time. So please, take what I can offer, or just blame me for being an idiot to have a different perspective from yours, but don't waste my bandwidth. I need it direly to be able to issue patches you can use, even at the expense of cloning a git tree.
However, if you do think that some good reason might exist to work with DENX material when it comes to powerpc over embedded platforms, but want to help in issuing a mainline-based version of the pipeline patches regularly, then I would agree to ease your task.
So, instead of complaining about how things are not done the way you want, do you agree to help in changing this situation, or what?
Signature · 1 line
Philippe.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Lennart Sorensen
Well I have not been able to find the magic invocation that lets me take the DENX tree (which I have had around for a long time just to look at occationally, whenever I was trying to get an ipipe patch to apply), apply the ipipe patch, revert the DENX changes to get back to a release kernel, and generate a diff of the ipipe changes. It has never worked when I tried.
Lennart,
It is not so hard (using git) to remove the Denx patches from the ipipe tree. I did this myself for 2.6.30 in about a half an hour. If you don't know how to use git, then you would have to consider the additional time you need to get to understand it. (For me, it was only a year or so ;)
In the ipipe tree, the Denx commits have been "squashed" together into one or two really large commits. So, you can just cherry pick the adeos commits into a new branch, with a few minor fixups.
Philippe,
I actually agree with Lennart that the Denx stuff is an annoyance. When considering my "no-denx" branch that I made, I could not see any significant Denx change that adeos builds upon. There were a few Denx fixes for one specific board that were close to the adeos changes, but these were only a few, and easy to fix. So, I could not understand why Denx is a prerequisite for adeos.
I understand that Denx sponsored the original PowerPC Xenomai port. Is the reason that ipipe is based on Denx simply to honor that fact? If so, I would not think it a bad reason at all.
However, I would still prefer the following ordering for the changes:
1. stable linux (2.6.xx.y)
2. adeos arch indepedendent
3. adeos powerpc
4. denx
5. adeos for denx (minimal changes, I expect)
Richard
Quoted 20 lines · Richard Cochran
Quoted 6 lines · Lennart Sorensen
Well I have not been able to find the magic invocation that lets me take the DENX tree (which I have had around for a long time just to look at occationally, whenever I was trying to get an ipipe patch to apply), apply the ipipe patch, revert the DENX changes to get back to a release kernel, and generate a diff of the ipipe changes. It has never worked when I tried.
Lennart,
It is not so hard (using git) to remove the Denx patches from the ipipe tree. I did this myself for 2.6.30 in about a half an hour. If you don't know how to use git, then you would have to consider the additional time you need to get to understand it. (For me, it was only a year or so ;)
In the ipipe tree, the Denx commits have been "squashed" together into one or two really large commits. So, you can just cherry pick the adeos commits into a new branch, with a few minor fixups.
Quoted 9 lines
Philippe,
I actually agree with Lennart that the Denx stuff is an annoyance. When considering my "no-denx" branch that I made, I could not see any significant Denx change that adeos builds upon. There were a few Denx fixes for one specific board that were close to the adeos changes, but these were only a few, and easy to fix. So, I could not understand why Denx is a prerequisite for adeos.
As I explained earlier in my reply to Lennart, the DENX tree is not a pre-requisite for having the pipeline run on each and every hw platform, but this is still the case for some, because they are not stable/complete/good enough in mainline yet. The reason to stick with it stems from this fact.
What has to be reassessed, is the number of platforms Xenomai supports that still need DENX bits today; if only a few of them remain in this category, then it's probably sound to start maintaining the pipeline support for them in a separate tree, rebasing I-pipe mainline over Linux mainline for ppc as well. I have no issue with that.
Quoted 4 lines
I understand that Denx sponsored the original PowerPC Xenomai port. Is the reason that ipipe is based on Denx simply to honor that fact? If so, I would not think it a bad reason at all.
No, it's not, because if I had chosen to base the pipeline code for ppc over mainline at that time, I would have maintained a DENX-based version for the very reason you mentioned, until it proves useless.
Quoted 8 lines
However, I would still prefer the following ordering for the changes:
1. stable linux (2.6.xx.y)
2. adeos arch indepedendent
3. adeos powerpc
4. denx
5. adeos for denx (minimal changes, I expect)
What we may be aiming at, if workable, is something like:
ipipe-*-mainline
ipipe-*-amcc
ipipe-*-512x
Maybe one for the PA6T as well, if we want to keep supporting the old A2 board rev. I'm unsure right now, since B0 is fine in mainline already.
A mainline pipeline branch for everything that directly works over mainline, and platform-specific branches for those that do not. Those special branches would then disappear as soon as mainline is fine for the platforms they host as well.
Quoted 6 lines
Richard
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Dear Philippe,
Quoted 6 lines · in message <[email protected]> you wrote:
What we may be aiming at, if workable, is something like:
ipipe-*-mainline
ipipe-*-amcc
ipipe-*-512x
This sounds fine to me.
I guess we don't even need a 'ipipe-*-amcc' branch - the only things that should be in our tree but not in mainline are the Synopsis USB and S-ATA drivers (which are in such a state that they have no chance of being accepted for mainline), and these additional features are probably not of relevance for use with Xenomai.
ACK for 'ipipe-*-512x', but this is a work-in-progress tree, with the clear intention to push this stuff into mainline ASAP.
Quoted 2 lines
Maybe one for the PA6T as well, if we want to keep supporting the old A2 board rev. I'm unsure right now, since B0 is fine in mainline already.
Are there any significant differences between A2 and Bx as far as Xenomai in concerned? I mean, would a mainline patch (for Bx) be missing anything so it doesn't run on A2?
Quoted 4 lines
A mainline pipeline branch for everything that directly works over mainline, and platform-specific branches for those that do not. Those special branches would then disappear as soon as mainline is fine for the platforms they host as well.
I like this approach :-)
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] "We don't care. We don't have to. We're the Phone Company."
Quoted 10 lines · Wolfgang Denk
Dear Philippe,
Quoted 6 lines · in message <[email protected]> you wrote:
What we may be aiming at, if workable, is something like:
ipipe-*-mainline
ipipe-*-amcc
ipipe-*-512x
Quoted 8 lines
This sounds fine to me.
I guess we don't even need a 'ipipe-*-amcc' branch - the only things that should be in our tree but not in mainline are the Synopsis USB and S-ATA drivers (which are in such a state that they have no chance of being accepted for mainline), and these additional features are probably not of relevance for use with Xenomai.
The 8250 serial support put aside, I don't think we have any hunks in non-core Linux code, so we likely don't need this branch indeed.
Quoted 3 lines
ACK for 'ipipe-*-512x', but this is a work-in-progress tree, with the clear intention to push this stuff into mainline ASAP.
Ok.
Quoted 6 lines
Quoted 2 lines
Maybe one for the PA6T as well, if we want to keep supporting the old A2 board rev. I'm unsure right now, since B0 is fine in mainline already.
Are there any significant differences between A2 and Bx as far as Xenomai in concerned? I mean, would a mainline patch (for Bx) be missing anything so it doesn't run on A2?
Basically the work-arounds to fix the A2 errata; some of them have to be adapted to run in any context from the pipeline code (some bits in the process switching and tlbie handling code come to mind). This said, this could be solved by a supplemental patch moving those work-arounds on top of a mainline-based support.
Quoted 8 lines
Quoted 5 lines
A mainline pipeline branch for everything that directly works over mainline, and platform-specific branches for those that do not. Those special branches would then disappear as soon as mainline is fine for the platforms they host as well.
I like this approach :-)
Ok, thanks. ETA is in the 2.6.33 time frame.
Quoted 4 lines
Best regards,
Wolfgang Denk
Signature · 1 line
Philippe.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Lennart Sorensen
Quoted 11 lines · Philippe Gerum
As I explained earlier in my reply to Lennart, the DENX tree is not a pre-requisite for having the pipeline run on each and every hw platform, but this is still the case for some, because they are not stable/complete/good enough in mainline yet. The reason to stick with it stems from this fact.
What has to be reassessed, is the number of platforms Xenomai supports that still need DENX bits today; if only a few of them remain in this category, then it's probably sound to start maintaining the pipeline support for them in a separate tree, rebasing I-pipe mainline over Linux mainline for ppc as well. I have no issue with that.
Sounds great to me.
Quoted 6 lines
What we may be aiming at, if workable, is something like:
ipipe-*-mainline
ipipe-*-amcc
ipipe-*-512xQuoted 7 lines
Maybe one for the PA6T as well, if we want to keep supporting the old A2 board rev. I'm unsure right now, since B0 is fine in mainline already.
A mainline pipeline branch for everything that directly works over mainline, and platform-specific branches for those that do not. Those special branches would then disappear as soon as mainline is fine for the platforms they host as well.
I also noticed on Friday that applying both x86 and powerpc ipipe patches to one kernel tree is a bit problematic. Obviously both include the noarch section, but dealing with that is simple. The only actual problem that had to be solved is that both xenomai architectures try to include arch/<archname>/xenomai/Kconfig which conflict with each other. Merging the x86 and powerpc
Kconfigbits together in one file isn't hard and allows both to work with a single included file.
Quoted 8 lines
The reason I want this is that I very much intend to have a single 2.6.32 kernel source build with the same patches on both our x86 based embedded systems and our powerpc based embedded systems.
Is there any interest in getting such cleanup done to make the code just apply all together? If so I will try to finish adding the other architectures together too.
If you can make this work cleanly, while keeping the ability to separate arch-dep sections in different patches, I'm a taker. Even if having separate per-architecture patches is better for decoupling their release cycle (issuing a jumbo patch each time minor updates appear only in a single arch-dep section is not suitable), we could also provide an integrated patch by combining all per-arch bits and a single no-arch section.
Signature · 1 line
Philippe.
Quoted 11 lines · Lennart Sorensen
Quoted 3 lines · Philippe Gerum
This is likely because your knowledge overwhelms mine. I'm only a moron, so git diff with a proper commit number, or even patch -R does work for me. Simple things always work for simple idiots, it's a fact of life.
Well I have not been able to find the magic invocation that lets me take the DENX tree (which I have had around for a long time just to look at occationally, whenever I was trying to get an ipipe patch to apply), apply the ipipe patch, revert the DENX changes to get back to a release kernel, and generate a diff of the ipipe changes. It has never worked when I tried.
To get a complete pipeline, you need the -noarch side, and the -powerpc side. ipipe-2.6.32-powerpc is based on ipipe-2.6.32-noarch, which is based on v2.6.32 mainline. From the official I-pipe tree located there:git://git.denx.de/ipipe-2.6.git
$ git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpc
gives:
704529e powerpc/ipipe: arch-dependent bits for 2.6.32.2 2cc8efe Merge branch 'DENX-v2.6.32' into ipipe-2.6.32-newppc 01765d4 powerpc: merge DENX-v2.6.32 bits
ea15238 powerpc: merge 2.6.32.2 -stable
So, what you want is a merge between 2.6.32.2 mainline and the powerpc bits, skipping the DENX bits:
$ git checkout -b ipipe-mainline ipipe-2.6.32-noarch $ git cherry-pick ea15238 $ git cherry-pick 704529e
This will lead to two trivial rejects, one is in the ppc64 section you do not care about, the other in process.c, which is a hunk related to supporting the PA6T 64bit architecture as well, which you don't care about, either.
# unmerged: arch/powerpc/kernel/process.c
# unmerged: arch/powerpc/mm/hash_native_64.c
Basically, it's a 2 minutes work. Granted, it applies to 2.6.32.2 only, and more conflicts could pop up with different revisions of this work; but this has never been a massive pain to move from a DENX tree to mainline, and I did it quite a few times.
Quoted 6 lines
Quoted 5 lines
If you do think that the situation for x86 must be applicable to any other architecture, then I really can't do anything for you, except perhaps suggest to get your feet a bit more wet with those, and probably do some reality check against your knowledge of the embedded world.
Quoted 6 lines
Actually yes I think the x86 situation should be applicable to other architectures. I am currently running embedded x86, powerpc and coldfire, all using release kernels. That to me is a highly desirable goal. The coldfire was painful a year ago, but it sure has come a long way in that year.
x86 does not qualify for this discussion; with a x86-based system, even if the kernel at hand does not support the very latest fancy device you have on board, your kernel will likely still boot and run properly. On the other hand, you would not even try booting your mpc8360 over a kernel built for 44x. But given you want to support both, if either of both happen to be in a poor state in your reference tree, things start hitting the crapper. The DENX tree saved my day so far, because it allowed me to work on all powerpc platforms from a single code base.
Quoted 10 lines
Quoted 5 lines
Aside of this, I don't intend to get dragged into such a discussion, it's a pure loss of time. So please, take what I can offer, or just blame me for being an idiot to have a different perspective from yours, but don't waste my bandwidth. I need it direly to be able to issue patches you can use, even at the expense of cloning a git tree.
Well debian used to try and package xenomai. They are still on 2.4.8. I suspect they may have given up on it given that they only use release kernels, and many of the patches are useless in that case. What's the point of trying then.
The Blackfin uClinux distro was still shipping 2.4.7 in their latest 2009R1 release, albeit they merged the Blackfin-specific bits from the pipeline into their official kernel tree, many moons ago. Incidentally, I'm maintaining those bits for their development kernel directly feeding mainline, so I don't think your reasoning should be generalized.
This said, if you have first hand information from the Debian team regarding this, maybe you should tell them to drop us a note; we would be happy to help.
Quoted 10 lines
Quoted 5 lines
However, if you do think that some good reason might exist to work with DENX material when it comes to powerpc over embedded platforms, but want to help in issuing a mainline-based version of the pipeline patches regularly, then I would agree to ease your task.
Well I do work with embedded powerpc, and so far have had no use for the DENX tree. I have no idea what powerpc systems need stuff from the DENX tree to work, but certainly not the mpc8360 I deal with.
I understand your point from your perspective. But maintaining our code base for mpc8360 only is not enough for us.
The reason why the powerpc patches are DENX-based is simply that this tree worked for me over time, for various platforms (52xx, 4xx/44x, pa6t come to mind), way before mainline did. Xenomai supports recent platforms like the 512x series precisely because of that as well.
Does this mean that the pipeline patches will be based on the DENX tree until hell freezes? No, this does not, because the DENX folks are doing their job as well, and make their best to close the gap between their tree and mainline, taking all needed provisions to get their bits merged upstream sooner.
A sidenote though: you can run Xenomai over mpc8360 because DENX published this support which was initially based on their tree, on behalf of a customer, like a bunch of other developments:
http://www.denx.de/en/Software/SoftwareXenomaiProjects
This makes your argument, about not depending on anything being DENX-originated, sound a bit weird. Make no mistake, you owe them quite a few kudos. Actually, anyone running Xenomai over powerpc owe them a lot.
Quoted 6 lines
Quoted 2 lines
So, instead of complaining about how things are not done the way you want, do you agree to help in changing this situation, or what?
I did manage to port the 2.6.30-DENX patch to 2.6.32 pure tree rather successfully and sent it to the list. It did take a few hours.
You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards:
http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3
Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions.
Quoted 5 lines
Having a patch for the DENX tree is useful to some, but having a patch for the real Linux tree seems a lot more useful.
How about having both then?
I am willing to help deal with making the patch work on real kernels if that makes it easier.
That is good to hear. This said, the DENX tree is based on mainline like zillions of other trees, and as you certainly know, many of those trees are feeding mainline with arch-specific improvements and new platform or driver support. So the concepts of "real Linux tree" or "real kernel", "or pure tree" bear absolutely no value. The latest "pure" Linux tree probably dates back to 1994 or so.
Quoted 3 lines
At least then there would be something that could
be used by people using a single kernel tree for multiple architectures.
Publishing the DENX-based support on a separate branch for ppc platforms which have incomplete support upstream, along with a mainline-based branch for the rest, is something I could handle.
The way for you to help is certainly about testing the mainline-based branch which will probably appear for 2.6.33, and send feedback/fixes as/if needed.
Signature · 1 line
Philippe.
Hi Philippe,
Philippe Gerum wrote:
[snip]
Quoted 11 lines · Lennart Sorensen
You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards:
http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions.
Here is the story. Lennart mentioned on the linuxppc-dev mailing list, that he has a iPipe patch for 2.6.32:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079191.html
I asked him privately, if the patch is available and he sent it to me with the note, that I can publish it on the mailing list if I feel it's useful. This patch helped me to go ahead immediately with some related development work. I also forwarded the patch to you.
Wolfgang.
Quoted 16 lines · Wolfgang Grandegger
Hi Philippe,
Philippe Gerum wrote:
[snip]Quoted 11 lines · Lennart Sorensen
You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards:
http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions.
Quoted 8 lines
Here is the story. Lennart mentioned on the linuxppc-dev mailing list, that he has a iPipe patch for 2.6.32:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079191.htmlI asked him privately, if the patch is available and he sent it to me with the note, that I can publish it on the mailing list if I feel it's useful. This patch helped me to go ahead immediately with some related development work. I also forwarded the patch to you.
It must be stuck somewhere, I really can't find it in my mailbox. I'll check on my side again. Thanks.
Quoted 7 lines
Wolfgang.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Quoted 20 lines · Philippe Gerum
Quoted 19 lines · Wolfgang Grandegger
Hi Philippe,
Philippe Gerum wrote:
[snip]Quoted 11 lines · Lennart Sorensen
You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards:
http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions.
Here is the story. Lennart mentioned on the linuxppc-dev mailing list, that he has a iPipe patch for 2.6.32:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079191.html
Quoted 7 lines
Quoted 4 lines
I asked him privately, if the patch is available and he sent it to me with the note, that I can publish it on the mailing list if I feel it's useful. This patch helped me to go ahead immediately with some related development work. I also forwarded the patch to you.
It must be stuck somewhere, I really can't find it in my mailbox. I'll check on my side again. Thanks.
I can't find it either, sorry. Obviously I just put you on CC of the followup mail and forgot to forward the patch somehow. I have attached it now.
Sorry again for the confusion.
Wolfgang.
Quoted 4 lines · Wolfgang Grandegger
Interesting? I wanted to port the Adeos-Ipipe patch for PowerPC to 2.6.32 as well, as Philippe will need some more time to catch up. Would you dare to send your patch to me or the Xenomai mailing list for testing and intermediate solution?
Sure. I think I may have left out a tiny piece of ppc64 support that I couldn't understand, and didn't really care about since I use a 32bit ppc anyhow.
Of course mine is also based on Linus's 2.6.32 release, not the denx tree that is just different enough to be annoying.
As for the ucc_geth problem, that at least has now been resolved and was not ipipe related at all. A few boxes are running stress tests over the holidays right now.
I think I am missing something from head_64.S but everything else I believe I have managed to figure out. It booted on first try, so I was pretty pleased with it. I am using xenomai 2.4.10 with it along with one patch from the git tree for 2.4 as far as I remember.
Feel free to send it to the xenomai list or where it makes sense for comments or fixes or adoption as desired.
adeos-ipipe-2.6.32.1-powerpc.patch:
arch/powerpc/Kconfig +28 -0
@@ -130,6 +130,7 @@ select HAVE_SYSCALL_WRAPPERS if PPC64 select GENERIC_ATOMIC64 if PPC32 select HAVE_PERF_EVENTS + select HAVE_FUNCTION_TRACE_MCOUNT_TEST config EARLY_PRINTK bool
@@ -145,6 +146,10 @@ depends on COMPAT && SYSVIPC default y +config SOFTDISABLE + bool + default (PPC64 && !IPIPE) + # All PPC32s use generic nvram driver through ppc_md config GENERIC_NVRAM bool
@@ -249,6 +254,29 @@ menu "Kernel options" +source "kernel/ipipe/Kconfig" + +config IPIPE_HAVE_PREEMPTIBLE_SWITCH + bool + depends on IPIPE + default y + +if IPIPE +config RUNLATCH + bool "Enable RUNLATCH support" + depends on PPC64 + default n if IPIPE + ---help--- + This option is costly latency-wise, so default is to keep + it off when the interrupt pipeline is enabled. +endif +if !IPIPE +config RUNLATCH + bool + depends on PPC64 + default y +endif + config HIGHMEM bool "High memory support" depends on PPC32
arch/powerpc/boot/Makefile +8 -0
@@ -29,6 +29,14 @@ BOOTCFLAGS += -g endif +ifdef CONFIG_IPIPE_TRACE +# do not trace the boot loader +nullstring := +space := $(nullstring) # end of the line +pg_flag = $(nullstring) -pg # end of the line +BOOTCFLAGS := $(subst ${pg_flag},${space},${BOOTCFLAGS}) +endif + ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif
arch/powerpc/include/asm/exception-64s.h +67 -6
133 lines not on this page · raw message
arch/powerpc/include/asm/ftrace.h +15 -3
@@ -9,9 +9,21 @@/* Based off of objdump optput from glibc */ -#define MCOUNT_SAVE_FRAME \ - stwu r1,-48(r1); \ - stw r3, 12(r1); \ +#define MCOUNT_SAVE_FRAME \ + stwu r1,-48(r1); \ + stw r3, 12(r1); \ + LOAD_REG_IMMEDIATE(r3, function_trace_stop) \ + lwz r3, 0(r3); \ + cmpwi r3, 0; \ + lwz r3, 12(r1); \ + beq 1f; \ + mflr r0; \ + mtctr r0; \ + lwz r0, 52(r1); \ + mtlr r0; \ + addi r1, r1, 48; \ + bctr; \ +1: \ stw r4, 16(r1); \ stw r5, 20(r1); \ stw r6, 24(r1); \
arch/powerpc/include/asm/hw_irq.h +267 -12
318 lines not on this page · raw message
arch/powerpc/include/asm/ipipe.h +271 -0
271 lines not on this page · raw message
arch/powerpc/include/asm/ipipe_base.h +154 -0
154 lines not on this page · raw message
arch/powerpc/include/asm/irqflags.h +11 -1
@@ -10,7 +10,17 @@*/ #include <asm/hw_irq.h> -#else +#elif CONFIG_IPIPE +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +#define TRACE_DISABLE_INTS bl __ipipe_trace_irqson +#define TRACE_ENABLE_INTS bl __ipipe_trace_irqson +#define TRACE_DISABLE_INTS_REALLY bl __ipipe_trace_irqsoff +#else +#define TRACE_DISABLE_INTS +#define TRACE_ENABLE_INTS +#define TRACE_DISABLE_INTS_REALLY +#endif +#else /* !CONFIG_IPIPE */ #ifdef CONFIG_TRACE_IRQFLAGS /* * Most of the CPU's IRQ-state tracing is done from assembly code; we
arch/powerpc/include/asm/mmu_context.h +46 -4
77 lines not on this page · raw message
arch/powerpc/include/asm/mpic.h +1 -1
@@ -289,7 +289,7 @@#ifdef CONFIG_MPIC_U3_HT_IRQS /* The fixup table */ struct mpic_irq_fixup *fixups; -spinlock_t fixup_lock; +ipipe_spinlock_t fixup_lock;#endif /* Register access method */
arch/powerpc/include/asm/paca.h +4 -0
@@ -119,8 +119,12 @@u64 saved_r1;/* r1 save for RTAS calls */ u64 saved_msr;/* MSR saved here by enter_rtas */ u16 trap_save;/* Used when bad stack is encountered */ +#ifdef CONFIG_SOFTDISABLE u8 soft_enabled;/* irq soft-enable flag */ u8 hard_enabled;/* set if irqs are enabled in MSR */ +#elif CONFIG_IPIPE +u64 root_percpu;/* Address of per_cpu data for the root domain */ +#endif u8 io_sync;/* writel() needs spin_unlock sync */ u8 perf_event_pending;/* PM interrupt while soft-disabled */
arch/powerpc/include/asm/ptrace.h +1 -1
@@ -36,7 +36,7 @@unsigned long xer;unsigned long ccr;#ifdef __powerpc64__ -unsigned long softe;/* Soft enabled/disabled */ +unsigned long softe;/* Soft enabled/disabled (CONFIG_SOFTDISABLE || CONFIG_IPIPE) */ #else unsigned long mq;/* 601 only (not used at present) */ /* Used on APUS to hold IPL value. */
arch/powerpc/include/asm/qe_ic.h +12 -5
@@ -74,6 +74,13 @@ {return 0 ; }#endif /* CONFIG_QUICC_ENGINE */ +#ifdef CONFIG_IPIPE +void __ipipe_qe_ic_cascade_irq (struct qe_ic *qe_ic,unsigned int virq); +#define qe_ic_cascade_irq (qe_ic, irq) __ipipe_qe_ic_cascade_irq(qe_ic, irq) +#else +#define qe_ic_cascade_irq (qe_ic, irq) generic_handle_irq(irq) +#endif +void qe_ic_set_highest_priority (unsigned int virq,int high);int qe_ic_set_priority (unsigned int virq,unsigned int priority);int qe_ic_set_high_priority (unsigned int virq,unsigned int priority,int high);
@@ -85,7 +92,7 @@unsigned int cascade_irq =qe_ic_get_low_irq (qe_ic);if (cascade_irq !=NO_IRQ ) -generic_handle_irq (cascade_irq); +qe_ic_cascade_irq (qe_ic, cascade_irq); } static inline void qe_ic_cascade_high_ipic(unsigned int irq,
@@ -95,7 +102,7 @@unsigned int cascade_irq =qe_ic_get_high_irq (qe_ic);if (cascade_irq !=NO_IRQ ) -generic_handle_irq (cascade_irq); +qe_ic_cascade_irq (qe_ic, cascade_irq); } static inline void qe_ic_cascade_low_mpic(unsigned int irq,
@@ -105,7 +112,7 @@unsigned int cascade_irq =qe_ic_get_low_irq (qe_ic);if (cascade_irq !=NO_IRQ ) -generic_handle_irq (cascade_irq); +qe_ic_cascade_irq (qe_ic, cascade_irq); desc->chip->eoi (irq); }
@@ -117,7 +124,7 @@unsigned int cascade_irq =qe_ic_get_high_irq (qe_ic);if (cascade_irq !=NO_IRQ ) -generic_handle_irq (cascade_irq); +qe_ic_cascade_irq (qe_ic, cascade_irq); desc->chip->eoi (irq); }
@@ -133,7 +140,7 @@ cascade_irq =qe_ic_get_low_irq (qe_ic);if (cascade_irq !=NO_IRQ ) -generic_handle_irq (cascade_irq); +qe_ic_cascade_irq (qe_ic, cascade_irq); desc->chip->eoi (irq); }
arch/powerpc/include/asm/reg.h +1 -1
@@ -928,7 +928,7 @@#define proc_trap () asm volatile("trap") -#ifdef CONFIG_PPC64 +#ifdef CONFIG_RUNLATCH extern void ppc64_runlatch_on (void );extern void ppc64_runlatch_off (void );
arch/powerpc/include/asm/smp.h +11 -0
@@ -54,8 +54,14 @@/* 32-bit */ extern int smp_hw_index[]; +#ifdef CONFIG_IPIPE +extern int smp_logical_index[]; +#define raw_smp_processor_id () (smp_logical_index[mfspr(SPRN_PIR)]) +#define hard_smp_processor_id () (smp_hw_index[raw_smp_processor_id()]) +#else #define raw_smp_processor_id () (current_thread_info()->cpu)#define hard_smp_processor_id () (smp_hw_index[smp_processor_id()]) +#endif static inline int get_hard_smp_processor_id (int cpu) {
@@ -65,6 +71,10 @@static inline void set_hard_smp_processor_id (int cpu,int phys) { smp_hw_index[cpu] = phys; +#ifdef CONFIG_IPIPE +BUG_ON (phys >=NR_CPUS ); + smp_logical_index[phys] = cpu; +#endif }#endif
@@ -80,6 +90,7 @@#define PPC_MSG_RESCHEDULE 1#define PPC_MSG_CALL_FUNC_SINGLE 2#define PPC_MSG_DEBUGGER_BREAK 3 +#define PPC_MSG_IPIPE_DEMUX PPC_MSG_DEBUGGER_BREAK/* * irq controllers that have dedicated ipis per message and don't
arch/powerpc/include/asm/thread_info.h +2 -0
@@ -112,6 +112,7 @@#define TIF_FREEZE 14/* Freezing for suspend */ #define TIF_RUNLATCH 15/* Is the runlatch enabled? */ #define TIF_ABI_PENDING 16/* 32/64 bit switch needed */ +#define TIF_MMSWITCH_INT 20/* MMU context switch interrupted */ /* as above, but as bit values */ #define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -130,6 +131,7 @@#define _TIF_FREEZE (1<<TIF_FREEZE)#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)#define _TIF_ABI_PENDING (1<<TIF_ABI_PENDING) +#define _TIF_MMSWITCH_INT (1<<TIF_MMSWITCH_INT)#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
arch/powerpc/include/asm/time.h +1 -0
@@ -30,6 +30,7 @@extern unsigned long tb_ticks_per_sec;extern u64 tb_to_xs;extern unsigned tb_to_us; +DECLARE_PER_CPU (int, disarm_decr);struct rtc_time ;extern void to_tm (int tim,struct rtc_time * tm);
arch/powerpc/kernel/Makefile +1 -0
@@ -39,6 +39,7 @@ obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o obj-$(CONFIG_PPC64) += vdso64/ obj-$(CONFIG_ALTIVEC) += vecemu.o +obj-$(CONFIG_IPIPE) += ipipe.o obj-$(CONFIG_PPC_970_NAP) += idle_power4.o obj-$(CONFIG_PPC_OF) += of_device.o of_platform.o prom_parse.o obj-$(CONFIG_PPC_CLOCK) += clock.o
arch/powerpc/kernel/asm-offsets.c +6 -0
@@ -131,8 +131,12 @@DEFINE (PACATOC , offsetof(struct paca_struct , kernel_toc));DEFINE (PACAKBASE , offsetof(struct paca_struct , kernelbase));DEFINE (PACAKMSR , offsetof(struct paca_struct , kernel_msr)); +#ifdef CONFIG_SOFTDISABLE DEFINE (PACASOFTIRQEN , offsetof(struct paca_struct , soft_enabled));DEFINE (PACAHARDIRQEN , offsetof(struct paca_struct , hard_enabled)); +#elif CONFIG_IPIPE +DEFINE (PACAROOTPCPU , offsetof(struct paca_struct , root_percpu)); +#endif DEFINE (PACAPERFPEND , offsetof(struct paca_struct , perf_event_pending)); DEFINE(PACACONTEXTID, offsetof(struct paca_struct, context.id));#ifdef CONFIG_PPC_MM_SLICES
@@ -271,7 +275,9 @@DEFINE (_DEAR,STACK_FRAME_OVERHEAD +offsetof(struct pt_regs , dar));DEFINE (_ESR,STACK_FRAME_OVERHEAD +offsetof(struct pt_regs , dsisr));#else /* CONFIG_PPC64 */ +#if defined(CONFIG_SOFTDISABLE ) || defined(CONFIG_IPIPE )DEFINE (SOFTE ,STACK_FRAME_OVERHEAD +offsetof(struct pt_regs , softe)); +#endif /* These _only_ to be used with {PROM,RTAS}_FRAME_SIZE!!! */ DEFINE (_SRR0,STACK_FRAME_OVERHEAD +sizeof (struct pt_regs ));
arch/powerpc/kernel/cputable.c +1 -1
@@ -1922,7 +1922,7 @@#endif /* CONFIG_PPC64 || CONFIG_BOOKE */ } -struct cpu_spec *__init identify_cpu (unsigned long offset,unsigned int pvr) +notrace struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr) {struct cpu_spec *s = cpu_specs;int i;
arch/powerpc/kernel/entry_32.S +75 -1
125 lines not on this page · raw message
arch/powerpc/kernel/entry_64.S +137 -2
256 lines not on this page · raw message
arch/powerpc/kernel/fpu.S +23 -1
@@ -122,7 +122,17 @@ * Enables the FPU for use in the kernel on return. */ _GLOBAL(giveup_fpu) +#ifdef CONFIG_IPIPE + mfmsr r6 +#ifdef CONFIG_PPC64 + rldicl r5,r6,48,1 /* clear MSR_EE */ + rotldi r5,r5,16 +#else + rlwinm r5,r6,0,17,15 /* clear MSR_EE */ +#endif +#else mfmsr r5 +#endif ori r5,r5,MSR_FP #ifdef CONFIG_VSX BEGIN_FTR_SECTION
@@ -135,7 +145,7 @@ SYNC_601 isync PPC_LCMPI 0,r3,0 - beqlr- /* if no previous owner, done */ + beq- 2f /* if no previous owner, done */ addi r3,r3,THREAD /* want THREAD of task */ PPC_LL r5,PT_REGS(r3) PPC_LCMPI 0,r5,0
@@ -158,6 +168,18 @@ LOAD_REG_ADDRBASE(r4,last_task_used_math) PPC_STL r5,ADDROFF(last_task_used_math)(r4) #endif /* CONFIG_SMP */ +2: +#ifdef CONFIG_IPIPE /* restore interrupt state */ + andi. r6,r6,MSR_EE + beqlr + mfmsr r5 + ori r5,r5,MSR_EE + SYNC_601 + ISYNC_601 + MTMSRD(r5) + SYNC_601 + isync +#endif blr /*
arch/powerpc/kernel/head_32.S +23 -0
@@ -322,6 +322,12 @@ EXC_XFER_TEMPLATE(n, hdlr, n, NOCOPY, transfer_to_handler_full, \ ret_from_except_full) +#ifdef CONFIG_IPIPE +#define EXC_XFER_IPIPE(n, hdlr) \ + EXC_XFER_TEMPLATE(n, hdlr, n+1, NOCOPY, transfer_to_handler, \ + __ipipe_ret_from_except) +#endif /* CONFIG_IPIPE */ + #define EXC_XFER_LITE(n, hdlr) \ EXC_XFER_TEMPLATE(n, hdlr, n+1, NOCOPY, transfer_to_handler, \ ret_from_except)
@@ -406,7 +412,11 @@ EXC_XFER_EE_LITE(0x400, handle_page_fault) /* External interrupt */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x500, HardwareInterrupt, __ipipe_grab_irq, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ /* Alignment exception */ . = 0x600
@@ -440,7 +450,11 @@ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception) /* Decrementer */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x900, Decrementer, __ipipe_grab_timer, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x900, Decrementer, timer_interrupt, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ EXCEPTION(0xa00, Trap_0a, unknown_exception, EXC_XFER_EE) EXCEPTION(0xb00, Trap_0b, unknown_exception, EXC_XFER_EE)
@@ -1016,6 +1030,12 @@ lwz r3,MMCONTEXTID(r4) cmpwi cr0,r3,0 blt- 4f +#ifdef CONFIG_IPIPE + mfmsr r7 + rlwinm r0,r7,0,17,15 /* clear MSR_EE in r0 */ + mtmsr r0 + sync +#endif mulli r3,r3,897 /* multiply context by skew factor */ rlwinm r3,r3,4,8,27 /* VSID = (context & 0xfffff) << 4 */ addis r3,r3,0x6000 /* Set Ks, Ku bits */
@@ -1039,6 +1059,9 @@ rlwinm r3,r3,0,8,3 /* clear out any overflow from VSID field */ addis r4,r4,0x1000 /* address of next segment */ bdnz 3b +#ifdef CONFIG_IPIPE + mtmsr r7 +#endif sync isync blr
arch/powerpc/kernel/head_40x.S +14 -0
@@ -234,6 +234,12 @@ EXC_XFER_TEMPLATE(hdlr, n, MSR_KERNEL, NOCOPY, transfer_to_handler_full, \ ret_from_except_full) +#ifdef CONFIG_IPIPE +#define EXC_XFER_IPIPE(n, hdlr) \ + EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, NOCOPY, transfer_to_handler, \ + __ipipe_ret_from_except) +#endif /* CONFIG_IPIPE */ + #define EXC_XFER_LITE(n, hdlr) \ EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, NOCOPY, transfer_to_handler, \ ret_from_except)
@@ -402,7 +408,11 @@ EXC_XFER_EE_LITE(0x400, handle_page_fault) /* 0x0500 - External Interrupt Exception */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x0500, HardwareInterrupt, __ipipe_grab_irq, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x0500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ /* 0x0600 - Alignment Exception */ START_EXCEPTION(0x0600, Alignment)
@@ -440,7 +450,11 @@ lis r0,TSR_PIS@h mtspr SPRN_TSR,r0 /* Clear the PIT exception */ addi r3,r1,STACK_FRAME_OVERHEAD +#ifdef CONFIG_IPIPE + EXC_XFER_IPIPE(0x1000, __ipipe_grab_timer) +#else /* !CONFIG_IPIPE */ EXC_XFER_LITE(0x1000, timer_interrupt) +#endif /* CONFIG_IPIPE */ #if 0 /* NOTE:
arch/powerpc/kernel/head_44x.S +5 -2
@@ -310,8 +310,11 @@ /* Instruction Storage Interrupt */ INSTRUCTION_STORAGE_EXCEPTION - /* External Input Interrupt */ - EXCEPTION(0x0500, ExternalInput, do_IRQ, EXC_XFER_LITE) +#ifdef CONFIG_IPIPE + EXCEPTION(0x0500, ExternalInput, __ipipe_grab_irq, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ + EXCEPTION(0x0500, ExternalInput, do_IRQ, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ /* Alignment Interrupt */ ALIGNMENT_EXCEPTION
arch/powerpc/kernel/head_8xx.S +14 -0
@@ -185,6 +185,12 @@ EXC_XFER_TEMPLATE(n, hdlr, n, NOCOPY, transfer_to_handler_full, \ ret_from_except_full) +#ifdef CONFIG_IPIPE +#define EXC_XFER_IPIPE(n, hdlr) \ + EXC_XFER_TEMPLATE(n, hdlr, n+1, NOCOPY, transfer_to_handler, \ + __ipipe_ret_from_except) +#endif /* CONFIG_IPIPE */ + #define EXC_XFER_LITE(n, hdlr) \ EXC_XFER_TEMPLATE(n, hdlr, n+1, NOCOPY, transfer_to_handler, \ ret_from_except)
@@ -236,7 +242,11 @@ EXC_XFER_EE_LITE(0x400, handle_page_fault) /* External interrupt */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x500, HardwareInterrupt, __ipipe_grab_irq, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ /* Alignment exception */ . = 0x600
@@ -257,7 +267,11 @@ EXCEPTION(0x800, FPUnavailable, unknown_exception, EXC_XFER_STD) /* Decrementer */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x900, Decrementer, __ipipe_grab_timer, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x900, Decrementer, timer_interrupt, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ EXCEPTION(0xa00, Trap_0a, unknown_exception, EXC_XFER_EE) EXCEPTION(0xb00, Trap_0b, unknown_exception, EXC_XFER_EE)
arch/powerpc/kernel/head_booke.h +16 -0
@@ -208,6 +208,12 @@EXC_XFER_TEMPLATE (hdlr, n,MSR_KERNEL ,NOCOPY , transfer_to_handler_full, \ ret_from_except_full) +#ifdef CONFIG_IPIPE +#define EXC_XFER_IPIPE (n, hdlr) \ + EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, NOCOPY, transfer_to_handler, \ + __ipipe_ret_from_except) +#endif /* CONFIG_IPIPE */ +#define EXC_XFER_LITE (n, hdlr) \ EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, NOCOPY, transfer_to_handler, \ ret_from_except)
@@ -372,6 +378,15 @@addi r3,r1,STACK_FRAME_OVERHEAD ; \ EXC_XFER_STD(0x0700, program_check_exception) +#ifdef CONFIG_IPIPE +#define DECREMENTER_EXCEPTION \ + START_EXCEPTION(Decrementer) \ + NORMAL_EXCEPTION_PROLOG; \ + lis r0,TSR_DIS@h;/* Setup the DEC interrupt mask */ \ +mtspr SPRN_TSR ,r0;/* Clear the DEC interrupt */ \ +addi r3,r1,STACK_FRAME_OVERHEAD ; \ + EXC_XFER_IPIPE(0x0900, __ipipe_grab_timer) +#else /* !CONFIG_IPIPE */ #define DECREMENTER_EXCEPTION \ START_EXCEPTION(Decrementer) \ NORMAL_EXCEPTION_PROLOG; \
@@ -379,6 +394,7 @@mtspr SPRN_TSR ,r0;/* Clear the DEC interrupt */ \addi r3,r1,STACK_FRAME_OVERHEAD ; \ EXC_XFER_LITE(0x0900, timer_interrupt) +#endif /* CONFIG_IPIPE */ #define FP_UNAVAILABLE_EXCEPTION \ START_EXCEPTION(FloatingPointUnavailable) \
arch/powerpc/kernel/head_fsl_booke.S +4 -0
@@ -488,7 +488,11 @@ INSTRUCTION_STORAGE_EXCEPTION /* External Input Interrupt */ +#ifdef CONFIG_IPIPE + EXCEPTION(0x0500, ExternalInput, __ipipe_grab_irq, EXC_XFER_IPIPE) +#else /* !CONFIG_IPIPE */ EXCEPTION(0x0500, ExternalInput, do_IRQ, EXC_XFER_LITE) +#endif /* CONFIG_IPIPE */ /* Alignment Interrupt */ ALIGNMENT_EXCEPTION
arch/powerpc/kernel/idle.c +3 -2
@@ -59,6 +59,7 @@tick_nohz_stop_sched_tick (1 );while (!need_resched () && !cpu_should_die ()) {ppc64_runlatch_off (); +ipipe_suspend_domain ();if (ppc_md.power_save) {clear_thread_flag (TIF_POLLING_NRFLAG );
@@ -67,7 +68,7 @@* is ordered w.r.t. need_resched() test. */ smp_mb (); -local_irq_disable (); +local_irq_disable_hw ();/* Don't trace irqs off for idle */ stop_critical_timings ();
@@ -78,7 +79,7 @@start_critical_timings (); -local_irq_enable (); +local_irq_enable_hw ();set_thread_flag (TIF_POLLING_NRFLAG ); }else {
arch/powerpc/kernel/idle_power4.S +4 -0
@@ -34,9 +34,11 @@ rldicl r0,r7,48,1 rotldi r0,r0,16 mtmsrd r0,1 /* hard-disable interrupts */ +#ifdef CONFIG_SOFTDISABLE li r0,1 stb r0,PACASOFTIRQEN(r13) /* we'll hard-enable shortly */ stb r0,PACAHARDIRQEN(r13) +#endif CONFIG_SOFTDISABLE BEGIN_FTR_SECTION DSSALL sync
@@ -59,10 +61,12 @@ rldicl r0,r7,48,1 rotldi r0,r0,16 mtmsrd r0,1 /* hard-disable interrupts */ +#ifdef CONFIG_SOFTDISABLE li r0,1 li r6,0 stb r0,PACAHARDIRQEN(r13) /* we'll hard-enable shortly */ stb r6,PACASOFTIRQEN(r13) /* soft-disable irqs */ +#endif BEGIN_FTR_SECTION DSSALL sync
arch/powerpc/kernel/ipipe.c +863 -0
863 lines not on this page · raw message
arch/powerpc/kernel/irq.c +6 -1
@@ -72,7 +72,7 @@#endif int __irq_offset_value; -static int ppc_spurious_interrupts; +int ppc_spurious_interrupts;#ifdef CONFIG_PPC32 EXPORT_SYMBOL (__irq_offset_value);
@@ -89,6 +89,8 @@int distribute_irqs =1 ; +#ifdef CONFIG_SOFTDISABLE +static inline notrace unsigned long get_hard_enabled (void ) {unsigned long enabled;
@@ -173,6 +175,9 @@__hard_irq_enable (); }EXPORT_SYMBOL (raw_local_irq_restore); + +#endif /* !CONFIG_SOFTDISABLE */ +#endif /* CONFIG_PPC64 */ int show_interrupts (struct seq_file *p,void *v)
arch/powerpc/kernel/ppc_ksyms.c +3 -0
@@ -123,6 +123,9 @@#ifdef CONFIG_SMP #ifdef CONFIG_PPC32 EXPORT_SYMBOL (smp_hw_index); +#ifdef CONFIG_IPIPE +EXPORT_SYMBOL (smp_logical_index); +#endif #endif #endif
arch/powerpc/kernel/process.c +8 -3
@@ -98,8 +98,12 @@void enable_kernel_fp (void ) { +unsigned long flags; +WARN_ON (preemptible ()); +local_irq_save_hw_cond (flags); +#ifdef CONFIG_SMP if (current->thread.regs && (current->thread.regs->msr &MSR_FP ))giveup_fpu (current);
@@ -108,6 +112,7 @@#else giveup_fpu (last_task_used_math);#endif /* CONFIG_SMP */ +local_irq_restore_hw_cond (flags); }EXPORT_SYMBOL (enable_kernel_fp);
@@ -398,7 +403,7 @@ }#endif -local_irq_save (flags); +local_irq_save_hw (flags);account_system_vtime (current);account_process_vtime (current);
@@ -412,7 +417,7 @@hard_irq_disable (); last =_switch (old_thread, new_thread); -local_irq_restore (flags); +local_irq_restore_hw (flags);return last; }
@@ -1084,7 +1089,7 @@ }EXPORT_SYMBOL (dump_stack); -#ifdef CONFIG_PPC64 +#ifdef CONFIG_RUNLATCH void ppc64_runlatch_on (void ) {unsigned long ctrl;
arch/powerpc/kernel/prom_init_check.sh +1 -1
@@ -20,7 +20,7 @@ _end enter_prom memcpy memset reloc_offset __secondary_hold __secondary_hold_acknowledge __secondary_hold_spinloop __start strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224 -reloc_got2 kernstart_addr memstart_addr linux_banner" +reloc_got2 kernstart_addr memstart_addr linux_banner _mcount" NM="$1" OBJ="$2"
arch/powerpc/kernel/setup_32.c +3 -0
@@ -52,6 +52,9 @@int boot_cpuid_phys;int smp_hw_index[NR_CPUS ]; +#ifdef CONFIG_IPIPE +int smp_logical_index[NR_CPUS ]; +#endif unsigned long ISA_DMA_THRESHOLD ;unsigned int DMA_MODE_READ ;
arch/powerpc/kernel/setup_64.c +12 -0
@@ -224,8 +224,10 @@#ifdef CONFIG_SMP void early_setup_secondary (void ) { +#ifdef CONFIG_SOFTDISABLE /* Mark interrupts enabled in PACA */ get_paca ()->soft_enabled =0 ; +#endif /* Initialize the hash table or TLB handling */ early_init_mmu_secondary ();
@@ -331,6 +333,12 @@*/ void __init setup_system (void ) { +#ifdef CONFIG_IPIPE +/* Early temporary init, before per-cpu areas are moved to +* their final location. */ +get_paca ()->root_percpu = (u64)&ipipe_percpudom (&ipipe_root, status,0 ); +#endif +DBG (" -> setup_system()\n" );/* Apply the CPUs-specific and firmware specific fixups to kernel
@@ -577,6 +585,10 @@snprintf (buf,128 ,"%s" , msg); ppc_md.progress (buf,0 ); } +#ifdef CONFIG_IPIPE +/* Reset pointer to the relocated per-cpu root domain data. */ +get_paca ()->root_percpu = (u64)&ipipe_percpudom (&ipipe_root, status,0 ); +#endif }/* Print a boot progress message. */
arch/powerpc/kernel/smp.c +19 -2
@@ -154,7 +154,7 @@ [PPC_MSG_CALL_FUNCTION] = "ipi call function", [PPC_MSG_RESCHEDULE] = "ipi reschedule", [PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single", - [PPC_MSG_DEBUGGER_BREAK] = "ipi debugger", + [PPC_MSG_DEBUGGER_BREAK] = "ipi I-pipe/debugger", };/* optional function to request ipi, for controllers with >= 4 ipis */
@@ -165,11 +165,17 @@if (msg <0 || msg >PPC_MSG_DEBUGGER_BREAK ) {return -EINVAL ; } +#ifdef CONFIG_IPIPE +if (msg ==PPC_MSG_DEBUGGER_BREAK ) +/* Piggyback the debugger IPI for the I-pipe. */ +__ipipe_register_ipi (virq); +#endif #if !defined(CONFIG_DEBUGGER ) && !defined(CONFIG_KEXEC )if (msg ==PPC_MSG_DEBUGGER_BREAK ) {return 1 ; }#endif + err =request_irq (virq, smp_ipi_action[msg],IRQF_DISABLED |IRQF_PERCPU , smp_ipi_name[msg],0 ); WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
@@ -200,8 +206,12 @@#ifdef CONFIG_DEBUGGER void smp_send_debugger_break (int cpu) { -if (likely (smp_ops)) +if (likely (smp_ops)) { +#ifdef CONFIG_IPIPE +cpu_set (cpu, __ipipe_dbrk_pending); +#endif smp_ops->message_pass (cpu,PPC_MSG_DEBUGGER_BREAK ); + } }#endif
@@ -210,6 +220,10 @@ { crash_ipi_function_ptr = crash_ipi_callback;if (crash_ipi_callback && smp_ops) { +#ifdef CONFIG_IPIPE +cpus_setall (__ipipe_dbrk_pending); +cpu_clear (ipipe_processor_id (), __ipipe_dbrk_pending); +#endif mb (); smp_ops->message_pass (MSG_ALL_BUT_SELF ,PPC_MSG_DEBUGGER_BREAK ); }
@@ -488,6 +502,9 @@struct device_node *l2_cache;int i, base; +#if defined(CONFIG_IPIPE ) && defined(CONFIG_PPC64 ) +get_paca ()->root_percpu = (u64)&ipipe_percpudom (&ipipe_root, status, cpu); +#endif atomic_inc (&init_mm.mm_count); current->active_mm = &init_mm;
arch/powerpc/kernel/time.c +47 -8
71 lines not on this page · raw message
arch/powerpc/kernel/traps.c +47 -1
48 lines not on this page · raw message
arch/powerpc/mm/hash_low_32.S +33 -12
45 lines not on this page · raw message
arch/powerpc/mm/hash_native_64.c +42 -8
50 lines not on this page · raw message
arch/powerpc/platforms/44x/canyonlands-sata.c +123 -0
123 lines not on this page · raw message
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c +33 -9
42 lines not on this page · raw message
arch/powerpc/sysdev/mpic.c +69 -13
82 lines not on this page · raw message
include/linux/fb.h +47 -0
47 lines not on this page · raw message
include/linux/ipipe.h +688 -0
688 lines not on this page · raw message
include/linux/ipipe_base.h +102 -0
102 lines not on this page · raw message
include/linux/ipipe_compat.h +54 -0
54 lines not on this page · raw message
include/linux/ipipe_percpu.h +86 -0
86 lines not on this page · raw message
include/linux/ipipe_tickdev.h +58 -0
58 lines not on this page · raw message
include/linux/ipipe_trace.h +72 -0
72 lines not on this page · raw message
include/linux/spinlock.h +138 -11
149 lines not on this page · raw message
kernel/ipipe/Kconfig.debug +96 -0
96 lines not on this page · raw message
kernel/ipipe/core.c +1794 -0
1,794 lines not on this page · raw message
kernel/ipipe/tracer.c +1441 -0
1,441 lines not on this page · raw message
kernel/irq/chip.c +154 -12
166 lines not on this page · raw message
kernel/printk.c +95 -0
95 lines not on this page · raw message
kernel/sched.c +85 -4
89 lines not on this page · raw message
mm/memory.c +188 -31
219 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
Len Sorensen
Part of the diff is not shown here. View the raw message.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Lennart Sorensen
Quoted 5 lines · Philippe Gerum
To get a complete pipeline, you need the -noarch side, and the -powerpc side. ipipe-2.6.32-powerpc is based on ipipe-2.6.32-noarch, which is based on v2.6.32 mainline. From the official I-pipe tree located there:
git://git.denx.de/ipipe-2.6.git
Quoted 8 lines
Quoted 1 line
$ git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpcrceng02:/data/git-trees/ipipe-2.6# git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpc fatal: ambiguous argument 'ipipe-2.6.32-powerpc': unknown revision or path not in the working tree. Use '--' to separate paths from revisionsFrom your end, the ipipe branches you care of are remote ones available
from the "origin" namespace, so you should try origin/ipipe-2.6.32-powerpc, and origin/ipipe-2.6.32-noarch is specs.
Quoted 2 lines
Hmm, is my git version too old?
No, I think it's fine.
<snip>
Quoted 9 lines
Quoted 8 lines
x86 does not qualify for this discussion; with a x86-based system, even if the kernel at hand does not support the very latest fancy device you have on board, your kernel will likely still boot and run properly. On the other hand, you would not even try booting your mpc8360 over a kernel built for 44x. But given you want to support both, if either of both happen to be in a poor state in your reference tree, things start hitting the crapper. The DENX tree saved my day so far, because it allowed me to work on all powerpc platforms from a single code base.
Quoted 4 lines
Certainly kernels for embedded systems often are only menat for one system. That doesn't mean you couldn't build a kernel with support for multiple systems.
Sure, but for that, you need to have a single source tree that works for both. This is the gist of the issue I'm facing.
Quoted 27 lines
Quoted 9 lines
The Blackfin uClinux distro was still shipping 2.4.7 in their latest 2009R1 release, albeit they merged the Blackfin-specific bits from the pipeline into their official kernel tree, many moons ago. Incidentally, I'm maintaining those bits for their development kernel directly feeding mainline, so I don't think your reasoning should be generalized.
This said, if you have first hand information from the Debian team regarding this, maybe you should tell them to drop us a note; we would be happy to help.
No I don't. Just speculation. I just remember trying to use the package and finding that it simply could not apply to the released kernel sources.
Quoted 8 lines
I understand your point from your perspective. But maintaining our code base for mpc8360 only is not enough for us.
The reason why the powerpc patches are DENX-based is simply that this tree worked for me over time, for various platforms (52xx, 4xx/44x, pa6t come to mind), way before mainline did. Xenomai supports recent platforms like the 512x series precisely because of that as well.
Quoted 5 lines
Does this mean that the pipeline patches will be based on the DENX tree until hell freezes? No, this does not, because the DENX folks are doing their job as well, and make their best to close the gap between their tree and mainline, taking all needed provisions to get their bits merged upstream sooner.
Quoted 4 lines
Well I hope it happens soon. Things always become much easier when you can work with the official kernel releases. The powerpc support in the main kernel tree seem rather good.
Generally yes, it is. We just have to deal with exceptions, and those exceptions used to be many. I agree that things evolve and the situation has to be reassessed from time to time, though. It's probably a good time to do this.
Quoted 11 lines
Quoted 8 lines
A sidenote though: you can run Xenomai over mpc8360 because DENX published this support which was initially based on their tree, on behalf of a customer, like a bunch of other developments:
http://www.denx.de/en/Software/SoftwareXenomaiProjects
This makes your argument, about not depending on anything being DENX-originated, sound a bit weird. Make no mistake, you owe them quite a few kudos. Actually, anyone running Xenomai over powerpc owe them a lot.Oh I know that. We paid for it. It was well worth it. That doesn't mean I want to use the DENX kernel tree.
But at least, you know for sure why having a working kernel is important, specially to those who cannot rely on mainline yet.
Quoted 7 lines
Quoted 6 lines
You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards:
http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3
Quoted 7 lines
Well I managed to get every piece except a few ppc64 bits (which as usual seemed to only apply to parts of the DENX tree. When will those bits go mainline I wonder. They seem to have been there for a while now).
I can only test on the 83xx boards we have here, but the person I gave a copy to said it worked for him, which was a different board, so it can't have been too bad.
It was likely fine, this was not my point. My point was rather that testing this on all of the hw platforms we are supposed to test it is much easier from a single code base.
Quoted 8 lines
Quoted 5 lines
Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions.
I gave a copy to someone else that saked for it who said they would post a copy.
For some reason, the patch entered the twilight zone before I could pick it. Maybe one of my spam filters, I don't know yet, I'll check.
Quoted 8 lines
Quoted 7 lines
That is good to hear. This said, the DENX tree is based on mainline like zillions of other trees, and as you certainly know, many of those trees are feeding mainline with arch-specific improvements and new platform or driver support. So the concepts of "real Linux tree" or "real kernel", "or pure tree" bear absolutely no value. The latest "pure" Linux tree probably dates back to 1994 or so.
Quoted 4 lines
OK, I will call it "Linus's tree from which released kernels are made". Specifically patches that apply to those released kernels are nice. Of course point release fixes to those release kernels can still break the patch. That's life when working out of tree.
Nope, actually, AFAIC, working out of tree is no life. But someone has to do it, sometimes.
Quoted 10 lines
Quoted 4 lines
Publishing the DENX-based support on a separate branch for ppc platforms which have incomplete support upstream, along with a mainline-based branch for the rest, is something I could handle.
Makes sense to me. Certainly not having support for platforms just because the released kernels doesn't support it yet would be silly. Just as not having support for people who are running release kernels also seems silly. Both seem very useful.
Quoted 6 lines
Quoted 3 lines
The way for you to help is certainly about testing the mainline-based branch which will probably appear for 2.6.33, and send feedback/fixes as/if needed.
I will certainly be testing it.
Ok, thanks. I will keep you posted.
Signature · 1 line
Philippe.
Philippe,
After updating my ipipe git repo, I notice that you have done something new with ipipe-2.6.32-powerpc, back in January. Previously, the Denx bits appeared as "squashed" commits. Now, the Denx commits appear individually.
I am curious, what's up with that?
Thanks,
Richard
Quoted 9 lines · Richard Cochran
Philippe,
After updating my ipipe git repo, I notice that you have done something new with ipipe-2.6.32-powerpc, back in January. Previously, the Denx bits appeared as "squashed" commits. Now, the Denx commits appear individually.
I am curious, what's up with that?
I wanted to rebase on the official DENX stable branch, since my work was previously based on a dev snapshot, and I did this by fetching+merging that branch into mine, based on v2.6.32.2; in that case, the changes appear as individual commits I guess. I did not want to mess with jumbo patches and the error-prone manual operations they entail.
With ipipe-2.6.33 solely tracking mainline, only the few temporary trees with not-mainlined-yet features/support will pull from the DENX tree to get them.
Quoted 7 lines
Thanks,
Richard_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Quoted 3 lines · Philippe Gerum
With ipipe-2.6.33 solely tracking mainline, only the few temporary trees with not-mainlined-yet features/support will pull from the DENX tree to get them.
Okay, its now clear to me. Thanks for the explanation.
Richard
Quoted 6 lines · Richard Cochran
Quoted 3 lines · Philippe Gerum
With ipipe-2.6.33 solely tracking mainline, only the few temporary trees with not-mainlined-yet features/support will pull from the DENX tree to get them.
Okay, its now clear to me. Thanks for the explanation.
You are welcome. Out of curiosity, what was unclear exactly?
Quoted 7 lines
Richard
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
Signature · 1 line
Philippe.
Quoted 2 lines · Philippe Gerum
You are welcome. Out of curiosity, what was unclear exactly?
We just had a nice discussion regarding powerpc support in ipipe/mainline/denx. Now it is clear to me, what your plan is!
Thanks for your efforts,
Richard