All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
@ 2012-11-23  9:45 WONG Sheng Chao
  2012-11-23  9:58 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-23  9:45 UTC (permalink / raw)
  To: xenomai

Hi

I am trying to get Xenomai working on the beaglebone (AM3359) and I had 
been following the instructions from this mailing list

http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html

The steps that I went through was such

1) I configured the Angstorm distribution with linux kernel 3.2.21 for 
beaglebone using bitbake

2) Copied the kernel source from it and saved it as 
{original_angstrom_kernel}

3) I then ran the patch script from xenomai-2.6.1

$./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm 
--adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch

4) There were four conflicting files, namely

arch/arm/common/gic.c
arch/arm/mach-omap2/irq.c
arch/arm/plat-mxc/gic.c
arch/arm/plat-omap/include/plat/irqs.h

5) I compared these four files to the vanilla linux-kernel-3.2.21 and 
patch these 4 files individually from {original_angstrom_kernel} with 
{vanilla-kernel-3.2.21}. Now i save the newly patched kernel source as 
{pre_patched_original_angstrom_kernel}

6) I ran the prepare-kernel script again with the --linux directed to 
the {pre_patched_original_angstrom_kernel} and the patch went through 
fine. So now i have a copy of i-pipe patched source 
{ipipe_patched_original_angstrom_kernel}

7) I proceed with copying the .config function from 
arch/arm/configs/omap2plus_defconfig and run the make menuconfig with

$make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- menuconfig

and save the kernel configuration

8) i then proceed to compile the kernel with the following command

$make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

9) The compilation fails and it gives the following error

  arch/arm/mach-omap2/devices.c:1096:12: error: 'AM33XX_IRQ_ICSS0_0' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1101:12: error: 'AM33XX_IRQ_ICSS0_1' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1106:12: error: 'AM33XX_IRQ_ICSS0_2' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1111:12: error: 'AM33XX_IRQ_ICSS0_3' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1116:12: error: 'AM33XX_IRQ_ICSS0_4' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1121:12: error: 'AM33XX_IRQ_ICSS0_5' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1126:12: error: 'AM33XX_IRQ_ICSS0_6' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1131:12: error: 'AM33XX_IRQ_ICSS0_7' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1260:12: error: 'AM33XX_IRQ_CPSW_C0_RX' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1260:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1260:3: error: (near initialization for 
'am33xx_cpsw_resources[2].start')
| arch/arm/mach-omap2/devices.c:1261:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1261:3: error: (near initialization for 
'am33xx_cpsw_resources[2].end')
| arch/arm/mach-omap2/devices.c:1265:12: error: 'AM33XX_IRQ_DMTIMER5' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1265:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1265:3: error: (near initialization for 
'am33xx_cpsw_resources[3].start')
| arch/arm/mach-omap2/devices.c:1266:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1266:3: error: (near initialization for 
'am33xx_cpsw_resources[3].end')
| arch/arm/mach-omap2/devices.c:1270:12: error: 'AM33XX_IRQ_DMTIMER6' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1270:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1270:3: error: (near initialization for 
'am33xx_cpsw_resources[4].start')
| arch/arm/mach-omap2/devices.c:1271:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1271:3: error: (near initialization for 
'am33xx_cpsw_resources[4].end')
| arch/arm/mach-omap2/devices.c:1275:12: error: 'AM33XX_IRQ_CPSW_C0' 
undeclared here (not in a function)
| arch/arm/mach-omap2/devices.c:1275:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1275:3: error: (near initialization for 
'am33xx_cpsw_resources[5].start')
| arch/arm/mach-omap2/devices.c:1276:3: error: initializer element is 
not constant
| arch/arm/mach-omap2/devices.c:1276:3: error: (near initialization for 
'am33xx_cpsw_resources[5].end')

I read from this link 
http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html that for 
the kernel to boot properly on the AM3359 two changes needs to be made. 
I had yet to made these changes as i want to see if the kernel source 
would compiled and to verify my steps.

Is my approach correct? Any advice on how to solve this problem?

Thanks in advance!!

Best regards
WONG Sheng Chao





