MicroWindows - Has been: Development Plan Proposal for ...

[Pavel Pisa]

On Tuesday 26 October 2004 10:07, Eric Valette wrote:
> Pavel Pisa wrote:
> > On Monday 25 October 2004 16:32, Eric Valette wrote:
> >
> > we successfully use latest MicroWindows version with August
> > snapshort of RTEMS head CVS on Motorola M9328MX1 (ARM920T)
> > based board.
>
> Nice to know. How much time did it take to have something useable and
> what has been reincoprorated back into microwindows? From your comment I
> understand it was ARM specific but probably would be about the same
> problem on MIPS and PPC...

The MicroWindows has not been big problem. I have already done
port of MicroWindows for system-less application with H8S 2633 MCU
and TOSHIBA T6963 graphic LCD controller and this controller
was really difficult to talk with.

On MX1 in system-less and RTEMS setups, there has not been much to do.
I have reused standard MicroWindows linear framebuffer implementation,
but I have throw away all framebuffer allocation complexity required
for PC. My boot code initializes integrated LCD controller for mode
required by our panel. Framebuffer memory is located into internal
eSRAM of the MX1. MicroWindows "driver" only points framebuffer
code to work on that location with correct BPP.
You can see my addon "scr_mx1sl.c" at next URL
  http://cmp.felk.cvut.cz/~pisa/rtems/

We have matrix keyboard directly connected to GPIO pins of MX1.
I have more strive to prepare elegant design there than in previous case.
This is real UID compliant driver, which has worker thread and is activated
by GPIO interrupts and RTEMS timing. This enables for our system to be 
waked up from sleep modes and to correctly filter our key contacts brushes.
The design should be well portable to other architectures.
I used it on H8S and outside of RTEMS on MX1 as well.
Code is in the file "scr_mx1sl.c".

I have put diffs for RTEMS and MicroWindows to the same directory today.
Most of the RTEMS changes are temporary changes which I used to get
my system up. Only one line is really required to enable eSRAM support.

--- rtems/c/src/lib/libbsp/arm/csb336/startup/memmap.c.orig     2004-08-03 
17:13:14.0000
00000 +0200
+++ rtems/c/src/lib/libbsp/arm/csb336/startup/memmap.c  2004-08-03 
17:13:41.000000000 +0
200
@@ -21,7 +21,7 @@ mmu_sect_map_t mem_map[] = {
 /*  <phys addr>  <virt addr> <size> <flags> */
     {0x08200000, 0x00000000,   1,    MMU_CACHE_NONE},     /* Mirror of SDRAM 
*/
     {0x00100000, 0x00100000,   1,    MMU_CACHE_NONE},     /* Bootstrap ROM */
-    {0x00200000, 0x00200000,   1,    MMU_CACHE_NONE},     /* Internal Regs */
+    {0x00200000, 0x00200000,   2,    MMU_CACHE_NONE},     /* Internal Regs + 
eSRAM */
     {0x08000000, 0x08000000,  32,    MMU_CACHE_WTHROUGH}, /* SDRAM */
     {0x10000000, 0x10000000,   8,    MMU_CACHE_NONE},     /* CS0 - Flash */
     {0x12000000, 0x12000000,   1,    MMU_CACHE_NONE},     /* CS1 - enet */

There has been more MicroWindows related adaptations required.
Look into file "microwin-031117-040912.patch".

Best wishes

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