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

[Joel Sherrill]

Pavel Pisa wrote:

>Hello Jay and Joel and all others,
>
>I would be happy to sort out next patches and include them
>in RTEMS CVS. I have already tried to offer them once,
>but it seems that time constraints resulted in their loss
>in the abyss of time.
>
>All my patches are accessible at next place
>
>http://rtime.felk.cvut.cz/darcs/darcsweb.cgi?r=rtems-devel;a=tree;f=/rtems-patches
>http://rtime.felk.cvut.cz/repos/rtems-devel/rtems-patches/
>
>They has been used for many months with 2005-10-08 RTEMS CVS snapshot.
>They are extensively used on test series of the instruments
>with 2006-04-19 CVS snapshot. No problem has been observed.
>It runs more control, safety, user interface task, logging and
>maintenance of user accessible archives on MMC/SD card.
>
>There is list of patches. I summary these intended for inclusion
>into RTEMS CVS first
>  
>

First, I have not looked at the actual code.  I am going to go on your 
comments
and give my initial thoughts.  I think there is a logical progression 
through these
and we can nibble the list down.  Some seem more obviously ready/OK to
review and merge quickly.  If Jay concurs on those, then we can nibble the
next chunk.

> - rtems-arm-more-abort-info.patch
>     this patch corrects ARM abort handling. Actual CVS code uses
>     mixes CPU_Exception_frame and Context_Control frame types
>     and result is, that it is not possible to retrieve usable
>     information from the abort case. Patch adapts assembly code
>     and "C" handler to agree on the stack contents and if
>     _print_full_context() is used, it enables to retrieve
>     valuable information about source of the problem.
>     Original code tries to fixup some aborts caused by unaligned
>     access, but it doesnot work correctly and it result in
>     dangerous hiding of errors which is unacceptable for safety
>     application. The fixup code is disabled.
>
>  
>
This seems like a good candidate for quick review and merge. 

> - rtems-csb336-undef-stack.patch
>     this patch ensures, that space for UDEF stack is allocated
>     for CSB336 board. This is required to include breakpoint
>     handling (GDB stub) in the application. Similar update
>     for all other ARM boards should be considered.
>
>  
>
Seems obviously needed. 

> - rtems-csb336-20051008-uart.patch
>     the enhanced interrupt driven MX1 UART code kindly provided
>     by Jay Monkman. Works well for months and it is shame to not
>     have it in RTEMS CVS.
>
>  
>
Again.. sounds OK to review and merge.

> - rtems-csb336-20051008-other.patch
>     there are more of Jay Monkman's enhancements. Again, I think
>     that it is shame to lost them. Jay even included my correction
>     of PLL and peripherals clock computation. All is CSB336+MX1
>     specific, same as preceding two changes, so risk of some
>     breakage of another platform is minimal (if not zero).
>
>  
>
Again.. sounds OK to review and merge.

> - rtems-csb336-20051008-asyncmclk.patch
>     this patch is required to enable MX1 ARM CPU core to run on
>     its own PLL at full speed (150..200MHz) above external
>     IO frequency (<=96MHz). We do not use this for power consumption
>     and EMI reasons, but it should be included in RTEMS sources.
>     May be, it should be conditionalized. I can adapt it according
>     to your preferences.
>
>  
>
If you think it can easily be conditionalized and there are technical 
reasons why
someone might want to do it both ways, then adding a BSP specific 
conditional
is the right thing to do.  Look at pc386/configure.ac and 
USE_COM1_AS_CONSOLE
as a simple example.  The mbx8xx BSP also uses BSP conditionals in 
conjunction
with BSP variants to change behavior between variants.

