[Xenomai-core] Build tests.

[Xenomai-core] Build tests.

[Gilles Chanteperdrix]

Hi,

I am working on automated build tests of several configurations of
Xenomai head. While running them, I found a few issues, and would need
acks, since it is in parts others maintain.

Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html

Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html

Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html

Philippe (check powerpc 2.4):
https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html

The current status of the tests may be found here:
http://sisyphus.hd.free.fr/~gilles/bx/

TIA,
Regards.

-- 
                                          Gilles

Re: [Xenomai-core] Build tests.

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Hi,
> 
> I am working on automated build tests of several configurations of
> Xenomai head. While running them, I found a few issues, and would need
> acks, since it is in parts others maintain.
> 
> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
> 
> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
> 

Though I'm not Wolfgang:

 config XENO_DRIVERS_CAN_SJA1000_PEAK_DNG
-       depends on XENO_DRIVERS_CAN_SJA1000
+       depends on XENO_DRIVERS_CAN_SJA1000 && !PARPORT
        tristate "PEAK Parallel Port Dongle"
        help

That's not obviously related. Why do we need it?

> Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
> 

If it builds, it's fine (I don't think anyone is using x86 on 2.4 anymore).

> Philippe (check powerpc 2.4):
> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
> 
> The current status of the tests may be found here:
> http://sisyphus.hd.free.fr/~gilles/bx/

Nice! That's not buildbot-based, is it?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Build tests.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>> 
>> I am working on automated build tests of several configurations of 
>> Xenomai head. While running them, I found a few issues, and would
>> need acks, since it is in parts others maintain.
>> 
>> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
>> 
>> 
>> Wolfgang:
>> https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
>> 
> 
> Though I'm not Wolfgang:
> 
> config XENO_DRIVERS_CAN_SJA1000_PEAK_DNG -       depends on
> XENO_DRIVERS_CAN_SJA1000 +       depends on XENO_DRIVERS_CAN_SJA1000
> && !PARPORT tristate "PEAK Parallel Port Dongle" help
> 
> That's not obviously related. Why do we need it?

Kconfig says:

config XENO_DRIVERS_CAN_SJA1000_PEAK_DNG
        depends on XENO_DRIVERS_CAN_SJA1000
        tristate "PEAK Parallel Port Dongle"
        help

        This driver is for the PCAN Dongle, the PC parallel port to CAN
        converter from PEAK Systems (http://www.peak-system.com). You need
        to disable parallel port support in the kernel (CONFIG_PARPORT) for
        proper operation. The interface type (sp or epp), I/O port and
        interrupt number should be defined via module parameters.

> 
>> Anyone:
>> https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
>> 
> 
> If it builds, it's fine (I don't think anyone is using x86 on 2.4
> anymore).

I do not think so either, but since we ship this patch, we should
check that it compiles at least... Or remove it.

> 
>> Philippe (check powerpc 2.4): 
>> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
>> 
>> The current status of the tests may be found here: 
>> http://sisyphus.hd.free.fr/~gilles/bx/
> 
> Nice! That's not buildbot-based, is it?

No. Only plain shell. Anyway, what dominates the run-time is the
x86 debian-like .config builds. I do not plan to run these tests
after each commit or even every night, only to validate a relase
before pushing it on the download area.

-- 
                                          Gilles

Re: [Xenomai-core] Build tests.

[Wolfgang Grandegger]

Hi Jan,

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I am working on automated build tests of several configurations of
>> Xenomai head. While running them, I found a few issues, and would need
>> acks, since it is in parts others maintain.
>>
>> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
>>
>> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
>>
> 
> Though I'm not Wolfgang:
> 
>  config XENO_DRIVERS_CAN_SJA1000_PEAK_DNG
> -       depends on XENO_DRIVERS_CAN_SJA1000
> +       depends on XENO_DRIVERS_CAN_SJA1000 && !PARPORT
>         tristate "PEAK Parallel Port Dongle"
>         help
> 
> That's not obviously related. Why do we need it?

As the help text explains, parport should be disabled. See:

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/Kconfig#066

Wolfgang.

Re: [Xenomai-core] Build tests.

[Alexis Berlemont]

Hi Gilles,

Gilles Chanteperdrix wrote:
> Hi,
> 
> I am working on automated build tests of several configurations of
> Xenomai head. While running them, I found a few issues, and would need
> acks, since it is in parts others maintain.
> 
> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html

Thank you for the fix.

> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
> 
> Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
> 
> Philippe (check powerpc 2.4):
> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
> 
> The current status of the tests may be found here:
> http://sisyphus.hd.free.fr/~gilles/bx/
> 
> TIA,
> Regards.
> 

Alexis.

Re: [Xenomai-core] Build tests.

[Philippe Gerum]

On Mon, 2009-12-14 at 14:32 +0100, Gilles Chanteperdrix wrote:
> Hi,
> 
> I am working on automated build tests of several configurations of
> Xenomai head. While running them, I found a few issues, and would need
> acks, since it is in parts others maintain.
> 
> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
> 
> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
> 
> Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
> 
> Philippe (check powerpc 2.4):
> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
> 