^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23  9:45 [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch WONG Sheng Chao
@ 2012-11-23  9:58 ` Gilles Chanteperdrix
  2012-11-23 12:35   ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-23  9:58 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
> Hi
> 
> I am trying to get Xenomai working on the beaglebone (AM3359) and I had 
> been following the instructions from this mailing list
> 
> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
> 
> The steps that I went through was such
> 
> 1) I configured the Angstorm distribution with linux kernel 3.2.21 for 
> beaglebone using bitbake
> 
> 2) Copied the kernel source from it and saved it as 
> {original_angstrom_kernel}
> 
> 3) I then ran the patch script from xenomai-2.6.1
> 
> $./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm 
> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
> 
> 4) There were four conflicting files, namely
> 
> arch/arm/common/gic.c
> arch/arm/mach-omap2/irq.c
> arch/arm/plat-mxc/gic.c
> arch/arm/plat-omap/include/plat/irqs.h
> 
> 5) I compared these four files to the vanilla linux-kernel-3.2.21 and 
> patch these 4 files individually from {original_angstrom_kernel} with 
> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel source as 
> {pre_patched_original_angstrom_kernel}
> 
> 6) I ran the prepare-kernel script again with the --linux directed to 
> the {pre_patched_original_angstrom_kernel} and the patch went through 
> fine. So now i have a copy of i-pipe patched source 
> {ipipe_patched_original_angstrom_kernel}
> 
> 7) I proceed with copying the .config function from 
> arch/arm/configs/omap2plus_defconfig and run the make menuconfig with
> 
> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- menuconfig
> 
> and save the kernel configuration
> 
> 8) i then proceed to compile the kernel with the following command
> 
> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
> 
> 9) The compilation fails and it gives the following error
> 
>   arch/arm/mach-omap2/devices.c:1096:12: error: 'AM33XX_IRQ_ICSS0_0' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1101:12: error: 'AM33XX_IRQ_ICSS0_1' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1106:12: error: 'AM33XX_IRQ_ICSS0_2' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1111:12: error: 'AM33XX_IRQ_ICSS0_3' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1116:12: error: 'AM33XX_IRQ_ICSS0_4' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1121:12: error: 'AM33XX_IRQ_ICSS0_5' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1126:12: error: 'AM33XX_IRQ_ICSS0_6' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1131:12: error: 'AM33XX_IRQ_ICSS0_7' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1260:12: error: 'AM33XX_IRQ_CPSW_C0_RX' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1260:3: error: (near initialization for 
> 'am33xx_cpsw_resources[2].start')
> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1261:3: error: (near initialization for 
> 'am33xx_cpsw_resources[2].end')
> | arch/arm/mach-omap2/devices.c:1265:12: error: 'AM33XX_IRQ_DMTIMER5' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1265:3: error: (near initialization for 
> 'am33xx_cpsw_resources[3].start')
> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1266:3: error: (near initialization for 
> 'am33xx_cpsw_resources[3].end')
> | arch/arm/mach-omap2/devices.c:1270:12: error: 'AM33XX_IRQ_DMTIMER6' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1270:3: error: (near initialization for 
> 'am33xx_cpsw_resources[4].start')
> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1271:3: error: (near initialization for 
> 'am33xx_cpsw_resources[4].end')
> | arch/arm/mach-omap2/devices.c:1275:12: error: 'AM33XX_IRQ_CPSW_C0' 
> undeclared here (not in a function)
> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1275:3: error: (near initialization for 
> 'am33xx_cpsw_resources[5].start')
> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer element is 
> not constant
> | arch/arm/mach-omap2/devices.c:1276:3: error: (near initialization for 
> 'am33xx_cpsw_resources[5].end')
> 
> I read from this link 
> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html that for 
> the kernel to boot properly on the AM3359 two changes needs to be made. 
> I had yet to made these changes as i want to see if the kernel source 
> would compiled and to verify my steps.
> 
> Is my approach correct? Any advice on how to solve this problem?

There is no correct approach, there is more than one way to do it. Does
the un-patched kernel compile with the .config you use? If yes, does the
patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI disabled?

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23  9:58 ` Gilles Chanteperdrix
@ 2012-11-23 12:35   ` WONG Sheng Chao
  2012-11-23 16:29     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-23 12:35 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>> Hi
>>
>> I am trying to get Xenomai working on the beaglebone (AM3359) and I 
>> had
>> been following the instructions from this mailing list
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>
>> The steps that I went through was such
>>
>> 1) I configured the Angstorm distribution with linux kernel 3.2.21 
>> for
>> beaglebone using bitbake
>>
>> 2) Copied the kernel source from it and saved it as
>> {original_angstrom_kernel}
>>
>> 3) I then ran the patch script from xenomai-2.6.1
>>
>> $./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm
>> 
>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>
>> 4) There were four conflicting files, namely
>>
>> arch/arm/common/gic.c
>> arch/arm/mach-omap2/irq.c
>> arch/arm/plat-mxc/gic.c
>> arch/arm/plat-omap/include/plat/irqs.h
>>
>> 5) I compared these four files to the vanilla linux-kernel-3.2.21 
>> and
>> patch these 4 files individually from {original_angstrom_kernel} 
>> with
>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel source 
>> as
>> {pre_patched_original_angstrom_kernel}
>>
>> 6) I ran the prepare-kernel script again with the --linux directed 
>> to
>> the {pre_patched_original_angstrom_kernel} and the patch went 
>> through
>> fine. So now i have a copy of i-pipe patched source
>> {ipipe_patched_original_angstrom_kernel}
>>
>> 7) I proceed with copying the .config function from
>> arch/arm/configs/omap2plus_defconfig and run the make menuconfig 
>> with
>>
>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- menuconfig
>>
>> and save the kernel configuration
>>
>> 8) i then proceed to compile the kernel with the following command
>>
>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>
>> 9) The compilation fails and it gives the following error
>>
>>   arch/arm/mach-omap2/devices.c:1096:12: error: 'AM33XX_IRQ_ICSS0_0'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1101:12: error: 'AM33XX_IRQ_ICSS0_1'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1106:12: error: 'AM33XX_IRQ_ICSS0_2'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1111:12: error: 'AM33XX_IRQ_ICSS0_3'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1116:12: error: 'AM33XX_IRQ_ICSS0_4'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1121:12: error: 'AM33XX_IRQ_ICSS0_5'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1126:12: error: 'AM33XX_IRQ_ICSS0_6'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1131:12: error: 'AM33XX_IRQ_ICSS0_7'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1260:12: error: 
>> 'AM33XX_IRQ_CPSW_C0_RX'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[2].start')
>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[2].end')
>> | arch/arm/mach-omap2/devices.c:1265:12: error: 
>> 'AM33XX_IRQ_DMTIMER5'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[3].start')
>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[3].end')
>> | arch/arm/mach-omap2/devices.c:1270:12: error: 
>> 'AM33XX_IRQ_DMTIMER6'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[4].start')
>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[4].end')
>> | arch/arm/mach-omap2/devices.c:1275:12: error: 'AM33XX_IRQ_CPSW_C0'
>> undeclared here (not in a function)
>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[5].start')
>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer element 
>> is
>> not constant
>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near initialization 
>> for
>> 'am33xx_cpsw_resources[5].end')
>>
>> I read from this link
>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html that 
>> for
>> the kernel to boot properly on the AM3359 two changes needs to be 
>> made.
>> I had yet to made these changes as i want to see if the kernel 
>> source
>> would compiled and to verify my steps.
>>
>> Is my approach correct? Any advice on how to solve this problem?
>
> There is no correct approach, there is more than one way to do it. 
> Does
> the un-patched kernel compile with the .config you use? If yes, does 
> the
> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI disabled?


Sorry about the private reply Gilles, I clicked the reply button 
instead of reply all.


The un-patched kernel compile fine with the original .config.

The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI disable 
shows the same compilation error as before.

Following the information from here and looking at the error code

http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#The_general_case

I had a look at arch/arm/mach-omap2/Kconfig and i found this snippet, 
but I am not sure how to proceed from here.

config SOC_OMAPAM33XX
	bool "AM33XX support"
	depends on ARCH_OMAP3
	default y

I will attach my .config for reference
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121123/bd50cea1/attachment.ksh>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23 12:35   ` WONG Sheng Chao
@ 2012-11-23 16:29     ` Gilles Chanteperdrix
  2012-11-23 17:22       ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-23 16:29 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/23/2012 01:35 PM, WONG Sheng Chao wrote:
> On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
>> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>>> Hi
>>>
>>> I am trying to get Xenomai working on the beaglebone (AM3359) and I 
>>> had
>>> been following the instructions from this mailing list
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>
>>> The steps that I went through was such
>>>
>>> 1) I configured the Angstorm distribution with linux kernel 3.2.21 
>>> for
>>> beaglebone using bitbake
>>>
>>> 2) Copied the kernel source from it and saved it as
>>> {original_angstrom_kernel}
>>>
>>> 3) I then ran the patch script from xenomai-2.6.1
>>>
>>> $./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm
>>>
>>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>>
>>> 4) There were four conflicting files, namely
>>>
>>> arch/arm/common/gic.c
>>> arch/arm/mach-omap2/irq.c
>>> arch/arm/plat-mxc/gic.c
>>> arch/arm/plat-omap/include/plat/irqs.h
>>>
>>> 5) I compared these four files to the vanilla linux-kernel-3.2.21 
>>> and
>>> patch these 4 files individually from {original_angstrom_kernel} 
>>> with
>>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel source 
>>> as
>>> {pre_patched_original_angstrom_kernel}
>>>
>>> 6) I ran the prepare-kernel script again with the --linux directed 
>>> to
>>> the {pre_patched_original_angstrom_kernel} and the patch went 
>>> through
>>> fine. So now i have a copy of i-pipe patched source
>>> {ipipe_patched_original_angstrom_kernel}
>>>
>>> 7) I proceed with copying the .config function from
>>> arch/arm/configs/omap2plus_defconfig and run the make menuconfig 
>>> with
>>>
>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- menuconfig
>>>
>>> and save the kernel configuration
>>>
>>> 8) i then proceed to compile the kernel with the following command
>>>
>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>>
>>> 9) The compilation fails and it gives the following error
>>>
>>>   arch/arm/mach-omap2/devices.c:1096:12: error: 'AM33XX_IRQ_ICSS0_0'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1101:12: error: 'AM33XX_IRQ_ICSS0_1'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1106:12: error: 'AM33XX_IRQ_ICSS0_2'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1111:12: error: 'AM33XX_IRQ_ICSS0_3'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1116:12: error: 'AM33XX_IRQ_ICSS0_4'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1121:12: error: 'AM33XX_IRQ_ICSS0_5'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1126:12: error: 'AM33XX_IRQ_ICSS0_6'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1131:12: error: 'AM33XX_IRQ_ICSS0_7'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1260:12: error: 
>>> 'AM33XX_IRQ_CPSW_C0_RX'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[2].start')
>>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[2].end')
>>> | arch/arm/mach-omap2/devices.c:1265:12: error: 
>>> 'AM33XX_IRQ_DMTIMER5'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[3].start')
>>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[3].end')
>>> | arch/arm/mach-omap2/devices.c:1270:12: error: 
>>> 'AM33XX_IRQ_DMTIMER6'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[4].start')
>>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[4].end')
>>> | arch/arm/mach-omap2/devices.c:1275:12: error: 'AM33XX_IRQ_CPSW_C0'
>>> undeclared here (not in a function)
>>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[5].start')
>>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer element 
>>> is
>>> not constant
>>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near initialization 
>>> for
>>> 'am33xx_cpsw_resources[5].end')
>>>
>>> I read from this link
>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html that 
>>> for
>>> the kernel to boot properly on the AM3359 two changes needs to be 
>>> made.
>>> I had yet to made these changes as i want to see if the kernel 
>>> source
>>> would compiled and to verify my steps.
>>>
>>> Is my approach correct? Any advice on how to solve this problem?
>>
>> There is no correct approach, there is more than one way to do it. 
>> Does
>> the un-patched kernel compile with the .config you use? If yes, does 
>> the
>> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI disabled?
> 
> 
> Sorry about the private reply Gilles, I clicked the reply button 
> instead of reply all.
> 
> 
> The un-patched kernel compile fine with the original .config.
> 
> The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI disable 
> shows the same compilation error as before.

This looks like an error due to some changes made by the I-pipe patch to
the include files. In order to debug this, you have to simply
pre-process the file, and try and understand what happens. If at the top
of the build tree, you run "make arch/arm/mach-omap2/devices.i" with the
proper make variables set, the kernel makefile should generate the
pre-processed file.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23 16:29     ` Gilles Chanteperdrix
@ 2012-11-23 17:22       ` WONG Sheng Chao
  2012-11-23 17:45         ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-23 17:22 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Fri, 23 Nov 2012 17:29:02 +0100, Gilles Chanteperdrix wrote:
> On 11/23/2012 01:35 PM, WONG Sheng Chao wrote:
>> On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
>>> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>>>> Hi
>>>>
>>>> I am trying to get Xenomai working on the beaglebone (AM3359) and 
>>>> I
>>>> had
>>>> been following the instructions from this mailing list
>>>>
>>>> 
>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>
>>>> The steps that I went through was such
>>>>
>>>> 1) I configured the Angstorm distribution with linux kernel 3.2.21
>>>> for
>>>> beaglebone using bitbake
>>>>
>>>> 2) Copied the kernel source from it and saved it as
>>>> {original_angstrom_kernel}
>>>>
>>>> 3) I then ran the patch script from xenomai-2.6.1
>>>>
>>>> $./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm
>>>>
>>>> 
>>>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>>>
>>>> 4) There were four conflicting files, namely
>>>>
>>>> arch/arm/common/gic.c
>>>> arch/arm/mach-omap2/irq.c
>>>> arch/arm/plat-mxc/gic.c
>>>> arch/arm/plat-omap/include/plat/irqs.h
>>>>
>>>> 5) I compared these four files to the vanilla linux-kernel-3.2.21
>>>> and
>>>> patch these 4 files individually from {original_angstrom_kernel}
>>>> with
>>>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel 
>>>> source
>>>> as
>>>> {pre_patched_original_angstrom_kernel}
>>>>
>>>> 6) I ran the prepare-kernel script again with the --linux directed
>>>> to
>>>> the {pre_patched_original_angstrom_kernel} and the patch went
>>>> through
>>>> fine. So now i have a copy of i-pipe patched source
>>>> {ipipe_patched_original_angstrom_kernel}
>>>>
>>>> 7) I proceed with copying the .config function from
>>>> arch/arm/configs/omap2plus_defconfig and run the make menuconfig
>>>> with
>>>>
>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- 
>>>> menuconfig
>>>>
>>>> and save the kernel configuration
>>>>
>>>> 8) i then proceed to compile the kernel with the following command
>>>>
>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>>>
>>>> 9) The compilation fails and it gives the following error
>>>>
>>>>   arch/arm/mach-omap2/devices.c:1096:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_0'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1101:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_1'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1106:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_2'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1111:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_3'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1116:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_4'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1121:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_5'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1126:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_6'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1131:12: error: 
>>>> 'AM33XX_IRQ_ICSS0_7'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1260:12: error:
>>>> 'AM33XX_IRQ_CPSW_C0_RX'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[2].start')
>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[2].end')
>>>> | arch/arm/mach-omap2/devices.c:1265:12: error:
>>>> 'AM33XX_IRQ_DMTIMER5'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[3].start')
>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[3].end')
>>>> | arch/arm/mach-omap2/devices.c:1270:12: error:
>>>> 'AM33XX_IRQ_DMTIMER6'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[4].start')
>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[4].end')
>>>> | arch/arm/mach-omap2/devices.c:1275:12: error: 
>>>> 'AM33XX_IRQ_CPSW_C0'
>>>> undeclared here (not in a function)
>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[5].start')
>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer element
>>>> is
>>>> not constant
>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near 
>>>> initialization
>>>> for
>>>> 'am33xx_cpsw_resources[5].end')
>>>>
>>>> I read from this link
>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html 
>>>> that
>>>> for
>>>> the kernel to boot properly on the AM3359 two changes needs to be
>>>> made.
>>>> I had yet to made these changes as i want to see if the kernel
>>>> source
>>>> would compiled and to verify my steps.
>>>>
>>>> Is my approach correct? Any advice on how to solve this problem?
>>>
>>> There is no correct approach, there is more than one way to do it.
>>> Does
>>> the un-patched kernel compile with the .config you use? If yes, 
>>> does
>>> the
>>> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI 
>>> disabled?
>>
>>
>> Sorry about the private reply Gilles, I clicked the reply button
>> instead of reply all.
>>
>>
>> The un-patched kernel compile fine with the original .config.
>>
>> The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI 
>> disable
>> shows the same compilation error as before.
>
> This looks like an error due to some changes made by the I-pipe patch 
> to
> the include files. In order to debug this, you have to simply
> pre-process the file, and try and understand what happens. If at the 
> top
> of the build tree, you run "make arch/arm/mach-omap2/devices.i" with 
> the
> proper make variables set, the kernel makefile should generate the
> pre-processed file.

I compared the devices.i and noticed that in the function where the 
compile error occurs the constant variables are not well defined. But 
how do I know which includes files are modified?

static struct resource am33xx_cpsw_resources[] = {
  {
   .start = 0x4A100000,
   .end = 0x4A100000 + 0x00000800 - 1,
   .flags = 0x00000200,
  },
  {
   .start = 0x4A101200,
   .end = 0x4A101200 + 0x00000100 - 1,
   .flags = 0x00000200,
  },
  {
   .start = AM33XX_IRQ_CPSW_C0_RX,
   .end = AM33XX_IRQ_CPSW_C0_RX,
   .flags = 0x00000400,
  },
  {
   .start = AM33XX_IRQ_DMTIMER5,
   .end = AM33XX_IRQ_DMTIMER5,
   .flags = 0x00000400,
  },
  {
   .start = AM33XX_IRQ_DMTIMER6,
   .end = AM33XX_IRQ_DMTIMER6,
   .flags = 0x00000400,
  },
  {
   .start = AM33XX_IRQ_CPSW_C0,
   .end = AM33XX_IRQ_CPSW_C0,
   .flags = 0x00000400,
  },
};










^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23 17:22       ` WONG Sheng Chao
@ 2012-11-23 17:45         ` Gilles Chanteperdrix
  2012-11-27 16:40           ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-23 17:45 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/23/2012 06:22 PM, WONG Sheng Chao wrote:
> On Fri, 23 Nov 2012 17:29:02 +0100, Gilles Chanteperdrix wrote:
>> On 11/23/2012 01:35 PM, WONG Sheng Chao wrote:
>>> On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>>>>> Hi
>>>>>
>>>>> I am trying to get Xenomai working on the beaglebone (AM3359) and 
>>>>> I
>>>>> had
>>>>> been following the instructions from this mailing list
>>>>>
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>
>>>>> The steps that I went through was such
>>>>>
>>>>> 1) I configured the Angstorm distribution with linux kernel 3.2.21
>>>>> for
>>>>> beaglebone using bitbake
>>>>>
>>>>> 2) Copied the kernel source from it and saved it as
>>>>> {original_angstrom_kernel}
>>>>>
>>>>> 3) I then ran the patch script from xenomai-2.6.1
>>>>>
>>>>> $./prepare-kernel.sh --linux={original_angstrom_kernel} --arch=arm
>>>>>
>>>>>
>>>>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>>>>
>>>>> 4) There were four conflicting files, namely
>>>>>
>>>>> arch/arm/common/gic.c
>>>>> arch/arm/mach-omap2/irq.c
>>>>> arch/arm/plat-mxc/gic.c
>>>>> arch/arm/plat-omap/include/plat/irqs.h
>>>>>
>>>>> 5) I compared these four files to the vanilla linux-kernel-3.2.21
>>>>> and
>>>>> patch these 4 files individually from {original_angstrom_kernel}
>>>>> with
>>>>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel 
>>>>> source
>>>>> as
>>>>> {pre_patched_original_angstrom_kernel}
>>>>>
>>>>> 6) I ran the prepare-kernel script again with the --linux directed
>>>>> to
>>>>> the {pre_patched_original_angstrom_kernel} and the patch went
>>>>> through
>>>>> fine. So now i have a copy of i-pipe patched source
>>>>> {ipipe_patched_original_angstrom_kernel}
>>>>>
>>>>> 7) I proceed with copying the .config function from
>>>>> arch/arm/configs/omap2plus_defconfig and run the make menuconfig
>>>>> with
>>>>>
>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- 
>>>>> menuconfig
>>>>>
>>>>> and save the kernel configuration
>>>>>
>>>>> 8) i then proceed to compile the kernel with the following command
>>>>>
>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>>>>
>>>>> 9) The compilation fails and it gives the following error
>>>>>
>>>>>   arch/arm/mach-omap2/devices.c:1096:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_0'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1101:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_1'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1106:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_2'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1111:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_3'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1116:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_4'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1121:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_5'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1126:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_6'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1131:12: error: 
>>>>> 'AM33XX_IRQ_ICSS0_7'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1260:12: error:
>>>>> 'AM33XX_IRQ_CPSW_C0_RX'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[2].start')
>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[2].end')
>>>>> | arch/arm/mach-omap2/devices.c:1265:12: error:
>>>>> 'AM33XX_IRQ_DMTIMER5'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[3].start')
>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[3].end')
>>>>> | arch/arm/mach-omap2/devices.c:1270:12: error:
>>>>> 'AM33XX_IRQ_DMTIMER6'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[4].start')
>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[4].end')
>>>>> | arch/arm/mach-omap2/devices.c:1275:12: error: 
>>>>> 'AM33XX_IRQ_CPSW_C0'
>>>>> undeclared here (not in a function)
>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[5].start')
>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer element
>>>>> is
>>>>> not constant
>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near 
>>>>> initialization
>>>>> for
>>>>> 'am33xx_cpsw_resources[5].end')
>>>>>
>>>>> I read from this link
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html 
>>>>> that
>>>>> for
>>>>> the kernel to boot properly on the AM3359 two changes needs to be
>>>>> made.
>>>>> I had yet to made these changes as i want to see if the kernel
>>>>> source
>>>>> would compiled and to verify my steps.
>>>>>
>>>>> Is my approach correct? Any advice on how to solve this problem?
>>>>
>>>> There is no correct approach, there is more than one way to do it.
>>>> Does
>>>> the un-patched kernel compile with the .config you use? If yes, 
>>>> does
>>>> the
>>>> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI 
>>>> disabled?
>>>
>>>
>>> Sorry about the private reply Gilles, I clicked the reply button
>>> instead of reply all.
>>>
>>>
>>> The un-patched kernel compile fine with the original .config.
>>>
>>> The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI 
>>> disable
>>> shows the same compilation error as before.
>>
>> This looks like an error due to some changes made by the I-pipe patch 
>> to
>> the include files. In order to debug this, you have to simply
>> pre-process the file, and try and understand what happens. If at the 
>> top
>> of the build tree, you run "make arch/arm/mach-omap2/devices.i" with 
>> the
>> proper make variables set, the kernel makefile should generate the
>> pre-processed file.
> 
> I compared the devices.i and noticed that in the function where the 
> compile error occurs the constant variables are not well defined. But 
> how do I know which includes files are modified?

You have to check which header defines the constant, and how it gets
included in the correct devices.i, then look at the incorrect one, and
check what prevents the include file from being included.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-23 17:45         ` Gilles Chanteperdrix
@ 2012-11-27 16:40           ` WONG Sheng Chao
  2012-11-27 16:52             ` WONG Sheng Chao
  2012-11-27 18:00             ` Gilles Chanteperdrix
  0 siblings, 2 replies; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-27 16:40 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Fri, 23 Nov 2012 18:45:50 +0100, Gilles Chanteperdrix wrote:
> On 11/23/2012 06:22 PM, WONG Sheng Chao wrote:
>> On Fri, 23 Nov 2012 17:29:02 +0100, Gilles Chanteperdrix wrote:
>>> On 11/23/2012 01:35 PM, WONG Sheng Chao wrote:
>>>> On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
>>>>> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>>>>>> Hi
>>>>>>
>>>>>> I am trying to get Xenomai working on the beaglebone (AM3359) 
>>>>>> and
>>>>>> I
>>>>>> had
>>>>>> been following the instructions from this mailing list
>>>>>>
>>>>>>
>>>>>> 
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>
>>>>>> The steps that I went through was such
>>>>>>
>>>>>> 1) I configured the Angstorm distribution with linux kernel 
>>>>>> 3.2.21
>>>>>> for
>>>>>> beaglebone using bitbake
>>>>>>
>>>>>> 2) Copied the kernel source from it and saved it as
>>>>>> {original_angstrom_kernel}
>>>>>>
>>>>>> 3) I then ran the patch script from xenomai-2.6.1
>>>>>>
>>>>>> $./prepare-kernel.sh --linux={original_angstrom_kernel} 
>>>>>> --arch=arm
>>>>>>
>>>>>>
>>>>>> 
>>>>>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>>>>>
>>>>>> 4) There were four conflicting files, namely
>>>>>>
>>>>>> arch/arm/common/gic.c
>>>>>> arch/arm/mach-omap2/irq.c
>>>>>> arch/arm/plat-mxc/gic.c
>>>>>> arch/arm/plat-omap/include/plat/irqs.h
>>>>>>
>>>>>> 5) I compared these four files to the vanilla 
>>>>>> linux-kernel-3.2.21
>>>>>> and
>>>>>> patch these 4 files individually from {original_angstrom_kernel}
>>>>>> with
>>>>>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel
>>>>>> source
>>>>>> as
>>>>>> {pre_patched_original_angstrom_kernel}
>>>>>>
>>>>>> 6) I ran the prepare-kernel script again with the --linux 
>>>>>> directed
>>>>>> to
>>>>>> the {pre_patched_original_angstrom_kernel} and the patch went
>>>>>> through
>>>>>> fine. So now i have a copy of i-pipe patched source
>>>>>> {ipipe_patched_original_angstrom_kernel}
>>>>>>
>>>>>> 7) I proceed with copying the .config function from
>>>>>> arch/arm/configs/omap2plus_defconfig and run the make menuconfig
>>>>>> with
>>>>>>
>>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi-
>>>>>> menuconfig
>>>>>>
>>>>>> and save the kernel configuration
>>>>>>
>>>>>> 8) i then proceed to compile the kernel with the following 
>>>>>> command
>>>>>>
>>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>>>>>
>>>>>> 9) The compilation fails and it gives the following error
>>>>>>
>>>>>>   arch/arm/mach-omap2/devices.c:1096:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_0'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1101:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_1'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1106:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_2'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1111:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_3'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1116:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_4'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1121:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_5'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1126:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_6'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1131:12: error:
>>>>>> 'AM33XX_IRQ_ICSS0_7'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1260:12: error:
>>>>>> 'AM33XX_IRQ_CPSW_C0_RX'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[2].start')
>>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[2].end')
>>>>>> | arch/arm/mach-omap2/devices.c:1265:12: error:
>>>>>> 'AM33XX_IRQ_DMTIMER5'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[3].start')
>>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[3].end')
>>>>>> | arch/arm/mach-omap2/devices.c:1270:12: error:
>>>>>> 'AM33XX_IRQ_DMTIMER6'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[4].start')
>>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[4].end')
>>>>>> | arch/arm/mach-omap2/devices.c:1275:12: error:
>>>>>> 'AM33XX_IRQ_CPSW_C0'
>>>>>> undeclared here (not in a function)
>>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[5].start')
>>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer 
>>>>>> element
>>>>>> is
>>>>>> not constant
>>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near
>>>>>> initialization
>>>>>> for
>>>>>> 'am33xx_cpsw_resources[5].end')
>>>>>>
>>>>>> I read from this link
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html
>>>>>> that
>>>>>> for
>>>>>> the kernel to boot properly on the AM3359 two changes needs to 
>>>>>> be
>>>>>> made.
>>>>>> I had yet to made these changes as i want to see if the kernel
>>>>>> source
>>>>>> would compiled and to verify my steps.
>>>>>>
>>>>>> Is my approach correct? Any advice on how to solve this problem?
>>>>>
>>>>> There is no correct approach, there is more than one way to do 
>>>>> it.
>>>>> Does
>>>>> the un-patched kernel compile with the .config you use? If yes,
>>>>> does
>>>>> the
>>>>> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI
>>>>> disabled?
>>>>
>>>>
>>>> Sorry about the private reply Gilles, I clicked the reply button
>>>> instead of reply all.
>>>>
>>>>
>>>> The un-patched kernel compile fine with the original .config.
>>>>
>>>> The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI
>>>> disable
>>>> shows the same compilation error as before.
>>>
>>> This looks like an error due to some changes made by the I-pipe 
>>> patch
>>> to
>>> the include files. In order to debug this, you have to simply
>>> pre-process the file, and try and understand what happens. If at 
>>> the
>>> top
>>> of the build tree, you run "make arch/arm/mach-omap2/devices.i" 
>>> with
>>> the
>>> proper make variables set, the kernel makefile should generate the
>>> pre-processed file.
>>
>> I compared the devices.i and noticed that in the function where the
>> compile error occurs the constant variables are not well defined. 
>> But
>> how do I know which includes files are modified?
>
> You have to check which header defines the constant, and how it gets
> included in the correct devices.i, then look at the incorrect one, 
> and
> check what prevents the include file from being included.

Hi Gilles

Following your advice i tracked down the include files which need to be 
included to remove the error. The kernel now compiles without errors. I 
followed the instructions in

http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html

to change the timer.c and also changing the .handle_irq with 
ipipe_handle_multi_irq

 From the serial terminal i noticed that with CONFIG_IPIPE = ON the 
timer is used correctly as in the above post but it hangs at

[    0.958295] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write

I followed the troubleshooting guide at

http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Troubleshooting

With both CONFIG_XENOMAI and CONFIG_IPIPE off, the kernel was able to 
boot normally

Uncompressing Linux... done, booting the kernel.
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc 
version 4.5.4 20120305 (prerelease) (GCC) ) #1 Tue Nov 27 17:19:52 CET 
2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] Machine: am335xevm
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (sgx neon )
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 65024
[    0.000000] Kernel command line: console=ttyO0,115200n8 
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 
bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 
bytes)
[    0.000000] Memory: 256MB = 256MB total
[    0.000000] Memory: 252968k/252968k available, 9176k reserved, 0K 
highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05bdd54   (5848 kB)
[    0.000000]       .init : 0xc05be000 - 0xc0600000   ( 264 kB)
[    0.000000]       .data : 0xc0600000 - 0xc064eea8   ( 316 kB)
[    0.000000]        .bss : 0xc064eecc - 0xc06b9214   ( 425 kB)
[    0.000000] NR_IRQS:410 nr_irqs:410 410
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 
interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
[    0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
every 178956ms
[    0.000000] Console: colour dummy device 80x30
[    0.000244] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
[    0.118703] pid_max: default: 32768 minimum: 301
[    0.118865] Security Framework initialized
[    0.118942] Mount-cache hash table entries: 512
[    0.119410] Initializing cgroup subsys cpuacct
[    0.119462] Initializing cgroup subsys devices
[    0.119478] Initializing cgroup subsys freezer
[    0.119558] CPU: Testing write buffer coherency: ok
[    0.120847] devtmpfs: initialized
[    0.141418] omap_hwmod: gfx: failed to hardreset
[    0.158137] omap_hwmod: pruss: failed to hardreset
[    0.158801] print_constraints: dummy:
[    0.159070] NET: Registered protocol family 16
[    0.160363] OMAP GPIO hardware version 0.1
[    0.161676] omap_mux_init: Add partition: #1: core, flags: 0
[    0.163248]  omap_i2c.1: alias fck already exists
[    0.163661] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.163848]  omap2_mcspi.1: alias fck already exists
[    0.163985]  omap2_mcspi.2: alias fck already exists
[    0.164171]  edma.0: alias fck already exists
[    0.164198]  edma.0: alias fck already exists
[    0.164222]  edma.0: alias fck already exists
[    0.164320] cape: pcm register
[    0.174334] bio: create slab <bio-0> at 0
[    0.175680] SCSI subsystem initialized
[    0.176720] usbcore: registered new interface driver usbfs
[    0.176869] usbcore: registered new interface driver hub
[    0.177082] usbcore: registered new device driver usb
[    0.177245] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
plat_mode=0x3
[    0.177408] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
plat_mode=0x1
[    0.177955] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[    0.179282] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    0.179941] Switching to clocksource gp timer
[    0.207177] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    0.207397] musb-hdrc musb-hdrc.0: dma type: pio
[    0.207605] MUSB0 controller's USBSS revision = 4ea20800
[    0.208120] musb-hdrc musb-hdrc.0: USB OTG mode controller at 
d081c000 using PIO, IRQ 18
[    0.208468] musb-hdrc musb-hdrc.1: dma type: pio
[    0.208658] MUSB1 controller's USBSS revision = 4ea20800
[    0.208803] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
[    0.208912] musb-hdrc musb-hdrc.1: new USB bus registered, assigned 
bus number 1
[    0.209083] usb usb1: New USB device found, idVendor=1d6b, 
idProduct=0002
[    0.209106] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[    0.209124] usb usb1: Product: MUSB HDRC host driver
[    0.209140] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
[    0.209155] usb usb1: SerialNumber: musb-hdrc.1
[    0.209949] hub 1-0:1.0: USB hub found
[    0.210075] hub 1-0:1.0: 1 port detected
[    0.210643] musb-hdrc musb-hdrc.1: USB Host mode controller at 
d081e800 using PIO, IRQ 19
[    0.211105] NET: Registered protocol family 2
[    0.211358] IP route cache hash table entries: 2048 (order: 1, 8192 
bytes)
[    0.211866] TCP established hash table entries: 8192 (order: 4, 
65536 bytes)
[    0.212090] TCP bind hash table entries: 8192 (order: 3, 32768 
bytes)
[    0.212226] TCP: Hash tables configured (established 8192 bind 8192)
[    0.212242] TCP reno registered
[    0.212260] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.212292] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.212623] NET: Registered protocol family 1
[    0.213057] RPC: Registered named UNIX socket transport module.
[    0.213077] RPC: Registered udp transport module.
[    0.213090] RPC: Registered tcp transport module.
[    0.213103] RPC: Registered tcp NFSv4.1 backchannel transport 
module.
[    0.213649] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
driver
[    0.215173] audit: initializing netlink socket (disabled)
[    0.215242] type=2000 audit(0.210:1): initialized
[    0.226622] VFS: Disk quotas dquot_6.5.2
[    0.226705] Dquot-cache hash table entries: 1024 (order 0, 4096 
bytes)
[    0.228060] msgmni has been set to 494
[    0.229491] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 252)
[    0.229517] io scheduler noop registered
[    0.229531] io scheduler deadline registered
[    0.229594] io scheduler cfq registered (default)
[    0.230798] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.232402] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a 
OMAP UART0
[    0.834573] console [ttyO0] enabled
[    0.838986] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a 
OMAP UART1
[    0.846942] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a 
OMAP UART2
[    0.854853] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a 
OMAP UART3
[    0.862748] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a 
OMAP UART4
[    0.870645] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a 
OMAP UART5
[    0.879787] brd: module loaded
[    0.887606] loop: module loaded
[    0.891067] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write
[    0.949996] No daughter card found
[    0.953630] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write
[    0.968911] Board name: A335BONE
[    0.972328] Board version: 00A6
[    0.975629] The board is a AM335x Beaglebone.
[    0.980934] tps65217 1-0024: TPS65217 ID 0xf version 1.1
[    0.988396] print_constraints: DCDC1: 900 <--> 1800 mV at 1800 mV
[    0.996824] print_constraints: DCDC2: 900 <--> 3300 mV at 1275 mV
[    1.005246] print_constraints: DCDC3: 900 <--> 1500 mV at 1100 mV
[    1.013632] print_constraints: LDO1: 1000 <--> 3300 mV at 1800 mV
[    1.022025] print_constraints: LDO2: 900 <--> 3300 mV at 3300 mV
[    1.030303] print_constraints: LDO3: 1800 <--> 3300 mV at 3300 mV
[    1.038701] print_constraints: LDO4: 1800 <--> 3300 mV at 3300 mV
[    1.045724] Maximum current provided by the USB port is 500mA which 
is not sufficient when operating @OPP120 and OPPTURBO. The current 
requirement for some use-cases using OPP100 might also exceed the 
maximum current that the USB port can provide. Unless you are fully 
confident that the current requirements for OPP100 use-case don't exceed 
the USB limits, switching to AC power is recommended.
[    1.082552]  omap_i2c.3: alias fck already exists
[    1.087824] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
[    1.098210] at24 3-0054: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write
[    1.159999] BeagleBone cape EEPROM: could not read eeprom at address 
0x54


Here's the log with CONFIG_XENOMAI = OFF and CONFIG_IPIPE = ON

Uncompressing Linux... done, booting the kernel.
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc 
version 4.5.4 20120305 (prerelease) (GCC) ) #1 PREEMPT Tue Nov 27 
17:36:26 CET 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] Machine: am335xevm
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (sgx neon )
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 65024
[    0.000000] Kernel command line: console=ttyO0,115200n8 
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 
bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 
bytes)
[    0.000000] Memory: 256MB = 256MB total
[    0.000000] Memory: 252464k/252464k available, 9680k reserved, 0K 
highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc061123c   (6181 kB)
[    0.000000]       .init : 0xc0612000 - 0xc0655000   ( 268 kB)
[    0.000000]       .data : 0xc0656000 - 0xc06a6868   ( 323 kB)
[    0.000000]        .bss : 0xc06a688c - 0xc0737d54   ( 582 kB)
[    0.000000] NR_IRQS:410 nr_irqs:410 410
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 
interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
[    0.000000] OMAP clocksource: GPTIMER3 at 24000000 Hz
[    0.000000] I-pipe, 24.000 MHz clocksource
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
every 178956ms
[    0.000000] Interrupt pipeline (release #1)
[    0.000000] Console: colour dummy device 80x30
[    0.000735] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
[    0.118663] pid_max: default: 32768 minimum: 301
[    0.118881] Security Framework initialized
[    0.118984] Mount-cache hash table entries: 512
[    0.119570] Initializing cgroup subsys cpuacct
[    0.119627] Initializing cgroup subsys devices
[    0.119645] Initializing cgroup subsys freezer
[    0.119746] CPU: Testing write buffer coherency: ok
[    0.121323] devtmpfs: initialized
[    0.142538] omap_hwmod: gfx: failed to hardreset
[    0.159288] omap_hwmod: pruss: failed to hardreset
[    0.160005] print_constraints: dummy:
[    0.160342] NET: Registered protocol family 16
[    0.161800] OMAP GPIO hardware version 0.1
[    0.163363] omap_mux_init: Add partition: #1: core, flags: 0
[    0.165179]  omap_i2c.1: alias fck already exists
[    0.165644] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.165856]  omap2_mcspi.1: alias fck already exists
[    0.166011]  omap2_mcspi.2: alias fck already exists
[    0.166215]  edma.0: alias fck already exists
[    0.166245]  edma.0: alias fck already exists
[    0.166271]  edma.0: alias fck already exists
[    0.166381] cape: pcm register
[    0.177948] bio: create slab <bio-0> at 0
[    0.179694] SCSI subsystem initialized
[    0.180900] usbcore: registered new interface driver usbfs
[    0.181072] usbcore: registered new interface driver hub
[    0.181333] usbcore: registered new device driver usb
[    0.181530] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
plat_mode=0x3
[    0.181709] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
plat_mode=0x1
[    0.182363] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[    0.183779] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    0.184506] Switching to clocksource ipipe_tsc
[    0.220287] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    0.220545] musb-hdrc musb-hdrc.0: dma type: pio
[    0.220788] MUSB0 controller's USBSS revision = 4ea20800
[    0.221366] musb-hdrc musb-hdrc.0: USB OTG mode controller at 
d081c000 using PIO, IRQ 18
[    0.221763] musb-hdrc musb-hdrc.1: dma type: pio
[    0.221979] MUSB1 controller's USBSS revision = 4ea20800
[    0.222143] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
[    0.222276] musb-hdrc musb-hdrc.1: new USB bus registered, assigned 
bus number 1
[    0.222485] usb usb1: New USB device found, idVendor=1d6b, 
idProduct=0002
[    0.222510] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[    0.222532] usb usb1: Product: MUSB HDRC host driver
[    0.222549] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
[    0.222566] usb usb1: SerialNumber: musb-hdrc.1
[    0.223435] hub 1-0:1.0: USB hub found
[    0.223478] hub 1-0:1.0: 1 port detected
[    0.224106] musb-hdrc musb-hdrc.1: USB Host mode controller at 
d081e800 using PIO, IRQ 19
[    0.224699] NET: Registered protocol family 2
[    0.224989] IP route cache hash table entries: 2048 (order: 1, 8192 
bytes)
[    0.225617] TCP established hash table entries: 8192 (order: 4, 
65536 bytes)
[    0.225845] TCP bind hash table entries: 8192 (order: 3, 32768 
bytes)
[    0.225982] TCP: Hash tables configured (established 8192 bind 8192)
[    0.226001] TCP reno registered
[    0.226021] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.226056] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.226446] NET: Registered protocol family 1
[    0.227121] RPC: Registered named UNIX socket transport module.
[    0.227146] RPC: Registered udp transport module.
[    0.227162] RPC: Registered tcp transport module.
[    0.227176] RPC: Registered tcp NFSv4.1 backchannel transport 
module.
[    0.227832] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
driver
[    0.229751] audit: initializing netlink socket (disabled)
[    0.229835] type=2000 audit(0.180:1): initialized
[    0.241446] VFS: Disk quotas dquot_6.5.2
[    0.241550] Dquot-cache hash table entries: 1024 (order 0, 4096 
bytes)
[    0.243359] msgmni has been set to 493
[    0.245251] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 252)
[    0.245282] io scheduler noop registered
[    0.245297] io scheduler deadline registered
[    0.245392] io scheduler cfq registered (default)
[    0.246642] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.248598] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a 
OMAP UART0
[    0.860338] console [ttyO0] enabled
[    0.864664] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a 
OMAP UART1
[    0.872618] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a 
OMAP UART2
[    0.880574] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a 
OMAP UART3
[    0.888525] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a 
OMAP UART4
[    0.896491] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a 
OMAP UART5
[    0.905879] brd: module loaded
[    0.914179] loop: module loaded
[    0.917564] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write


Any advice on how to proceed to debug this problem? I attach the 
config files of two cases for your reference.
















-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config_with_xenomai_off_ipipe_off
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/cd61c917/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config_with_xenomai_off_ipipe_on
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/cd61c917/attachment-0001.ksh>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-27 16:40           ` WONG Sheng Chao
@ 2012-11-27 16:52             ` WONG Sheng Chao
  2012-11-27 18:00             ` Gilles Chanteperdrix
  1 sibling, 0 replies; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-27 16:52 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On Tue, 27 Nov 2012 17:40:59 +0100, WONG Sheng Chao wrote:
> On Fri, 23 Nov 2012 18:45:50 +0100, Gilles Chanteperdrix wrote:
>> On 11/23/2012 06:22 PM, WONG Sheng Chao wrote:
>>> On Fri, 23 Nov 2012 17:29:02 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/23/2012 01:35 PM, WONG Sheng Chao wrote:
>>>>> On Fri, 23 Nov 2012 10:58:50 +0100, Gilles Chanteperdrix wrote:
>>>>>> On 11/23/2012 10:45 AM, WONG Sheng Chao wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I am trying to get Xenomai working on the beaglebone (AM3359) 
>>>>>>> and
>>>>>>> I
>>>>>>> had
>>>>>>> been following the instructions from this mailing list
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>>
>>>>>>> The steps that I went through was such
>>>>>>>
>>>>>>> 1) I configured the Angstorm distribution with linux kernel 
>>>>>>> 3.2.21
>>>>>>> for
>>>>>>> beaglebone using bitbake
>>>>>>>
>>>>>>> 2) Copied the kernel source from it and saved it as
>>>>>>> {original_angstrom_kernel}
>>>>>>>
>>>>>>> 3) I then ran the patch script from xenomai-2.6.1
>>>>>>>
>>>>>>> $./prepare-kernel.sh --linux={original_angstrom_kernel} 
>>>>>>> --arch=arm
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> --adeos=/xenomai-2.6.1/ksrc/arch/arm/patches/ipipe-core-3.2.21-arm-1.patch
>>>>>>>
>>>>>>> 4) There were four conflicting files, namely
>>>>>>>
>>>>>>> arch/arm/common/gic.c
>>>>>>> arch/arm/mach-omap2/irq.c
>>>>>>> arch/arm/plat-mxc/gic.c
>>>>>>> arch/arm/plat-omap/include/plat/irqs.h
>>>>>>>
>>>>>>> 5) I compared these four files to the vanilla 
>>>>>>> linux-kernel-3.2.21
>>>>>>> and
>>>>>>> patch these 4 files individually from 
>>>>>>> {original_angstrom_kernel}
>>>>>>> with
>>>>>>> {vanilla-kernel-3.2.21}. Now i save the newly patched kernel
>>>>>>> source
>>>>>>> as
>>>>>>> {pre_patched_original_angstrom_kernel}
>>>>>>>
>>>>>>> 6) I ran the prepare-kernel script again with the --linux 
>>>>>>> directed
>>>>>>> to
>>>>>>> the {pre_patched_original_angstrom_kernel} and the patch went
>>>>>>> through
>>>>>>> fine. So now i have a copy of i-pipe patched source
>>>>>>> {ipipe_patched_original_angstrom_kernel}
>>>>>>>
>>>>>>> 7) I proceed with copying the .config function from
>>>>>>> arch/arm/configs/omap2plus_defconfig and run the make 
>>>>>>> menuconfig
>>>>>>> with
>>>>>>>
>>>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi-
>>>>>>> menuconfig
>>>>>>>
>>>>>>> and save the kernel configuration
>>>>>>>
>>>>>>> 8) i then proceed to compile the kernel with the following 
>>>>>>> command
>>>>>>>
>>>>>>> $make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
>>>>>>>
>>>>>>> 9) The compilation fails and it gives the following error
>>>>>>>
>>>>>>>   arch/arm/mach-omap2/devices.c:1096:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_0'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1101:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_1'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1106:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_2'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1111:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_3'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1116:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_4'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1121:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_5'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1126:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_6'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1131:12: error:
>>>>>>> 'AM33XX_IRQ_ICSS0_7'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1260:12: error:
>>>>>>> 'AM33XX_IRQ_CPSW_C0_RX'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1260:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[2].start')
>>>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1261:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[2].end')
>>>>>>> | arch/arm/mach-omap2/devices.c:1265:12: error:
>>>>>>> 'AM33XX_IRQ_DMTIMER5'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1265:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[3].start')
>>>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1266:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[3].end')
>>>>>>> | arch/arm/mach-omap2/devices.c:1270:12: error:
>>>>>>> 'AM33XX_IRQ_DMTIMER6'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1270:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[4].start')
>>>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1271:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[4].end')
>>>>>>> | arch/arm/mach-omap2/devices.c:1275:12: error:
>>>>>>> 'AM33XX_IRQ_CPSW_C0'
>>>>>>> undeclared here (not in a function)
>>>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1275:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[5].start')
>>>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: initializer 
>>>>>>> element
>>>>>>> is
>>>>>>> not constant
>>>>>>> | arch/arm/mach-omap2/devices.c:1276:3: error: (near
>>>>>>> initialization
>>>>>>> for
>>>>>>> 'am33xx_cpsw_resources[5].end')
>>>>>>>
>>>>>>> I read from this link
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000476.html
>>>>>>> that
>>>>>>> for
>>>>>>> the kernel to boot properly on the AM3359 two changes needs to 
>>>>>>> be
>>>>>>> made.
>>>>>>> I had yet to made these changes as i want to see if the kernel
>>>>>>> source
>>>>>>> would compiled and to verify my steps.
>>>>>>>
>>>>>>> Is my approach correct? Any advice on how to solve this 
>>>>>>> problem?
>>>>>>
>>>>>> There is no correct approach, there is more than one way to do 
>>>>>> it.
>>>>>> Does
>>>>>> the un-patched kernel compile with the .config you use? If yes,
>>>>>> does
>>>>>> the
>>>>>> patched kernel compile with CONFIG_IPIPE and CONFIG_XENOMAI
>>>>>> disabled?
>>>>>
>>>>>
>>>>> Sorry about the private reply Gilles, I clicked the reply button
>>>>> instead of reply all.
>>>>>
>>>>>
>>>>> The un-patched kernel compile fine with the original .config.
>>>>>
>>>>> The ipipe patched kernel with CONFIG_IPIPE and CONFIG_XENOMAI
>>>>> disable
>>>>> shows the same compilation error as before.
>>>>
>>>> This looks like an error due to some changes made by the I-pipe 
>>>> patch
>>>> to
>>>> the include files. In order to debug this, you have to simply
>>>> pre-process the file, and try and understand what happens. If at 
>>>> the
>>>> top
>>>> of the build tree, you run "make arch/arm/mach-omap2/devices.i" 
>>>> with
>>>> the
>>>> proper make variables set, the kernel makefile should generate the
>>>> pre-processed file.
>>>
>>> I compared the devices.i and noticed that in the function where the
>>> compile error occurs the constant variables are not well defined. 
>>> But
>>> how do I know which includes files are modified?
>>
>> You have to check which header defines the constant, and how it gets
>> included in the correct devices.i, then look at the incorrect one, 
>> and
>> check what prevents the include file from being included.
>
> Hi Gilles
>
> Following your advice i tracked down the include files which need to
> be included to remove the error. The kernel now compiles without
> errors. I followed the instructions in
>
> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>
> to change the timer.c and also changing the .handle_irq with
> ipipe_handle_multi_irq
>
> From the serial terminal i noticed that with CONFIG_IPIPE = ON the
> timer is used correctly as in the above post but it hangs at
>
> [    0.958295] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64
> bytes/write
>
> I followed the troubleshooting guide at
>
> 
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Troubleshooting
>
> With both CONFIG_XENOMAI and CONFIG_IPIPE off, the kernel was able to
> boot normally
>
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc
> version 4.5.4 20120305 (prerelease) (GCC) ) #1 Tue Nov 27 17:19:52 
> CET
> 2012
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
> cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine: am335xevm
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] AM335X ES1.0 (sgx neon )
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 65024
> [    0.000000] Kernel command line: console=ttyO0,115200n8
> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 
> bytes)
> [    0.000000] Memory: 256MB = 256MB total
> [    0.000000] Memory: 252968k/252968k available, 9176k reserved, 0K 
> highmem
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc05bdd54   (5848 kB)
> [    0.000000]       .init : 0xc05be000 - 0xc0600000   ( 264 kB)
> [    0.000000]       .data : 0xc0600000 - 0xc064eea8   ( 316 kB)
> [    0.000000]        .bss : 0xc064eecc - 0xc06b9214   ( 425 kB)
> [    0.000000] NR_IRQS:410 nr_irqs:410 410
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with
> 128 interrupts
> [    0.000000] Total of 128 interrupts on 1 active controller
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
> [    0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
> every 178956ms
> [    0.000000] Console: colour dummy device 80x30
> [    0.000244] Calibrating delay loop... 498.89 BogoMIPS 
> (lpj=2494464)
> [    0.118703] pid_max: default: 32768 minimum: 301
> [    0.118865] Security Framework initialized
> [    0.118942] Mount-cache hash table entries: 512
> [    0.119410] Initializing cgroup subsys cpuacct
> [    0.119462] Initializing cgroup subsys devices
> [    0.119478] Initializing cgroup subsys freezer
> [    0.119558] CPU: Testing write buffer coherency: ok
> [    0.120847] devtmpfs: initialized
> [    0.141418] omap_hwmod: gfx: failed to hardreset
> [    0.158137] omap_hwmod: pruss: failed to hardreset
> [    0.158801] print_constraints: dummy:
> [    0.159070] NET: Registered protocol family 16
> [    0.160363] OMAP GPIO hardware version 0.1
> [    0.161676] omap_mux_init: Add partition: #1: core, flags: 0
> [    0.163248]  omap_i2c.1: alias fck already exists
> [    0.163661] hw-breakpoint: debug architecture 0x4 unsupported.
> [    0.163848]  omap2_mcspi.1: alias fck already exists
> [    0.163985]  omap2_mcspi.2: alias fck already exists
> [    0.164171]  edma.0: alias fck already exists
> [    0.164198]  edma.0: alias fck already exists
> [    0.164222]  edma.0: alias fck already exists
> [    0.164320] cape: pcm register
> [    0.174334] bio: create slab <bio-0> at 0
> [    0.175680] SCSI subsystem initialized
> [    0.176720] usbcore: registered new interface driver usbfs
> [    0.176869] usbcore: registered new interface driver hub
> [    0.177082] usbcore: registered new device driver usb
> [    0.177245] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
> plat_mode=0x3
> [    0.177408] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
> plat_mode=0x1
> [    0.177955] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
> [    0.179282] Advanced Linux Sound Architecture Driver Version 
> 1.0.24.
> [    0.179941] Switching to clocksource gp timer
> [    0.207177] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    0.207397] musb-hdrc musb-hdrc.0: dma type: pio
> [    0.207605] MUSB0 controller's USBSS revision = 4ea20800
> [    0.208120] musb-hdrc musb-hdrc.0: USB OTG mode controller at
> d081c000 using PIO, IRQ 18
> [    0.208468] musb-hdrc musb-hdrc.1: dma type: pio
> [    0.208658] MUSB1 controller's USBSS revision = 4ea20800
> [    0.208803] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
> [    0.208912] musb-hdrc musb-hdrc.1: new USB bus registered,
> assigned bus number 1
> [    0.209083] usb usb1: New USB device found, idVendor=1d6b, 
> idProduct=0002
> [    0.209106] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    0.209124] usb usb1: Product: MUSB HDRC host driver
> [    0.209140] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
> [    0.209155] usb usb1: SerialNumber: musb-hdrc.1
> [    0.209949] hub 1-0:1.0: USB hub found
> [    0.210075] hub 1-0:1.0: 1 port detected
> [    0.210643] musb-hdrc musb-hdrc.1: USB Host mode controller at
> d081e800 using PIO, IRQ 19
> [    0.211105] NET: Registered protocol family 2
> [    0.211358] IP route cache hash table entries: 2048 (order: 1, 
> 8192 bytes)
> [    0.211866] TCP established hash table entries: 8192 (order: 4,
> 65536 bytes)
> [    0.212090] TCP bind hash table entries: 8192 (order: 3, 32768 
> bytes)
> [    0.212226] TCP: Hash tables configured (established 8192 bind 
> 8192)
> [    0.212242] TCP reno registered
> [    0.212260] UDP hash table entries: 256 (order: 0, 4096 bytes)
> [    0.212292] UDP-Lite hash table entries: 256 (order: 0, 4096 
> bytes)
> [    0.212623] NET: Registered protocol family 1
> [    0.213057] RPC: Registered named UNIX socket transport module.
> [    0.213077] RPC: Registered udp transport module.
> [    0.213090] RPC: Registered tcp transport module.
> [    0.213103] RPC: Registered tcp NFSv4.1 backchannel transport 
> module.
> [    0.213649] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
> driver
> [    0.215173] audit: initializing netlink socket (disabled)
> [    0.215242] type=2000 audit(0.210:1): initialized
> [    0.226622] VFS: Disk quotas dquot_6.5.2
> [    0.226705] Dquot-cache hash table entries: 1024 (order 0, 4096 
> bytes)
> [    0.228060] msgmni has been set to 494
> [    0.229491] Block layer SCSI generic (bsg) driver version 0.4
> loaded (major 252)
> [    0.229517] io scheduler noop registered
> [    0.229531] io scheduler deadline registered
> [    0.229594] io scheduler cfq registered (default)
> [    0.230798] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
> enabled
> [    0.232402] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a
> OMAP UART0
> [    0.834573] console [ttyO0] enabled
> [    0.838986] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a
> OMAP UART1
> [    0.846942] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a
> OMAP UART2
> [    0.854853] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a
> OMAP UART3
> [    0.862748] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a
> OMAP UART4
> [    0.870645] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a
> OMAP UART5
> [    0.879787] brd: module loaded
> [    0.887606] loop: module loaded
> [    0.891067] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64
> bytes/write
> [    0.949996] No daughter card found
> [    0.953630] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64
> bytes/write
> [    0.968911] Board name: A335BONE
> [    0.972328] Board version: 00A6
> [    0.975629] The board is a AM335x Beaglebone.
> [    0.980934] tps65217 1-0024: TPS65217 ID 0xf version 1.1
> [    0.988396] print_constraints: DCDC1: 900 <--> 1800 mV at 1800 mV
> [    0.996824] print_constraints: DCDC2: 900 <--> 3300 mV at 1275 mV
> [    1.005246] print_constraints: DCDC3: 900 <--> 1500 mV at 1100 mV
> [    1.013632] print_constraints: LDO1: 1000 <--> 3300 mV at 1800 mV
> [    1.022025] print_constraints: LDO2: 900 <--> 3300 mV at 3300 mV
> [    1.030303] print_constraints: LDO3: 1800 <--> 3300 mV at 3300 mV
> [    1.038701] print_constraints: LDO4: 1800 <--> 3300 mV at 3300 mV
> [    1.045724] Maximum current provided by the USB port is 500mA
> which is not sufficient when operating @OPP120 and OPPTURBO. The
> current requirement for some use-cases using OPP100 might also exceed
> the maximum current that the USB port can provide. Unless you are
> fully confident that the current requirements for OPP100 use-case
> don't exceed the USB limits, switching to AC power is recommended.
> [    1.082552]  omap_i2c.3: alias fck already exists
> [    1.087824] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
> [    1.098210] at24 3-0054: 32768 byte 24c256 EEPROM, writable, 64
> bytes/write
> [    1.159999] BeagleBone cape EEPROM: could not read eeprom at 
> address 0x54
>
>
> Here's the log with CONFIG_XENOMAI = OFF and CONFIG_IPIPE = ON
>
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc
> version 4.5.4 20120305 (prerelease) (GCC) ) #1 PREEMPT Tue Nov 27
> 17:36:26 CET 2012
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
> cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine: am335xevm
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] AM335X ES1.0 (sgx neon )
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 65024
> [    0.000000] Kernel command line: console=ttyO0,115200n8
> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 
> bytes)
> [    0.000000] Memory: 256MB = 256MB total
> [    0.000000] Memory: 252464k/252464k available, 9680k reserved, 0K 
> highmem
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc061123c   (6181 kB)
> [    0.000000]       .init : 0xc0612000 - 0xc0655000   ( 268 kB)
> [    0.000000]       .data : 0xc0656000 - 0xc06a6868   ( 323 kB)
> [    0.000000]        .bss : 0xc06a688c - 0xc0737d54   ( 582 kB)
> [    0.000000] NR_IRQS:410 nr_irqs:410 410
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with
> 128 interrupts
> [    0.000000] Total of 128 interrupts on 1 active controller
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000 Hz
> [    0.000000] I-pipe, 24.000 MHz clocksource
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
> every 178956ms
> [    0.000000] Interrupt pipeline (release #1)
> [    0.000000] Console: colour dummy device 80x30
> [    0.000735] Calibrating delay loop... 498.89 BogoMIPS 
> (lpj=2494464)
> [    0.118663] pid_max: default: 32768 minimum: 301
> [    0.118881] Security Framework initialized
> [    0.118984] Mount-cache hash table entries: 512
> [    0.119570] Initializing cgroup subsys cpuacct
> [    0.119627] Initializing cgroup subsys devices
> [    0.119645] Initializing cgroup subsys freezer
> [    0.119746] CPU: Testing write buffer coherency: ok
> [    0.121323] devtmpfs: initialized
> [    0.142538] omap_hwmod: gfx: failed to hardreset
> [    0.159288] omap_hwmod: pruss: failed to hardreset
> [    0.160005] print_constraints: dummy:
> [    0.160342] NET: Registered protocol family 16
> [    0.161800] OMAP GPIO hardware version 0.1
> [    0.163363] omap_mux_init: Add partition: #1: core, flags: 0
> [    0.165179]  omap_i2c.1: alias fck already exists
> [    0.165644] hw-breakpoint: debug architecture 0x4 unsupported.
> [    0.165856]  omap2_mcspi.1: alias fck already exists
> [    0.166011]  omap2_mcspi.2: alias fck already exists
> [    0.166215]  edma.0: alias fck already exists
> [    0.166245]  edma.0: alias fck already exists
> [    0.166271]  edma.0: alias fck already exists
> [    0.166381] cape: pcm register
> [    0.177948] bio: create slab <bio-0> at 0
> [    0.179694] SCSI subsystem initialized
> [    0.180900] usbcore: registered new interface driver usbfs
> [    0.181072] usbcore: registered new interface driver hub
> [    0.181333] usbcore: registered new device driver usb
> [    0.181530] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
> plat_mode=0x3
> [    0.181709] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
> plat_mode=0x1
> [    0.182363] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
> [    0.183779] Advanced Linux Sound Architecture Driver Version 
> 1.0.24.
> [    0.184506] Switching to clocksource ipipe_tsc
> [    0.220287] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    0.220545] musb-hdrc musb-hdrc.0: dma type: pio
> [    0.220788] MUSB0 controller's USBSS revision = 4ea20800
> [    0.221366] musb-hdrc musb-hdrc.0: USB OTG mode controller at
> d081c000 using PIO, IRQ 18
> [    0.221763] musb-hdrc musb-hdrc.1: dma type: pio
> [    0.221979] MUSB1 controller's USBSS revision = 4ea20800
> [    0.222143] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
> [    0.222276] musb-hdrc musb-hdrc.1: new USB bus registered,
> assigned bus number 1
> [    0.222485] usb usb1: New USB device found, idVendor=1d6b, 
> idProduct=0002
> [    0.222510] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    0.222532] usb usb1: Product: MUSB HDRC host driver
> [    0.222549] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
> [    0.222566] usb usb1: SerialNumber: musb-hdrc.1
> [    0.223435] hub 1-0:1.0: USB hub found
> [    0.223478] hub 1-0:1.0: 1 port detected
> [    0.224106] musb-hdrc musb-hdrc.1: USB Host mode controller at
> d081e800 using PIO, IRQ 19
> [    0.224699] NET: Registered protocol family 2
> [    0.224989] IP route cache hash table entries: 2048 (order: 1, 
> 8192 bytes)
> [    0.225617] TCP established hash table entries: 8192 (order: 4,
> 65536 bytes)
> [    0.225845] TCP bind hash table entries: 8192 (order: 3, 32768 
> bytes)
> [    0.225982] TCP: Hash tables configured (established 8192 bind 
> 8192)
> [    0.226001] TCP reno registered
> [    0.226021] UDP hash table entries: 256 (order: 0, 4096 bytes)
> [    0.226056] UDP-Lite hash table entries: 256 (order: 0, 4096 
> bytes)
> [    0.226446] NET: Registered protocol family 1
> [    0.227121] RPC: Registered named UNIX socket transport module.
> [    0.227146] RPC: Registered udp transport module.
> [    0.227162] RPC: Registered tcp transport module.
> [    0.227176] RPC: Registered tcp NFSv4.1 backchannel transport 
> module.
> [    0.227832] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
> driver
> [    0.229751] audit: initializing netlink socket (disabled)
> [    0.229835] type=2000 audit(0.180:1): initialized
> [    0.241446] VFS: Disk quotas dquot_6.5.2
> [    0.241550] Dquot-cache hash table entries: 1024 (order 0, 4096 
> bytes)
> [    0.243359] msgmni has been set to 493
> [    0.245251] Block layer SCSI generic (bsg) driver version 0.4
> loaded (major 252)
> [    0.245282] io scheduler noop registered
> [    0.245297] io scheduler deadline registered
> [    0.245392] io scheduler cfq registered (default)
> [    0.246642] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
> enabled
> [    0.248598] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a
> OMAP UART0
> [    0.860338] console [ttyO0] enabled
> [    0.864664] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a
> OMAP UART1
> [    0.872618] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a
> OMAP UART2
> [    0.880574] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a
> OMAP UART3
> [    0.888525] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a
> OMAP UART4
> [    0.896491] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a
> OMAP UART5
> [    0.905879] brd: module loaded
> [    0.914179] loop: module loaded
> [    0.917564] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64
> bytes/write
>
>
> Any advice on how to proceed to debug this problem? I attach the
> config files of two cases for your reference.
>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: config_with_xenomai_off_ipipe_off
> URL:
> 
> <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/cd61c917/attachment.ksh>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: config_with_xenomai_off_ipipe_on
> URL:
> 
> <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/cd61c917/attachment-0001.ksh>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai



Here's the renamed config files for the two cases mentioned above

config1 with CONFIG_IPIPE not set
cnofig2 with CONFIG_IPIPE set

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config1
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/4cf0977f/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config2
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121127/4cf0977f/attachment-0001.ksh>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-27 16:40           ` WONG Sheng Chao
  2012-11-27 16:52             ` WONG Sheng Chao
@ 2012-11-27 18:00             ` Gilles Chanteperdrix
  2012-11-28 15:12               ` WONG Sheng Chao
  1 sibling, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-27 18:00 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
> Hi Gilles
> 
> Following your advice i tracked down the include files which need to be 
> included to remove the error. The kernel now compiles without errors. I 
> followed the instructions in
> 
> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
> 
> to change the timer.c and also changing the .handle_irq with 
> ipipe_handle_multi_irq
> 
>  From the serial terminal i noticed that with CONFIG_IPIPE = ON the 
> timer is used correctly as in the above post but it hangs at

Are you sure the timer is running correctly?


> Any advice on how to proceed to debug this problem? I attach the 
> config files of two cases for your reference.

I would put a printk in linux timer irq handler.


-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
       [not found] <mailman.2.1354034873.1423.xenomai@xenomai.org>
@ 2012-11-27 18:42 ` Stephan Kappertz
  2012-11-27 20:05   ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Stephan Kappertz @ 2012-11-27 18:42 UTC (permalink / raw)
  To: xenomai

> 
> Hi Gilles
> 
> Following your advice i tracked down the include files which need to be included to remove the error. The kernel now compiles without errors. I followed the instructions in
> 
> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
> 
> to change the timer.c and also changing the .handle_irq with ipipe_handle_multi_irq
> 
> From the serial terminal i noticed that with CONFIG_IPIPE = ON the timer is used correctly as in the above post but it hangs at
> 
> [    0.958295] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
> 
> I followed the troubleshooting guide at
> 
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Troubleshooting
> 
> With both CONFIG_XENOMAI and CONFIG_IPIPE off, the kernel was able to boot normally
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc version 4.5.4 20120305 (prerelease) (GCC) ) #1 Tue Nov 27 17:19:52 CET 2012
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] Machine: am335xevm
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] AM335X ES1.0 (sgx neon )
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
> [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 256MB = 256MB total
> [    0.000000] Memory: 252968k/252968k available, 9176k reserved, 0K highmem
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc05bdd54   (5848 kB)
> [    0.000000]       .init : 0xc05be000 - 0xc0600000   ( 264 kB)
> [    0.000000]       .data : 0xc0600000 - 0xc064eea8   ( 316 kB)
> [    0.000000]        .bss : 0xc064eecc - 0xc06b9214   ( 425 kB)
> [    0.000000] NR_IRQS:410 nr_irqs:410 410
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
> [    0.000000] Total of 128 interrupts on 1 active controller
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
> [    0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
> [    0.000000] Console: colour dummy device 80x30
> [    0.000244] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
> [    0.118703] pid_max: default: 32768 minimum: 301
> [    0.118865] Security Framework initialized
> [    0.118942] Mount-cache hash table entries: 512
> [    0.119410] Initializing cgroup subsys cpuacct
> [    0.119462] Initializing cgroup subsys devices
> [    0.119478] Initializing cgroup subsys freezer
> [    0.119558] CPU: Testing write buffer coherency: ok
> [    0.120847] devtmpfs: initialized
> [    0.141418] omap_hwmod: gfx: failed to hardreset
> [    0.158137] omap_hwmod: pruss: failed to hardreset
> [    0.158801] print_constraints: dummy:
> [    0.159070] NET: Registered protocol family 16
> [    0.160363] OMAP GPIO hardware version 0.1
> [    0.161676] omap_mux_init: Add partition: #1: core, flags: 0
> [    0.163248]  omap_i2c.1: alias fck already exists
> [    0.163661] hw-breakpoint: debug architecture 0x4 unsupported.
> [    0.163848]  omap2_mcspi.1: alias fck already exists
> [    0.163985]  omap2_mcspi.2: alias fck already exists
> [    0.164171]  edma.0: alias fck already exists
> [    0.164198]  edma.0: alias fck already exists
> [    0.164222]  edma.0: alias fck already exists
> [    0.164320] cape: pcm register
> [    0.174334] bio: create slab <bio-0> at 0
> [    0.175680] SCSI subsystem initialized
> [    0.176720] usbcore: registered new interface driver usbfs
> [    0.176869] usbcore: registered new interface driver hub
> [    0.177082] usbcore: registered new device driver usb
> [    0.177245] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, plat_mode=0x3
> [    0.177408] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, plat_mode=0x1
> [    0.177955] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
> [    0.179282] Advanced Linux Sound Architecture Driver Version 1.0.24.
> [    0.179941] Switching to clocksource gp timer
> [    0.207177] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    0.207397] musb-hdrc musb-hdrc.0: dma type: pio
> [    0.207605] MUSB0 controller's USBSS revision = 4ea20800
> [    0.208120] musb-hdrc musb-hdrc.0: USB OTG mode controller at d081c000 using PIO, IRQ 18
> [    0.208468] musb-hdrc musb-hdrc.1: dma type: pio
> [    0.208658] MUSB1 controller's USBSS revision = 4ea20800
> [    0.208803] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
> [    0.208912] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
> [    0.209083] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    0.209106] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    0.209124] usb usb1: Product: MUSB HDRC host driver
> [    0.209140] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
> [    0.209155] usb usb1: SerialNumber: musb-hdrc.1
> [    0.209949] hub 1-0:1.0: USB hub found
> [    0.210075] hub 1-0:1.0: 1 port detected
> [    0.210643] musb-hdrc musb-hdrc.1: USB Host mode controller at d081e800 using PIO, IRQ 19
> [    0.211105] NET: Registered protocol family 2
> [    0.211358] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.211866] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> [    0.212090] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> [    0.212226] TCP: Hash tables configured (established 8192 bind 8192)
> [    0.212242] TCP reno registered
> [    0.212260] UDP hash table entries: 256 (order: 0, 4096 bytes)
> [    0.212292] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> [    0.212623] NET: Registered protocol family 1
> [    0.213057] RPC: Registered named UNIX socket transport module.
> [    0.213077] RPC: Registered udp transport module.
> [    0.213090] RPC: Registered tcp transport module.
> [    0.213103] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.213649] cpuidle-am33xx cpuidle-am33xx.0: failed to register driver
> [    0.215173] audit: initializing netlink socket (disabled)
> [    0.215242] type=2000 audit(0.210:1): initialized
> [    0.226622] VFS: Disk quotas dquot_6.5.2
> [    0.226705] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [    0.228060] msgmni has been set to 494
> [    0.229491] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
> [    0.229517] io scheduler noop registered
> [    0.229531] io scheduler deadline registered
> [    0.229594] io scheduler cfq registered (default)
> [    0.230798] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.232402] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
> [    0.834573] console [ttyO0] enabled
> [    0.838986] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
> [    0.846942] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
> [    0.854853] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
> [    0.862748] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4
> [    0.870645] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a OMAP UART5
> [    0.879787] brd: module loaded
> [    0.887606] loop: module loaded
> [    0.891067] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
> [    0.949996] No daughter card found
> [    0.953630] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
> [    0.968911] Board name: A335BONE
> [    0.972328] Board version: 00A6
> [    0.975629] The board is a AM335x Beaglebone.
> [    0.980934] tps65217 1-0024: TPS65217 ID 0xf version 1.1
> [    0.988396] print_constraints: DCDC1: 900 <--> 1800 mV at 1800 mV
> [    0.996824] print_constraints: DCDC2: 900 <--> 3300 mV at 1275 mV
> [    1.005246] print_constraints: DCDC3: 900 <--> 1500 mV at 1100 mV
> [    1.013632] print_constraints: LDO1: 1000 <--> 3300 mV at 1800 mV
> [    1.022025] print_constraints: LDO2: 900 <--> 3300 mV at 3300 mV
> [    1.030303] print_constraints: LDO3: 1800 <--> 3300 mV at 3300 mV
> [    1.038701] print_constraints: LDO4: 1800 <--> 3300 mV at 3300 mV
> [    1.045724] Maximum current provided by the USB port is 500mA which is not sufficient when operating @OPP120 and OPPTURBO. The current requirement for some use-cases using OPP100 might also exceed the maximum current that the USB port can provide. Unless you are fully confident that the current requirements for OPP100 use-case don't exceed the USB limits, switching to AC power is recommended.
> [    1.082552]  omap_i2c.3: alias fck already exists
> [    1.087824] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
> [    1.098210] at24 3-0054: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
> [    1.159999] BeagleBone cape EEPROM: could not read eeprom at address 0x54
> 
> 
> Here's the log with CONFIG_XENOMAI = OFF and CONFIG_IPIPE = ON
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc version 4.5.4 20120305 (prerelease) (GCC) ) #1 PREEMPT Tue Nov 27 17:36:26 CET 2012
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] Machine: am335xevm
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] AM335X ES1.0 (sgx neon )
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
> [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 256MB = 256MB total
> [    0.000000] Memory: 252464k/252464k available, 9680k reserved, 0K highmem
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc061123c   (6181 kB)
> [    0.000000]       .init : 0xc0612000 - 0xc0655000   ( 268 kB)
> [    0.000000]       .data : 0xc0656000 - 0xc06a6868   ( 323 kB)
> [    0.000000]        .bss : 0xc06a688c - 0xc0737d54   ( 582 kB)
> [    0.000000] NR_IRQS:410 nr_irqs:410 410
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
> [    0.000000] Total of 128 interrupts on 1 active controller
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000 Hz
> [    0.000000] I-pipe, 24.000 MHz clocksource
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
> [    0.000000] Interrupt pipeline (release #1)
> [    0.000000] Console: colour dummy device 80x30
> [    0.000735] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
> [    0.118663] pid_max: default: 32768 minimum: 301
> [    0.118881] Security Framework initialized
> [    0.118984] Mount-cache hash table entries: 512
> [    0.119570] Initializing cgroup subsys cpuacct
> [    0.119627] Initializing cgroup subsys devices
> [    0.119645] Initializing cgroup subsys freezer
> [    0.119746] CPU: Testing write buffer coherency: ok
> [    0.121323] devtmpfs: initialized
> [    0.142538] omap_hwmod: gfx: failed to hardreset
> [    0.159288] omap_hwmod: pruss: failed to hardreset
> [    0.160005] print_constraints: dummy:
> [    0.160342] NET: Registered protocol family 16
> [    0.161800] OMAP GPIO hardware version 0.1
> [    0.163363] omap_mux_init: Add partition: #1: core, flags: 0
> [    0.165179]  omap_i2c.1: alias fck already exists
> [    0.165644] hw-breakpoint: debug architecture 0x4 unsupported.
> [    0.165856]  omap2_mcspi.1: alias fck already exists
> [    0.166011]  omap2_mcspi.2: alias fck already exists
> [    0.166215]  edma.0: alias fck already exists
> [    0.166245]  edma.0: alias fck already exists
> [    0.166271]  edma.0: alias fck already exists
> [    0.166381] cape: pcm register
> [    0.177948] bio: create slab <bio-0> at 0
> [    0.179694] SCSI subsystem initialized
> [    0.180900] usbcore: registered new interface driver usbfs
> [    0.181072] usbcore: registered new interface driver hub
> [    0.181333] usbcore: registered new device driver usb
> [    0.181530] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, plat_mode=0x3
> [    0.181709] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, plat_mode=0x1
> [    0.182363] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
> [    0.183779] Advanced Linux Sound Architecture Driver Version 1.0.24.
> [    0.184506] Switching to clocksource ipipe_tsc
> [    0.220287] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    0.220545] musb-hdrc musb-hdrc.0: dma type: pio
> [    0.220788] MUSB0 controller's USBSS revision = 4ea20800
> [    0.221366] musb-hdrc musb-hdrc.0: USB OTG mode controller at d081c000 using PIO, IRQ 18
> [    0.221763] musb-hdrc musb-hdrc.1: dma type: pio
> [    0.221979] MUSB1 controller's USBSS revision = 4ea20800
> [    0.222143] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
> [    0.222276] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
> [    0.222485] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    0.222510] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    0.222532] usb usb1: Product: MUSB HDRC host driver
> [    0.222549] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
> [    0.222566] usb usb1: SerialNumber: musb-hdrc.1
> [    0.223435] hub 1-0:1.0: USB hub found
> [    0.223478] hub 1-0:1.0: 1 port detected
> [    0.224106] musb-hdrc musb-hdrc.1: USB Host mode controller at d081e800 using PIO, IRQ 19
> [    0.224699] NET: Registered protocol family 2
> [    0.224989] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.225617] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> [    0.225845] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> [    0.225982] TCP: Hash tables configured (established 8192 bind 8192)
> [    0.226001] TCP reno registered
> [    0.226021] UDP hash table entries: 256 (order: 0, 4096 bytes)
> [    0.226056] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> [    0.226446] NET: Registered protocol family 1
> [    0.227121] RPC: Registered named UNIX socket transport module.
> [    0.227146] RPC: Registered udp transport module.
> [    0.227162] RPC: Registered tcp transport module.
> [    0.227176] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.227832] cpuidle-am33xx cpuidle-am33xx.0: failed to register driver
> [    0.229751] audit: initializing netlink socket (disabled)
> [    0.229835] type=2000 audit(0.180:1): initialized
> [    0.241446] VFS: Disk quotas dquot_6.5.2
> [    0.241550] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [    0.243359] msgmni has been set to 493
> [    0.245251] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
> [    0.245282] io scheduler noop registered
> [    0.245297] io scheduler deadline registered
> [    0.245392] io scheduler cfq registered (default)
> [    0.246642] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.248598] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
> [    0.860338] console [ttyO0] enabled
> [    0.864664] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
> [    0.872618] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
> [    0.880574] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
> [    0.888525] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4
> [    0.896491] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a OMAP UART5
> [    0.905879] brd: module loaded
> [    0.914179] loop: module loaded
> [    0.917564] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
> 
> 
> Any advice on how to proceed to debug this problem? I attach the config files of two cases for your reference.
> 

The kernel hangs because the eeprom driver waits based on timer ticks. The timer ticks don't increment because the ipipe irq handler is never called.

In arch/arm/mach-omap2/irq.c: static inline void omap_intc_handle_irq you need to replace handle_IRQ by ipipe_handle_multi_irq.

- Stephan




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-27 18:42 ` Stephan Kappertz
@ 2012-11-27 20:05   ` WONG Sheng Chao
  0 siblings, 0 replies; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-27 20:05 UTC (permalink / raw)
  To: Stephan Kappertz; +Cc: xenomai

On Tue, 27 Nov 2012 19:42:21 +0100, Stephan Kappertz wrote:
>>
>> Hi Gilles
>>
>> Following your advice i tracked down the include files which need to 
>> be included to remove the error. The kernel now compiles without 
>> errors. I followed the instructions in
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>
>> to change the timer.c and also changing the .handle_irq with 
>> ipipe_handle_multi_irq
>>
>> From the serial terminal i noticed that with CONFIG_IPIPE = ON the 
>> timer is used correctly as in the above post but it hangs at
>>
>> [    0.958295] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
>> bytes/write
>>
>> I followed the troubleshooting guide at
>>
>> 
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Troubleshooting
>>
>> With both CONFIG_XENOMAI and CONFIG_IPIPE off, the kernel was able 
>> to boot normally
>>
>> Uncompressing Linux... done, booting the kernel.
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc 
>> version 4.5.4 20120305 (prerelease) (GCC) ) #1 Tue Nov 27 17:19:52 CET 
>> 2012
>> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>> cr=10c53c7d
>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT 
>> aliasing instruction cache
>> [    0.000000] Machine: am335xevm
>> [    0.000000] Memory policy: ECC disabled, Data cache writeback
>> [    0.000000] AM335X ES1.0 (sgx neon )
>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping 
>> on.  Total pages: 65024
>> [    0.000000] Kernel command line: console=ttyO0,115200n8 
>> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
>> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 
>> 131072 bytes)
>> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 
>> 65536 bytes)
>> [    0.000000] Memory: 256MB = 256MB total
>> [    0.000000] Memory: 252968k/252968k available, 9176k reserved, 0K 
>> highmem
>> [    0.000000] Virtual kernel memory layout:
>> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
>> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
>> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>> [    0.000000]       .text : 0xc0008000 - 0xc05bdd54   (5848 kB)
>> [    0.000000]       .init : 0xc05be000 - 0xc0600000   ( 264 kB)
>> [    0.000000]       .data : 0xc0600000 - 0xc064eea8   ( 316 kB)
>> [    0.000000]        .bss : 0xc064eecc - 0xc06b9214   ( 425 kB)
>> [    0.000000] NR_IRQS:410 nr_irqs:410 410
>> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 
>> 128 interrupts
>> [    0.000000] Total of 128 interrupts on 1 active controller
>> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
>> [    0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
>> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
>> every 178956ms
>> [    0.000000] Console: colour dummy device 80x30
>> [    0.000244] Calibrating delay loop... 498.89 BogoMIPS 
>> (lpj=2494464)
>> [    0.118703] pid_max: default: 32768 minimum: 301
>> [    0.118865] Security Framework initialized
>> [    0.118942] Mount-cache hash table entries: 512
>> [    0.119410] Initializing cgroup subsys cpuacct
>> [    0.119462] Initializing cgroup subsys devices
>> [    0.119478] Initializing cgroup subsys freezer
>> [    0.119558] CPU: Testing write buffer coherency: ok
>> [    0.120847] devtmpfs: initialized
>> [    0.141418] omap_hwmod: gfx: failed to hardreset
>> [    0.158137] omap_hwmod: pruss: failed to hardreset
>> [    0.158801] print_constraints: dummy:
>> [    0.159070] NET: Registered protocol family 16
>> [    0.160363] OMAP GPIO hardware version 0.1
>> [    0.161676] omap_mux_init: Add partition: #1: core, flags: 0
>> [    0.163248]  omap_i2c.1: alias fck already exists
>> [    0.163661] hw-breakpoint: debug architecture 0x4 unsupported.
>> [    0.163848]  omap2_mcspi.1: alias fck already exists
>> [    0.163985]  omap2_mcspi.2: alias fck already exists
>> [    0.164171]  edma.0: alias fck already exists
>> [    0.164198]  edma.0: alias fck already exists
>> [    0.164222]  edma.0: alias fck already exists
>> [    0.164320] cape: pcm register
>> [    0.174334] bio: create slab <bio-0> at 0
>> [    0.175680] SCSI subsystem initialized
>> [    0.176720] usbcore: registered new interface driver usbfs
>> [    0.176869] usbcore: registered new interface driver hub
>> [    0.177082] usbcore: registered new device driver usb
>> [    0.177245] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
>> plat_mode=0x3
>> [    0.177408] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
>> plat_mode=0x1
>> [    0.177955] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
>> [    0.179282] Advanced Linux Sound Architecture Driver Version 
>> 1.0.24.
>> [    0.179941] Switching to clocksource gp timer
>> [    0.207177] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>> [    0.207397] musb-hdrc musb-hdrc.0: dma type: pio
>> [    0.207605] MUSB0 controller's USBSS revision = 4ea20800
>> [    0.208120] musb-hdrc musb-hdrc.0: USB OTG mode controller at 
>> d081c000 using PIO, IRQ 18
>> [    0.208468] musb-hdrc musb-hdrc.1: dma type: pio
>> [    0.208658] MUSB1 controller's USBSS revision = 4ea20800
>> [    0.208803] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
>> [    0.208912] musb-hdrc musb-hdrc.1: new USB bus registered, 
>> assigned bus number 1
>> [    0.209083] usb usb1: New USB device found, idVendor=1d6b, 
>> idProduct=0002
>> [    0.209106] usb usb1: New USB device strings: Mfr=3, Product=2, 
>> SerialNumber=1
>> [    0.209124] usb usb1: Product: MUSB HDRC host driver
>> [    0.209140] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
>> [    0.209155] usb usb1: SerialNumber: musb-hdrc.1
>> [    0.209949] hub 1-0:1.0: USB hub found
>> [    0.210075] hub 1-0:1.0: 1 port detected
>> [    0.210643] musb-hdrc musb-hdrc.1: USB Host mode controller at 
>> d081e800 using PIO, IRQ 19
>> [    0.211105] NET: Registered protocol family 2
>> [    0.211358] IP route cache hash table entries: 2048 (order: 1, 
>> 8192 bytes)
>> [    0.211866] TCP established hash table entries: 8192 (order: 4, 
>> 65536 bytes)
>> [    0.212090] TCP bind hash table entries: 8192 (order: 3, 32768 
>> bytes)
>> [    0.212226] TCP: Hash tables configured (established 8192 bind 
>> 8192)
>> [    0.212242] TCP reno registered
>> [    0.212260] UDP hash table entries: 256 (order: 0, 4096 bytes)
>> [    0.212292] UDP-Lite hash table entries: 256 (order: 0, 4096 
>> bytes)
>> [    0.212623] NET: Registered protocol family 1
>> [    0.213057] RPC: Registered named UNIX socket transport module.
>> [    0.213077] RPC: Registered udp transport module.
>> [    0.213090] RPC: Registered tcp transport module.
>> [    0.213103] RPC: Registered tcp NFSv4.1 backchannel transport 
>> module.
>> [    0.213649] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
>> driver
>> [    0.215173] audit: initializing netlink socket (disabled)
>> [    0.215242] type=2000 audit(0.210:1): initialized
>> [    0.226622] VFS: Disk quotas dquot_6.5.2
>> [    0.226705] Dquot-cache hash table entries: 1024 (order 0, 4096 
>> bytes)
>> [    0.228060] msgmni has been set to 494
>> [    0.229491] Block layer SCSI generic (bsg) driver version 0.4 
>> loaded (major 252)
>> [    0.229517] io scheduler noop registered
>> [    0.229531] io scheduler deadline registered
>> [    0.229594] io scheduler cfq registered (default)
>> [    0.230798] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
>> enabled
>> [    0.232402] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a 
>> OMAP UART0
>> [    0.834573] console [ttyO0] enabled
>> [    0.838986] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a 
>> OMAP UART1
>> [    0.846942] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a 
>> OMAP UART2
>> [    0.854853] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a 
>> OMAP UART3
>> [    0.862748] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a 
>> OMAP UART4
>> [    0.870645] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a 
>> OMAP UART5
>> [    0.879787] brd: module loaded
>> [    0.887606] loop: module loaded
>> [    0.891067] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
>> bytes/write
>> [    0.949996] No daughter card found
>> [    0.953630] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64 
>> bytes/write
>> [    0.968911] Board name: A335BONE
>> [    0.972328] Board version: 00A6
>> [    0.975629] The board is a AM335x Beaglebone.
>> [    0.980934] tps65217 1-0024: TPS65217 ID 0xf version 1.1
>> [    0.988396] print_constraints: DCDC1: 900 <--> 1800 mV at 1800 mV
>> [    0.996824] print_constraints: DCDC2: 900 <--> 3300 mV at 1275 mV
>> [    1.005246] print_constraints: DCDC3: 900 <--> 1500 mV at 1100 mV
>> [    1.013632] print_constraints: LDO1: 1000 <--> 3300 mV at 1800 mV
>> [    1.022025] print_constraints: LDO2: 900 <--> 3300 mV at 3300 mV
>> [    1.030303] print_constraints: LDO3: 1800 <--> 3300 mV at 3300 mV
>> [    1.038701] print_constraints: LDO4: 1800 <--> 3300 mV at 3300 mV
>> [    1.045724] Maximum current provided by the USB port is 500mA 
>> which is not sufficient when operating @OPP120 and OPPTURBO. The 
>> current requirement for some use-cases using OPP100 might also exceed 
>> the maximum current that the USB port can provide. Unless you are 
>> fully confident that the current requirements for OPP100 use-case 
>> don't exceed the USB limits, switching to AC power is recommended.
>> [    1.082552]  omap_i2c.3: alias fck already exists
>> [    1.087824] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
>> [    1.098210] at24 3-0054: 32768 byte 24c256 EEPROM, writable, 64 
>> bytes/write
>> [    1.159999] BeagleBone cape EEPROM: could not read eeprom at 
>> address 0x54
>>
>>
>> Here's the log with CONFIG_XENOMAI = OFF and CONFIG_IPIPE = ON
>>
>> Uncompressing Linux... done, booting the kernel.
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 3.2.21-ipipe (chao@chao-laptop) (gcc 
>> version 4.5.4 20120305 (prerelease) (GCC) ) #1 PREEMPT Tue Nov 27 
>> 17:36:26 CET 2012
>> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>> cr=10c53c7d
>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT 
>> aliasing instruction cache
>> [    0.000000] Machine: am335xevm
>> [    0.000000] Memory policy: ECC disabled, Data cache writeback
>> [    0.000000] AM335X ES1.0 (sgx neon )
>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping 
>> on.  Total pages: 65024
>> [    0.000000] Kernel command line: console=ttyO0,115200n8 
>> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
>> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 
>> 131072 bytes)
>> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 
>> 65536 bytes)
>> [    0.000000] Memory: 256MB = 256MB total
>> [    0.000000] Memory: 252464k/252464k available, 9680k reserved, 0K 
>> highmem
>> [    0.000000] Virtual kernel memory layout:
>> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>> [    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
>> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
>> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>> [    0.000000]       .text : 0xc0008000 - 0xc061123c   (6181 kB)
>> [    0.000000]       .init : 0xc0612000 - 0xc0655000   ( 268 kB)
>> [    0.000000]       .data : 0xc0656000 - 0xc06a6868   ( 323 kB)
>> [    0.000000]        .bss : 0xc06a688c - 0xc0737d54   ( 582 kB)
>> [    0.000000] NR_IRQS:410 nr_irqs:410 410
>> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 
>> 128 interrupts
>> [    0.000000] Total of 128 interrupts on 1 active controller
>> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
>> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000 Hz
>> [    0.000000] I-pipe, 24.000 MHz clocksource
>> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
>> every 178956ms
>> [    0.000000] Interrupt pipeline (release #1)
>> [    0.000000] Console: colour dummy device 80x30
>> [    0.000735] Calibrating delay loop... 498.89 BogoMIPS 
>> (lpj=2494464)
>> [    0.118663] pid_max: default: 32768 minimum: 301
>> [    0.118881] Security Framework initialized
>> [    0.118984] Mount-cache hash table entries: 512
>> [    0.119570] Initializing cgroup subsys cpuacct
>> [    0.119627] Initializing cgroup subsys devices
>> [    0.119645] Initializing cgroup subsys freezer
>> [    0.119746] CPU: Testing write buffer coherency: ok
>> [    0.121323] devtmpfs: initialized
>> [    0.142538] omap_hwmod: gfx: failed to hardreset
>> [    0.159288] omap_hwmod: pruss: failed to hardreset
>> [    0.160005] print_constraints: dummy:
>> [    0.160342] NET: Registered protocol family 16
>> [    0.161800] OMAP GPIO hardware version 0.1
>> [    0.163363] omap_mux_init: Add partition: #1: core, flags: 0
>> [    0.165179]  omap_i2c.1: alias fck already exists
>> [    0.165644] hw-breakpoint: debug architecture 0x4 unsupported.
>> [    0.165856]  omap2_mcspi.1: alias fck already exists
>> [    0.166011]  omap2_mcspi.2: alias fck already exists
>> [    0.166215]  edma.0: alias fck already exists
>> [    0.166245]  edma.0: alias fck already exists
>> [    0.166271]  edma.0: alias fck already exists
>> [    0.166381] cape: pcm register
>> [    0.177948] bio: create slab <bio-0> at 0
>> [    0.179694] SCSI subsystem initialized
>> [    0.180900] usbcore: registered new interface driver usbfs
>> [    0.181072] usbcore: registered new interface driver hub
>> [    0.181333] usbcore: registered new device driver usb
>> [    0.181530] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, 
>> plat_mode=0x3
>> [    0.181709] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, 
>> plat_mode=0x1
>> [    0.182363] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
>> [    0.183779] Advanced Linux Sound Architecture Driver Version 
>> 1.0.24.
>> [    0.184506] Switching to clocksource ipipe_tsc
>> [    0.220287] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>> [    0.220545] musb-hdrc musb-hdrc.0: dma type: pio
>> [    0.220788] MUSB0 controller's USBSS revision = 4ea20800
>> [    0.221366] musb-hdrc musb-hdrc.0: USB OTG mode controller at 
>> d081c000 using PIO, IRQ 18
>> [    0.221763] musb-hdrc musb-hdrc.1: dma type: pio
>> [    0.221979] MUSB1 controller's USBSS revision = 4ea20800
>> [    0.222143] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
>> [    0.222276] musb-hdrc musb-hdrc.1: new USB bus registered, 
>> assigned bus number 1
>> [    0.222485] usb usb1: New USB device found, idVendor=1d6b, 
>> idProduct=0002
>> [    0.222510] usb usb1: New USB device strings: Mfr=3, Product=2, 
>> SerialNumber=1
>> [    0.222532] usb usb1: Product: MUSB HDRC host driver
>> [    0.222549] usb usb1: Manufacturer: Linux 3.2.21-ipipe musb-hcd
>> [    0.222566] usb usb1: SerialNumber: musb-hdrc.1
>> [    0.223435] hub 1-0:1.0: USB hub found
>> [    0.223478] hub 1-0:1.0: 1 port detected
>> [    0.224106] musb-hdrc musb-hdrc.1: USB Host mode controller at 
>> d081e800 using PIO, IRQ 19
>> [    0.224699] NET: Registered protocol family 2
>> [    0.224989] IP route cache hash table entries: 2048 (order: 1, 
>> 8192 bytes)
>> [    0.225617] TCP established hash table entries: 8192 (order: 4, 
>> 65536 bytes)
>> [    0.225845] TCP bind hash table entries: 8192 (order: 3, 32768 
>> bytes)
>> [    0.225982] TCP: Hash tables configured (established 8192 bind 
>> 8192)
>> [    0.226001] TCP reno registered
>> [    0.226021] UDP hash table entries: 256 (order: 0, 4096 bytes)
>> [    0.226056] UDP-Lite hash table entries: 256 (order: 0, 4096 
>> bytes)
>> [    0.226446] NET: Registered protocol family 1
>> [    0.227121] RPC: Registered named UNIX socket transport module.
>> [    0.227146] RPC: Registered udp transport module.
>> [    0.227162] RPC: Registered tcp transport module.
>> [    0.227176] RPC: Registered tcp NFSv4.1 backchannel transport 
>> module.
>> [    0.227832] cpuidle-am33xx cpuidle-am33xx.0: failed to register 
>> driver
>> [    0.229751] audit: initializing netlink socket (disabled)
>> [    0.229835] type=2000 audit(0.180:1): initialized
>> [    0.241446] VFS: Disk quotas dquot_6.5.2
>> [    0.241550] Dquot-cache hash table entries: 1024 (order 0, 4096 
>> bytes)
>> [    0.243359] msgmni has been set to 493
>> [    0.245251] Block layer SCSI generic (bsg) driver version 0.4 
>> loaded (major 252)
>> [    0.245282] io scheduler noop registered
>> [    0.245297] io scheduler deadline registered
>> [    0.245392] io scheduler cfq registered (default)
>> [    0.246642] Serial: 8250/16550 driver, 4 ports, IRQ sharing 
>> enabled
>> [    0.248598] omap_uart.0: ttyO0 at MMIO 0x44e09000 (irq = 72) is a 
>> OMAP UART0
>> [    0.860338] console [ttyO0] enabled
>> [    0.864664] omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a 
>> OMAP UART1
>> [    0.872618] omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a 
>> OMAP UART2
>> [    0.880574] omap_uart.3: ttyO3 at MMIO 0x481a6000 (irq = 44) is a 
>> OMAP UART3
>> [    0.888525] omap_uart.4: ttyO4 at MMIO 0x481a8000 (irq = 45) is a 
>> OMAP UART4
>> [    0.896491] omap_uart.5: ttyO5 at MMIO 0x481aa000 (irq = 46) is a 
>> OMAP UART5
>> [    0.905879] brd: module loaded
>> [    0.914179] loop: module loaded
>> [    0.917564] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
>> bytes/write
>>
>>
>> Any advice on how to proceed to debug this problem? I attach the 
>> config files of two cases for your reference.
>>
>
> The kernel hangs because the eeprom driver waits based on timer
> ticks. The timer ticks don't increment because the ipipe irq handler
> is never called.
>
> In arch/arm/mach-omap2/irq.c: static inline void omap_intc_handle_irq
> you need to replace handle_IRQ by ipipe_handle_multi_irq.

>
> - Stephan
>
Hi Stephan

Actually i already replaced the handle_IRQ by ipipe_handle_multi_irq in 
arch/arm/mach-omap2/irq.c following  your previous discussion with 
Gilles. Probably i did a mistake in replacing the function. Since we are 
both using the beaglebone do you mind sending me a copy of your irq.c, 
so that i can compare and see what went wrong?

Best
Wong




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-27 18:00             ` Gilles Chanteperdrix
@ 2012-11-28 15:12               ` WONG Sheng Chao
  2012-11-28 17:40                 ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-28 15:12 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>> Hi Gilles
>>
>> Following your advice i tracked down the include files which need to 
>> be
>> included to remove the error. The kernel now compiles without 
>> errors. I
>> followed the instructions in
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>
>> to change the timer.c and also changing the .handle_irq with
>> ipipe_handle_multi_irq
>>
>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON the
>> timer is used correctly as in the above post but it hangs at
>
> Are you sure the timer is running correctly?
>
>
>> Any advice on how to proceed to debug this problem? I attach the
>> config files of two cases for your reference.
>
> I would put a printk in linux timer irq handler.

How should i come about debugging the timer irq handler?

Looking at the arch/arm/mach-omap2/timer.c i would think the timer 
handler is omap_itimer.irq ? But i am not sure how to verify it.


As for the omap_intc_handle_irq in arch/arm/mach-omap2/irq.c here is my 
function which i used from the vender

static inline void omap_intc_handle_irq(void __iomem 
*base_addr,unsigned int no_regs_req, struct pt_regs *regs)
{
	u32 irqnr = 0;

	do {
		int i = 0;

		for (i = 0; i < no_regs_req; i++) {
			irqnr = readl_relaxed(base_addr + 0x98 + (0x20 * i));
			if (irqnr)
				goto out;
		}

out:
		if (!irqnr)
			break;

		irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
		irqnr &= ACTIVEIRQ_MASK;

		if (irqnr)
		{
//			handle_IRQ(irqnr, regs);
			ipipe_handle_multi_irq(irqnr, regs); //This is where i added the 
ipipe_handle_multi_irq
		}

	} while (irqnr);
}

Is this the right place for it?

-WONG






^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 15:12               ` WONG Sheng Chao
@ 2012-11-28 17:40                 ` WONG Sheng Chao
  2012-11-28 18:14                   ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-28 17:40 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>> Hi Gilles
>>>
>>> Following your advice i tracked down the include files which need 
>>> to be
>>> included to remove the error. The kernel now compiles without 
>>> errors. I
>>> followed the instructions in
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>
>>> to change the timer.c and also changing the .handle_irq with
>>> ipipe_handle_multi_irq
>>>
>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON the
>>> timer is used correctly as in the above post but it hangs at
>>
>> Are you sure the timer is running correctly?
>>
>>
>>> Any advice on how to proceed to debug this problem? I attach the
>>> config files of two cases for your reference.
>>
>> I would put a printk in linux timer irq handler.
>
> How should i come about debugging the timer irq handler?
>
> Looking at the arch/arm/mach-omap2/timer.c i would think the timer
> handler is omap_itimer.irq ? But i am not sure how to verify it.
>
>
> As for the omap_intc_handle_irq in arch/arm/mach-omap2/irq.c here is
> my function which i used from the vender
>
> static inline void omap_intc_handle_irq(void __iomem
> *base_addr,unsigned int no_regs_req, struct pt_regs *regs)
> {
> u32 irqnr = 0;
>
> do {
> 	int i = 0;
>
> 	for (i = 0; i < no_regs_req; i++) {
> 		irqnr = readl_relaxed(base_addr + 0x98 + (0x20 * i));
> 		if (irqnr)
> 			goto out;
> 	}
>
> out:
> 	if (!irqnr)
> 		break;
>
> 	irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
> 	irqnr &= ACTIVEIRQ_MASK;
>
> 	if (irqnr)
> 	{
> //			handle_IRQ(irqnr, regs);
> 		ipipe_handle_multi_irq(irqnr, regs); //This is where i added the
> ipipe_handle_multi_irq
> 	}
>
> } while (irqnr);
> }
>
> Is this the right place for it?
>
> -WONG

Refering to this,

http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html

I believe that i should be put a printk in the function 
ipipe_mach_acktimer, as it is called when the linux timer interrupt, but 
I after checking in these files, i still couldn't find it.

./include/ipipe
./include/linux/ipipe_debug.h
./include/linux/ipipe_lock.h
./include/linux/ipipe_base.h
./include/linux/ipipe_tickdev.h
./include/linux/ipipe_trace.h
./include/linux/ipipe_compat.h
./include/linux/ipipe_domain.h
./include/linux/ipipe.h
./include/config/ipipe
./include/config/ipipe.h
./kernel/ipipe
./arch/blackfin/include/asm/ipipe_base.h
./arch/blackfin/include/asm/ipipe.h
./arch/blackfin/kernel/ipipe.c
./arch/arm/include/asm/ipipe_base.h
./arch/arm/include/asm/ipipe_hwirq.h
./arch/arm/include/asm/ipipe.h
./arch/arm/kernel/ipipe_tsc.o
./arch/arm/kernel/ipipe_tsc_asm.o
./arch/arm/kernel/ipipe.c
./arch/arm/kernel/ipipe_tsc.c
./arch/arm/kernel/ipipe_tsc_asm.S
./arch/arm/kernel/ipipe.o

Can someone point me to the right direction?

-WONG




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 17:40                 ` WONG Sheng Chao
@ 2012-11-28 18:14                   ` Gilles Chanteperdrix
  2012-11-28 18:49                     ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-28 18:14 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>> Hi Gilles
>>>>
>>>> Following your advice i tracked down the include files which need 
>>>> to be
>>>> included to remove the error. The kernel now compiles without 
>>>> errors. I
>>>> followed the instructions in
>>>>
>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>
>>>> to change the timer.c and also changing the .handle_irq with
>>>> ipipe_handle_multi_irq
>>>>
>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON the
>>>> timer is used correctly as in the above post but it hangs at
>>>
>>> Are you sure the timer is running correctly?
>>>
>>>
>>>> Any advice on how to proceed to debug this problem? I attach the
>>>> config files of two cases for your reference.
>>>
>>> I would put a printk in linux timer irq handler.
>>
>> How should i come about debugging the timer irq handler?
> 
> Refering to this,
> 
> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
> 
> I believe that i should be put a printk in the function 
> ipipe_mach_acktimer, as it is called when the linux timer interrupt, but 
> I after checking in these files, i still couldn't find it.

ipipe_mach_acktimer disappeared, it is in the pre I-pipe core patches.
The documentation for the I-pipe core patches on the ARM architecture is
here:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting

The linux timer interrupt handler given as example in this documentation
is "omap2_gp_timer_interrupt" function, and is probably the same for
your omap3 derivative.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 18:14                   ` Gilles Chanteperdrix
@ 2012-11-28 18:49                     ` WONG Sheng Chao
  2012-11-28 18:57                       ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-28 18:49 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>> Hi Gilles
>>>>>
>>>>> Following your advice i tracked down the include files which need
>>>>> to be
>>>>> included to remove the error. The kernel now compiles without
>>>>> errors. I
>>>>> followed the instructions in
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>
>>>>> to change the timer.c and also changing the .handle_irq with
>>>>> ipipe_handle_multi_irq
>>>>>
>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON 
>>>>> the
>>>>> timer is used correctly as in the above post but it hangs at
>>>>
>>>> Are you sure the timer is running correctly?
>>>>
>>>>
>>>>> Any advice on how to proceed to debug this problem? I attach the
>>>>> config files of two cases for your reference.
>>>>
>>>> I would put a printk in linux timer irq handler.
>>>
>>> How should i come about debugging the timer irq handler?
>>
>> Refering to this,
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>
>> I believe that i should be put a printk in the function
>> ipipe_mach_acktimer, as it is called when the linux timer interrupt, 
>> but
>> I after checking in these files, i still couldn't find it.
>
> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core 
> patches.
> The documentation for the I-pipe core patches on the ARM architecture 
> is
> here:
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>
> The linux timer interrupt handler given as example in this 
> documentation
> is "omap2_gp_timer_interrupt" function, and is probably the same for
> your omap3 derivative.

Thanks for the information. So to proceed i looked at the function

static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
	struct clock_event_device *evt = &clockevent_gpt;

	if (!clockevent_ipipe_stolen(evt))
		omap2_gp_timer_ack();

	if (num_online_cpus() == 1)
		__ipipe_tsc_update();

	evt->event_handler(evt);
	return IRQ_HANDLED;
}

when clockevent_ipipe_stolen == 0
the omap2_gp_timer_ack is called to acknowledge the linux timer 
interrupt (with CONFIG_XENOMAI = no)

I put a printk in omap2_gp_timer_ack and i notice that in both cases of 
CONFIG_IPIPE = yes and CONFIG_IPIPE = no

the omap2_gp_timer_ack function get called.

But i am not sure how to interrupt this. I guess this means that the 
timer interrupt is being handled. But it still does not tell me why the 
kernel does not boot properly when CONFIG_IPIPE = yes.









^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 18:49                     ` WONG Sheng Chao
@ 2012-11-28 18:57                       ` Gilles Chanteperdrix
  2012-11-28 19:34                         ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-28 18:57 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:

> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>> Hi Gilles
>>>>>>
>>>>>> Following your advice i tracked down the include files which need
>>>>>> to be
>>>>>> included to remove the error. The kernel now compiles without
>>>>>> errors. I
>>>>>> followed the instructions in
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>
>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>> ipipe_handle_multi_irq
>>>>>>
>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON 
>>>>>> the
>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>
>>>>> Are you sure the timer is running correctly?
>>>>>
>>>>>
>>>>>> Any advice on how to proceed to debug this problem? I attach the
>>>>>> config files of two cases for your reference.
>>>>>
>>>>> I would put a printk in linux timer irq handler.
>>>>
>>>> How should i come about debugging the timer irq handler?
>>>
>>> Refering to this,
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>
>>> I believe that i should be put a printk in the function
>>> ipipe_mach_acktimer, as it is called when the linux timer interrupt, 
>>> but
>>> I after checking in these files, i still couldn't find it.
>>
>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core 
>> patches.
>> The documentation for the I-pipe core patches on the ARM architecture 
>> is
>> here:
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>
>> The linux timer interrupt handler given as example in this 
>> documentation
>> is "omap2_gp_timer_interrupt" function, and is probably the same for
>> your omap3 derivative.
> 
> Thanks for the information. So to proceed i looked at the function
> 
> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
> {
> 	struct clock_event_device *evt = &clockevent_gpt;
> 
> 	if (!clockevent_ipipe_stolen(evt))
> 		omap2_gp_timer_ack();
> 
> 	if (num_online_cpus() == 1)
> 		__ipipe_tsc_update();
> 
> 	evt->event_handler(evt);
> 	return IRQ_HANDLED;
> }
> 
> when clockevent_ipipe_stolen == 0
> the omap2_gp_timer_ack is called to acknowledge the linux timer 
> interrupt (with CONFIG_XENOMAI = no)
> 
> I put a printk in omap2_gp_timer_ack and i notice that in both cases of 
> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
> 
> the omap2_gp_timer_ack function get called.
> 
> But i am not sure how to interrupt this. I guess this means that the 
> timer interrupt is being handled. But it still does not tell me why the 
> kernel does not boot properly when CONFIG_IPIPE = yes.


Put a static counter in the timer_ack function to only emit a printk
every HZ ticks, and check whether the timer is ticking when you get the
freeze in the at24c driver initialization.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 18:57                       ` Gilles Chanteperdrix
@ 2012-11-28 19:34                         ` WONG Sheng Chao
  2012-11-28 19:55                           ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-28 19:34 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>
>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>> Hi Gilles
>>>>>>>
>>>>>>> Following your advice i tracked down the include files which 
>>>>>>> need
>>>>>>> to be
>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>> errors. I
>>>>>>> followed the instructions in
>>>>>>>
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>
>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>> ipipe_handle_multi_irq
>>>>>>>
>>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON
>>>>>>> the
>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>
>>>>>> Are you sure the timer is running correctly?
>>>>>>
>>>>>>
>>>>>>> Any advice on how to proceed to debug this problem? I attach 
>>>>>>> the
>>>>>>> config files of two cases for your reference.
>>>>>>
>>>>>> I would put a printk in linux timer irq handler.
>>>>>
>>>>> How should i come about debugging the timer irq handler?
>>>>
>>>> Refering to this,
>>>>
>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>
>>>> I believe that i should be put a printk in the function
>>>> ipipe_mach_acktimer, as it is called when the linux timer 
>>>> interrupt,
>>>> but
>>>> I after checking in these files, i still couldn't find it.
>>>
>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>> patches.
>>> The documentation for the I-pipe core patches on the ARM 
>>> architecture
>>> is
>>> here:
>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>
>>> The linux timer interrupt handler given as example in this
>>> documentation
>>> is "omap2_gp_timer_interrupt" function, and is probably the same 
>>> for
>>> your omap3 derivative.
>>
>> Thanks for the information. So to proceed i looked at the function
>>
>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>> {
>> 	struct clock_event_device *evt = &clockevent_gpt;
>>
>> 	if (!clockevent_ipipe_stolen(evt))
>> 		omap2_gp_timer_ack();
>>
>> 	if (num_online_cpus() == 1)
>> 		__ipipe_tsc_update();
>>
>> 	evt->event_handler(evt);
>> 	return IRQ_HANDLED;
>> }
>>
>> when clockevent_ipipe_stolen == 0
>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>> interrupt (with CONFIG_XENOMAI = no)
>>
>> I put a printk in omap2_gp_timer_ack and i notice that in both cases 
>> of
>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>
>> the omap2_gp_timer_ack function get called.
>>
>> But i am not sure how to interrupt this. I guess this means that the
>> timer interrupt is being handled. But it still does not tell me why 
>> the
>> kernel does not boot properly when CONFIG_IPIPE = yes.
>
>
> Put a static counter in the timer_ack function to only emit a printk
> every HZ ticks, and check whether the timer is ticking when you get 
> the
> freeze in the at24c driver initialization.

Yes the timer is still ticking after the freeze in the at24c driver 
initialization. Does this means that  the ipipe_handle_multi_irq in 
omap_intc_handle_irq is not handling the multiple irq properly?




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 19:34                         ` WONG Sheng Chao
@ 2012-11-28 19:55                           ` Gilles Chanteperdrix
  2012-11-28 20:22                             ` WONG Sheng Chao
  2012-11-29 12:10                             ` WONG Sheng Chao
  0 siblings, 2 replies; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-28 19:55 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:

> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>
>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>> Hi Gilles
>>>>>>>>
>>>>>>>> Following your advice i tracked down the include files which 
>>>>>>>> need
>>>>>>>> to be
>>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>>> errors. I
>>>>>>>> followed the instructions in
>>>>>>>>
>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>
>>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>
>>>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = ON
>>>>>>>> the
>>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>>
>>>>>>> Are you sure the timer is running correctly?
>>>>>>>
>>>>>>>
>>>>>>>> Any advice on how to proceed to debug this problem? I attach 
>>>>>>>> the
>>>>>>>> config files of two cases for your reference.
>>>>>>>
>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>
>>>>>> How should i come about debugging the timer irq handler?
>>>>>
>>>>> Refering to this,
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>
>>>>> I believe that i should be put a printk in the function
>>>>> ipipe_mach_acktimer, as it is called when the linux timer 
>>>>> interrupt,
>>>>> but
>>>>> I after checking in these files, i still couldn't find it.
>>>>
>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>> patches.
>>>> The documentation for the I-pipe core patches on the ARM 
>>>> architecture
>>>> is
>>>> here:
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>
>>>> The linux timer interrupt handler given as example in this
>>>> documentation
>>>> is "omap2_gp_timer_interrupt" function, and is probably the same 
>>>> for
>>>> your omap3 derivative.
>>>
>>> Thanks for the information. So to proceed i looked at the function
>>>
>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>>> {
>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>
>>> 	if (!clockevent_ipipe_stolen(evt))
>>> 		omap2_gp_timer_ack();
>>>
>>> 	if (num_online_cpus() == 1)
>>> 		__ipipe_tsc_update();
>>>
>>> 	evt->event_handler(evt);
>>> 	return IRQ_HANDLED;
>>> }
>>>
>>> when clockevent_ipipe_stolen == 0
>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>> interrupt (with CONFIG_XENOMAI = no)
>>>
>>> I put a printk in omap2_gp_timer_ack and i notice that in both cases 
>>> of
>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>
>>> the omap2_gp_timer_ack function get called.
>>>
>>> But i am not sure how to interrupt this. I guess this means that the
>>> timer interrupt is being handled. But it still does not tell me why 
>>> the
>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>
>>
>> Put a static counter in the timer_ack function to only emit a printk
>> every HZ ticks, and check whether the timer is ticking when you get 
>> the
>> freeze in the at24c driver initialization.
> 
> Yes the timer is still ticking after the freeze in the at24c driver 
> initialization. Does this means that  the ipipe_handle_multi_irq in 
> omap_intc_handle_irq is not handling the multiple irq properly?


No. It simply means the problem is not the timer. Next usual suspect is
the clocksource. Did you get the message about clocksource switching to
ipipe_tsc and does ipipe_tsc_get return increasing values?

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 19:55                           ` Gilles Chanteperdrix
@ 2012-11-28 20:22                             ` WONG Sheng Chao
  2012-11-29 12:10                             ` WONG Sheng Chao
  1 sibling, 0 replies; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-28 20:22 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Wed, 28 Nov 2012 20:55:24 +0100, Gilles Chanteperdrix wrote:
