[Xenomai-core] Xenomai server down

[Xenomai-core] Xenomai server down

[Gilles Chanteperdrix]

Hi,

xenomai.org server will be down for maintenance during the week-end.

Regards.

-- 
					    Gilles.

[Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

Hi,

it seems that i have a big problem with preemption.  (kernel 2.6.31, arm 
freescale imx25, xenomai 2.5.6 )
I send a simple application that doesn't work.

The task with name 'task2ms' has higher priority than 'taskPrintf', but 
'taskPrintf' stop the task 'task2ms' until sleeps.

I think i have a problem with ipipe porting.

Any idea ?

-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: axc25xendriverCANtest.c --]
[-- Type: text/plain, Size: 7061 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>

#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>	/* for MCL_CURRENT and MCL_FUTURE */
#include <rtdm/rtdm.h>
#include <native/task.h>

#define RTXENDRIVER_TYPE                RTDM_CLASS_TESTING
#define RTXENDRIVER_SUBCLASS            0
#define DEVICE_NAME						"axc25xendriverCAN"

/*---------------------------PRIVATE DATA---------------------------------*/

#define GPIO6_ON 		*Gpio2ValAddr |= 1 << 6
#define GPIO6_OFF		*Gpio2ValAddr &= ~(1 << 6);

static RT_TASK rt_task_desc;

typedef unsigned int canid_t;

struct can_frame {
	canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
	unsigned char    can_dlc; /* data length code: 0 .. 8 */
	unsigned char    data[8] __attribute__((aligned(8)));
};

/* valid bits in CAN ID for frame formats */
#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */
#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */

/* special address description flags for the CAN_ID */
#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
#define CAN_ERR_FLAG 0x20000000U /* error frame */



int device;
	//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;

/*---------------------------PUBLIC FUNCTIONS------------------------------*/
RT_TASK tskDesc;
RT_TASK tskCan;
RT_TASK tskDesc1;

int read_index =0;
int write_index =0;
#define SIZE_BUFFER 64

struct can_frame globCanFrameBuffer[SIZE_BUFFER];

volatile int x;
volatile int y;

/*void taskCan( void * params )
{
	struct can_frame frame;
	int nbytes;
		
	for(;;)
	{
		nbytes = rt_dev_read( device, &frame, sizeof( frame ));
	}
}*/

void task2ms( void * params )
{
	struct can_frame frame;
	int nbytes;
		
	for(;;)
	{
		GPIO6_ON;
		rt_task_sleep( 2000000 );
		GPIO6_OFF;
	}
}

void taskPrintf( void * params )
{
	for(;;)
	{
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		rt_task_sleep( 10000000 ); 
	}
}



/*void taskRead( void * params )
{
	struct can_frame frame;
	int i;


	while (1 )
	{
		//rt_task_sleep( 10000000 );
		int nbytes;
		GPIO6_ON;
		nbytes = rt_dev_read( device, &frame, sizeof( frame ));
		GPIO6_OFF;
		//for( x=0; x < 1000000; x++ );
		//for( x=0; x < 1000000; x++ );
		
		

		if( nbytes != sizeof( frame ) )
		{
			printf( "Incomplete rtr CAN frame\n" );
			return;
		}
		else
		{
			//rt_mutex_acquire( &mutex );
			globCanFrameBuffer[ write_index++ ] = frame;
			if( write_index == SIZE_BUFFER )
			{
				write_index = 0;
				//printf("Rec %d\n", SIZE_BUFFER  );
			}

			/*printf( "REC %03X, LEN %d, %02X %02X %02X %02X %02X %02X %02X %02X\n", frame.can_id, frame.can_dlc, 
						frame.data[0],
					frame.data[1],
					frame.data[2],
					frame.data[3],
					frame.data[4],
					frame.data[5],
					frame.data[6],
					frame.data[7]);
		//rt_mutex_release( &mutex );
		}
		
	}
}*/

/*void taskPrint( void * params )
{
	int localReadIndex;
	int i;

	while (1 )
	{
		rt_task_sleep( 10000000 );
		for( y=0; y < 1000000; y++ );
		for( y=0; y < 1000000; y++ );

		//rt_mutex_acquire( &mutex );
		/*if( write_index != read_index )
		{
			localReadIndex = read_index;
			read_index++;
			if( read_index == SIZE_BUFFER )
				read_index = 0;

			//rt_mutex_release( &mutex );

			printf( "RX: %04d - ", localReadIndex );
			printf( "Len: %1d - ",globCanFrameBuffer[localReadIndex].can_dlc  );
			printf( "ID: %08X - ",globCanFrameBuffer[localReadIndex].can_id  );
			for( i=0; i < globCanFrameBuffer[localReadIndex].can_dlc; i++ )
				printf( "%02X ", globCanFrameBuffer[localReadIndex].data[i]  );
			printf("\n");

		}

		else
			rt_mutex_release( &mutex );
	}
}*/

//#define QUANTUMTIMEMS 	  2
//#define QUANTUMTIMENS	  ( QUANTUMTIMEMS * 1000000 )

int main(int argc, char *argv[])
{
	int ret;
	char key;
	int nbytes;
	struct can_frame frame;
	int fd;
	
	//fprintf(stderr, "AXC25 CAN driver\n");

	// no memory-swapping for this programm
	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
	if( ret )
	{
		perror("ERROR : mlockall has failled");
		exit(1);
	}

	//fd = open( "/dev/mem", O_RDWR | O_SYNC );
	//Gpio2ValAddr = (unsigned long  *)mmap(  NULL, 0x1000, PROT_READ | PROT_WRITE,  MAP_SHARED, fd, 0x53FD0000 );

	//rt_timer_set_mode( QUANTUMTIMENS );

    //rt_mutex_create( 	&mutex, "mutexWrite" );
	
	//
	// Turn the current task into a RT-task.
	// The task has no name to allow multiple program instances to be run
	// at the same time.
	//
	/*ret = rt_task_shadow(&rt_task_desc, NULL, 1, 0);
	if( ret != 0 )
	{
		fprintf(stderr, "ERROR : rt_task_shadow: %s\n", strerror(-ret));
		exit( 1 );
	}*/
	
	//open the device
	/*fprintf(stderr, "CAN open\n");*/
	/*device = rt_dev_open( DEVICE_NAME, 0 );
	if( device < 0 )
	{
		printf( "ERROR : can't open device %s (%s)\n", DEVICE_NAME, strerror( -device ));
		exit( 1 );
	}*/

		//partenza lettura
	//rt_task_spawn( &tskDesc, "taskRead", 0, 71, T_JOINABLE, taskRead, NULL );
		//partenza stampa
	//rt_task_spawn( &tskDesc1, "taskPrint", 0, 72, T_JOINABLE, taskPrint, NULL );

	//rt_task_spawn( &tskCan, "taskCan", 0, 99, T_JOINABLE, taskCan, NULL );
	rt_task_spawn( &tskDesc, "task2ms", 0, 99, T_JOINABLE, task2ms, NULL );
	rt_task_spawn( &tskDesc1, "taskPrintf", 0, 90, T_JOINABLE, taskPrintf, NULL );


	for(;;)
	{
		//rt_task_sleep(1000000000);
		sleep( 1 );
	}

	/*for(;;)
	{
		key = getchar();

		if( key == 'd' )
		{
			frame.can_id = 1;
			nbytes = rt_dev_write( device, &frame, sizeof( frame ));
			printf("end write\n");
		}
		else if( key == 'e' )
		{
			break;
		}
		else if( key == 's' )
		{
			frame.can_id  = 0x602;
			frame.can_id &= CAN_SFF_MASK;
			frame.can_dlc = 8;
			frame.data[ 0 ] = 0x40;
			frame.data[ 1 ] = 0x00;
			frame.data[ 2 ] = 0x10;
			frame.data[ 3 ] = 0x00;
			frame.data[ 4 ] = 0x00;
			frame.data[ 5 ] = 0x00;
			frame.data[ 6 ] = 0x00;
			frame.data[ 7 ] = 0x00;
			nbytes = rt_dev_write( device, &frame, sizeof( frame ));
			if( nbytes != sizeof( frame ) )
			{
				printf( "Incomplete trs CAN frame\n" );
			}
			else
			{
				printf( "CAN frame has been sent\n" );
			}
		}
		else if( key == 'r' )
		{
			frame.can_id  = 0x702;
			frame.can_id &= CAN_SFF_MASK;
			frame.can_id |= CAN_RTR_FLAG;
			frame.can_dlc = 1;
			frame.data[ 0 ] = 0x00;
			frame.data[ 1 ] = 0x00;
			frame.data[ 2 ] = 0x00;
			frame.data[ 3 ] = 0x00;
			frame.data[ 4 ] = 0x00;
			frame.data[ 5 ] = 0x00;
			frame.data[ 6 ] = 0x00;
			frame.data[ 7 ] = 0x00;
			nbytes = rt_dev_write( device, &frame, sizeof( frame ));
			if( nbytes != sizeof( frame ) )
			{
				printf( "Incomplete rtr CAN frame\n" );
			}
			else
			{
				printf( "CAN rtr frame has been sent\n" );
			}
		}
	}*/

	//rt_task_delete( &tskDesc );
	//rt_task_join( &tskDesc );

	//close the device
	//fprintf(stderr, "CAN close\n");
	/*ret = rt_dev_close( device );
	if( ret < 0 )
	{
		printf( "ERROR : can't close device %s (%s)\n", DEVICE_NAME, strerror( -ret ));
		exit( 1 );
	}*/

	return 0;
}

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 08:55 AM, Roberto Bielli wrote:
> Hi,
> 
> it seems that i have a big problem with preemption.  (kernel 2.6.31, arm 
> freescale imx25, xenomai 2.5.6 )
> I send a simple application that doesn't work.
> 
> The task with name 'task2ms' has higher priority than 'taskPrintf', but 
> 'taskPrintf' stop the task 'task2ms' until sleeps.
> 
> I think i have a problem with ipipe porting.
> 
> Any idea ?

Please try getting a trace with the I-pipe tracer.

-- 
                                                                Gilles.

Re: [Xenomai-help] [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 11:14 AM, Roberto Bielli wrote:
> Hi,
> 
> here is the trace.

Please try to capture the xntimer_next_local_shot which happens before
the bug to see if the timer ticks when expected.

Also note that if we are going through __ipipe_preempt_schedule_irq, it
means that the task eating the cpu is running in secondary mode. So, you
should use T_WARNSW to see.

Please keep the discussion on the mailing list.	

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

Hi Gilles,

here is the new trace.

Il 06/03/2012 13:09, Gilles Chanteperdrix ha scritto:
> On 03/06/2012 11:14 AM, Roberto Bielli wrote:
>> Hi,
>>
>> here is the trace.
> Please try to capture the xntimer_next_local_shot which happens before
> the bug to see if the timer ticks when expected.
>
> Also note that if we are going through __ipipe_preempt_schedule_irq, it
> means that the task eating the cpu is running in secondary mode. So, you
> should use T_WARNSW to see.
>
> Please keep the discussion on the mailing list.	
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: Ipipe.txt --]
[-- Type: text/plain, Size: 4168 bytes --]

I-pipe worst-case tracing service on 2.6.31/ipipe-1.16-02
------------------------------------------------------------
CPU: 0, Begin: 413559887374 cycles, Trace Points: 27 (-10/+1), Length: 81 us
Calibrated minimum trace-point overhead: 1.029 us

 +----- Hard IRQs ('|': locked)
 |+---- <unused>
 ||+--- <unused>
 |||+-- Xenomai
 ||||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
 |||||                        +---------- Delay flag ('+': > 1 us, '!': > 10 us)
 |||||                        |        +- NMI noise ('N')
 |||||                        |        |
      Type    User Val.   Time    Delay  Function (Parent)
 |   +begin   0x80000001  -126    2.313  __up_read+0x30 (up_read+0x18)
 |   #end     0x80000001  -124    1.880  __up_read+0x50 (up_read+0x18)
     #func                -122    1.850  ipipe_check_context+0x10 (__up_read+0x5c)
     #func                -120    1.522  __ipipe_restore_root+0x10 (__up_read+0x130)
     #func                -119    1.149  __ipipe_unstall_root+0x10 (__ipipe_restore_root+0x94)
 |   #begin   0x80000000  -118    1.597  __ipipe_unstall_root+0x34 (__ipipe_restore_root+0x94)
 |   +end     0x80000000  -116    1.432  __ipipe_unstall_root+0x98 (__ipipe_restore_root+0x94)
     +func                -115    2.970  ipipe_check_context+0x10 (__up_read+0x138)
     +func                -112  107.507  __ipipe_check_root+0x10 (ret_from_exception+0x4)
 |   +func                  -4    4.656  __ipipe_grab_irq+0x10 (__irq_usr+0x70)
>|   +begin   0xffffffff     0+   2.462  __ipipe_grab_irq+0x5c (__irq_usr+0x70)
:|   +func                   2+   3.626  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   +func                   6+   2.104  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   +func                   8+   2.805  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   +func                  11+   1.776  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   +func                  12+   1.686  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   +func                  14+   1.507  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   +func                  15+   1.611  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   +func                  17+   2.253  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   +func                  19+   2.283  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   +func                  22+   2.194  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  # func                  24+   2.776  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  # func                  27+   5.388  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  # func                  32+   2.313  xnthread_periodic_handler+0x10 (xntimer_tick_aperiodic+0xa8)
:|  # func                  34+   4.029  xnpod_resume_thread+0x10 (xnthread_periodic_handler+0x2c)
:|  # [ 1411] task2ms 99    38+   8.686  xnpod_resume_thread+0x6c (xnthread_periodic_handler+0x2c)
:|  # func                  47+   1.656  xnthread_timeout_handler+0x10 (xntimer_tick_aperiodic+0xa8)
:|  # func                  49+   2.238  xnpod_resume_thread+0x10 (xnthread_timeout_handler+0x34)
:|  # [ 1412] taskPrin 1    51+   2.477  xnpod_resume_thread+0x6c (xnthread_timeout_handler+0x34)
:|  # func                  53+   3.880  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  # event   tick@1969     57+   2.238  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  # func                  60+   4.089  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|  # func                  64+   3.134  __xnpod_schedule+0x14 (xnintr_clock_handler+0xcc)
:|  # [ 1413] cat     -1    67+   2.432  __xnpod_schedule+0x98 (xnintr_clock_handler+0xcc)
:|  # func                  69+   9.014  xnsched_pick_next+0x10 (__xnpod_schedule+0x10c)
:|  # func                  78+   2.895  ipipe_unstall_pipeline_head+0x10 (__xnpod_schedule+0x2f8)
<|  + end     0x80000000    81    2.805  ipipe_unstall_pipeline_head+0x8c (__xnpod_schedule+0x2f8)
 |  + begin   0x80000001    84    0.000  __xnpod_schedule+0x398 (xnintr_clock_handler+0xcc)

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 02:00 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is the new trace.

There is nothing to see on that trace. Please increase the number of
trace points, and trigger a trace when you detect a problem., the number
of trace points should be sufficient to get the timer programmation
which happens before the problem.

Also, did you try T_WANRSW ?

Please disable the configuration of you mail server which asks me to
send a receipt to each every mail you send me.

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

Hi Gilles,

i changed the min value of the '__ipipe_mach_set_dec' but the situation 
is the same.
I see with the scope that the task with less priority is not interrupted.

It's difficult to see with the ipipe trace the problem so i put the 
xenomai trace in the application with 
|xntrace_user_start|/|xntrace_user_stop|.
Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ?

Thanks a lot



Il 06/03/2012 14:04, Gilles Chanteperdrix ha scritto:
> On 03/06/2012 02:00 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> here is the new trace.
> There is nothing to see on that trace. Please increase the number of
> trace points, and trigger a trace when you detect a problem., the number
> of trace points should be sufficient to get the timer programmation
> which happens before the problem.
>
> Also, did you try T_WANRSW ?
>
> Please disable the configuration of you mail server which asks me to
> send a receipt to each every mail you send me.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: Type: text/html, Size: 3379 bytes --]

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 04:14 PM, Roberto Bielli wrote:
>  Hi Gilles,
> 
> i changed the min value of the '__ipipe_mach_set_dec' but the situation
> is the same.
> I see with the scope that the task with less priority is not interrupted.

In the trace you sent, we clearly saw that it was interrupted by a timer
interrupt.

> 
> It's difficult to see with the ipipe trace the problem so i put the
> xenomai trace in the application with
> |xntrace_user_start|/|xntrace_user_stop|.
> Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ?

See the latency test for an example of usage of the I-pipe tracer in
user-space. When using latency -f the trace is available in
/proc/ipipe/trace/frozen.

What about T_WARNSW (it is the third time I ask).

