Patches for the eCos 2.0 branch

Patches for the eCos 2.0 branch

[John Dallaway]

[ moving from ecos-patches to ecos-maintainers ]

Gary, Nick and all

Nick Garnett wrote:

> Gary Thomas <gary@mlbassoc.com> writes:

>> You know me - I'm always interested in more [debug] information :-)
>> By all means, apply this, and the QUICC changes as well.

> Currently I have applied this only to the trunk, since the v2.0 branch
> does not have the changes that you made to the CPM/DPRAM allocator.
> Were you going to apply these to the v2 branch, was there some reason
> not to do that? If you are awaiting approval consider it given.

To avoid invalidating beta testing, we need to be very careful about what 
goes into the 2.0 branch. Does the CPM/DPRAM allocator patch address a 
known problem or is it purely delivering a new feature?

I would like to see some more formal consensus among the maintainers on what 
goes in to the 2.0 branch from here on.

John Dallaway

Re: Patches for the eCos 2.0 branch

[Gary Thomas]

On Tue, 2003-03-18 at 01:48, John Dallaway wrote:
> [ moving from ecos-patches to ecos-maintainers ]
> 
> Gary, Nick and all
> 
> Nick Garnett wrote:
> 
> > Gary Thomas <gary@mlbassoc.com> writes:
> 
> >> You know me - I'm always interested in more [debug] information :-)
> >> By all means, apply this, and the QUICC changes as well.
> 
> > Currently I have applied this only to the trunk, since the v2.0 branch
> > does not have the changes that you made to the CPM/DPRAM allocator.
> > Were you going to apply these to the v2 branch, was there some reason
> > not to do that? If you are awaiting approval consider it given.
> 
> To avoid invalidating beta testing, we need to be very careful about what 
> goes into the 2.0 branch. Does the CPM/DPRAM allocator patch address a 
> known problem or is it purely delivering a new feature?
> 

IMO it addresses a long-standing deficiency. 

> I would like to see some more formal consensus among the maintainers on what 
> goes in to the 2.0 branch from here on.

Just doing as I was asked.
-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Proposal for processing patches for the eCos 2.0 branch

[John Dallaway]

Hello eCos Maintainers

I've spoken with some of you already about putting in place a process for 
deciding which patches do and do not get applied to the eCos 2.0 branch 
from now on. I would like to suggest that we post proposals for patching 
the 2.0 branch to the ecos-maintainers (sic) list. Each proposal should 
contain:

a) A brief name by which we can all refer to the patch.

b) A description of what the patch achieves or the problem which it 
addresses. No more than a few sentences.

c) A rationale for including the patch in the 2.0 final release. This 
rationale should be mindful of the need to minimise disruption to the 
branch as far as possible and therefore preserve the value of 2.0b1 testing 
feedback from the eCos community. A good rationale might be: "This patch 
touches the XYZ platform HAL package only. Support for this platform is 
currently completely broken." A bad rationale might be: "This patch 
provides feature ABC which I've been intending to implement for ages and 
would really like to see in the eCos 2.0 final release."

d) The patch itself, or a URL to the patch in the ecos-patches list archive.

I would like the eCos maintainers to then have a maximum period of 2 days to 
debate before (hopefully) a consensus is reached. If consensus is not 
reached then a simple majority verdict among the maintainers should 
prevail.

The above procedure should be adopted for all target side code in the branch 
at minimum. There is still quite a bit of work to be done on the configtool 
for 2.0 final so we might consider excepting configtool code from this 
process.

The usual procedures for patches to the trunk of the repository would be 
unaffected by all this.

Please comment on or otherwise indicate your acceptance of this proposal and 
whether you think configtool patches should be excepted or not.

Thanks

John Dallaway

Re: Proposal for processing patches for the eCos 2.0 branch

[Jonathan Larmour]

John Dallaway wrote:
> 
> The usual procedures for patches to the trunk of the repository would be 
> unaffected by all this.
> 
> Please comment on or otherwise indicate your acceptance of this proposal

Everything except the 2 day limit. Not everyone can necessarily turn 
around replies that quickly if they're out of town. Obviously you're 
trying to curtail the patch submission process to prevent everything all 
happening at the last minute, but I think that's safe enough because as we 
get closer to final, patches will need to be more and more important to 
qualify anyway, and the default after all is "no", so it's in people's 
interests to get patches in.

Oh, and a cvs diff command to run is as good as a pointer to ecos-patches 
IMHO. i.e. "cvs diff -D date1 -D date2 somepackage". It'll be obvious from 
the rationale and the date what the ecos-patches message is if anyone's 
interested to look at the original. The diff is more useful than the 
ecos-patches mail, because many (contributed) patches are changed somewhat 
before committing; and sometimes you need multiple patches anyway.

 > and
> whether you think configtool patches should be excepted or not.

I don't think I'm qualified to say what should or shouldn't go in the 
config tool, and you're the one making the changes, and you're more 
cautious than me :-), so I'm happy.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Proposal for processing patches for the eCos 2.0 branch

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> 
> Oh, and a cvs diff command to run is as good as a pointer to
> ecos-patches IMHO. i.e. "cvs diff -D date1 -D date2
> somepackage". It'll be obvious from the rationale and the date what
> the ecos-patches message is if anyone's interested to look at the
> original. The diff is more useful than the ecos-patches mail, because
> many (contributed) patches are changed somewhat before committing; and
> sometimes you need multiple patches anyway.

I don't like this. I, and maybe others, have limited ability to run
commands against the CVS repository. I would much prefer to be able to
fetch the diff out of an email, either here or in ecos-patches. If the
proposal is significantly different from the ecos-patches message, it
should be included again.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: Proposal for processing patches for the eCos 2.0 branch

[Andrew Lunn]

> The above procedure should be adopted for all target side code in the branch 
> at minimum. There is still quite a bit of work to be done on the configtool 
> for 2.0 final so we might consider excepting configtool code from this 
> process.

Please could you elaborate on the configtool issues. 

I used it yesterday for the first time to do the requested testing of
2.0b1. I ran into problems running the test cases. Quite a few times
it did not detect when the test case had finished. I also had gdb
protocol errors with signal4. Running the tests by hand worked
fine. Are these known issues? Do i need to create bugzilla entries?

      Andrew

PS 

The testing of AFE1 passed. I used the HAL from 1.5.2 since this is
not in 2.0b1. I then tried to put Redboot in the boot block rather
than using ascom's POST as the boot block and killed the board :-(
This is probably my error in building the image since its not a normal
setup. Time to find a JTAG programmer.

Re: Proposal for processing patches for the eCos 2.0 branch

[Jonathan Larmour]

Andrew Lunn wrote:
 >John Dallaway wrote:
>>There is still quite a bit of work to be done on the configtool 
>>for 2.0 final so we might consider excepting configtool code from this 
>>process.
> 
> 
> Please could you elaborate on the configtool issues. 
> 
> I used it yesterday for the first time to do the requested testing of
> 2.0b1. I ran into problems running the test cases. Quite a few times
> it did not detect when the test case had finished. I also had gdb
> protocol errors with signal4. Running the tests by hand worked
> fine. Are these known issues? Do i need to create bugzilla entries?

I don't think I ever saw a reply to this, so if this is still reproducable 
with a snapshot from http://www.ecoscentric.com/devzone/configtool.shtml 
then bugzilla it.

> The testing of AFE1 passed. I used the HAL from 1.5.2 since this is
> not in 2.0b1. I then tried to put Redboot in the boot block rather
> than using ascom's POST as the boot block and killed the board :-(
> This is probably my error in building the image since its not a normal
> setup. Time to find a JTAG programmer.

