[Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

Hi,

I try to compile a kernel (2.6.32 patched with
adeos-ipipe-2.6.33-arm-1.17-02.patch	) with xenomai.
The target is AM3517 Evaluation Module. It runs correctly without
xenomai and the compilation proccess sucess with only adeos patch

this is my current method :

1)with xenomail :
./scripts/prepare-kernel.sh
--linux=/home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai
 --arch=arm
2)in the kernel directory :
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

These errors occur :
arch/arm/xenomai/built-in.o: In function `rthal_irq_host_release':
/home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai/arch/arm/xenomai/hal.c:193:
undefined reference to `__bad_lock_type'
arch/arm/xenomai/built-in.o: In function `rthal_irq_host_request':
/home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai/arch/arm/xenomai/hal.c:172:
undefined reference to `__bad_lock_type'

the test is done with  xenomai-2.5.0 and  xenomai-2.5.4
the toolchain is a codeSourcery toolchain : arm-none-linux-gnueabi-gcc
(Sourcery G++ 4.3-234) 4.3.3

have you a suggestion ? can you suggest me a kernel version and a
xenomai version ?

regards,
marc

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> Hi,
> 
> I try to compile a kernel (2.6.32 patched with
> adeos-ipipe-2.6.33-arm-1.17-02.patch	) with xenomai.
> The target is AM3517 Evaluation Module. It runs correctly without
> xenomai and the compilation proccess sucess with only adeos patch
> 
> this is my current method :
> 
> 1)with xenomail :
> ./scripts/prepare-kernel.sh
> --linux=/home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai
>  --arch=arm
> 2)in the kernel directory :
> make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
> make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
> 
> These errors occur :
> arch/arm/xenomai/built-in.o: In function `rthal_irq_host_release':
> /home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai/arch/arm/xenomai/hal.c:193:
> undefined reference to `__bad_lock_type'
> arch/arm/xenomai/built-in.o: In function `rthal_irq_host_request':
> /home/marc/sdk/AM35x-OMAP35x-PSP-SDK/src/kernel/linux-03.00.00.05_xenomai/arch/arm/xenomai/hal.c:172:
> undefined reference to `__bad_lock_type'
> 
> the test is done with  xenomai-2.5.0 and  xenomai-2.5.4
> the toolchain is a codeSourcery toolchain : arm-none-linux-gnueabi-gcc
> (Sourcery G++ 4.3-234) 4.3.3
> 
> have you a suggestion ? can you suggest me a kernel version and a
> xenomai version ?

Could you send me your kernel configuration?

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> Hi,
> 
> I try to compile a kernel (2.6.32 patched with
> adeos-ipipe-2.6.33-arm-1.17-02.patch	) with xenomai.

Looking at your sources directory name, are you sure you are using a
vanilla Linux kernel from kernel.org? Because this is the only kernel
this patch supports.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

Indeed, I use the kernel included in the SDK of TI. I will retry with
a vanilla kernel.

2010/8/18 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> marc doz wrote:
>> Hi,
>>
>> I try to compile a kernel (2.6.32 patched with
>> adeos-ipipe-2.6.33-arm-1.17-02.patch  ) with xenomai.
>
> Looking at your sources directory name, are you sure you are using a
> vanilla Linux kernel from kernel.org? Because this is the only kernel
> this patch supports.
>
> --
>                                            Gilles.
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

The compilation is a sucess without the line 172 and 193. It seem that
spin lock management is different between kernel 2.6.32 ans 2.6.33.

So I think that my realy problem is that is need a adeos patch  for
kernel 2.6.32 adeos-ipipe-2.6.32-arm* . I have 298 patchs of Texas
Instrument for the kernel 2.6.32 and my board. So I can't upgrade to
2.6.33 or downgrade to 2.6.31.

The 2.6.32 adeos-ipipe-2.6.32-arm* patch is not present in the
downloading section of the adeos website

