Dear all.
Currently, I'm porting FreeRTOS on or1200.

I have a few questions.

In the "OpenRISC 1000 Architecture Manual", I found below sentence.

"The architecture requires that all exceptions be handled in strict order with respect
to the instruction stream. When an instruction-caused exception is recognized, any
unexecuted instructions that appear earlier in the instruction stream are required to
complete before the exception is taken."


1. According to above sentence, do I need some synchronization command like "l.psync or l.msync or l.csync" before "l.sys" ?
2. Can I get some stable FreeRTOS porting on or1200 ?

Plz, help me.
Thanks.

I think these are not strictly necessary. In the OR1200 a memory access in the instruction prior to a system call should complete before the system call exception is executed. Any error due to that memory access (bus error or alignment) will cause that exception to be raised before the system call. This happens without the use of those synchronise instructions.


There's older ports of RTEMS and ecos in the OpenRISC project's repositories already. I don't know how stable they are. We don't yet have a port of FreeRTOS for OpenRISC but it would be nice to have.

Hi Quartus0

I believe there is a port of FreeRTOS to the OpenRISC, but not on the OpenCores or FreeRTOS sites. You might like to drop Richard Barry (they guy who wrote FreeRTOS) and email, since I recall him talking to me about it at a conference a couple of years ago. I know he as well as the OpenCores community would be very pleased if someone took up that port and made it more widely available.

Best wishes,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

hi.

I am porting FreeRTOS 6.1.1 on OpenRISC too. My targeting platform is minisoc with SDRAM controller. (currently work on or1ksim version 2011-02-24).

I thing if we are share the source codes, porting is can be done quickly.

Hi filepang.

Thanks for the response.

I'm attaching the current source files.
It includes the "lwip" port also. (TcpIp stack)

Actually, my port works good for about 1~2 hour.
But it suddenly hangs.
I found that it enters below infinite loop(in "list.c")

for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue pxNext )
{
/* There is nothing to do here, we are just iterating to the
wanted insertion position. */
}

I understood from the developer's comment, that the conditions for entering the above mentioned infinite loop are as follows:

/* *** NOTE ***********************************************************
If you find your application is crashing here then likely causes are:
1) Stack overflow -
see http://www.freertos.org/Stacks-and-stack-overflow-checking.html
2) Incorrect interrupt priority assignment, especially on Cortex M3
parts where numerically high priority values denote low actual
interrupt priories, which can seem counter intuitive. See
configMAX_SYSCALL_INTERRUPT_PRIORITY on http://www.freertos.org/a00110.html
3) Calling an API function from within a critical section or when
the scheduler is suspended.
4) Using a queue or semaphore before it has been initialised or
before the scheduler has been started (are interrupts firing
before vTaskStartScheduler() has been called?).
See http://www.freertos.org/FAQHelp.html for more tips.
**********************************************************************/

I checked with all the above mentioned cases, but couldn't find any any of the above cases to be met.
I suppose, the cause for entering the infinite loop is my porting error.


P.S. : Context switch occur in case of "Tick timer exception, Interrupt service routine, By system call"

Hi.

I started this project few days ago. so, my port still not working.
I'm attaching the patch. my port based on FreeRTOSV6.1.1 from SourceForge.net.
apply the patch for original FreeRTOSV6.1.1 in this way.
$ pwd
/home/acc/FreeRTOSV6.1.1
$ patch
I'm trying to writing a codes like that,
kernel is running in supervisor mode
user tasks are running in user mode
and context switching caused by system call, ISR, tick timer exception.

I think that freezing is caused by memory shortage.
I had a similar problem on the other processor.

Hi filepang.

I guess it's not memory shortage error.
FreeRTOS support to check stack error.
When you set "#define configCHECK_FOR_STACK_OVERFLOW 2", we can check that.

Anyway, if you succeed in porting, could you please send it to me ?
My email address is "shyou@eyenix.com"

Best regards.

Hi,
What is the status of the FreeRTOS port ?
I would very much like to use it for our project.
(I'm new to OpenRisc and FreeRTOS ...)

I tested it with the simulator and it seems to run fine with the demo tasks.
Enabling interrupts did not work, the main interrupt routine "int_main" is not entered.

Leif

Hi again

The above statement about interrupt not working was wrong I saw following output:
"Warning: Int on line 2 pending: ignored"

and assumed it was not working ...
But the interrupt routine is really entered.

Leif

Hi Leif

I believe that is an Or1ksim warning about unexpected behaviour. There are known doubts about how Or1ksim handles interrupts, and there are some diagnostic messages in there. You saw one. It means a second interrupt on line 2 was encountered while a previous one had not been dealt with. However the interrupt handler in FreeRTOS probably copes with this anyway.

HTH

Jeremy

hi Leif

current FreeRTOS port(rev 649) and it's demo tasks are using 'uart tx fifo empty interrupt' for send message to terminal.

if you are use interrupt in your FreeRTOS application,
1. enable interrupt of IP core - refer prvSetupHardware in main.c
2. register your interrupt handler in main interrupt handler - refer xSerialPortInitMinimal in serial/serial.c
3. write interrupt handler(vUSART_ISR), some helper function like xSerialPutChar in serial/serial.c

also, driver for IP core is needed. driver/uart.c, gpio.c and IP core's software testbench are good references.

IP cores interrupt status must be cleared in interrupt handler. but, OpenRISC interrupt related SPR and internal PIC's SPR managed by kernel. (check FreeRTOSVx.y.z/Source/portable/GCC/OpenRISC/port.c, FreeRTOSVx.y.z/Source/portable/GCC/OpenRISC/portasm.S)

current FreeRTOS port is not work perfectly. task control is work. but, other kernel API(like inter-task queue, mutex..etc) may not work. I'm working on in.

thanks.

Ok
Thanks for the info.
Sorry that I cannot be of much help with the porting.
I think I will have to use either eCos or uC/OS for our OpenRisc project since we have no extra time for OS testing/development.

Leif