2.4 versus 2.6 patches

2.4 versus 2.6 patches

[Robert P. J. Day]

   i just realized that the sample excerpts i was posting from the
ppc config files were from the 2.4 source tree, not 2.6, so for most
of the folks on this list, i suspect they'd be more interested in
patches to a 2.6-style Kconfig file, not a 2.4-style config.in file,
correct?

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[David Woodhouse]

On Fri, 2004-07-23 at 10:57 -0400, Robert P. J. Day wrote:
> for most of the folks on this list, i suspect they'd be more
> interested in patches to a 2.6-style Kconfig file, not a 2.4-style
> config.in file, correct?

Yes. The 2.4 kernel is dead.

There are two classes of people -- those who are shipping 2.4 already or
at least close to doing so, and those who are bringing Linux up on a new
board.

The former are hopefully already past the stage of being confused by
such things in the config files, and the latter should most definitely
be using 2.6.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Song Sam]

David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2004-07-23 at 10:57 -0400, Robert P. J. Day wrote:
> > for most of the folks on this list, i suspect they'd be more
> > interested in patches to a 2.6- style Kconfig file,not a 2.4-style
> > config.in file, correct?
>
> Yes. The 2.4 kernel is dead.

But 2.4 kernel is still a pet for 8xx,at least.I guess
many embedded Linux development lean to 2.4 kernel for
the moment.For Linux kernel hackers,2.4 kernel was
dead but it is alive for most embedded
developers.Right? :-)

Best regards,

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[David Woodhouse]

On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:
> But 2.4 kernel is still a pet for 8xx,at least.I guess
> many embedded Linux development lean to 2.4 kernel for
> the moment.For Linux kernel hackers,2.4 kernel was
> dead but it is alive for most embedded
> developers.Right? :-)

I cannot speak for 'most embedded developers.'; only those with clue.

I would not consider deploying anything new on 2.4 today; it's just
not a viable, maintainable platform in my opinion.

--
dwmw2

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Eugene Surovegin]

On Mon, Jul 26, 2004 at 12:13:17AM -0400, David Woodhouse wrote:
>
> On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:
> > But 2.4 kernel is still a pet for 8xx,at least.I guess
> > many embedded Linux development lean to 2.4 kernel for
> > the moment.For Linux kernel hackers,2.4 kernel was
> > dead but it is alive for most embedded
> > developers.Right? :-)
>
> I cannot speak for 'most embedded developers.'; only those with clue.

I find this statement almost offensive, btw.

> I would not consider deploying anything new on 2.4 today; it's just
> not a viable, maintainable platform in my opinion.

I would not consider deploying anything on 2.6 today. IMHO it's not mature
enough to be used in production environment.

Just my $0.02

Eugene

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Song Sam]

--- Eugene Surovegin <ebs@ebshome.net> wrote£º

> On Mon, Jul 26, 2004 at 12:13:17AM -0400, David
> Woodhouse wrote:
> >
> > On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:
> > > But 2.4 kernel is still a pet for 8xx,at least. I guess many
> > > embedded Linux development lean to 2.4 kernel for the moment.For
> > > Linux kernel hackers,2.4 kernel was dead but it is alive for most
> > > embedded developers.Right? :-)
> >
> > I cannot speak for 'most embedded developers.'; only those with
> > clue.

Sorry,I got you wrong.I was a little too sensitive to
see 2.4 with "dead".Just gave my opinion on 2.4 kernel
on embedded development.

> > I would not consider deploying anything new on 2.4 today; it's just
> > not a viable, maintainable platform in my opinion.

It was really a puzzle for me why 2.4 is NOT a viable,
maintainable platform but it is used more than 2.6.x
in many embedded development.Also why to see 2.4 dying
without leaving the official maintaining work to some
volunteers? Any special reason?

> I would not consider deploying anything on 2.6 today. IMHO it's not
> mature enough to be used in production environment.

I do agree with the view.I guess it is most embedded
developers's opinion.

Thanks for all attention.

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[David Woodhouse]

On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:

> Sorry,I got you wrong.I was a little too sensitive to
> see 2.4 with "dead".Just gave my opinion on 2.4 kernel
> on embedded development.

