RTEMS port to Lattice Mico32 (lm32)

[Joel Sherrill]

Jukka Pietarinen wrote:
> Hi,
>
> I have started to work towards a RTEMS port to the Lattice Mico32 
> softcore CPU (lm32). I have built the tools starting with sources from 
> Lattice which are based on binutils-2.18 and gcc-3.4.4, and replaced the 
> supplied newlib with newlib-1.16 and RTEMS patches (yes, I know this gcc 
> version is outdated but unfortunately the lm32 target is not in the FSF 
> source tree).
>
>   
:(  I wish vendors would submit their ports.  Altera is in
the same situation with the NIOS 2 tools. 

Anyone who can apply pressure to the vendors to submit their
tools should. 
> The current status is that I am able to run the "hello" application with 
> a polling console. The RTEMS version I'm working is from CVS, early October.
>
>   
Great!  Hopefully you will be submitting this in the not so
distant future.

Please also write up a chapter for the CPU Supplement to
provide some details on the port.

Was the port hard so far?  Are you using the newlib C library?
> I ran into a problem with the allocation of workspace and heap. If I use 
> the shared bootcard.c heap_start is always defined as NULL. Just to get 
> forward I hard-coded the addresses and sizes for both the workspace and 
> heap in bootcard.c, but how should the start of heap be really defined? 
>   
It sounds line you have defined all the required symbols
correctly in your linkcmds but just to double check, this
is the set:

+ WorkAreaBase
+ RamBase
+ RamSize

If so, then by default libbsp/shared/bspgetworkarea.c
sets *heap_start as NULL to indicate that the logic
in libbsp/shared/bootcard.c can select the starting
address for the C Program Heap.  See the method
bootcard_bsp_libc_helper() in bootcard.c.  If you
have heap_start == NULL, then it is free to allocate
memory as it sees fit.

Set a break point at bsp_libc_init and do a back
trace.  That routine is passed the C program heap
start and size.
> There seems to be an option of using a unified work area for both 
> workspace and heap, too.
>
>   
Yes.  It is an application configure time option.  Most
of the tests use a split workspace/C program heap
configuration though.
> I'm targeting custom hardware with a ECP2M-20 FPGA, 32 Mbytes of DDR2 
> memory and 10/100 ethernet.
>
>   
In this case, the C Program Heap should be nearly all of
the 32MB of RAM for most tests.
> Thanks,
> Jukka
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985