Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Michel He]

Still not working after reactivation of Timer 3. Here's the codes :


/*
  * Set up timer interrupt.
  *
  * Currently we use timer4 as event timer and timer3 as tick counter which
  * permanently counts ticks without interrupt generation.
  */
static void s3c2410_timer_setup (void)
{
         unsigned long tcon;
         unsigned long tcnt;
         unsigned long tcfg1;
         unsigned long tcfg0;
	unsigned long intmask;

         tcnt = TICK_MAX;  /* default value for tcnt */

         /* configure the system for whichever machine is in use */

         if (use_tclk1_12()) {
                 /* timer is at 12MHz, scaler is 1 */
                 timer_usec_ticks = timer_mask_usec_ticks(1, 12000000);
                 tcnt = 12000000 / HZ;

		tcfg1 = __raw_readl(S3C2410_TCFG1);
		tcfg1 &= ~S3C2410_TCFG1_MUX4_MASK;
		tcfg1 |= S3C2410_TCFG1_MUX4_TCLK1;
		__raw_writel(tcfg1, S3C2410_TCFG1);

		/* timer 3 */

		tcfg1 = __raw_readl(S3C2410_TCFG1);
		tcfg1 &= ~S3C2410_TCFG1_MUX3_MASK;
		tcfg1 |= S3C2410_TCFG1_MUX3_TCLK1;
		__raw_writel(tcfg1, S3C2410_TCFG1);


         } else {
                 unsigned long pclk;
                 struct clk *tscaler;

                 /* for the h1940 (and others), we use the pclk from the core
                  * to generate the timer values. since values around 50 to
                  * 70MHz are not values we can directly generate the timer
                  * value from, we need to pre-scale and divide before  
using it.
                  *
                  * for instance, using 50.7MHz and dividing by 6 gives 8.45MHz
                  * (8.45 ticks per usec)
                  */
                 pclk = clk_get_rate(timerclk);

                 /* configure clock tick */

                 timer_usec_ticks = timer_mask_usec_ticks(6, pclk);

                 tscaler = clk_get_parent(tdiv);

                 clk_set_rate(tscaler, pclk / 3);
                 clk_set_rate(tdiv, pclk / 6);
                 clk_set_parent(tin, tdiv);

                 tcnt = clk_get_rate(tin) / HZ;

		/* timer 3 */
		tcfg1 = __raw_readl(S3C2410_TCFG1);
		tcfg1 &= ~S3C2410_TCFG1_MUX3_MASK;
		tcfg1 |= S3C2410_TCFG1_MUX3_TCLK1;
		__raw_writel(tcfg1, S3C2410_TCFG1);


         }

         tcon = __raw_readl(S3C2410_TCON);
         tcfg0 = __raw_readl(S3C2410_TCFG0);
         tcfg1 = __raw_readl(S3C2410_TCFG1);

#ifdef CONFIG_IPIPE
	tsc = (unsigned long long *)__ipipe_tsc_area;
	last_cnt = (unsigned *)(tsc + 1);		/* means: +8 bytes */
	barrier();

	__ipipe_mach_ticks_per_jiffy = tcnt;
#endif /* CONFIG_IPIPE */

	/* timers reload after counting zero, so reduce the count by 1 */

	tcnt--;

	printk(KERN_DEBUG "timer tcon=%08lx, tcnt %04lx, tcfg %08lx,%08lx,  
usec %08lx\n",
	       tcon, tcnt, tcfg0, tcfg1, timer_usec_ticks);

	/* check to see if timer is within 16bit range... */
	if (tcnt > TICK_MAX) {
		panic("setup_timer: HZ is too small, cannot configure timer!");
		return;
	}

	__raw_writel(tcfg1, S3C2410_TCFG1);
	__raw_writel(tcfg0, S3C2410_TCFG0);


	/* ensure timer stopped... */

	//tcon &= ~(7<<20);
	tcon &= ~(0x3f<<17);
	free_running_tcon = tcon |  S3C2410_TCON_T3RELOAD | S3C2410_TCON_T3START;

	tcon |= S3C2410_TCON_T4RELOAD;
	tcon |= S3C2410_TCON_T4MANUALUPD;

	__raw_writel(tcon, S3C2410_TCON);
	__raw_writel(tcnt, S3C2410_TCNTB(4));
	__raw_writel(tcnt, S3C2410_TCMPB(4));

	/* start the timer 4 */
	tcon |= S3C2410_TCON_T4START;
	tcon &= ~S3C2410_TCON_T4MANUALUPD;
	__raw_writel(tcon, S3C2410_TCON);

	/* timer 3 */
	tcon |= S3C2410_TCON_T3RELOAD;
	tcon |= S3C2410_TCON_T3MANUALUPD;

	/* Mask timer3 interrupt. */
	intmask = __raw_readl(S3C2410_INTMSK);
	intmask |= 1UL << (IRQ_TIMER3 - IRQ_EINT0);
	__raw_writel(intmask, S3C2410_INTMSK);

	__raw_writel(tcon, S3C2410_TCON);
	__raw_writel(0xffff, S3C2410_TCNTB(3));
	__raw_writel(0xffff, S3C2410_TCMPB(3));

	/* start the timer 3 */
	tcon |= S3C2410_TCON_T3START;
	//tcon &= ~S3C2410_TCON_T3MANUALUPD;
	__raw_writel(tcon, S3C2410_TCON);

	last_free_running_tcnt = 0xffff;
}



