[Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Henri Roosen]

Hi,

I'm trying to bringup Xenomai 2.4.9.1 on a freescale iMX25 board and
linux kernel 2.6.28. Until now all was straightforward by following
the ArmPorting page on the Xenomai website and because the iMX25 is
very similar to the already supported iMX3. The kernel boots and the
xenomai timer is running.

However the testsuite apps (latency) are not working because the
rt_timer_tsc() call results in a Bus error: 'Unhandled fault: external
abort on non-linefetch (0x008) at 0x4001f024)'.

I verified at the xeno_arm_features_check() call the physical address
of the GPT1 counter register is correct (0x53f90024 which matches the
datasheet). The mmap call succeeds and the virtual address is at
0x4001f024. However, when de-referencing that pointer in the
__xn_rdtsc() call the bus error occurs.

Anyone have an idea what I am missing?

Thanks,
Henri

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Gilles Chanteperdrix]

Henri Roosen wrote:
> Hi,
> 
> I'm trying to bringup Xenomai 2.4.9.1 on a freescale iMX25 board and
> linux kernel 2.6.28. Until now all was straightforward by following
> the ArmPorting page on the Xenomai website and because the iMX25 is
> very similar to the already supported iMX3. The kernel boots and the
> xenomai timer is running.
> 
> However the testsuite apps (latency) are not working because the
> rt_timer_tsc() call results in a Bus error: 'Unhandled fault: external
> abort on non-linefetch (0x008) at 0x4001f024)'.
> 
> I verified at the xeno_arm_features_check() call the physical address
> of the GPT1 counter register is correct (0x53f90024 which matches the
> datasheet). The mmap call succeeds and the virtual address is at
> 0x4001f024. However, when de-referencing that pointer in the
> __xn_rdtsc() call the bus error occurs.
> 
> Anyone have an idea what I am missing?

Ok. I have already heard about that, and have not yet had time to
investigate it. However, I have seen in the kernel configuration which
restricts the access to /dev/mem, would you have such an option enabled?

Could you send me your .config ?

-- 
                                          Gilles

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Henri Roosen]

Hi Gilles,

I found the problem.

There seems to be a sw-workaround needed to access the peripherals in
user-mode. It is implemented in cpu.c, which the bsp for the iMX25 did
not have, but the iMX3 has. I implemented the post_cpu_init() call for
the iMX25 and now the access is fine.

Thanks for your reply!

On Wed, Oct 28, 2009 at 4:19 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Henri Roosen wrote:
>> Hi Gilles,
>>
>> Thanks for the quick response! Please find attached the .config
>
> Ok. I can not find anything about /dev/mem in the kernel configuration.
> I wonder where I saw this.
>
> If you are sure that the physical address is correct, then maybe the MMU
> parameter are incorrect. In xeno_arm_features_check, could you try to
> open /dev/mem without the O_SYNC flag, and see if it does not change
> anything ?
>
> If it does not work, I am afraid you will have to configure Xenomai
> user-space with --enable-arm-mach=generic, in which case the tsc
> emulation in user-space will be disabled.
>
> --
>                                          Gilles
>
>

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Gilles Chanteperdrix]

Henri Roosen wrote:
> Hi Gilles,
> 
> I found the problem.
> 
> There seems to be a sw-workaround needed to access the peripherals in
> user-mode. It is implemented in cpu.c, which the bsp for the iMX25 did
> not have, but the iMX3 has. I implemented the post_cpu_init() call for
> the iMX25 and now the access is fine.
> 
> Thanks for your reply!

Could you send me a patch? We will put this in the I-pipe patch.

-- 
                                          Gilles

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Henri Roosen]

This code is part of the iMX25 bsp that is not part of any kernel yet,
so generating a patch is not possible. Seems the upcoming 2.6.32
kernel will have support for iMX25, but the -rc5 still has
build-failures for this platform.

Maybe the complete BSP with ipipe for the iMX25 and 2.6.28 kernel
might be interesting for release (similar as the patch
ipipe-2.6.26-mxc.diff), but is still in an early development state:
now the latency app runs I see it runs fine only for a few minutes and
then gets overruns... asks for debugging ;-)

Please let me know if someone is interested to co-develop this bsp with Xenomai.

Henri

On Wed, Oct 28, 2009 at 4:28 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Henri Roosen wrote:
>> Hi Gilles,
>>
>> I found the problem.
>>
>> There seems to be a sw-workaround needed to access the peripherals in
>> user-mode. It is implemented in cpu.c, which the bsp for the iMX25 did
>> not have, but the iMX3 has. I implemented the post_cpu_init() call for
>> the iMX25 and now the access is fine.
>>
>> Thanks for your reply!
>
> Could you send me a patch? We will put this in the I-pipe patch.
>
> --
>                                          Gilles
>
>

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Gilles Chanteperdrix]

Henri Roosen wrote:
> This code is part of the iMX25 bsp that is not part of any kernel yet,
> so generating a patch is not possible. Seems the upcoming 2.6.32
> kernel will have support for iMX25, but the -rc5 still has
> build-failures for this platform.