Also, it would be nice if you could try a more recent version of Xenomai
and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38.

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change mode (the value of MSW is 0 )
so, it hasn't changed in secondary mode.

Correct ?



Il 06/03/2012 16:20, Gilles Chanteperdrix ha scritto:
> On 03/06/2012 04:14 PM, Roberto Bielli wrote:
>>   Hi Gilles,
>>
>> i changed the min value of the '__ipipe_mach_set_dec' but the situation
>> is the same.
>> I see with the scope that the task with less priority is not interrupted.
> In the trace you sent, we clearly saw that it was interrupted by a timer
> interrupt.
>
>> It's difficult to see with the ipipe trace the problem so i put the
>> xenomai trace in the application with
>> |xntrace_user_start|/|xntrace_user_stop|.
>> Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ?
> See the latency test for an example of usage of the I-pipe tracer in
> user-space. When using latency -f the trace is available in
> /proc/ipipe/trace/frozen.
>
> What about T_WARNSW (it is the third time I ask).
>
> Also, it would be nice if you could try a more recent version of Xenomai
> and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 04:35 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change mode (the value of MSW is 0 )
> so, it hasn't changed in secondary mode.

Or maybe it started in secondary mode and never switched mode?


-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

we are sure that when a task execute NO INTERRUPTS arrives in interrupt 
service routine in assembler in the kernel,
until it sleeps. It's not a problem of secondary mode.

So we tried the same application on another porting of xenomai with 
marvell ( kernel 2.6.31.8 - xenomai always 2.5.6 ) and there is no problem.

We cannot change the kernel so we must find the problem in this version 
2.6.31 with xenomai 2.5.6 .
The patch of ipipe used is for 2.6.31.8 instead 2.6.31.
Is there a problem for this ? There are the hw locks (spin_lock, etc...) 
in the 2.6.31 that are different in 2.6.31.8 ?

I repeat that seems that all interrupt are disabled, as if there are 
some irq_enable/irq_disable when execute a task,
or the interrupt line is not acked.

The hw implementation of read/write/ack timer are correct.

Can you explain me how work the scheduler of xenomai compared with the 
tasks and the timer ?

Thanks for all.




Il 06/03/2012 17:16, Gilles Chanteperdrix ha scritto:
> On 03/06/2012 04:35 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change mode (the value of MSW is 0 )
>> so, it hasn't changed in secondary mode.
> Or maybe it started in secondary mode and never switched mode?
>
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 01:59 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> we are sure that when a task execute NO INTERRUPTS arrives in interrupt 
> service routine in assembler in the kernel,
> until it sleeps. It's not a problem of secondary mode.

Show me the trace and I will believe you (approximately fourth time I ask).

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

Hi Gilles,

this is the trace and the test.

It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
disable interrupts.


Thanks a lot for your time.



Il 07/03/2012 14:44, Gilles Chanteperdrix ha scritto:
> On 03/07/2012 01:59 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> we are sure that when a task execute NO INTERRUPTS arrives in interrupt
>> service routine in assembler in the kernel,
>> until it sleeps. It's not a problem of secondary mode.
> Show me the trace and I will believe you (approximately fourth time I ask).
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: Ipipe.txt --]
[-- Type: text/plain, Size: 11222 bytes --]

I-pipe frozen back-tracing service on 2.6.31/ipipe-1.16-02
------------------------------------------------------------
CPU: 0, Freeze: 2038911849125 cycles, Trace Points: 100 (+10)
Calibrated minimum trace-point overhead: 1.044 us

 +----- Hard IRQs ('|': locked)
 |+---- <unused>
 ||+--- <unused>
 |||+-- Xenomai
 ||||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
 |||||                        +---------- Delay flag ('+': > 1 us, '!': > 10 us)
 |||||                        |        +- NMI noise ('N')
 |||||                        |        |
      Type    User Val.   Time    Delay  Function (Parent)
:|   #func               -84864+   1.313  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   #func               -84863+   1.164  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   #func               -84862+   1.462  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   #func               -84860+   1.358  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   #func               -84859+   1.432  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   #func               -84858+   1.268  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   #func               -84856+   1.298  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   #func               -84855+   1.358  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   #func               -84854+   1.552  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   #func               -84852+   1.238  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  #*func               -84851+   1.507  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  #*func               -84849+   2.208  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  #*func               -84847+   2.074  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  #*event   tick@-84784-84845+   1.164  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  #*func               -84844+   2.268  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|   #func               -84842+   1.552  __ipipe_walk_pipeline+0x10 (__ipipe_dispatch_wired_nocheck+0xac)
:|   #end     0xffffffff -84840+   1.835  __ipipe_grab_irq+0x74 (__irq_svc+0x68)
:    #func               -84838+   1.522  vma_prio_tree_remove+0x10 (__remove_shared_vm_struct+0x120)
:    #func               -84837+   1.268  __ipipe_unstall_root+0x10 (__remove_shared_vm_struct+0x124)
:|   #begin   0x80000000 -84836+   1.567  __ipipe_unstall_root+0x34 (__remove_shared_vm_struct+0x124)
:|   +end     0x80000000 -84834+   1.313  __ipipe_unstall_root+0x98 (__remove_shared_vm_struct+0x124)
:    +func               -84833+   1.432  ipipe_check_context+0x10 (__remove_shared_vm_struct+0x12c)
:    +func               -84831+   1.597  ipipe_check_context+0x10 (unlink_file_vma+0x60)
:    +func               -84830+   1.537  anon_vma_unlink+0x10 (free_pgtables+0x50)
:    +func               -84828+   1.910  unlink_file_vma+0x10 (free_pgtables+0x58)
:|   +func               -84826+   1.223  __ipipe_grab_irq+0x10 (__irq_svc+0x68)
:|   +begin   0xffffffff -84825+   1.522  __ipipe_grab_irq+0x5c (__irq_svc+0x68)
:|   +func               -84823+   1.641  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   +func               -84822+   1.208  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   +func               -84821+   1.164  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   +func               -84819+   1.373  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   +func               -84818+   1.328  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   +func               -84817+   1.313  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   +func               -84815+   1.149  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   +func               -84814+   1.358  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   +func               -84813+   1.492  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   +func               -84811+   1.298  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  # func               -84810+   1.373  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  # func               -84809+   2.686  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  # func               -84806+   1.955  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  # event   tick@-84783-84804+   1.567  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  # func               -84803+   2.253  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|   +func               -84800+   1.805  __ipipe_walk_pipeline+0x10 (__ipipe_dispatch_wired_nocheck+0xac)
:|   +end     0xffffffff -84798+   1.940  __ipipe_grab_irq+0x74 (__irq_svc+0x68)
:    +func               -84797+   1.432  ipipe_check_context+0x10 (unlink_file_vma+0x3c)
:    +func               -84795+   1.343  __remove_shared_vm_struct+0x10 (unlink_file_vma+0x58)
:|   +begin   0x80000001 -84794+   1.507  __remove_shared_vm_struct+0xa4 (unlink_file_vma+0x58)
:|   #end     0x80000001 -84792+   1.402  __remove_shared_vm_struct+0xc4 (unlink_file_vma+0x58)
:    #func               -84791+   1.343  ipipe_check_context+0x10 (__remove_shared_vm_struct+0xd0)
:    #func               -84790+   1.238  vma_prio_tree_remove+0x10 (__remove_shared_vm_struct+0x120)
:    #func               -84788+   1.417  __ipipe_unstall_root+0x10 (__remove_shared_vm_struct+0x124)
:|   #begin   0x80000000 -84787+   1.507  __ipipe_unstall_root+0x34 (__remove_shared_vm_struct+0x124)
:|   +end     0x80000000 -84785+   1.925  __ipipe_unstall_root+0x98 (__remove_shared_vm_struct+0x124)
:|   +func               -84783+   1.656  __ipipe_grab_irq+0x10 (__irq_svc+0x68)
:|   +begin   0xffffffff -84782+   1.522  __ipipe_grab_irq+0x5c (__irq_svc+0x68)
:|   +func               -84780+   1.522  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   +func               -84779+   1.567  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   +func               -84777+   1.208  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   +func               -84776+   1.373  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   +func               -84775+   1.447  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   +func               -84773+   1.313  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   +func               -84772+   1.164  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   +func               -84771+   1.402  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   +func               -84769+   1.402  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   +func               -84768+   1.298  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  # func               -84767+   1.388  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  # func               -84765+   4.358  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  # func               -84761+   2.179  xnthread_timeout_handler+0x10 (xntimer_tick_aperiodic+0xa8)
:|  # func               -84759+   3.447  xnpod_resume_thread+0x10 (xnthread_timeout_handler+0x34)
:|  # [ 1575] -<?>-    1 -84755+   5.343  xnpod_resume_thread+0x6c (xnthread_timeout_handler+0x34)
:|  # func               -84750+   1.537  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  # event   tick@-83749-84748+   1.462  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  # func               -84747+   2.835  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|  # func               -84744+   3.044  __xnpod_schedule+0x14 (xnintr_clock_handler+0xcc)
:|  # [ 1577] -<?>-   -1 -84741+   2.761  __xnpod_schedule+0x98 (xnintr_clock_handler+0xcc)
:|  # func               -84738+   7.507  xnsched_pick_next+0x10 (__xnpod_schedule+0x10c)
:|  # func               -84731+   2.522  ipipe_unstall_pipeline_head+0x10 (__xnpod_schedule+0x2f8)
:|  + end     0x80000000 -84728+   2.373  ipipe_unstall_pipeline_head+0x8c (__xnpod_schedule+0x2f8)
:|  + begin   0x80000001 -84726+   2.358  __xnpod_schedule+0x398 (xnintr_clock_handler+0xcc)
:|  + end     0x80000001 -84723!  55.000  __xnpod_schedule+0x3b8 (xnintr_clock_handler+0xcc)
:   + func               -84668+   7.716  xnsched_finish_unlocked_switch+0x10 (__xnpod_schedule+0x4e0)
:|  + begin   0x80000000 -84661+   7.970  xnsched_finish_unlocked_switch+0x38 (__xnpod_schedule+0x4e0)
:|  # [ 1575] -<?>-    1 -84653+   7.522  __xnpod_schedule+0x504 (xnpod_suspend_thread+0x278)
:|  # func               -84645+   3.313  __ipipe_restore_pipeline_head+0x10 (xnpod_suspend_thread+0x2c8)
:|  + end     0x80000000 -84642+   6.805  __ipipe_restore_pipeline_head+0xdc (xnpod_suspend_thread+0x2c8)
:|  + begin   0x80000001 -84635+   4.522  __ipipe_dispatch_event+0x158 (__ipipe_syscall_root+0x88)
:|  + end     0x80000001 -84631! 84595.567  __ipipe_dispatch_event+0x22c (__ipipe_syscall_root+0x88)
:   + func                 -35+   3.567  __ipipe_syscall_root+0x10 (vector_swi+0x74)
:   + func                 -31+   1.417  __ipipe_dispatch_event+0x14 (__ipipe_syscall_root+0x88)
:|  + begin   0x80000001   -30+   4.447  __ipipe_dispatch_event+0x40 (__ipipe_syscall_root+0x88)
:|  + end     0x80000001   -26+   1.970  __ipipe_dispatch_event+0xfc (__ipipe_syscall_root+0x88)
:   + func                 -24+   5.507  hisyscall_event+0x14 (__ipipe_dispatch_event+0x120)
:   + func                 -18+   2.268  xnshadow_sys_trace+0x10 (hisyscall_event+0x168)
:   + func                 -16+   1.358  ipipe_trace_frozen_reset+0x10 (xnshadow_sys_trace+0xa0)
:   + func                 -14+   1.925  __ipipe_global_path_lock+0x10 (ipipe_trace_frozen_reset+0x18)
:   + func                 -13+   1.388  __ipipe_spin_lock_irqsave+0x10 (__ipipe_global_path_lock+0x1c)
:|  + begin   0x80000001   -11+   6.805  __ipipe_spin_lock_irqsave+0x34 (__ipipe_global_path_lock+0x1c)
:|  # func                  -4+   2.283  __ipipe_spin_unlock_irqcomplete+0x10 (__ipipe_global_path_unlock+0x6c)
:|  + end     0x80000001    -2+   2.552  __ipipe_spin_unlock_irqcomplete+0x50 (__ipipe_global_path_unlock+0x6c)
<   + freeze  0x00000000     0    2.791  xnshadow_sys_trace+0xac (hisyscall_event+0x168)
 |  + begin   0x80000001     2    1.895  __ipipe_dispatch_event+0x158 (__ipipe_syscall_root+0x88)
 |  + end     0x80000001     4  84585.373  __ipipe_dispatch_event+0x22c (__ipipe_syscall_root+0x88)
    + func               84590    1.746  __ipipe_syscall_root+0x10 (vector_swi+0x74)
    + func               84591    1.268  __ipipe_dispatch_event+0x14 (__ipipe_syscall_root+0x88)
 |  + begin   0x80000001 84593    1.940  __ipipe_dispatch_event+0x40 (__ipipe_syscall_root+0x88)
 |  + end     0x80000001 84595    1.179  __ipipe_dispatch_event+0xfc (__ipipe_syscall_root+0x88)
    + func               84596    3.223  hisyscall_event+0x14 (__ipipe_dispatch_event+0x120)
    + func               84599    4.582  __rt_task_sleep+0x14 (hisyscall_event+0x168)
    + func               84604    2.835  rt_task_sleep+0x14 (__rt_task_sleep+0x68)
    + func               84606    0.000  xnpod_suspend_thread+0x14 (rt_task_sleep+0x80)