Deployment if you're already almost ready to ship is sane enough, I
suppose -- but to actually put more effort into 2.4 wouldn't make much
sense.

> It was really a puzzle for me why 2.4 is NOT a viable,
> maintainable platform but it is used more than 2.6.x
> in many embedded development.Also why to see 2.4 dying
> without leaving the official maintaining work to some
> volunteers? Any special reason?

Because nobody's really that interested in it. For what it's worth, I've
abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS
tree. I won't object too hard if someone else wants to fix it up, _if_
that doesn't uglify the 2.6 code.

If 2.4 works already for you, by all means use it -- but if you're doing
any new development, or you _really_ want people to care when you find
bugs, it really ought to be 2.6.

> > I would not consider deploying anything on 2.6
> > today. IMHO it's not mature
> > enough to be used in production environment.
>
> I do agree with the view.I guess it is most embedded
> developers's opinion.

Out of interest, how many platforms are you using 2.6 on and how does
your experience with these platforms support your stated view?

--
dwmw2

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Mark Chambers]

> If 2.4 works already for you, by all means use it -- but if you're doing
> any new development, or you _really_ want people to care when you find
> bugs, it really ought to be 2.6.
>

Well, this is a surprise to me.  Does the stock 2.6 even compile on 8xx yet,
or are you talking about 8xxx and/or IBM?

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Robert P. J. Day]

On Mon, 26 Jul 2004, Mark Chambers wrote:

>> If 2.4 works already for you, by all means use it -- but if you're
>> doing any new development, or you _really_ want people to care when
>> you find bugs, it really ought to be 2.6.

> Well, this is a surprise to me.  Does the stock 2.6 even compile on
> 8xx yet, or are you talking about 8xxx and/or IBM?

well, the linuxppc-2.5 bk pull from bkbits.net compiles and boots on
our 8xx board.  although i'm still working on relocating SMC1 to allow
ethernet on SCC3.  but other than that, sure, it builds and boots.

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Eugene Surovegin]

On Mon, Jul 26, 2004 at 10:27:52AM -0400, David Woodhouse wrote:
> Because nobody's really that interested in it. For what it's worth, I've
> abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS
> tree.

This is quite sad, but not all maintainers do the same. IIRC networking fixes
are still backported to 2.4.

Hopefully, I can maintain this stuff myself and backport fixes (what I already
did for some MTD stuff, btw).

> > > I would not consider deploying anything on 2.6
> > > today. IMHO it's not mature
> > > enough to be used in production environment.
> >
> > I do agree with the view.I guess it is most embedded
> > developers's opinion.
>
> Out of interest, how many platforms are you using 2.6 on and how does
> your experience with these platforms support your stated view?

How the number of platforms is relevant for this discussion? It should work on
one I use, it's quite academic for me if it works fine on another. Could you
point me to _any_ distribution which is shipping_2.6 PPC 4xx based kernel with
working preemption? Last time I tried this on Ebony it wasn't quite stable.

A little history, IMO we get something we can call "production quality" 2.4
PPC 4xx only in the end of 2003. It took me almost 1.5 years to get 2.4 stable
on platforms I use (fixing some nasty bugs on the way, even MTD ones :P). After
that I'm quite reluctant to switch to 2.6 right now, just because some
maintainers lost interest in 2.4.

--
Eugene

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Thomas Gleixner]

On Mon, 2004-07-26 at 18:30, Eugene Surovegin wrote:
> On Mon, Jul 26, 2004 at 10:27:52AM -0400, David Woodhouse wrote:
> > Because nobody's really that interested in it. For what it's worth, I've
> > abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS
> > tree.
>
> This is quite sad, but not all maintainers do the same. IIRC networking fixes
> are still backported to 2.4.

Maybe not all maintainers suffer from continous lack of collaboration
and community feedback.

> Hopefully, I can maintain this stuff myself and backport fixes (what I already
> did for some MTD stuff, btw).

Cool (where are the patches, btw ???).

We would certainly be happy to keep a 2.4 branch of MTD alive if there
would be any noticable support available instead of whinging about the
brokenness of the MTD CVS.