The system boot shows :
......
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
yaffs: dev is 32505859 name is "mtdblock3"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.3, "mtdblock3"
block 191 is bad
block 651 is bad
yaffs_read_super: isCheckpointed 0
VFS: Mounted root (yaffs2 filesystem) on device 31:3.
Freeing init memory: 112K
Warning: unable to open an initial console.
<-----   stucked here ----->


thank you for your advice.



Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> a écrit :

> Michel He wrote:
>> Hello Gilles,
>>
>>    I read out on your site that issue regarding to the adeos port of S3C
>> comes from the Timer. Here the problem is Timer 3, which has been
>> already reserved by the sound driver (maybe also other drivers). So I
>> did some slight changes in arch/arm/plat-s3c/time.c to get rid of it
>> (actually not knowing the real utility of it), and Adeos get going on.
>> Adeos seems to be working without Xenomai. So I reactivate Xenomai in
>> the Kernel.
>>
>>   However again it's stucked in the FrameBuffer (S3C) and the Ethernet
>> (dm9000) initializations. I make the FrameBuffer desactivated. We need
>> the networking, the Ethernet is now the problem :
>>
>> TCP cubic registered
>> NET: Registered protocol family 17
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> <----- kernel stucked  here ------>
>> if passed, it should show that :
>> eth0: link down
>> IP-Config: Complete:...
>>
>>
>> Thank you for your advice.
>
> Actually, xenomai needs a hardware timer. So, if you removed timer 3
> without using something else instead, it is normal that the system is
> not working.
>
>>
>>
>
>
> --
> Gilles Chanteperdrix, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Gilles Chanteperdrix]

Michel He wrote:
> Still not working after reactivation of Timer 3. Here's the codes :

Well, if timer 3 is used by another driver in the system, no wonder that
it does not work. You will not get it to work by just changing a few
things here and there. You have to actually understand what is needed
and fix the implementation (probably to use another timer). Fortunately,
you have the I-pipe porting guide to arm to understand what is needed.


-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Michel He]

How can I exactly figure out which driver is using the Timer 3 ? I  
wonder if there's a list of interrupt somewhere ? in irq.c ->  
watch-dog and ac97, Both are disactivated from the kernel.



Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> a écrit :

> Michel He wrote:
>> Still not working after reactivation of Timer 3. Here's the codes :
>
> Well, if timer 3 is used by another driver in the system, no wonder that
> it does not work. You will not get it to work by just changing a few
> things here and there. You have to actually understand what is needed
> and fix the implementation (probably to use another timer). Fortunately,
> you have the I-pipe porting guide to arm to understand what is needed.
>
>
> --
> Gilles Chanteperdrix, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Gilles Chanteperdrix]

Michel He wrote:
> How can I exactly figure out which driver is using the Timer 3 ? I  
> wonder if there's a list of interrupt somewhere ? in irq.c ->  
> watch-dog and ac97, Both are disactivated from the kernel.

You are the one who mentioned timer 3 in the first place, but if no
other code than the I-pipe uses it then, that is not your problem. You
have basically no way of knowing that two drivers are accessing the same
hardware registers. Only code inspection cal tell you that.

Please stop top-posting, it makes things really hard to follow for those
who read us.


-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Michel He]

ok, thanks for help as far as concerned the S3C2440 issues on that board.

So what has been previously found out is: no external clock connected  
on pin clk1 of timer 3, instead timer 2 and 3 are used to drive the  
sound module. Since I get changed the timer 3 to timer 1, it can boot  
to shell. However, the xenomai test give a 7000 us of average latency,  
it is even worst than pure Linux system. Also, the USB, nor the camera  
won't work at all (the system get freezed when plug them in). The UART  
and LCD are OK. The sound is buggy due to lags, it seems the buffer  
not continuously filled up by linux. So far the others modules are not  
tested.

Something should get wrong, but no idea how to figure it out.

Michel He <michel.he@domain.hid> a écrit :