2010/8/18 marc doz <doz.marc@domain.hid>:
> Indeed, I use the kernel included in the SDK of TI. I will retry with
> a vanilla kernel.
>
> 2010/8/18 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>> marc doz wrote:
>>> Hi,
>>>
>>> I try to compile a kernel (2.6.32 patched with
>>> adeos-ipipe-2.6.33-arm-1.17-02.patch  ) with xenomai.
>>
>> Looking at your sources directory name, are you sure you are using a
>> vanilla Linux kernel from kernel.org? Because this is the only kernel
>> this patch supports.
>>
>> --
>>                                            Gilles.
>>
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> The compilation is a sucess without the line 172 and 193. It seem that
> spin lock management is different between kernel 2.6.32 ans 2.6.33.
> 
> So I think that my realy problem is that is need a adeos patch  for
> kernel 2.6.32 adeos-ipipe-2.6.32-arm* . I have 298 patchs of Texas
> Instrument for the kernel 2.6.32 and my board. So I can't upgrade to
> 2.6.33 or downgrade to 2.6.31.
> 
> The 2.6.32 adeos-ipipe-2.6.32-arm* patch is not present in the
> downloading section of the adeos website

Yes, I did not produce this patch. If you want to do it, you should use
the I-pipe git: git://git.denx.de/ipipe-2.6.git, then merge the
ipipe-2.6.32-noarch branch with your vendor branch, then try and apply
the diff between ipipe-2.6.31-noarch and ipipe-2.6.31-arm or
ipipe-2.6.33-noarch and ipipe-2.6.33-arm.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

Hi,
I don't know where do you from my vendor kernel but it seems that it
is a 2.6.32 kernel.
This is my first time with git ! so I will need that you valid my
method, please.

I test with these commands :

#git clone git://git.denx.de/ipipe-2.6.git
#git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
#git checkout -b vendor
#cp -vR ../TI_linux/* ./
#git add *
#git commit
#git checkout ipipe-2.6.32-noarch
#git merge vendor
--> no error, no warning
#git checkout -branch -b ipipe-2.6.31-noarch origin/ipipe-2.6.31-noarch
#git checkout -branch -b ipipe-2.6.31-arm origin/ipipe-2.6.31-arm
#git checkout ipipe-2.6.32-noarch
#cat ../result.patch | patch -p1
#find . -name '*.reji'
./arch/arm/mach-sa1100/time.c.rej
./arch/arm/plat-mxc/gpio.c.rej
./arch/arm/mach-omap2/irq.c.rej
./arch/arm/mach-omap2/timer-gp.c.rej
./arch/arm/Kconfig.rej
./arch/arm/kernel/entry-common.S.rej
./arch/arm/kernel/smp.c.rej
./arch/arm/kernel/Makefile.rej
./arch/arm/kernel/entry-armv.S.rej
./arch/arm/kernel/entry-header.S.rej
./arch/arm/vfp/vfpmodule.c.rej
./arch/arm/mach-at91/at91sam9261.c.rej
./arch/arm/include/asm/mmu_context.h.rej
./arch/arm/include/asm/cacheflush.h.rej
./arch/arm/include/asm/thread_info.h.rej
./arch/arm/mm/Kconfig.rej
./arch/arm/mm/flush.c.rej

I will try to resolve manualy these rejectfile :
./arch/arm/mach-omap2/irq.c.rej
./arch/arm/mach-omap2/timer-gp.c.rej
./arch/arm/Kconfig.rej
./arch/arm/kernel/entry-common.S.rej
./arch/arm/kernel/smp.c.rej
./arch/arm/kernel/Makefile.rej
./arch/arm/kernel/entry-armv.S.rej
./arch/arm/kernel/entry-header.S.rej
./arch/arm/vfp/vfpmodule.c.rej
./arch/arm/include/asm/mmu_context.h.rej
./arch/arm/include/asm/cacheflush.h.rej
./arch/arm/include/asm/thread_info.h.rej
./arch/arm/mm/Kconfig.rej
./arch/arm/mm/flush.c.rej


2010/8/19 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> marc doz wrote:
>> The compilation is a sucess without the line 172 and 193. It seem that
>> spin lock management is different between kernel 2.6.32 ans 2.6.33.
>>
>> So I think that my realy problem is that is need a adeos patch  for
>> kernel 2.6.32 adeos-ipipe-2.6.32-arm* . I have 298 patchs of Texas
>> Instrument for the kernel 2.6.32 and my board. So I can't upgrade to
>> 2.6.33 or downgrade to 2.6.31.
>>
>> The 2.6.32 adeos-ipipe-2.6.32-arm* patch is not present in the
>> downloading section of the adeos website
>
> Yes, I did not produce this patch. If you want to do it, you should use
> the I-pipe git: git://git.denx.de/ipipe-2.6.git, then merge the
> ipipe-2.6.32-noarch branch with your vendor branch, then try and apply
> the diff between ipipe-2.6.31-noarch and ipipe-2.6.31-arm or
> ipipe-2.6.33-noarch and ipipe-2.6.33-arm.
>
> --
>                                            Gilles.
>