But we certainly do not get any further, when people have patches around
and complain why we have not included them into MTD CVS by magic
awareness of the solution.

tglx


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Eugene Surovegin]

On Tue, Jul 27, 2004 at 01:17:52AM +0200, Thomas Gleixner wrote:
> > Hopefully, I can maintain this stuff myself and backport fixes (what I already
> > did for some MTD stuff, btw).
>
> Cool (where are the patches, btw ???).

All stuff I backported into my 2.4.21 tree _are_ from MTD CVS (e.g. write buffer
support for AMD flashes). When I found bugs in MTD layer, I submit patches
through usual channels.

> We would certainly be happy to keep a 2.4 branch of MTD alive if there
> would be any noticable support available instead of whinging about the
> brokenness of the MTD CVS.

Could you point to any e-mail where I was whining about brokenness of MTD CVS?
If not, what was the purpose of your statement?

This is the exact attitude which will not help you to get "any noticeable
support".

> But we certainly do not get any further, when people have patches around
> and complain why we have not included them into MTD CVS by magic
> awareness of the solution.

What is your point? Do you accuse me of not contributing back patches? I always
do this.

You missed the point of this discussion. We wasn't talking about some
random patches floating around. We were talking about stuff which _is_ in 2.6
but not 2.4. Also, we were talking about how mature is 2.6 for production
environment and how "dead" is 2.4

Of course, it's up to maintainer to decide what to backport or not, _nobody_
here asks you or David or anybody else to backport anything.

This is what I _love_ about OSS - I don't depend on any vendor/person/whoever.

Eugene.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Thomas Gleixner]

On Tue, 2004-07-27 at 01:49, Eugene Surovegin wrote:
> On Tue, Jul 27, 2004 at 01:17:52AM +0200, Thomas Gleixner wrote:
> > > Hopefully, I can maintain this stuff myself and backport fixes (what I already
> > > did for some MTD stuff, btw).
> >
> > Cool (where are the patches, btw ???).
>
> All stuff I backported into my 2.4.21 tree _are_ from MTD CVS (e.g. write buffer
> support for AMD flashes). When I found bugs in MTD layer, I submit patches
> through usual channels.

I would suspect, that MTD would be an usual channel for stuff concerning
MTD. And maybe I'm missing the point again, but your last posting to MTD
is dated from Jan 2003, if "ebshome" || "eugene" are sufficient enough
search strings.

> > We would certainly be happy to keep a 2.4 branch of MTD alive if there
> > would be any noticable support available instead of whinging about the
> > brokenness of the MTD CVS.
>
> Could you point to any e-mail where I was whining about brokenness of MTD CVS?
> If not, what was the purpose of your statement?

References:  <20040726134847.84704.qmail@web15214.mail.bjs.yahoo.com>
<Pine.LNX.4.58.0407261021120.6190@localhost.localdomain>

Cite: "This is quite sad, but not all maintainers do the same. IIRC
networking fixes are still backported to 2.4. <snip> Hopefully, I can
maintain this stuff myself and backport fixes (what I already did for
some MTD stuff, btw)."

You are accusing David of being not as 2.4 friendly as other maintainers
seem to be in your opinion.

> This is the exact attitude which will not help you to get "any noticeable
> support".

You're attitude is exactly what I'm talking of and why I choose this
tone:
"(what I already did for some MTD stuff, btw)."

> > But we certainly do not get any further, when people have patches around
> > and complain why we have not included them into MTD CVS by magic
> > awareness of the solution.
>
> What is your point? Do you accuse me of not contributing back patches? I always
> do this.

I'm just asking where the patches go to. To the usual places ? See
above.

> You missed the point of this discussion. We wasn't talking about some
> random patches floating around. We were talking about stuff which _is_ in 2.6
> but not 2.4. Also, we were talking about how mature is 2.6 for production
> environment and how "dead" is 2.4

I'm well aware of what you were talking in foreground, but I'm also able
to read the implicit things between the lines.

Quite in contrary: Random patches floating around which do not make
their way to the place where they should go, _ARE_ part of the problem.