[-- Attachment #3: testpreempt.c --]
[-- Type: text/plain, Size: 1670 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>

#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>	/* for MCL_CURRENT and MCL_FUTURE */
#include <rtdm/rtdm.h>
#include <native/task.h>
#include <nucleus/trace.h>

#define GPIO6_ON 		*Gpio2ValAddr |= 1 << 6
#define GPIO6_OFF		*Gpio2ValAddr &= ~(1 << 6);

static RT_TASK rt_task_desc;
static RT_TASK tsk2ms;

	//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;

volatile int cnt2ms = 0;
volatile int cntmain = 0;
volatile int x;

void funct2ms( void * params )
{
	for(;;)
	{
		GPIO6_ON;
		rt_task_sleep( 2000000 );
		++ cnt2ms;
		GPIO6_OFF;
	}
}

int main(int argc, char *argv[])
{
	int count = 0;
	int traceOn = 0;
	int fd, ret;

	// no memory-swapping for this programm
	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
	if( ret )
	{
		perror("ERROR : mlockall has failled");
		exit(1);
	}


	fd = open( "/dev/mem", O_RDWR | O_SYNC );
	printf( "FD=%d", fd );
	fflush( stdout );

	Gpio2ValAddr = (unsigned long  *)mmap(  NULL, 0x1000, PROT_READ | PROT_WRITE,  MAP_SHARED, fd, 0x53FD0000 );

	ret = rt_task_shadow(&rt_task_desc, NULL, 1, 0);
	if( ret != 0 )
	{
		fprintf(stderr, "ERROR : rt_task_shadow: %s\n", strerror(-ret));
		exit( 1 );
	}

	rt_task_create( &tsk2ms, "task2ms",0, 99, 0 );
	rt_task_start( &tsk2ms, funct2ms, NULL );


	for(;;)
	{
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		xntrace_user_freeze(0, 0);
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		rt_task_sleep( 10000000 );
	}

	return 0;
}

[Xenomai-core] Fwd: Re: preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1.1: Type: text/plain, Size: 2604 bytes --]

Hi Gilles,

have you received the trace ?
Have you find a weird behaviour ?

In attach you find the same trace.

Thanks a lot in advance.

-------- Messaggio originale --------
Oggetto: 	Re: [Xenomai-core] preemptive doesn't work
Data: 	Wed, 07 Mar 2012 19:13:59 +0100
Mittente: 	Roberto Bielli <roberto.bielli@domain.hid>
A: 	Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
CC: 	xenomai@xenomai.org



Hi Gilles,

this is the trace and the test.

It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.


Thanks a lot for your time.



Il 07/03/2012 14:44, Gilles Chanteperdrix ha scritto:
>  On 03/07/2012 01:59 PM, Roberto Bielli wrote:
>>  Hi Gilles,
>>
>>  we are sure that when a task execute NO INTERRUPTS arrives in interrupt
>>  service routine in assembler in the kernel,
>>  until it sleeps. It's not a problem of secondary mode.
>  Show me the trace and I will believe you (approximately fourth time I ask).
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+




[-- Attachment #1.2: Type: text/html, Size: 4090 bytes --]

[-- Attachment #2: Ipipe.txt --]
[-- Type: text/plain, Size: 11222 bytes --]

I-pipe frozen back-tracing service on 2.6.31/ipipe-1.16-02
------------------------------------------------------------
CPU: 0, Freeze: 2038911849125 cycles, Trace Points: 100 (+10)
Calibrated minimum trace-point overhead: 1.044 us

 +----- Hard IRQs ('|': locked)
 |+---- <unused>
 ||+--- <unused>
 |||+-- Xenomai
 ||||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
 |||||                        +---------- Delay flag ('+': > 1 us, '!': > 10 us)
 |||||                        |        +- NMI noise ('N')
 |||||                        |        |
      Type    User Val.   Time    Delay  Function (Parent)
:|   #func               -84864+   1.313  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   #func               -84863+   1.164  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   #func               -84862+   1.462  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   #func               -84860+   1.358  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   #func               -84859+   1.432  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   #func               -84858+   1.268  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   #func               -84856+   1.298  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   #func               -84855+   1.358  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   #func               -84854+   1.552  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   #func               -84852+   1.238  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  #*func               -84851+   1.507  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  #*func               -84849+   2.208  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  #*func               -84847+   2.074  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  #*event   tick@-84784-84845+   1.164  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  #*func               -84844+   2.268  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|   #func               -84842+   1.552  __ipipe_walk_pipeline+0x10 (__ipipe_dispatch_wired_nocheck+0xac)
:|   #end     0xffffffff -84840+   1.835  __ipipe_grab_irq+0x74 (__irq_svc+0x68)
:    #func               -84838+   1.522  vma_prio_tree_remove+0x10 (__remove_shared_vm_struct+0x120)
:    #func               -84837+   1.268  __ipipe_unstall_root+0x10 (__remove_shared_vm_struct+0x124)
:|   #begin   0x80000000 -84836+   1.567  __ipipe_unstall_root+0x34 (__remove_shared_vm_struct+0x124)
:|   +end     0x80000000 -84834+   1.313  __ipipe_unstall_root+0x98 (__remove_shared_vm_struct+0x124)
:    +func               -84833+   1.432  ipipe_check_context+0x10 (__remove_shared_vm_struct+0x12c)
:    +func               -84831+   1.597  ipipe_check_context+0x10 (unlink_file_vma+0x60)
:    +func               -84830+   1.537  anon_vma_unlink+0x10 (free_pgtables+0x50)
:    +func               -84828+   1.910  unlink_file_vma+0x10 (free_pgtables+0x58)
:|   +func               -84826+   1.223  __ipipe_grab_irq+0x10 (__irq_svc+0x68)
:|   +begin   0xffffffff -84825+   1.522  __ipipe_grab_irq+0x5c (__irq_svc+0x68)
:|   +func               -84823+   1.641  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   +func               -84822+   1.208  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   +func               -84821+   1.164  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   +func               -84819+   1.373  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   +func               -84818+   1.328  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   +func               -84817+   1.313  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   +func               -84815+   1.149  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   +func               -84814+   1.358  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   +func               -84813+   1.492  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   +func               -84811+   1.298  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  # func               -84810+   1.373  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  # func               -84809+   2.686  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  # func               -84806+   1.955  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  # event   tick@-84783-84804+   1.567  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  # func               -84803+   2.253  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|   +func               -84800+   1.805  __ipipe_walk_pipeline+0x10 (__ipipe_dispatch_wired_nocheck+0xac)
:|   +end     0xffffffff -84798+   1.940  __ipipe_grab_irq+0x74 (__irq_svc+0x68)
:    +func               -84797+   1.432  ipipe_check_context+0x10 (unlink_file_vma+0x3c)
:    +func               -84795+   1.343  __remove_shared_vm_struct+0x10 (unlink_file_vma+0x58)
:|   +begin   0x80000001 -84794+   1.507  __remove_shared_vm_struct+0xa4 (unlink_file_vma+0x58)
:|   #end     0x80000001 -84792+   1.402  __remove_shared_vm_struct+0xc4 (unlink_file_vma+0x58)
:    #func               -84791+   1.343  ipipe_check_context+0x10 (__remove_shared_vm_struct+0xd0)
:    #func               -84790+   1.238  vma_prio_tree_remove+0x10 (__remove_shared_vm_struct+0x120)
:    #func               -84788+   1.417  __ipipe_unstall_root+0x10 (__remove_shared_vm_struct+0x124)
:|   #begin   0x80000000 -84787+   1.507  __ipipe_unstall_root+0x34 (__remove_shared_vm_struct+0x124)
:|   +end     0x80000000 -84785+   1.925  __ipipe_unstall_root+0x98 (__remove_shared_vm_struct+0x124)
:|   +func               -84783+   1.656  __ipipe_grab_irq+0x10 (__irq_svc+0x68)
:|   +begin   0xffffffff -84782+   1.522  __ipipe_grab_irq+0x5c (__irq_svc+0x68)
:|   +func               -84780+   1.522  __ipipe_handle_irq+0x14 (__ipipe_grab_irq+0x68)
:|   +func               -84779+   1.567  __ipipe_ack_timerirq+0x10 (__ipipe_handle_irq+0x9c)
:|   +func               -84777+   1.208  __ipipe_ack_level_irq+0x10 (__ipipe_ack_timerirq+0x24)
:|   +func               -84776+   1.373  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x3c)
:|   +func               -84775+   1.447  mxc_mask_irq+0x10 (__ipipe_ack_level_irq+0x54)
:|   +func               -84773+   1.313  __ipipe_mach_acktimer+0x10 (__ipipe_ack_timerirq+0x28)
:|   +func               -84772+   1.164  __ipipe_end_level_irq+0x10 (__ipipe_ack_timerirq+0x38)
:|   +func               -84771+   1.402  mxc_unmask_irq+0x10 (__ipipe_end_level_irq+0x28)
:|   +func               -84769+   1.402  __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xa8)
:|   +func               -84768+   1.298  __ipipe_dispatch_wired_nocheck+0x10 (__ipipe_dispatch_wired+0x84)
:|  # func               -84767+   1.388  xnintr_clock_handler+0x10 (__ipipe_dispatch_wired_nocheck+0x68)
:|  # func               -84765+   4.358  xntimer_tick_aperiodic+0x14 (xnintr_clock_handler+0x44)
:|  # func               -84761+   2.179  xnthread_timeout_handler+0x10 (xntimer_tick_aperiodic+0xa8)
:|  # func               -84759+   3.447  xnpod_resume_thread+0x10 (xnthread_timeout_handler+0x34)
:|  # [ 1575] -<?>-    1 -84755+   5.343  xnpod_resume_thread+0x6c (xnthread_timeout_handler+0x34)
:|  # func               -84750+   1.537  xntimer_next_local_shot+0x10 (xntimer_tick_aperiodic+0x258)
:|  # event   tick@-83749-84748+   1.462  xntimer_next_local_shot+0xcc (xntimer_tick_aperiodic+0x258)
:|  # func               -84747+   2.835  __ipipe_mach_set_dec+0x10 (xntimer_next_local_shot+0x110)
:|  # func               -84744+   3.044  __xnpod_schedule+0x14 (xnintr_clock_handler+0xcc)
:|  # [ 1577] -<?>-   -1 -84741+   2.761  __xnpod_schedule+0x98 (xnintr_clock_handler+0xcc)
:|  # func               -84738+   7.507  xnsched_pick_next+0x10 (__xnpod_schedule+0x10c)
:|  # func               -84731+   2.522  ipipe_unstall_pipeline_head+0x10 (__xnpod_schedule+0x2f8)
:|  + end     0x80000000 -84728+   2.373  ipipe_unstall_pipeline_head+0x8c (__xnpod_schedule+0x2f8)
:|  + begin   0x80000001 -84726+   2.358  __xnpod_schedule+0x398 (xnintr_clock_handler+0xcc)
:|  + end     0x80000001 -84723!  55.000  __xnpod_schedule+0x3b8 (xnintr_clock_handler+0xcc)
:   + func               -84668+   7.716  xnsched_finish_unlocked_switch+0x10 (__xnpod_schedule+0x4e0)
:|  + begin   0x80000000 -84661+   7.970  xnsched_finish_unlocked_switch+0x38 (__xnpod_schedule+0x4e0)
:|  # [ 1575] -<?>-    1 -84653+   7.522  __xnpod_schedule+0x504 (xnpod_suspend_thread+0x278)
:|  # func               -84645+   3.313  __ipipe_restore_pipeline_head+0x10 (xnpod_suspend_thread+0x2c8)
:|  + end     0x80000000 -84642+   6.805  __ipipe_restore_pipeline_head+0xdc (xnpod_suspend_thread+0x2c8)
:|  + begin   0x80000001 -84635+   4.522  __ipipe_dispatch_event+0x158 (__ipipe_syscall_root+0x88)
:|  + end     0x80000001 -84631! 84595.567  __ipipe_dispatch_event+0x22c (__ipipe_syscall_root+0x88)
:   + func                 -35+   3.567  __ipipe_syscall_root+0x10 (vector_swi+0x74)
:   + func                 -31+   1.417  __ipipe_dispatch_event+0x14 (__ipipe_syscall_root+0x88)
:|  + begin   0x80000001   -30+   4.447  __ipipe_dispatch_event+0x40 (__ipipe_syscall_root+0x88)
:|  + end     0x80000001   -26+   1.970  __ipipe_dispatch_event+0xfc (__ipipe_syscall_root+0x88)
:   + func                 -24+   5.507  hisyscall_event+0x14 (__ipipe_dispatch_event+0x120)
:   + func                 -18+   2.268  xnshadow_sys_trace+0x10 (hisyscall_event+0x168)
:   + func                 -16+   1.358  ipipe_trace_frozen_reset+0x10 (xnshadow_sys_trace+0xa0)
:   + func                 -14+   1.925  __ipipe_global_path_lock+0x10 (ipipe_trace_frozen_reset+0x18)
:   + func                 -13+   1.388  __ipipe_spin_lock_irqsave+0x10 (__ipipe_global_path_lock+0x1c)
:|  + begin   0x80000001   -11+   6.805  __ipipe_spin_lock_irqsave+0x34 (__ipipe_global_path_lock+0x1c)
:|  # func                  -4+   2.283  __ipipe_spin_unlock_irqcomplete+0x10 (__ipipe_global_path_unlock+0x6c)
:|  + end     0x80000001    -2+   2.552  __ipipe_spin_unlock_irqcomplete+0x50 (__ipipe_global_path_unlock+0x6c)
<   + freeze  0x00000000     0    2.791  xnshadow_sys_trace+0xac (hisyscall_event+0x168)
 |  + begin   0x80000001     2    1.895  __ipipe_dispatch_event+0x158 (__ipipe_syscall_root+0x88)
 |  + end     0x80000001     4  84585.373  __ipipe_dispatch_event+0x22c (__ipipe_syscall_root+0x88)
    + func               84590    1.746  __ipipe_syscall_root+0x10 (vector_swi+0x74)
    + func               84591    1.268  __ipipe_dispatch_event+0x14 (__ipipe_syscall_root+0x88)
 |  + begin   0x80000001 84593    1.940  __ipipe_dispatch_event+0x40 (__ipipe_syscall_root+0x88)
 |  + end     0x80000001 84595    1.179  __ipipe_dispatch_event+0xfc (__ipipe_syscall_root+0x88)
    + func               84596    3.223  hisyscall_event+0x14 (__ipipe_dispatch_event+0x120)
    + func               84599    4.582  __rt_task_sleep+0x14 (hisyscall_event+0x168)
    + func               84604    2.835  rt_task_sleep+0x14 (__rt_task_sleep+0x68)
    + func               84606    0.000  xnpod_suspend_thread+0x14 (rt_task_sleep+0x80)

[-- Attachment #3: testpreempt.c --]
[-- Type: text/plain, Size: 1670 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>

#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>	/* for MCL_CURRENT and MCL_FUTURE */
#include <rtdm/rtdm.h>
#include <native/task.h>
#include <nucleus/trace.h>

#define GPIO6_ON 		*Gpio2ValAddr |= 1 << 6
#define GPIO6_OFF		*Gpio2ValAddr &= ~(1 << 6);

static RT_TASK rt_task_desc;
static RT_TASK tsk2ms;

	//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;

volatile int cnt2ms = 0;
volatile int cntmain = 0;
volatile int x;

void funct2ms( void * params )
{
	for(;;)
	{
		GPIO6_ON;
		rt_task_sleep( 2000000 );
		++ cnt2ms;
		GPIO6_OFF;
	}
}

int main(int argc, char *argv[])
{
	int count = 0;
	int traceOn = 0;
	int fd, ret;

	// no memory-swapping for this programm
	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
	if( ret )
	{
		perror("ERROR : mlockall has failled");
		exit(1);
	}


	fd = open( "/dev/mem", O_RDWR | O_SYNC );
	printf( "FD=%d", fd );
	fflush( stdout );

	Gpio2ValAddr = (unsigned long  *)mmap(  NULL, 0x1000, PROT_READ | PROT_WRITE,  MAP_SHARED, fd, 0x53FD0000 );

	ret = rt_task_shadow(&rt_task_desc, NULL, 1, 0);
	if( ret != 0 )
	{
		fprintf(stderr, "ERROR : rt_task_shadow: %s\n", strerror(-ret));
		exit( 1 );
	}

	rt_task_create( &tsk2ms, "task2ms",0, 99, 0 );
	rt_task_start( &tsk2ms, funct2ms, NULL );


	for(;;)
	{
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		xntrace_user_freeze(0, 0);
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		rt_task_sleep( 10000000 );
	}

	return 0;
}

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 07:13 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> this is the trace and the test.
> 
> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
> disable interrupts.

Sorry, I somehow missed this post.

I am afraid you are mis-reading the trace. The time spent in user-space
gets accounted to __ipipe_dispatch_event, because this is the last
instrumented function called before the return to user-space. Interrupts
are disabled at this point, this is perfectly normal, but they are
probably re-enabled when returning to user-space.

What is more problematic, however, is that the timer interrupt did not
tick at -83749 like it is supposed to. If it had ticked and the
interrupt had been disabled in user-space, you would have taken the
interrupt at -35, when __ipipe_syscall_root gets called with interrupts on.

So, now, you have to understand why the timer interrupt did not tick. I
suggest, when the problem happens, you look at:
* the interrupt controller register, to see if the timer interrupt is
still masked, if it is masked, then try first commenting out the snippet
in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the
irq_mask_ack callback
* the timer registers, to see if the timer was programmed correctly, and
is still ticking when the issue happens.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/13/2012 12:44 PM, Gilles Chanteperdrix wrote:
> On 03/07/2012 07:13 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> this is the trace and the test.
>>
>> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
>> disable interrupts.
> 
> Sorry, I somehow missed this post.
> 
> I am afraid you are mis-reading the trace. The time spent in user-space
> gets accounted to __ipipe_dispatch_event, because this is the last
> instrumented function called before the return to user-space. Interrupts
> are disabled at this point, this is perfectly normal, but they are
> probably re-enabled when returning to user-space.
> 
> What is more problematic, however, is that the timer interrupt did not
> tick at -83749 like it is supposed to. If it had ticked and the
> interrupt had been disabled in user-space, you would have taken the
> interrupt at -35, when __ipipe_syscall_root gets called with interrupts on.
> 
> So, now, you have to understand why the timer interrupt did not tick. I
> suggest, when the problem happens, you look at:
> * the interrupt controller register, to see if the timer interrupt is
> still masked, if it is masked, then try first commenting out the snippet
> in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the
> irq_mask_ack callback
> * the timer registers, to see if the timer was programmed correctly, and
> is still ticking when the issue happens.
> 

You may also want, in __ipipe_mach_set_dec, to re-read the comparator
value after writing it. Sometimes, such things are needed for the write
to register to be really taken into account.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 07:13 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> this is the trace and the test.
> 
> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
> disable interrupts.
> 
> 
> Thanks a lot for your time.

Hi Roberto,

any news about this issue?

Regards.

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i have always this big problem but the timer and the avic are programmed 
correctly.
There is something else but i don't know what.
In this moment i'm doing another work but soon i want to debug that error.

Thanks for all

Il 04/04/2012 11:21, Gilles Chanteperdrix ha scritto:
> On 03/07/2012 07:13 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> this is the trace and the test.
>>
>> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
>> disable interrupts.
>>
>>
>> Thanks a lot for your time.
> Hi Roberto,
>
> any news about this issue?
>
> Regards.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/04/2012 11:29 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i have always this big problem but the timer and the avic are programmed 
> correctly.
> There is something else but i don't know what.
> In this moment i'm doing another work but soon i want to debug that error.

It is undoubtly a timer ack/program issue. There is no other problem,
the trace is quite clear: the timer is programmed, should tick, but
does not.

I had a look at the imx code again for other reasons, what may be also
missing in __ipipe_mach_acktimer function is a read of the timer status
register. As in:

void __ipipe_mach_acktimer(void)
{
        uint32_t tstat;

        if (timer_is_v2())
                tstat = __raw_readl(timer_base + V2_TSTAT);
        else
                tstat = __raw_readl(timer_base + MX1_2_TSTAT);

        gpt_irq_acknowledge();
}

And put that piece of code in mxc_timer_interrupt in the #ifndef
CONFIG_IPIPE section.

You may also want to issue a register read after programming the
compare register. As in:


void __ipipe_mach_set_dec(unsigned long delay)
{
         if (delay > mxc_min_delay) {
                 unsigned long tcmp;
 
                 if (!timer_is_v2()) {
                         tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
                         __raw_writel(tcmp, timer_base + MX1_2_TCMP);
                         __raw_readl(timer_base + MX1_2_TCN);
                 } else {
                         tcmp = __raw_readl(timer_base + V2_TCN) + delay;
                         __raw_writel(tcmp, timer_base + V2_TCMP);
                         __raw_readl(timer_base + V2_TCN);
                 }
         } else
                 ipipe_trigger_irq(__ipipe_mach_timerint);
}

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

excuse me, but i don't understand why i have to read the register after 
a write.
In the imx processor manual i didn't find that behaviour.

Where did you find that information ?

Il 04/04/2012 11:45, Gilles Chanteperdrix ha scritto:
> On 04/04/2012 11:29 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i have always this big problem but the timer and the avic are programmed
>> correctly.
>> There is something else but i don't know what.
>> In this moment i'm doing another work but soon i want to debug that error.
> It is undoubtly a timer ack/program issue. There is no other problem,
> the trace is quite clear: the timer is programmed, should tick, but
> does not.
>
> I had a look at the imx code again for other reasons, what may be also
> missing in __ipipe_mach_acktimer function is a read of the timer status
> register. As in:
>
> void __ipipe_mach_acktimer(void)
> {
>          uint32_t tstat;
>
>          if (timer_is_v2())
>                  tstat = __raw_readl(timer_base + V2_TSTAT);
>          else
>                  tstat = __raw_readl(timer_base + MX1_2_TSTAT);
>
>          gpt_irq_acknowledge();
> }
>
> And put that piece of code in mxc_timer_interrupt in the #ifndef
> CONFIG_IPIPE section.
>
> You may also want to issue a register read after programming the
> compare register. As in:
>
>
> void __ipipe_mach_set_dec(unsigned long delay)
> {
>           if (delay>  mxc_min_delay) {
>                   unsigned long tcmp;
>
>                   if (!timer_is_v2()) {
>                           tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
>                           __raw_writel(tcmp, timer_base + MX1_2_TCMP);
>                           __raw_readl(timer_base + MX1_2_TCN);
>                   } else {
>                           tcmp = __raw_readl(timer_base + V2_TCN) + delay;
>                           __raw_writel(tcmp, timer_base + V2_TCMP);
>                           __raw_readl(timer_base + V2_TCN);
>                   }
>           } else
>                   ipipe_trigger_irq(__ipipe_mach_timerint);
> }
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/06/2012 05:35 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> excuse me, but i don't understand why i have to read the register after 
> a write.
> In the imx processor manual i didn't find that behaviour.

Read again what I wrote: I do not say you "have to", I say "you may want
to", it is just a trick you may want to try, which I have already seen
solving this kind of issues. Besides, that is what the linux clockevent
driver does.

I would first try reading the status register in the
__ipipe_mach_acktimer , and if it does not fix the issue, try the
re-read trick.

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i made all your modifies and re-read all corect register but the problem 
is the same.

Best Regards

Il 06/04/2012 17:40, Gilles Chanteperdrix ha scritto:
> On 04/06/2012 05:35 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> excuse me, but i don't understand why i have to read the register after
>> a write.
>> In the imx processor manual i didn't find that behaviour.
> Read again what I wrote: I do not say you "have to", I say "you may want
> to", it is just a trick you may want to try, which I have already seen
> solving this kind of issues. Besides, that is what the linux clockevent
> driver does.
>
> I would first try reading the status register in the
> __ipipe_mach_acktimer , and if it does not fix the issue, try the
> re-read trick.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/06/2012 06:59 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i made all your modifies and re-read all corect register but the problem 
> is the same.

Ok. What I would do at this point is check whether linux has the same
issue. You can also check the processor errata to see if there is no
issue with the timer.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i learned the ipipe trace that i send you but i don't unserstand why i 
have three timer reprogramming in few useconds.

Can you explain me the behaviour ?



Il 08/04/2012 00:17, Gilles Chanteperdrix ha scritto:
> On 04/06/2012 06:59 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i made all your modifies and re-read all corect register but the problem
>> is the same.
> Ok. What I would do at this point is check whether linux has the same
> issue. You can also check the processor errata to see if there is no
> issue with the timer.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:18 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i learned the ipipe trace that i send you but i don't unserstand why i 
> have three timer reprogramming in few useconds.
> 
> Can you explain me the behaviour ?

Can you resend the trace and give us the time where this happens?
Anyway, the timer function must work even if the timer has already been
programmed, it is normal to reprogram the timer while it has been
programmed for instance when adding or removing a timer.


-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

I don't find the end of last __ipipe_grab_irq in the trace that i send you.
Is it correct ?

Il 08/04/2012 00:17, Gilles Chanteperdrix ha scritto:
> On 04/06/2012 06:59 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i made all your modifies and re-read all corect register but the problem
>> is the same.
> Ok. What I would do at this point is check whether linux has the same
> issue. You can also check the processor errata to see if there is no
> issue with the timer.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:43 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> I don't find the end of last __ipipe_grab_irq in the trace that i send you.
> Is it correct ?

Yes, because the timer interrupt reschedules and wakes up the periodic
task. I had a look at the timer programming events, it is true that the
timer ticks more often than it should. Generally, this is an indication
that the timer frequency is not what xenomai believe it is. xenomai idea
of the timer frequency is given by __ipipe_mach_ticks_per_jiffy. Anyway,
this should not cause the timer not to tick, only to tick it more often.

What you should do now is try and reproduce the same conditions under an
unpatched linux to see if you get the same phenomenon.

Did you have a look a the processor errata ?

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i look at the processor errata but for the imx25 there are no errata 
elements on timer.
I see that tsc uses the same timer.

Does xenomai use the tsc for the next timer period ?



Il 10/04/2012 10:45, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 10:43 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> I don't find the end of last __ipipe_grab_irq in the trace that i send you.
>> Is it correct ?
> Yes, because the timer interrupt reschedules and wakes up the periodic
> task. I had a look at the timer programming events, it is true that the
> timer ticks more often than it should. Generally, this is an indication
> that the timer frequency is not what xenomai believe it is. xenomai idea
> of the timer frequency is given by __ipipe_mach_ticks_per_jiffy. Anyway,
> this should not cause the timer not to tick, only to tick it more often.
>
> What you should do now is try and reproduce the same conditions under an
> unpatched linux to see if you get the same phenomenon.
>
> Did you have a look a the processor errata ?
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:58 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i look at the processor errata but for the imx25 there are no errata 
> elements on timer.
> I see that tsc uses the same timer.
> 
> Does xenomai use the tsc for the next timer period ?

If you look at the trace, you will see that with the "timer@" event that
the timer is supposedly programmed for the right time. For instance at
-84748, the timer is programmed to tick at -83749, which is around
1000us later and is what we would expect. So, the tsc is out of the
issue. The issue is the timer.

For the third time I tell you, you should now try and reproduce the same
issue with an unpatched linux.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:58 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i look at the processor errata but for the imx25 there are no errata 
> elements on timer.

It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
support imx25.

The I-pipe support has not been written for imx25, so, it is entirely
possible that you have to adapt it. See:
http://www.xenomai.org/index.php/I-pipe:ArmPorting

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote:
> On 04/10/2012 10:58 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i look at the processor errata but for the imx25 there are no errata 
>> elements on timer.
> 
> It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
> support imx25.
> 
> The I-pipe support has not been written for imx25, so, it is entirely
> possible that you have to adapt it. See:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting
> 
Latest kernels support imx25, and imx25 works like an mx3, not an mx2,
can you show me arch/arm/plat-mxc/time.c for your (undoubtedly) patched
kernel?

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Hi Gilles,

here is my time.c



Il 10/04/2012 11:11, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote:
>> On 04/10/2012 10:58 AM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i look at the processor errata but for the imx25 there are no errata
>>> elements on timer.
>> It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
>> support imx25.
>>
>> The I-pipe support has not been written for imx25, so, it is entirely
>> possible that you have to adapt it. See:
>> http://www.xenomai.org/index.php/I-pipe:ArmPorting
>>
> Latest kernels support imx25, and imx25 works like an mx3, not an mx2,
> can you show me arch/arm/plat-mxc/time.c for your (undoubtedly) patched
> kernel?
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: time.c --]
[-- Type: text/plain, Size: 13546 bytes --]

/*
 *  linux/arch/arm/plat-mxc/time.c
 *
 *  Copyright (C) 2000-2001 Deep Blue Solutions
 *  Copyright (C) 2002 Shane Nay (shane@minirl.com)
 *  Copyright (C) 2006-2007 Pavel Pisa (ppisa@pikron.com)
 *  Copyright (C) 2008 Juergen Beisert (kernel@pengutronix.de)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 * MA 02110-1301, USA.
 */

#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/clockchips.h>
#include <linux/clk.h>

#include <mach/hardware.h>
#include <asm/mach/time.h>
#include <mach/common.h>

/* defines common for all i.MX */
#define MXC_TCTL		0x00
#define MXC_TCTL_TEN		(1 << 0)
#define MXC_TPRER		0x04

/* MX1, MX21, MX27 */
#define MX1_2_TCTL_CLK_PCLK1	(1 << 1)
#define MX1_2_TCTL_IRQEN	(1 << 4)
#define MX1_2_TCTL_FRR		(1 << 8)
#define MX1_2_TCMP		0x08
#define MX1_2_TCN		0x10
#define MX1_2_TSTAT		0x14

/* MX21, MX27 */
#define MX2_TSTAT_CAPT		(1 << 1)
#define MX2_TSTAT_COMP		(1 << 0)

/* MX31, MX35, MX25 */
#define MX3_TCTL_WAITEN		(1 << 3)
#define MX3_TCTL_CLK_IPG	(1 << 6)
#define MX3_TCTL_CLK_PER	(2 << 6)
#define MX3_TCTL_FRR		(1 << 9)
#define MX3_IR			0x0c
#define MX3_TSTAT		0x08
#define MX3_TSTAT_OF1		(1 << 0)
#define MX3_TCN			0x24
#define MX3_TCMP		0x10

#ifdef CONFIG_IPIPE
#ifdef CONFIG_NO_IDLE_HZ
#error "dynamic tick timer not yet supported with IPIPE"
#endif /* CONFIG_NO_IDLE_HZ */
int __ipipe_mach_timerint;
EXPORT_SYMBOL(__ipipe_mach_timerint);

int __ipipe_mach_timerstolen = 0;
EXPORT_SYMBOL(__ipipe_mach_timerstolen);

unsigned int __ipipe_mach_ticks_per_jiffy = LATCH;
EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);

static int mxc_timer_initialized;
static unsigned mxc_min_delay;

union tsc_reg {
#ifdef __BIG_ENDIAN
	struct {
		unsigned long high;
		unsigned long low;
	};
#else /* __LITTLE_ENDIAN */
	struct {
		unsigned long low;
		unsigned long high;
	};
#endif /* __LITTLE_ENDIAN */
	unsigned long long full;
};

#ifdef CONFIG_SMP
static union tsc_reg tsc[NR_CPUS];

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_NONE;
}