Glad AFE sorta worked, and hope you got it sorted!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Proposal for processing patches for the eCos 2.0 branch

[Andrew Lunn]

> >I used it yesterday for the first time to do the requested testing of
> >2.0b1. I ran into problems running the test cases. Quite a few times
> >it did not detect when the test case had finished. I also had gdb
> >protocol errors with signal4. Running the tests by hand worked
> >fine. Are these known issues? Do i need to create bugzilla entries?
> 
> I don't think I ever saw a reply to this, so if this is still 
> reproducable with a snapshot from 
> http://www.ecoscentric.com/devzone/configtool.shtml then bugzilla it.

I've not tried it again. Maybe later this week.
 
> >The testing of AFE1 passed. I used the HAL from 1.5.2 since this is
> >not in 2.0b1. I then tried to put Redboot in the boot block rather
> >than using ascom's POST as the boot block and killed the board :-(
> >This is probably my error in building the image since its not a normal
> >setup. Time to find a JTAG programmer.
> 
> Glad AFE sorta worked, and hope you got it sorted!

Nope. I took the lazy option of pulled a couple of old EBSA based
devices out of the junk cupboard.

        Andrew

Re: Proposal for processing patches for the eCos 2.0 branch

[Andrew Lunn]

Hi folks

Is there some sort of time plan for 2.0 final? The longer it takes,
the more patches from the trunk we will want to put into the branch. 

As to the process, its fine by me. 

   Andrew

Re: Proposal for processing patches for the eCos 2.0 branch

[Jonathan Larmour]

Andrew Lunn wrote:
> Hi folks
> 
> Is there some sort of time plan for 2.0 final? The longer it takes,
> the more patches from the trunk we will want to put into the branch. 

We were saying the same earlier over lunch :-). While the "official" 
answer to give the net is always "when it's ready" (although it never 
really will be, arguably), we should aim for a month or so - enough time 
for feedback, but not enough time for serious divergence.

It's possible we can do some sort of rolling snapshot releases from the 
trunk, but the overhead and care and feeding may be too difficult, as well 
as the inevitable support questions (it can be _good_ to put the "barrier" 
of CVS in the way!).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

SNMP for FreeBSD

[Andrew Lunn]

> a) A brief name by which we can all refer to the patch.

SNMP for FreeBSD
 
> b) A description of what the patch achieves or the problem which it 
> addresses. No more than a few sentences.

This patch allows the SNMP code to work with the FreeBSD stack as well
as the OpenBSD stack.
 
> c) A rationale for including the patch in the 2.0 final release. 

Currently the branch only supports SNMP with the OpenBSD stack. This
is no longer the default stack for 2.0b1. FreeBSD should become the
stack everyone uses, but if people want SNMP they are forced to use
the old stack. This patch touches the two snmp packages only. It does
have the risk of breaking the OpenBSD support for snmp :-(

> d) The patch itself, or a URL to the patch in the ecos-patches list archive.

cvs diff -D 2003-02-14 packages/net/snmp

Also, see the thread starting at 
http://sources.redhat.com/ml/ecos-patches/2003-02/msg00177.html


> I would like the eCos maintainers to then have a maximum period of 2 days to 
> debate before (hopefully) a consensus is reached. If consensus is not 
> reached then a simple majority verdict among the maintainers should 
> prevail.

Its unlikely i will have time to do anything till Tuesday, so take
your time.

 
        Andrew

Re: SNMP for FreeBSD

[Jonathan Larmour]

Andrew Lunn wrote:
> 
>>c) A rationale for including the patch in the 2.0 final release. 
> 
> 
> Currently the branch only supports SNMP with the OpenBSD stack. This
> is no longer the default stack for 2.0b1. FreeBSD should become the
> stack everyone uses, but if people want SNMP they are forced to use
> the old stack. This patch touches the two snmp packages only. It does
> have the risk of breaking the OpenBSD support for snmp :-(

This is a highly desirable patch as it gets rid of a long-standing issue, 
and Andrew has tested it, and Ascom have used the stack far more than any 
other user anyway! I would very much like to have it, although I can see 
why it wouldn't be considered "critical". So I'll leave it to John to make 
a final decision.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: SNMP for FreeBSD

[Gary Thomas]

On Wed, 2003-03-19 at 06:20, Jonathan Larmour wrote:
> Andrew Lunn wrote:
> > 
> >>c) A rationale for including the patch in the 2.0 final release. 
> > 
> > 
> > Currently the branch only supports SNMP with the OpenBSD stack. This
> > is no longer the default stack for 2.0b1. FreeBSD should become the
> > stack everyone uses, but if people want SNMP they are forced to use
> > the old stack. This patch touches the two snmp packages only. It does
> > have the risk of breaking the OpenBSD support for snmp :-(
> 
> This is a highly desirable patch as it gets rid of a long-standing issue, 
> and Andrew has tested it, and Ascom have used the stack far more than any 
> other user anyway! I would very much like to have it, although I can see 
> why it wouldn't be considered "critical". So I'll leave it to John to make 
> a final decision.

I tested it on PowerPC (for big-endian coverage) and it worked well
for me too.  I think it should be applied.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: SNMP for FreeBSD

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Andrew Lunn wrote:
> >
> >> c) A rationale for including the patch in the 2.0 final release.
> > Currently the branch only supports SNMP with the OpenBSD stack. This
> > is no longer the default stack for 2.0b1. FreeBSD should become the
> > stack everyone uses, but if people want SNMP they are forced to use
> > the old stack. This patch touches the two snmp packages only. It does
> > have the risk of breaking the OpenBSD support for snmp :-(
> 
> This is a highly desirable patch as it gets rid of a long-standing
> issue, and Andrew has tested it, and Ascom have used the stack far
> more than any other user anyway! I would very much like to have it,
> although I can see why it wouldn't be considered "critical". So I'll
> leave it to John to make a final decision.
> 

It gets my vote too.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: SNMP for FreeBSD

[Andrew Lunn]

On Tue, Mar 18, 2003 at 08:16:18PM +0100, Andrew Lunn wrote:
> > a) A brief name by which we can all refer to the patch.
> 
> SNMP for FreeBSD

Since there were no objections, i've just committed this to the 2.0
branch.

        Andrew

2.0 branch: mn10300 debug info patch

[Bart Veer]

>>>>> "John" == John Dallaway <jld@ecoscentric.com> writes:

    a) A brief name by which we can all refer to the patch.

mn10300 debug info

    John> b) A description of what the patch achieves or the problem
    John> which it addresses. No more than a few sentences.

Add debug info sections to the mn10300 am31/am33 linker scripts

    John> c) A rationale for including the patch in the 2.0 final
          release.

Without this patch the debug info in mn10300 binaries is broken and
debugging is impossible. Only the mn10300 am31 and am33 variant HAL's
are affected.

    John> d) The patch itself, or a URL to the patch in the
    John> ecos-patches list archive.

http://sources.redhat.com/ml/ecos-patches/2003-03/msg00104.html

Bart

Re: 2.0 branch: mn10300 debug info patch

[John Dallaway]

I vote to apply this one to the 2.0 branch on the condition that it has been 
sanity tested for debugging against the AM31 simulator first.

John Dallaway

-----Original Message-----
From: Bart Veer
Date: Wednesday 19 Mar 2003 14:22
Subject: 2.0 branch: mn10300 debug info patch