Ok. But could you point me to the code in the mach-mx3 tree? I do not
find any cpu.c. The Denx Qong box probably has the same issue as imx25,
and I would be interested in fixing it.

> 
> Maybe the complete BSP with ipipe for the iMX25 and 2.6.28 kernel
> might be interesting for release (similar as the patch
> ipipe-2.6.26-mxc.diff), but is still in an early development state:
> now the latency app runs I see it runs fine only for a few minutes and
> then gets overruns... asks for debugging ;-)

Ok. You can try and use the I-pipe tracer. And make sure to run latency
-p 1000. I can have a look at your I-pipe code to see if I do not see
anything obvious.

-- 
                                          Gilles

Re: [Xenomai-help] Read TSC results in bus error (ARM iMX25)

[Henri Roosen]

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

On Wed, Oct 28, 2009 at 5:42 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Henri Roosen wrote:
>> This code is part of the iMX25 bsp that is not part of any kernel yet,
>> so generating a patch is not possible. Seems the upcoming 2.6.32
>> kernel will have support for iMX25, but the -rc5 still has
>> build-failures for this platform.
>
> Ok. But could you point me to the code in the mach-mx3 tree? I do not
> find any cpu.c. The Denx Qong box probably has the same issue as imx25,
> and I would be interested in fixing it.
>

Ok, now I noticed the cpu.c file is part of the bsp patches I put over
the 2.8.28 vanilla kernel. Please find it attached to this email. What
you are looking for is the s/w workaround part of post_cpu_init, which
removes the Supervisor mode protect bit from the AIPS.

>>
>> Maybe the complete BSP with ipipe for the iMX25 and 2.6.28 kernel
>> might be interesting for release (similar as the patch
>> ipipe-2.6.26-mxc.diff), but is still in an early development state:
>> now the latency app runs I see it runs fine only for a few minutes and
>> then gets overruns... asks for debugging ;-)
>
> Ok. You can try and use the I-pipe tracer. And make sure to run latency
> -p 1000. I can have a look at your I-pipe code to see if I do not see
> anything obvious.

I run with period 1000 already and will use the I-pipe tracer tomorrow
and see if I can find anything. Then your offer to have a look at the
I-pipe code is highly appreciated!

Thanks,
Henri

>
> --
>                                          Gilles
>
>

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

/*
 *  Copyright (C) 2001 Deep Blue Solutions Ltd.
 *  Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 */

/*!
 * @file mach-mx3/cpu.c
 *
 * @brief This file contains the CPU initialization code.
 *
 * @ingroup MSL_MX31
 */

#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <mach/hardware.h>
#include <linux/io.h>
#include <asm/hardware/cache-l2x0.h>

/*!
 * CPU initialization. It is called by fixup_mxc_board()
 */
void __init mxc_cpu_init(void)
{
	/* Setup Peripheral Port Remap register for AVIC */
	asm("ldr r0, =0xC0000015				\n\
	 mcr p15, 0, r0, c15, c2, 4");
	if (!system_rev) {
		mxc_set_system_rev(0x31, CHIP_REV_2_0);
	}
}

/*!
 * Post CPU init code
 *
 * @return 0 always
 */
static int __init post_cpu_init(void)
{
	void *l2_base;
	volatile unsigned long aips_reg;

	/* Initialize L2 cache */
	l2_base = ioremap(L2CC_BASE_ADDR, SZ_4K);
	if (l2_base) {
		l2x0_init(l2_base, 0x00030024, 0x00000000);
	}

	/*
	 * S/W workaround: Clear the off platform peripheral modules
	 * Supervisor Protect bit for SDMA to access them.
	 */
	__raw_writel(0x0, IO_ADDRESS(AIPS1_BASE_ADDR + 0x40));
	__raw_writel(0x0, IO_ADDRESS(AIPS1_BASE_ADDR + 0x44));
	__raw_writel(0x0, IO_ADDRESS(AIPS1_BASE_ADDR + 0x48));
	__raw_writel(0x0, IO_ADDRESS(AIPS1_BASE_ADDR + 0x4C));
	aips_reg = __raw_readl(IO_ADDRESS(AIPS1_BASE_ADDR + 0x50));
	aips_reg &= 0x00FFFFFF;
	__raw_writel(aips_reg, IO_ADDRESS(AIPS1_BASE_ADDR + 0x50));

	__raw_writel(0x0, IO_ADDRESS(AIPS2_BASE_ADDR + 0x40));
	__raw_writel(0x0, IO_ADDRESS(AIPS2_BASE_ADDR + 0x44));
	__raw_writel(0x0, IO_ADDRESS(AIPS2_BASE_ADDR + 0x48));
	__raw_writel(0x0, IO_ADDRESS(AIPS2_BASE_ADDR + 0x4C));
	aips_reg = __raw_readl(IO_ADDRESS(AIPS2_BASE_ADDR + 0x50));
	aips_reg &= 0x00FFFFFF;
	__raw_writel(aips_reg, IO_ADDRESS(AIPS2_BASE_ADDR + 0x50));

	return 0;
}

postcore_initcall(post_cpu_init);