> On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:
>
>> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>>
>>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>>> Hi Gilles
>>>>>>>>>
>>>>>>>>> Following your advice i tracked down the include files which
>>>>>>>>> need
>>>>>>>>> to be
>>>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>>>> errors. I
>>>>>>>>> followed the instructions in
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>>
>>>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>>
>>>>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = 
>>>>>>>>> ON
>>>>>>>>> the
>>>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>>>
>>>>>>>> Are you sure the timer is running correctly
>>>>>>>>
>>>>>>>>
>>>>>>>>> Any advice on how to proceed to debug this problem? I attach
>>>>>>>>> the
>>>>>>>>> config files of two cases for your reference.
>>>>>>>>
>>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>>
>>>>>>> How should i come about debugging the timer irq handler?
>>>>>>
>>>>>> Refering to this,
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>>
>>>>>> I believe that i should be put a printk in the function
>>>>>> ipipe_mach_acktimer, as it is called when the linux timer
>>>>>> interrupt,
>>>>>> but
>>>>>> I after checking in these files, i still couldn't find it.
>>>>>
>>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>>> patches.
>>>>> The documentation for the I-pipe core patches on the ARM
>>>>> architecture
>>>>> is
>>>>> here:
>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>
>>>>> The linux timer interrupt handler given as example in this
>>>>> documentation
>>>>> is "omap2_gp_timer_interrupt" function, and is probably the same
>>>>> for
>>>>> your omap3 derivative.
>>>>
>>>> Thanks for the information. So to proceed i looked at the function
>>>>
>>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>>>> {
>>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>>
>>>> 	if (!clockevent_ipipe_stolen(evt))
>>>> 		omap2_gp_timer_ack();
>>>>
>>>> 	if (num_online_cpus() == 1)
>>>> 		__ipipe_tsc_update();
>>>>
>>>> 	evt->event_handler(evt);
>>>> 	return IRQ_HANDLED;
>>>> }
>>>>
>>>> when clockevent_ipipe_stolen == 0
>>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>>> interrupt (with CONFIG_XENOMAI = no)
>>>>
>>>> I put a printk in omap2_gp_timer_ack and i notice that in both 
>>>> cases
>>>> of
>>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>>
>>>> the omap2_gp_timer_ack function get called.
>>>>
>>>> But i am not sure how to interrupt this. I guess this means that 
>>>> the
>>>> timer interrupt is being handled. But it still does not tell me 
>>>> why
>>>> the
>>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>>
>>>
>>> Put a static counter in the timer_ack function to only emit a 
>>> printk
>>> every HZ ticks, and check whether the timer is ticking when you get
>>> the
>>> freeze in the at24c driver initialization.
>>
>> Yes the timer is still ticking after the freeze in the at24c driver
>> initialization. Does this means that  the ipipe_handle_multi_irq in
>> omap_intc_handle_irq is not handling the multiple irq properly?
>
>
> No. It simply means the problem is not the timer. Next usual suspect 
> is
> the clocksource. Did you get the message about clocksource switching 
> to
> ipipe_tsc and does ipipe_tsc_get return increasing values?