> >>>>> "John" == John Dallaway <jld@ecoscentric.com> writes:
>
>     a) A brief name by which we can all refer to the patch.
>
> mn10300 debug info
>
>     John> b) A description of what the patch achieves or the problem
>     John> which it addresses. No more than a few sentences.
>
> Add debug info sections to the mn10300 am31/am33 linker scripts
>
>     John> c) A rationale for including the patch in the 2.0 final
>           release.
>
> Without this patch the debug info in mn10300 binaries is broken and
> debugging is impossible. Only the mn10300 am31 and am33 variant HAL's
> are affected.
>
>     John> d) The patch itself, or a URL to the patch in the
>     John> ecos-patches list archive.
>
> http://sources.redhat.com/ml/ecos-patches/2003-03/msg00104.html
>
> Bart

Re: 2.0 branch: mn10300 debug info patch

[Nick Garnett]

Bart Veer <bartv@ecoscentric.com> writes:

> >>>>> "John" == John Dallaway <jld@ecoscentric.com> writes:
> 
>     a) A brief name by which we can all refer to the patch.
> 
> mn10300 debug info
> 
>     John> b) A description of what the patch achieves or the problem
>     John> which it addresses. No more than a few sentences.
> 
> Add debug info sections to the mn10300 am31/am33 linker scripts
> 
>     John> c) A rationale for including the patch in the 2.0 final
>           release.
> 
> Without this patch the debug info in mn10300 binaries is broken and
> debugging is impossible. Only the mn10300 am31 and am33 variant HAL's
> are affected.
> 
>     John> d) The patch itself, or a URL to the patch in the
>     John> ecos-patches list archive.
> 
> http://sources.redhat.com/ml/ecos-patches/2003-03/msg00104.html
> 
> Bart
> 

This has my vote. The worst that can happen is that it doesn't fix the
problem, but I doubt Bart would be proposing it if it didn't, it
certainly cannot do any harm.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: Patches for the eCos 2.0 branch

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> > 
> > To avoid invalidating beta testing, we need to be very careful about what 
> > goes into the 2.0 branch. Does the CPM/DPRAM allocator patch address a 
> > known problem or is it purely delivering a new feature?
> > 
> 
> IMO it addresses a long-standing deficiency.

Indeed.

> 
> > I would like to see some more formal consensus among the maintainers on what 
> > goes in to the 2.0 branch from here on.
> 
> Just doing as I was asked.

If this change does not go in to the v2 branch then I will have to
check a slightly different version of the quicc ethernet driver in
there than the one I checked into the trunk. 

Gary's patch also introduces an incompatibility between old and new
RedBoots/eCoses, since management of the DPRAM is now shared. Without
it eCoses build with V2 cannot run on RedBoots built out of the trunk,
and vice versa. So I think it is essential.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: Patches for the eCos 2.0 branch

[Gary Thomas]

On Tue, 2003-03-18 at 11:09, Nick Garnett wrote:
> Gary Thomas <gary@mlbassoc.com> writes:
> 
> > > 
> > > To avoid invalidating beta testing, we need to be very careful about what 
> > > goes into the 2.0 branch. Does the CPM/DPRAM allocator patch address a 
> > > known problem or is it purely delivering a new feature?
> > > 
> > 
> > IMO it addresses a long-standing deficiency.
> 
> Indeed.
> 
> > 
> > > I would like to see some more formal consensus among the maintainers on what 
> > > goes in to the 2.0 branch from here on.
> > 
> > Just doing as I was asked.
> 
> If this change does not go in to the v2 branch then I will have to
> check a slightly different version of the quicc ethernet driver in
> there than the one I checked into the trunk. 
> 
> Gary's patch also introduces an incompatibility between old and new
> RedBoots/eCoses, since management of the DPRAM is now shared. Without
> it eCoses build with V2 cannot run on RedBoots built out of the trunk,
> and vice versa. So I think it is essential.

Actually, I tried to make it such that a dependency does not exist
(note the most recent version which this patch reflects does try 
and work properly even without an updated RedBoot).  I may have
missed the mark, but I did try.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: Patches for the eCos 2.0 branch

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> 
> Actually, I tried to make it such that a dependency does not exist
> (note the most recent version which this patch reflects does try 
> and work properly even without an updated RedBoot).  I may have
> missed the mark, but I did try.
> 

It certainly caused me a bit of head scratching when I tried running
on an Adder board with an old RedBoot yesterday. Fortunately I
remembered your change and updating the Adder's RedBoot fixed it.

The problem appeared to be that *(CYGHWR_HAL_VSR_TABLE + 0x1F0)
contained 0xFFFF, resulting in _mpc8xx_allocBd() starting again from
QUICC_BD_BASE and overwriting RedBoot's stuff for the serial device.

The effect I saw was that halfway through initializing the rx buffer
descriptors, the serial device went haywire.

I'm not sure how it is possible to make this code backward compatible,
since without the value in (CYGHWR_HAL_VSR_TABLE + 0x1F0), eCos has no
way of knowing where in the DPRAM it can make allocations.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: Patches for the eCos 2.0 branch

[Gary Thomas]

On Tue, 2003-03-18 at 12:05, Nick Garnett wrote:
> Gary Thomas <gary@mlbassoc.com> writes:
> 
> > 
> > Actually, I tried to make it such that a dependency does not exist
> > (note the most recent version which this patch reflects does try 
> > and work properly even without an updated RedBoot).  I may have
> > missed the mark, but I did try.
> > 
> 
> It certainly caused me a bit of head scratching when I tried running
> on an Adder board with an old RedBoot yesterday. Fortunately I
> remembered your change and updating the Adder's RedBoot fixed it.
> 
> The problem appeared to be that *(CYGHWR_HAL_VSR_TABLE + 0x1F0)
> contained 0xFFFF, resulting in _mpc8xx_allocBd() starting again from
> QUICC_BD_BASE and overwriting RedBoot's stuff for the serial device.
> 
> The effect I saw was that halfway through initializing the rx buffer
> descriptors, the serial device went haywire.
> 
> I'm not sure how it is possible to make this code backward compatible,
> since without the value in (CYGHWR_HAL_VSR_TABLE + 0x1F0), eCos has no
> way of knowing where in the DPRAM it can make allocations.

The drivers are supposed to be flexible in this case.  If the
eCos program changes the serial port setup (allocates different
buffer descriptors), the driver in RedBoot should be OK with it
since it uses only the data from the CPM after initialization.

I could see a problem though - RedBoot could choose some region
for the buffers for the serial port and then, because of the lack of 
communication, eCos might choose those same locations for the
network.  If you were running an eCos program with networking in
it, I could see this happening.

Alas, it seems that updating RedBoot is a good idea anyway :-)

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

New CPM/DPRAM allocator

[John Dallaway]

Hello eCos maintainers

I'm concerned to read of the incompatibility between newer eCos builds and 
older RedBoot builds due to the new CPM/DPRAM allocator. If I understand 
correctly:

a) The incompatibility which has arisen was not intentional.
b) The new allocator is highly desirable.
c) There does not appear to be any way to avoid the incompatibility 
robustly.

A few of questions:

1) Does this incompatibilty affect _all_ targets which run both RedBoot and 
eCos?
2) Could the new allocator implementation be modified in any way to preserve 
compatibility?
3) To what extent might the new allocator perturb eCos functionality other 
than by a stepwise "it will work or it will be completely broken".
4) Is a further break in compatibility possible as potential issues with the 
new allocator are ironed out?

