[uClinux-dev] LPC 2294
Quick question: does uclinux have a port for LPC2294. I am asking because I did not see it mentioned here http://www.uclinux.org/ports/ Thanks. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Protecting kernel and other apps.
Hi all, General question. Lets say that I have a uClinux in a flash with some application. How this can stop other people from stealing image with an application? On micro we have LOCK bits so reading image (hex, bit etc.) is not possible. Is anything like that possible with external FLASH? Thanks, P.Voslak ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Protecting kernel and other apps.
No, if you can't read the image then you can't run the image. If your processor has flash memory that it can boot from internally and that can be locked, then you could create a bootloader that decodes and encrypted external flash chip into RAM. - Original Message - From: vo sla vos...@gmail.com General question. Lets say that I have a uClinux in a flash with some application. How this can stop other people from stealing image with an application? On micro we have LOCK bits so reading image (hex, bit etc.) is not possible. Is anything like that possible with external FLASH? ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
And if you want to enable 3rd parties to develop applications for your device you would IMO be pretty crazy to do it in native code. It's considerations like that which are driving the adoption of Java in consumer electronics. We got pretty insane learning every bug and limitation and quirk of every device and every library or toolchain we had to work with. Frustrating enough to even contemplate vertical integration. Yet, we're aware of the dangers of being locked in to specific vendors. Altogether crazy. Regards Jonathan Chris Gray wrote: On Tuesday 03 February 2009 12:32:48 Jamie Lokier wrote: Chris Gray wrote: On Monday 02 February 2009 22:01:12 Jamie Lokier wrote: I didn't use Java because I thought it wouldn't fit, to be honest. There's about 10MB free on my 64MB device (32 allocated to video coprocessors, away from Linux; the rest is used by Linux, utils etc.) I found that's actually not enough when streaming from hard disk - because Linux's page allocator can't handle it, playback struggles. So I thought adding Java would make it worse. It probably would have: you can certainly run Java applications in less than 10 MB (or even 5 MB), but you need to keep them pretty simple (and when the memory consumption starts to grow it can be hard to put your finger on just why). OTOH I know people who are doing pretty complex stuff (including genetic algorithms, would you believe) in something like 18 MB. That's good to know. My customer wants to use Java, I can use this to say no, bad idea! :-) Hm, and I'm supposed to be an advocate of embedded Java. :-/ But honestly if memory is as tight as this it would probably better not to go that route. Even if it fits in 5MB, the trouble is the system needs 10MB _free_ to stream from hard disk reliably. Linux 2.4 with the page_alloc2 fragmentation-avoidance allocator cannot release page-cache due to streaming I/O smoothly, and with page_alloc (the normal Linux allocator), it's smooth but quickly fragments so much that launching new apps, such as shell scripts or telnet shells stops working. There are some aspects of Java which make it hard to keep the memory consumption real down low - the reflection data for example (all those strings!) and the frustrating lack of modularity in the class libraries. Yes you can compile stuff AOT and strip out unused methods and reflection data - but be careful because the Java libraries themselves use reflection quite a lot. The good news is that once you have a certain critical mass of commonly- used core classes from java.lang, java.io, java.net and java.util loaded the memory consumed by class libraries starts to stabilise a bit - provided of course that you don't start dragging in every cute open-source library you see on the web. And of course, no MMU means no swapping in just those parts of the libraries which are used, so you really need enough RAM. Quite. Of course Java does bring some advantages too - managed code means that you shouldn't need to worry about applications writing to other applications' (or system) memory. You need to trust the JVM, but that has probably been scrutinised by more eyeballs than your own applications. And if you want to enable 3rd parties to develop applications for your device you would IMO be pretty crazy to do it in native code. It's considerations like that which are driving the adoption of Java in consumer electronics. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
On Tuesday 03 February 2009 12:32:48 Jamie Lokier wrote: Chris Gray wrote: On Monday 02 February 2009 22:01:12 Jamie Lokier wrote: I didn't use Java because I thought it wouldn't fit, to be honest. There's about 10MB free on my 64MB device (32 allocated to video coprocessors, away from Linux; the rest is used by Linux, utils etc.) I found that's actually not enough when streaming from hard disk - because Linux's page allocator can't handle it, playback struggles. So I thought adding Java would make it worse. It probably would have: you can certainly run Java applications in less than 10 MB (or even 5 MB), but you need to keep them pretty simple (and when the memory consumption starts to grow it can be hard to put your finger on just why). OTOH I know people who are doing pretty complex stuff (including genetic algorithms, would you believe) in something like 18 MB. That's good to know. My customer wants to use Java, I can use this to say no, bad idea! :-) Hm, and I'm supposed to be an advocate of embedded Java. :-/ But honestly if memory is as tight as this it would probably better not to go that route. Even if it fits in 5MB, the trouble is the system needs 10MB _free_ to stream from hard disk reliably. Linux 2.4 with the page_alloc2 fragmentation-avoidance allocator cannot release page-cache due to streaming I/O smoothly, and with page_alloc (the normal Linux allocator), it's smooth but quickly fragments so much that launching new apps, such as shell scripts or telnet shells stops working. There are some aspects of Java which make it hard to keep the memory consumption real down low - the reflection data for example (all those strings!) and the frustrating lack of modularity in the class libraries. Yes you can compile stuff AOT and strip out unused methods and reflection data - but be careful because the Java libraries themselves use reflection quite a lot. The good news is that once you have a certain critical mass of commonly- used core classes from java.lang, java.io, java.net and java.util loaded the memory consumed by class libraries starts to stabilise a bit - provided of course that you don't start dragging in every cute open-source library you see on the web. And of course, no MMU means no swapping in just those parts of the libraries which are used, so you really need enough RAM. Quite. Of course Java does bring some advantages too - managed code means that you shouldn't need to worry about applications writing to other applications' (or system) memory. You need to trust the JVM, but that has probably been scrutinised by more eyeballs than your own applications. And if you want to enable 3rd parties to develop applications for your device you would IMO be pretty crazy to do it in native code. It's considerations like that which are driving the adoption of Java in consumer electronics. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ chris.g...@kiffer.be +32 3 216 0369 Come and see us at Embedded World 2009 in Nürnberg, 3-5.3.2009: Hall 12, Stand 560 (DSP Valley). http://www.embedded-world.de/ ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Chris Gray wrote: On Monday 02 February 2009 22:01:12 Jamie Lokier wrote: I didn't use Java because I thought it wouldn't fit, to be honest. There's about 10MB free on my 64MB device (32 allocated to video coprocessors, away from Linux; the rest is used by Linux, utils etc.) I found that's actually not enough when streaming from hard disk - because Linux's page allocator can't handle it, playback struggles. So I thought adding Java would make it worse. It probably would have: you can certainly run Java applications in less than 10 MB (or even 5 MB), but you need to keep them pretty simple (and when the memory consumption starts to grow it can be hard to put your finger on just why). OTOH I know people who are doing pretty complex stuff (including genetic algorithms, would you believe) in something like 18 MB. That's good to know. My customer wants to use Java, I can use this to say no, bad idea! :-) Even if it fits in 5MB, the trouble is the system needs 10MB _free_ to stream from hard disk reliably. Linux 2.4 with the page_alloc2 fragmentation-avoidance allocator cannot release page-cache due to streaming I/O smoothly, and with page_alloc (the normal Linux allocator), it's smooth but quickly fragments so much that launching new apps, such as shell scripts or telnet shells stops working. There are some aspects of Java which make it hard to keep the memory consumption real down low - the reflection data for example (all those strings!) and the frustrating lack of modularity in the class libraries. Yes you can compile stuff AOT and strip out unused methods and reflection data - but be careful because the Java libraries themselves use reflection quite a lot. The good news is that once you have a certain critical mass of commonly- used core classes from java.lang, java.io, java.net and java.util loaded the memory consumed by class libraries starts to stabilise a bit - provided of course that you don't start dragging in every cute open-source library you see on the web. And of course, no MMU means no swapping in just those parts of the libraries which are used, so you really need enough RAM. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] LPC 2294
Jivin vo sla lays it down ... Quick question: does uclinux have a port for LPC2294. I am asking because I did not see it mentioned here http://www.uclinux.org/ports/ There's something in there: http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-dist/vendors/Philips/LPC2294/ Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] MCF5271EVB: console=ttyS2,115200 does not work
Hi Guys, I am using a Motorola MCF5271EVB with U-boot 2009.01 and Linux 2.6.27 from kernel.org I customized the m5271evb_defconfig I got from the DENX linux-2.6 distro. I compiled in kernel bootargs with console=ttyS0,115200 and was able to see the console output. Then I changed that line to console=ttyS2,115200, and am not able to get the console output on any of the 3 UARTs. The deprecated mcfserial.c driver is limited to use ttyS0 or ttyS1. I am able to crudely hack this to work with ttyS2. However, I am a bit lost with the newer mcf.c serial driver. What am I missing that prevents me to use ttyS2 as my console? Thank you for your time. - Richard Retanubun ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] How to commonicate to ttySx in a kernel driver
not sure about that, but I think you'll have to use a line discipline in your driver. If you have any chance to handle the serial port in user space that would be much easier. -Erwin Am Dienstag, den 03.02.2009, 07:08 +0100 schrieb Siegfried Müller: Hi, i want to send an receive characters trough /dev/ttyS2 in a kernel driver. How can i do this? Thanks for any hint. Cheers Siegfried ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MCF5271EVB: console=ttyS2,115200 does not work
Hi Richard, Richard Retanubun wrote: I am using a Motorola MCF5271EVB with U-boot 2009.01 and Linux 2.6.27 from kernel.org I customized the m5271evb_defconfig I got from the DENX linux-2.6 distro. I compiled in kernel bootargs with console=ttyS0,115200 and was able to see the console output. Then I changed that line to console=ttyS2,115200, and am not able to get the console output on any of the 3 UARTs. The deprecated mcfserial.c driver is limited to use ttyS0 or ttyS1. I am able to crudely hack this to work with ttyS2. However, I am a bit lost with the newer mcf.c serial driver. What am I missing that prevents me to use ttyS2 as my console? Are the ttyS2 pins at the CPU multi-function (are they shared with something else)? It maybe that there is no appropriate setup to turn them into serial lines in linux-2.6.x/arch/m68knommu/platform/527x/confnig.c. Look for the m527x_uart_init_line() function. This sort of setup used to be in the old mcfserial.c driver itself. But the new style mcf.c is a true platform device, so the CPU/board specific setup is now done in the platform code. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Protecting kernel and other apps.
If someone really wants to get a application from your system, then even encrypting it somehow will not stop it, because all it takes is someone who is determined enough ... -- From: vo sla vos...@gmail.com Sent: Tuesday, February 03, 2009 10:43 PM To: uclinux-dev@uclinux.org Subject: [uClinux-dev] Protecting kernel and other apps. Hi all, General question. Lets say that I have a uClinux in a flash with some application. How this can stop other people from stealing image with an application? On micro we have LOCK bits so reading image (hex, bit etc.) is not possible. Is anything like that possible with external FLASH? Thanks, P.Voslak ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