#else /* !CONFIG_SMP */
static union tsc_reg *tsc;

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_FREERUNNING;
	if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
		info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
	}
	info->u.fr.mask = 0xffffffff;
	info->u.fr.tsc = &tsc->full;
}
#endif /* !CONFIG_SMP */

static void ipipe_mach_update_tsc(void);
#endif /* CONFIG_IPIPE */

#define timer_is_v2()	(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())

static struct clock_event_device clockevent_mxc;
static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;

static void __iomem *timer_base;

static inline void gpt_irq_disable(void)
{
	unsigned int tmp;

	if (timer_is_v2())
		__raw_writel(0, timer_base + MX3_IR);
	else {
		tmp = __raw_readl(timer_base + MXC_TCTL);
		__raw_writel(tmp & ~MX1_2_TCTL_IRQEN, timer_base + MXC_TCTL);
	}
}

static inline void gpt_irq_enable(void)
{
	if (timer_is_v2())
		__raw_writel(1<<0, timer_base + MX3_IR);
	else {
		__raw_writel(__raw_readl(timer_base + MXC_TCTL) | MX1_2_TCTL_IRQEN,
			timer_base + MXC_TCTL);
	}
}

static void gpt_irq_acknowledge(void)
{
	if (cpu_is_mx1())
		__raw_writel(0, timer_base + MX1_2_TSTAT);
	if (cpu_is_mx2())
		__raw_writel(MX2_TSTAT_CAPT | MX2_TSTAT_COMP, timer_base + MX1_2_TSTAT);
	if (timer_is_v2())
		__raw_writel(MX3_TSTAT_OF1, timer_base + MX3_TSTAT);
}

static cycle_t timer_v1_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX1_2_TCN);
}

static cycle_t timer_v2_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX3_TCN);
}

static struct clocksource clocksource_mxc = {
	.name		= "mxc_timer1",
	.rating		= 200,
	.read		= timer_v1_get_cycles,
	.mask		= CLOCKSOURCE_MASK(32),
	.shift		= 20,
	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
};

static int __init mxc_clocksource_init(struct clk *timer_clk)
{
	unsigned int c = clk_get_rate(timer_clk);

	if (timer_is_v2())
		clocksource_mxc.read = timer_v2_get_cycles;

#ifdef CONFIG_IPIPE
	__ipipe_mach_ticks_per_jiffy = (c + HZ/2) / HZ;
#endif /* CONFIG_IPIPE */
	clocksource_mxc.mult = clocksource_hz2mult(c,
					clocksource_mxc.shift);
	clocksource_register(&clocksource_mxc);

	return 0;
}

/* clock event */

static int timer_v1_set_next_event(unsigned long evt,
			      struct clock_event_device *unused)
{
	unsigned long tcmp;

	tcmp = __raw_readl(timer_base + MX1_2_TCN) + evt;

	__raw_writel(tcmp, timer_base + MX1_2_TCMP);

	return (int)(tcmp - __raw_readl(timer_base + MX1_2_TCN)) < 0 ?
				-ETIME : 0;
}

static int timer_v2_set_next_event(unsigned long evt,
			      struct clock_event_device *unused)
{
	unsigned long tcmp;

	tcmp = __raw_readl(timer_base + MX3_TCN) + evt;

	__raw_writel(tcmp, timer_base + MX3_TCMP);

	return (int)(tcmp - __raw_readl(timer_base + MX3_TCN)) < 0 ? -ETIME : 0;
}

#ifdef DEBUG
static inline const char *clock_event_mode_label(enum clock_event_mode mode)
{
	switch (mode) {
	case CLOCK_EVT_MODE_PERIODIC:
		return "CLOCK_EVT_MODE_PERIODIC";
	case CLOCK_EVT_MODE_ONESHOT:
		return "CLOCK_EVT_MODE_ONESHOT";
	case CLOCK_EVT_MODE_SHUTDOWN:
		return "CLOCK_EVT_MODE_SHUTDOWN";
	case CLOCK_EVT_MODE_UNUSED:
		return "CLOCK_EVT_MODE_UNUSED";
	case CLOCK_EVT_MODE_RESUME:
		return "CLOCK_EVT_MODE_RESUME";
	}
	return "UNKNOWN";
};
#endif /* DEBUG */

static void mxc_set_mode(enum clock_event_mode mode,
				struct clock_event_device *evt)
{
	unsigned long flags;

	/*
	 * The timer interrupt generation is disabled at least
	 * for enough time to call mxc_set_next_event()
	 */
	local_irq_save(flags);

	/* Disable interrupt in GPT module */
	gpt_irq_disable();

	if (mode != clockevent_mode) {
		/* Set event time into far-far future */
		if (timer_is_v2())
			__raw_writel(__raw_readl(timer_base + MX3_TCN) - 3,
					timer_base + MX3_TCMP);
		else
			__raw_writel(__raw_readl(timer_base + MX1_2_TCN) - 3,
					timer_base + MX1_2_TCMP);

		/* Clear pending interrupt */
		gpt_irq_acknowledge();
	}

#ifdef DEBUG
	printk(KERN_INFO "mxc_set_mode: changing mode from %s[%d] to %s[%d]\n",
		clock_event_mode_label(clockevent_mode), clockevent_mode,
		clock_event_mode_label(mode), mode);
#endif /* DEBUG */