tglx


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[David Woodhouse]

On Tue, 2004-07-27 at 02:25 +0200, Thomas Gleixner wrote:
> > You missed the point of this discussion. We wasn't talking about some
> > random patches floating around. We were talking about stuff which _is_ in 2.6
> > but not 2.4. Also, we were talking about how mature is 2.6 for production
> > environment and how "dead" is 2.4
>
> I'm well aware of what you were talking in foreground, but I'm also able
> to read the implicit things between the lines.
>
> Quite in contrary: Random patches floating around which do not make
> their way to the place where they should go, _ARE_ part of the problem.

In the case of patches backporting 2.6 features into 2.4, the 'place
where they should go' is /dev/null. It's only pure bug fixes which
should be merged.

We already have a branch in CVS for the 2.4 version of JFFS2, and bugs
are independently fixed there. I've seen no need to do likewise for the
MTD code yet, because most people patching that have been doing so in
order to backport new features rather than to fix bugs.

I don't intend to put new features into 2.4. Where 'new' means developed
after the time I last gave Marcelo an update; not after today. If you
want stuff developed in the last few years (like JFFS2 which mounts in a
relatively sane amount of time) then you should be using 2.6.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Wolfgang Denk]

In message <Pine.LNX.4.58.0407261021120.6190@localhost.localdomain> you wrote:
>
> Deployment if you're already almost ready to ship is sane enough, I
> suppose -- but to actually put more effort into 2.4 wouldn't make much
> sense.

It depends on your requirements.

If you need a kernel that is
	(1) stable and working [2.6 is still pretty much useless for  example
	    on  8xx  systems],
	(2) small [2.6 is usually >= 20% bigger than 2.4],
and/or
	(3) fast [2.6 is usually >= 10% slower than 2.4],
then 2.4 may be the better choice.

> Because nobody's really that interested in it. For what it's worth, I've
> abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS

David, you can do what you want. But it is not up to  you  to  decide
what  other people are doing. I declare that there ARE people who are
interested in 2.4 kernel - both for maintenance and development work.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Another megabytes the dust.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Marcelo Tosatti]

Hi Wolfgang!

On Mon, Jul 26, 2004 at 07:16:03PM +0200, Wolfgang Denk wrote:
>
> In message <Pine.LNX.4.58.0407261021120.6190@localhost.localdomain> you wrote:
> >
> > Deployment if you're already almost ready to ship is sane enough, I
> > suppose -- but to actually put more effort into 2.4 wouldn't make much
> > sense.
>
> It depends on your requirements.
>
> If you need a kernel that is
> 	(1) stable and working [2.6 is still pretty much useless for  example
> 	    on  8xx  systems],
> 	(2) small [2.6 is usually >= 20% bigger than 2.4],
> and/or

Even with CONFIG_EMBEDDED or Matt Mackall's -tiny tree?

> 	(3) fast [2.6 is usually >= 10% slower than 2.4],
> then 2.4 may be the better choice.

Where are you you seeing this slowdown?

v2.6 is faster in almost all workloads (it often consumes less memory, VM/FS/core API's
are faster, etc).

rkload, and we are talking about embedded setups/workloads here.

So, I'm sure we should go hunt the slowdowns... At least make the kernel development
community known about them. For sure we should make efforts to fix any performance
regressions in v2.6.

> > Because nobody's really that interested in it. For what it's worth, I've
> > abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS
>
> David, you can do what you want. But it is not up to  you  to  decide
> what  other people are doing. I declare that there ARE people who are
> interested in 2.4 kernel - both for maintenance and development work.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Song Sam]

David Woodhouse <dwmw2@infradead.org> wrote£º

> On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:
> > It was really a puzzle for me why 2.4 is NOT a viable,maintainable
> > platform but it is used more than 2.6.x in many embedded
> > development.Also why to see 2.4 dying without leaving the official
> > maintaining work to some volunteers? Any special reason?

> Because nobody's really that interested in it.

Here nobody perhaps means "no official
maintainers",those top level kernel hackers.

> If 2.4 works already for you, by all means use it -- but if you're
> doing any new development, or you _really_ want people to care when
> you find bugs, it really ought to be 2.6.

