Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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 99fax : +33 5.56.37.20.23 + + 33402 TALENCE Cedex voice : +33 5.56.84.23.47 + + FRANCE mailto:patrice.kadio...@ims-bordeaux.fr + +--+ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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 99fax : +33 5.56.37.20.23 + + 33402 TALENCE Cedex voice : +33 5.56.84.23.47 + + FRANCE mailto:patrice.kadio...@ims-bordeaux.fr + +--+ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