We need to determine how to manage the switch over to the new CPM/DPRAM 
allocator smoothly for everyone. From my perspective, it is certainly 
unfortunate that this innovation has arrived between 2.0 beta and 2.0 
final. Were it not for the break in compatibility, I would vote against 
incorporating this change for 2.0 final since the change will (to a certain 
extent) invalidate beta testing by the net community. However, it would 
also be undesirable for 2.0 final RedBoot to be incompatible with anonCVS 
eCos from day 1. Users are likely to want to stick with a release version 
of the firmware while experimenting with eCos from anonCVS.

John Dallaway

Re: New CPM/DPRAM allocator

[Nick Garnett]

John Dallaway <jld@ecoscentric.com> writes:

> A few of questions:
> 
> 1) Does this incompatibilty affect _all_ targets which run both RedBoot and 
> eCos?

Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.

> 2) Could the new allocator implementation be modified in any way to preserve 
> compatibility?

Possibly. But I'll defer to Gary on this one.

> 3) To what extent might the new allocator perturb eCos functionality other 
> than by a stepwise "it will work or it will be completely broken".

It shouldn't affect anything else. Failure modes are hard to specify
since they depend on the contents of what is currently an
uninitialized location in RAM. Different instances of RedBoot might
have different values there.

We might even be able to add a test to the DPRAM code to detect an old
RedBoot and generate an error message before proceeding.

> 4) Is a further break in compatibility possible as potential issues with the 
> new allocator are ironed out?

Unlikely. The code is only a handful of lines. 

> 
> We need to determine how to manage the switch over to the new CPM/DPRAM 
> allocator smoothly for everyone. From my perspective, it is certainly 
> unfortunate that this innovation has arrived between 2.0 beta and 2.0 
> final. Were it not for the break in compatibility, I would vote against 
> incorporating this change for 2.0 final since the change will (to a certain 
> extent) invalidate beta testing by the net community. However, it would 
> also be undesirable for 2.0 final RedBoot to be incompatible with anonCVS 
> eCos from day 1. Users are likely to want to stick with a release version 
> of the firmware while experimenting with eCos from anonCVS.
> 

It only affects a handful of boards: MBX, VIPER, ADDER, TS1000. QUICC2
targets like the tS6 and VADS are not affected, and non-QUICC MPC8xx
targets like the CMA28x and FADS boards are not affected.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: New CPM/DPRAM allocator

[Gary Thomas]

On Wed, 2003-03-19 at 04:07, Nick Garnett wrote:
> John Dallaway <jld@ecoscentric.com> writes:
> 
> > A few of questions:
> > 
> > 1) Does this incompatibilty affect _all_ targets which run both RedBoot and 
> > eCos?
> 
> Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.
> 
> > 2) Could the new allocator implementation be modified in any way to preserve 
> > compatibility?
> 
> Possibly. But I'll defer to Gary on this one.
> 

The more I look at this, the less I understand why it fails now.  The 
new allocation scheme should not clash - i.e. mixing new eCos with old
RedBoot should be OK.

Perhaps if I can figure out why this is failing, I can propose a change
which will not cause problems.

> > 3) To what extent might the new allocator perturb eCos functionality other 
> > than by a stepwise "it will work or it will be completely broken".
> 
> It shouldn't affect anything else. Failure modes are hard to specify
> since they depend on the contents of what is currently an
> uninitialized location in RAM. Different instances of RedBoot might
> have different values there.
> 
> We might even be able to add a test to the DPRAM code to detect an old
> RedBoot and generate an error message before proceeding.
> 
> > 4) Is a further break in compatibility possible as potential issues with the 
> > new allocator are ironed out?
> 
> Unlikely. The code is only a handful of lines. 
> 
> > 
> > We need to determine how to manage the switch over to the new CPM/DPRAM 
> > allocator smoothly for everyone. From my perspective, it is certainly 
> > unfortunate that this innovation has arrived between 2.0 beta and 2.0 
> > final. Were it not for the break in compatibility, I would vote against 
> > incorporating this change for 2.0 final since the change will (to a certain 
> > extent) invalidate beta testing by the net community. However, it would 
> > also be undesirable for 2.0 final RedBoot to be incompatible with anonCVS 
> > eCos from day 1. Users are likely to want to stick with a release version 
> > of the firmware while experimenting with eCos from anonCVS.
> > 
> 
> It only affects a handful of boards: MBX, VIPER, ADDER, TS1000. QUICC2
> targets like the tS6 and VADS are not affected, and non-QUICC MPC8xx
> targets like the CMA28x and FADS boards are not affected.
> 
> -- 
> Nick Garnett                    eCos Kernel Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: New CPM/DPRAM allocator

[John Dallaway]

Nick Garnett wrote:

> > 1) Does this incompatibilty affect _all_ targets which run both RedBoot
> > and eCos?
>
> Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.

Good. Not as pervasive as I suspected. It looks like Gary is investigating 
why the incompatibility is there at all. Hopefully he can resolve the 
compatibility issue. I will delay my vote on accepting this into the 2.0 
branch pending his report.

John Dallaway

Re: New CPM/DPRAM allocator

[Gary Thomas]

On Wed, 2003-03-19 at 08:45, John Dallaway wrote:
> Nick Garnett wrote:
> 
> > > 1) Does this incompatibilty affect _all_ targets which run both RedBoot
> > > and eCos?
> >
> > Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.
> 
> Good. Not as pervasive as I suspected. It looks like Gary is investigating 
> why the incompatibility is there at all. Hopefully he can resolve the 
> compatibility issue. I will delay my vote on accepting this into the 2.0 
> branch pending his report.

I've just tried this - CVS latest eCos + old (2.0beta) RedBoot
on the Adder and I can't see a failure.  I tried both the default
and net templates.

Nick - any ideas how I can duplicate the failure?

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: New CPM/DPRAM allocator

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> On Wed, 2003-03-19 at 08:45, John Dallaway wrote:
> > Nick Garnett wrote:
> > 
> > > > 1) Does this incompatibilty affect _all_ targets which run both RedBoot
> > > > and eCos?
> > >
> > > Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.
> > 
> > Good. Not as pervasive as I suspected. It looks like Gary is investigating 
> > why the incompatibility is there at all. Hopefully he can resolve the 
> > compatibility issue. I will delay my vote on accepting this into the 2.0 
> > branch pending his report.
> 
> I've just tried this - CVS latest eCos + old (2.0beta) RedBoot
> on the Adder and I can't see a failure.  I tried both the default
> and net templates.
> 
> Nick - any ideas how I can duplicate the failure?
> 

I'm afraid not. I was, until Monday, using the default RedBoot
installed by A&M on the board. Maybe there were other changes since
that was made that make this problem go away.

As explained elsewhere, what I saw was the value at
(CYGHWR_HAL_VSR_TABLE + 0x1F0) was 0xFFFF. This caused
_mpc8xx_allocBd() to reset it to QUICC_BD_BASE and start allocating
network rxbds from there. At some point during that process it
obviously overwrote something being used by redboot's serial device,
which then went haywire.

I don't see how the code as it stands can avoid this. How does the new
eCos know where to allocate BDs to avoid trampling on an old RedBoot's
BDs? Just allocating from the start it seems bound to trample on
something important.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: New CPM/DPRAM allocator

[Gary Thomas]