Thanks for this guideness.I am also interested in
2.6.x development on embedded application.But for the
sake of stable and useable,I perfer to 2.4.x for the
moment.Anyway,2.4 is a sign of mature for Linux.
Now I know what's the real reason of End Development
for official 2_4_devel.

> Out of interest, how many platforms are you using 2.6 on and how does
> your experience with these platforms support your stated view?

Good point.I should take back my assumption to say
"most" from now on.
For your insterest,just 2 platforms was used by me.One
is RPXlite DW,which could run on 2.4.x and 2.6.7 with
RAMDISK root file system.Another it's modified
board,which could only run with 2.4.x by now.

Thanks a lot for your attention on this point.

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Marcelo Tosatti]

On Mon, Jul 26, 2004 at 09:48:47PM +0800, Song Sam wrote:
>
> --- Eugene Surovegin <ebs@ebshome.net> wrote£º
>
> > On Mon, Jul 26, 2004 at 12:13:17AM -0400, David
> > Woodhouse wrote:
> > >
> > > On Mon, 26 Jul 2004, [gb2312] Song Sam wrote:
> > > > But 2.4 kernel is still a pet for 8xx,at least. I guess many
> > > > embedded Linux development lean to 2.4 kernel for the moment.For
> > > > Linux kernel hackers,2.4 kernel was dead but it is alive for most
> > > > embedded developers.Right? :-)
> > >
> > > I cannot speak for 'most embedded developers.'; only those with
> > > clue.
>
> Sorry,I got you wrong.I was a little too sensitive to
> see 2.4 with "dead".Just gave my opinion on 2.4 kernel
> on embedded development.
>
> > > I would not consider deploying anything new on 2.4 today; it's just
> > > not a viable, maintainable platform in my opinion.
>
> It was really a puzzle for me why 2.4 is NOT a viable,
> maintainable platform but it is used more than 2.6.x
> in many embedded development.Also why to see 2.4 dying
> without leaving the official maintaining work to some
> volunteers? Any special reason?

I think what David means is that v2.6 is the new platform
where all development effort is being done. Most of its core
code, in general, is much cleaner than v2.4.

I disagree with him when he says "v2.4 is dead" (I coudlnt otherwise :)),
because its still maintained and will be for years. And its still in
use by a lot of folks.

But his point is that new development efforts should be based on the
new, shiny, improved v2.6 kernel, since that is where all development
is focused at. And as time passes, v2.4 will get more and more
obsolete.

Unfortunately for 8xx users, as noted by other people on this thread,
v2.6 is not yet 100% (wish it was, I'm myself trying to get our boards
to boot v2.6).

There are some TLB related issue which needs fixing, Panto got a workaround
which works for him (while not being fully optimal). Dan Malek and Panto, at
least, know exactly what still needs work (unlike me).

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Song Sam]

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote£º
> I think what David means is that v2.6 is the new platform where all
> development effort is being done. Most of its core code, in general,
> is much cleaner than v2.4.

Thanks for your insight on 2.6 nice characters.

> I disagree with him when he says "v2.4 is dead" (I coudlnt otherwise
> :)), because its still maintained and will be for years. And its still
> in use by a lot of folks.

Yeah,I am so happy to see v2.4 is still supported
officially.2.4.27 was released a couple of days ago.So
mother tree is alive but ppc child tree was dead.
I wonder if I have a patch vs 2.4 branch on ppc,could
I send to Marcelo Tosatti directly?

> But his point is that new development efforts should be based on the
> new, shiny, improved v2.6 kernel, since that is where all development
> is focused at. And as time passes, v2.4 will get more and more
> obsolete.

I am looking forward to seeing the day coming. :-)

> Unfortunately for 8xx users, as noted by other people on this thread,
> v2.6 is not yet 100% (wish it was, I'm myself trying to get our boards
> to boot v2.6).

Could you make it? I once booted v2.6 on RPXlite DW
via ramdisk root file system but failed via NFS.

Best regards,

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 2.4 versus 2.6 patches

[Marcelo Tosatti]