>There is more stuff which is not intended for inclusion
>or which generic usability can be discused.
>
> - rtems-m9328-pimx1-mapping-change.patch
>     this is patch with modifications required for PiMX1 board.
>     I have not cloned CSB336, because the overlap is so high
>     and duplication would lead only to problems with correcting
>     and updating things on multiple places.
>
>     In the fact we only need to extend internal registers range 
>     include eSRAM for framebuffer
>       {0x00200000, 0x00200000,   2,    MMU_CACHE_NONE},     /* Internal Regs + eSRAM */
>     and we ran with write back caching which works reliably as write through does
>       {0x08000000, 0x08000000,  32,    MMU_CACHE_WBACK},    /* SDRAM */
>
>     patch is not intended for inclusion. Some idea, how to do that
>     some other acceptable way would not be bad, but due to patch size
>     I see actual solution as maintainable and good even for future.
>
>  
>
The PiMX1 appears to be a commercially available board so making it a 
variant
of the csb336 would be perfectly acceptable.  This would allow for 
conditional
compilation based upon the BSP name or using the BSP name in configure.ac
to trip feature conditional flags.

> - rtems-m9328-pimx1-baud-19200.patch
>     not interesting, only change of default baudrate from 38400 -> 19200
>
>  
>
I think making this a BSP conditional and then using the BSP variant 
name to select
the default baud rate sounds like the way to go.

> - rtems-inttypes-wcs-disable-fix.patch
>     we have some problems with inclusion of inttypes.h in some cases.
>     Probably NEWLIB version problem. This is simple and temporarily fix,
>     we do not need WCS, because our app is fully UTF-8 based. 
>
>  
>
Best to ignore this and assume a tool problem on your side.

> - rtems-clone-mrm332-to-mo376.patch
> - rtems-update-mrm332-to-mo376.patch
> - rtems-mo376-add-to-configs.patch
> - rtems-mo376-m68376-updates.patch
>     tested and working support for our MO_CPU2 68376 based board.
>     Used at university in some diploma thesis works for robotic
>     control etc. If somebody things, that this can be usesfull and
>     inclusion is good idea, go on. If not, can stay as external patches
>  
>
My first reaction is to not merge code for boards that are not generally 
available but
at the same time, this sounds like it might have more generally useful 
stuff in it.
This will require some review/discussion to really know what to do with 
it.  Are you
copying the BSP or building a variant?

Is there any code added to libcpu or shared that is generally useful?

The mrm332 BSP has some odd things I don't think are 100% correct so 
this might
fix those anyway.

> - rtems-clone-ss555-to-ec555.patch
> - rtems-ec555-add-to-configs.patch
> - rtems-update-ss555-to-ec555.patch
> - rtems-update-ss555-to-ec555-cpld-remove.patch
>     same for EC555 board, but not finished. Student has not invest
>     time to test and polish that. Should not be problem to finish
>     that and if I find free time (not so much probable) I return to that.
>  
>
Is this the Wurz board? 

Is this a variant or a copy?

Sounds like you want to wait until it is in better shape.

>There are other more project specific things I can provide,
>if somebody has interrest. MX1 MMC/SD driver, MX1 keyboard driver
>and many other pieces of our projects up to full featured XML
>driven GUI (SuiTk) developed by Roman Bartosinski and me.
>
>  
>
Without looking, the MMC/SD driver is probably of interest to the general
community.  Other pieces may be as well.

>Please, decide, which patches could be integrated into RTEMS CVS.
>If you prefer some patch approval policy, declare it.
>  
>
For the ARM patches and those which impact BSPs Jay has written, I would
prefer that he review and merge them.  I hope he doesn't have a problem 
doing
this. 

>I can sent full patches one per message over list (but I do not think
>that it is best solution for its volume). If you provide me GNATS
>login or pointer to HOWTO, I can sent patches there. 
>
I don't see shipping them over the list and for non-bugs, it is just as 
easy to merge
from email or downloading. 

Given the long list of patches, it might make sense to add a Wiki page 
based on this
email so we can track merging and commenting on each patch.

>If you prefer
>to split patches to specific smaller chunks I can do that.
>If you have another preference, send me note and I try to follow that.
>
>  
>
Sounds like you have split them into logical pieces and we need to start 
nibbling
at the top of the list.

>But I would be happy, if I can forget about the first batch of
>patches existence after RTEMS-4.7 release. I have significant
>problems with frequent brain memory and queues overflow exceptions
>and scheduler overload states.
>
>  
>
I don't see waiting for the parts that are ready.

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