On Wed, 2003-03-19 at 11:22, Nick Garnett wrote:
> Gary Thomas <gary@mlbassoc.com> writes:
> 
> > On Wed, 2003-03-19 at 08:45, John Dallaway wrote:
> > > Nick Garnett wrote:
> > > 
> > > > > 1) Does this incompatibilty affect _all_ targets which run both RedBoot
> > > > > and eCos?
> > > >
> > > > Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example.
> > > 
> > > Good. Not as pervasive as I suspected. It looks like Gary is investigating 
> > > why the incompatibility is there at all. Hopefully he can resolve the 
> > > compatibility issue. I will delay my vote on accepting this into the 2.0 
> > > branch pending his report.
> > 
> > I've just tried this - CVS latest eCos + old (2.0beta) RedBoot
> > on the Adder and I can't see a failure.  I tried both the default
> > and net templates.
> > 
> > Nick - any ideas how I can duplicate the failure?
> > 
> 
> I'm afraid not. I was, until Monday, using the default RedBoot
> installed by A&M on the board. Maybe there were other changes since
> that was made that make this problem go away.
> 
> As explained elsewhere, what I saw was the value at
> (CYGHWR_HAL_VSR_TABLE + 0x1F0) was 0xFFFF. This caused
> _mpc8xx_allocBd() to reset it to QUICC_BD_BASE and start allocating
> network rxbds from there. At some point during that process it
> obviously overwrote something being used by redboot's serial device,
> which then went haywire.
> 
> I don't see how the code as it stands can avoid this. How does the new
> eCos know where to allocate BDs to avoid trampling on an old RedBoot's
> BDs? Just allocating from the start it seems bound to trample on
> something important.

Only that the old code didn't use 0x2000 for it's buffers, but
0x2800 (for the serial ports).  The only driver that this should
affect would be the serial driver in the installed RedBoot.  If
the new allocator is using a different "base", then there should
be no conflict.

Do you recall what configurations/templates/etc you were using?

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

Re: New CPM/DPRAM allocator

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> 
> Only that the old code didn't use 0x2000 for it's buffers, but
> 0x2800 (for the serial ports).  The only driver that this should
> affect would be the serial driver in the installed RedBoot.  If
> the new allocator is using a different "base", then there should
> be no conflict.

OK. I hadn't realized that. Have you moved QUICC_BD_BASE before?
Could the original Adder RedBoot have been using 0x2000 too?

> 
> Do you recall what configurations/templates/etc you were using?

Nothing special. The standard net template with some config to give
the ethernet device a static IP address, and turn assertions
on. Nothing that would affect things at this level.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: New CPM/DPRAM allocator

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> 
> With the attached version of the code, I think we'll be
> quite safe.  This changes the behaviour of the code, mitigating
> the possibility of clashes, but it's not 100%.
> 
> Is there any way you can test this?  Do you have the original
> Adder ROM contents?  If not, I've attached what I sent to A&M
> when it was first released.
> 

I'll give this a go tomorrow sometime.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: New CPM/DPRAM allocator

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> With the attached version of the code, I think we'll be
> quite safe.  This changes the behaviour of the code, mitigating
> the possibility of clashes, but it's not 100%.
> 
> Is there any way you can test this?  Do you have the original
> Adder ROM contents?  If not, I've attached what I sent to A&M
> when it was first released.

I've now tried this: it works correctly on the Adder with the old
RedBoot in place. So this change has my approval, for both the trunk
and the v2 branch.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

Re: New CPM/DPRAM allocator

[Gary Thomas]

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

On Thu, 2003-03-20 at 04:51, Nick Garnett wrote:
> Gary Thomas <gary@mlbassoc.com> writes:
> 
> > With the attached version of the code, I think we'll be
> > quite safe.  This changes the behaviour of the code, mitigating
> > the possibility of clashes, but it's not 100%.
> > 
> > Is there any way you can test this?  Do you have the original
> > Adder ROM contents?  If not, I've attached what I sent to A&M
> > when it was first released.
> 
> I've now tried this: it works correctly on the Adder with the old
> RedBoot in place. So this change has my approval, for both the trunk
> and the v2 branch.

Excellent.  I'll be committing this patch to the branch (trunk 
is already done).  Just a final "looks good" please.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 22618 bytes --]

Index: devs/eth/powerpc/quicc/current/ChangeLog
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/devs/eth/powerpc/quicc/current/ChangeLog,v
retrieving revision 1.16
diff -u -5 -p -r1.16 ChangeLog
--- devs/eth/powerpc/quicc/current/ChangeLog	25 Nov 2002 23:20:51 -0000	1.16
+++ devs/eth/powerpc/quicc/current/ChangeLog	17 Mar 2003 23:34:53 -0000
@@ -1,5 +1,9 @@
+2003-03-06  Gary Thomas  <gary@mlbassoc.com>
+
+	* src/if_quicc.c (quicc_eth_init): New name for CPM/DPRAM allocator.
+
 2002-11-25  Gary Thomas  <gthomas@ecoscentric.com>
 
 	* src/quicc_eth.h: 
 	* src/if_quicc.c: Split platform specifics into separate packages.
 