> How can I exactly figure out which driver is using the Timer 3 ? I  
> wonder if there's a list of interrupt somewhere ? in irq.c ->  
> watch-dog and ac97, Both are disactivated from the kernel.
>
>
>
> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> a écrit :
>
>> Michel He wrote:
>>> Still not working after reactivation of Timer 3. Here's the codes :
>>
>> Well, if timer 3 is used by another driver in the system, no wonder that
>> it does not work. You will not get it to work by just changing a few
>> things here and there. You have to actually understand what is needed
>> and fix the implementation (probably to use another timer). Fortunately,
>> you have the I-pipe porting guide to arm to understand what is needed.
>>
>>
>> --
>> Gilles Chanteperdrix, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
>>
>
>

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Gilles Chanteperdrix]

Michel He wrote:
> ok, thanks for help as far as concerned the S3C2440 issues on that board.
> 
> So what has been previously found out is: no external clock connected  
> on pin clk1 of timer 3, instead timer 2 and 3 are used to drive the  
> sound module. Since I get changed the timer 3 to timer 1, it can boot  
> to shell. However, the xenomai test give a 7000 us of average latency,  
> it is even worst than pure Linux system. Also, the USB, nor the camera  
> won't work at all (the system get freezed when plug them in). The UART  
> and LCD are OK. The sound is buggy due to lags, it seems the buffer  
> not continuously filled up by linux. So far the others modules are not  
> tested.
> 
> Something should get wrong, but no idea how to figure it out.

The timer issue you had should have been fixed in the latest I-pipe
versions. Could you try Xenomai 2.5.3 and one of the I-pipe patch it
contains and see if it has the same latencies issues?

-- 
					    Gilles.

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Michel He]

Hello Gilles,

    I just tested the latest I-pipe with Xenomai versions 2.5.3. So  
the average latency 7000 us has slightly been improved. It is now  
about 4000 us, that's too much for servo motor controlling. The  
S3C2410 PWM divider is 1/2 (this is the minimum) and the prescalar is  
set to 0 (no shift)...

Bye !

Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> a écrit :

> Michel He wrote:
>> ok, thanks for help as far as concerned the S3C2440 issues on that board.
>>
>> So what has been previously found out is: no external clock connected
>> on pin clk1 of timer 3, instead timer 2 and 3 are used to drive the
>> sound module. Since I get changed the timer 3 to timer 1, it can boot
>> to shell. However, the xenomai test give a 7000 us of average latency,
>> it is even worst than pure Linux system. Also, the USB, nor the camera
>> won't work at all (the system get freezed when plug them in). The UART
>> and LCD are OK. The sound is buggy due to lags, it seems the buffer
>> not continuously filled up by linux. So far the others modules are not
>> tested.
>>
>> Something should get wrong, but no idea how to figure it out.
>
> The timer issue you had should have been fixed in the latest I-pipe
> versions. Could you try Xenomai 2.5.3 and one of the I-pipe patch it
> contains and see if it has the same latencies issues?
>
> --
> 					    Gilles.
>

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Gilles Chanteperdrix]

Michel He wrote:
> Hello Gilles,
> 
>     I just tested the latest I-pipe with Xenomai versions 2.5.3. So  
> the average latency 7000 us has slightly been improved. It is now  
> about 4000 us, that's too much for servo motor controlling. The  
> S3C2410 PWM divider is 1/2 (this is the minimum) and the prescalar is  
> set to 0 (no shift)...

Obviously, there is an issue with your setup, drivers, or kernel because
Xenomai runs on similar ARMs with latencies under 300us, and under 100us
for more powerful processors.

So, if you are interested in running Xenomai, you will have to find
where the latencies come from. I would advise you to use the I-pipe
tracer, but I am afraid it is broken on ARM since the tracer was rebased
on Linux' tracing infrastructure, so, your best luck is with
instrumenting the code.

-- 
					    Gilles.

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Gilles Chanteperdrix]

Michel He wrote:
> Ok, just updated from 2.6.30.1 to 2.6.30.3, everything back to normal,  
> under 100 us. but the mystery remains entire.

Please no private messages.

You should really investigate the situation where you had big latencies.
Are you sure you are using exactly the same kernel configuration for the
two setups?

-- 
					    Gilles.

Re: [Xenomai-help] Mini2440 on the kernel 2.6.30.1

[Michel He]

Yes, absolutely sure. It's the same .config

Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> a écrit :

> Michel He wrote:
>> Ok, just updated from 2.6.30.1 to 2.6.30.3, everything back to normal,
>> under 100 us. but the mystery remains entire.
>
> Please no private messages.
>
> You should really investigate the situation where you had big latencies.
> Are you sure you are using exactly the same kernel configuration for the
> two setups?
>
> --
> 					    Gilles.
>