Re: [Xenomai-core] PATCH: fix ppc64 calibration
Wolfgang Grandegger kirjoitti: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? 0? No machine is that fast. For the 32-bit ppc it might be harder to provide a reasonable default, because of the broader scale of hardware, but I'd guess that 100MHz targets prefer to use a dedicated RTOS instead of Xenomai. For the 64-bit targets, I didn't find slower than 400 MHz machines and they were iSeries, which, I suppose, also aren't prime target for Xenomai. Regardless of what default value is used, there could be some examples provided by the config help to direct user to the right direction. What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). -- Heikki Lindholm
RE: [Xenomai-core] PATCH: fix ppc64 calibration
Wolfgang Grandegger wrote: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? If it helps, know there's 2.6.10 and 2.6.11 (CONFIG_PREEMPT disabled though) ADEOS patches available for ppc. My latency measurements for Freescale e500 are here: https://mail.gna.org/public/rtai-dev/2005-02/msg00045.html It looks like an ADEOS/I-Pipe patch for current Linux kernels is much expected. The default calibration value may be set according to L1_CACHE_BYTES. Of course I'm fine with a default value set to 0, which is closer to my end of the spectrum :-) -- Stephane
Re: [Xenomai-core] PATCH: fix ppc64 calibration
On 10/12/2005 02:51 PM Heikki Lindholm wrote: Wolfgang Grandegger kirjoitti: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? 0? No machine is that fast. For the 32-bit ppc it might be harder to provide a reasonable default, because of the broader scale of hardware, but I'd guess that 100MHz targets prefer to use a dedicated RTOS instead of Xenomai. For the 64-bit targets, I didn't find slower than There are a lot of 32 bit CPUs 100 MHz running Linux and sometimes they even need a realtime extension. 400 MHz machines and they were iSeries, which, I suppose, also aren't prime target for Xenomai. Regardless of what default value is used, there could be some examples provided by the config help to direct user to the right direction. I fully agree. What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Wolfgang.
Re: [Xenomai-core] PATCH: fix ppc64 calibration
On 10/12/2005 03:16 PM Fillod Stephane wrote: Wolfgang Grandegger wrote: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? If it helps, know there's 2.6.10 and 2.6.11 (CONFIG_PREEMPT disabled though) ADEOS patches available for ppc. I'm using adeos-linux-2.6.10-ppc-r8c4.patch with linuxppc-2.6.10rc3, which works fine, at least on the Ocotea board. My latency measurements for Freescale e500 are here: https://mail.gna.org/public/rtai-dev/2005-02/msg00045.html It looks like an ADEOS/I-Pipe patch for current Linux kernels is much expected. Of course. But Phillips is already heavily loaded with the project, I assume. The default calibration value may be set according to L1_CACHE_BYTES. Of course I'm fine with a default value set to 0, which is closer to my end of the spectrum :-) The nice thing with 0 is that you do not get negative latency values. But for me, any number is OK. Wolfgang.
Re: [Xenomai-core] PATCH: fix ppc64 calibration
Wolfgang Grandegger kirjoitti: What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Now that you mention it, I remember I had to hack u-boot support in there back when I used the Ebonys. Maybe I'll see if I can get some numbers out of them later this week. -- Heikki Lindholm
[Xenomai-core] 2.4 vs 2.6 in embedded space
Wolfgang Grandegger wrote: We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Open question: to your opinion, is 2.6 on low-end embedded hw doomed by design and why, or do you think that part of the reluctance to move to 2.6 is mostly explained because 2.4 is just fine and up to the task, IOW it's kind of a don't fix if it ain't broken perception? -- Philippe.
Re: [Xenomai-core] 2.4 vs 2.6 in embedded space
Dear Philippe, in message [EMAIL PROTECTED] you wrote: Open question: to your opinion, is 2.6 on low-end embedded hw doomed by design Something like that. and why, or do you think that part of the reluctance to move to 2.6 is mostly explained because 2.4 is just fine and up to the task, IOW it's kind of a don't fix if it ain't broken perception? Please see http://www.denx.de/twiki/bin/view/Know/Linux24vs26 and http://www.denx.de/twiki/bin/view/Know/Clock100vs1000Hz The major causes of the serious performance degradation under 2.6 are (1) the increased code size (especially the code that is running in interrupt context and for test switching - check for example just the code size of the scheduler and compar ewith it's size under 2.4), and (2) the increased clock frequency. OK, (2) has been partially fixed in the mean time by making the clock frequency adjustable, so you can go back to the old value of 100 Hz on low end systems. The other factor remains. And yes, this is by design - Linux is more and more designed for high end machines like fat servers running thousands of tasks or other multiprocessor systems with N GHz clocks. A MPC860 at 50 Mhz is just another world. joke I see a business opportunity to revive the 2.2 or even the 2.0 kernel tree development especially for small systems wth real-time requirements. /joke Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] If there was anything that depressed him more than his own cynicism, it was that quite often it still wasn't as cynical as real life. - Terry Pratchett, _Guards! Guards!_
[Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
Hi, today I discovered a bug after having tried to load the Xenomai RTDM skin. I've attached a patch which should correct the problem. Sebastian--- xenomai/skins/rtdm/proc.c 2005-10-12 16:58:48.0 +0200 +++ proc.c 2005-10-12 17:00:59.0 +0200 @@ -285,7 +285,7 @@ int __init rtdm_proc_init(void) /* Initialise /proc entries */ -rtdm_proc_root = create_proc_entry(Xenomai/rtdm, S_IFDIR, NULL); +rtdm_proc_root = create_proc_entry(xenomai/rtdm, S_IFDIR, NULL); if (!rtdm_proc_root) return -EAGAIN;
Re: [Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
Sebastian Smolorz wrote: Hi, today I discovered a bug after having tried to load the Xenomai RTDM skin. I've attached a patch which should correct the problem. Applied, thanks. -- Philippe.
Re: [Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
On Wed, 12 Oct 2005, Philippe Gerum wrote: Sebastian Smolorz wrote: Hi, today I discovered a bug after having tried to load the Xenomai RTDM skin. I've attached a patch which should correct the problem. ... and if we want to have a clean removal of the proc entry at module unload, this next patch is very useful! ;-) Sebastian--- xenomai/skins/rtdm/proc.c 2005-10-12 17:35:42.0 +0200 +++ proc.c 2005-10-12 17:31:09.0 +0200 @@ -322,7 +322,7 @@ void rtdm_proc_cleanup(void) remove_proc_entry(open_fildes, rtdm_proc_root); remove_proc_entry(protocol_devices, rtdm_proc_root); remove_proc_entry(named_devices, rtdm_proc_root); -remove_proc_entry(Xenomai/rtdm, NULL); +remove_proc_entry(xenomai/rtdm, NULL); } #endif /* CONFIG_PROC_FS */
Re: [Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
Sebastian Smolorz wrote: On Wed, 12 Oct 2005, Philippe Gerum wrote: Sebastian Smolorz wrote: Hi, today I discovered a bug after having tried to load the Xenomai RTDM skin. I've attached a patch which should correct the problem. ... and if we want to have a clean removal of the proc entry at module unload, this next patch is very useful! ;-) Oh, well... -- Philippe.