	/* Remember timer mode */
	clockevent_mode = mode;
	local_irq_restore(flags);
	switch (mode)
	{
	case CLOCK_EVT_MODE_PERIODIC:
		printk(KERN_ERR "mxc_set_mode: Periodic mode is not supported for i.MX\n");
		break;
	case CLOCK_EVT_MODE_ONESHOT:
	/*
	 * Do not put overhead of interrupt enable/disable into
	 * mxc_set_next_event(), the core has about 4 minutes
	 * to call mxc_set_next_event() or shutdown clock after
	 * mode switching
	 */
		local_irq_save(flags);
		gpt_irq_enable();
		local_irq_restore(flags);
		break;
	case CLOCK_EVT_MODE_SHUTDOWN:
	case CLOCK_EVT_MODE_UNUSED:
	case CLOCK_EVT_MODE_RESUME:
		/* Left event sources disabled, no more interrupts appear */
		break;
	}
}

/*
 * IRQ handler for the timer
 */
static irqreturn_t mxc_timer_interrupt(int irq, void *dev_id)
{
	struct clock_event_device *evt = &clockevent_mxc;
	uint32_t tstat;
	unsigned long reg;

	if (timer_is_v2())
		tstat = __raw_readl(timer_base + MX3_TSTAT);
	else
		tstat = __raw_readl(timer_base + MX1_2_TSTAT);

#ifndef CONFIG_IPIPE
	gpt_irq_acknowledge();
#else /* !CONFIG_IPIPE */

	ipipe_mach_update_tsc();

#endif /* !CONFIG_IPIPE */

	evt->event_handler(evt);

	return IRQ_HANDLED;
}

static struct irqaction mxc_timer_irq = {
	.name		= "i.MX Timer Tick",
	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
	.handler	= mxc_timer_interrupt,
};

static struct clock_event_device clockevent_mxc = {
	.name		= "mxc_timer1",
	.features	= CLOCK_EVT_FEAT_ONESHOT,
	.shift		= 32,
	.set_mode	= mxc_set_mode,
	.set_next_event	= timer_v1_set_next_event,
	.rating		= 200,
};

static int __init mxc_clockevent_init(struct clk *timer_clk)
{
	unsigned long c = clk_get_rate(timer_clk);

	printk(KERN_DEBUG "%s: timer clk rate is %lu.%03luMHz\n", __FUNCTION__,
		c / 1000000, c / 1000 % 1000);

	if (timer_is_v2())
		clockevent_mxc.set_next_event = timer_v2_set_next_event;

	clockevent_mxc.mult = div_sc(c, NSEC_PER_SEC,
					clockevent_mxc.shift);
	clockevent_mxc.max_delta_ns =
			clockevent_delta2ns(0xfffffffe, &clockevent_mxc);
	clockevent_mxc.min_delta_ns =
			clockevent_delta2ns(0xff, &clockevent_mxc);

	clockevent_mxc.cpumask = cpumask_of(0);

	clockevents_register_device(&clockevent_mxc);

	return 0;
}

void __init mxc_timer_init(struct clk *timer_clk, void __iomem *base, int irq)
{
	uint32_t tctl_val;

	clk_enable(timer_clk);

	timer_base = base;

	/*
	 * Initialise to a known state (all timers off, and timing reset)
	 */

	__raw_writel(0, timer_base + MXC_TCTL);
	__raw_writel(0, timer_base + MXC_TPRER); /* see datasheet note */

	if (timer_is_v2())
		tctl_val = MX3_TCTL_CLK_IPG | MX3_TCTL_FRR | MX3_TCTL_WAITEN | MXC_TCTL_TEN;
	else
		tctl_val = MX1_2_TCTL_FRR | MX1_2_TCTL_CLK_PCLK1 | MXC_TCTL_TEN;

	__raw_writel(tctl_val, timer_base + MXC_TCTL);

	/* init and register the timer to the framework */
	mxc_clocksource_init(timer_clk);
	mxc_clockevent_init(timer_clk);

	/* Make irqs happen */
	setup_irq(irq, &mxc_timer_irq);

#ifdef CONFIG_IPIPE
	__ipipe_mach_timerint = irq;
#ifndef CONFIG_SMP
	tsc = (union tsc_reg *) __ipipe_tsc_area;
	barrier();
#endif /* CONFIG_SMP */

//	mxc_min_delay = ((ipipe_cpu_freq() + 500000) / 1000000) ?: 1;
	mxc_min_delay = (ipipe_cpu_freq() + 500000) / 1000000;
	if (mxc_min_delay == 0)
	{
		mxc_min_delay = 1;
	}

	printk(  KERN_INFO "mxc_min_delay = %d\n", mxc_min_delay );
	mxc_timer_initialized = 1;
#endif /* CONFIG_IPIPE */
}

#ifdef CONFIG_IPIPE
int __ipipe_check_tickdev(const char *devname)
{
	return !strcmp(devname, clockevent_mxc.name);
}

void __ipipe_mach_acktimer(void)
{
	uint32_t tstat;

    if (timer_is_v2())
		tstat = __raw_readl(timer_base + MX3_TSTAT);
	else
		tstat = __raw_readl(timer_base + MX1_2_TSTAT);
		
				 
	gpt_irq_acknowledge();
}

static void ipipe_mach_update_tsc(void)
{
	union tsc_reg *local_tsc;
	unsigned long stamp, flags;

	//local_irq_save_hw(flags);
	local_tsc = &tsc[ipipe_processor_id()];
	if (!cpu_is_mx3() && !cpu_is_mx25() )
		stamp = __raw_readl(timer_base + MX1_2_TCN);
	else
		stamp = __raw_readl(timer_base + MX3_TCN);
	if (unlikely(stamp < local_tsc->low))
		/* 32 bit counter wrapped, increment high word. */
		local_tsc->high++;
	local_tsc->low = stamp;
	//local_irq_restore_hw(flags);
}

notrace unsigned long long __ipipe_mach_get_tsc(void)
{
	if (likely(mxc_timer_initialized)) {
		union tsc_reg *local_tsc, result;
		unsigned long stamp;

		local_tsc = &tsc[ipipe_processor_id()];

		if (!cpu_is_mx3() && !cpu_is_mx25() )  {
			__asm__ ("ldmia %1, %M0\n"
				 : "=r"(result.full), "+&r"(local_tsc)
				 : "m"(*local_tsc));
			barrier();
			stamp = __raw_readl(timer_base + MX1_2_TCN);
		} else {
			__asm__ ("ldmia %1, %M0\n"
				 : "=r"(result.full), "+&r"(local_tsc)
				 : "m"(*local_tsc));
			barrier();
			stamp = __raw_readl(timer_base + MX3_TCN);
		}
		if (unlikely(stamp < result.low))
			/* 32 bit counter wrapped, increment high word. */
			result.high++;
		result.low = stamp;

		return result.full;
	}

        return 0;
}
EXPORT_SYMBOL(__ipipe_mach_get_tsc);

/*
 * Reprogram the timer
 */

void __ipipe_mach_set_dec(unsigned long delay)
{
	/*if (delay > mxc_min_delay) {
		unsigned long flags;

		local_irq_save_hw(flags);
		if (!cpu_is_mx3() && !cpu_is_mx25() )
			timer_v1_set_next_event(delay, NULL);
		else
			timer_v2_set_next_event(delay, NULL);
		local_irq_restore_hw(flags);
	} else
		ipipe_trigger_irq(__ipipe_mach_timerint);*/
		
		
	if (delay > mxc_min_delay) {
		 unsigned long tcmp;

		 if (!timer_is_v2()) {
				 tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
				 __raw_writel(tcmp, timer_base + MX1_2_TCMP);
				 __raw_readl(timer_base + MX1_2_TCN);
		 } else {
				 tcmp = __raw_readl(timer_base + MX3_TCN) + delay;
				 __raw_writel(tcmp, timer_base + MX3_TCMP);
				 __raw_readl(timer_base + MX3_TCN);
		 }
    } else
                 ipipe_trigger_irq(__ipipe_mach_timerint);
}
EXPORT_SYMBOL(__ipipe_mach_set_dec);

void __ipipe_mach_release_timer(void)
{
	mxc_set_mode(clockevent_mxc.mode, &clockevent_mxc);
	if (clockevent_mxc.mode == CLOCK_EVT_MODE_ONESHOT)
		clockevent_mxc.set_next_event(LATCH, &clockevent_mxc);
}
EXPORT_SYMBOL(__ipipe_mach_release_timer);

unsigned long __ipipe_mach_get_dec(void)
{
	if (!cpu_is_mx3() && !cpu_is_mx25() )
		return __raw_readl(timer_base + MX1_2_TCMP)
			- __raw_readl(timer_base + MX1_2_TCN);
	else
		return __raw_readl(timer_base + MX3_TCMP)
			- __raw_readl(timer_base + MX3_TCN);
}
#endif /* CONFIG_IPIPE */

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:21 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is my time.c

Looks fine, though I do not understand why you do not use timer_is_v2
instead of cpu_is_mx3 || cpu_is_mx25. I think the problem is elsewhere,
and I suggest you check whether linux without xenomai has or has not the
same issue.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On 04/10/2012 11:21 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is my time.c

Though you have not made all the changes I suggested. Here is the time.c
I would use.

-- 
                                                                Gilles.

[-- Attachment #2: time.c --]
[-- Type: text/x-csrc, Size: 12926 bytes --]

/*
 *  linux/arch/arm/plat-mxc/time.c
 *
 *  Copyright (C) 2000-2001 Deep Blue Solutions
 *  Copyright (C) 2002 Shane Nay (shane@domain.hid)
 *  Copyright (C) 2006-2007 Pavel Pisa (ppisa@domain.hid)
 *  Copyright (C) 2008 Juergen Beisert (kernel@domain.hid)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 * MA 02110-1301, USA.
 */

#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/clockchips.h>
#include <linux/clk.h>

#include <mach/hardware.h>
#include <asm/mach/time.h>
#include <mach/common.h>

/* defines common for all i.MX */
#define MXC_TCTL		0x00
#define MXC_TCTL_TEN		(1 << 0)
#define MXC_TPRER		0x04

/* MX1, MX21, MX27 */
#define MX1_2_TCTL_CLK_PCLK1	(1 << 1)
#define MX1_2_TCTL_IRQEN	(1 << 4)
#define MX1_2_TCTL_FRR		(1 << 8)
#define MX1_2_TCMP		0x08
#define MX1_2_TCN		0x10
#define MX1_2_TSTAT		0x14

/* MX21, MX27 */
#define MX2_TSTAT_CAPT		(1 << 1)
#define MX2_TSTAT_COMP		(1 << 0)

/* MX31, MX35, MX25 */
#define MX3_TCTL_WAITEN		(1 << 3)
#define MX3_TCTL_CLK_IPG	(1 << 6)
#define MX3_TCTL_CLK_PER	(2 << 6)
#define MX3_TCTL_FRR		(1 << 9)
#define MX3_IR			0x0c
#define MX3_TSTAT		0x08
#define MX3_TSTAT_OF1		(1 << 0)
#define MX3_TCN			0x24
#define MX3_TCMP		0x10

#ifdef CONFIG_IPIPE
#ifdef CONFIG_NO_IDLE_HZ
#error "dynamic tick timer not yet supported with IPIPE"
#endif /* CONFIG_NO_IDLE_HZ */
int __ipipe_mach_timerint;
EXPORT_SYMBOL(__ipipe_mach_timerint);

int __ipipe_mach_timerstolen = 0;
EXPORT_SYMBOL(__ipipe_mach_timerstolen);

unsigned int __ipipe_mach_ticks_per_jiffy = LATCH;
EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);

static int mxc_timer_initialized;
static unsigned mxc_min_delay;

union tsc_reg {
#ifdef __BIG_ENDIAN
	struct {
		unsigned long high;
		unsigned long low;
	};
#else /* __LITTLE_ENDIAN */
	struct {
		unsigned long low;
		unsigned long high;
	};
#endif /* __LITTLE_ENDIAN */
	unsigned long long full;
};

#ifdef CONFIG_SMP
static union tsc_reg tsc[NR_CPUS];

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_NONE;
}

#else /* !CONFIG_SMP */
static union tsc_reg *tsc;

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_FREERUNNING;
	if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
		info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
	}
	info->u.fr.mask = 0xffffffff;
	info->u.fr.tsc = &tsc->full;
}
#endif /* !CONFIG_SMP */

static void ipipe_mach_update_tsc(void);
#endif /* CONFIG_IPIPE */

#define timer_is_v2()	(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())

static struct clock_event_device clockevent_mxc;
static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;

static void __iomem *timer_base;

static inline void gpt_irq_disable(void)
{
	unsigned int tmp;

	if (timer_is_v2())
		__raw_writel(0, timer_base + MX3_IR);
	else {
		tmp = __raw_readl(timer_base + MXC_TCTL);
		__raw_writel(tmp & ~MX1_2_TCTL_IRQEN, timer_base + MXC_TCTL);
	}
}

static inline void gpt_irq_enable(void)
{
	if (timer_is_v2())
		__raw_writel(1<<0, timer_base + MX3_IR);
	else {
		__raw_writel(__raw_readl(timer_base + MXC_TCTL) | MX1_2_TCTL_IRQEN,
			timer_base + MXC_TCTL);
	}
}

static void gpt_irq_acknowledge(void)
{
	if (!timer_is_v2()) {
		if (cpu_is_mx1())
			__raw_writel(0, timer_base + MX1_2_TSTAT);
		else
			__raw_writel(MX2_TSTAT_CAPT | MX2_TSTAT_COMP, timer_base + MX1_2_TSTAT);
	} else
		__raw_writel(MX3_TSTAT_OF1, timer_base + MX3_TSTAT);
}

static cycle_t timer_v1_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX1_2_TCN);
}

static cycle_t timer_v2_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX3_TCN);
}

static struct clocksource clocksource_mxc = {
	.name		= "mxc_timer1",
	.rating		= 200,
	.read		= timer_v1_get_cycles,
	.mask		= CLOCKSOURCE_MASK(32),
	.shift		= 20,
	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
};

static int __init mxc_clocksource_init(struct clk *timer_clk)
{
	unsigned int c = clk_get_rate(timer_clk);

	if (timer_is_v2())
		clocksource_mxc.read = timer_v2_get_cycles;

#ifdef CONFIG_IPIPE
	__ipipe_mach_ticks_per_jiffy = (c + HZ/2) / HZ;
#endif /* CONFIG_IPIPE */
	clocksource_mxc.mult = clocksource_hz2mult(c,
					clocksource_mxc.shift);
	clocksource_register(&clocksource_mxc);

	return 0;
}

/* clock event */

static int timer_v1_set_next_event(unsigned long evt,
			      struct clock_event_device *unused)
{
	unsigned long tcmp;

	tcmp = __raw_readl(timer_base + MX1_2_TCN) + evt;

	__raw_writel(tcmp, timer_base + MX1_2_TCMP);

	return (int)(tcmp - __raw_readl(timer_base + MX1_2_TCN)) < 0 ?
				-ETIME : 0;
}

static int timer_v2_set_next_event(unsigned long evt,
			      struct clock_event_device *unused)
{
	unsigned long tcmp;

	tcmp = __raw_readl(timer_base + MX3_TCN) + evt;

	__raw_writel(tcmp, timer_base + MX3_TCMP);

	return (int)(tcmp - __raw_readl(timer_base + MX3_TCN)) < 0 ? -ETIME : 0;
}

#ifdef DEBUG
static inline const char *clock_event_mode_label(enum clock_event_mode mode)
{
	switch (mode) {
	case CLOCK_EVT_MODE_PERIODIC:
		return "CLOCK_EVT_MODE_PERIODIC";
	case CLOCK_EVT_MODE_ONESHOT:
		return "CLOCK_EVT_MODE_ONESHOT";
	case CLOCK_EVT_MODE_SHUTDOWN:
		return "CLOCK_EVT_MODE_SHUTDOWN";
	case CLOCK_EVT_MODE_UNUSED:
		return "CLOCK_EVT_MODE_UNUSED";
	case CLOCK_EVT_MODE_RESUME:
		return "CLOCK_EVT_MODE_RESUME";
	}
	return "UNKNOWN";
};
#endif /* DEBUG */

static void mxc_set_mode(enum clock_event_mode mode,
				struct clock_event_device *evt)
{
	unsigned long flags;