On Tue, Aug 10, 2004 at 01:58:26PM +0800, Song Sam wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote??
> > I think what David means is that v2.6 is the new
> > platform where all development effort is being done.
> > Most of its core code, in general, is much cleaner
> > than v2.4.
>
> Thanks for your insight on 2.6 nice characters.
>
> > I disagree with him when he says "v2.4 is dead" (I
> > coudlnt otherwise :)),
> > because its still maintained and will be for years.
> > And its still in use by a lot of folks.
>
> Yeah,I am so happy to see v2.4 is still supported
> officially.2.4.27 was released a couple of days ago.So
> mother tree is alive but ppc child tree was dead.
> I wonder if I have a patch vs 2.4 branch on ppc,could
> I send to Marcelo Tosatti directly?
>
> > But his point is that new development efforts should
> > be based on the new, shiny, improved v2.6 kernel,
> > since that is where all development
> > is focused at. And as time passes, v2.4 will get
> > more and more obsolete.
>
> I am looking forward to seeing the day coming. :-)

Me too :)

> > Unfortunately for 8xx users, as noted by other
> > people on this thread,
> > v2.6 is not yet 100% (wish it was, I'm myself trying
> > to get our boards
> > to boot v2.6).
>
> Could you make it? I once booted v2.6 on RPXlite DW
> via ramdisk root file system but failed via NFS.

There was an oops at startup, but it reached
"VFS: Mounting root" point.

It took me almost two weeks to get there.

Note our board has quite some specific needs which are not
supported in mainline.

I plan to send a CONFIG_PRxK (new sub-sub-architecture)
to PPC maintainers as soon as I have it clean (its
years work of Cyclades programmers work on top of
MontaVista work) to support it.

Other people seem to get it to boot fully (reported here on
the list), but there's still needs work to be done on
TLB flushing code (Paul & others discussed this in-depth
on the list a month ago or so).


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: 2.4 versus 2.6 patches

[Demke, Torsten]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Hello Robert,

>
> well, the linuxppc-2.5 bk pull from bkbits.net compiles and boots on
> our 8xx board.  although i'm still working on relocating SMC1 to allow
> ethernet on SCC3.  but other than that, sure, it builds and boots.
>
I'm using here a MPC852T with SMC1 and SCC3. Attached is part of an private
patch
against linuxppc-2.5. Its used on our board (CONFIG_SHMC) and there are some
hardcoded
values, but you could try...

/*
* The relocation address must match with the
* port address that is used in the driver table[]!
*   reloc. addr       | table.port
*   (offset in dpmem) | (offset in dparam)
*   0x1FC0            | 0x03C0  <---- hardcoded
*/

Regards,
Torsten


