low latency/preempt patch for denx linuxppc_2_4_devel
I hope this is the right place to ask. My apologise if it's wrong. I am using linuxppc_2_4_devel from denx.de (2.4.25 PPC oriented patched kernel) and looking at the code I didn't find any low latency/preempt patches (well this is still a 2.4.x kernel, so no problem) so I went to the internet and found 2.4.25-low-latency.patch.gz (that is fails to apply at one file anyway) but I couldn't find preemptible patch for this version of kernel. I found preempt-kernel-rml-2.4.23-pre5-1.patch and preempt-kernel-rml-2.4.26-pre5-1.patch which are pretty close but not exactly for the same version. Is anybody using linux_2_4_devel from denx.de for 'soft' real-time embedded targets? Thank you Dmytro
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
Hi Jocke, I changed the force_reinit() to // Disable interrupts. i2c-i2c_i2cmr = 0; i2c-i2c_i2cer = 0xff; // Clear enable i2c-i2c_i2mod = ~1; // Reset internal state iip-iic_rstate = 0; iip-iic_tstate = 0; This seems to work and is less code than my old force_reinit(). On the other hand: This kind of CPM timeout will only occur on heavy I2C bus conflicts. They should not appear at all. The code will not be executed if a slave device does not answer! The original driver is from the year 2001 and nobody has mentioned problems of this kind before. Without detailed knowledge of the CPM internals I feel much safer using my old force_reinit(), which does a complete re-init. Cajus
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
Hi Jocke, I changed the force_reinit() to // Disable interrupts. i2c-i2c_i2cmr = 0; i2c-i2c_i2cer = 0xff; // Clear enable i2c-i2c_i2mod = ~1; // Reset internal state iip-iic_rstate = 0; iip-iic_tstate = 0; This seems to work and is less code than my old force_reinit(). On the other hand: This kind of CPM timeout will only occur on heavy I2C bus conflicts. They should not appear at all. The code will not be executed if a slave device does not answer! The original driver is from the year 2001 and nobody has mentioned problems of this kind before. Without detailed knowledge of the CPM internals I feel much safer using my old force_reinit(), which does a complete re-init. Good, however I think we should try to it simple, the code that is, and avoid unneded bloat. I would like to see the shorter version in the kernel. Jocke
how to run iptables-1.2.9 at Kernel 2.4.25
Hi all: I got some problem at compiler iptables 1.2.9 at my 2.4.25 Linux, anybody know how to solve it? PS:I used eldk 3.1.1 and 2.4.25 kernel at my custom MPC852T board. extensions/libipt_ULOG.c: In function `init': extensions/libipt_ULOG.c:58: error: `NFLOG_DEFAULT_NLGROUP' undeclared (first use in this function) extensions/libipt_ULOG.c:58: error: (Each undeclared identifier is reported only once extensions/libipt_ULOG.c:58: error: for each function it appears in.) extensions/libipt_ULOG.c:59: error: `NFLOG_DEFAULT_QTHRESHOLD' undeclared (first use in this function) extensions/libipt_ULOG.c: In function `save': extensions/libipt_ULOG.c:158: error: `NFLOG_DEFAULT_NLGROUP' undeclared (first use in this function) extensions/libipt_ULOG.c:165: error: `NFLOG_DEFAULT_QTHRESHOLD' undeclared (first use in this function) make: *** [extensions/libipt_ULOG.o] Error 1
how to run iptables-1.2.9 at Kernel 2.4.25
In message 1124094153.13556.3.camel at banana you wrote: I got some problem at compiler iptables 1.2.9 at my 2.4.25 Linux, anybody know how to solve it? Please provide a correct subject. It seems your problem is not with running but with building iptables, right? PS:I used eldk 3.1.1 and 2.4.25 kernel at my custom MPC852T board. extensions/libipt_ULOG.c: In function `init': extensions/libipt_ULOG.c:58: error: `NFLOG_DEFAULT_NLGROUP' undeclared ... extensions/libipt_ULOG.c:59: error: `NFLOG_DEFAULT_QTHRESHOLD' ... Seems you misconfigured it. Check your Makefiles. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de To program is to be.
[00/02] MPC5200 Bestcomm platform driver
Hi Sylvain This is first part of platformizied bestcomm/fec drivers. Comments/Commit? -- Regards Andrey Volkov -- next part -- An embedded and charset-unspecified text was scrubbed... Name: 01-bestcomm.diff Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050815/4e7dfee4/attachment.txt
[01/02] Fec MPC5200 eth driver
Second part. Contain only FEC parts. Depended on previous bestcomm patch. -- Regards Andrey Volkov -- next part -- An embedded and charset-unspecified text was scrubbed... Name: 02-fec52xx.diff Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050815/0a78e079/attachment.txt
[00/02] MPC5200 Bestcomm platform driver
Sylvain Munaut wrote: Obviously I haven't yet had the time to review all the code but the glance I had looked good ! I'll review it deeper and test it and come back to you asap. As you could see it was only first step (I hope at not so long way :)): bring Dale's code to the current kernel, and make point from which everyone could start dance. Still, some preliminary comments : - I never really liked to have multiple type of buffer descriptors depending of the number of pointers in them. standard task have either 1 or 2 pointers true but I have custom tasks with 3 so I need a subtmitbuffer3 ... Not very extensible imho. I think there is no problem as defining the descriptor structure with an array of pointer and then just allocate the good size at init. Whoever use them must anyway know the number of pointer to fill. Accepted. But I think it will be better to start from another end: allow everyone to create him/here self task (variable buffers number will consequence of that). - When I started to clean up bescomm a while ago, the only thing I really got done was a rewrite of the SRAM allocator that supports the freeing of block at little overcost. I'll try to find it and send it to you. I agree with you, sram_free is required function, especially if sdma-depended drivers will loaded/unloaded as modules. But I also agree with Dale's comments: What to do with fragmentations? I could lightly imagine situation, when after some load/unload iterations we receive ENOMEM :(. - I like the separation of phys/virt ;) I'd like it too :), but I had a pa/va headache when setting up task/var/inc tables, so everyone, who will write sdma related code must be very careful. - sdma_clear_irq(struct sdma *s) is useless, interrupt acking for the SDMA is already done in mpc52xx_irq.c Ok, will be removed. - I thought of separating bestcomm.h in two headers : one public for the drivers that use the SDMA like the fec. one private for the bestcomm.c and the tasks implementation. I think it makes sense but I never deeply looked it one wouldn't end up almost empty. I review code. It will be done bloodless, I hope :). ... to be continued ;) Will wait impatiently ;). -- Regards Andrey Volkov
[00/02] MPC5200 Bestcomm platform driver
On Mon, Aug 15, 2005 at 03:05:37PM +, Andrey Volkov wrote: Sylvain Munaut wrote: Obviously I haven't yet had the time to review all the code but the glance I had looked good ! I'll review it deeper and test it and come back to you asap. As you could see it was only first step (I hope at not so long way :)): bring Dale's code to the current kernel, and make point from which everyone could start dance. Andrey, thanks for keeping this alive. I agree with Sylvain's other comments. The main thing I would like to see happen to this driver (other than getting it in mainline :-) is an attempt to replace the ugly phy code with calls to the new phy abstraction layer. On the other hand, I'm glad to see progress on any front. -Dale
error when loading shared library
First off it is bad idea to post HTML to this list, you are more likely to get a response if you post plain text. On Sun, 2005-08-14 at 20:36 -0700, Maziah Mat @ Mohamad wrote: Hi, I working with MPC8560ADS development which loaded with the ppc-linux glibc -3.3.2. You should be a bit more specific about your setup. What version of the kernel are you running? Where did you get your root file system? When running the software, faced error which state error while loading shared libraries:/lib/libdb.so.3.. You are missing the db library on your root file system. Berkeley DB can provide this library I believe. You need to download it, and compile for your target. Could you please advise, where is the good link to download the required shared libraries that working for ppc-linux. Your best bet would be to do a search on google. -Matthew
[00/02] MPC5200 Bestcomm platform driver
Dale Farnsworth wrote: On Mon, Aug 15, 2005 at 03:05:37PM +, Andrey Volkov wrote: Sylvain Munaut wrote: Obviously I haven't yet had the time to review all the code but the glance I had looked good ! I'll review it deeper and test it and come back to you asap. As you could see it was only first step (I hope at not so long way :)): bring Dale's code to the current kernel, and make point from which everyone could start dance. Andrey, thanks for keeping this alive. I agree with Sylvain's other comments. The main thing I would like to see happen to this driver (other than getting it in mainline :-) is an attempt to replace the ugly phy code with calls to the new phy abstraction layer. On the other hand, I'm glad to see progress on any front. Ok. But if smb, wish do it now -- welcome. Because I planned do it only after bestcomm will be accepted. -- Regards Andrey Volkov
subscribe linuxppc-embedded
subscribe linuxppc-embedded Regards, Mike Michael J. Randazzo Senior Applications Engineer Data Device Corporation 105 Wilbur Place Bohemia, NY 11716-2482 Voice: 800-DDC-1772 ext. 7321 Fax: 631-567-7358 Email: randazzo at ddc-web.com Web: http://www.ddc-web.com -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050815/5ede6734/attachment.htm
eBay Inc: Please Confirm Your Banking Details [Mon, 15 Aug 2005 22:38:14 -0100]
An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050815/3088a19b/attachment.htm
GCJ
I have used crosstools to build a cross compiler that support C,C++, and java code. I have no problems build my kernel and filesystem and what not. But when I try to build java code using GCJ everything seems to build with no issues. But when I copie the compiled code to the target device and execute the code I get an an error stating libjava.so can not be found. I have copied the libjava.so file from my host machine to the target device but can not get the code to see it. Any help on how to get rid of this error would be greatly appreciated. Thanks Brett -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050815/ee5b1a4f/attachment.htm
Best kernel for Xilinx VirtexII Pro/PPC405 ?
You might want to look at Xilinx Application Note 765 (XAPP765, http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf) for some instructions on how to get started with EDK and Linux. All source is published in linuxppc-2.4. - Peter Keith J Outwater wrote: Hello all - I am designing an embedded system using a Xilinx Virtex II Pro FPGA. Can anyone point me to the best kernel source tree to use ? Best in this case means: 1. A 2.4 series kernel with good support for Xilinx peripheral devices (existing Xilinx ML300 support is fine). 2. Good stability By default I'll use the Montavista linuxppc_2.4 tree unless there is a better choice out there. Thanks! Keith ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] ppc32: fix ppc4xx stb03xxx dma build
Fixes build on 4xx stb03xxx when general purpose dma engine support is enabled. Signed-off-by: Matt Porter mporter at kernel.crashing.org diff --git a/arch/ppc/syslib/ppc4xx_dma.c b/arch/ppc/syslib/ppc4xx_dma.c --- a/arch/ppc/syslib/ppc4xx_dma.c +++ b/arch/ppc/syslib/ppc4xx_dma.c @@ -620,6 +620,7 @@ ppc4xx_clr_dma_status(unsigned int dmanr return DMA_STATUS_GOOD; } +#ifdef CONFIG_PPC4xx_EDMA /* * Enables the burst on the channel (BTEN bit in the control/count register) * Note: @@ -685,6 +686,11 @@ ppc4xx_set_burst_size(unsigned int dmanr return DMA_STATUS_GOOD; } +EXPORT_SYMBOL(ppc4xx_enable_burst); +EXPORT_SYMBOL(ppc4xx_disable_burst); +EXPORT_SYMBOL(ppc4xx_set_burst_size); +#endif /* CONFIG_PPC4xx_EDMA */ + EXPORT_SYMBOL(ppc4xx_init_dma_channel); EXPORT_SYMBOL(ppc4xx_get_channel_config); EXPORT_SYMBOL(ppc4xx_set_channel_priority); @@ -703,6 +709,4 @@ EXPORT_SYMBOL(ppc4xx_enable_dma_interrup EXPORT_SYMBOL(ppc4xx_disable_dma_interrupt); EXPORT_SYMBOL(ppc4xx_get_dma_status); EXPORT_SYMBOL(ppc4xx_clr_dma_status); -EXPORT_SYMBOL(ppc4xx_enable_burst); -EXPORT_SYMBOL(ppc4xx_disable_burst); -EXPORT_SYMBOL(ppc4xx_set_burst_size); + diff --git a/include/asm-ppc/ppc4xx_dma.h b/include/asm-ppc/ppc4xx_dma.h --- a/include/asm-ppc/ppc4xx_dma.h +++ b/include/asm-ppc/ppc4xx_dma.h @@ -285,7 +285,7 @@ typedef uint32_t sgl_handle_t; #define GET_DMA_POLARITY(chan) (DMAReq_ActiveLow(chan) | DMAAck_ActiveLow(chan) | EOT_ActiveLow(chan)) -#elif defined(CONFIG_STBXXX_DMA) /* stb03xxx */ +#elif defined(CONFIG_STB03xxx) /* stb03xxx */ #define DMA_PPC4xx_SIZE4096
Redwood-6 and 2.6
On Thu, Aug 11, 2005 at 09:28:19PM -0600, Otto Solares wrote: Hi! Redwood-6 support in 2.6 is broken. I subscribed to this list just to know if somebody is working on it? 2.4.30 works ok. I went ahead and fixed this compile issue in the following patch: http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019782.html -Matt
