date:20171121

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

2017-11-21 Thread Leopold Palomo-Avellaneda

On 22/11/17 02:44, Jack Lee wrote:
> 
> 
> On 11/21/2017 04:01 PM, Henning Schild wrote:
>> Am Tue, 21 Nov 2017 08:28:11 +0100
>> schrieb Leopold Palomo-Avellaneda :
>>
>>> On 21/11/17 06:52, Jack Lee wrote:
 Hello,

    My board cpu is Intel Atom CPU N2800. I am using xenomai 3.0.6
 with linux 4.9.51. I get the following error when compiling the
 kernel. Can anyone give me some help? Thanks!

    CC  arch/x86/xenomai/machine.o
 In file included from arch/x86/xenomai/machine.c:22:0:
 arch/x86/xenomai/include/asm/xenomai/syscall.h: In function
 ‘__xn_get_syscall_nr’:
 arch/x86/xenomai/include/asm/xenomai/syscall.h:46:31: error:
 implicit declaration of function
 ‘__COBALT_CALL32_SYSNR’ [-Werror=implicit-function-declaration]
 #define __xn_syscall(regs)
 __COBALT_CALL32_SYSNR(__xn_reg_sys(regs) \ ^
 arch/x86/xenomai/include/asm/xenomai/syscall.h:60:32: note: in
 expansion of macro ‘__xn_syscall’ return __xn_syscall_p(regs) ?
 __xn_syscall(regs) :
>>> I had the same problem yesterday and Philippe Gerum answered:
>>>
> As a work around, drop CONFIG_IA32_EMULATION if you don't need
> it.
> I tried it, but got another error.
> 
> rivers/xenomai/net/drivers/eepro100.c: In function ‘eepro100_init_module’:
> drivers/xenomai/net/drivers/eepro100.c:1832:8: error: lvalue required as left
> operand of assignment
>   debug = speedo_debug; /* touch debug variable */
>     ^

Please,

cloud you check the lists emails of yesterday?. Robert Lange sent a patch to
solve this, at least in the intel cards.

Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

2017-11-21 Thread Jack Lee




On 11/21/2017 04:01 PM, Henning Schild wrote:

Am Tue, 21 Nov 2017 08:28:11 +0100
schrieb Leopold Palomo-Avellaneda :


On 21/11/17 06:52, Jack Lee wrote:

Hello,

   My board cpu is Intel Atom CPU N2800. I am using xenomai 3.0.6
with linux 4.9.51. I get the following error when compiling the
kernel. Can anyone give me some help? Thanks!

   CC  arch/x86/xenomai/machine.o
In file included from arch/x86/xenomai/machine.c:22:0:
arch/x86/xenomai/include/asm/xenomai/syscall.h: In function
‘__xn_get_syscall_nr’:
arch/x86/xenomai/include/asm/xenomai/syscall.h:46:31: error:
implicit declaration of function
‘__COBALT_CALL32_SYSNR’ [-Werror=implicit-function-declaration]
#define __xn_syscall(regs)
__COBALT_CALL32_SYSNR(__xn_reg_sys(regs) \ ^
arch/x86/xenomai/include/asm/xenomai/syscall.h:60:32: note: in
expansion of macro ‘__xn_syscall’ return __xn_syscall_p(regs) ?
__xn_syscall(regs) :

I had the same problem yesterday and Philippe Gerum answered:


As a work around, drop CONFIG_IA32_EMULATION if you don't need
it.

I tried it, but got another error.

rivers/xenomai/net/drivers/eepro100.c: In function ‘eepro100_init_module’:
drivers/xenomai/net/drivers/eepro100.c:1832:8: error: lvalue required as 
left operand of assignment

  debug = speedo_debug; /* touch debug variable */
^

There is also a commit on top of 3.0.6 that should solve that problem.
You could try with
http://git.xenomai.org/xenomai-3.git/snapshot/xenomai-3-cc283c7f26c1b097b94a61bb25c2564f51daf16d.tar.bz2

Henning


Best regards,

Leopold

I didn't try it. I think I should let the system run first, so I will 
use the 3.0.5 version temporarily and try 3.0.7 in the future.


Thanks, all.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] R: install xenomai on centos

2017-11-21 Thread 郭健







--

操千曲而后晓声，观千剑而后识器。



At 2017-11-20 15:29:25, "Fazio Maurizio"  
wrote:
>Hello,
>I installed the 3.18.20 linux kernel but the installation process is the same 
>for your kernel version.
>
>Try this installation process:
>
>#./xenomai-3.0.5/scripts/prepare-kernel.sh 
>--ipipe=ipipe-core-3.10.32-x86-9.patch --linux=linux-3.10.32
>
>Go to linux-3.10.32 folder and after the kernel configuration step
>#make rpm
>
>At the end of operations
>#cd /root/rpmbuild/RPMS/x86_64
>#rpm -ivh kernel-3.10.32-1.x86_64.rpm
>#rpm -ivh kernel-devel-3.10.32-1.x86_64.rpm
>#rpm -ivh kernel-headers-3.10.32-1.x86_64.rpm
>
>Auto configure the grub2
>#grub2-mkconfig
>

>Reboot the system
>
I tried your process step, but it doesn't work. When I used kernel 3.18.20, 
ipipe has a bug.
the grub info is attached.
can you give me some details ?
>
>Maurizio Fazio
>
>Chief Technical Office / Aircraft Systems
>Software Engineer
>
>Leonardo S.p.A.
>C.so Francia, 426 - Torino - 10146 - Italy
>Tel. +39 011 756 3308 / 3761
>maurizio.fa...@leonardocompany.com
>www.leonardocompany.com
>
>–——
>HELICOPTERS/AERONAUTICS/ELECTRONICS, DEFENCE & SECURITY SYSTEMS/SPACE
>–——
>
>
>
>Il presente messaggio e-mail e ogni suo allegato devono intendersi indirizzati 
>esclusivamente al destinatario indicato e considerarsi dal contenuto 
>strettamente riservato e confidenziale. Se non siete l'effettivo destinatario 
>o avete ricevuto il messaggio e-mail per errore, siete pregati di avvertire 
>immediatamente il mittente e di cancellare il suddetto messaggio e ogni suo 
>allegato dal vostro sistema informatico. Qualsiasi utilizzo, diffusione, copia 
>o archiviazione del presente messaggio da parte di chi non ne è il 
>destinatario è strettamente proibito e può dar luogo a responsabilità di 
>carattere civile e penale punibili ai sensi di legge.
>Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della 
>normativa vigente.
>
>The contents of this email message and any attachments are intended solely for 
>the addressee(s) and contain confidential and/or privileged information.
>If you are not the intended recipient of this message, or if this message has 
>been addressed to you in error, please immediately notify the sender and then 
>delete this message and any attachments from your system. If you are not the 
>intended recipient, you are hereby notified that any use, dissemination, 
>copying, or storage of this message or its attachments is strictly prohibited. 
>Unauthorized disclosure and/or use of information contained in this email 
>message may result in civil and criminal liability. “
>This e-mail has legal value according to the applicable laws only if it is 
>digitally signed by the sender
>-Messaggio originale-
>Da: Xenomai [mailto:xenomai-boun...@xenomai.org] Per conto di ??
>Inviato: domenica 19 novembre 2017 03:57
>A: xenomai@xenomai.org
>Oggetto: [Xenomai] install xenomai on centos
>
>Hi,
>
>I am attempting to install xenomai-3.x on centos7(kernel: 
>3.10.0-229.el7.x86_64, or 3.10.0-229.rt56.el7) for x86 XEON E5.
>I use:
>linux-3.10.32.tar.xz;
>xenomai-3.0.5.tar.bz2;
>ipipe-core-3.10.32-x86-9.patch;
>when I finished install linux with:
>#./xenomai-3.0.5/scripts/prepare-kernel.sh 
>--ipipe=ipipe-core-3.10.32-x86-9.patch --linux=linux-3.10.32 #make bzImage -j2 
>&& make modules -j2 && make modules_install && make install #reboot but the 
>system can't boot from kernel 3.10.32, and there was no any display on screen.
>
>
>
>
>--
>
>操千曲而后晓声，观千剑而后识器。
>___
>Xenomai mailing list
>Xenomai@xenomai.org
>https://xenomai.org/mailman/listinfo/xenomai
-- next part --
A non-text attachment was scrubbed...
Name: RHEL_7.1-2017-11-22-02-26-37.png
Type: image/png
Size: 18728 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: RHEL_7.1-2017-11-22-02-27-24.png
Type: image/png
Size: 15884 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: RHEL_7.1-2017-11-22-02-27-20.png
Type: image/png
Size: 16002 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: RHEL_7.1-2017-11-22-02-27-24.png
Type: image/png
Size: 15884 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: RHEL_7.1-2017-11-22-02-27-20.png
Type: image/png
Size: 16002 bytes
Desc: not available
URL:

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

2017-11-21 Thread Dmitriy Cherkasov


On 11/21/2017 09:11 AM, Philippe Gerum wrote:


So, let's talk about the elephant in the room: the current situation of
the Xenomai project is not viable in the long run. I can only encourage
people who feel concerned about it to discuss openly the practical steps
to best address this challenge.


Hi Philippe,

I would be happy to help any way that I can, especially with any of the new 
pipeline work.


Having said that, I think this is a good discussion to have. If there are 
commercial or institutional users of any of the somewhat neglected subsystems, 
this would be a good time to remind them to invest some resources into 
maintaining these things in the upstream project.


I think in general, hobbyist contributors will mostly work on what they find 
interesting to themselves, and if there is no hobbyist or commercial support for 
certain features then perhaps it does make sense to drop them.


-Dmitriy

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

2017-11-21 Thread Auel, Kendall

Hi Philippe,

Is there an online bug tracking and feature request database? This would be a 
useful way to distribute work and to sync up contributors. I think the kernel 
uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.

I'd like to contribute in some way. I've been having a lot of fun as a Xenomai 
user.

Regards,
Kendall


-Original Message-
From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Philippe Gerum
Sent: Tuesday, November 21, 2017 9:12 AM
To: Xenomai@xenomai.org
Subject: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room


As the GIT commit history shows, there has been no sustained effort in 
maintaining several of the Xenomai I/O frameworks for several months (e.g. 
RTnet, analogy), even years in some cases, despite obvious bugs are still 
haunting the code base according to the mailing list. The situation has reached 
a point where I see no alternative to dropping them if the situation does not 
improve, because there is absolutely no point in this project shipping bit rot 
software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since Gilles 
passed away last year, I have not been scaling to the Xenomai maintenance, 
development and documentation tasks, with the requirement of running my 
business in parallel.

The solution to this serious problem is fitting the project to the available 
resources by narrowing its goal, or conversely, by growing the pool of 
contributors.

In addition, we can rework the most tricky part of the implementation to make 
it simpler to maintain, better documented, drastically lowering the barrier on 
entry for new contributors, which is what I've been working on for a year with 
the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again limited by 
the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of contributions 
from only a few committed people and companies. At this chance, let's mention 
that people who have been deploying Xenomai in industrial applications owe a 
lot to Wolfgang Denk from Denx Engineering, Siemens's Jan Kiszka and Jorge 
Ramirez, who have supported the project in crucial ways directly or indirectly 
over the years, and still do.

Xenomai as a dual kernel technology showcase has been quietly delivering on the 
promise of real-time Linux for more than a decade now, with marketing tools 
limited to showing decent code quality, good and reliable performance figures. 
As a result, to my current knowledge, Xenomai is present in a broad range of 
applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning, 
communication equipment, autonomous vehicles, control & automation systems in 
various plants.

On the sad side of the story, this project has virtually become a one-man show 
the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and stalled 
two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of the 
Xenomai project is not viable in the long run. I can only encourage people who 
feel concerned about it to discuss openly the practical steps to best address 
this challenge.

Thanks,

--
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

2017-11-21 Thread Greg Gallagher

Hi,
   I've been using Xenomai for a couple of years now and having been
preparing my first patch.
I'd love to help any way that is needed.  Documentation may be a good place
for me to start.  I'd also
be more than happy to help maintain some of the I/O frameworks.  I would
probably need a mentor
for guidance at the beginning.

Thanks

On Tue, Nov 21, 2017 at 12:11 PM, Philippe Gerum  wrote:

>
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI,
> GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>
> --
> Philippe.
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [RFC] RTnet, Analogy and the elephant in the room

2017-11-21 Thread Philippe Gerum


As the GIT commit history shows, there has been no sustained effort in
maintaining several of the Xenomai I/O frameworks for several months
(e.g. RTnet, analogy), even years in some cases, despite obvious bugs
are still haunting the code base according to the mailing list. The
situation has reached a point where I see no alternative to dropping
them if the situation does not improve, because there is absolutely no
point in this project shipping bit rot software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since
Gilles passed away last year, I have not been scaling to the Xenomai
maintenance, development and documentation tasks, with the requirement
of running my business in parallel.

The solution to this serious problem is fitting the project to the
available resources by narrowing its goal, or conversely, by growing the
pool of contributors.

In addition, we can rework the most tricky part of the implementation to
make it simpler to maintain, better documented, drastically lowering the
barrier on entry for new contributors, which is what I've been working
on for a year with the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again
limited by the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of
contributions from only a few committed people and companies. At this
chance, let's mention that people who have been deploying Xenomai in
industrial applications owe a lot to Wolfgang Denk from Denx
Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
the project in crucial ways directly or indirectly over the years, and
still do.

Xenomai as a dual kernel technology showcase has been quietly delivering
on the promise of real-time Linux for more than a decade now, with
marketing tools limited to showing decent code quality, good and
reliable performance figures. As a result, to my current knowledge,
Xenomai is present in a broad range of applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning,
communication equipment, autonomous vehicles, control & automation
systems in various plants.

On the sad side of the story, this project has virtually become a
one-man show the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and
stalled two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of
the Xenomai project is not viable in the long run. I can only encourage
people who feel concerned about it to discuss openly the practical steps
to best address this challenge.

Thanks,

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Fix compilation of e1000, eepro100 and igp rtnet drivers

2017-11-21 Thread Norbert Lange

Hello,

enabling RTNet will result in compile failures, because there is a
nameclash from some linux-headers.
This patch fixes some intel NICs to compile
-- next part --
A non-text attachment was scrubbed...
Name: 0001-rtnet-driver-fix-compilation-of-intel-drivers.patch
Type: text/x-patch
Size: 4353 bytes
Desc: not available
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20171121/6339e60e/attachment.bin>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai 3.0.6 doesn't build the patched kernel

2017-11-21 Thread Philippe Gerum


On 11/21/2017 10:16 AM, Leopold Palomo-Avellaneda wrote:

On 20/11/17 17:26, Leopold Palomo-Avellaneda wrote:

On 20/11/17 17:25, Leopold Palomo-Avellaneda wrote:

On 20/11/17 14:38, Philippe Gerum wrote:

On 11/20/2017 01:14 PM, Leopold Palomo-Avellaneda wrote:

Hi,

trying to build the new Xenomai version (3.0.6), after have prepared the linux
sources, I got this error:

In file included from arch/x86/xenomai/machine.c:22:0:
arch/x86/xenomai/include/asm/xenomai/syscall.h: In function
‘__xn_get_syscall_nr’:
arch/x86/xenomai/include/asm/xenomai/syscall.h:46:31: error: implicit
declaration of function ‘__COBALT_CALL32_SYSNR’
[-Werror=implicit-function-declaration]
   #define __xn_syscall(regs)    __COBALT_CALL32_SYSNR(__xn_reg_sys(regs) \
     ^
arch/x86/xenomai/include/asm/xenomai/syscall.h:60:32: note: in expansion of
macro ‘__xn_syscall’
    return __xn_syscall_p(regs) ? __xn_syscall(regs) :
  ^~~~
cc1: some warnings being treated as errors

I have used the prepare-kernel script and built the Debian packages. The
platform is a Debian Stretch (amd64) with the default compiler.

linux version linux-4.9.51 and

http://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.9.51-x86-4.patch

as a patch.





As a work around, drop CONFIG_IA32_EMULATION if you don't need it.



Hi,

trying to compile again I found some ugly warnings (gcc-6)


[snip]




it's strange to me because 3.0.5 built without any problems. Probably I activate
something in the kernel that provoke the errors. Any idea?.




Not yet. Thanks for the heads up though.

We used to have a build farm for checking proper compilation of many 
configurations nightly until last year, but we do not anymore. 
Therefore, those issues are likely to pop up in the future, until the 
situation is fixed.


Meanwhile, please send me the .config privately. I'll have a look. Thanks.

--
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai 3.0.6 doesn't build the patched kernel

2017-11-21 Thread Leopold Palomo-Avellaneda

On 20/11/17 17:26, Leopold Palomo-Avellaneda wrote:
> On 20/11/17 17:25, Leopold Palomo-Avellaneda wrote:
>> On 20/11/17 14:38, Philippe Gerum wrote:
>>> On 11/20/2017 01:14 PM, Leopold Palomo-Avellaneda wrote:
 Hi,

 trying to build the new Xenomai version (3.0.6), after have prepared the 
 linux
 sources, I got this error:

 In file included from arch/x86/xenomai/machine.c:22:0:
 arch/x86/xenomai/include/asm/xenomai/syscall.h: In function
 ‘__xn_get_syscall_nr’:
 arch/x86/xenomai/include/asm/xenomai/syscall.h:46:31: error: implicit
 declaration of function ‘__COBALT_CALL32_SYSNR’
 [-Werror=implicit-function-declaration]
   #define __xn_syscall(regs)    __COBALT_CALL32_SYSNR(__xn_reg_sys(regs) \
     ^
 arch/x86/xenomai/include/asm/xenomai/syscall.h:60:32: note: in expansion of
 macro ‘__xn_syscall’
    return __xn_syscall_p(regs) ? __xn_syscall(regs) :
  ^~~~
 cc1: some warnings being treated as errors

 I have used the prepare-kernel script and built the Debian packages. The
 platform is a Debian Stretch (amd64) with the default compiler.

 linux version linux-4.9.51 and

 http://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.9.51-x86-4.patch

 as a patch.

>>>
>>> As a work around, drop CONFIG_IA32_EMULATION if you don't need it.
>>>

Hi,

trying to compile again I found some ugly warnings (gcc-6)

drivers/xenomai/analogy/buffer.c: In function ‘a4l_ioctl_bufcfg’:
drivers/xenomai/analogy/buffer.c:611:38: warning: ‘*((void *)&buf_cfg+8)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
   cxt->dev->transfer.default_bufsize = buf_cfg.buf_size;
   ~~~^~

drivers/xenomai/can/sja1000/rtcan_adv_pci.c: In function 
‘rtcan_adv_pci_add_chan’:
drivers/xenomai/can/sja1000/rtcan_adv_pci.c:163:3: warning: this ‘else’ clause
does not guard... [-Wmisleading-indentation]
   else
   ^~~~
drivers/xenomai/can/sja1000/rtcan_adv_pci.c:165:4: note: ...this statement, but
the latter is misleadingly indented as if it is guarded by the ‘else’
if (!base_addr) {
^~

drivers/xenomai/net/stack/rtwlan.c:171:2: warning: this ‘if’ clause does not
guard... [-Wmisleading-indentation]
  if (mutex_lock_interruptible(&rtdev->nrt_lock))
  ^~

and some erros with 'debug'

./arch/x86/include/asm/traps.h:13:17: error: ‘debug’ redeclared as different
kind of symbol
 asmlinkage void debug(void);
 ^
drivers/xenomai/net/drivers/eepro100.c:55:12: note: previous definition of
‘debug’ was here
 static int debug = -1; /* The debug level */
^
In file included from ./include/linux/module.h:18:0,
 from drivers/xenomai/net/drivers/eepro100.c:85:
drivers/xenomai/net/drivers/eepro100.c: In function ‘__check_debug’:
./include/linux/moduleparam.h:146:27: error: return from incompatible pointer
type [-Werror=incompatible-pointer-types]
  param_check_##type(name, &(value));   \
   ^
./include/linux/moduleparam.h:344:68: note: in definition of macro 
‘__param_check’
  static inline type __always_unused *__check_##name(void) { return(p); }
^
./include/linux/moduleparam.h:146:2: note: in expansion of macro 
‘param_check_int’
  param_check_##type(name, &(value));   \
  ^~~~
./include/linux/moduleparam.h:126:2: note: in expansion of macro
‘module_param_named’
  module_param_named(name, name, type, perm)
  ^~
drivers/xenomai/net/drivers/eepro100.c:123:1: note: in expansion of macro
‘module_param’
 module_param(debug, int, 0444);
 ^~~~
drivers/xenomai/net/drivers/eepro100.c: In function ‘eepro100_init_module’:
drivers/xenomai/net/drivers/eepro100.c:1832:8: error: lvalue required as left
operand of assignment
  debug = speedo_debug; /* touch debug variable */
^
At top level:
drivers/xenomai/net/drivers/eepro100.c:55:12: warning: ‘debug’ defined but not
used [-Wunused-variable]
 static int debug = -1; /* The debug level */
^

##

drivers/xenomai/net/drivers/natsemi.c:199:12: error: ‘debug’ redeclared as
different kind of symbol
 static int debug = -1;
^
In file included from arch/x86/xenomai/include/asm/xenomai/thread.h:25:0,
 from include/xenomai/cobalt/kernel/thread.h:35,
 from include/xenomai/cobalt/kernel/sched.h:24,
 from include/xenomai/rtdm/driver.h:37,
 from drivers/xenomai/net/stack/include/rtnet.h:99,
 from drivers/xenomai/net/stack/include/rtskb.h:32,
 from drivers/xenomai/net/stack/include

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

2017-11-21 Thread Henning Schild

Am Tue, 21 Nov 2017 08:28:11 +0100
schrieb Leopold Palomo-Avellaneda :

> On 21/11/17 06:52, Jack Lee wrote:
> > Hello,
> > 
> >   My board cpu is Intel Atom CPU N2800. I am using xenomai 3.0.6
> > with linux 4.9.51. I get the following error when compiling the
> > kernel. Can anyone give me some help? Thanks!
> > 
> >   CC  arch/x86/xenomai/machine.o
> > In file included from arch/x86/xenomai/machine.c:22:0:
> > arch/x86/xenomai/include/asm/xenomai/syscall.h: In function
> > ‘__xn_get_syscall_nr’:
> > arch/x86/xenomai/include/asm/xenomai/syscall.h:46:31: error:
> > implicit declaration of function
> > ‘__COBALT_CALL32_SYSNR’ [-Werror=implicit-function-declaration]
> > #define __xn_syscall(regs)
> > __COBALT_CALL32_SYSNR(__xn_reg_sys(regs) \ ^
> > arch/x86/xenomai/include/asm/xenomai/syscall.h:60:32: note: in
> > expansion of macro ‘__xn_syscall’ return __xn_syscall_p(regs) ?
> > __xn_syscall(regs) :  
> 
> I had the same problem yesterday and Philippe Gerum answered:
> 
> >> As a work around, drop CONFIG_IA32_EMULATION if you don't need
> >> it.  

There is also a commit on top of 3.0.6 that should solve that problem.
You could try with
http://git.xenomai.org/xenomai-3.git/snapshot/xenomai-3-cc283c7f26c1b097b94a61bb25c2564f51daf16d.tar.bz2

Henning

> Best regards,
> 
> Leopold
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

Re: [Xenomai] R: install xenomai on centos

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Xenomai] [PATCH] Fix compilation of e1000, eepro100 and igp rtnet drivers

Re: [Xenomai] Xenomai 3.0.6 doesn't build the patched kernel

Re: [Xenomai] Xenomai 3.0.6 doesn't build the patched kernel

Re: [Xenomai] 3.0.6 with linux 4.9.51 on x86_64 Intel(R) Atom(TM) CPU N2800 compilation failed

11 matches

Site Navigation

Mail list logo

Footer information