ARM core and i.MX MX1 patches intended for RTEMS 4.7 inclusion

[Pavel Pisa]

Hello Jay,

On Saturday 03 June 2006 05:38, Jay Monkman wrote:
> Pavel Pisa wrote:
> >  - rtems-arm-more-abort-info.patch
> >  - rtems-csb336-undef-stack.patch
> >  - rtems-csb336-20051008-uart.patch
> >  - rtems-csb336-20051008-other.patch
> >  - rtems-csb336-20051008-asyncmclk.patch
>
> I've committed these patches. I even tested that the sample programs still
> run on the CSB336.

Thanks much for committing the patches.

> Pavel, for some reason that I couldn't figure out, your uart patch was
> rejected, but I was able to apply my original one. If you made more changes
> to it, can you send me a diff against the latest in CVS?

I have compared resulting files and there seems to be differences
only in whitespaces. I use quilt and it push users by its objections
to not leave whitespaces on ends of lines so this could be source
of some deviations.

I have rebuilt RTEMS (CVS rtems-060602), MicroWindows, our libraries
and our application. I have not observed deviations from rtems-060419.
Because I am not aware of any rtems-060419 issue affecting our code,
I do not intend to switch our development environment and colleagues
shared setup to the updated version now. We would have to restart
long run test cycle. But I definitely want invest time to that
once 4.7 is out. I would retest BSP for 4.7 release candidates as well.

> >  - rtems-m9328-pimx1-mapping-change.patch
> >  - rtems-m9328-pimx1-baud-19200.patch
>
> I haven't applied these. Since they are specific to your board, I think we
> should make the changes conditional.
>
> Joel, is there a preferred way of doing this? I can do it with an #ifdef,
> but isn't there some way to do it with an autoconf flag?

I agree, they should not be included directly.

As for baudrate, I think, that it would be nice to have
BSP independent configure option to select initial console baudrate.
If it is not set, BSP should use conventional value for the
target in question. Else user override should be used.
I would welcome this feature for others BSP as well.

The mapping change does two things.

The first one is to extend covered internal address range to include
eSRAM memory found on MX1. We use eSRAM as MicroWindows frame buffer
in our application. The patch has no effect on MXL except accesses
to eSRAM range would return meaningless data.

The second thing is switching of SDRAM range to write-back
caching policy. It should be fully compatible to MXL as well.
It should increase CPU performace and lowewer number of
write accesses over external bus. I have not noticed some big
performance impact in practice, but I believe, that it could
lower power consumption a little. On the other hand, this
could be problem for cases, when framebuffer is fed from SDRAM,
because writes could be delayed. It is possible to add some
cache range cleanup function in such case or map specific
part of SDRAM with write through. I have some version
of ARM920T cache management functions ported to RTEMS
for such cases. So this change is more advanced user
option than some board specific feature.

It seems, that MX1 support for RTEMS and Linux-2.6 is getting
into better shape by this time, but I have fear, if all
users has not abandoned this family due to lack of support
and FreeScale not so much cooperative behavior in the past.

Thanks again for cooperation

                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa
        work:   http://www.pikron.com