regards,
Marc

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> Hi,
> I don't know where do you from my vendor kernel but it seems that it
> is a 2.6.32 kernel.

I have no doubt that it is a 2.6.32 kernel. The question is to know
whether it is a vanilla kernel, i.e. coming from kernel.org. Since in
your first post the kernel directory was named linux_0030 or something
like that, I assumed it was not. But in any case it does not change
anything since the I-pipe patch for arm does not exist for linux-2.6.32
either.

> This is my first time with git ! so I will need that you valid my
> method, please.
> 
> I test with these commands :
> 
> #git clone git://git.denx.de/ipipe-2.6.git
> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
> #git checkout -b vendor
> #cp -vR ../TI_linux/* ./

It will work better if the branch "vendor" comes from the vendor git.

> #git add *
> #git commit
> #git checkout ipipe-2.6.32-noarch
> #git merge vendor

Ill-chosen name. Since this is the branch where you will make the merge,
you should call it, say, vendor+ipipe-2.6.32-arm. Having a branch called
ipipe-2.6.32-noarch which in fact contains the vendor kernel patches with

> --> no error, no warning

That was expected.

> #git checkout -branch -b ipipe-2.6.31-noarch origin/ipipe-2.6.31-noarch
> #git checkout -branch -b ipipe-2.6.31-arm origin/ipipe-2.6.31-arm

You do not really need to checkout this branches. All you need is to
generate the patch with:
git diff origin/ipipe-2.6.31-noarch origin/ipipe-2.6.31-arm

> #git checkout ipipe-2.6.32-noarch
> #cat ../result.patch | patch -p1
> #find . -name '*.reji'

The rejects are expected, you are applying changes for a 2.6.31 kernel
to a 2.6.32 kernel, vendor-specific or not, this makes rejects. Anyway,
maybe you will get less rejects if you use 2.6.33 instead of 2.6.31.

Rejects in entry-*.S are no good sign, and will be hard to fix (without
more knowledge of the Adeos patch). Please try 2.6.33.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> marc doz wrote:
>> Hi,
>> I don't know where do you from my vendor kernel but it seems that it
>> is a 2.6.32 kernel.
> 
> I have no doubt that it is a 2.6.32 kernel. The question is to know
> whether it is a vanilla kernel, i.e. coming from kernel.org. Since in
> your first post the kernel directory was named linux_0030 or something
> like that, I assumed it was not. But in any case it does not change
> anything since the I-pipe patch for arm does not exist for linux-2.6.32
> either.
> 
>> This is my first time with git ! so I will need that you valid my
>> method, please.
>>
>> I test with these commands :
>>
>> #git clone git://git.denx.de/ipipe-2.6.git
>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>> #git checkout -b vendor
>> #cp -vR ../TI_linux/* ./
> 
> It will work better if the branch "vendor" comes from the vendor git.

No, what you did does not work at all. After this cp, the "vendor"
branch will contain a mix of files from the noarch branch with the ones
of your vendor.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

03.00.00.05 is version of the SDK.  TI said that their kernel is the
result of patches that were applied to the open source kernel 2.6.32 .
But I find some differences with the vanilia kernel. I don't get
response from TI about this subject ... I'm waiting information.
I don't access to the vendor git ...

I restarted with your advices :

#git clone git://git.denx.de/ipipe-2.6.git
#git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
#git checkout -b vendor
#rm -rf
#cp -vR ../TI_linux/* ./
#git add *
#git commit
#git checkout ipipe-2.6.32-noarch
#git merge vendor
#git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
#git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
#cat ../result.patch | patch -p1
#find ./ -name '*.rej'

./init/main.c.rej
./kernel/ipipe/core.c.rej
./arch/arm/vfp/vfpmodule.c.rej
./arch/arm/plat-omap/gpio.c.rej
./arch/arm/mach-mx25/devices.c.rej
./include/linux/ipipe.h.rej
./include/linux/ipipe_percpu.h.rej
./include/linux/ipipe_base.h.rej