	/*
	 * The timer interrupt generation is disabled at least
	 * for enough time to call mxc_set_next_event()
	 */
	local_irq_save(flags);

	/* Disable interrupt in GPT module */
	gpt_irq_disable();

	if (mode != clockevent_mode) {
		/* Set event time into far-far future */
		if (timer_is_v2())
			__raw_writel(__raw_readl(timer_base + MX3_TCN) - 3,
					timer_base + MX3_TCMP);
		else
			__raw_writel(__raw_readl(timer_base + MX1_2_TCN) - 3,
					timer_base + MX1_2_TCMP);

		/* Clear pending interrupt */
		gpt_irq_acknowledge();
	}

#ifdef DEBUG
	printk(KERN_INFO "mxc_set_mode: changing mode from %s[%d] to %s[%d]\n",
		clock_event_mode_label(clockevent_mode), clockevent_mode,
		clock_event_mode_label(mode), mode);
#endif /* DEBUG */

	/* Remember timer mode */
	clockevent_mode = mode;
	local_irq_restore(flags);
	switch (mode)
	{
	case CLOCK_EVT_MODE_PERIODIC:
		printk(KERN_ERR "mxc_set_mode: Periodic mode is not supported for i.MX\n");
		break;
	case CLOCK_EVT_MODE_ONESHOT:
	/*
	 * Do not put overhead of interrupt enable/disable into
	 * mxc_set_next_event(), the core has about 4 minutes
	 * to call mxc_set_next_event() or shutdown clock after
	 * mode switching
	 */
		local_irq_save(flags);
		gpt_irq_enable();
		local_irq_restore(flags);
		break;
	case CLOCK_EVT_MODE_SHUTDOWN:
	case CLOCK_EVT_MODE_UNUSED:
	case CLOCK_EVT_MODE_RESUME:
		/* Left event sources disabled, no more interrupts appear */
		break;
	}
}

/*
 * IRQ handler for the timer
 */
static irqreturn_t mxc_timer_interrupt(int irq, void *dev_id)
{
	struct clock_event_device *evt = &clockevent_mxc;
	uint32_t tstat;
	unsigned long reg;

#ifndef CONFIG_IPIPE
	if (timer_is_v2())
		tstat = __raw_readl(timer_base + MX3_TSTAT);
	else
		tstat = __raw_readl(timer_base + MX1_2_TSTAT);

	gpt_irq_acknowledge();
#else /* !CONFIG_IPIPE */

	ipipe_mach_update_tsc();

#endif /* !CONFIG_IPIPE */

	evt->event_handler(evt);

	return IRQ_HANDLED;
}

static struct irqaction mxc_timer_irq = {
	.name		= "i.MX Timer Tick",
	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
	.handler	= mxc_timer_interrupt,
};

static struct clock_event_device clockevent_mxc = {
	.name		= "mxc_timer1",
	.features	= CLOCK_EVT_FEAT_ONESHOT,
	.shift		= 32,
	.set_mode	= mxc_set_mode,
	.set_next_event	= timer_v1_set_next_event,
	.rating		= 200,
};

static int __init mxc_clockevent_init(struct clk *timer_clk)
{
	unsigned long c = clk_get_rate(timer_clk);

	printk(KERN_DEBUG "%s: timer clk rate is %lu.%03luMHz\n", __FUNCTION__,
		c / 1000000, c / 1000 % 1000);

	if (timer_is_v2())
		clockevent_mxc.set_next_event = timer_v2_set_next_event;

	clockevent_mxc.mult = div_sc(c, NSEC_PER_SEC,
					clockevent_mxc.shift);
	clockevent_mxc.max_delta_ns =
			clockevent_delta2ns(0xfffffffe, &clockevent_mxc);
	clockevent_mxc.min_delta_ns =
			clockevent_delta2ns(0xff, &clockevent_mxc);

	clockevent_mxc.cpumask = cpumask_of(0);

	clockevents_register_device(&clockevent_mxc);

	return 0;
}

void __init mxc_timer_init(struct clk *timer_clk, void __iomem *base, int irq)
{
	uint32_t tctl_val;

	clk_enable(timer_clk);

	timer_base = base;

	/*
	 * Initialise to a known state (all timers off, and timing reset)
	 */

	__raw_writel(0, timer_base + MXC_TCTL);
	__raw_writel(0, timer_base + MXC_TPRER); /* see datasheet note */

	if (timer_is_v2())
		tctl_val = MX3_TCTL_CLK_IPG | MX3_TCTL_FRR | MX3_TCTL_WAITEN | MXC_TCTL_TEN;
	else
		tctl_val = MX1_2_TCTL_FRR | MX1_2_TCTL_CLK_PCLK1 | MXC_TCTL_TEN;

	__raw_writel(tctl_val, timer_base + MXC_TCTL);

	/* init and register the timer to the framework */
	mxc_clocksource_init(timer_clk);
	mxc_clockevent_init(timer_clk);

	/* Make irqs happen */
	setup_irq(irq, &mxc_timer_irq);

#ifdef CONFIG_IPIPE
	__ipipe_mach_timerint = irq;
#ifndef CONFIG_SMP
	tsc = (union tsc_reg *) __ipipe_tsc_area;
	barrier();
#endif /* CONFIG_SMP */

	mxc_min_delay = 2 * ((ipipe_cpu_freq() + 500000) / 1000000) ?: 1;
	if (mxc_min_delay == 0)
	{
		mxc_min_delay = 1;
	}

	printk(  KERN_INFO "mxc_min_delay = %d\n", mxc_min_delay );
	mxc_timer_initialized = 1;
#endif /* CONFIG_IPIPE */
}

#ifdef CONFIG_IPIPE
int __ipipe_check_tickdev(const char *devname)
{
	return !strcmp(devname, clockevent_mxc.name);
}

void __ipipe_mach_acktimer(void)
{
	uint32_t tstat;

	if (timer_is_v2())
		tstat = __raw_readl(timer_base + MX3_TSTAT);
	else
		tstat = __raw_readl(timer_base + MX1_2_TSTAT);

	gpt_irq_acknowledge();
}

static void ipipe_mach_update_tsc(void)
{
	union tsc_reg *local_tsc;
	unsigned long stamp, flags;

	local_irq_save_hw(flags);
	local_tsc = &tsc[ipipe_processor_id()];
	if (!timer_is_v2())
		stamp = __raw_readl(timer_base + MX1_2_TCN);
	else
		stamp = __raw_readl(timer_base + MX3_TCN);
	if (unlikely(stamp < local_tsc->low))
		/* 32 bit counter wrapped, increment high word. */
		local_tsc->high++;
	local_tsc->low = stamp;
	local_irq_restore_hw(flags);
}

notrace unsigned long long __ipipe_mach_get_tsc(void)
{
	if (likely(mxc_timer_initialized)) {
		union tsc_reg *local_tsc, result;
		unsigned long stamp;

		local_tsc = &tsc[ipipe_processor_id()];

		if (!timer_is_v2())  {
			__asm__ ("ldmia %1, %M0\n"
				 : "=r"(result.full), "+&r"(local_tsc)
				 : "m"(*local_tsc));
			barrier();
			stamp = __raw_readl(timer_base + MX1_2_TCN);
		} else {
			__asm__ ("ldmia %1, %M0\n"
				 : "=r"(result.full), "+&r"(local_tsc)
				 : "m"(*local_tsc));
			barrier();
			stamp = __raw_readl(timer_base + MX3_TCN);
		}
		if (unlikely(stamp < result.low))
			/* 32 bit counter wrapped, increment high word. */
			result.high++;
		result.low = stamp;

		return result.full;
	}

	return 0;
}
EXPORT_SYMBOL(__ipipe_mach_get_tsc);

/*
 * Reprogram the timer
 */

void __ipipe_mach_set_dec(unsigned long delay)
{
	if (delay > mxc_min_delay) {
		unsigned long flags;

		local_irq_save_hw(flags);
		if (!time_is_v2())
			timer_v1_set_next_event(delay, NULL);
		else
			timer_v2_set_next_event(delay, NULL);
		local_irq_restore_hw(flags);
	} else
		ipipe_trigger_irq(__ipipe_mach_timerint);
}
EXPORT_SYMBOL(__ipipe_mach_set_dec);

void __ipipe_mach_release_timer(void)
{
	mxc_set_mode(clockevent_mxc.mode, &clockevent_mxc);
	if (clockevent_mxc.mode == CLOCK_EVT_MODE_ONESHOT)
		clockevent_mxc.set_next_event(LATCH, &clockevent_mxc);
}
EXPORT_SYMBOL(__ipipe_mach_release_timer);

unsigned long __ipipe_mach_get_dec(void)
{
	if (!time_is_v2())
		return __raw_readl(timer_base + MX1_2_TCMP)
			- __raw_readl(timer_base + MX1_2_TCN);
	else
		return __raw_readl(timer_base + MX3_TCMP)
			- __raw_readl(timer_base + MX3_TCN);
}
#endif /* CONFIG_IPIPE */

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i tried your code but th behavior is the same.

Then i tried a linux base app and works correctly.






Il 10/04/2012 11:37, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 11:21 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> here is my time.c
> Though you have not made all the changes I suggested. Here is the time.c
> I would use.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 12:39 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i tried your code but th behavior is the same.
> 
> Then i tried a linux base app and works correctly.

The tsc physical address passed to user-space looks wrong.

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_FREERUNNING;
	if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
		info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
	}
	info->u.fr.mask = 0xffffffff;
	info->u.fr.tsc = &tsc->full;
}

Here cpu_is_mx2() will return true, and we will not go to cpu_is_mx25().

Are you using the tsc in user-space?

If you are passing --enable-arm-mach=mx2 to xenomai configure 
script, you are using the tsc in user-space, and it is a wonder 
how it works.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

Hi Gilles,

i added this in configure of xenomai so i pass --enable-arm-mach=imx25

imx25)        arch=5
             tsc_type=__XN_TSC_TYPE_FREERUNNING;;

Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and 
imx25 is NOT mx2
#define cpu_is_mx2()    (cpu_is_mx21() || cpu_is_mx27())

i don't understand a things.
Does the tsc necessary to calculate correct timer period, or can i 
disable tsc and xenomai continue work correctly ?

However i cannot use tsc in my simple application. I resend the simple C 
application that doesn't work.


Il 10/04/2012 13:25, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i tried your code but th behavior is the same.
>>
>> Then i tried a linux base app and works correctly.
> The tsc physical address passed to user-space looks wrong.
>
> void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
> {
> 	info->type = IPIPE_TSC_TYPE_FREERUNNING;
> 	if (cpu_is_mx1()) {
> #ifdef CONFIG_ARCH_MX1
> 		info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
> #endif
> 	} else if (cpu_is_mx2()) {
> #ifdef CONFIG_ARCH_MX2
> 		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
> #endif
> 	} else if (cpu_is_mx3() || cpu_is_mx25() ) {
> #if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
> 		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
> #endif
> 	}
> 	info->u.fr.mask = 0xffffffff;
> 	info->u.fr.tsc =&tsc->full;
> }
>
> Here cpu_is_mx2() will return true, and we will not go to cpu_is_mx25().
>
> Are you using the tsc in user-space?
>
> If you are passing --enable-arm-mach=mx2 to xenomai configure
> script, you are using the tsc in user-space, and it is a wonder
> how it works.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: testpreempt.c --]
[-- Type: text/plain, Size: 1696 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>

#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>	/* for MCL_CURRENT and MCL_FUTURE */
#include <rtdm/rtdm.h>
#include <native/task.h>
#include <nucleus/trace.h>

#define GPIO6_ON 		*Gpio2ValAddr |= 1 << 6
#define GPIO6_OFF		*Gpio2ValAddr &= ~(1 << 6);

static RT_TASK rt_task_desc;
static RT_TASK tsk2ms;

	//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;

volatile int cnt2ms = 0;
volatile int cntmain = 0;
volatile int x;

void funct2ms( void * params )
{
	for(;;)
	{
		GPIO6_ON;
		rt_task_sleep( 2000000 );
		++ cnt2ms;
		GPIO6_OFF;
	}
}

int main(int argc, char *argv[])
{
	int count = 0;
	int traceOn = 0;
	int fd, ret;

	// no memory-swapping for this programm
	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
	if( ret )
	{
		perror("ERROR : mlockall has failled");
		exit(1);
	}


	fd = open( "/dev/mem", O_RDWR | O_SYNC );
	printf( "FD=%d", fd );
	fflush( stdout );

	Gpio2ValAddr = (unsigned long  *)mmap(  NULL, 0x1000, PROT_READ | PROT_WRITE,  MAP_SHARED, fd, 0x53FD0000 );
	GPIO6_ON;
	GPIO6_OFF;

	rt_task_create( &tsk2ms, "task2ms",0, 99, 0 );
	rt_task_start( &tsk2ms, funct2ms, NULL );
	
	ret = rt_task_shadow(&rt_task_desc, NULL, 1, 0);
	if( ret != 0 )
	{
		fprintf(stderr, "ERROR : rt_task_shadow: %s\n", strerror(-ret));
		exit( 1 );
	}

	for(;;)
	{
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		//xntrace_user_freeze(0, 0);
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		rt_task_sleep( 10000000 );
	}

	return 0;
}

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:05 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
> 
> imx25)        arch=5
>              tsc_type=__XN_TSC_TYPE_FREERUNNING;;
> 
> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and 
> imx25 is NOT mx2
> #define cpu_is_mx2()    (cpu_is_mx21() || cpu_is_mx27())
> 
> i don't understand a things.
> Does the tsc necessary to calculate correct timer period, or can i 
> disable tsc and xenomai continue work correctly ?

Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
tsc in user-space, you will not see that it is wrong. Correct physical
address is only needed for user-space.

> 
> However i cannot use tsc in my simple application. I resend the simple C 
> application that doesn't work.

What do you mean you can not use the tsc in your application? What
happens if you use it?

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Il 10/04/2012 14:06, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 02:05 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
>>
>> imx25)        arch=5
>>               tsc_type=__XN_TSC_TYPE_FREERUNNING;;
>>
>> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and
>> imx25 is NOT mx2
>> #define cpu_is_mx2()    (cpu_is_mx21() || cpu_is_mx27())
>>
>> i don't understand a things.
>> Does the tsc necessary to calculate correct timer period, or can i
>> disable tsc and xenomai continue work correctly ?
> Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
> tsc in user-space, you will not see that it is wrong. Correct physical
> address is only needed for user-space.
>
>> However i cannot use tsc in my simple application. I resend the simple C
>> application that doesn't work.
> What do you mean you can not use the tsc in your application? What
> happens if you use it?
>
If i use tsc i have no error and i read a correct value.

-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:11 PM, Roberto Bielli wrote:
> Il 10/04/2012 14:06, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 02:05 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
>>>
>>> imx25)        arch=5
>>>               tsc_type=__XN_TSC_TYPE_FREERUNNING;;
>>>
>>> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and
>>> imx25 is NOT mx2
>>> #define cpu_is_mx2()    (cpu_is_mx21() || cpu_is_mx27())
>>>
>>> i don't understand a things.
>>> Does the tsc necessary to calculate correct timer period, or can i
>>> disable tsc and xenomai continue work correctly ?
>> Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
>> tsc in user-space, you will not see that it is wrong. Correct physical
>> address is only needed for user-space.
>>
>>> However i cannot use tsc in my simple application. I resend the simple C
>>> application that doesn't work.
>> What do you mean you can not use the tsc in your application? What
>> happens if you use it?
>>
> If i use tsc i have no error and i read a correct value.
> 
So, it works. Good news. To know if it works as expected, you can try
the "latency" test.

Something I have not asked, could you type:
cat /proc/xenomai/timer

on the mx25 board?

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

here is some logs.

status=on:setup=616:clock=509343446344:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509413956366:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509461811116:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509493738137:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509642692217:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509889401336:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=509959233537:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=510033716418:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=510083589650:timerdev=mxc_timer1:clockdev=mxc_timer1
root@domain.hid# cat /proc/xenomai/timer
status=on:setup=616:clock=510145433674:timerdev=mxc_timer1:clockdev=mxc_timer1