[-- Attachment #2: SMC1_SCC3.patch --]
[-- Type: application/octet-stream, Size: 4159 bytes --]

diff -purN linuxppc-2.6.7-bk1.1248-org/include/asm-ppc/commproc.h linuxppc-2.6.7-bk1.1248/include/asm-ppc/commproc.h
--- linuxppc-2.6.7-bk1.1248-org/include/asm-ppc/commproc.h	2004-07-20 10:56:22.000000000 +0200
+++ linuxppc-2.6.7-bk1.1248/include/asm-ppc/commproc.h	2004-07-20 11:02:21.000000000 +0200
@@ -145,6 +145,8 @@ typedef struct smc_uart {
 	ushort	smc_brkec;	/* rcv'd break condition counter */
 	ushort	smc_brkcr;	/* xmt break count register */
 	ushort	smc_rmask;	/* Temporary bit mask */
+	u_char  smc_res[8];     /* 0x34..0x3b */
+	ushort	smc_rpbase;	/* Relocation pointer */
 } smc_uart_t;
 
 /* Function code bits.
diff -purN linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c
--- linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c	2004-07-20 10:57:37.000000000 +0200
+++ linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c	2004-07-20 11:02:21.000000000 +0200
@@ -743,6 +743,15 @@ static void cpm_uart_init_smc(struct uar
 	pinfo->smcup->smc_rbase = (u_char *)pinfo->rx_bd_base - DPRAM_BASE;
 	pinfo->smcup->smc_tbase = (u_char *)pinfo->tx_bd_base - DPRAM_BASE;
 
+#if defined (CONFIG_SHMC) && defined (CONFIG_UCODE_PATCH)
+	up->smc_rbptr = pinfo->smcup->smc_rbase;
+	up->smc_tbptr = pinfo->smcup->smc_tbase;
+	up->smc_rstate = 0;
+	up->smc_tstate = 0;
+	up->smc_brkcr = 1;		/* number of break chars */
+	up->smc_brkec = 0;
+#endif
+
 	/* Set up the uart parameters in the
 	 * parameter ram.
 	 */
diff -purN linuxppc-2.6.7-bk1.1248-org/arch/ppc/8xx_io/micropatch.c linuxppc-2.6.7-bk1.1248/arch/ppc/8xx_io/micropatch.c
--- linuxppc-2.6.7-bk1.1248-org/arch/ppc/8xx_io/micropatch.c	2004-07-20 10:57:49.000000000 +0200
+++ linuxppc-2.6.7-bk1.1248/arch/ppc/8xx_io/micropatch.c	2004-07-20 11:02:21.000000000 +0200
@@ -20,9 +20,8 @@
 #include <asm/commproc.h>
 
 /* Define this to get SMC patches as well.  You need to modify the uart
- * driver as well......
+ * driver as well...... */
 #define USE_SMC_PATCH 1
- */
 
 #ifdef CONFIG_USB_MPC8xx
 #define USE_USB_SOF_PATCH
@@ -638,6 +637,7 @@ cpm_load_patch(volatile immap_t *immr)
 	volatile cpm8xx_t	*commproc;
 	volatile iic_t		*iip;
 	volatile spi_t		*spp;
+	volatile smc_uart_t	*smp;
 	int	i;
 
 	commproc = (cpm8xx_t *)&immr->im_cpm;
@@ -683,7 +683,11 @@ cpm_load_patch(volatile immap_t *immr)
 #if defined(USE_SMC_PATCH) || defined(USE_IIC_PATCH)
 
 	iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
+#if defined(USE_SMC_PATCH) /* uses dpmem from 0..0x4FF */
+#define RPBASE 0x0500
+#else
 #define RPBASE 0x0400
+#endif
 	iip->iic_rpbase = RPBASE;
 
 	/* Put SPI above the IIC, also 32-byte aligned.
@@ -707,6 +711,20 @@ cpm_load_patch(volatile immap_t *immr)
 	/* Enable uCode fetches from DPRAM.
 	*/
 	commproc->cp_rccr = 3;
+
+	printk("SMC1 uCode patch installed\n");
+
+	/* Put SMC DSP2 area. 
+	 * The relocation address must match with the 
+	 * port address that is used in the rs_table[]!  
+	 *   reloc. addr       | rs_table.port
+	 *   (offset in dpmem) | (offset in dparam)
+	 *   0x1FC0            | 0x03C0  
+	*/
+	smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
+	smp->smc_rpbase = 0x1FC0;
+
+	printk("SMC1 relocated to 0x%x\n", smp->smc_rpbase);
 #endif
 
 #ifdef USE_IIC_PATCH
diff -purN linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_cpm1.c linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_cpm1.c
--- linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_cpm1.c	2004-07-20 10:56:09.000000000 +0200
+++ linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_cpm1.c	2004-07-20 11:02:21.000000000 +0200
@@ -196,6 +196,10 @@ int cpm_uart_init_portdesc(void)
 	cpm_uart_ports[UART_SMC1].smcp = &cpmp->cp_smc[0];
 	cpm_uart_ports[UART_SMC1].smcup =
 	    (smc_uart_t *) & cpmp->cp_dparam[PROFF_SMC1];
+#if defined (CONFIG_SHMC) && defined (CONFIG_UCODE_PATCH)
+	cpm_uart_ports[UART_SMC1].smcup =
+	    (smc_uart_t *) & cpmp->cp_dparam[0x3C0];
+#endif
 	cpm_uart_ports[UART_SMC1].port.mapbase =
 	    (unsigned long)&cpmp->cp_smc[0];