It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.

Best regards,
Marc

2010/8/23 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> Gilles Chanteperdrix wrote:
>> marc doz wrote:
>>> Hi,
>>> I don't know where do you from my vendor kernel but it seems that it
>>> is a 2.6.32 kernel.
>>
>> I have no doubt that it is a 2.6.32 kernel. The question is to know
>> whether it is a vanilla kernel, i.e. coming from kernel.org. Since in
>> your first post the kernel directory was named linux_0030 or something
>> like that, I assumed it was not. But in any case it does not change
>> anything since the I-pipe patch for arm does not exist for linux-2.6.32
>> either.
>>
>>> This is my first time with git ! so I will need that you valid my
>>> method, please.
>>>
>>> I test with these commands :
>>>
>>> #git clone git://git.denx.de/ipipe-2.6.git
>>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>>> #git checkout -b vendor
>>> #cp -vR ../TI_linux/* ./
>>
>> It will work better if the branch "vendor" comes from the vendor git.
>
> No, what you did does not work at all. After this cp, the "vendor"
> branch will contain a mix of files from the noarch branch with the ones
> of your vendor.
>
> --
>                                            Gilles.
>
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> 03.00.00.05 is version of the SDK.  TI said that their kernel is the
> result of patches that were applied to the open source kernel 2.6.32 .
> But I find some differences with the vanilia kernel.

I don't get it, if patches are applied, then it is not a vanilla kernel.
Period.

> I don't get response from TI about this subject ... I'm waiting information.
> I don't access to the vendor git ...

I doubt that, TI git repositories are public.

> 
> I restarted with your advices :
> 
> #git clone git://git.denx.de/ipipe-2.6.git
> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
> #git checkout -b vendor
> #rm -rf
> #cp -vR ../TI_linux/* ./

> #git add *

Still not good. You have to git rm the files which no longer exist.

> #git commit
> #git checkout ipipe-2.6.32-noarch
> #git merge vendor
> #git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
> #git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
> #cat ../result.patch | patch -p1
> #find ./ -name '*.rej'
> 
> ./init/main.c.rej
> ./kernel/ipipe/core.c.rej
> ./arch/arm/vfp/vfpmodule.c.rej
> ./arch/arm/plat-omap/gpio.c.rej
> ./arch/arm/mach-mx25/devices.c.rej
> ./include/linux/ipipe.h.rej
> ./include/linux/ipipe_percpu.h.rej
> ./include/linux/ipipe_base.h.rej
> 
> It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Flavio de Castro Alves Filho]

I believe that TI provides the patches separatelly too, but I'm not sure.


2010/8/23 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> marc doz wrote:
>> 03.00.00.05 is version of the SDK.  TI said that their kernel is the
>> result of patches that were applied to the open source kernel 2.6.32 .
>> But I find some differences with the vanilia kernel.
>
> I don't get it, if patches are applied, then it is not a vanilla kernel.
> Period.
>
>> I don't get response from TI about this subject ... I'm waiting information.
>> I don't access to the vendor git ...
>
> I doubt that, TI git repositories are public.
>
>>
>> I restarted with your advices :
>>
>> #git clone git://git.denx.de/ipipe-2.6.git
>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>> #git checkout -b vendor
>> #rm -rf
>> #cp -vR ../TI_linux/* ./
>
>> #git add *
>
> Still not good. You have to git rm the files which no longer exist.
>
>> #git commit
>> #git checkout ipipe-2.6.32-noarch
>> #git merge vendor
>> #git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
>> #git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
>> #cat ../result.patch | patch -p1
>> #find ./ -name '*.rej'
>>
>> ./init/main.c.rej
>> ./kernel/ipipe/core.c.rej
>> ./arch/arm/vfp/vfpmodule.c.rej
>> ./arch/arm/plat-omap/gpio.c.rej
>> ./arch/arm/mach-mx25/devices.c.rej
>> ./include/linux/ipipe.h.rej
>> ./include/linux/ipipe_percpu.h.rej
>> ./include/linux/ipipe_base.h.rej
>>
>> It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.
>
> --
>                                            Gilles.
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

Hi,

You are right !  The texas kernel comes from this repository :
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/pm
Ti gives also a TI patch to apply on this kernel.
This is a 2.6.32 kernel. Actualy, I work with a ipipe patch for 2.6.33
kernel  but I get compilation errors with this patch.
--> I am trying to get the a good ipipe patch for this kernel.