Il 10/04/2012 14:12, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 02:11 PM, Roberto Bielli wrote:
>> Il 10/04/2012 14:06, Gilles Chanteperdrix ha scritto:
>>> On 04/10/2012 02:05 PM, Roberto Bielli wrote:
>>>> Hi Gilles,
>>>>
>>>> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
>>>>
>>>> imx25)        arch=5
>>>>                tsc_type=__XN_TSC_TYPE_FREERUNNING;;
>>>>
>>>> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and
>>>> imx25 is NOT mx2
>>>> #define cpu_is_mx2()    (cpu_is_mx21() || cpu_is_mx27())
>>>>
>>>> i don't understand a things.
>>>> Does the tsc necessary to calculate correct timer period, or can i
>>>> disable tsc and xenomai continue work correctly ?
>>> Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
>>> tsc in user-space, you will not see that it is wrong. Correct physical
>>> address is only needed for user-space.
>>>
>>>> However i cannot use tsc in my simple application. I resend the simple C
>>>> application that doesn't work.
>>> What do you mean you can not use the tsc in your application? What
>>> happens if you use it?
>>>
>> If i use tsc i have no error and i read a correct value.
>>
> So, it works. Good news. To know if it works as expected, you can try
> the "latency" test.
>
> Something I have not asked, could you type:
> cat /proc/xenomai/timer
>
> on the mx25 board?
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 12:39 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i tried your code but th behavior is the same.
> 
> Then i tried a linux base app and works correctly.

In the exact same conditions? With the crunching task running with
SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
priority 99, and the linux real-time throttling disabled?

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i tried your code but th behavior is the same.
>>
>> Then i tried a linux base app and works correctly.
> In the exact same conditions? With the crunching task running with
> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
> priority 99, and the linux real-time throttling disabled?
>
Yes, and i see that every LATCH ( about ~10ms ) period the task with 
higher priority is wakeup.
So a task with lower priority is interrupted by timer interrupt and 
reschedule the task with higher priority.

-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.

In the example you sent the periodic task was running with a 200us
period, not 10ms.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

In the xenomai example the task periodic is 2ms not 200us. ( 
rt_task_sleep( 2ms 000us 000ns ) );
And the 10ms is because the default system time period of the timer 
without xenomai is ~10ms.
So a process that execute in linux base can be re-scheduled only when 
the timer generate an interrupt , the task makes I/O, or sleeps.



Il 10/04/2012 14:36, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 02:33 PM, Roberto Bielli wrote:
>> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>>> Hi Gilles,
>>>>
>>>> i tried your code but th behavior is the same.
>>>>
>>>> Then i tried a linux base app and works correctly.
>>> In the exact same conditions? With the crunching task running with
>>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>>> priority 99, and the linux real-time throttling disabled?
>>>
>> Yes, and i see that every LATCH ( about ~10ms ) period the task with
>> higher priority is wakeup.
> In the example you sent the periodic task was running with a 200us
> period, not 10ms.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:58 PM, Roberto Bielli wrote:
> In the xenomai example the task periodic is 2ms not 200us. ( 
> rt_task_sleep( 2ms 000us 000ns ) );

sorry, I misred.

> And the 10ms is because the default system time period of the timer 
> without xenomai is ~10ms.
> So a process that execute in linux base can be re-scheduled only when 
> the timer generate an interrupt , the task makes I/O, or sleeps.

That is only if you do not use CONFIG_HIGH_RES_TIMERS, in which case you
are not in the same configuration as xenomai, and the test does not mean
anything.

> 
> 
> 
> Il 10/04/2012 14:36, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 02:33 PM, Roberto Bielli wrote:
>>> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>>>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>>>> Hi Gilles,
>>>>>
>>>>> i tried your code but th behavior is the same.
>>>>>
>>>>> Then i tried a linux base app and works correctly.
>>>> In the exact same conditions? With the crunching task running with
>>>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>>>> priority 99, and the linux real-time throttling disabled?
>>>>
>>> Yes, and i see that every LATCH ( about ~10ms ) period the task with
>>> higher priority is wakeup.
>> In the example you sent the periodic task was running with a 200us
>> period, not 10ms.
>>
> 
> 


-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.
> So a task with lower priority is interrupted by timer interrupt and 
> reschedule the task with higher priority.
> 
The only thing I can think is that the timer interrupt in fact stays 
masked. You can try the following patch:

diff --git a/arch/arm/plat-mxc/irq.c b/arch/arm/plat-mxc/irq.c                  
index 8aee763..7e4cc2e 100644                                                   
--- a/arch/arm/plat-mxc/irq.c                                                   
+++ b/arch/arm/plat-mxc/irq.c                                                   
@@ -94,12 +94,14 @@ EXPORT_SYMBOL(mxc_set_irq_fiq);                             
 static void mxc_mask_irq(unsigned int irq)                                     
 {                                                                              
        __raw_writel(irq, avic_base + AVIC_INTDISNUM);                          
+       __raw_readl(avic_base + AVIC_INTDISNUM);                                
 }                                                                              
                                                                                
 /* Enable interrupt number "irq" in the AVIC */                                
 static void mxc_unmask_irq(unsigned int irq)                                   
 {                                                                              
        __raw_writel(irq, avic_base + AVIC_INTENNUM);                           
+       __raw_readl(avic_base + AVIC_INTENNUM);                                 
 }                                                                              
                                                                                
 static struct irq_chip mxc_avic_chip = {                                       


If I had to debug this issue, I would look at all the timer and 
interrupt controller registers value, to see what is wrong.

You can also try the plain linux example with CONFIG_IPIPE on, but 
without CONFIG_XENOMAI.

Other than that, without access to the board, it is hard for me to 
debug further, so I am afraid you are on your own.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

i try your workaround but nothing is changed.
I make another test. I try to comment out all the content of 
mxc_mask_irq() but the result is the same.
(the mxc_mask_irq is used also for acking interrupts but is not correct 
why it doesn't write in the processor manual)
Do you know if there is a code over the mxc_mask_irq that disable the 
interrupts ?

About interrupt gpio it should be a link with this behaviour ? ( i don't 
want gpio as interrupts )



Il 10/04/2012 14:40, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 02:33 PM, Roberto Bielli wrote:
>> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>>> Hi Gilles,
>>>>
>>>> i tried your code but th behavior is the same.
>>>>
>>>> Then i tried a linux base app and works correctly.
>>> In the exact same conditions? With the crunching task running with
>>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>>> priority 99, and the linux real-time throttling disabled?
>>>
>> Yes, and i see that every LATCH ( about ~10ms ) period the task with
>> higher priority is wakeup.
>> So a task with lower priority is interrupted by timer interrupt and
>> reschedule the task with higher priority.
>>
> The only thing I can think is that the timer interrupt in fact stays
> masked. You can try the following patch:
>
> diff --git a/arch/arm/plat-mxc/irq.c b/arch/arm/plat-mxc/irq.c
> index 8aee763..7e4cc2e 100644
> --- a/arch/arm/plat-mxc/irq.c
> +++ b/arch/arm/plat-mxc/irq.c
> @@ -94,12 +94,14 @@ EXPORT_SYMBOL(mxc_set_irq_fiq);
>   static void mxc_mask_irq(unsigned int irq)
>   {
>          __raw_writel(irq, avic_base + AVIC_INTDISNUM);
> +       __raw_readl(avic_base + AVIC_INTDISNUM);
>   }
>
>   /* Enable interrupt number "irq" in the AVIC */
>   static void mxc_unmask_irq(unsigned int irq)
>   {
>          __raw_writel(irq, avic_base + AVIC_INTENNUM);
> +       __raw_readl(avic_base + AVIC_INTENNUM);
>   }
>
>   static struct irq_chip mxc_avic_chip = {
>
>
> If I had to debug this issue, I would look at all the timer and
> interrupt controller registers value, to see what is wrong.
>
> You can also try the plain linux example with CONFIG_IPIPE on, but
> without CONFIG_XENOMAI.
>
> Other than that, without access to the board, it is hard for me to
> debug further, so I am afraid you are on your own.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/11/2012 08:59 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try your workaround but nothing is changed.
> I make another test. I try to comment out all the content of 
> mxc_mask_irq() but the result is the same.
> (the mxc_mask_irq is used also for acking interrupts but is not correct 
> why it doesn't write in the processor manual)
> Do you know if there is a code over the mxc_mask_irq that disable the 
> interrupts ?

mxc_mask_irq disables the interrupt at interrupt controller level.
Generally, you can not avoid to do that.

Have you tried reproducing the problem with linux configured with
CONFIG_HIGH_RES_TIMERS?


-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/11/2012 08:59 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try your workaround but nothing is changed.
> I make another test. I try to comment out all the content of 
> mxc_mask_irq() but the result is the same.
> (the mxc_mask_irq is used also for acking interrupts but is not correct 
> why it doesn't write in the processor manual)
> Do you know if there is a code over the mxc_mask_irq that disable the 
> interrupts ?
> 
> About interrupt gpio it should be a link with this behaviour ? ( i don't 
> want gpio as interrupts )

No,  I do not think it is possible. You do not get to decide whether you
want gpio as interrupts or not, the design of the board you use does.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

Hi Gilles,

i found in my trace the function 'xnthread_timeout_handler' that is 
called in the code where there is the problem.
In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?] 
stalled xeno domain 
<http://www.opensubscriber.com/messages/xenomai@xenomai.org> )

Do you think that can be a similar problem ?



Il 11/04/2012 14:10, Gilles Chanteperdrix ha scritto:
> On 04/11/2012 08:59 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i try your workaround but nothing is changed.
>> I make another test. I try to comment out all the content of
>> mxc_mask_irq() but the result is the same.
>> (the mxc_mask_irq is used also for acking interrupts but is not correct
>> why it doesn't write in the processor manual)
>> Do you know if there is a code over the mxc_mask_irq that disable the
>> interrupts ?
>>
>> About interrupt gpio it should be a link with this behaviour ? ( i don't
>> want gpio as interrupts )
> No,  I do not think it is possible. You do not get to decide whether you
> want gpio as interrupts or not, the design of the board you use does.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: Type: text/html, Size: 3476 bytes --]

[Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 4985 bytes --]

Hi Gilles,

you tell me that you are working on imx.
Do you know if there is a working xenomai on imx (any kernel or imx 
version) ?

Thanks a lot


Il 12/04/2012 12:12, Roberto Bielli ha scritto:
> Hi Gilles,
>
> i found in my trace the function 'xnthread_timeout_handler' that is 
> called in the code where there is the problem.
> In xenomai there is a topic about that function. ( [Xenomai-core] 
> [BUG?] stalled xeno domain 
> <http://www.opensubscriber.com/messages/xenomai@xenomai.org> )
>
> Do you think that can be a similar problem ?
>
>
>
> Il 11/04/2012 14:10, Gilles Chanteperdrix ha scritto:
>> On 04/11/2012 08:59 AM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i try your workaround but nothing is changed.
>>> I make another test. I try to comment out all the content of
>>> mxc_mask_irq() but the result is the same.
>>> (the mxc_mask_irq is used also for acking interrupts but is not correct
>>> why it doesn't write in the processor manual)
>>> Do you know if there is a code over the mxc_mask_irq that disable the
>>> interrupts ?
>>>
>>> About interrupt gpio it should be a link with this behaviour ? ( i don't
>>> want gpio as interrupts )
>> No,  I do not think it is possible. You do not get to decide whether you
>> want gpio as interrupts or not, the design of the board you use does.
>>
>
>
> -- 
> +------------------------------------------------------------------------------------------------+
> 							
> Roberto Bielli
> Sviluppo Software					
> Axel S.r.l.					
> 							
> Via Del Cannino, 3 				
> 21020 Crosio Della Valle			
> Varese - Italy					
> 							
> Telefono: +39 0332 949600			
> Fax:      +39 0332 969315			
> 							
> E-mail:roberto.bielli@domain.hid	
> Web Site:www.axelsw.it
>
> +------------------------------------------------------------------------------------------------+
>
> Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
> Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
> dandocene gentilmente comunicazione. Grazie.
> Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
> I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
> per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
> Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati:info@domain.hid
>
> This e-mail and any attachments is confidential and may contain privileged information
> intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
> else is unauthorised. If you are not the intended recipient,
> please delete this message and any attachments and advise the sender
> by return e-mail.Thank you.  			
> 							
> +------------------------------------------------------------------------------------------------+
>
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>
>
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com <http://www.avg.com>
> Versione: 2012.0.1913 / Database dei virus: 2411/4929 - Data di 
> rilascio: 11/04/2012
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: Type: text/html, Size: 6775 bytes --]

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/12/2012 06:58 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> you tell me that you are working on imx.
> Do you know if there is a working xenomai on imx (any kernel or imx 
> version) ?

I have tested Xenomai  on imx31, imx51, imx53, imx6q. It works on these
platforms. Now, what you are doing is in fact porting xenomai on imx25,
nobody did that before you, and you are faced with a peculiarity of the
timer on this platform. What you should do is:
- try to reproduce the problem with an unpatched linux with
CONFIG_HIGH_RES_TIMERS
- or try and look at the timers registers value at the time when the bug
happens to see what is going wrong.

Also, the first thing to do when running xenomai on a new platform is to
run the "latency" test. Have you run this test?

I feel like I am starting to repeat myself, I do not know if I should
continue trying and answering you.

-- 
                                                                Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

Hi Gilles,

you don't feel like to repeat.
I'm trying all the things that you told me and i will do all the missing 
test that you told me.

And now this is the result of latency that i ran. It seems correct.
root@domain.hid# ./latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|     67.263|     77.203|     85.458|       0|     0|     67.263|     
85.458
RTD|     67.293|     77.203|    100.240|       0|     0|     67.263|    
100.240
RTD|     67.413|     77.203|     88.360|       0|     0|     67.263|    
100.240
RTD|     67.323|     77.233|     86.661|       0|     0|     67.263|    
100.240
RTD|     66.676|     77.187|     85.849|       0|     0|     66.676|    
100.240
RTD|     67.353|     77.233|     87.172|       0|     0|     66.676|    
100.240
RTD|     67.203|     77.368|    217.323|       0|     0|     66.676|    
217.323
RTD|     67.609|     77.172|     87.022|       0|     0|     66.676|    
217.323
RTD|     66.796|     77.218|     86.030|       0|     0|     66.676|    
217.323
RTD|     67.714|     77.172|     85.368|       0|     0|     66.676|    
217.323
RTD|     67.263|     77.233|     87.263|       0|     0|     66.676|    
217.323
RTD|     67.022|     77.172|     85.684|       0|     0|     66.676|    
217.323
RTD|     67.669|     77.248|     83.894|       0|     0|     66.676|    
217.323
RTD|     67.969|     77.172|     86.736|       0|     0|     66.676|    
217.323
RTD|     66.827|     77.187|     87.383|       0|     0|     66.676|    
217.323
RTD|     67.097|     77.263|    119.909|       0|     0|     66.676|    
217.323
RTD|     67.022|     77.308|    183.548|       0|     0|     66.676|    
217.323
RTD|     66.616|     77.187|     84.902|       0|     0|     66.616|    
217.323
RTD|     67.353|     77.187|     91.338|       0|     0|     66.616|    
217.323
RTD|     67.022|     77.233|     83.278|       0|     0|     66.616|    
217.323
RTD|     67.037|     77.248|     87.022|       0|     0|     66.616|    
217.323
RTT|  00:00:22  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|     67.037|     77.157|     86.796|       0|     0|     66.616|    
217.323
RTD|     66.902|     77.263|    125.383|       0|     0|     66.616|    
217.323
RTD|     67.548|     77.187|     87.894|       0|     0|     66.616|    
217.323
RTD|     67.338|     77.248|     86.255|       0|     0|     66.616|    
217.323
RTD|     67.157|     77.218|     87.157|       0|     0|     66.616|    
217.323
RTD|     67.308|     77.233|     84.180|       0|     0|     66.616|    
217.323
RTD|     67.684|     77.203|     86.631|       0|     0|     66.616|    
217.323
RTD|     67.578|     77.187|     89.368|       0|     0|     66.616|    
217.323
RTD|     66.917|     77.203|     86.691|       0|     0|     66.616|    
217.323
RTD|     66.992|     77.218|     86.616|       0|     0|     66.616|    
217.323
RTD|     67.142|     77.218|     87.097|       0|     0|     66.616|    
217.323
RTD|     67.248|     77.187|     90.180|       0|     0|     66.616|    
217.323
RTD|     67.368|     77.233|     87.939|       0|     0|     66.616|    
217.323
RTD|     67.413|     77.187|     89.503|       0|     0|     66.616|    
217.323
RTD|     67.684|     77.233|     87.368|       0|     0|     66.616|    
217.323
RTD|     67.428|     77.157|     87.203|       0|     0|     66.616|    
217.323
RTD|     67.248|     77.157|     91.368|       0|     0|     66.616|    
217.323
RTD|     67.233|     77.368|    215.879|       0|     0|     66.616|    
217.323
RTD|     67.428|     77.323|    178.857|       0|     0|     66.616|    
217.323
RTD|     66.917|     77.187|     92.075|       0|     0|     66.616|    
217.323
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|     66.616|     77.218|    217.323|       0|     0|    
00:00:41/00:00:41

Il 12/04/2012 19:40, Gilles Chanteperdrix ha scritto:
> On 04/12/2012 06:58 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> you tell me that you are working on imx.
>> Do you know if there is a working xenomai on imx (any kernel or imx
>> version) ?
> I have tested Xenomai  on imx31, imx51, imx53, imx6q. It works on these
> platforms. Now, what you are doing is in fact porting xenomai on imx25,
> nobody did that before you, and you are faced with a peculiarity of the
> timer on this platform. What you should do is:
> - try to reproduce the problem with an unpatched linux with
> CONFIG_HIGH_RES_TIMERS
> - or try and look at the timers registers value at the time when the bug
> happens to see what is going wrong.
>
> Also, the first thing to do when running xenomai on a new platform is to
> run the "latency" test. Have you run this test?
>
> I feel like I am starting to repeat myself, I do not know if I should
> continue trying and answering you.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/13/2012 10:44 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> you don't feel like to repeat.
> I'm trying all the things that you told me and i will do all the missing 
> test that you told me.

So, what is the result of running your test with unpatched Linux, but
with CONFIG_HIGH_RES_TIMERS enabled?

> 
> And now this is the result of latency that i ran. It seems correct.

Is it with or without CONFIG_HIGH_RES_TIMERS?


-- 
                                                                Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

[-- Attachment #1: Type: text/plain, Size: 5320 bytes --]

Hi Gilles,

here find the answers.
sorry for the delay.

Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto:
> On 04/13/2012 10:44 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> you don't feel like to repeat.
>> I'm trying all the things that you told me and i will do all the missing
>> test that you told me.
> So, what is the result of running your test with unpatched Linux, but
> with CONFIG_HIGH_RES_TIMERS enabled?
the result is the same.
With the base linux application and  CONFIG_HIGH_RES_TIMERS all it's ok,
instead with xenomai application the task with less priority halt the 
task with higher priority until it sleeps.
I send you my .config file and the test with pthread base.

>
>> And now this is the result of latency that i ran. It seems correct.
> Is it with or without CONFIG_HIGH_RES_TIMERS?
was without CONFIG_HIGH_RES_TIMERS.
Instead this is the test with CONFIG_HIGH_RES_TIMERS

  ./latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|     69.533|     77.458|    123.909|       0|     0|     69.533|    
123.909
RTD|     70.571|     77.398|     85.909|       0|     0|     69.533|    
123.909
RTD|     70.887|     77.383|     86.511|       0|     0|     69.533|    
123.909
RTD|     69.458|     77.428|     86.812|       0|     0|     69.458|    
123.909
RTD|     70.330|     77.398|     85.804|       0|     0|     69.458|    
123.909
RTD|     70.691|     77.458|     86.195|       0|     0|     69.458|    
123.909
RTD|     69.578|     77.428|     89.172|       0|     0|     69.458|    
123.909
RTD|     69.548|     77.398|     89.037|       0|     0|     69.458|    
123.909
RTD|     70.631|     77.398|     86.270|       0|     0|     69.458|    
123.909
RTD|     69.819|     77.443|     86.135|       0|     0|     69.458|    
123.909
RTD|     69.609|     77.458|     88.857|       0|     0|     69.458|    
123.909
RTD|     70.511|     77.398|     86.300|       0|     0|     69.458|    
123.909
RTD|     69.368|     77.368|     85.759|       0|     0|     69.368|    
123.909
RTD|     70.045|     77.443|     87.563|       0|     0|     69.368|    
123.909
RTD|     70.812|     77.443|     88.315|       0|     0|     69.368|    
123.909
RTD|     70.586|     77.398|     84.812|       0|     0|     69.368|    
123.909
RTD|     69.548|     77.428|     86.812|       0|     0|     69.368|    
123.909
RTD|     70.857|     77.413|     86.270|       0|     0|     69.368|    
123.909
RTD|     70.751|     77.413|     90.360|       0|     0|     69.368|    
123.909
RTD|     69.548|     77.398|     87.699|       0|     0|     69.368|    
123.909
RTD|     70.030|     77.398|     94.300|       0|     0|     69.368|    
123.909
RTT|  00:00:22  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|     70.751|     77.428|     85.639|       0|     0|     69.368|    
123.909
RTD|     65.699|     77.443|    122.586|       0|     0|     65.699|    
123.909
RTD|     69.954|     77.428|     86.496|       0|     0|     65.699|    
123.909
RTD|     70.556|     77.413|     86.902|       0|     0|     65.699|    
123.909
RTD|     70.090|     77.413|     86.240|       0|     0|     65.699|    
123.909
RTD|     69.639|     77.533|    162.616|       0|     0|     65.699|    
162.616
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|     65.699|     77.413|    162.616|       0|     0|    
00:00:28/00:00:28
>
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+


[-- Attachment #2: testpreemptBase.c --]
[-- Type: text/plain, Size: 2145 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>

#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>	/* for MCL_CURRENT and MCL_FUTURE */


#define GPIO6_ON 		*Gpio2ValAddr |= 1 << 6
#define GPIO6_OFF		*Gpio2ValAddr &= ~(1 << 6);

pthread_t task1;
pthread_t task2;

void CreateRunTask( pthread_t * threadPtr, int prio, void * fnz )
{
	pthread_attr_t thread_attr;
	struct sched_param sched;
	
	pthread_attr_init(&thread_attr);
	
	pthread_attr_setschedpolicy(&thread_attr, SCHED_RR);
	sched.sched_priority = prio;
	pthread_attr_setschedparam(&thread_attr, &sched);

	pthread_create(threadPtr, &thread_attr, fnz, NULL );
	pthread_attr_destroy(&thread_attr);
}

	//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;

volatile int cnt2ms = 0;
volatile int cntmain = 0;
volatile int x;


void funct2ms( void * params )
{
	struct timespec ts;
    ts.tv_sec = 0;
    ts.tv_nsec = 2000000;
	
	for(;;)
	{
		GPIO6_ON;
		nanosleep( &ts, NULL );
		++ cnt2ms;
		GPIO6_OFF;
	}
}

void funct10ms( void * params )
{
	struct timespec ts;
    ts.tv_sec = 0;
    ts.tv_nsec = 10000000;

	for( ;;)
	{
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		for( x=0; x < 1000000; x++ );
		
		nanosleep( &ts, NULL );
	}
}

int main(int argc, char *argv[])
{
	int count = 0;
	int traceOn = 0;
	int fd, ret;
	unsigned long reg, reg1;
	int device;
	unsigned long memShared=0;

	fd = open( "/dev/mem", O_RDWR | O_SYNC );
	printf( "FD=%d", fd );
	fflush( stdout );

	Gpio2ValAddr = (unsigned long  *)mmap(  NULL, 0x1000, PROT_READ | PROT_WRITE,  MAP_SHARED, fd, 0x53FD0000 );
	GPIO6_ON;
	GPIO6_OFF;

	CreateRunTask( &task1, 99, funct2ms );
	CreateRunTask( &task2, 1, funct10ms );

	while( 1 )
		sleep( 1 );

	return 0;
}

[-- Attachment #3: .config --]
[-- Type: application/xml, Size: 47137 bytes --]

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/18/2012 10:44 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here find the answers.
> sorry for the delay.
> 
> Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto:
>> On 04/13/2012 10:44 AM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> you don't feel like to repeat.
>>> I'm trying all the things that you told me and i will do all the missing
>>> test that you told me.
>> So, what is the result of running your test with unpatched Linux, but
>> with CONFIG_HIGH_RES_TIMERS enabled?
> the result is the same.
> With the base linux application and  CONFIG_HIGH_RES_TIMERS all it's ok,
> instead with xenomai application the task with less priority halt the 
> task with higher priority until it sleeps.
> I send you my .config file and the test with pthread base.

You know as well as me that this description of the problem is
inaccurate, what really happens is that the timer is programmed but does
not tick. What you have to do now is try and understand what is the
difference between the way xenomai and linux handle the timer to
understand what cause it not to work in xenomai case. If I were you, to
understand this difference, I would start by dumping all timer registers
values at the time when the problem is detected, that is, before the
timer is programmed again. But I am afraid I can not give you more help,
ultimately you are the one which is doing the port to imx25, so you are
on your own.

-- 
					    Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

Hi Gilles,

i try to give only another accurate information.

i made another test:
i write a xenomai driver for reading the timer and avic register and i 
see a strange behaviour.
when there is the problem the interrupt is NOT masqueraded in avic but 
the timer has the interrupt not acked.

After this i understand that now are my problems.
Do you know somebody that can help me understanding the problem only for 
xenomai side?
We can accept a quotation of work.

Thanks for all


information and if you

Il 18/04/2012 11:19, Gilles Chanteperdrix ha scritto:
> On 04/18/2012 10:44 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> here find the answers.
>> sorry for the delay.
>>
>> Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto:
>>> On 04/13/2012 10:44 AM, Roberto Bielli wrote:
>>>> Hi Gilles,
>>>>
>>>> you don't feel like to repeat.
>>>> I'm trying all the things that you told me and i will do all the missing
>>>> test that you told me.
>>> So, what is the result of running your test with unpatched Linux, but
>>> with CONFIG_HIGH_RES_TIMERS enabled?
>> the result is the same.
>> With the base linux application and  CONFIG_HIGH_RES_TIMERS all it's ok,
>> instead with xenomai application the task with less priority halt the
>> task with higher priority until it sleeps.
>> I send you my .config file and the test with pthread base.
> You know as well as me that this description of the problem is
> inaccurate, what really happens is that the timer is programmed but does
> not tick. What you have to do now is try and understand what is the
> difference between the way xenomai and linux handle the timer to
> understand what cause it not to work in xenomai case. If I were you, to
> understand this difference, I would start by dumping all timer registers
> values at the time when the problem is detected, that is, before the
> timer is programmed again. But I am afraid I can not give you more help,
> ultimately you are the one which is doing the port to imx25, so you are
> on your own.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/18/2012 12:28 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try to give only another accurate information.
> 
> i made another test:
> i write a xenomai driver for reading the timer and avic register and i 
> see a strange behaviour.
> when there is the problem the interrupt is NOT masqueraded in avic but 
> the timer has the interrupt not acked.

Ah, that is good news, at least now we have a clue. Note that it could
also mean that the timer has ticked, but the irq is not generated for
another reason. I think you should dump all the timer registers, and see
if anything is wrong by decoding their values with the datasheet.

A quick test also, assuming that the write to the MX3_TSTAT regiter in
gpt_irq_acknowledge may be posted, try rereading the register after
writing it.

> 
> After this i understand that now are my problems.
> Do you know somebody that can help me understanding the problem only for 
> xenomai side?

If you need someone's help, you need to give access to your board to
that person or company. Because indirect debugging is really
inefficient: look at how many mails I had to send you over how much time
to get you to do what anybody with xenomai experience would have done in
just a few hours.

-- 
                                                                Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

Hi Gilles,

i found the problem that disable interrupts when execute a task.
My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config.
This properties enable reentrant interrupts so it uses the NIMASK(normal 
interrupt mask register ) register to disable interrupts with
certain priority level. The interrupt of timer is disabled in that cases.
i tried to disable this option in the kernel but i have other big 
problems with the task and so i have to do other tests before saying the 
conclusions.

Do you know if xenomai doesn't work with reentrant interrupts ?





Il 18/04/2012 13:51, Gilles Chanteperdrix ha scritto:
> On 04/18/2012 12:28 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i try to give only another accurate information.
>>
>> i made another test:
>> i write a xenomai driver for reading the timer and avic register and i
>> see a strange behaviour.
>> when there is the problem the interrupt is NOT masqueraded in avic but
>> the timer has the interrupt not acked.
> Ah, that is good news, at least now we have a clue. Note that it could
> also mean that the timer has ticked, but the irq is not generated for
> another reason. I think you should dump all the timer registers, and see
> if anything is wrong by decoding their values with the datasheet.
>
> A quick test also, assuming that the write to the MX3_TSTAT regiter in
> gpt_irq_acknowledge may be posted, try rereading the register after
> writing it.
>
>> After this i understand that now are my problems.
>> Do you know somebody that can help me understanding the problem only for
>> xenomai side?
> If you need someone's help, you need to give access to your board to
> that person or company. Because indirect debugging is really
> inefficient: look at how many mails I had to send you over how much time
> to get you to do what anybody with xenomai experience would have done in
> just a few hours.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 10:52 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i found the problem that disable interrupts when execute a task.
> My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config.
> This properties enable reentrant interrupts so it uses the NIMASK(normal 
> interrupt mask register ) register to disable interrupts with
> certain priority level. The interrupt of timer is disabled in that cases.
> i tried to disable this option in the kernel but i have other big 
> problems with the task and so i have to do other tests before saying the 
> conclusions.
> 
> Do you know if xenomai doesn't work with reentrant interrupts ?

Xenomai as it is will not work in that case, and this option is useless
as all interrupts handlers are executed with hardware irqs disabled, so
your best solution is to try and disable this option.

-- 
                                                                Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Roberto Bielli]

have you a .config for imx31 to give me so i can compare them?

Il 19/04/2012 10:54, Gilles Chanteperdrix ha scritto:
> On 04/19/2012 10:52 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i found the problem that disable interrupts when execute a task.
>> My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config.
>> This properties enable reentrant interrupts so it uses the NIMASK(normal
>> interrupt mask register ) register to disable interrupts with
>> certain priority level. The interrupt of timer is disabled in that cases.
>> i tried to disable this option in the kernel but i have other big
>> problems with the task and so i have to do other tests before saying the
>> conclusions.
>>
>> Do you know if xenomai doesn't work with reentrant interrupts ?
> Xenomai as it is will not work in that case, and this option is useless
> as all interrupts handlers are executed with hardware irqs disabled, so
> your best solution is to try and disable this option.
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 11:01 AM, Roberto Bielli wrote:
> have you a .config for imx31 to give me so i can compare them?

http://sisyphus.hd.free.fr/~gilles/config-mx31ads-2.6.33

This said, looking at the code, I do not understand how it can break irq
delivery.

-- 
                                                                Gilles.

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 11:02 AM, Gilles Chanteperdrix wrote:
> On 04/19/2012 11:01 AM, Roberto Bielli wrote:
>> have you a .config for imx31 to give me so i can compare them?
> 
> http://sisyphus.hd.free.fr/~gilles/config-mx31ads-2.6.33
> 
> This said, looking at the code, I do not understand how it can break irq
> delivery.

I understand it now, yes, CONFIG_IMX_IRQ_PRIOR can not work with
CONFIG_IPIPE.

-- 
					    Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/12/2012 12:12 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i found in my trace the function 'xnthread_timeout_handler' that is 
> called in the code where there is the problem.
> In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?] 
> stalled xeno domain 
> <http://www.opensubscriber.com/messages/xenomai@xenomai.org> )
> 
> Do you think that can be a similar problem ?

No.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.
> So a task with lower priority is interrupted by timer interrupt and 
> reschedule the task with higher priority.
> 
You need CONFIG_HIGH_RES_TIMERS to be in the same case as xenomai.

-- 
                                                                Gilles.

Re: [Xenomai-core] preemptive doesn't work

[Roberto Bielli]

Hi Gilles,

the steps for supporting imx25 have been:
1. We buy a board with imx25
2. Our supplier made the porting of linux 2.6.31 freescale with  imx25
3. we put a xenomai  2.5.6 and we have adapted for imx25. The only 
changes is this (because imx25 registers are identical to mx3 ):

old:
#define timer_is_v2()    (cpu_is_mx3() || cpu_is_mx5())

new:
#define timer_is_v2()    (cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())





Il 10/04/2012 11:06, Gilles Chanteperdrix ha scritto:
> On 04/10/2012 10:58 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i look at the processor errata but for the imx25 there are no errata
>> elements on timer.
> It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
> support imx25.
>
> The I-pipe support has not been written for imx25, so, it is entirely
> possible that you have to adapt it. See:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting
>


-- 
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   roberto.bielli@domain.hid	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: info@domain.hid

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:19 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> the steps for supporting imx25 have been:
> 1. We buy a board with imx25
> 2. Our supplier made the porting of linux 2.6.31 freescale with  imx25
> 3. we put a xenomai  2.5.6 and we have adapted for imx25. The only 
> changes is this (because imx25 registers are identical to mx3 ):
> 
> old:
> #define timer_is_v2()    (cpu_is_mx3() || cpu_is_mx5())
> 
> new:
> #define timer_is_v2()    (cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())
> 

Yes, but if you use the unchanged adeos patch, it uses if (cpu_is_mx3())
in tsc and timer code, whereas it should use if (timer_is_v2()),
timer_is_v2 is not present in vanilla linux code.

-- 
                                                                Gilles.