We have to include asm/mmu.h to get phys_addr_t defined.
The default declaration of this type for pre-2.6.28 kernels breaks
2.6.20. Better rely on phys_addr_t being defined in linux/types.h, or
specifically in our wrappers for older kernels. What a mess.

Tested here on blackfin 2.6.3x, x86* 2.6.27-2.6.30, nios2 2.6.3x, ppc
2.4.x, 2.6.20, 2.6.3x. You may want to check this against ARM as well.

diff --git a/include/asm-generic/wrappers.h b/include/asm-generic/wrappers.h
index 198d882..ae36932 100644
--- a/include/asm-generic/wrappers.h
+++ b/include/asm-generic/wrappers.h
@@ -319,16 +319,10 @@ static inline unsigned long hweight_long(unsigned long w)
 unsigned long find_next_bit(const unsigned long *addr,
                             unsigned long size, unsigned long offset);
 
-typedef phys_addr_t resource_size_t;
-
 #define mmiowb()	barrier()
 
 #else /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
-typedef unsigned long phys_addr_t;
-#endif
-
 #define compat_module_param_array(name, type, count, perm) \
 	module_param_array(name, type, NULL, perm)
 
diff --git a/include/asm-powerpc/wrappers.h b/include/asm-powerpc/wrappers.h
index 7d98539..edab86c 100644
--- a/include/asm-powerpc/wrappers.h
+++ b/include/asm-powerpc/wrappers.h
@@ -30,6 +30,8 @@
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
 
+#include <asm/mmu.h>
+
 #define CONFIG_MMU 1
 
 #define wrap_phys_mem_prot(filp,pfn,size,prot)  \
@@ -53,6 +55,8 @@ static __inline__ int fls(unsigned int x)
 	return 32 - lz;
 }
 
+typedef phys_addr_t resource_size_t;
+
 #else /*  LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)  */
 
 #define wrap_phys_mem_prot(filp,pfn,size,prot) \
diff --git a/include/asm-x86/wrappers_32.h b/include/asm-x86/wrappers_32.h
index d16cf6d..90ccdc1 100644
--- a/include/asm-x86/wrappers_32.h
+++ b/include/asm-x86/wrappers_32.h
@@ -78,6 +78,10 @@ static inline int fls(int x)
 	return r+1;
 }
 
+typedef unsigned long phys_addr_t;
+
+typedef phys_addr_t resource_size_t;
+
 #else /*  LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)  */
 
 #define wrap_phys_mem_prot(filp,pfn,size,prot)  (prot)

> The current status of the tests may be found here:
> http://sisyphus.hd.free.fr/~gilles/bx/
> 
> TIA,
> Regards.
> 


-- 
Philippe.

Re: [Xenomai-core] Build tests.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Mon, 2009-12-14 at 14:32 +0100, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I am working on automated build tests of several configurations of
>> Xenomai head. While running them, I found a few issues, and would need
>> acks, since it is in parts others maintain.
>>
>> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
>>
>> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
>>
>> Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
>>
>> Philippe (check powerpc 2.4):
>> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
>>
> 
> We have to include asm/mmu.h to get phys_addr_t defined.
> The default declaration of this type for pre-2.6.28 kernels breaks
> 2.6.20. Better rely on phys_addr_t being defined in linux/types.h, or
> specifically in our wrappers for older kernels. What a mess.
> 
> Tested here on blackfin 2.6.3x, x86* 2.6.27-2.6.30, nios2 2.6.3x, ppc
> 2.4.x, 2.6.20, 2.6.3x. You may want to check this against ARM as well.

Ok. Will do.

-- 
                                          Gilles

Re: [Xenomai-core] Build tests.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Mon, 2009-12-14 at 14:32 +0100, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I am working on automated build tests of several configurations of
>> Xenomai head. While running them, I found a few issues, and would need
>> acks, since it is in parts others maintain.
>>
>> Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
>>
>> Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html
>>
>> Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html
>>
>> Philippe (check powerpc 2.4):
>> https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html
>>
> 
> We have to include asm/mmu.h to get phys_addr_t defined.
> The default declaration of this type for pre-2.6.28 kernels breaks
> 2.6.20. Better rely on phys_addr_t being defined in linux/types.h, or
> specifically in our wrappers for older kernels. What a mess.
> 
> Tested here on blackfin 2.6.3x, x86* 2.6.27-2.6.30, nios2 2.6.3x, ppc
> 2.4.x, 2.6.20, 2.6.3x. You may want to check this against ARM as well.

Ok. Tested in the last run (same address as usual,
http://sisyphus.hd.free.fr/~gilles/bx), and no more traces of
phys_addr_t. The patch is in my repository.

However, we have two more issues:
- a section mismatch issue with analogy which appears in the pasemi
compilations (I guess the issues is there on all platforms, but only
pasemi has the proper debugging option enabled)
- missing PCI ids in the RTCAN drivers when building for ppc with linux
2.6.20.

-- 
					    Gilles.