Yes the clock source did change to tsc in the boot message, I will take 
a look at the return value of I pipe_tsc_get.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-28 19:55                           ` Gilles Chanteperdrix
  2012-11-28 20:22                             ` WONG Sheng Chao
@ 2012-11-29 12:10                             ` WONG Sheng Chao
  1 sibling, 0 replies; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-29 12:10 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Wed, 28 Nov 2012 20:55:24 +0100, Gilles Chanteperdrix wrote:
> On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:
>
>> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>>
>>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>>> Hi Gilles
>>>>>>>>>
>>>>>>>>> Following your advice i tracked down the include files which
>>>>>>>>> need
>>>>>>>>> to be
>>>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>>>> errors. I
>>>>>>>>> followed the instructions in
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>>
>>>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>>
>>>>>>>>>  From the serial terminal i noticed that with CONFIG_IPIPE = 
>>>>>>>>> ON
>>>>>>>>> the
>>>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>>>
>>>>>>>> Are you sure the timer is running correctly?
>>>>>>>>
>>>>>>>>
>>>>>>>>> Any advice on how to proceed to debug this problem? I attach
>>>>>>>>> the
>>>>>>>>> config files of two cases for your reference.
>>>>>>>>
>>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>>
>>>>>>> How should i come about debugging the timer irq handler?
>>>>>>
>>>>>> Refering to this,
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>>
>>>>>> I believe that i should be put a printk in the function
>>>>>> ipipe_mach_acktimer, as it is called when the linux timer
>>>>>> interrupt,
>>>>>> but
>>>>>> I after checking in these files, i still couldn't find it.
>>>>>
>>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>>> patches.
>>>>> The documentation for the I-pipe core patches on the ARM
>>>>> architecture
>>>>> is
>>>>> here:
>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>
>>>>> The linux timer interrupt handler given as example in this
>>>>> documentation
>>>>> is "omap2_gp_timer_interrupt" function, and is probably the same
>>>>> for
>>>>> your omap3 derivative.
>>>>
>>>> Thanks for the information. So to proceed i looked at the function
>>>>
>>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>>>> {
>>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>>
>>>> 	if (!clockevent_ipipe_stolen(evt))
>>>> 		omap2_gp_timer_ack();
>>>>
>>>> 	if (num_online_cpus() == 1)
>>>> 		__ipipe_tsc_update();
>>>>
>>>> 	evt->event_handler(evt);
>>>> 	return IRQ_HANDLED;
>>>> }
>>>>
>>>> when clockevent_ipipe_stolen == 0
>>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>>> interrupt (with CONFIG_XENOMAI = no)
>>>>
>>>> I put a printk in omap2_gp_timer_ack and i notice that in both 
>>>> cases
>>>> of
>>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>>
>>>> the omap2_gp_timer_ack function get called.
>>>>
>>>> But i am not sure how to interrupt this. I guess this means that 
>>>> the
>>>> timer interrupt is being handled. But it still does not tell me 
>>>> why
>>>> the
>>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>>
>>>
>>> Put a static counter in the timer_ack function to only emit a 
>>> printk
>>> every HZ ticks, and check whether the timer is ticking when you get
>>> the
>>> freeze in the at24c driver initialization.
>>
>> Yes the timer is still ticking after the freeze in the at24c driver
>> initialization. Does this means that  the ipipe_handle_multi_irq in
>> omap_intc_handle_irq is not handling the multiple irq properly?
>
>
> No. It simply means the problem is not the timer. Next usual suspect 
> is
> the clocksource. Did you get the message about clocksource switching 
> to
> ipipe_tsc and does ipipe_tsc_get return increasing values?


I added a static counter and a printk on ipipe_tsc_get() under the 
omap2_gp_timer_ack function


static void omap2_gp_timer_ack(void)
{

	test_counter++;

	if(test_counter > 100)
	{
	 test_counter = 0;
	 printk("static counter overflow, ipipe_tsc_get = 
%llu\n",__ipipe_tsc_get());
	}

	__omap_dm_timer_write_status(&clkev, OMAP_TIMER_INT_OVERFLOW);
	__omap_dm_timer_read_status(&clkev);
}

And this is the boot message that i got

[    0.181481] Switching to clocksource ipipe_tsc
.
.
.
[    0.892249] brd: module loaded
[    0.900176] loop: module loaded
[    0.903603] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 
bytes/write
[    1.633867] static counter overflow, ipipe_tsc_get = 4294967296
[    2.650588] static counter overflow, ipipe_tsc_get = 4294967296
[    3.667300] static counter overflow, ipipe_tsc_get = 4294967296
[    4.684013] static counter overflow, ipipe_tsc_get = 4294967296
[    5.700726] static counter overflow, ipipe_tsc_get = 4294967296
[    6.717439] static counter overflow, ipipe_tsc_get = 4294967296
[    7.734150] static counter overflow, ipipe_tsc_get = 4294967296
[    8.750861] static counter overflow, ipipe_tsc_get = 4294967296

the ipipe_tsc_get is returning a constant value rather than increasing 
values. How can i further track down the source of the problem?





^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
       [not found] <mailman.0.1354186801.18650.xenomai@xenomai.org>
@ 2012-11-29 12:16 ` Stephan Kappertz
  2012-11-30  8:54   ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Stephan Kappertz @ 2012-11-29 12:16 UTC (permalink / raw)
  To: xenomai