This repository contains also a 2.6.31 kernel and I have got the TI
patch corresponding to this kernel (old TI delivery)
I patch with  adeos-ipipe-2.6.31-arm-1.16-02.patch. I have got 2 rej
file. They are easy to solve.
arch/arm/mach-omap2/timer-gp.c.rej
arch/arm/mach-omap2/irq.c.rej
--> This kernel compiles without error and I am testing this solution
on my target

Thank you for your patience and the  lesson with git

It seems that kernel for my card is not a vanilla kernel and it is not
compatible to adeos/ipipe patch but I will try to continue.

l will keep you updated

best regards,
Marc

2010/8/23 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> marc doz wrote:
>> 03.00.00.05 is version of the SDK.  TI said that their kernel is the
>> result of patches that were applied to the open source kernel 2.6.32 .
>> But I find some differences with the vanilia kernel.
>
> I don't get it, if patches are applied, then it is not a vanilla kernel.
> Period.
>
>> I don't get response from TI about this subject ... I'm waiting information.
>> I don't access to the vendor git ...
>
> I doubt that, TI git repositories are public.
>
>>
>> I restarted with your advices :
>>
>> #git clone git://git.denx.de/ipipe-2.6.git
>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>> #git checkout -b vendor
>> #rm -rf
>> #cp -vR ../TI_linux/* ./
>
>> #git add *
>
> Still not good. You have to git rm the files which no longer exist.
>
>> #git commit
>> #git checkout ipipe-2.6.32-noarch
>> #git merge vendor
>> #git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
>> #git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
>> #cat ../result.patch | patch -p1
>> #find ./ -name '*.rej'
>>
>> ./init/main.c.rej
>> ./kernel/ipipe/core.c.rej
>> ./arch/arm/vfp/vfpmodule.c.rej
>> ./arch/arm/plat-omap/gpio.c.rej
>> ./arch/arm/mach-mx25/devices.c.rej
>> ./include/linux/ipipe.h.rej
>> ./include/linux/ipipe_percpu.h.rej
>> ./include/linux/ipipe_base.h.rej
>>
>> It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.
>
> --
>                                            Gilles.
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Flavio de Castro Alves Filho]

The TI patches were done for which kernel version?

Maybe that's the best version to work with adeos patches.

I use to work with git just when there is in the repository the same
configuration of the board that I am working on. My first tries are
always with the vanilla kernel from kernel.org and the patches from
adeos and the manufactures.

Best regards,

Flavio

2010/8/24 marc doz <doz.marc@domain.hid>:
> Hi,
>
> You are right !  The texas kernel comes from this repository :
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/pm
> Ti gives also a TI patch to apply on this kernel.
> This is a 2.6.32 kernel. Actualy, I work with a ipipe patch for 2.6.33
> kernel  but I get compilation errors with this patch.
> --> I am trying to get the a good ipipe patch for this kernel.
>
> This repository contains also a 2.6.31 kernel and I have got the TI
> patch corresponding to this kernel (old TI delivery)
> I patch with  adeos-ipipe-2.6.31-arm-1.16-02.patch. I have got 2 rej
> file. They are easy to solve.
> arch/arm/mach-omap2/timer-gp.c.rej
> arch/arm/mach-omap2/irq.c.rej
> --> This kernel compiles without error and I am testing this solution
> on my target
>
> Thank you for your patience and the  lesson with git
>
> It seems that kernel for my card is not a vanilla kernel and it is not
> compatible to adeos/ipipe patch but I will try to continue.
>
> l will keep you updated
>
> best regards,
> Marc
>
> 2010/8/23 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>> marc doz wrote:
>>> 03.00.00.05 is version of the SDK.  TI said that their kernel is the
>>> result of patches that were applied to the open source kernel 2.6.32 .
>>> But I find some differences with the vanilia kernel.
>>
>> I don't get it, if patches are applied, then it is not a vanilla kernel.
>> Period.
>>
>>> I don't get response from TI about this subject ... I'm waiting information.
>>> I don't access to the vendor git ...
>>
>> I doubt that, TI git repositories are public.
>>
>>>
>>> I restarted with your advices :
>>>
>>> #git clone git://git.denx.de/ipipe-2.6.git
>>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>>> #git checkout -b vendor
>>> #rm -rf
>>> #cp -vR ../TI_linux/* ./
>>
>>> #git add *
>>
>> Still not good. You have to git rm the files which no longer exist.
>>
>>> #git commit
>>> #git checkout ipipe-2.6.32-noarch
>>> #git merge vendor
>>> #git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
>>> #git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
>>> #cat ../result.patch | patch -p1
>>> #find ./ -name '*.rej'
>>>
>>> ./init/main.c.rej
>>> ./kernel/ipipe/core.c.rej
>>> ./arch/arm/vfp/vfpmodule.c.rej
>>> ./arch/arm/plat-omap/gpio.c.rej
>>> ./arch/arm/mach-mx25/devices.c.rej
>>> ./include/linux/ipipe.h.rej
>>> ./include/linux/ipipe_percpu.h.rej
>>> ./include/linux/ipipe_base.h.rej
>>>
>>> It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.
>>
>> --
>>                                            Gilles.
>>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[marc doz]

