[Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Hi, I've downloaded latest Adeos/Ipipe patch for PPC and unfortunately this latest doesn't (yet) support the ARCH=powerpc architecture from kernel but only the PPC one. I've tried porting the changes to support the PPC_MERGE and be able to still use Xenomai on 2.6.18 with ARCH=powerpc. Attached is a patch that has to be applied after regular adeos-2.6.18-ppc patch to extends supports for PowerPC. Please consider it for review only right now as it might not yet compiles to the end (i'm facing problems with includes inter-race which required me to change the radix-tree.h header file which is something i don't want to). I also have problems booting my latest kernel with this patch on (but booting regular 2.6.18 in merged PowerPC architecture already is a hassle atm) and I'd like you to help me know whether it cames from my patch's content or not. FYI, I've tried to port all Adeos architecture dependant parts but i only focused on PPC32 (PPC64 support might be in but i won't test on it). I'm also trying to boot an MPC8349 chip but i don't think I'll have to address anything with it as it used to work with Xenomai on 2.6.14. Thanks for the review, Ben diff -NEwabur -x '*~' -x linux.orig -x '*.rej' linux.orig/arch/powerpc/Kconfig linux.edit/arch/powerpc/Kconfig --- linux.orig/arch/powerpc/Kconfig 2006-09-20 05:42:06.0 +0200 +++ linux.edit/arch/powerpc/Kconfig 2006-11-23 13:31:29.0 +0100 @@ -590,6 +590,8 @@ menu Kernel options +source kernel/ipipe/Kconfig + config HIGHMEM bool High memory support depends on PPC32 diff -NEwabur -x '*~' -x linux.orig -x '*.rej' linux.orig/arch/powerpc/kernel/entry_32.S linux.edit/arch/powerpc/kernel/entry_32.S --- linux.orig/arch/powerpc/kernel/entry_32.S 2006-09-20 05:42:06.0 +0200 +++ linux.edit/arch/powerpc/kernel/entry_32.S 2006-11-23 13:39:27.0 +0100 @@ -132,8 +132,23 @@ * check for stack overflow */ lwz r9,THREAD_INFO-THREAD(r12) +#ifdef CONFIG_IPIPE + /* Allow for private kernel-based stacks: those must not cause + the stack overflow detection to trigger when some activity has + been preempted over them. We just check if the kernel stack is + not treading on the memory area ranging from + current-thread_info to current-thread, which is coarser + than the vanilla implementation, but likely sensitive enough + to catch overflows soon enough though.*/ + addir12,r9,THREAD + cmplw 0,r1,r9 + cmplw 1,r1,r12 + crand 1,1,4 + bgt-stack_ovf /* if r9 r1 r9+THREAD */ +#else /* CONFIG_IPIPE */ cmplw r1,r9 /* if r1 = current-thread_info */ ble-stack_ovf /* then the kernel stack overflowed */ +#endif /* CONFIG_IPIPE */ 5: #ifdef CONFIG_6xx tophys(r9,r9) /* check local flags */ @@ -198,6 +213,21 @@ lwz r11,_CCR(r1)/* Clear SO bit in CR */ rlwinm r11,r11,0,4,2 stw r11,_CCR(r1) +#ifdef CONFIG_IPIPE + addir3,r1,GPR0 + bl __ipipe_syscall_root + cmpwi r3,0 + lwz r3,GPR3(r1) + lwz r0,GPR0(r1) + lwz r4,GPR4(r1) + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + lwz r9,GPR9(r1) + bgt .ipipe_end_syscall + blt ret_from_syscall +#endif /* CONFIG_IPIPE */ #ifdef SHOW_SYSCALLS bl do_show_syscall #endif /* SHOW_SYSCALLS */ @@ -260,11 +290,34 @@ SYNC RFI +#ifdef CONFIG_IPIPE +.ipipe_end_syscall: + LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */ + SYNC + MTMSRD(r10) + b syscall_exit_cont +#endif /* CONFIG_IPIPE */ + 66:li r3,-ENOSYS b ret_from_syscall .globl ret_from_fork ret_from_fork: +#ifdef CONFIG_IPIPE +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF + stwur1,-4(r1) + stw r3,0(r1) + lis r3,(0x8000)@h + ori r3,r3,(0x8000)@l + bl ipipe_trace_end + lwz r3,0(r1) + addir1,r1,4 +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + LOAD_MSR_KERNEL(r10,MSR_KERNEL) + ori r10,r10,MSR_EE + SYNC + MTMSRD(r10) +#endif /* CONFIG_IPIPE */ REST_NVGPRS(r1) bl schedule_tail li r3,0 @@ -630,6 +683,12 @@ SYNC/* Some chip revs have problems here... */ MTMSRD(r10) /* disable interrupts */ +#ifdef CONFIG_IPIPE +bl __ipipe_check_root +cmpwi r3, 0 +beq- restore +#endif /* CONFIG_IPIPE */ + lwz r3,_MSR(r1) /* Returning to user mode? */ andi. r0,r3,MSR_PR beq resume_kernel @@ -665,11 +724,37 @@ beq+restore andi. r0,r3,MSR_EE/* interrupts off? */ beq restore /*
[Xenomai-core] Re: [Xenomai-help] RT-Socket-CAN update, please read
Hi Wolfgang, some more comments after looking at code and running a compiler: ... * ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c: timestamps are now read and copied in rtcan_recv() and rtcan_tx_loopbcak(). ...thus multiple times in the same IRQ context if there are multiple packets pending. Do we gain enough from the new design that helps to compensate the drawback (considering slow rtdm_clock_read() implementations)? Moreover, we may see a feature one day that the RTDM layer will provide you timestamps for an IRQ event (e.g. when the handler will be running at higher latency as a thread). ... * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig, ksrc/drivers/can/Kconfig: add more help for kernel parameters. Suggestion: N x depends on XYZ = 1 x if XZY != n ... endif ... * ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/sja1000/rtcan_isa.c, ksrc/drivers/can/sja1000/rtcan_mem.c, ksrc/drivers/can/sja1000/rtcan_peak_pci.c, ksrc/drivers/can/sja1000/rtcan_peak_dng.c: Remove rtcan_dev_free() from rtcan_sja1000_unregister() to allow proper cleanup after the device has been unregistered. [2.4.33 build for x86] rtcan_peak_dng.c: In function `rtcan_peak_dng_exit_one': rtcan_peak_dng.c:315: warning: implicit declaration of function `rtcan_free_dev' [Not related to this change] In order to use the parport dongle also with recent PnP ports (e.g. in notebooks), you may want to have a look at the code I added to irqbench for this purpose: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/irqbench.c?v=SVN-trunk#496 The background is that once you unload the parport module, the port will be powered off. ... * src/drivers/Makefile, ksrc/drivers/can/*, scripts/Modules.frag, src/utils/can/README: Replace rtcan with can in macro definitions CONFIG_XENO_DRIVERS_RTCAN_* and module names xeno_rtcan_* to comply to the common naming scheme. Hmm, wouldn't shortening some file names also make sense then? Jan PS: 2.4 help patching and updating work nicely for me - except for choices which is obviously a 2.4 bug. I saw that the kernel then sometimes stuffs all information into the first item. Maybe scriptable for Xenomai... :- signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] RT-Socket-CAN update, please read
Jan Kiszka wrote: Hi Wolfgang, some more comments after looking at code and running a compiler: ... * ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c: timestamps are now read and copied in rtcan_recv() and rtcan_tx_loopbcak(). ...thus multiple times in the same IRQ context if there are multiple packets pending. Do we gain enough from the new design that helps to compensate the drawback (considering slow rtdm_clock_read() I think you agree, that it's unlikely, that an RX interrupt is handled together with an TX done or an error interrupt. And we save reading the timestamp when there is just a TX done interrupt (without TX loopback, of course). It makes the driver dependent code simpler and cleaner. implementations)? Moreover, we may see a feature one day that the RTDM layer will provide you timestamps for an IRQ event (e.g. when the handler will be running at higher latency as a thread). Then we need to modify the interface to the driver anyhow. ... * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig, ksrc/drivers/can/Kconfig: add more help for kernel parameters. Suggestion: N x depends on XYZ = 1 x if XZY != n ... endif OK, no priority though. ... * ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/sja1000/rtcan_isa.c, ksrc/drivers/can/sja1000/rtcan_mem.c, ksrc/drivers/can/sja1000/rtcan_peak_pci.c, ksrc/drivers/can/sja1000/rtcan_peak_dng.c: Remove rtcan_dev_free() from rtcan_sja1000_unregister() to allow proper cleanup after the device has been unregistered. [2.4.33 build for x86] rtcan_peak_dng.c: In function `rtcan_peak_dng_exit_one': rtcan_peak_dng.c:315: warning: implicit declaration of function `rtcan_free_dev' Yes, I realized already this bug. [Not related to this change] In order to use the parport dongle also with recent PnP ports (e.g. in notebooks), you may want to have a look at the code I added to irqbench for this purpose: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/irqbench.c?v=SVN-trunk#496 The background is that once you unload the parport module, the port will be powered off. Are there still laptops with parallel ports? Anyhow, I'm going to check that. ... * src/drivers/Makefile, ksrc/drivers/can/*, scripts/Modules.frag, src/utils/can/README: Replace rtcan with can in macro definitions CONFIG_XENO_DRIVERS_RTCAN_* and module names xeno_rtcan_* to comply to the common naming scheme. Hmm, wouldn't shortening some file names also make sense then? Well, we could remove rtcan_, but I have not time to do it now. Jan PS: 2.4 help patching and updating work nicely for me - except for choices which is obviously a 2.4 bug. I saw that the kernel then sometimes stuffs all information into the first item. Maybe scriptable for Xenomai... :- Yes, I observed the same behavior. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