> 
> Von: WONG Sheng Chao <wong@isir.upmc.fr>
> Betreff: Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
> Datum: 28. November 2012 21:22:41 MEZ
> An: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Kopie: xenomai@xenomai.org
> 
> 
> On Wed, 28 Nov 2012 20:55:24 +0100, Gilles Chanteperdrix wrote:
>> On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:
>> 
>>> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>>>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>>> 
>>>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix wrote:
>>>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>>>> Hi Gilles
>>>>>>>>>> 
>>>>>>>>>> Following your advice i tracked down the include files which
>>>>>>>>>> need
>>>>>>>>>> to be
>>>>>>>>>> included to remove the error. The kernel now compiles without
>>>>>>>>>> errors. I
>>>>>>>>>> followed the instructions in
>>>>>>>>>> 
>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>>> 
>>>>>>>>>> to change the timer.c and also changing the .handle_irq with
>>>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>>> 
>>>>>>>>>> From the serial terminal i noticed that with CONFIG_IPIPE = ON
>>>>>>>>>> the
>>>>>>>>>> timer is used correctly as in the above post but it hangs at
>>>>>>>>> 
>>>>>>>>> Are you sure the timer is running correctly
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Any advice on how to proceed to debug this problem? I attach
>>>>>>>>>> the
>>>>>>>>>> config files of two cases for your reference.
>>>>>>>>> 
>>>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>>> 
>>>>>>>> How should i come about debugging the timer irq handler?
>>>>>>> 
>>>>>>> Refering to this,
>>>>>>> 
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>>> 
>>>>>>> I believe that i should be put a printk in the function
>>>>>>> ipipe_mach_acktimer, as it is called when the linux timer
>>>>>>> interrupt,
>>>>>>> but
>>>>>>> I after checking in these files, i still couldn't find it.
>>>>>> 
>>>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>>>> patches.
>>>>>> The documentation for the I-pipe core patches on the ARM
>>>>>> architecture
>>>>>> is
>>>>>> here:
>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>> 
>>>>>> The linux timer interrupt handler given as example in this
>>>>>> documentation
>>>>>> is "omap2_gp_timer_interrupt" function, and is probably the same
>>>>>> for
>>>>>> your omap3 derivative.
>>>>> 
>>>>> Thanks for the information. So to proceed i looked at the function
>>>>> 
>>>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
>>>>> {
>>>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>>> 
>>>>> 	if (!clockevent_ipipe_stolen(evt))
>>>>> 		omap2_gp_timer_ack();
>>>>> 
>>>>> 	if (num_online_cpus() == 1)
>>>>> 		__ipipe_tsc_update();
>>>>> 
>>>>> 	evt->event_handler(evt);
>>>>> 	return IRQ_HANDLED;
>>>>> }
>>>>> 
>>>>> when clockevent_ipipe_stolen == 0
>>>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>>>> interrupt (with CONFIG_XENOMAI = no)
>>>>> 
>>>>> I put a printk in omap2_gp_timer_ack and i notice that in both cases
>>>>> of
>>>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>>> 
>>>>> the omap2_gp_timer_ack function get called.
>>>>> 
>>>>> But i am not sure how to interrupt this. I guess this means that the
>>>>> timer interrupt is being handled. But it still does not tell me why
>>>>> the
>>>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>>> 
>>>> 
>>>> Put a static counter in the timer_ack function to only emit a printk
>>>> every HZ ticks, and check whether the timer is ticking when you get
>>>> the
>>>> freeze in the at24c driver initialization.
>>> 
>>> Yes the timer is still ticking after the freeze in the at24c driver
>>> initialization. Does this means that  the ipipe_handle_multi_irq in
>>> omap_intc_handle_irq is not handling the multiple irq properly?
>> 
>> 
>> No. It simply means the problem is not the timer. Next usual suspect is
>> the clocksource. Did you get the message about clocksource switching to
>> ipipe_tsc and does ipipe_tsc_get return increasing values?
> 
> Yes the clock source did change to tsc in the boot message, I will take a look at the return value of I pipe_tsc_get.
> 
> 

The problem is that you are using the wrong timer.

You should have 

OMAP clockevent source: GPTIMER2 at 24000000 Hz
OMAP clocksource: GPTIMER1 at 24000000 Hz

in the startup console output for both the kernel with IPIPE disabled and with IPIPE enabled.

Thus in arch/arm/mach-omap2/timer.c you need to change the timer definitions accordingly.

What I did was:

#define OMAP2_MPU_SOURCE	"sys_ck"
#define OMAP3_MPU_SOURCE	OMAP2_MPU_SOURCE
#define OMAP4_MPU_SOURCE	"sys_clkin_ck"
#define OMAP2_32K_SOURCE	"func_32k_ck"
#define OMAP3_32K_SOURCE	"omap_32k_fck"
#define OMAP4_32K_SOURCE	"sys_32k_ck"
#define AM33XX_CLKEV_SOURCE OMAP4_MPU_SOURCE
#define AM33XX_RTC32K_SOURCE	"clk_32768_ck"

#ifdef CONFIG_OMAP_32K_TIMER
#define OMAP2_CLKEV_SOURCE	OMAP2_32K_SOURCE
#define OMAP3_CLKEV_SOURCE	OMAP3_32K_SOURCE
#define OMAP4_CLKEV_SOURCE	OMAP4_32K_SOURCE
#define AM33XX_MPU_SOURCE	AM33XX_RTC32K_SOURCE
#define OMAP3_SECURE_TIMER	12
#else
#define OMAP2_CLKEV_SOURCE	OMAP2_MPU_SOURCE
#define OMAP3_CLKEV_SOURCE	OMAP3_MPU_SOURCE
#define OMAP4_CLKEV_SOURCE	OMAP4_MPU_SOURCE
#define AM33XX_MPU_SOURCE	OMAP4_MPU_SOURCE
#define OMAP3_SECURE_TIMER	1
#endif
...
...
...
#ifdef CONFIG_ARCH_OMAP3

#ifndef CONFIG_SOC_OMAPAM33XX

#ifndef CONFIG_IPIPE
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
#else
OMAP_SYS_TIMER_INIT(3, 2, OMAP3_CLKEV_SOURCE, 3, OMAP3_MPU_SOURCE)
#endif
OMAP_SYS_TIMER(3)
OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
			2, OMAP3_MPU_SOURCE)
OMAP_SYS_TIMER(3_secure)

#else // #ifdef CONFIG_SOC_OMAPAM33XX

OMAP_SYS_TIMER_INIT(3, 2, AM33XX_CLKEV_SOURCE, 1, AM33XX_MPU_SOURCE)
OMAP_SYS_TIMER(3)

#endif

#endif

- Stephan


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-29 12:16 ` Stephan Kappertz
@ 2012-11-30  8:54   ` WONG Sheng Chao
  2012-11-30 11:45     ` Michael Haberler
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-11-30  8:54 UTC (permalink / raw)
  To: Stephan Kappertz; +Cc: xenomai

On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>
>> Von: WONG Sheng Chao <wong@isir.upmc.fr>
>> Betreff: Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone 
>> from Angstrom branch
>> Datum: 28. November 2012 21:22:41 MEZ
>> An: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>> Kopie: xenomai@xenomai.org
>>
>>
>> On Wed, 28 Nov 2012 20:55:24 +0100, Gilles Chanteperdrix wrote:
>>> On 11/28/2012 08:34 PM, WONG Sheng Chao wrote:
>>>
>>>> On Wed, 28 Nov 2012 19:57:50 +0100, Gilles Chanteperdrix wrote:
>>>>> On 11/28/2012 07:49 PM, WONG Sheng Chao wrote:
>>>>>
>>>>>> On Wed, 28 Nov 2012 19:14:41 +0100, Gilles Chanteperdrix wrote:
>>>>>>> On 11/28/2012 06:40 PM, WONG Sheng Chao wrote:
>>>>>>>> On Wed, 28 Nov 2012 16:12:58 +0100, WONG Sheng Chao wrote:
>>>>>>>>> On Tue, 27 Nov 2012 19:00:30 +0100, Gilles Chanteperdrix 
>>>>>>>>> wrote:
>>>>>>>>>> On 11/27/2012 05:40 PM, WONG Sheng Chao wrote:
>>>>>>>>>>> Hi Gilles
>>>>>>>>>>>
>>>>>>>>>>> Following your advice i tracked down the include files 
>>>>>>>>>>> which
>>>>>>>>>>> need
>>>>>>>>>>> to be
>>>>>>>>>>> included to remove the error. The kernel now compiles 
>>>>>>>>>>> without
>>>>>>>>>>> errors. I
>>>>>>>>>>> followed the instructions in
>>>>>>>>>>>
>>>>>>>>>>> 
>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-July/000481.html
>>>>>>>>>>>
>>>>>>>>>>> to change the timer.c and also changing the .handle_irq 
>>>>>>>>>>> with
>>>>>>>>>>> ipipe_handle_multi_irq
>>>>>>>>>>>
>>>>>>>>>>> From the serial terminal i noticed that with CONFIG_IPIPE = 
>>>>>>>>>>> ON
>>>>>>>>>>> the
>>>>>>>>>>> timer is used correctly as in the above post but it hangs 
>>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>>> Are you sure the timer is running correctly
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Any advice on how to proceed to debug this problem? I 
>>>>>>>>>>> attach
>>>>>>>>>>> the
>>>>>>>>>>> config files of two cases for your reference.
>>>>>>>>>>
>>>>>>>>>> I would put a printk in linux timer irq handler.
>>>>>>>>>
>>>>>>>>> How should i come about debugging the timer irq handler?
>>>>>>>>
>>>>>>>> Refering to this,
>>>>>>>>
>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-May/025838.html
>>>>>>>>
>>>>>>>> I believe that i should be put a printk in the function
>>>>>>>> ipipe_mach_acktimer, as it is called when the linux timer
>>>>>>>> interrupt,
>>>>>>>> but
>>>>>>>> I after checking in these files, i still couldn't find it.
>>>>>>>
>>>>>>> ipipe_mach_acktimer disappeared, it is in the pre I-pipe core
>>>>>>> patches.
>>>>>>> The documentation for the I-pipe core patches on the ARM
>>>>>>> architecture
>>>>>>> is
>>>>>>> here:
>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>>>
>>>>>>> The linux timer interrupt handler given as example in this
>>>>>>> documentation
>>>>>>> is "omap2_gp_timer_interrupt" function, and is probably the 
>>>>>>> same
>>>>>>> for
>>>>>>> your omap3 derivative.
>>>>>>
>>>>>> Thanks for the information. So to proceed i looked at the 
>>>>>> function
>>>>>>
>>>>>> static irqreturn_t omap2_gp_timer_interrupt(int irq, void 
>>>>>> *dev_id)
>>>>>> {
>>>>>> 	struct clock_event_device *evt = &clockevent_gpt;
>>>>>>
>>>>>> 	if (!clockevent_ipipe_stolen(evt))
>>>>>> 		omap2_gp_timer_ack();
>>>>>>
>>>>>> 	if (num_online_cpus() == 1)
>>>>>> 		__ipipe_tsc_update();
>>>>>>
>>>>>> 	evt->event_handler(evt);
>>>>>> 	return IRQ_HANDLED;
>>>>>> }
>>>>>>
>>>>>> when clockevent_ipipe_stolen == 0
>>>>>> the omap2_gp_timer_ack is called to acknowledge the linux timer
>>>>>> interrupt (with CONFIG_XENOMAI = no)
>>>>>>
>>>>>> I put a printk in omap2_gp_timer_ack and i notice that in both 
>>>>>> cases
>>>>>> of
>>>>>> CONFIG_IPIPE = yes and CONFIG_IPIPE = no
>>>>>>
>>>>>> the omap2_gp_timer_ack function get called.
>>>>>>
>>>>>> But i am not sure how to interrupt this. I guess this means that 
>>>>>> the
>>>>>> timer interrupt is being handled. But it still does not tell me 
>>>>>> why
>>>>>> the
>>>>>> kernel does not boot properly when CONFIG_IPIPE = yes.
>>>>>
>>>>>
>>>>> Put a static counter in the timer_ack function to only emit a 
>>>>> printk
>>>>> every HZ ticks, and check whether the timer is ticking when you 
>>>>> get
>>>>> the
>>>>> freeze in the at24c driver initialization.
>>>>
>>>> Yes the timer is still ticking after the freeze in the at24c 
>>>> driver
>>>> initialization. Does this means that  the ipipe_handle_multi_irq 
>>>> in
>>>> omap_intc_handle_irq is not handling the multiple irq properly?
>>>
>>>
>>> No. It simply means the problem is not the timer. Next usual 
>>> suspect is
>>> the clocksource. Did you get the message about clocksource 
>>> switching to
>>> ipipe_tsc and does ipipe_tsc_get return increasing values?
>>
>> Yes the clock source did change to tsc in the boot message, I will 
>> take a look at the return value of I pipe_tsc_get.
>>
>>
>
> The problem is that you are using the wrong timer.
>
> You should have
>
> OMAP clockevent source: GPTIMER2 at 24000000 Hz
> OMAP clocksource: GPTIMER1 at 24000000 Hz
>
> in the startup console output for both the kernel with IPIPE disabled
> and with IPIPE enabled.
>
> Thus in arch/arm/mach-omap2/timer.c you need to change the timer
> definitions accordingly.
>
> What I did was:
>
> #define OMAP2_MPU_SOURCE	"sys_ck"
> #define OMAP3_MPU_SOURCE	OMAP2_MPU_SOURCE
> #define OMAP4_MPU_SOURCE	"sys_clkin_ck"
> #define OMAP2_32K_SOURCE	"func_32k_ck"
> #define OMAP3_32K_SOURCE	"omap_32k_fck"
> #define OMAP4_32K_SOURCE	"sys_32k_ck"
> #define AM33XX_CLKEV_SOURCE OMAP4_MPU_SOURCE
> #define AM33XX_RTC32K_SOURCE	"clk_32768_ck"
>
> #ifdef CONFIG_OMAP_32K_TIMER
> #define OMAP2_CLKEV_SOURCE	OMAP2_32K_SOURCE
> #define OMAP3_CLKEV_SOURCE	OMAP3_32K_SOURCE
> #define OMAP4_CLKEV_SOURCE	OMAP4_32K_SOURCE
> #define AM33XX_MPU_SOURCE	AM33XX_RTC32K_SOURCE
> #define OMAP3_SECURE_TIMER	12
> #else
> #define OMAP2_CLKEV_SOURCE	OMAP2_MPU_SOURCE
> #define OMAP3_CLKEV_SOURCE	OMAP3_MPU_SOURCE
> #define OMAP4_CLKEV_SOURCE	OMAP4_MPU_SOURCE
> #define AM33XX_MPU_SOURCE	OMAP4_MPU_SOURCE
> #define OMAP3_SECURE_TIMER	1
> #endif
> ...
> ...
> ...
> #ifdef CONFIG_ARCH_OMAP3
>
> #ifndef CONFIG_SOC_OMAPAM33XX
>
> #ifndef CONFIG_IPIPE
> OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
> #else
> OMAP_SYS_TIMER_INIT(3, 2, OMAP3_CLKEV_SOURCE, 3, OMAP3_MPU_SOURCE)
> #endif
> OMAP_SYS_TIMER(3)
> OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
> 			2, OMAP3_MPU_SOURCE)
> OMAP_SYS_TIMER(3_secure)
>
> #else // #ifdef CONFIG_SOC_OMAPAM33XX
>
> OMAP_SYS_TIMER_INIT(3, 2, AM33XX_CLKEV_SOURCE, 1, AM33XX_MPU_SOURCE)
> OMAP_SYS_TIMER(3)
>
> #endif
>
> #endif
>
> - Stephan

Thanks a lot Stephan and Gilles! The kernel is now able to boot with 
both CONFIG_XENOMAI and CONFIG_IPIPE.





^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-30  8:54   ` WONG Sheng Chao
@ 2012-11-30 11:45     ` Michael Haberler
  2012-11-30 13:42       ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: Michael Haberler @ 2012-11-30 11:45 UTC (permalink / raw)
  To: xenomai


Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:

> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>> 
>> The problem is that you are using the wrong timer.
>> ...

>> 
>> #endif
>> 
>> - Stephan
> 
> Thanks a lot Stephan and Gilles! The kernel is now able to boot with both CONFIG_XENOMAI and CONFIG_IPIPE.

great! could you publish a complete patch relative to a known base?

thanks in advance,

- Michael



> 
> 
> 
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai



^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-30 11:45     ` Michael Haberler
@ 2012-11-30 13:42       ` Gilles Chanteperdrix
  2012-11-30 19:22         ` Michael Haberler
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-11-30 13:42 UTC (permalink / raw)
  To: Michael Haberler; +Cc: xenomai

On 11/30/2012 12:45 PM, Michael Haberler wrote:
> 
> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
> 
>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>
>>> The problem is that you are using the wrong timer.
>>> ...
> 
>>>
>>> #endif
>>>
>>> - Stephan
>>
>> Thanks a lot Stephan and Gilles! The kernel is now able to boot with both CONFIG_XENOMAI and CONFIG_IPIPE.
> 
> great! could you publish a complete patch relative to a known base?
> 
> thanks in advance,