Index: devs/eth/powerpc/quicc/current/src/if_quicc.c
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/devs/eth/powerpc/quicc/current/src/if_quicc.c,v
retrieving revision 1.15
diff -u -5 -p -r1.15 if_quicc.c
--- devs/eth/powerpc/quicc/current/src/if_quicc.c	25 Nov 2002 23:20:51 -0000	1.15
+++ devs/eth/powerpc/quicc/current/src/if_quicc.c	17 Mar 2003 23:34:53 -0000
@@ -245,12 +245,12 @@ quicc_eth_init(struct cyg_netdevtab_entr
     // Shut down ethernet, in case it is already running
     scc->scc_gsmr_l &= ~(QUICC_SCC_GSML_ENR | QUICC_SCC_GSML_ENT);
 
     memset((void *)enet_pram, 0, sizeof(*enet_pram));
 
-    TxBD = cyg_hal_allocBd(CYGNUM_DEVS_ETH_POWERPC_QUICC_TxNUM * sizeof(struct cp_bufdesc));
-    RxBD = cyg_hal_allocBd(CYGNUM_DEVS_ETH_POWERPC_QUICC_RxNUM * sizeof(struct cp_bufdesc));
+    TxBD = _mpc8xx_allocBd(CYGNUM_DEVS_ETH_POWERPC_QUICC_TxNUM * sizeof(struct cp_bufdesc));
+    RxBD = _mpc8xx_allocBd(CYGNUM_DEVS_ETH_POWERPC_QUICC_RxNUM * sizeof(struct cp_bufdesc));
 
     txbd = (struct cp_bufdesc *)((char *)eppc + TxBD);
     rxbd = (struct cp_bufdesc *)((char *)eppc + RxBD);
     qi->tbase = txbd;
     qi->txbd = txbd;    
Index: devs/serial/powerpc/quicc/current/ChangeLog
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/devs/serial/powerpc/quicc/current/ChangeLog,v
retrieving revision 1.13
diff -u -5 -p -r1.13 ChangeLog
--- devs/serial/powerpc/quicc/current/ChangeLog	24 Feb 2003 14:18:55 -0000	1.13
+++ devs/serial/powerpc/quicc/current/ChangeLog	17 Mar 2003 23:42:43 -0000
@@ -1,5 +1,10 @@
+2003-03-05  Gary Thomas  <gary@mlbassoc.com>
+
+	* src/quicc_smc_serial.c: Use common routines to manage CPM/DPRAM
+	pointers - much nicer in a multi-driver environment.
+
 2003-02-24  Jonathan Larmour  <jifl@eCosCentric.com>
 
 	* cdl/ser_quicc_smc.cdl: Remove irrelevant doc link.
 
 2002-12-10  Gary Thomas  <gthomas@ecoscentric.com>
Index: devs/serial/powerpc/quicc/current/src/quicc_smc_serial.c
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/devs/serial/powerpc/quicc/current/src/quicc_smc_serial.c,v
retrieving revision 1.9
diff -u -5 -p -r1.9 quicc_smc_serial.c
--- devs/serial/powerpc/quicc/current/src/quicc_smc_serial.c	23 May 2002 23:01:23 -0000	1.9
+++ devs/serial/powerpc/quicc/current/src/quicc_smc_serial.c	17 Mar 2003 23:42:00 -0000
@@ -7,10 +7,11 @@
 //==========================================================================
 //####ECOSGPLCOPYRIGHTBEGIN####
 // -------------------------------------------
 // This file is part of eCos, the Embedded Configurable Operating System.
 // Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
+// Copyright (C) 2003 Gary Thomas
 //
 // eCos is free software; you can redistribute it and/or modify it under
 // the terms of the GNU General Public License as published by the Free
 // Software Foundation; either version 2 or (at your option) any later version.
 //
@@ -57,10 +58,11 @@
 #include <cyg/hal/hal_intr.h>
 #include <cyg/io/devtab.h>
 #include <cyg/io/serial.h>
 #include <cyg/infra/diag.h>
 #include <cyg/hal/hal_cache.h>
+#include <cyg/hal/quicc/ppc8xx.h>
 #include CYGBLD_HAL_PLATFORM_H
 
 #ifdef CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC
 
 // macro for aligning buffers to cache lines
@@ -388,10 +390,11 @@ quicc_smc_serial_init(struct cyg_devtab_
     quicc_smc_serial_info *smc_chan = (quicc_smc_serial_info *)chan->dev_priv;
     volatile EPPC *eppc = (volatile EPPC *)eppc_base();
     int TxBD, RxBD;
     static int first_init = 1;
     int cache_state;
+
     HAL_DCACHE_IS_ENABLED(cache_state);
     HAL_DCACHE_SYNC();
     HAL_DCACHE_DISABLE();
 #ifdef CYGDBG_IO_INIT
     diag_printf("QUICC_SMC SERIAL init - dev: %x.%d\n", smc_chan->channel, smc_chan->int_num);
@@ -400,12 +403,12 @@ quicc_smc_serial_init(struct cyg_devtab_
         // Set up tables since many fields are dynamic [computed at runtime]
         first_init = 0;
 #ifdef CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC_SMC1
         eppc->cp_cr = QUICC_SMC_CMD_Reset | QUICC_SMC_CMD_Go;  // Totally reset CP
         while (eppc->cp_cr & QUICC_SMC_CMD_Reset) ;
-        TxBD = 0x2800;  // Note: this should be configurable
-        RxBD = TxBD + CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_TxNUM*8;
+        TxBD = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_TxNUM);
+        RxBD = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_RxNUM);
         quicc_smc_serial_init_info(&quicc_smc_serial_info1,
                                    &eppc->pram[2].scc.pothers.smc_modem.psmc.u, // PRAM
                                    &eppc->smc_regs[0], // Control registers
                                    TxBD, 
                                    CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_TxNUM,
@@ -417,11 +420,10 @@ quicc_smc_serial_init(struct cyg_devtab_
                                    ALIGN_TO_CACHELINES(&quicc_smc1_rxbuf[0][0]),
                                    0xC0, // PortB mask
                                    CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_BRG,
                                    12  // SI mask position
             );
-        TxBD = RxBD + CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC1_RxNUM*8;
 #else
 #ifdef CYGPKG_HAL_POWERPC_MBX
         // Ensure the SMC1 side is initialized first and use shared mem
         // above where it plays:
         diag_init();    // (pull in constructor that inits diag channel)
@@ -433,11 +435,12 @@ quicc_smc_serial_init(struct cyg_devtab_
         while (eppc->cp_cr & QUICC_SMC_CMD_Reset) ;
         TxBD = 0x2800;  // Note: this should be configurable
 #endif        
 #endif
 #ifdef CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC_SMC2
-        RxBD = TxBD + CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC2_TxNUM*8;
+        TxBD = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC2_TxNUM);
+        RxBD = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC2_RxNUM);
         quicc_smc_serial_init_info(&quicc_smc_serial_info2,
                                    &eppc->pram[3].scc.pothers.smc_modem.psmc.u, // PRAM
                                    &eppc->smc_regs[1], // Control registers
                                    TxBD, 
                                    CYGNUM_IO_SERIAL_POWERPC_QUICC_SMC_SMC2_TxNUM,
Index: hal/powerpc/quicc/current/ChangeLog
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/powerpc/quicc/current/ChangeLog,v
retrieving revision 1.27
diff -u -5 -p -r1.27 ChangeLog
--- hal/powerpc/quicc/current/ChangeLog	26 Nov 2002 15:36:55 -0000	1.27
+++ hal/powerpc/quicc/current/ChangeLog	17 Mar 2003 23:26:06 -0000
@@ -1,5 +1,22 @@
+2003-03-06  Gary Thomas  <gary@mlbassoc.com>
+
+	* src/cpm.c: Handle case where DPRAM allocation is unknown.
+	
+	* include/ppc8xx.h: Define limits of CPM/DPRAM space.
+
+2003-03-05  Gary Thomas  <gary@mlbassoc.com>
+
+	* src/quicc_smc1.c: Need to flush data cache because the serial
+	driver may set use buffers in cacheable memory.  Without this,
+	diag_printf() falls over if the serial driver is ever used.
+
+	* src/cpm.c: New file with CPM/DPRAM support.
+
+	* include/ppc8xx.h: 
+	* cdl/hal_powerpc_quicc.cdl: Split out support for CPM/DPRAM.
+
 2002-11-26  Gary Thomas  <gthomas@ecoscentric.com>
 
 	* src/quicc_smc1.c: Initialize BD allocation point.  Note that it is
 	different from when the CPM get's reset directly.  This is to allow
 	sharing of the space between ROM (RedBoot) code and applications.
Index: hal/powerpc/quicc/current/cdl/hal_powerpc_quicc.cdl
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/powerpc/quicc/current/cdl/hal_powerpc_quicc.cdl,v
retrieving revision 1.8
diff -u -5 -p -r1.8 hal_powerpc_quicc.cdl
--- hal/powerpc/quicc/current/cdl/hal_powerpc_quicc.cdl	26 Nov 2002 13:48:19 -0000	1.8
+++ hal/powerpc/quicc/current/cdl/hal_powerpc_quicc.cdl	17 Mar 2003 23:26:06 -0000
@@ -7,11 +7,11 @@
 # ====================================================================
 #####ECOSGPLCOPYRIGHTBEGIN####
 ## -------------------------------------------
 ## This file is part of eCos, the Embedded Configurable Operating System.
 ## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
-## Copyright (C) 2002 Gary Thomas
+## Copyright (C) 2002, 2003 Gary Thomas
 ##
 ## eCos is free software; you can redistribute it and/or modify it under
 ## the terms of the GNU General Public License as published by the Free
 ## Software Foundation; either version 2 or (at your option) any later version.
 ##
@@ -98,11 +98,11 @@ cdl_package CYGPKG_HAL_QUICC {
         display    "SCC3 is available for serial I/O"
         description "
           Port SCC3 is available for serial I/O"
     }
 
-    compile       quicc_smc1.c
+    compile       quicc_smc1.c cpm.c
 
    cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS {
        display      "Number of communication channels on the board"
        flavor       data
        calculated   CYGNUM_HAL_QUICC_SMC1+CYGNUM_HAL_QUICC_SMC2+CYGNUM_HAL_QUICC_SCC1+CYGNUM_HAL_QUICC_SCC2+CYGNUM_HAL_QUICC_SCC3
Index: hal/powerpc/quicc/current/include/ppc8xx.h
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/powerpc/quicc/current/include/ppc8xx.h,v
retrieving revision 1.11
diff -u -5 -p -r1.11 ppc8xx.h
--- hal/powerpc/quicc/current/include/ppc8xx.h	25 Nov 2002 23:20:53 -0000	1.11
+++ hal/powerpc/quicc/current/include/ppc8xx.h	17 Mar 2003 23:26:06 -0000
@@ -10,11 +10,11 @@
 //==========================================================================
 //####ECOSGPLCOPYRIGHTBEGIN####
 // -------------------------------------------
 // This file is part of eCos, the Embedded Configurable Operating System.
 // Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
-// Copyright (C) 2002 Gary Thomas
+// Copyright (C) 2002, 2003 Gary Thomas
 //
 // eCos is free software; you can redistribute it and/or modify it under
 // the terms of the GNU General Public License as published by the Free
 // Software Foundation; either version 2 or (at your option) any later version.
 //
@@ -937,13 +937,15 @@ static inline EPPC *eppc_base(void)
 }
 
 
 // Function used to allocate space in shared memory area
 // typically used for buffer descriptors, etc.
-__externC unsigned short cyg_hal_allocBd(int len);
+__externC void _mpc8xx_reset_cpm(void);
+__externC unsigned short _mpc8xx_allocBd(int len);
 
 #define QUICC_BD_BASE               0x2000  // Start of shared memory
+#define QUICC_BD_END                0x3000  // End of shared memory
 
 
 #endif /* __ASSEMBLER__ */
 
 /* Memory Periodic Timer Prescaler Register values */
Index: hal/powerpc/quicc/current/src/cpm.c
===================================================================
RCS file: hal/powerpc/quicc/current/src/cpm.c
diff -N hal/powerpc/quicc/current/src/cpm.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ hal/powerpc/quicc/current/src/cpm.c	20 Mar 2003 13:11:06 -0000
@@ -0,0 +1,115 @@
+//==========================================================================
+//
+//      cpm.c
+//
+//      PowerPC QUICC support functions
+//
+//==========================================================================
+//####ECOSGPLCOPYRIGHTBEGIN####
+// -------------------------------------------
+// This file is part of eCos, the Embedded Configurable Operating System.
+// Copyright (C) 2003 Gary Thomas
+//
+// eCos is free software; you can redistribute it and/or modify it under
+// the terms of the GNU General Public License as published by the Free
+// Software Foundation; either version 2 or (at your option) any later version.
+//
+// eCos is distributed in the hope that it will be useful, but WITHOUT ANY
+// WARRANTY; without even the implied warranty of MERCHANTABILITY or
+// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+// for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with eCos; if not, write to the Free Software Foundation, Inc.,
+// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+//
+// As a special exception, if other files instantiate templates or use macros
+// or inline functions from this file, or you compile this file and link it
+// with other works to produce a work based on this file, this file does not
+// by itself cause the resulting work to be covered by the GNU General Public
+// License. However the source code for this file must still be made available
+// in accordance with section (3) of the GNU General Public License.
+//
+// This exception does not invalidate any other reasons why a work based on
+// this file might be covered by the GNU General Public License.
+//
+// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
+// at http://sources.redhat.com/ecos/ecos-license/
+// -------------------------------------------
+//####ECOSGPLCOPYRIGHTEND####
+//==========================================================================
+//#####DESCRIPTIONBEGIN####
+//
+// Author(s):    Gary Thomas 
+// Contributors: 
+// Date:         2003-03-04
+// Purpose:      Common support for the QUICC/CPM
+// Description:  
+//               
+// Usage:
+// Notes:        
+//
+//####DESCRIPTIONEND####
+//
+//==========================================================================
+
+#include <pkgconf/hal.h>
+#include <pkgconf/hal_powerpc_quicc.h>
+#include <cyg/infra/cyg_type.h>
+#include <cyg/hal/hal_arch.h>
+
+#ifdef CYGPKG_HAL_POWERPC_MPC860
+// eCos headers decribing PowerQUICC:
+#include <cyg/hal/quicc/ppc8xx.h>
+
+// Information about DPRAM usage
+// This lets the CPM/DPRAM information be shared by all environments
+//
+static short *nextBd = (short *)(CYGHWR_HAL_VSR_TABLE + 0x1F0);
+
+/*
+ * Reset the communications processor
+ */
+
+void
+_mpc8xx_reset_cpm(void)
+{
+    EPPC *eppc = eppc_base();
+    int i;
+    static int init_done = 0;
+
+    if (init_done) return;
+    init_done++;
+
+    eppc->cp_cr = QUICC_CPM_CR_RESET | QUICC_CPM_CR_BUSY;
+    memset(eppc->pram, 0, 0x400);
+    for (i = 0; i < 100000; i++);
+
+    *nextBd = QUICC_BD_BASE;
+}
+
+//
+// Allocate a chunk of memory in the shared CPM memory, typically
+// used for buffer descriptors, etc.  The length will be aligned
+// to a multiple of 8 bytes.
+//
+unsigned short
+_mpc8xx_allocBd(int len)
+{
+    unsigned short bd;
+
+    bd = *nextBd;
+    if ((bd < QUICC_BD_BASE) || (bd > QUICC_BD_END)) {
+        // Most likely not set up - make a guess :-(
+        bd = *nextBd = QUICC_BD_BASE+0x400;
+    }
+    len = (len + 7) & ~7;  // Multiple of 8 bytes
+    *nextBd += len;
+    if (*nextBd >= QUICC_BD_END) {
+        *nextBd = QUICC_BD_BASE;
+    }
+    return bd;
+}
+
+#endif // CYGPKG_HAL_POWERPC_MPC860
+// EOF cpm.c
Index: hal/powerpc/quicc/current/src/quicc_smc1.c
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/powerpc/quicc/current/src/quicc_smc1.c,v
retrieving revision 1.23
diff -u -5 -p -r1.23 quicc_smc1.c
--- hal/powerpc/quicc/current/src/quicc_smc1.c	26 Nov 2002 15:36:56 -0000	1.23
+++ hal/powerpc/quicc/current/src/quicc_smc1.c	17 Mar 2003 23:26:06 -0000
@@ -7,11 +7,11 @@
 //==========================================================================
 //####ECOSGPLCOPYRIGHTBEGIN####
 // -------------------------------------------
 // This file is part of eCos, the Embedded Configurable Operating System.
 // Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
-// Copyright (C) 2002 Gary Thomas
+// Copyright (C) 2002, 2003 Gary Thomas
 //
 // eCos is free software; you can redistribute it and/or modify it under
 // the terms of the GNU General Public License as published by the Free
 // Software Foundation; either version 2 or (at your option) any later version.
 //
@@ -131,49 +131,10 @@ static struct port_info ports[] = {
 #define QUICC_SMCE_BSY 0x04  // Busy - receive buffer overrun
 #define QUICC_SMCE_TX  0x02  // Tx interrupt
 #define QUICC_SMCE_RX  0x01  // Rx interrupt
 
 /*
- * Reset the communications processor
- */
-
-static short nextBd = QUICC_BD_BASE + 0x400;
-
-static void
-reset_cpm(void)
-{
-    EPPC *eppc = eppc_base();
-    int i;
-    static int init_done = 0;
-
-    if (init_done) return;
-    init_done++;
-
-    eppc->cp_cr = QUICC_CPM_CR_RESET | QUICC_CPM_CR_BUSY;
-    memset(eppc->pram, 0, 0x400);
-    for (i = 0; i < 100000; i++);
-
-    nextBd = QUICC_BD_BASE;
-
-}
-
-//
-// Allocate a chunk of memory in the shared CPM memory, typically
-// used for buffer descriptors, etc.  The length will be aligned
-// to a multiple of 8 bytes.
-//
-unsigned short
-cyg_hal_allocBd(int len)
-{
-    unsigned short bd = nextBd;
-
-    len = (len + 7) & ~7;  // Multiple of 8 bytes
-    nextBd += len;
-    return bd;
-}
-
-/*
  *  Initialize SMCX as a uart.
  *
  *  Comments below reference Motorola's "MPC860 User Manual".
  *  The basic initialization steps are from Section 16.15.8
  *  of that manual.
@@ -188,11 +149,11 @@ cyg_hal_smcx_init_channel(struct port_in
     struct cp_bufdesc *txbd, *rxbd;
 
     if (info->init) return;
     info->init = 1;
 
-    reset_cpm();
+    _mpc8xx_reset_cpm();
 
     switch (port) {
 #if CYGNUM_HAL_QUICC_SMC1 > 0
     case QUICC_CPM_SMC1:
         /*
@@ -238,12 +199,12 @@ cyg_hal_smcx_init_channel(struct port_in
 
     /*
      *  Set pointers to buffer descriptors.
      *  (Sections 16.15.4.1, 16.15.7.12, and 16.15.7.13)
      */
-    uart_pram->rbase = cyg_hal_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum);
-    uart_pram->tbase = cyg_hal_allocBd(sizeof(struct cp_bufdesc)*info->Txnum + info->Txnum);
+    uart_pram->rbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum);
+    uart_pram->tbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Txnum + info->Txnum);
 
     /*
      *  SDMA & LCD bus request level 5
      *  (Section 16.10.2.1)
      */
