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

[Pavel Pisa]

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

 - 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.

 - 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.

 - 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.

 - 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).

 - 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.

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.

 - rtems-m9328-pimx1-baud-19200.patch
     not interesting, only change of default baudrate from 38400 -> 19200

 - 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. 

 - 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.

 - 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.

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.

Please, decide, which patches could be integrated into RTEMS CVS.
If you prefer some patch approval policy, declare it.
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. 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.

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.

Best wishes

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