As I already said, if someone takes the little time it takes to generate
a pre and post patch (I explained the why and how in a previous mail),
we can even integrate it in xenomai repository.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-30 13:42       ` Gilles Chanteperdrix
@ 2012-11-30 19:22         ` Michael Haberler
  2012-12-02 13:53           ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Michael Haberler @ 2012-11-30 19:22 UTC (permalink / raw)
  To: xenomai


Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:

> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>> 
>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>> 
>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>> 
>>>> The problem is that you are using the wrong timer.
>>>> ...
>> 
>>>> 
>>>> #endif
>>>> 
>>>> - Stephan
>>> 
>>> Thanks a lot Stephan and Gilles! The kernel is now able to boot with both CONFIG_XENOMAI and CONFIG_IPIPE.
>> 
>> great! could you publish a complete patch relative to a known base?
>> 
>> thanks in advance,
> 
> As I already said, if someone takes the little time it takes to generate
> a pre and post patch (I explained the why and how in a previous mail),
> we can even integrate it in xenomai repository.

I'll take that on after I have something working. 

The beaglebone has very good potential for RT applications especially with the PRU coprocessors which are dead simple to use and blazing fast, so I see some folks coming in that direction.




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-11-30 19:22         ` Michael Haberler
@ 2012-12-02 13:53           ` WONG Sheng Chao
  2012-12-02 14:45             ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-02 13:53 UTC (permalink / raw)
  To: Michael Haberler; +Cc: xenomai

On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>
>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>
>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>
>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>
>>>>> The problem is that you are using the wrong timer.
>>>>> ...
>>>
>>>>>
>>>>> #endif
>>>>>
>>>>> - Stephan
>>>>
>>>> Thanks a lot Stephan and Gilles! The kernel is now able to boot 
>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>
>>> great! could you publish a complete patch relative to a known base?
>>>
>>> thanks in advance,
>>
>> As I already said, if someone takes the little time it takes to 
>> generate
>> a pre and post patch (I explained the why and how in a previous 
>> mail),
>> we can even integrate it in xenomai repository.

I am trying to generate the pre and post patch following the 
instructions from this mail

http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html

But I am still not clear on the pre-patch part especially this part of 
the mail

The pre-patch is the reverse diff between the files in the vanilla 
kernel,
and the files conflicting in the vendor branch.
Generate the pre-patch.
git reset --hard
git clean -df (beware this erases all files non commited in git, so do
not do that if you keep precious files not under git control)


 From what I understand so far, the steps to make the pre and post patch 
are as follow

1) Make a copy of the original_vendor_kernel_source and run git commit.

2) I ran the i-pipe patch from xenomai/scripts with the linux_tree 
pointing to the original_vender_kernel_source to check for the 
conflicting files.

3) I fix the conflicting files in the original_verndor_kernel_source by 
replacing the files from the vanilla_kernel_source

4) I use git diff to create a patch, is this consider a pre-patch?

5) I ran the i-pipe patch again, now the i-pipe will patch 
successfully, commit the changes

6) Modify the timer.c, irq.c, some includes file, and create the post 
patch with git diff.

Is this flow correct?


>
> I'll take that on after I have something working.
>
> The beaglebone has very good potential for RT applications especially
> with the PRU coprocessors which are dead simple to use and blazing
> fast, so I see some folks coming in that direction.

Hi Michael

I am still trying to figure out how to make the proper pre and psot 
patch files. But I do have a txt files which I wrote down the steps and 
changes I made based on advice from Gilles and Stephen to make Xenomai 
running on my Beaglebone for the Angstrom branch. If you are interested 
I can send the txt file to you.

- Wong


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-02 13:53           ` WONG Sheng Chao
@ 2012-12-02 14:45             ` Gilles Chanteperdrix
  2012-12-02 15:15               ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-02 14:45 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:

> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>
>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>
>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>
>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>
>>>>>> The problem is that you are using the wrong timer.
>>>>>> ...
>>>>
>>>>>>
>>>>>> #endif
>>>>>>
>>>>>> - Stephan
>>>>>
>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to boot 
>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>
>>>> great! could you publish a complete patch relative to a known base?
>>>>
>>>> thanks in advance,
>>>
>>> As I already said, if someone takes the little time it takes to 
>>> generate
>>> a pre and post patch (I explained the why and how in a previous 
>>> mail),
>>> we can even integrate it in xenomai repository.
> 
> I am trying to generate the pre and post patch following the 
> instructions from this mail
> 
> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
> 
> But I am still not clear on the pre-patch part especially this part of 
> the mail
> 
> The pre-patch is the reverse diff between the files in the vanilla 
> kernel,
> and the files conflicting in the vendor branch.
> Generate the pre-patch.
> git reset --hard
> git clean -df (beware this erases all files non commited in git, so do
> not do that if you keep precious files not under git control)
> 
> 
>  From what I understand so far, the steps to make the pre and post patch 
> are as follow
> 
> 1) Make a copy of the original_vendor_kernel_source and run git commit.
> 
> 2) I ran the i-pipe patch from xenomai/scripts with the linux_tree 
> pointing to the original_vender_kernel_source to check for the 
> conflicting files.


No, the pre and post patches are I-pipe only, they do not include Xenomai.


-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-02 14:45             ` Gilles Chanteperdrix
@ 2012-12-02 15:15               ` WONG Sheng Chao
  2012-12-02 16:14                 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-02 15:15 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>
>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>
>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>
>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>
>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>
>>>>>>> The problem is that you are using the wrong timer.
>>>>>>> ...
>>>>>
>>>>>>>
>>>>>>> #endif
>>>>>>>
>>>>>>> - Stephan
>>>>>>
>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to boot
>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>
>>>>> great! could you publish a complete patch relative to a known 
>>>>> base?
>>>>>
>>>>> thanks in advance,
>>>>
>>>> As I already said, if someone takes the little time it takes to
>>>> generate
>>>> a pre and post patch (I explained the why and how in a previous
>>>> mail),
>>>> we can even integrate it in xenomai repository.
>>
>> I am trying to generate the pre and post patch following the
>> instructions from this mail
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>
>> But I am still not clear on the pre-patch part especially this part 
>> of
>> the mail
>>
>> The pre-patch is the reverse diff between the files in the vanilla
>> kernel,
>> and the files conflicting in the vendor branch.
>> Generate the pre-patch.
>> git reset --hard
>> git clean -df (beware this erases all files non commited in git, so 
>> do
>> not do that if you keep precious files not under git control)
>>
>>
>>  From what I understand so far, the steps to make the pre and post 
>> patch
>> are as follow
>>
>> 1) Make a copy of the original_vendor_kernel_source and run git 
>> commit.
>>
>> 2) I ran the i-pipe patch from xenomai/scripts with the linux_tree
>> pointing to the original_vender_kernel_source to check for the
>> conflicting files.
>
>
> No, the pre and post patches are I-pipe only, they do not include 
> Xenomai.

So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to my 
original_vendor_kernel_source folder and run

patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch

to check for conflicting files?




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-02 15:15               ` WONG Sheng Chao
@ 2012-12-02 16:14                 ` Gilles Chanteperdrix
  2012-12-03 14:31                   ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-02 16:14 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:

> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>
>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>
>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>
>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>
>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>>
>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>> ...
>>>>>>
>>>>>>>>
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> - Stephan
>>>>>>>
>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to boot
>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>
>>>>>> great! could you publish a complete patch relative to a known 
>>>>>> base?
>>>>>>
>>>>>> thanks in advance,
>>>>>
>>>>> As I already said, if someone takes the little time it takes to
>>>>> generate
>>>>> a pre and post patch (I explained the why and how in a previous
>>>>> mail),
>>>>> we can even integrate it in xenomai repository.
>>>
>>> I am trying to generate the pre and post patch following the
>>> instructions from this mail
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>
>>> But I am still not clear on the pre-patch part especially this part 
>>> of
>>> the mail
>>>
>>> The pre-patch is the reverse diff between the files in the vanilla
>>> kernel,
>>> and the files conflicting in the vendor branch.
>>> Generate the pre-patch.
>>> git reset --hard
>>> git clean -df (beware this erases all files non commited in git, so 
>>> do
>>> not do that if you keep precious files not under git control)
>>>
>>>
>>>  From what I understand so far, the steps to make the pre and post 
>>> patch
>>> are as follow
>>>
>>> 1) Make a copy of the original_vendor_kernel_source and run git 
>>> commit.
>>>
>>> 2) I ran the i-pipe patch from xenomai/scripts with the linux_tree
>>> pointing to the original_vender_kernel_source to check for the
>>> conflicting files.
>>
>>
>> No, the pre and post patches are I-pipe only, they do not include 
>> Xenomai.
> 
> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to my 
> original_vendor_kernel_source folder and run
> 
> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
> 
> to check for conflicting files?


I do not know what -i means, but yes, that is what you should do.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-02 16:14                 ` Gilles Chanteperdrix
@ 2012-12-03 14:31                   ` WONG Sheng Chao
  2012-12-03 18:30                     ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-03 14:31 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>
>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>
>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>
>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>
>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>
>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>>>
>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>> ...
>>>>>>>
>>>>>>>>>
>>>>>>>>> #endif
>>>>>>>>>
>>>>>>>>> - Stephan
>>>>>>>>
>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to 
>>>>>>>> boot
>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>
>>>>>>> great! could you publish a complete patch relative to a known
>>>>>>> base?
>>>>>>>
>>>>>>> thanks in advance,
>>>>>>
>>>>>> As I already said, if someone takes the little time it takes to
>>>>>> generate
>>>>>> a pre and post patch (I explained the why and how in a previous
>>>>>> mail),
>>>>>> we can even integrate it in xenomai repository.
>>>>
>>>> I am trying to generate the pre and post patch following the
>>>> instructions from this mail
>>>>
>>>> 
>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>
>>>> But I am still not clear on the pre-patch part especially this 
>>>> part
>>>> of
>>>> the mail
>>>>
>>>> The pre-patch is the reverse diff between the files in the vanilla
>>>> kernel,
>>>> and the files conflicting in the vendor branch.
>>>> Generate the pre-patch.
>>>> git reset --hard
>>>> git clean -df (beware this erases all files non commited in git, 
>>>> so
>>>> do
>>>> not do that if you keep precious files not under git control)
>>>>
>>>>
>>>>  From what I understand so far, the steps to make the pre and post
>>>> patch
>>>> are as follow
>>>>
>>>> 1) Make a copy of the original_vendor_kernel_source and run git
>>>> commit.
>>>>
>>>> 2) I ran the i-pipe patch from xenomai/scripts with the linux_tree
>>>> pointing to the original_vender_kernel_source to check for the
>>>> conflicting files.
>>>
>>>
>>> No, the pre and post patches are I-pipe only, they do not include
>>> Xenomai.
>>
>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to my
>> original_vendor_kernel_source folder and run
>>
>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>
>> to check for conflicting files?
>
>
> I do not know what -i means, but yes, that is what you should do.

Here are the pre and post patch that I made to make Xenomai run on my 
beaglebone.

The general workflow that I took was as follow

1) Clone the setup-script from below and run the update script

git clone git://github.com/Angstrom-distribution/setup-scripts.git

2) Edit the bitbake recipe to download the kernel source of linux 
3.2.21 and the rest of the meta patch.

3) Apply the pre-patch

4) Apply the ipipe patch as usual with the ./prepare-kernel.sh script

5) Apply the post-patch

6) Copy the am335x-pm-firmware.bin to the /firmware folder, this is 
needed to compile the kernel for AM3359

7) Compile the kernel
















-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre-patch.patch
Type: text/x-c
Size: 16458 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: post-patch.patch
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-03 14:31                   ` WONG Sheng Chao
@ 2012-12-03 18:30                     ` WONG Sheng Chao
  2012-12-03 19:57                       ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-03 18:30 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On Mon, 03 Dec 2012 15:31:20 +0100, WONG Sheng Chao wrote:
> On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
>> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>>
>>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>>
>>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>>
>>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>>
>>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>>
>>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>>>>
>>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>>> ...
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> #endif
>>>>>>>>>>
>>>>>>>>>> - Stephan
>>>>>>>>>
>>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to 
>>>>>>>>> boot
>>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>>
>>>>>>>> great! could you publish a complete patch relative to a known
>>>>>>>> base?
>>>>>>>>
>>>>>>>> thanks in advance,
>>>>>>>
>>>>>>> As I already said, if someone takes the little time it takes to
>>>>>>> generate
>>>>>>> a pre and post patch (I explained the why and how in a previous
>>>>>>> mail),
>>>>>>> we can even integrate it in xenomai repository.
>>>>>
>>>>> I am trying to generate the pre and post patch following the
>>>>> instructions from this mail
>>>>>
>>>>> 
>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>
>>>>> But I am still not clear on the pre-patch part especially this 
>>>>> part
>>>>> of
>>>>> the mail
>>>>>
>>>>> The pre-patch is the reverse diff between the files in the 
>>>>> vanilla
>>>>> kernel,
>>>>> and the files conflicting in the vendor branch.
>>>>> Generate the pre-patch.
>>>>> git reset --hard
>>>>> git clean -df (beware this erases all files non commited in git, 
>>>>> so
>>>>> do
>>>>> not do that if you keep precious files not under git control)
>>>>>
>>>>>
>>>>>  From what I understand so far, the steps to make the pre and 
>>>>> post
>>>>> patch
>>>>> are as follow
>>>>>
>>>>> 1) Make a copy of the original_vendor_kernel_source and run git
>>>>> commit.
>>>>>
>>>>> 2) I ran the i-pipe patch from xenomai/scripts with the 
>>>>> linux_tree
>>>>> pointing to the original_vender_kernel_source to check for the
>>>>> conflicting files.
>>>>
>>>>
>>>> No, the pre and post patches are I-pipe only, they do not include
>>>> Xenomai.
>>>
>>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to 
>>> my
>>> original_vendor_kernel_source folder and run
>>>
>>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>>
>>> to check for conflicting files?
>>
>>
>> I do not know what -i means, but yes, that is what you should do.
>
> Here are the pre and post patch that I made to make Xenomai run on my
> beaglebone.
>
> The general workflow that I took was as follow
>
> 1) Clone the setup-script from below and run the update script
>
> git clone git://github.com/Angstrom-distribution/setup-scripts.git
>
> 2) Edit the bitbake recipe to download the kernel source of linux
> 3.2.21 and the rest of the meta patch.
>
> 3) Apply the pre-patch
>
> 4) Apply the ipipe patch as usual with the ./prepare-kernel.sh script
>
> 5) Apply the post-patch
>
> 6) Copy the am335x-pm-firmware.bin to the /firmware folder, this is
> needed to compile the kernel for AM3359
>
> 7) Compile the kernel
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: pre-patch.patch
> Type: text/x-c
> Size: 16458 bytes
> Desc: not available
> URL:
> 
> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: post-patch.patch
> URL:
> 
> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai



post and pre patches resent in attachment




-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre_post_patches.tar.bz2
Type: application/octet-stream
Size: 25558 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/c97abee8/attachment.obj>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-03 18:30                     ` WONG Sheng Chao
@ 2012-12-03 19:57                       ` Gilles Chanteperdrix
  2012-12-04  9:26                         ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-03 19:57 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/03/2012 07:30 PM, WONG Sheng Chao wrote:

> On Mon, 03 Dec 2012 15:31:20 +0100, WONG Sheng Chao wrote:
>> On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
>>> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>>>
>>>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>>>
>>>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>>>
>>>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>>>
>>>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>>>
>>>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>>>>>
>>>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> #endif
>>>>>>>>>>>
>>>>>>>>>>> - Stephan
>>>>>>>>>>
>>>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to 
>>>>>>>>>> boot
>>>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>>>
>>>>>>>>> great! could you publish a complete patch relative to a known
>>>>>>>>> base?
>>>>>>>>>
>>>>>>>>> thanks in advance,
>>>>>>>>
>>>>>>>> As I already said, if someone takes the little time it takes to
>>>>>>>> generate
>>>>>>>> a pre and post patch (I explained the why and how in a previous
>>>>>>>> mail),
>>>>>>>> we can even integrate it in xenomai repository.
>>>>>>
>>>>>> I am trying to generate the pre and post patch following the
>>>>>> instructions from this mail
>>>>>>
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>
>>>>>> But I am still not clear on the pre-patch part especially this 
>>>>>> part
>>>>>> of
>>>>>> the mail
>>>>>>
>>>>>> The pre-patch is the reverse diff between the files in the 
>>>>>> vanilla
>>>>>> kernel,
>>>>>> and the files conflicting in the vendor branch.
>>>>>> Generate the pre-patch.
>>>>>> git reset --hard
>>>>>> git clean -df (beware this erases all files non commited in git, 
>>>>>> so
>>>>>> do
>>>>>> not do that if you keep precious files not under git control)
>>>>>>
>>>>>>
>>>>>>  From what I understand so far, the steps to make the pre and 
>>>>>> post
>>>>>> patch
>>>>>> are as follow
>>>>>>
>>>>>> 1) Make a copy of the original_vendor_kernel_source and run git
>>>>>> commit.
>>>>>>
>>>>>> 2) I ran the i-pipe patch from xenomai/scripts with the 
>>>>>> linux_tree
>>>>>> pointing to the original_vender_kernel_source to check for the
>>>>>> conflicting files.
>>>>>
>>>>>
>>>>> No, the pre and post patches are I-pipe only, they do not include
>>>>> Xenomai.
>>>>
>>>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to 
>>>> my
>>>> original_vendor_kernel_source folder and run
>>>>
>>>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>>>
>>>> to check for conflicting files?
>>>
>>>
>>> I do not know what -i means, but yes, that is what you should do.
>>
>> Here are the pre and post patch that I made to make Xenomai run on my
>> beaglebone.
>>
>> The general workflow that I took was as follow
>>
>> 1) Clone the setup-script from below and run the update script
>>
>> git clone git://github.com/Angstrom-distribution/setup-scripts.git
>>
>> 2) Edit the bitbake recipe to download the kernel source of linux
>> 3.2.21 and the rest of the meta patch.
>>
>> 3) Apply the pre-patch
>>
>> 4) Apply the ipipe patch as usual with the ./prepare-kernel.sh script
>>
>> 5) Apply the post-patch
>>
>> 6) Copy the am335x-pm-firmware.bin to the /firmware folder, this is
>> needed to compile the kernel for AM3359
>>
>> 7) Compile the kernel
>>
>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: pre-patch.patch
>> Type: text/x-c
>> Size: 16458 bytes
>> Desc: not available
>> URL:
>>
>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
>> -------------- next part --------------
>> An embedded and charset-unspecified text was scrubbed...
>> Name: post-patch.patch
>> URL:
>>
>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
> 
> 
> 
> post and pre patches resent in attachment


The first post was just fine. But two things:
- we do not want the .config in the post patch
- the post patch does not re-add the changes removed by the pre-patch in
arch/arm/common/gic.c, which makes it look really suspicious.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-03 19:57                       ` Gilles Chanteperdrix
@ 2012-12-04  9:26                         ` WONG Sheng Chao
  2012-12-04  9:45                           ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-04  9:26 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Mon, 03 Dec 2012 20:57:49 +0100, Gilles Chanteperdrix wrote:
> On 12/03/2012 07:30 PM, WONG Sheng Chao wrote:
>
>> On Mon, 03 Dec 2012 15:31:20 +0100, WONG Sheng Chao wrote:
>>> On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
>>>> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>>>>
>>>>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>>>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>>>>
>>>>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>>>>
>>>>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>>>>
>>>>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>>>>
>>>>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> #endif
>>>>>>>>>>>>
>>>>>>>>>>>> - Stephan
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to
>>>>>>>>>>> boot
>>>>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>>>>
>>>>>>>>>> great! could you publish a complete patch relative to a 
>>>>>>>>>> known
>>>>>>>>>> base?
>>>>>>>>>>
>>>>>>>>>> thanks in advance,
>>>>>>>>>
>>>>>>>>> As I already said, if someone takes the little time it takes 
>>>>>>>>> to
>>>>>>>>> generate
>>>>>>>>> a pre and post patch (I explained the why and how in a 
>>>>>>>>> previous
>>>>>>>>> mail),
>>>>>>>>> we can even integrate it in xenomai repository.
>>>>>>>
>>>>>>> I am trying to generate the pre and post patch following the
>>>>>>> instructions from this mail
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>>
>>>>>>> But I am still not clear on the pre-patch part especially this
>>>>>>> part
>>>>>>> of
>>>>>>> the mail
>>>>>>>
>>>>>>> The pre-patch is the reverse diff between the files in the
>>>>>>> vanilla
>>>>>>> kernel,
>>>>>>> and the files conflicting in the vendor branch.
>>>>>>> Generate the pre-patch.
>>>>>>> git reset --hard
>>>>>>> git clean -df (beware this erases all files non commited in 
>>>>>>> git,
>>>>>>> so
>>>>>>> do
>>>>>>> not do that if you keep precious files not under git control)
>>>>>>>
>>>>>>>
>>>>>>>  From what I understand so far, the steps to make the pre and
>>>>>>> post
>>>>>>> patch
>>>>>>> are as follow
>>>>>>>
>>>>>>> 1) Make a copy of the original_vendor_kernel_source and run git
>>>>>>> commit.
>>>>>>>
>>>>>>> 2) I ran the i-pipe patch from xenomai/scripts with the
>>>>>>> linux_tree
>>>>>>> pointing to the original_vender_kernel_source to check for the
>>>>>>> conflicting files.
>>>>>>
>>>>>>
>>>>>> No, the pre and post patches are I-pipe only, they do not 
>>>>>> include
>>>>>> Xenomai.
>>>>>
>>>>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch to
>>>>> my
>>>>> original_vendor_kernel_source folder and run
>>>>>
>>>>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>>>>
>>>>> to check for conflicting files?
>>>>
>>>>
>>>> I do not know what -i means, but yes, that is what you should do.
>>>
>>> Here are the pre and post patch that I made to make Xenomai run on 
>>> my
>>> beaglebone.
>>>
>>> The general workflow that I took was as follow
>>>
>>> 1) Clone the setup-script from below and run the update script
>>>
>>> git clone git://github.com/Angstrom-distribution/setup-scripts.git
>>>
>>> 2) Edit the bitbake recipe to download the kernel source of linux
>>> 3.2.21 and the rest of the meta patch.
>>>
>>> 3) Apply the pre-patch
>>>
>>> 4) Apply the ipipe patch as usual with the ./prepare-kernel.sh 
>>> script
>>>
>>> 5) Apply the post-patch
>>>
>>> 6) Copy the am335x-pm-firmware.bin to the /firmware folder, this is
>>> needed to compile the kernel for AM3359
>>>
>>> 7) Compile the kernel
>>>
>>>
>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: pre-patch.patch
>>> Type: text/x-c
>>> Size: 16458 bytes
>>> Desc: not available
>>> URL:
>>>
>>> 
>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
>>> -------------- next part --------------
>>> An embedded and charset-unspecified text was scrubbed...
>>> Name: post-patch.patch
>>> URL:
>>>
>>> 
>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>>
>>
>> post and pre patches resent in attachment
>
>
> The first post was just fine. But two things:
> - we do not want the .config in the post patch

I will redo the post patch without the .config file

> - the post patch does not re-add the changes removed by the pre-patch 
> in
> arch/arm/common/gic.c, which makes it look really suspicious.

as for the arch/arm/common/gic.c, it did not exist in the original 
vendor code (Angstrom). Since it did not exists, there were an error 
when i ran the .prepare-kernel script. So what I did was copy the 
arch/arm/common/gic.c from the vanilla linux kernel to my vender code. I 
did not modify the arch/arm/common/gic.c there after thus the post patch 
does not do anything to it.

Does that makes sense? or did I miss something?




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-04  9:26                         ` WONG Sheng Chao
@ 2012-12-04  9:45                           ` WONG Sheng Chao
  2012-12-04 19:29                             ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-04  9:45 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On Tue, 04 Dec 2012 10:26:45 +0100, WONG Sheng Chao wrote:
> On Mon, 03 Dec 2012 20:57:49 +0100, Gilles Chanteperdrix wrote:
>> On 12/03/2012 07:30 PM, WONG Sheng Chao wrote:
>>
>>> On Mon, 03 Dec 2012 15:31:20 +0100, WONG Sheng Chao wrote:
>>>> On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
>>>>> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>>>>>
>>>>>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>>>>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>>>>>
>>>>>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>>>>>
>>>>>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>>>>>
>>>>>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Stephan
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to
>>>>>>>>>>>> boot
>>>>>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>>>>>
>>>>>>>>>>> great! could you publish a complete patch relative to a 
>>>>>>>>>>> known
>>>>>>>>>>> base?
>>>>>>>>>>>
>>>>>>>>>>> thanks in advance,
>>>>>>>>>>
>>>>>>>>>> As I already said, if someone takes the little time it takes 
>>>>>>>>>> to
>>>>>>>>>> generate
>>>>>>>>>> a pre and post patch (I explained the why and how in a 
>>>>>>>>>> previous
>>>>>>>>>> mail),
>>>>>>>>>> we can even integrate it in xenomai repository.
>>>>>>>>
>>>>>>>> I am trying to generate the pre and post patch following the
>>>>>>>> instructions from this mail
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>>>
>>>>>>>> But I am still not clear on the pre-patch part especially this
>>>>>>>> part
>>>>>>>> of
>>>>>>>> the mail
>>>>>>>>
>>>>>>>> The pre-patch is the reverse diff between the files in the
>>>>>>>> vanilla
>>>>>>>> kernel,
>>>>>>>> and the files conflicting in the vendor branch.
>>>>>>>> Generate the pre-patch.
>>>>>>>> git reset --hard
>>>>>>>> git clean -df (beware this erases all files non commited in 
>>>>>>>> git,
>>>>>>>> so
>>>>>>>> do
>>>>>>>> not do that if you keep precious files not under git control)
>>>>>>>>
>>>>>>>>
>>>>>>>>  From what I understand so far, the steps to make the pre and
>>>>>>>> post
>>>>>>>> patch
>>>>>>>> are as follow
>>>>>>>>
>>>>>>>> 1) Make a copy of the original_vendor_kernel_source and run 
>>>>>>>> git
>>>>>>>> commit.
>>>>>>>>
>>>>>>>> 2) I ran the i-pipe patch from xenomai/scripts with the
>>>>>>>> linux_tree
>>>>>>>> pointing to the original_vender_kernel_source to check for the
>>>>>>>> conflicting files.
>>>>>>>
>>>>>>>
>>>>>>> No, the pre and post patches are I-pipe only, they do not 
>>>>>>> include
>>>>>>> Xenomai.
>>>>>>
>>>>>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch 
>>>>>> to
>>>>>> my
>>>>>> original_vendor_kernel_source folder and run
>>>>>>
>>>>>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>>>>>
>>>>>> to check for conflicting files?
>>>>>
>>>>>
>>>>> I do not know what -i means, but yes, that is what you should do.
>>>>
>>>> Here are the pre and post patch that I made to make Xenomai run on 
>>>> my
>>>> beaglebone.
>>>>
>>>> The general workflow that I took was as follow
>>>>
>>>> 1) Clone the setup-script from below and run the update script
>>>>
>>>> git clone git://github.com/Angstrom-distribution/setup-scripts.git
>>>>
>>>> 2) Edit the bitbake recipe to download the kernel source of linux
>>>> 3.2.21 and the rest of the meta patch.
>>>>
>>>> 3) Apply the pre-patch
>>>>
>>>> 4) Apply the ipipe patch as usual with the ./prepare-kernel.sh 
>>>> script
>>>>
>>>> 5) Apply the post-patch
>>>>
>>>> 6) Copy the am335x-pm-firmware.bin to the /firmware folder, this 
>>>> is
>>>> needed to compile the kernel for AM3359
>>>>
>>>> 7) Compile the kernel
>>>>
>>>>
>>>>
>>>> -------------- next part --------------
>>>> A non-text attachment was scrubbed...
>>>> Name: pre-patch.patch
>>>> Type: text/x-c
>>>> Size: 16458 bytes
>>>> Desc: not available
>>>> URL:
>>>>
>>>> 
>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
>>>> -------------- next part --------------
>>>> An embedded and charset-unspecified text was scrubbed...
>>>> Name: post-patch.patch
>>>> URL:
>>>>
>>>> 
>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>
>>>> _______________________________________________
>>>> Xenomai mailing list
>>>> Xenomai@xenomai.org
>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>
>>>
>>>
>>> post and pre patches resent in attachment
>>
>>
>> The first post was just fine. But two things:
>> - we do not want the .config in the post patch
>
> I will redo the post patch without the .config file
>
>> - the post patch does not re-add the changes removed by the 
>> pre-patch in
>> arch/arm/common/gic.c, which makes it look really suspicious.
>
> as for the arch/arm/common/gic.c, it did not exist in the original
> vendor code (Angstrom). Since it did not exists, there were an error
> when i ran the .prepare-kernel script. So what I did was copy the
> arch/arm/common/gic.c from the vanilla linux kernel to my vender 
> code.
> I did not modify the arch/arm/common/gic.c there after thus the post
> patch does not do anything to it.
>
> Does that makes sense? or did I miss somethin

I am sorry i made a mistake, the file i mentioned above is 
arch/arm/plat-mxc/gic.c

As for arch/arm/common/gic.c, i pre-patch it to the 
vanilla-kernel-3.2.21.

I don't quite understand, since I did not do any changes in this file 
after i patch it with ipipe, so isn't it logical that the post-patch 
does not re-add since there is nothing to add?



^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-04  9:45                           ` WONG Sheng Chao
@ 2012-12-04 19:29                             ` Gilles Chanteperdrix
  2012-12-10 18:08                               ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-04 19:29 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/04/2012 10:45 AM, WONG Sheng Chao wrote:

> On Tue, 04 Dec 2012 10:26:45 +0100, WONG Sheng Chao wrote:
>> On Mon, 03 Dec 2012 20:57:49 +0100, Gilles Chanteperdrix wrote:
>>> On 12/03/2012 07:30 PM, WONG Sheng Chao wrote:
>>>
>>>> On Mon, 03 Dec 2012 15:31:20 +0100, WONG Sheng Chao wrote:
>>>>> On Sun, 02 Dec 2012 17:14:37 +0100, Gilles Chanteperdrix wrote:
>>>>>> On 12/02/2012 04:15 PM, WONG Sheng Chao wrote:
>>>>>>
>>>>>>> On Sun, 02 Dec 2012 15:45:56 +0100, Gilles Chanteperdrix wrote:
>>>>>>>> On 12/02/2012 02:53 PM, WONG Sheng Chao wrote:
>>>>>>>>
>>>>>>>>> On Fri, 30 Nov 2012 20:22:11 +0100, Michael Haberler wrote:
>>>>>>>>>> Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix:
>>>>>>>>>>
>>>>>>>>>>> On 11/30/2012 12:45 PM, Michael Haberler wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem is that you are using the wrong timer.
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Stephan
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks a lot Stephan and Gilles! The kernel is now able to
>>>>>>>>>>>>> boot
>>>>>>>>>>>>> with both CONFIG_XENOMAI and CONFIG_IPIPE.
>>>>>>>>>>>>
>>>>>>>>>>>> great! could you publish a complete patch relative to a 
>>>>>>>>>>>> known
>>>>>>>>>>>> base?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks in advance,
>>>>>>>>>>>
>>>>>>>>>>> As I already said, if someone takes the little time it takes 
>>>>>>>>>>> to
>>>>>>>>>>> generate
>>>>>>>>>>> a pre and post patch (I explained the why and how in a 
>>>>>>>>>>> previous
>>>>>>>>>>> mail),
>>>>>>>>>>> we can even integrate it in xenomai repository.
>>>>>>>>>
>>>>>>>>> I am trying to generate the pre and post patch following the
>>>>>>>>> instructions from this mail
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-September/026190.html
>>>>>>>>>
>>>>>>>>> But I am still not clear on the pre-patch part especially this
>>>>>>>>> part
>>>>>>>>> of
>>>>>>>>> the mail
>>>>>>>>>
>>>>>>>>> The pre-patch is the reverse diff between the files in the
>>>>>>>>> vanilla
>>>>>>>>> kernel,
>>>>>>>>> and the files conflicting in the vendor branch.
>>>>>>>>> Generate the pre-patch.
>>>>>>>>> git reset --hard
>>>>>>>>> git clean -df (beware this erases all files non commited in 
>>>>>>>>> git,
>>>>>>>>> so
>>>>>>>>> do
>>>>>>>>> not do that if you keep precious files not under git control)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  From what I understand so far, the steps to make the pre and
>>>>>>>>> post
>>>>>>>>> patch
>>>>>>>>> are as follow
>>>>>>>>>
>>>>>>>>> 1) Make a copy of the original_vendor_kernel_source and run 
>>>>>>>>> git
>>>>>>>>> commit.
>>>>>>>>>
>>>>>>>>> 2) I ran the i-pipe patch from xenomai/scripts with the
>>>>>>>>> linux_tree
>>>>>>>>> pointing to the original_vender_kernel_source to check for the
>>>>>>>>> conflicting files.
>>>>>>>>
>>>>>>>>
>>>>>>>> No, the pre and post patches are I-pipe only, they do not 
>>>>>>>> include
>>>>>>>> Xenomai.
>>>>>>>
>>>>>>> So for step 2, I should copy the ipipe-core-3.2.21-arm-1.patch 
>>>>>>> to
>>>>>>> my
>>>>>>> original_vendor_kernel_source folder and run
>>>>>>>
>>>>>>> patch --dry-run -p1 -i ipipe-core-3.2.21-arm-1.patch
>>>>>>>
>>>>>>> to check for conflicting files?
>>>>>>
>>>>>>
>>>>>> I do not know what -i means, but yes, that is what you should do.
>>>>>
>>>>> Here are the pre and post patch that I made to make Xenomai run on 
>>>>> my
>>>>> beaglebone.
>>>>>
>>>>> The general workflow that I took was as follow
>>>>>
>>>>> 1) Clone the setup-script from below and run the update script
>>>>>
>>>>> git clone git://github.com/Angstrom-distribution/setup-scripts.git
>>>>>
>>>>> 2) Edit the bitbake recipe to download the kernel source of linux
>>>>> 3.2.21 and the rest of the meta patch.
>>>>>
>>>>> 3) Apply the pre-patch
>>>>>
>>>>> 4) Apply the ipipe patch as usual with the ./prepare-kernel.sh 
>>>>> script
>>>>>
>>>>> 5) Apply the post-patch
>>>>>
>>>>> 6) Copy the am335x-pm-firmware.bin to the /firmware folder, this 
>>>>> is
>>>>> needed to compile the kernel for AM3359
>>>>>
>>>>> 7) Compile the kernel
>>>>>
>>>>>
>>>>>
>>>>> -------------- next part --------------
>>>>> A non-text attachment was scrubbed...
>>>>> Name: pre-patch.patch
>>>>> Type: text/x-c
>>>>> Size: 16458 bytes
>>>>> Desc: not available
>>>>> URL:
>>>>>
>>>>>
>>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.bin>
>>>>> -------------- next part --------------
>>>>> An embedded and charset-unspecified text was scrubbed...
>>>>> Name: post-patch.patch
>>>>> URL:
>>>>>
>>>>>
>>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20121203/fa85d30d/attachment.ksh>
>>>>> _______________________________________________
>>>>> Xenomai mailing list
>>>>> Xenomai@xenomai.org
>>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>
>>>>
>>>>
>>>> post and pre patches resent in attachment
>>>
>>>
>>> The first post was just fine. But two things:
>>> - we do not want the .config in the post patch
>>
>> I will redo the post patch without the .config file
>>
>>> - the post patch does not re-add the changes removed by the 
>>> pre-patch in
>>> arch/arm/common/gic.c, which makes it look really suspicious.
>>
>> as for the arch/arm/common/gic.c, it did not exist in the original
>> vendor code (Angstrom). Since it did not exists, there were an error
>> when i ran the .prepare-kernel script. So what I did was copy the
>> arch/arm/common/gic.c from the vanilla linux kernel to my vender 
>> code.
>> I did not modify the arch/arm/common/gic.c there after thus the post
>> patch does not do anything to it.
>>
>> Does that makes sense? or did I miss somethin
> 
> I am sorry i made a mistake, the file i mentioned above is 
> arch/arm/plat-mxc/gic.c
> 
> As for arch/arm/common/gic.c, i pre-patch it to the 
> vanilla-kernel-3.2.21.
> 
> I don't quite understand, since I did not do any changes in this file 
> after i patch it with ipipe, so isn't it logical that the post-patch 
> does not re-add since there is nothing to add?


If you did not modify it, then the pre-patch should not contain anything
with regard to that file. Could you give me the url to the vendor git
repository and the modified branch so that I can generate the patches
myself and compare ?

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-04 19:29                             ` Gilles Chanteperdrix
@ 2012-12-10 18:08                               ` WONG Sheng Chao
  2012-12-10 19:07                                 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-10 18:08 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

>>>> The first post was just fine. But two things:
>>>> - we do not want the .config in the post patch
>>>
>>> I will redo the post patch without the .config file
>>>
>>>> - the post patch does not re-add the changes removed by the
>>>> pre-patch in
>>>> arch/arm/common/gic.c, which makes it look really suspicious.
>>>
>>> as for the arch/arm/common/gic.c, it did not exist in the original
>>> vendor code (Angstrom). Since it did not exists, there were an 
>>> error
>>> when i ran the .prepare-kernel script. So what I did was copy the
>>> arch/arm/common/gic.c from the vanilla linux kernel to my vender
>>> code.
>>> I did not modify the arch/arm/common/gic.c there after thus the 
>>> post
>>> patch does not do anything to it.
>>>
>>> Does that makes sense? or did I miss somethin
>>
>> I am sorry i made a mistake, the file i mentioned above is
>> arch/arm/plat-mxc/gic.c
>>
>> As for arch/arm/common/gic.c, i pre-patch it to the
>> vanilla-kernel-3.2.21.
>>
>> I don't quite understand, since I did not do any changes in this 
>> file
>> after i patch it with ipipe, so isn't it logical that the post-patch
>> does not re-add since there is nothing to add?
>
>
> If you did not modify it, then the pre-patch should not contain 
> anything
> with regard to that file. Could you give me the url to the vendor git
> repository and the modified branch so that I can generate the patches
> myself and compare ?


Since I was using bitbake recipe to get the vendor source code, I 
created my own git repository for the kernel source

https://github.com/shengchao/beaglebone-angstrom-xenomai

the master branch contains the original source from the vendor

and the xenomai branch is the one with pre-patch, ipipe_patch and 
post_patch applied.

I removed the .config file from the postpatch as you requested and 
included it separately in the tar file.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches_and_config_file.tar.bz2
Type: application/octet-stream
Size: 25531 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121210/97d68984/attachment.obj>

^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-10 18:08                               ` WONG Sheng Chao
@ 2012-12-10 19:07                                 ` Gilles Chanteperdrix
  2012-12-10 20:23                                   ` WONG Sheng Chao
  0 siblings, 1 reply; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-10 19:07 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/10/2012 07:08 PM, WONG Sheng Chao wrote:

>>>>> The first post was just fine. But two things:
>>>>> - we do not want the .config in the post patch
>>>>
>>>> I will redo the post patch without the .config file
>>>>
>>>>> - the post patch does not re-add the changes removed by the
>>>>> pre-patch in
>>>>> arch/arm/common/gic.c, which makes it look really suspicious.
>>>>
>>>> as for the arch/arm/common/gic.c, it did not exist in the original
>>>> vendor code (Angstrom). Since it did not exists, there were an 
>>>> error
>>>> when i ran the .prepare-kernel script. So what I did was copy the
>>>> arch/arm/common/gic.c from the vanilla linux kernel to my vender
>>>> code.
>>>> I did not modify the arch/arm/common/gic.c there after thus the 
>>>> post
>>>> patch does not do anything to it.
>>>>
>>>> Does that makes sense? or did I miss somethin
>>>
>>> I am sorry i made a mistake, the file i mentioned above is
>>> arch/arm/plat-mxc/gic.c
>>>
>>> As for arch/arm/common/gic.c, i pre-patch it to the
>>> vanilla-kernel-3.2.21.
>>>
>>> I don't quite understand, since I did not do any changes in this 
>>> file
>>> after i patch it with ipipe, so isn't it logical that the post-patch
>>> does not re-add since there is nothing to add?
>>
>>
>> If you did not modify it, then the pre-patch should not contain 
>> anything
>> with regard to that file. Could you give me the url to the vendor git
>> repository and the modified branch so that I can generate the patches
>> myself and compare ?
> 
> 
> Since I was using bitbake recipe to get the vendor source code, I 
> created my own git repository for the kernel source
> 
> https://github.com/shengchao/beaglebone-angstrom-xenomai
> 
> the master branch contains the original source from the vendor
> 
> and the xenomai branch is the one with pre-patch, ipipe_patch and 
> post_patch applied.


As I already said, what you should put under source control is the
I-pipe kernel, putting xenomai in the sources defeats the purpose of
having xenomai separated from the I-pipe patch.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-10 19:07                                 ` Gilles Chanteperdrix
@ 2012-12-10 20:23                                   ` WONG Sheng Chao
  2012-12-10 20:32                                     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 39+ messages in thread
From: WONG Sheng Chao @ 2012-12-10 20:23 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

On Mon, 10 Dec 2012 20:07:47 +0100, Gilles Chanteperdrix wrote:
> On 12/10/2012 07:08 PM, WONG Sheng Chao wrote:
>
>>>>>> The first post was just fine. But two things:
>>>>>> - we do not want the .config in the post patch
>>>>>
>>>>> I will redo the post patch without the .config file
>>>>>
>>>>>> - the post patch does not re-add the changes removed by the
>>>>>> pre-patch in
>>>>>> arch/arm/common/gic.c, which makes it look really suspicious.
>>>>>
>>>>> as for the arch/arm/common/gic.c, it did not exist in the 
>>>>> original
>>>>> vendor code (Angstrom). Since it did not exists, there were an
>>>>> error
>>>>> when i ran the .prepare-kernel script. So what I did was copy the
>>>>> arch/arm/common/gic.c from the vanilla linux kernel to my vender
>>>>> code.
>>>>> I did not modify the arch/arm/common/gic.c there after thus the
>>>>> post
>>>>> patch does not do anything to it.
>>>>>
>>>>> Does that makes sense? or did I miss somethin
>>>>
>>>> I am sorry i made a mistake, the file i mentioned above is
>>>> arch/arm/plat-mxc/gic.c
>>>>
>>>> As for arch/arm/common/gic.c, i pre-patch it to the
>>>> vanilla-kernel-3.2.21.
>>>>
>>>> I don't quite understand, since I did not do any changes in this
>>>> file
>>>> after i patch it with ipipe, so isn't it logical that the 
>>>> post-patch
>>>> does not re-add since there is nothing to add?
>>>
>>>
>>> If you did not modify it, then the pre-patch should not contain
>>> anything
>>> with regard to that file. Could you give me the url to the vendor 
>>> git
>>> repository and the modified branch so that I can generate the 
>>> patches
>>> myself and compare ?
>>
>>
>> Since I was using bitbake recipe to get the vendor source code, I
>> created my own git repository for the kernel source
>>
>> https://github.com/shengchao/beaglebone-angstrom-xenomai
>>
>> the master branch contains the original source from the vendor
>>
>> and the xenomai branch is the one with pre-patch, ipipe_patch and
>> post_patch applied.
>
>
> As I already said, what you should put under source control is the
> I-pipe kernel, putting xenomai in the sources defeats the purpose of
> having xenomai separated from the I-pipe patch.

I'm sorry but can you be more specific about the error i made as i am 
still new to source control. What do you mean by putting xenomai in the 
sources? What i did was

1) Pre patch the vendor source to remove the conflict files for ipipe 
patch

2) Patch the updated vendor source with ipipe using prepare-kernel.sh ( 
Is this a mistake? )

3) post patch the ipipe patched source

4) Compile and deploy the kernel




^ permalink raw reply	[flat|nested] 39+ messages in thread
* Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch
  2012-12-10 20:23                                   ` WONG Sheng Chao
@ 2012-12-10 20:32                                     ` Gilles Chanteperdrix
  0 siblings, 0 replies; 39+ messages in thread
From: Gilles Chanteperdrix @ 2012-12-10 20:32 UTC (permalink / raw)
  To: WONG Sheng Chao; +Cc: xenomai

On 12/10/2012 09:23 PM, WONG Sheng Chao wrote:

> I'm sorry but can you be more specific about the error i made as i am 
> still new to source control. What do you mean by putting xenomai in the 
> sources? What i did was
> 
> 1) Pre patch the vendor source to remove the conflict files for ipipe 
> patch
> 
> 2) Patch the updated vendor source with ipipe using prepare-kernel.sh ( 
> Is this a mistake? )


Yes. And the pre and post patch can be generated from a working tree,
they are not what you should put under version control.

> 
> 3) post patch the ipipe patched source
> 
> 4) Compile and deploy the kernel


You should run prepare-kernel.sh at this point, using the I-pipe patched
kernel, and keep the I-pipe patched kernel and xenomai sources separate,
so that you can update them separately.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 39+ messages in thread
end of thread, other threads:[~2012-12-10 20:32 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-23  9:45 [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch WONG Sheng Chao
2012-11-23  9:58 ` Gilles Chanteperdrix
2012-11-23 12:35   ` WONG Sheng Chao
2012-11-23 16:29     ` Gilles Chanteperdrix
2012-11-23 17:22       ` WONG Sheng Chao
2012-11-23 17:45         ` Gilles Chanteperdrix
2012-11-27 16:40           ` WONG Sheng Chao
2012-11-27 16:52             ` WONG Sheng Chao
2012-11-27 18:00             ` Gilles Chanteperdrix
2012-11-28 15:12               ` WONG Sheng Chao
2012-11-28 17:40                 ` WONG Sheng Chao
2012-11-28 18:14                   ` Gilles Chanteperdrix
2012-11-28 18:49                     ` WONG Sheng Chao
2012-11-28 18:57                       ` Gilles Chanteperdrix
2012-11-28 19:34                         ` WONG Sheng Chao
2012-11-28 19:55                           ` Gilles Chanteperdrix
2012-11-28 20:22                             ` WONG Sheng Chao
2012-11-29 12:10                             ` WONG Sheng Chao
     [not found] <mailman.2.1354034873.1423.xenomai@xenomai.org>
2012-11-27 18:42 ` Stephan Kappertz
2012-11-27 20:05   ` WONG Sheng Chao
     [not found] <mailman.0.1354186801.18650.xenomai@xenomai.org>
2012-11-29 12:16 ` Stephan Kappertz
2012-11-30  8:54   ` WONG Sheng Chao
2012-11-30 11:45     ` Michael Haberler
2012-11-30 13:42       ` Gilles Chanteperdrix
2012-11-30 19:22         ` Michael Haberler
2012-12-02 13:53           ` WONG Sheng Chao
2012-12-02 14:45             ` Gilles Chanteperdrix
2012-12-02 15:15               ` WONG Sheng Chao
2012-12-02 16:14                 ` Gilles Chanteperdrix
2012-12-03 14:31                   ` WONG Sheng Chao
2012-12-03 18:30                     ` WONG Sheng Chao
2012-12-03 19:57                       ` Gilles Chanteperdrix
2012-12-04  9:26                         ` WONG Sheng Chao
2012-12-04  9:45                           ` WONG Sheng Chao
2012-12-04 19:29                             ` Gilles Chanteperdrix
2012-12-10 18:08                               ` WONG Sheng Chao
2012-12-10 19:07                                 ` Gilles Chanteperdrix
2012-12-10 20:23                                   ` WONG Sheng Chao
2012-12-10 20:32                                     ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.