@@ -333,10 +294,11 @@ cyg_hal_smcx_putc(void* __ch_data, cyg_u
     EPPC *eppc = eppc_base();
     struct port_info *info = (struct port_info *)__ch_data;
     volatile struct smc_uart_pram *uart_pram = (volatile struct smc_uart_pram *)((char *)eppc + info->pram);
     volatile struct smc_regs *regs = (volatile struct smc_regs *)((char *)eppc + info->regs);
     int timeout;
+    int cache_state;
     CYGARC_HAL_SAVE_GP();
 
     /* tx buffer descriptor */
     bd = (struct cp_bufdesc *)((char *)eppc + uart_pram->tbptr);
 
@@ -356,12 +318,18 @@ cyg_hal_smcx_putc(void* __ch_data, cyg_u
         // This buffer has just completed interrupt output.  Reset bits
         bd->ctrl &= ~QUICC_BD_CTL_Int;
         bd->length = 0;
     }
 
-    bd->buffer[bd->length++] = ch;
+    bd->length = 1;
+    bd->buffer[0] = ch;
     bd->ctrl      |= QUICC_BD_CTL_Ready;
+    // Flush cache if necessary - buffer may be in cacheable memory
+    HAL_DCACHE_IS_ENABLED(cache_state);
+    if (cache_state) {
+      HAL_DCACHE_FLUSH(bd->buffer, 1);
+    }
 
 #ifdef CYGDBG_DIAG_BUF
         enable_diag_uart = 0;
 #endif // CYGDBG_DIAG_BUF
     timeout = 0;
@@ -617,11 +585,11 @@ cyg_hal_sccx_init_channel(struct port_in
     struct cp_bufdesc *txbd, *rxbd;
 
     if (info->init) return;
     info->init = 1;
 
-    reset_cpm();
+    _mpc8xx_reset_cpm();
 
     /*
      *  Set up the Port pins for UART operation.
      */
     switch (port) {
@@ -650,30 +618,30 @@ cyg_hal_sccx_init_channel(struct port_in
         break;
 #endif
 #if CYGNUM_HAL_QUICC_SCC2 > 0
     case QUICC_CPM_SCC2:
 #error FIXME
-        eppc->pio_papar |= 0x03;
-        eppc->pio_padir &= ~0x03;
-        eppc->pio_paodr &= ~0x03;
+        eppc->pio_papar |= 0x0C;
+        eppc->pio_padir &= ~0x0C;
+        eppc->pio_paodr &= ~0x0C;
 
         /* CTS on PortC.11 */
-        eppc->pio_pcdir &= 0x800;
-        eppc->pio_pcpar &= 0x800;
-        eppc->pio_pcso  |= 0x800;
+        eppc->pio_pcdir &= 0xC00;
+        eppc->pio_pcpar &= 0xC00;
+        eppc->pio_pcso  |= 0xC00;
 
         /* RTS on PortB.19 */
-        eppc->pip_pbpar |= 0x1000;
-        eppc->pip_pbdir |= 0x1000;
+        eppc->pip_pbpar |= 0x2000;
+        eppc->pip_pbdir |= 0x2000;
 
         /* Configure baud rate generator (Section 16.13.2) */
         eppc->brgc2 = 0x10000 | (UART_BIT_RATE(UART_BAUD_RATE)<<1);
 
         /*
-         *  NMSI mode, BRG2 to SCC1
+         *  NMSI mode, BRG2 to SCC2
          */
-        eppc->si_sicr |= (1<<3)|(1<<0);
+        eppc->si_sicr |= (1<<11)|(1<<8);
         break;
 #endif
 #if CYGNUM_HAL_QUICC_SCC3 > 0
     case QUICC_CPM_SCC3:
 #if 0
@@ -704,12 +672,12 @@ cyg_hal_sccx_init_channel(struct port_in
 
     /*
      *  Set pointers to buffer descriptors.
      */
     memset((void *)uart_pram, 0xFF, 0x100);
-    uart_pram->rbase = cyg_hal_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum);
-    uart_pram->tbase = cyg_hal_allocBd(sizeof(struct cp_bufdesc)*info->Txnum + info->Txnum);
+    uart_pram->rbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum);
+    uart_pram->tbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Txnum + info->Txnum);
 
     /*
      *  SDMA & LCD bus request level 5
      */
     eppc->dma_sdcr = 1;

Re: New CPM/DPRAM allocator

[Nick Garnett]

Gary Thomas <gary@mlbassoc.com> writes:

> On Thu, 2003-03-20 at 04:51, Nick Garnett wrote:
> > Gary Thomas <gary@mlbassoc.com> writes:
> > 
> > > With the attached version of the code, I think we'll be
> > > quite safe.  This changes the behaviour of the code, mitigating
> > > the possibility of clashes, but it's not 100%.
> > > 
> > > Is there any way you can test this?  Do you have the original
> > > Adder ROM contents?  If not, I've attached what I sent to A&M
> > > when it was first released.
> > 
> > I've now tried this: it works correctly on the Adder with the old
> > RedBoot in place. So this change has my approval, for both the trunk
> > and the v2 branch.
> 
> Excellent.  I'll be committing this patch to the branch (trunk 
> is already done).  Just a final "looks good" please.
> 

Looks OK to me. I'll take your serial device changes on trust.

Once you have committed this I'll commit the if_quicc.c changes I have
waiting.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts