Re: SH4 port

Jan Kiszka wrote:
> Kiichi Kameda wrote:
>> ...
>> After tough investigation, I think I found some clues such as:
>> While in.ftpd runs hard, a "write" system call was issued and Linux
>> kernel was processing its request.
>>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
>>
>> I think the problem originates from a Xenomai context switch(which
>> overwrites "current"), while Linux is processing  system call.
> 
> If I interpret linux/include/asm-sh/current.h correctly, current is
> derived from the stack on your platform (like on most archs) and cannot

That's nonsense as I realised later by following the code down to
include/asm-sh/thread_info.h: current_thread_info seems to get
referenced by some register.

Still the question remains for me why this should be a general Xenomai
problem. Xenomai may overwrite the content on switch_to (but I don't
know your patch, how you realised context switches between RT tasks on
SH4), but then it should definitely also restore it again on returning
to Linux.

Jan

_______________________________________________
Xenomai-help mailing list

Re: Xenomai on 2.6.17 ppc

2006/9/30, Wolfgang Grandegger <wg <at> grandegger.com>:
> I realized, that the differences to Linux 2.6.18 are quite small and non
> critical. Attached is a ADEOS-IPIPE patch for Linux 2.6.17, which should
> work on your MPC5200 as well (the idle loop problem for 6xx is solved).
> Would be nice if you could test the patch and report the results. It's
> difficult these days to get a 2.6.x kernel built and booted on an
> MPC5200 .
>
> Note: this patch requires another small fix for Xenomai (see
> attachment). Philippe, could you please apply it? TIA.

Thank you for the 2.6.17 patch, but unfortunately it did not work.
I had problems with both patches. The xenomai patch expected 2 lines
in the source that are not in the original xenomai sources. But i
patched it manual.
The Kernel Patch does not work with the prepare-kernel script. It stops with:

grep: /home/amg/linux-2.6.17/include/asm-powerpc/ipipe.h: No such file
or directory
prepare-kernel.sh: /home/amg/linux-2.6.17 has no Adeos support for powerpc

ipipe.h is in asm-ppc so i think it has something to do with the ppc
-> powerpc merge.
So i patched is manually. But in menuconfig the xenomai entries are
missing so i could not activate it to test it.

Syed Amer Gilani

Re: Xenomai on 2.6.17 ppc

Syed Amer Gilani wrote:
> 2006/9/30, Wolfgang Grandegger <wg <at> grandegger.com>:
>> I realized, that the differences to Linux 2.6.18 are quite small and non
>> critical. Attached is a ADEOS-IPIPE patch for Linux 2.6.17, which should
>> work on your MPC5200 as well (the idle loop problem for 6xx is solved).
>> Would be nice if you could test the patch and report the results. It's
>> difficult these days to get a 2.6.x kernel built and booted on an
>> MPC5200 .
>>
>> Note: this patch requires another small fix for Xenomai (see
>> attachment). Philippe, could you please apply it? TIA.
> 
> Thank you for the 2.6.17 patch, but unfortunately it did not work.
> I had problems with both patches. The xenomai patch expected 2 lines
> in the source that are not in the original xenomai sources. But i
> patched it manual.

What version of Xenomai did you use? You need the head of SVN trunk (or 
take the snapshot):

  $ svn co http://svn.gna.org/svn/xenomai/trunk xenomai
  $ wget http://svn.gna.org/daily/xenomai-snapshot.tar.gz

> The Kernel Patch does not work with the prepare-kernel script. It stops 
> with:
> 
> grep: /home/amg/linux-2.6.17/include/asm-powerpc/ipipe.h: No such file
> or directory
> prepare-kernel.sh: /home/amg/linux-2.6.17 has no Adeos support for powerpc

Re: Xenomai on 2.6.17 ppc

2006/10/2, Wolfgang Grandegger <wg <at> grandegger.com>:
> Likely you do just not use a recent version of Xenomai 2.3.x. It is
> working with my setup.

That's right. I used the latest stable version. I will try it later
with the trunk.

Re: SH4 port

Thank you for your effort.

> Jan Kiszka wrote:
> > Kiichi Kameda wrote:
> >> ...
> >> After tough investigation, I think I found some clues such as:
> >> While in.ftpd runs hard, a "write" system call was issued and Linux
> >> kernel was processing its request.
> >>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
> >>
> >> I think the problem originates from a Xenomai context switch(which
> >> overwrites "current"), while Linux is processing  system call.
> >
> > If I interpret linux/include/asm-sh/current.h correctly, current is
> > derived from the stack on your platform (like on most archs) and cannot
>
> That's nonsense as I realised later by following the code down to
> include/asm-sh/thread_info.h: current_thread_info seems to get
> referenced by some register.

In original SH-Linux ,"current" is based on r7_bank register in SH CPU
 which is set only at context switch.  "current" macro which is
referenced everywhere(including page fault handling and stack pointer
setting
at interrupt from userspace), depends on this special register.
r7_bank register has nothing to do with stack.

So, I created modified version of  SH-Linux code , where "current" macro
uses

Re: SH4 port

Kiichi Kameda wrote:
> Thank you for your effort.
> 
>> Jan Kiszka wrote:
>>> Kiichi Kameda wrote:
>>>> ...
>>>> After tough investigation, I think I found some clues such as:
>>>> While in.ftpd runs hard, a "write" system call was issued and Linux
>>>> kernel was processing its request.
>>>>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
>>>>
>>>> I think the problem originates from a Xenomai context switch(which
>>>> overwrites "current"), while Linux is processing  system call.
>>> If I interpret linux/include/asm-sh/current.h correctly, current is
>>> derived from the stack on your platform (like on most archs) and cannot
>> That's nonsense as I realised later by following the code down to
>> include/asm-sh/thread_info.h: current_thread_info seems to get
>> referenced by some register.
> 
> In original SH-Linux ,"current" is based on r7_bank register in SH CPU
>  which is set only at context switch.  "current" macro which is
> referenced everywhere(including page fault handling and stack pointer
> setting
> at interrupt from userspace), depends on this special register.
> r7_bank register has nothing to do with stack.

Yep, that's what I understood as well meanwhile.

> 
> So, I created modified version of  SH-Linux code , where "current" macro

Re: SH4 port

> >
> > So, I created modified version of  SH-Linux code , where "current" macro
> > uses
> > the stack pointer(SP & ~(THREAD_SIZE) -1).
> > After that, although Linux seems to work well, the Xenomai thread still
> > causes system panic, if I once run the Xenomai program that uses POSIX
> skin.
>
> And that's something I do not understand. What was your idea behind this
> step?
>

Just a try , because I realized overwriting "current" may not be right way.

>
> [ksrc/arch/sh/switch.c]
>
> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
> {
> ...
>         /*
>          * Restore the kernel mode register
>          *      k7 (r7_bank1)
>          */
>  if(next->user_task) {
>
>             asm volatile("ldc       %0, r5_bank"
>                      : /* no output */
>                      : "r" (next->user_task->thread_info));
>  }

Re: SH4 port

Kiichi Kameda wrote:
>> [ksrc/arch/sh/switch.c]
>>
>> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
>> {
>> ...
>>         /*
>>          * Restore the kernel mode register
>>          *      k7 (r7_bank1)
>>          */
>>  if(next->user_task) {
>>
>>             asm volatile("ldc       %0, r5_bank"
>>                      : /* no output */
>>                      : "r" (next->user_task->thread_info));
>>  }
>>
>> Is there a particular reason why comment and reality diverge regarding
>> the thread_info register? Could this cause your troubles?
>>
> 
> I'm sorry, the comment is wrong.
> The code that uses r7_bank  results in overwriting "current".

What code is it?

> To avoid this,  I changed  from r7_bank to r5_bank for Xenomai context
> switch .

Wouldn't it be better to avoid that overwriting in the first place

Issue installing Xenomai 2.2.3 on Ubuntu 6.06 using kernel 2.6.17

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: Issue installing Xenomai 2.2.3 on Ubuntu 6.06 using kernel 2.6.17

Montibus, Vincent (GE Healthcare) wrote:
> Hi all,
>  
> I've been spending last week in trying to setup xenomai 2.2.3 on a
> 2.6.17 Kernel (from kernel.org).
> I have the kernel 2.6.17 sources in /tmp/linux.
> I have Xenomai 2.2.3 sources in /tmp/xenomai.
>  
> Here are the steps I followed :
> 
> *	cd /tmp/xenomai 
> *	scripts/prepare-kernel.sh --linux=../linux
> --adeos=ksrc/arch/i386/patches/adeos-ipipe-2.6.17-i386-1.4-00.patch
> --arch=i386 
> *	cd ../linux 
> *	cp /boot/.config .config (in order to use a working .config
> file) 
> *	make xconfig 
> *	make-kpkg clean 
> *	make-kpkg -initrd --revision=386 kernel_image kernel_headers
> modules_image 
> *	dpkg -i kernel_headers... .deb 
> *	dpkg -i kernel_image... .deb 
> *	modify grub menu.lst in order to pass "lapic=1" as boot
> parameter for the kernel 
> *	Reboot on the xenomai patched kernel
> 
> The boot hangs up every time at the same level :
>  
> I-pipe: Domaine Xenomai registered
> Xenomai: hal/x86 started
> Xenomai: real-time nucleus v2.2.3 (Memories) loaded
> Xenomai: starting native API services
> Xenomai: starting RTDM services
> ...
> Limiting direct PCI/PCI transfert.
>  
> I have no clue on where to start my investigation and on what am I doing
> wrong.
>  
> I joint with this mail the .config file used.

Maybe it's our old friend MSI again. Please try to disable
CONFIG_PCI_MSI to see if the situation improves and report back. If not,
try to disable Xenomai and boot your box only with I-pipe enabled.

Jan

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help