Actualy, I have got 2 versions :
1) TI SDK : OMAP35x-PSP-SDK-03.00.00.05 with a kernel 2.6.32 which
comes from linux-omap-2.6.git with specific TI patch for EVM of AM3517
2) TI SDK : OMAP35x-PSP-SDK-03.00.00.02 with a kernel 2.6.31-rc7 which
comes from linux-omap-2.6.git with specific TI patch for EVM of AM3517

I am testing solution 2 with software examples for native skin.

./trivial-periodic
Time since last turn: 1000.024230 ms
Time since last turn: 999.991461 ms
Time since last turn: 999.991999 ms
Time since last turn: 999.999384 ms
Time since last turn: 999.998538 ms
Time since last turn: 1000.005999 ms
Time since last turn: 999.993538 ms

./rtprint
This triggers auto-init of rt_print for the calling thread.
A last switch to secondary mode can occure here, but future invocations of rt_pr
401f0470: #1 Yet another RT printer - but to stderr.
400221e0 Task 1: #1 Hello RT world!
401f0470: #2 Yet another RT printer - but to stderr.
401f0470: #3 Yet another RT printer - but to stderr.

What do you think about this test ?
can you recommend me  some measure points  ?

regards,
Marc

2010/8/24 Flavio de Castro Alves Filho <flavio.alves@domain.hid>:
> The TI patches were done for which kernel version?
>
> Maybe that's the best version to work with adeos patches.
>
> I use to work with git just when there is in the repository the same
> configuration of the board that I am working on. My first tries are
> always with the vanilla kernel from kernel.org and the patches from
> adeos and the manufactures.
>
> Best regards,
>
> Flavio
>
> 2010/8/24 marc doz <doz.marc@domain.hid>:
>> Hi,
>>
>> You are right !  The texas kernel comes from this repository :
>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/pm
>> Ti gives also a TI patch to apply on this kernel.
>> This is a 2.6.32 kernel. Actualy, I work with a ipipe patch for 2.6.33
>> kernel  but I get compilation errors with this patch.
>> --> I am trying to get the a good ipipe patch for this kernel.
>>
>> This repository contains also a 2.6.31 kernel and I have got the TI
>> patch corresponding to this kernel (old TI delivery)
>> I patch with  adeos-ipipe-2.6.31-arm-1.16-02.patch. I have got 2 rej
>> file. They are easy to solve.
>> arch/arm/mach-omap2/timer-gp.c.rej
>> arch/arm/mach-omap2/irq.c.rej
>> --> This kernel compiles without error and I am testing this solution
>> on my target
>>
>> Thank you for your patience and the  lesson with git
>>
>> It seems that kernel for my card is not a vanilla kernel and it is not
>> compatible to adeos/ipipe patch but I will try to continue.
>>
>> l will keep you updated
>>
>> best regards,
>> Marc
>>
>> 2010/8/23 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>>> marc doz wrote:
>>>> 03.00.00.05 is version of the SDK.  TI said that their kernel is the
>>>> result of patches that were applied to the open source kernel 2.6.32 .
>>>> But I find some differences with the vanilia kernel.
>>>
>>> I don't get it, if patches are applied, then it is not a vanilla kernel.
>>> Period.
>>>
>>>> I don't get response from TI about this subject ... I'm waiting information.
>>>> I don't access to the vendor git ...
>>>
>>> I doubt that, TI git repositories are public.
>>>
>>>>
>>>> I restarted with your advices :
>>>>
>>>> #git clone git://git.denx.de/ipipe-2.6.git
>>>> #git checkout -branch -b ipipe-2.6.32-noarch origin/ipipe-2.6.32-noarch
>>>> #git checkout -b vendor
>>>> #rm -rf
>>>> #cp -vR ../TI_linux/* ./
>>>
>>>> #git add *
>>>
>>> Still not good. You have to git rm the files which no longer exist.
>>>
>>>> #git commit
>>>> #git checkout ipipe-2.6.32-noarch
>>>> #git merge vendor
>>>> #git branch -m ipipe-2.6.32-noarch vendor+ipipe-2.6.32-noarch
>>>> #git diff origin/ipipe-2.6.33-noarch origin/ipipe-2.6.33-arm > ../result.patch
>>>> #cat ../result.patch | patch -p1
>>>> #find ./ -name '*.rej'
>>>>
>>>> ./init/main.c.rej
>>>> ./kernel/ipipe/core.c.rej
>>>> ./arch/arm/vfp/vfpmodule.c.rej
>>>> ./arch/arm/plat-omap/gpio.c.rej
>>>> ./arch/arm/mach-mx25/devices.c.rej
>>>> ./include/linux/ipipe.h.rej
>>>> ./include/linux/ipipe_percpu.h.rej
>>>> ./include/linux/ipipe_base.h.rej
>>>>
>>>> It seem easier with 2.6.33. I will try to resolve manualy these rejectfile.
>>>
>>> --
>>>                                            Gilles.
>>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> Actualy, I have got 2 versions :
> 1) TI SDK : OMAP35x-PSP-SDK-03.00.00.05 with a kernel 2.6.32 which
> comes from linux-omap-2.6.git with specific TI patch for EVM of AM3517
> 2) TI SDK : OMAP35x-PSP-SDK-03.00.00.02 with a kernel 2.6.31-rc7 which
> comes from linux-omap-2.6.git with specific TI patch for EVM of AM3517
> 
> I am testing solution 2 with software examples for native skin.
> 
> ./trivial-periodic
> Time since last turn: 1000.024230 ms
> Time since last turn: 999.991461 ms
> Time since last turn: 999.991999 ms
> Time since last turn: 999.999384 ms
> Time since last turn: 999.998538 ms
> Time since last turn: 1000.005999 ms
> Time since last turn: 999.993538 ms
> 
> ./rtprint
> This triggers auto-init of rt_print for the calling thread.
> A last switch to secondary mode can occure here, but future invocations of rt_pr
> 401f0470: #1 Yet another RT printer - but to stderr.
> 400221e0 Task 1: #1 Hello RT world!
> 401f0470: #2 Yet another RT printer - but to stderr.
> 401f0470: #3 Yet another RT printer - but to stderr.
> 
> What do you think about this test ?
> can you recommend me  some measure points  ?

