[Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Hi,

Since I started talking about it, I have run build tests fixing a few
things here and there. The current status is this (still at the same
place: http://sisyphus.hd.free.fr/~gilles/bx):

* analogy: I have tried to disable some parts of analogy when compiling
on machines without CONFIG_PCI, as compiling parts using PCI on a
machine without PCI support, give various levels of warning and even
errors depending on the architecture. Doing this, I stumbled across this
compilation error:
http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.

So, Alex, could you:
- fix that error, if this combination is supposed to make sense
- fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
is not set (I tried and do this myself, but better one who knows than
100 who have to search...). As I said, doing this result in various
levels of success depending on the architecture.

* blackfin: I finally compiled blackfin! had to build a toolchain for
that as the binary-only toolchain from analog.com uses glibc 2.8 and
mine is 2.7. However, blackfin does not compile very well, as can be
seen by the log:
http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1
It may happen that my toolchain is buggy or outdated though.

* rtcan: on blackfin we seem to have a conflict with rtcan.
The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
define this in core headers which are included everywhere. This said,
not prefixing a Xenomai symbol with something like XN seems to be asking
for trouble. Wolfgang, do you think it would be possible to rename the
symbols with such prefix? Or do you share some code with socket-can that
you do not want to touch?

* nios2: I am lacking some important file needed to even start to compile.

Thanks in advance for your efforts.
Regards.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Philippe Gerum]

On Tue, 2009-12-22 at 11:06 +0100, Gilles Chanteperdrix wrote:
> Hi,
> 
> Since I started talking about it, I have run build tests fixing a few
> things here and there. The current status is this (still at the same
> place: http://sisyphus.hd.free.fr/~gilles/bx):
> 
> * analogy: I have tried to disable some parts of analogy when compiling
> on machines without CONFIG_PCI, as compiling parts using PCI on a
> machine without PCI support, give various levels of warning and even
> errors depending on the architecture. Doing this, I stumbled across this
> compilation error:
> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
> 
> So, Alex, could you:
> - fix that error, if this combination is supposed to make sense
> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> is not set (I tried and do this myself, but better one who knows than
> 100 who have to search...). As I said, doing this result in various
> levels of success depending on the architecture.
> 
> * blackfin: I finally compiled blackfin!

Good. So now you can try fixing the climate.

>  had to build a toolchain for
> that as the binary-only toolchain from analog.com uses glibc 2.8 and
> mine is 2.7. However, blackfin does not compile very well, as can be
> seen by the log:
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1
> It may happen that my toolchain is buggy or outdated though.

4.1.2 might still have the mcount prologue issue, so no tracer, but
aside of this, it seems ok here.

I've just pushed fixes for the NMI braindamage for blackfin.

> 
> * rtcan: on blackfin we seem to have a conflict with rtcan.
> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
> define this in core headers which are included everywhere. This said,
> not prefixing a Xenomai symbol with something like XN seems to be asking
> for trouble. Wolfgang, do you think it would be possible to rename the
> symbols with such prefix? Or do you share some code with socket-can that
> you do not want to touch?
> 
> * nios2: I am lacking some important file needed to even start to compile.
> 

I'm on this.

> Thanks in advance for your efforts.
> Regards.
> 


-- 
Philippe.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> * rtcan: on blackfin we seem to have a conflict with rtcan.
> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
> define this in core headers which are included everywhere. This said,
> not prefixing a Xenomai symbol with something like XN seems to be asking
> for trouble. Wolfgang, do you think it would be possible to rename the
> symbols with such prefix? Or do you share some code with socket-can that
> you do not want to touch?

CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
it must not be called differently. Blackfin is obviously doing namespace
pollution which should be fixed upstream and meanwhile worked around in
Xenomai (e.g. via #undef CAN_ERR_MASK).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>> define this in core headers which are included everywhere. This said,
>> not prefixing a Xenomai symbol with something like XN seems to be asking
>> for trouble. Wolfgang, do you think it would be possible to rename the
>> symbols with such prefix? Or do you share some code with socket-can that
>> you do not want to touch?
> 
> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
> it must not be called differently. Blackfin is obviously doing namespace
> pollution which should be fixed upstream and meanwhile worked around in
> Xenomai (e.g. via #undef CAN_ERR_MASK).

Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
The error seems to have been fixed upstream, since we get this warning
with 2.6.30 and not with 2.6.31.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Wolfgang Grandegger]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>> define this in core headers which are included everywhere. This said,
>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>> symbols with such prefix? Or do you share some code with socket-can that
>>> you do not want to touch?
>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>> it must not be called differently. Blackfin is obviously doing namespace
>> pollution which should be fixed upstream and meanwhile worked around in
>> Xenomai (e.g. via #undef CAN_ERR_MASK).
> 
> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
> The error seems to have been fixed upstream, since we get this warning
> with 2.6.30 and not with 2.6.31.
> 

The RT-SocketCAN API is compatible with the SocketCAN API and therefore
we should not use different names. And there are much more common
defines and names. It is simply stupid to include that header file in a
central place. I tend to fix this be adding "#ifndef" to rtnet.h. I will
have a closer look later.

Wolfgang.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Wolfgang Grandegger]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>> define this in core headers which are included everywhere. This said,
>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>> symbols with such prefix? Or do you share some code with socket-can that
>>> you do not want to touch?
>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>> it must not be called differently. Blackfin is obviously doing namespace
>> pollution which should be fixed upstream and meanwhile worked around in
>> Xenomai (e.g. via #undef CAN_ERR_MASK).
> 
> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
> The error seems to have been fixed upstream, since we get this warning
> with 2.6.30 and not with 2.6.31.

Right, the error comes from:

http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20

and is in conflict with "include/linux/can/can.h" anyhow.

Wolfgang.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>>> define this in core headers which are included everywhere. This said,
>>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>>> symbols with such prefix? Or do you share some code with socket-can that
>>>> you do not want to touch?
>>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>>> it must not be called differently. Blackfin is obviously doing namespace
>>> pollution which should be fixed upstream and meanwhile worked around in
>>> Xenomai (e.g. via #undef CAN_ERR_MASK).
>> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
>> The error seems to have been fixed upstream, since we get this warning
>> with 2.6.30 and not with 2.6.31.
> 
> Right, the error comes from:
> 
> http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20
> 
> and is in conflict with "include/linux/can/can.h" anyhow.

Ok, ok. My question was about rtdm/rtcan.h redefining what is already
defined in linux/can.h. Would not it make sense to include linux/can.h
instead? Of course, this is not something that needs fixing right now,
but would be better on the long run.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>>>> define this in core headers which are included everywhere. This said,
>>>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>>>> symbols with such prefix? Or do you share some code with socket-can that
>>>>> you do not want to touch?
>>>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>>>> it must not be called differently. Blackfin is obviously doing namespace
>>>> pollution which should be fixed upstream and meanwhile worked around in
>>>> Xenomai (e.g. via #undef CAN_ERR_MASK).
>>> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
>>> The error seems to have been fixed upstream, since we get this warning
>>> with 2.6.30 and not with 2.6.31.
>> Right, the error comes from:
>>
>> http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20
>>
>> and is in conflict with "include/linux/can/can.h" anyhow.
> 
> Ok, ok. My question was about rtdm/rtcan.h redefining what is already
> defined in linux/can.h. Would not it make sense to include linux/can.h
> instead? Of course, this is not something that needs fixing right now,
> but would be better on the long run.

Right. We just need to take care for pre-CAN kernels.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>>>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>>>>> define this in core headers which are included everywhere. This said,
>>>>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>>>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>>>>> symbols with such prefix? Or do you share some code with socket-can that
>>>>>> you do not want to touch?
>>>>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>>>>> it must not be called differently. Blackfin is obviously doing namespace
>>>>> pollution which should be fixed upstream and meanwhile worked around in
>>>>> Xenomai (e.g. via #undef CAN_ERR_MASK).
>>>> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
>>>> The error seems to have been fixed upstream, since we get this warning
>>>> with 2.6.30 and not with 2.6.31.
>>> Right, the error comes from:
>>>
>>> http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20
>>>
>>> and is in conflict with "include/linux/can/can.h" anyhow.
>> Ok, ok. My question was about rtdm/rtcan.h redefining what is already
>> defined in linux/can.h. Would not it make sense to include linux/can.h
>> instead? Of course, this is not something that needs fixing right now,
>> but would be better on the long run.
> 
> Right. We just need to take care for pre-CAN kernels.

In wrappers.h, as we do for every other variation of the kernel interface.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Wolfgang Grandegger]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> * rtcan: on blackfin we seem to have a conflict with rtcan.
>>>>>>> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
>>>>>>> define this in core headers which are included everywhere. This said,
>>>>>>> not prefixing a Xenomai symbol with something like XN seems to be asking
>>>>>>> for trouble. Wolfgang, do you think it would be possible to rename the
>>>>>>> symbols with such prefix? Or do you share some code with socket-can that
>>>>>>> you do not want to touch?
>>>>>> CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h),
>>>>>> it must not be called differently. Blackfin is obviously doing namespace
>>>>>> pollution which should be fixed upstream and meanwhile worked around in
>>>>>> Xenomai (e.g. via #undef CAN_ERR_MASK).
>>>>> Ok. But according to the build logs, it is redefined in rtdm/rtcan.h.
>>>>> The error seems to have been fixed upstream, since we get this warning
>>>>> with 2.6.30 and not with 2.6.31.
>>>> Right, the error comes from:
>>>>
>>>> http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20
>>>>
>>>> and is in conflict with "include/linux/can/can.h" anyhow.
>>> Ok, ok. My question was about rtdm/rtcan.h redefining what is already
>>> defined in linux/can.h. Would not it make sense to include linux/can.h
>>> instead? Of course, this is not something that needs fixing right now,
>>> but would be better on the long run.
>> Right. We just need to take care for pre-CAN kernels.
> 
> In wrappers.h, as we do for every other variation of the kernel interface.

Yes, I'm going to work on RT-Socket-CAN soon anyhow.

Wolfgang.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Patrice Kadionik]

Hi Gilles,

Gilles Chanteperdrix a écrit :
> Hi,
>
> Since I started talking about it, I have run build tests fixing a few
> things here and there. The current status is this (still at the same
> place: http://sisyphus.hd.free.fr/~gilles/bx):
>
> * analogy: I have tried to disable some parts of analogy when compiling
> on machines without CONFIG_PCI, as compiling parts using PCI on a
> machine without PCI support, give various levels of warning and even
> errors depending on the architecture. Doing this, I stumbled across this
> compilation error:
> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>
> So, Alex, could you:
> - fix that error, if this combination is supposed to make sense
> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> is not set (I tried and do this myself, but better one who knows than
> 100 who have to search...). As I said, doing this result in various
> levels of success depending on the architecture.
>
> * blackfin: I finally compiled blackfin! had to build a toolchain for
> that as the binary-only toolchain from analog.com uses glibc 2.8 and
> mine is 2.7. However, blackfin does not compile very well, as can be
> seen by the log:
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1
> It may happen that my toolchain is buggy or outdated though.
>
> * rtcan: on blackfin we seem to have a conflict with rtcan.
> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
> define this in core headers which are included everywhere. This said,
> not prefixing a Xenomai symbol with something like XN seems to be asking
> for trouble. Wolfgang, do you think it would be possible to rename the
> symbols with such prefix? Or do you share some code with socket-can that
> you do not want to touch?
>
> * nios2: I am lacking some important file needed to even start to compile.
>
>   
You may use this tutorial on how to use Xenomai on NIOS 2 softcore 
processor: 
http://uuu.enseirb.fr/~kadionik/nios-xenomai/Xenomai%20on%20NIOS%20II%20Softcore%20Processor.%20A%20step%20by%20step%20Guide.pdf

Regards,

Pat.
> Thanks in advance for your efforts.
> Regards.
>
>   


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
+ IMS Laboratory               http://www.ims-bordeaux.fr/             +
+ ENSEIRB                      http://www.enseirb.fr                   +
+ PO BOX 99                    fax   : +33 5.56.37.20.23               +
+ 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
+ FRANCE                       mailto:patrice.kadionik@domain.hid +
+----------------------------------------------------------------------+

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Patrice Kadionik]

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

Gilles Chanteperdrix a écrit :
> Hi,
>
> Since I started talking about it, I have run build tests fixing a few
> things here and there. The current status is this (still at the same
> place: http://sisyphus.hd.free.fr/~gilles/bx):
>   
Hi,

I've watched your log file for nios2 
(http://sisyphus.hd.free.fr/~gilles/bx/nios2/2.6.30-nios2-linux-uclibc-gcc-3.4.6/log.html#1). 
You have this error because you don't have generated before the HW 
design for the NIOS softcore processor: after synthesis with the Quartus 
Altera tools, you finally have a file for programming the FPGA circuit 
and a .ptf file that gives ASCII informations on your SoPC design (in a 
xml style...).
The error:
./arch/nios2/Makefile:131: *** Run "make hwselect SYSPTF=<system.ptf>" 
first. Stop.
is due to lack of this .ptf file.
This command generates a .h (nios2.h) file that makes relation between 
hardware and the Linux kernel (peripheral base address, irq number, 
peripheral name...)
Please find here: http://uuu.enseirb.fr/~kadionik/nios-xenomai/std_1s10.ptf
a valid .ptf file for Xenomai port.
Juste run :
$ make hwselect SYSPTF=path_to_std_1s10.ptf
for completing the kernel compilation...

Pat.




> * analogy: I have tried to disable some parts of analogy when compiling
> on machines without CONFIG_PCI, as compiling parts using PCI on a
> machine without PCI support, give various levels of warning and even
> errors depending on the architecture. Doing this, I stumbled across this
> compilation error:
> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>
> So, Alex, could you:
> - fix that error, if this combination is supposed to make sense
> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> is not set (I tried and do this myself, but better one who knows than
> 100 who have to search...). As I said, doing this result in various
> levels of success depending on the architecture.
>
> * blackfin: I finally compiled blackfin! had to build a toolchain for
> that as the binary-only toolchain from analog.com uses glibc 2.8 and
> mine is 2.7. However, blackfin does not compile very well, as can be
> seen by the log:
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1
> It may happen that my toolchain is buggy or outdated though.
>
> * rtcan: on blackfin we seem to have a conflict with rtcan.
> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
> define this in core headers which are included everywhere. This said,
> not prefixing a Xenomai symbol with something like XN seems to be asking
> for trouble. Wolfgang, do you think it would be possible to rename the
> symbols with such prefix? Or do you share some code with socket-can that
> you do not want to touch?
>
> * nios2: I am lacking some important file needed to even start to compile.
>
> Thanks in advance for your efforts.
> Regards.
>
>   


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
+ IMS Laboratory               http://www.ims-bordeaux.fr/             +
+ ENSEIRB                      http://www.enseirb.fr                   +
+ PO BOX 99                    fax   : +33 5.56.37.20.23               +
+ 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
+ FRANCE                       mailto:patrice.kadionik@domain.hid +
+----------------------------------------------------------------------+


[-- Attachment #2: Type: text/html, Size: 5080 bytes --]

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Patrice Kadionik wrote:
> Gilles Chanteperdrix a écrit :
>> Hi,
>>
>> Since I started talking about it, I have run build tests fixing a few
>> things here and there. The current status is this (still at the same
>> place: http://sisyphus.hd.free.fr/~gilles/bx):
>>   
> Hi,
> 
> I've watched your log file for nios2
> (http://sisyphus.hd.free.fr/~gilles/bx/nios2/2.6.30-nios2-linux-uclibc-gcc-3.4.6/log.html#1).
> You have this error because you don't have generated before the HW
> design for the NIOS softcore processor: after synthesis with the Quartus
> Altera tools, you finally have a file for programming the FPGA circuit
> and a .ptf file that gives ASCII informations on your SoPC design (in a
> xml style...).
> The error:
> ./arch/nios2/Makefile:131: *** Run "make hwselect SYSPTF=<system.ptf>"
> first. Stop.
> is due to lack of this .ptf file.
> This command generates a .h (nios2.h) file that makes relation between
> hardware and the Linux kernel (peripheral base address, irq number,
> peripheral name...)
> Please find here: http://uuu.enseirb.fr/~kadionik/nios-xenomai/std_1s10.ptf
> a valid .ptf file for Xenomai port.
> Juste run :
> $ make hwselect SYSPTF=path_to_std_1s10.ptf
> for completing the kernel compilation...

Ok. Thanks, nios2 now compiles.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Alexis Berlemont]

Hi Gilles,

Gilles Chanteperdrix wrote:
> Hi,
> 
> Since I started talking about it, I have run build tests fixing a few
> things here and there. The current status is this (still at the same
> place: http://sisyphus.hd.free.fr/~gilles/bx):
> 
> * analogy: I have tried to disable some parts of analogy when compiling
> on machines without CONFIG_PCI, as compiling parts using PCI on a
> machine without PCI support, give various levels of warning and even
> errors depending on the architecture. Doing this, I stumbled across this
> compilation error:
> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
> 
> So, Alex, could you:
> - fix that error, if this combination is supposed to make sense
Yes it makes sense. I think the MITE is integrated into all PCI boards
but the driver should work with the MITE disabled (one day, we could add
the ISA boards).
> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> is not set (I tried and do this myself, but better one who knows than
> 100 who have to search...). As I said, doing this result in various
> levels of success depending on the architecture.
Ack. I will fix these problems as quickly as possible.

> 
> * blackfin: I finally compiled blackfin! had to build a toolchain for
> that as the binary-only toolchain from analog.com uses glibc 2.8 and
> mine is 2.7. However, blackfin does not compile very well, as can be
> seen by the log:
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1
> It may happen that my toolchain is buggy or outdated though.
> 
> * rtcan: on blackfin we seem to have a conflict with rtcan.
> The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
> define this in core headers which are included everywhere. This said,
> not prefixing a Xenomai symbol with something like XN seems to be asking
> for trouble. Wolfgang, do you think it would be possible to rename the
> symbols with such prefix? Or do you share some code with socket-can that
> you do not want to touch?
> 
> * nios2: I am lacking some important file needed to even start to compile.
> 
> Thanks in advance for your efforts.
> Regards.
> 
Alexis.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Alexis Berlemont wrote:
> Hi Gilles,
> 
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> Since I started talking about it, I have run build tests fixing a few
>> things here and there. The current status is this (still at the same
>> place: http://sisyphus.hd.free.fr/~gilles/bx):
>>
>> * analogy: I have tried to disable some parts of analogy when compiling
>> on machines without CONFIG_PCI, as compiling parts using PCI on a
>> machine without PCI support, give various levels of warning and even
>> errors depending on the architecture. Doing this, I stumbled across this
>> compilation error:
>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>>
>> So, Alex, could you:
>> - fix that error, if this combination is supposed to make sense
> Yes it makes sense. I think the MITE is integrated into all PCI boards
> but the driver should work with the MITE disabled (one day, we could add
> the ISA boards).
>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
>> is not set (I tried and do this myself, but better one who knows than
>> 100 who have to search...). As I said, doing this result in various
>> levels of success depending on the architecture.
> Ack. I will fix these problems as quickly as possible.

Ok. The fix for the second problem would be nice to have soon, as
analogy breaks the build on blackfin for this reason. If it is of any
help, you can send me a patch for this fix only which I will apply on my
side while you are working on other changes.

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Alexis Berlemont]

Hi Gilles,

Gilles Chanteperdrix wrote:
> Alexis Berlemont wrote:
>> Hi Gilles,
>>
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> Since I started talking about it, I have run build tests fixing a few
>>> things here and there. The current status is this (still at the same
>>> place: http://sisyphus.hd.free.fr/~gilles/bx):
>>>
>>> * analogy: I have tried to disable some parts of analogy when compiling
>>> on machines without CONFIG_PCI, as compiling parts using PCI on a
>>> machine without PCI support, give various levels of warning and even
>>> errors depending on the architecture. Doing this, I stumbled across this
>>> compilation error:
>>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
>>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>>>
>>> So, Alex, could you:
>>> - fix that error, if this combination is supposed to make sense
>> Yes it makes sense. I think the MITE is integrated into all PCI boards
>> but the driver should work with the MITE disabled (one day, we could add
>> the ISA boards).
>>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
>>> is not set (I tried and do this myself, but better one who knows than
>>> 100 who have to search...). As I said, doing this result in various
>>> levels of success depending on the architecture.
>> Ack. I will fix these problems as quickly as possible.
> 
> Ok. The fix for the second problem would be nice to have soon, as
> analogy breaks the build on blackfin for this reason. If it is of any
> help, you can send me a patch for this fix only which I will apply on my
> side while you are working on other changes.
> 

I modified the common part of the NI driver so that the PCI code can be 
disabled without any compilation issues.

I made a pull request which contains the fixes.

Merry Christmas.

Alexis.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Alexis Berlemont wrote:
> Hi Gilles,
> 
> Gilles Chanteperdrix wrote:
>> Alexis Berlemont wrote:
>>> Hi Gilles,
>>>
>>> Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> Since I started talking about it, I have run build tests fixing a few
>>>> things here and there. The current status is this (still at the same
>>>> place: http://sisyphus.hd.free.fr/~gilles/bx):
>>>>
>>>> * analogy: I have tried to disable some parts of analogy when compiling
>>>> on machines without CONFIG_PCI, as compiling parts using PCI on a
>>>> machine without PCI support, give various levels of warning and even
>>>> errors depending on the architecture. Doing this, I stumbled across this
>>>> compilation error:
>>>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
>>>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>>>>
>>>> So, Alex, could you:
>>>> - fix that error, if this combination is supposed to make sense
>>> Yes it makes sense. I think the MITE is integrated into all PCI boards
>>> but the driver should work with the MITE disabled (one day, we could add
>>> the ISA boards).
>>>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
>>>> is not set (I tried and do this myself, but better one who knows than
>>>> 100 who have to search...). As I said, doing this result in various
>>>> levels of success depending on the architecture.
>>> Ack. I will fix these problems as quickly as possible.
>> Ok. The fix for the second problem would be nice to have soon, as
>> analogy breaks the build on blackfin for this reason. If it is of any
>> help, you can send me a patch for this fix only which I will apply on my
>> side while you are working on other changes.
>>
> 
> I modified the common part of the NI driver so that the PCI code can be 
> disabled without any compilation issues.
> 
> I made a pull request which contains the fixes.

Thanks, but well, the compilation still fails on blackfin:
http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#13

And we get a new warning on most platforms (x86 and powerpc, and ixp4xx,
which is an ARM with PCI support).

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Philippe Gerum]

On Sat, 2009-12-26 at 19:09 +0100, Gilles Chanteperdrix wrote:
> Alexis Berlemont wrote:
> > Hi Gilles,
> > 
> > Gilles Chanteperdrix wrote:
> >> Alexis Berlemont wrote:
> >>> Hi Gilles,
> >>>
> >>> Gilles Chanteperdrix wrote:
> >>>> Hi,
> >>>>
> >>>> Since I started talking about it, I have run build tests fixing a few
> >>>> things here and there. The current status is this (still at the same
> >>>> place: http://sisyphus.hd.free.fr/~gilles/bx):
> >>>>
> >>>> * analogy: I have tried to disable some parts of analogy when compiling
> >>>> on machines without CONFIG_PCI, as compiling parts using PCI on a
> >>>> machine without PCI support, give various levels of warning and even
> >>>> errors depending on the architecture. Doing this, I stumbled across this
> >>>> compilation error:
> >>>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> >>>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
> >>>>
> >>>> So, Alex, could you:
> >>>> - fix that error, if this combination is supposed to make sense
> >>> Yes it makes sense. I think the MITE is integrated into all PCI boards
> >>> but the driver should work with the MITE disabled (one day, we could add
> >>> the ISA boards).
> >>>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> >>>> is not set (I tried and do this myself, but better one who knows than
> >>>> 100 who have to search...). As I said, doing this result in various
> >>>> levels of success depending on the architecture.
> >>> Ack. I will fix these problems as quickly as possible.
> >> Ok. The fix for the second problem would be nice to have soon, as
> >> analogy breaks the build on blackfin for this reason. If it is of any
> >> help, you can send me a patch for this fix only which I will apply on my
> >> side while you are working on other changes.
> >>
> > 
> > I modified the common part of the NI driver so that the PCI code can be 
> > disabled without any compilation issues.
> > 
> > I made a pull request which contains the fixes.
> 
> Thanks, but well, the compilation still fails on blackfin:
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#13
> 

This is because arch/blackfin/include/asm/pci.h does not include
asm-generic/pci-dma-compat.h in 2.6.30 yet. Upstream fixed this is
2.6.31.

So either we patch in some ugliness like below, or I issue a revised
pipeline patch for 2.6.30.6 which fixes this upstream bug.

diff --git a/include/asm-blackfin/wrappers.h b/include/asm-blackfin/wrappers.h
index 6556e74..6111f64 100644
--- a/include/asm-blackfin/wrappers.h
+++ b/include/asm-blackfin/wrappers.h
@@ -27,6 +27,11 @@
 #include <asm-generic/xenomai/wrappers.h> /* Read the generic portion. */
 #include <linux/interrupt.h>
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
+#include <linux/pci.h>
+#include <asm-generic/pci-dma-compat.h>
+#endif
+
 #define wrap_phys_mem_prot(filp,pfn,size,prot)	(prot)
 
 #define wrap_strncpy_from_user(dstP, srcP, n)	strncpy_from_user(dstP, srcP, n)

> And we get a new warning on most platforms (x86 and powerpc, and ixp4xx,
> which is an ARM with PCI support).
> 


-- 
Philippe.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Sat, 2009-12-26 at 19:09 +0100, Gilles Chanteperdrix wrote:
>> Alexis Berlemont wrote:
>>> Hi Gilles,
>>>
>>> Gilles Chanteperdrix wrote:
>>>> Alexis Berlemont wrote:
>>>>> Hi Gilles,
>>>>>
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Since I started talking about it, I have run build tests fixing a few
>>>>>> things here and there. The current status is this (still at the same
>>>>>> place: http://sisyphus.hd.free.fr/~gilles/bx):
>>>>>>
>>>>>> * analogy: I have tried to disable some parts of analogy when compiling
>>>>>> on machines without CONFIG_PCI, as compiling parts using PCI on a
>>>>>> machine without PCI support, give various levels of warning and even
>>>>>> errors depending on the architecture. Doing this, I stumbled across this
>>>>>> compilation error:
>>>>>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
>>>>>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
>>>>>>
>>>>>> So, Alex, could you:
>>>>>> - fix that error, if this combination is supposed to make sense
>>>>> Yes it makes sense. I think the MITE is integrated into all PCI boards
>>>>> but the driver should work with the MITE disabled (one day, we could add
>>>>> the ISA boards).
>>>>>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
>>>>>> is not set (I tried and do this myself, but better one who knows than
>>>>>> 100 who have to search...). As I said, doing this result in various
>>>>>> levels of success depending on the architecture.
>>>>> Ack. I will fix these problems as quickly as possible.
>>>> Ok. The fix for the second problem would be nice to have soon, as
>>>> analogy breaks the build on blackfin for this reason. If it is of any
>>>> help, you can send me a patch for this fix only which I will apply on my
>>>> side while you are working on other changes.
>>>>
>>> I modified the common part of the NI driver so that the PCI code can be 
>>> disabled without any compilation issues.
>>>
>>> I made a pull request which contains the fixes.
>> Thanks, but well, the compilation still fails on blackfin:
>> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#13
>>
> 
> This is because arch/blackfin/include/asm/pci.h does not include
> asm-generic/pci-dma-compat.h in 2.6.30 yet. Upstream fixed this is
> 2.6.31.
> 
> So either we patch in some ugliness like below, or I issue a revised
> pipeline patch for 2.6.30.6 which fixes this upstream bug.

Ok. As you wish. Could you also have a look at the bf561 compilation? It
seems rtdm gets undefined references to some rthal_atomic* operations.
http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.31-bfin-uclinux-gcc-4.1.2/log.html#1

-- 
					    Gilles.

Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.

[Philippe Gerum]

On Sat, 2009-12-26 at 23:54 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Sat, 2009-12-26 at 19:09 +0100, Gilles Chanteperdrix wrote:
> >> Alexis Berlemont wrote:
> >>> Hi Gilles,
> >>>
> >>> Gilles Chanteperdrix wrote:
> >>>> Alexis Berlemont wrote:
> >>>>> Hi Gilles,
> >>>>>
> >>>>> Gilles Chanteperdrix wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Since I started talking about it, I have run build tests fixing a few
> >>>>>> things here and there. The current status is this (still at the same
> >>>>>> place: http://sisyphus.hd.free.fr/~gilles/bx):
> >>>>>>
> >>>>>> * analogy: I have tried to disable some parts of analogy when compiling
> >>>>>> on machines without CONFIG_PCI, as compiling parts using PCI on a
> >>>>>> machine without PCI support, give various levels of warning and even
> >>>>>> errors depending on the architecture. Doing this, I stumbled across this
> >>>>>> compilation error:
> >>>>>> http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1
> >>>>>> this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE.
> >>>>>>
> >>>>>> So, Alex, could you:
> >>>>>> - fix that error, if this combination is supposed to make sense
> >>>>> Yes it makes sense. I think the MITE is integrated into all PCI boards
> >>>>> but the driver should work with the MITE disabled (one day, we could add
> >>>>> the ISA boards).
> >>>>>> - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI
> >>>>>> is not set (I tried and do this myself, but better one who knows than
> >>>>>> 100 who have to search...). As I said, doing this result in various
> >>>>>> levels of success depending on the architecture.
> >>>>> Ack. I will fix these problems as quickly as possible.
> >>>> Ok. The fix for the second problem would be nice to have soon, as
> >>>> analogy breaks the build on blackfin for this reason. If it is of any
> >>>> help, you can send me a patch for this fix only which I will apply on my
> >>>> side while you are working on other changes.
> >>>>
> >>> I modified the common part of the NI driver so that the PCI code can be 
> >>> disabled without any compilation issues.
> >>>
> >>> I made a pull request which contains the fixes.
> >> Thanks, but well, the compilation still fails on blackfin:
> >> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#13
> >>
> > 
> > This is because arch/blackfin/include/asm/pci.h does not include
> > asm-generic/pci-dma-compat.h in 2.6.30 yet. Upstream fixed this is
> > 2.6.31.
> > 
> > So either we patch in some ugliness like below, or I issue a revised
> > pipeline patch for 2.6.30.6 which fixes this upstream bug.
> 
> Ok. As you wish. Could you also have a look at the bf561 compilation? It
> seems rtdm gets undefined references to some rthal_atomic* operations.
> http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.31-bfin-uclinux-gcc-4.1.2/log.html#1
> 

Missing exports. Will fix.

-- 
Philippe.