You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(12) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(13) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(7) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
|
May
(6) |
Jun
(7) |
Jul
(8) |
Aug
(13) |
Sep
(28) |
Oct
(5) |
Nov
(17) |
Dec
(5) |
| 2007 |
Jan
(2) |
Feb
(18) |
Mar
(22) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(22) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
(7) |
May
(2) |
Jun
(18) |
Jul
(19) |
Aug
(6) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
| 2009 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
(20) |
Nov
|
Dec
(10) |
| 2011 |
Jan
(15) |
Feb
(33) |
Mar
(5) |
Apr
(8) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(21) |
Oct
(21) |
Nov
(12) |
Dec
(7) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jan K. <jan...@we...> - 2009-11-23 19:03:44
|
Nicola Pedrocchi wrote: > Hi, > > I am a new rtnet user, and I wish to knwo the state-of-art of the Arcnet > support in the project. > > As I read at > http://www.mail-archive.com/rtn...@li.../msg00134.html > > > a lot of work has been already done, but it is a very old thread. > > Can you give me some more information on this topic? Unless I totally forgot some detail (or some private chat), that code never saw the light of day outside Chris' lab (or wherever he worked). Just in case: I put him on CC, though I'm afraid that the address is no longer valid. Jan |
|
From: Nicola P. <nic...@it...> - 2009-11-23 18:51:31
|
Thanks Jan for the very fast reply! I will try to contact the reaserch gropu where Chris worked in order to understand what they did. Thanks again, nicola Jan Kiszka ha scritto: > Nicola Pedrocchi wrote: > >> Hi, >> >> I am a new rtnet user, and I wish to knwo the state-of-art of the Arcnet >> support in the project. >> >> As I read at >> http://www.mail-archive.com/rtn...@li.../msg00134.html >> >> >> a lot of work has been already done, but it is a very old thread. >> >> Can you give me some more information on this topic? >> > > Unless I totally forgot some detail (or some private chat), that code > never saw the light of day outside Chris' lab (or wherever he worked). > Just in case: I put him on CC, though I'm afraid that the address is no > longer valid. > > Jan > > -- Eng. Nicola Pedrocchi, Ph.D. ITIA-CNR Insititute of Industrial Technologies and Automation National Council of Researches Via Bassini 15 - 20133 Milano, Italy phone: +39 02 2369 9982 fax: +39 02 2369 9925 mobile: +39 328 19159914 email: nic...@it... ...Thanks for correcting me ----------------------------------------------------- |
|
From: Nicola P. <nic...@it...> - 2009-11-23 12:31:44
|
Hi, I am a new rtnet user, and I wish to knwo the state-of-art of the Arcnet support in the project. As I read at http://www.mail-archive.com/rtn...@li.../msg00134.html a lot of work has been already done, but it is a very old thread. Can you give me some more information on this topic? Thanks in advance!! Nicola Pedrocchi -- --------------------------------------------------- Eng. Nicola Pedrocchi, Ph.D --------------------------------------------------- ITIA-CNR Institute of Industrial Technologies and Automation Via Bassini, 15 20133 Milano - Italy --------------------------------------------------- Mobile: +39 328 9159914 / Office: +39 02 23699978 --------------------------------------------------- Thanks for correcting me! --------------------------------------------------- |
|
From: Kolja W. <rtn...@ix...> - 2009-11-18 08:06:56
|
Hi, I consider to use RTnet on a Blackfin BF537 with ucLinux/Xenomai. Well, at least I need some mechanism to send out a huge amount of measured data in real time with no packets lost. Now my question is whether anyone has a RT driver for the Blackfin MAC matching latest kernel? The latest code that I've found in the net seems to be Andras Garzo's > http://garzoand.web.elte.hu/blackfin/bfport/ Thanks for any hints Kolja |
|
From: James K. <jam...@gm...> - 2009-10-28 18:40:36
|
Hi Jan, Thank you for your response. We have a custom build process that was probably confusing the RTnet configure script, and I also just recently patched my development machine's kernel with xenomai to test RTnet with the device--the configuration script also seemed to want to use some of those directories. The resolution was to clean everything (make mrproper, make distclean) from both the custom build and kernel/linux directories and rebuild the kernel from the standard kernel/linux directory, reconfigure xenomai in that directory, and then rerun the RTnet configuration script. Along the way, I also moved all of the directories used for patching my development machine's kernel with xenomai, but that probably wasn't necessary. > CONFIG_RTNET_RTEXT_CLASSIC only applies to very old Xenomai version (or > to RTAI), so this is probably wrongly configured. But you did not tell > us what your Xenomai version is. I'm running xenomai 2.4.9.1. I'm guessing it was the same build process confusion (files that appeared missing because they were in other locations) that caused the configuration script to think that it was an old xenomai patch. > BTW, a short description how to cross-compile RTnet can also be found at > rtnet/drivers/mpc52xx_fec/README. I did happen upon that a few weeks ago when I was looking for a good example of porting a driver. Perhaps this would be a good thing for the wiki... Thanks, - James |
|
From: Jan K. <jan...@si...> - 2009-10-28 10:07:30
|
James Kilts wrote: > When I try to configure RTnet using the autotools in a cross-compile > environment, I get the error "*** Unsupported kernel version". What's > interesting is that I had this issue before, but by commenting out the > variable "CONFIG_RTNET_RTEXT_CLASSIC=y" in the configure.ac script it > could identify xenomai and the linux kernel. This allowed me to build > valid kernel modules for arm-linux. I committed all of the changes > into a local GIT repository and noted all of the environment variables > (PATH, CROSS_COMPILE, ARCH, etc) to ensure that I could get back to a > working build. > > This most recent problem started after I rebuilt my development > machine kernel with Xenomai and RTnet so that I could properly test > the device. Now that I go back to the cross-compile environment, I'm > running into the same problem as before, and I can verify that my > environment now to cross-compile RTnet is the same as before. > > I've also tried re-running the "scripts/autogen.sh" with > "CONFIG_RTNET_RTEXT_CLASSIC=y" enabled again, but it still gives the > same error. > > Finally, to my questions: Why did I have to disable > CONFIG_RTNET_RTEXT_CLASSIC to make the build work in the first place? > Are there known issues with the autotool configuration for RTnet? Any > ideas as to what could be going wrong? CONFIG_RTNET_RTEXT_CLASSIC only applies to very old Xenomai version (or to RTAI), so this is probably wrongly configured. But you did not tell us what your Xenomai version is. BTW, a short description how to cross-compile RTnet can also be found a trtnet/drivers/mpc52xx_fec/README. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux |
|
From: James K. <jam...@gm...> - 2009-10-27 18:11:05
|
When I try to configure RTnet using the autotools in a cross-compile environment, I get the error "*** Unsupported kernel version". What's interesting is that I had this issue before, but by commenting out the variable "CONFIG_RTNET_RTEXT_CLASSIC=y" in the configure.ac script it could identify xenomai and the linux kernel. This allowed me to build valid kernel modules for arm-linux. I committed all of the changes into a local GIT repository and noted all of the environment variables (PATH, CROSS_COMPILE, ARCH, etc) to ensure that I could get back to a working build. This most recent problem started after I rebuilt my development machine kernel with Xenomai and RTnet so that I could properly test the device. Now that I go back to the cross-compile environment, I'm running into the same problem as before, and I can verify that my environment now to cross-compile RTnet is the same as before. I've also tried re-running the "scripts/autogen.sh" with "CONFIG_RTNET_RTEXT_CLASSIC=y" enabled again, but it still gives the same error. Finally, to my questions: Why did I have to disable CONFIG_RTNET_RTEXT_CLASSIC to make the build work in the first place? Are there known issues with the autotool configuration for RTnet? Any ideas as to what could be going wrong? Thanks, - James |
|
From: Jan K. <jan...@si...> - 2009-10-26 16:19:18
|
Sebastian Smolorz wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Sebastian Smolorz wrote: >>>> Hello Jan, >>>> >>>> is there a reason why the RTnet drivers don't request their interrupts >>>> with flag RTDM_IRQTYPE_SHARED? We just stumbled over this fact when >>>> trying to get a CAN and an ethernet card working under rtcan resp. >>>> rtnet with both IRQ 17. >>> This has historical reasons. Old Xenomai and RTAI versions did not >>> support IRQ sharing. >>> >>> But I think we can now demand RTDM_API_VER >= 4 for RTnet (configure >>> test) and add this bit to all drivers. Patches will be warmly welcomed. >> ...provided all drivers are safe /wrt IRQ sharing. No blind conversion >> please, only after review, maybe for prominent drivers first. > > I could provide the result of a field test with the rt_natsemi driver. I'm > lacking the time to go through the source code, however. Would you refuse > the modification to the IRQ flag if we do not encounter any issues after the > test? The review is no black-magic: Does the interrupt handler also return RTDM_IRQ_NONE when it doesn't find any event in its status register or does it always answer with RTDM_IRQ_HANDLED? BTW, for the rt_natsemi, this basic check fails... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux |
|
From: Sebastian S. <sm...@rt...> - 2009-10-26 16:12:26
|
Jan Kiszka wrote: > Jan Kiszka wrote: > > Sebastian Smolorz wrote: > >> Hello Jan, > >> > >> is there a reason why the RTnet drivers don't request their interrupts > >> with flag RTDM_IRQTYPE_SHARED? We just stumbled over this fact when > >> trying to get a CAN and an ethernet card working under rtcan resp. > >> rtnet with both IRQ 17. > > > > This has historical reasons. Old Xenomai and RTAI versions did not > > support IRQ sharing. > > > > But I think we can now demand RTDM_API_VER >= 4 for RTnet (configure > > test) and add this bit to all drivers. Patches will be warmly welcomed. > > ...provided all drivers are safe /wrt IRQ sharing. No blind conversion > please, only after review, maybe for prominent drivers first. I could provide the result of a field test with the rt_natsemi driver. I'm lacking the time to go through the source code, however. Would you refuse the modification to the IRQ flag if we do not encounter any issues after the test? -- Sebastian |
|
From: Jan K. <jan...@si...> - 2009-10-26 15:55:08
|
Jan Kiszka wrote: > Sebastian Smolorz wrote: >> Hello Jan, >> >> is there a reason why the RTnet drivers don't request their interrupts with >> flag RTDM_IRQTYPE_SHARED? We just stumbled over this fact when trying to get >> a CAN and an ethernet card working under rtcan resp. rtnet with both IRQ >> 17. >> > > This has historical reasons. Old Xenomai and RTAI versions did not > support IRQ sharing. > > But I think we can now demand RTDM_API_VER >= 4 for RTnet (configure > test) and add this bit to all drivers. Patches will be warmly welcomed. > ...provided all drivers are safe /wrt IRQ sharing. No blind conversion please, only after review, maybe for prominent drivers first. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux |
|
From: Jan K. <jan...@si...> - 2009-10-26 15:49:46
|
Sebastian Smolorz wrote: > Hello Jan, > > is there a reason why the RTnet drivers don't request their interrupts with > flag RTDM_IRQTYPE_SHARED? We just stumbled over this fact when trying to get > a CAN and an ethernet card working under rtcan resp. rtnet with both IRQ > 17. > This has historical reasons. Old Xenomai and RTAI versions did not support IRQ sharing. But I think we can now demand RTDM_API_VER >= 4 for RTnet (configure test) and add this bit to all drivers. Patches will be warmly welcomed. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux |
|
From: Sebastian S. <sm...@rt...> - 2009-10-26 15:32:17
|
Hello Jan, is there a reason why the RTnet drivers don't request their interrupts with flag RTDM_IRQTYPE_SHARED? We just stumbled over this fact when trying to get a CAN and an ethernet card working under rtcan resp. rtnet with both IRQ 17. -- Sebastian |
|
From: Jan K. <jan...@we...> - 2009-09-15 19:07:09
|
Dietrich Pescoller wrote:
> Dear all,
>
> I tried to upgrade to rtnet 0.9.11 with kernel 2.19.7 and rtai 3.6-cv, but I m
> not able to compile i get the following errors:
>
> In file included from /usr/src/rtnet-0.9.11/stack/rtnet_module.c:33:
> /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:101: error: expected
> declaration specifiers or '...' before 'rtdm_selector_t'
> /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:103: warning: 'enum
> rtdm_selecttype' declared inside parameter list
> /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:103: warning: its scope is
> only this definition or declaration, which is probably not what you want
> make[4]: *** [/usr/src/rtnet-0.9.11/stack/rtnet_module.o] Error 1
> make[3]: *** [_module_/usr/src/rtnet-0.9.11/stack] Error 2
> make[3]: Leaving directory `/usr/src/linux-2.6.19.7-rtai-3.6'
> make[2]: *** [all-local.ko] Error 2
> make[2]: Leaving directory `/usr/src/rtnet-0.9.11/stack'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/rtnet-0.9.11/stack'
> make: *** [all-recursive] Error 1
>
>
> No problem indeed using rtnet-0.9.9 which compiles properly,
> shall I avoid the upgrade or is there a simple solution for the problem I get?
>
Hmm, looks like we have no proper feature check in the internal header.
Does this help?
diff --git a/stack/include/rtnet_socket.h b/stack/include/rtnet_socket.h
index 077c0e5..20bd42c 100644
--- a/stack/include/rtnet_socket.h
+++ b/stack/include/rtnet_socket.h
@@ -97,9 +97,11 @@ int rt_socket_common_ioctl(struct rtdm_dev_context *context,
int rt_socket_if_ioctl(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info,
int request, void *arg);
+#ifdef CONFIG_RTNET_SELECT_SUPPORT
int rt_socket_select_bind(struct rtdm_dev_context *context,
rtdm_selector_t *selector,
enum rtdm_selecttype type,
unsigned fd_index);
+#endif /* CONFIG_RTNET_SELECT_SUPPORT */
#endif /* __RTNET_SOCKET_H_ */
Jan
|
|
From: Dietrich P. <dpe...@mi...> - 2009-09-15 14:14:13
|
Dear all, I tried to upgrade to rtnet 0.9.11 with kernel 2.19.7 and rtai 3.6-cv, but I m not able to compile i get the following errors: In file included from /usr/src/rtnet-0.9.11/stack/rtnet_module.c:33: /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:101: error: expected declaration specifiers or '...' before 'rtdm_selector_t' /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:103: warning: 'enum rtdm_selecttype' declared inside parameter list /usr/src/rtnet-0.9.11/stack/include/rtnet_socket.h:103: warning: its scope is only this definition or declaration, which is probably not what you want make[4]: *** [/usr/src/rtnet-0.9.11/stack/rtnet_module.o] Error 1 make[3]: *** [_module_/usr/src/rtnet-0.9.11/stack] Error 2 make[3]: Leaving directory `/usr/src/linux-2.6.19.7-rtai-3.6' make[2]: *** [all-local.ko] Error 2 make[2]: Leaving directory `/usr/src/rtnet-0.9.11/stack' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/rtnet-0.9.11/stack' make: *** [all-recursive] Error 1 No problem indeed using rtnet-0.9.9 which compiles properly, shall I avoid the upgrade or is there a simple solution for the problem I get? Thx for the Help Dietrich -- MICROGATE S.r.l. Via Stradivari, 4 I-39100 BOLZANO-BOZEN (ITALY) P.I. 00709780217 Tel. 0471-501532 Fax. 0471-501524 Cell. +393357879496 http://www.microgate.it/engineering/ |
|
From: Jan K. <jan...@we...> - 2009-07-16 19:34:23
|
Wolfgang Grandegger wrote: > The configure script does not properly determine the real arch of the > kernel used for PowerPC, either "ppc" or "powerpc". This patch updates > configure to look for the string "ppc" in the symbolic link > "include/asm" of the kernel. If it does find it, the arch "ppc" is > selected, "powerpc" otherwise. > > Signed-off-by: Wolfgang Grandegger <wg...@de...> > Tested-by: Giammarco Zacheo <g.z...@gm...> Thanks again, applied. Jan |
|
From: Wolfgang G. <wg...@gr...> - 2009-07-16 14:54:40
|
The configure script does not properly determine the real arch of the
kernel used for PowerPC, either "ppc" or "powerpc". This patch updates
configure to look for the string "ppc" in the symbolic link
"include/asm" of the kernel. If it does find it, the arch "ppc" is
selected, "powerpc" otherwise.
Signed-off-by: Wolfgang Grandegger <wg...@de...>
Tested-by: Giammarco Zacheo <g.z...@gm...>
---
configure.ac | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: rtnet/configure.ac
===================================================================
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -59,7 +59,7 @@ case "$host" in
wanted_kernel_arch=CONFIG_ARM
;;
powerpc-*|ppc-*)
- RTNET_TARGET_ARCH=ppc
+ RTNET_TARGET_ARCH=powerpc
wanted_kernel_arch=CONFIG_PPC
;;
# mips-*|mipsel-*)
@@ -225,6 +225,13 @@ else
AC_MSG_RESULT([$RTEXT_LINUX_DIR (kernel ${RTEXT_LINUX_VERSION}${CONFIG_SMP:+-SMP} + Xenomai)])
fi
+# Fixup real arch for powerpc
+if test "${RTNET_TARGET_ARCH}" = "powerpc" ; then
+ AC_MSG_CHECKING([for real PowerPC arch])
+ readlink ${CONFIG_RTNET_LINUX_DIR}/include/asm | grep -q ppc && RTNET_TARGET_ARCH="ppc"
+ AC_MSG_RESULT([$RTNET_TARGET_ARCH])
+fi
+
#
# from now we think we've found some RT-extension, so if we got an error
# it will be fatal, thus exit with AC_MSG_ERROR
|
|
From: Jan K. <jan...@we...> - 2009-07-16 07:13:04
|
Giammarco Zacheo wrote:
> Yes it is.
>
Great. Wolfgang, could you post a version of your patch that should be
merged? You know: missing signed-off...
Thanks,
Jan
> On Fri, Jul 3, 2009 at 12:42 PM, Wolfgang Grandegger<wg...@gr...> wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
>>>> Giammarco Zacheo wrote:
>>>>> Hi,
>>>>> while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with
>>>>> xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running
>>>>> the configure script, which wasn't able to find Xenomai headers in the
>>>>> kernel tree. This is due to the fact that the configure script is
>>>>> still looking for the arch/ppc obsoleted directory.
>>>>>
>>>>> The following patch worked for me, but I'm afraid this could break
>>>>> compatibility with older kernels and/or RTAI/Xenomai releases. There's
>>>>> probably a better way to do this. Any ideas?
>>>>>
>>>>> Cheers,
>>>>> Giammarco
>>>>>
>>>>> --- a/configure.ac
>>>>> +++ b/configure.ac
>>>>> @@ -58,10 +58,14 @@ case "$host" in
>>>>> RTNET_TARGET_ARCH=arm
>>>>> wanted_kernel_arch=CONFIG_ARM
>>>>> ;;
>>>>> - powerpc-*|ppc-*)
>>>>> + ppc-*)
>>>>> RTNET_TARGET_ARCH=ppc
>>>>> wanted_kernel_arch=CONFIG_PPC
>>>>> ;;
>>>>> + powerpc-*)
>>>>> + RTNET_TARGET_ARCH=powerpc
>>>>> + wanted_kernel_arch=CONFIG_PPC
>>>>> + ;;
>>>>> # mips-*|mipsel-*)
>>>>> # RTNET_TARGET_ARCH=mips
>>>>> # wanted_kernel_arch=CONFIG_MIPS
>>>>>
>>>> Wolfgang, can you check if it breaks anything (specifically 2.4)?
>>> This does not work for Kernels using the arch/ppc tree. Retrieving the
>>> real ARCH from $host (powerpc-unknown-linux-gnu in my case) gives always
>>> "powerpc". Either we provide a configuration parameter "--arch=" or we
>>> try to retrieve ARCH from the kernel tree, e.g. by checking "include/asm".
>> Giammarco, does the patch below work for you?
>>
>> Wolfgang.
>>
>> ---
>> configure.ac | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> Index: rtnet/configure.ac
>> ===================================================================
>> --- rtnet.orig/configure.ac
>> +++ rtnet/configure.ac
>> @@ -59,7 +59,7 @@ case "$host" in
>> wanted_kernel_arch=CONFIG_ARM
>> ;;
>> powerpc-*|ppc-*)
>> - RTNET_TARGET_ARCH=ppc
>> + RTNET_TARGET_ARCH=powerpc
>> wanted_kernel_arch=CONFIG_PPC
>> ;;
>> # mips-*|mipsel-*)
>> @@ -225,6 +225,13 @@ else
>> AC_MSG_RESULT([$RTEXT_LINUX_DIR (kernel ${RTEXT_LINUX_VERSION}${CONFIG_SMP:+-SMP} + Xenomai)])
>> fi
>>
>> +# Fixup real arch for powerpc
>> +if test "${RTNET_TARGET_ARCH}" = "powerpc" ; then
>> + AC_MSG_CHECKING([for real PowerPC arch])
>> + readlink ${CONFIG_RTNET_LINUX_DIR}/include/asm | grep -q ppc && RTNET_TARGET_ARCH="ppc"
>> + AC_MSG_RESULT([$RTNET_TARGET_ARCH])
>> +fi
>> +
>> #
>> # from now we think we've found some RT-extension, so if we got an error
>> # it will be fatal, thus exit with AC_MSG_ERROR
>>
>>
|
|
From: Giammarco Z. <g.z...@gm...> - 2009-07-07 15:34:45
|
Yes it is.
Giammarco
On Fri, Jul 3, 2009 at 12:42 PM, Wolfgang Grandegger<wg...@gr...> wrote:
> Wolfgang Grandegger wrote:
>> Jan Kiszka wrote:
>>> Giammarco Zacheo wrote:
>>>> Hi,
>>>> while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with
>>>> xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running
>>>> the configure script, which wasn't able to find Xenomai headers in the
>>>> kernel tree. This is due to the fact that the configure script is
>>>> still looking for the arch/ppc obsoleted directory.
>>>>
>>>> The following patch worked for me, but I'm afraid this could break
>>>> compatibility with older kernels and/or RTAI/Xenomai releases. There's
>>>> probably a better way to do this. Any ideas?
>>>>
>>>> Cheers,
>>>> Giammarco
>>>>
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -58,10 +58,14 @@ case "$host" in
>>>> RTNET_TARGET_ARCH=arm
>>>> wanted_kernel_arch=CONFIG_ARM
>>>> ;;
>>>> - powerpc-*|ppc-*)
>>>> + ppc-*)
>>>> RTNET_TARGET_ARCH=ppc
>>>> wanted_kernel_arch=CONFIG_PPC
>>>> ;;
>>>> + powerpc-*)
>>>> + RTNET_TARGET_ARCH=powerpc
>>>> + wanted_kernel_arch=CONFIG_PPC
>>>> + ;;
>>>> # mips-*|mipsel-*)
>>>> # RTNET_TARGET_ARCH=mips
>>>> # wanted_kernel_arch=CONFIG_MIPS
>>>>
>>> Wolfgang, can you check if it breaks anything (specifically 2.4)?
>>
>> This does not work for Kernels using the arch/ppc tree. Retrieving the
>> real ARCH from $host (powerpc-unknown-linux-gnu in my case) gives always
>> "powerpc". Either we provide a configuration parameter "--arch=" or we
>> try to retrieve ARCH from the kernel tree, e.g. by checking "include/asm".
>
> Giammarco, does the patch below work for you?
>
> Wolfgang.
>
> ---
> configure.ac | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Index: rtnet/configure.ac
> ===================================================================
> --- rtnet.orig/configure.ac
> +++ rtnet/configure.ac
> @@ -59,7 +59,7 @@ case "$host" in
> wanted_kernel_arch=CONFIG_ARM
> ;;
> powerpc-*|ppc-*)
> - RTNET_TARGET_ARCH=ppc
> + RTNET_TARGET_ARCH=powerpc
> wanted_kernel_arch=CONFIG_PPC
> ;;
> # mips-*|mipsel-*)
> @@ -225,6 +225,13 @@ else
> AC_MSG_RESULT([$RTEXT_LINUX_DIR (kernel ${RTEXT_LINUX_VERSION}${CONFIG_SMP:+-SMP} + Xenomai)])
> fi
>
> +# Fixup real arch for powerpc
> +if test "${RTNET_TARGET_ARCH}" = "powerpc" ; then
> + AC_MSG_CHECKING([for real PowerPC arch])
> + readlink ${CONFIG_RTNET_LINUX_DIR}/include/asm | grep -q ppc && RTNET_TARGET_ARCH="ppc"
> + AC_MSG_RESULT([$RTNET_TARGET_ARCH])
> +fi
> +
> #
> # from now we think we've found some RT-extension, so if we got an error
> # it will be fatal, thus exit with AC_MSG_ERROR
>
>
|
|
From: Wolfgang G. <wg...@gr...> - 2009-07-03 10:42:53
|
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Giammarco Zacheo wrote:
>>> Hi,
>>> while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with
>>> xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running
>>> the configure script, which wasn't able to find Xenomai headers in the
>>> kernel tree. This is due to the fact that the configure script is
>>> still looking for the arch/ppc obsoleted directory.
>>>
>>> The following patch worked for me, but I'm afraid this could break
>>> compatibility with older kernels and/or RTAI/Xenomai releases. There's
>>> probably a better way to do this. Any ideas?
>>>
>>> Cheers,
>>> Giammarco
>>>
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -58,10 +58,14 @@ case "$host" in
>>> RTNET_TARGET_ARCH=arm
>>> wanted_kernel_arch=CONFIG_ARM
>>> ;;
>>> - powerpc-*|ppc-*)
>>> + ppc-*)
>>> RTNET_TARGET_ARCH=ppc
>>> wanted_kernel_arch=CONFIG_PPC
>>> ;;
>>> + powerpc-*)
>>> + RTNET_TARGET_ARCH=powerpc
>>> + wanted_kernel_arch=CONFIG_PPC
>>> + ;;
>>> # mips-*|mipsel-*)
>>> # RTNET_TARGET_ARCH=mips
>>> # wanted_kernel_arch=CONFIG_MIPS
>>>
>> Wolfgang, can you check if it breaks anything (specifically 2.4)?
>
> This does not work for Kernels using the arch/ppc tree. Retrieving the
> real ARCH from $host (powerpc-unknown-linux-gnu in my case) gives always
> "powerpc". Either we provide a configuration parameter "--arch=" or we
> try to retrieve ARCH from the kernel tree, e.g. by checking "include/asm".
Giammarco, does the patch below work for you?
Wolfgang.
---
configure.ac | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: rtnet/configure.ac
===================================================================
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -59,7 +59,7 @@ case "$host" in
wanted_kernel_arch=CONFIG_ARM
;;
powerpc-*|ppc-*)
- RTNET_TARGET_ARCH=ppc
+ RTNET_TARGET_ARCH=powerpc
wanted_kernel_arch=CONFIG_PPC
;;
# mips-*|mipsel-*)
@@ -225,6 +225,13 @@ else
AC_MSG_RESULT([$RTEXT_LINUX_DIR (kernel ${RTEXT_LINUX_VERSION}${CONFIG_SMP:+-SMP} + Xenomai)])
fi
+# Fixup real arch for powerpc
+if test "${RTNET_TARGET_ARCH}" = "powerpc" ; then
+ AC_MSG_CHECKING([for real PowerPC arch])
+ readlink ${CONFIG_RTNET_LINUX_DIR}/include/asm | grep -q ppc && RTNET_TARGET_ARCH="ppc"
+ AC_MSG_RESULT([$RTNET_TARGET_ARCH])
+fi
+
#
# from now we think we've found some RT-extension, so if we got an error
# it will be fatal, thus exit with AC_MSG_ERROR
|
|
From: Wolfgang G. <wg...@gr...> - 2009-07-02 10:14:14
|
Jan Kiszka wrote: > Giammarco Zacheo wrote: >> Hi, >> while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with >> xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running >> the configure script, which wasn't able to find Xenomai headers in the >> kernel tree. This is due to the fact that the configure script is >> still looking for the arch/ppc obsoleted directory. >> >> The following patch worked for me, but I'm afraid this could break >> compatibility with older kernels and/or RTAI/Xenomai releases. There's >> probably a better way to do this. Any ideas? >> >> Cheers, >> Giammarco >> >> --- a/configure.ac >> +++ b/configure.ac >> @@ -58,10 +58,14 @@ case "$host" in >> RTNET_TARGET_ARCH=arm >> wanted_kernel_arch=CONFIG_ARM >> ;; >> - powerpc-*|ppc-*) >> + ppc-*) >> RTNET_TARGET_ARCH=ppc >> wanted_kernel_arch=CONFIG_PPC >> ;; >> + powerpc-*) >> + RTNET_TARGET_ARCH=powerpc >> + wanted_kernel_arch=CONFIG_PPC >> + ;; >> # mips-*|mipsel-*) >> # RTNET_TARGET_ARCH=mips >> # wanted_kernel_arch=CONFIG_MIPS >> > > Wolfgang, can you check if it breaks anything (specifically 2.4)? This does not work for Kernels using the arch/ppc tree. Retrieving the real ARCH from $host (powerpc-unknown-linux-gnu in my case) gives always "powerpc". Either we provide a configuration parameter "--arch=" or we try to retrieve ARCH from the kernel tree, e.g. by checking "include/asm". Wolfgang. |
|
From: Jan K. <jan...@we...> - 2009-07-01 21:45:46
|
Giammarco Zacheo wrote: > Hi, > while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with > xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running > the configure script, which wasn't able to find Xenomai headers in the > kernel tree. This is due to the fact that the configure script is > still looking for the arch/ppc obsoleted directory. > > The following patch worked for me, but I'm afraid this could break > compatibility with older kernels and/or RTAI/Xenomai releases. There's > probably a better way to do this. Any ideas? > > Cheers, > Giammarco > > --- a/configure.ac > +++ b/configure.ac > @@ -58,10 +58,14 @@ case "$host" in > RTNET_TARGET_ARCH=arm > wanted_kernel_arch=CONFIG_ARM > ;; > - powerpc-*|ppc-*) > + ppc-*) > RTNET_TARGET_ARCH=ppc > wanted_kernel_arch=CONFIG_PPC > ;; > + powerpc-*) > + RTNET_TARGET_ARCH=powerpc > + wanted_kernel_arch=CONFIG_PPC > + ;; > # mips-*|mipsel-*) > # RTNET_TARGET_ARCH=mips > # wanted_kernel_arch=CONFIG_MIPS > Wolfgang, can you check if it breaks anything (specifically 2.4)? Thanks, Jan |
|
From: Giammarco Z. <g.z...@gm...> - 2009-06-26 08:45:09
|
Hi, while compiling rtnet 0.9.11 for a mpc5200-based (powerpc) board with xenomai 2.4.8 on a denx-2.6.29.4 kernel, i had problems while running the configure script, which wasn't able to find Xenomai headers in the kernel tree. This is due to the fact that the configure script is still looking for the arch/ppc obsoleted directory. The following patch worked for me, but I'm afraid this could break compatibility with older kernels and/or RTAI/Xenomai releases. There's probably a better way to do this. Any ideas? Cheers, Giammarco --- a/configure.ac +++ b/configure.ac @@ -58,10 +58,14 @@ case "$host" in RTNET_TARGET_ARCH=arm wanted_kernel_arch=CONFIG_ARM ;; - powerpc-*|ppc-*) + ppc-*) RTNET_TARGET_ARCH=ppc wanted_kernel_arch=CONFIG_PPC ;; + powerpc-*) + RTNET_TARGET_ARCH=powerpc + wanted_kernel_arch=CONFIG_PPC + ;; # mips-*|mipsel-*) # RTNET_TARGET_ARCH=mips # wanted_kernel_arch=CONFIG_MIPS |
|
From: Jeremy V. <ala...@gm...> - 2009-06-15 08:20:27
|
Hi, I have a nVidia Corporation MCP51 Ethernet Controller. This controller is not in the list of the Supported Network Adapters. Somebody knows if there is a driver for nvidia Ethernet controller ? Thank you for your answer ! Jérémy |
|
From: Jan K. <jan...@we...> - 2009-05-24 16:11:53
|
Hillier, Gernot wrote: > Hi there! > > Just noticed that COPYING in current git head is stored in DOS mode: > >> file COPYING > COPYING: ASCII English text, with CRLF line terminators > > Could you please dos2unix it? TIA! > Done. Jan |
|
From: Jan K. <jan...@we...> - 2009-05-24 16:11:36
|
Hillier, Gernot wrote: > Hi there! > > The current git head of rtnet installs PREFIX/etc/rtnet.conf with > non-exec permissions but with a she-bang at start. > > If I'm not completely wrong, this script is not intended to be called > directly (would make no sense as it only sets environment vars), the > she-bang is wrong here. > > It also causes rpmlint to complain about installing a shell script in > /etc when e.g. building a SUSE package. > > So please apply the attached patch. TIA! Thanks, merged. Jan |