You want to run the latency test. But the latency on a system without
load is meaningless. As part of validating Xenomai, we use a test called
"dohell" to load the system. We provide a system to build a root
filesystem for running these tests called mkrootfs, available through git:
http://git.xenomai.org/?p=mkrootfs.git;a=summary

It has a README which should help you generate the root filesystem.

The procedure to run the test is:
- in a telnet session connected to the board, run the latency test
- in another telnet session, launch "dohell"
- when this scripts displays "Listening on any address 5566"
  run netcat target 5566 > /dev/null

Now wait a few hours.

-- 
					    Gilles.

Re: [Xenomai-help] kernel compilation problem with a Cortex A8, AM3517 EVM

[Gilles Chanteperdrix]

marc doz wrote:
> Hi,
> Your script runs since yesterday.
> I don't see "Listening on any address 5566"
> 

Ah. Could you send me your mkrootfs configuration file (should be named
.config at the top of your build tree).

> with latency test :
> RTT|  16:17:55  (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD|     14.230|     15.307|     27.307|       0|     0|      3.692|     58.538
> To day, I will learn to understand latency logs

The lat min, lat avg, lat max are the minimum, average and maximum
latencies on one second, overruns and msw should be zero if everything
is fine, lat best and lat worst are the best case and worst case
latencies for the whole run-time of the program.


-- 
					    Gilles.