Re: [uClinux-dev] starter kit or development board
On Saturday 29 August 2009 10:08:09 micro...@virginbroadband.com.au wrote: > Hi, > > I don't know about Video set top box, but just about any other device is > ARM. This includes PMP, gaming consoles,and the massive Cellular market. Darn, I should stay out of this kind of discussion but: What gaming console uses ARM? The only one I know of is the Zeebo. -- Chris Gray/k/ Embedded Java Solutions BE0809.435.306 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ chris.g...@kiffer.be +32 3 216 0369 ___ 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] starter kit or development board
On Friday 28 August 2009 19:11:23 Steven King wrote: > another choice would be a linksys wrt54gl. That's what I was going to suggest - it's the platform we first used when porting the Mika VM to MIPS, and it must be the cheapest development system we bought so far. Take a look at the list of hardware at <http://oldwiki.openwrt.org/TableOfHardware.html> and <https://dev.openwrt.org/wiki/platforms>. (Not all the platforms listed are MIPS but many are). For some platforms you have to be very careful which model you buy, because apparently similar models may not have enough memory to run (even) uClinux. My own experience of networking is different to yours: I see a lot of MIPS and quite a bit of SH4 and Coldfire, ARM is really not dominant in this area. Best regards Chris -- Chris Gray/k/ Embedded Java Solutions BE0809.435.306 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ chris.g...@kiffer.be +32 3 216 0369 ___ 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] Alternatives to C/C++ to write apps?
On Wednesday 05 August 2009 18:13:35 Fred wrote: > Too bad PowerBasic isn't available for uCLinux ;-) Use FICL to develop your own domain-specific language. :-) -- Chris Gray/k/ Embedded Java Solutions BE0809.435.306 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ chris.g...@kiffer.be +32 3 216 0369 ___ 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] Alternatives to C/C++ to write apps?
Hello Fred, > I'm just getting started with the uCLinux + Blackfin-based appliance > IP01 built by Atcom to run Asterisk (an IP-PBX application.) It only > has 64M RAM and 128MB NAND flash, so installing PHP or Python is > basically out of the question*. > > I need to write a few applets triggered by calls into Asterisk, eg. > log calls into an SQLite database, broadcast a message to display the > CallerID on users's PC screen, send e-mails, etc. > > I've never really programmed in C/C++, so before I go ahead, I'd like > to make sure there aren't easier ways to write applications for > uCLinux that are closer to PHP or Python, ie. rich libraries and easy > syntax while still keeping the applets small enough, since there's > only about 30MB left for applications. If Java would be an acceptablelanguage then you could look at Mika: ca. 2 MB on flash and can do quite a lot with 30 MB of RAM. The libraries supplied cover most of what you mention, but not the email part; you should be able to run GNU JavaMail but I've never tried it. http://trac.k-embedded-java.com/mika/trac/ Chris Gray /k/ Embedded Java Solutions _ Scarlet Mobile, free subscription in combination with your Scarlet One or ADSL, visit http://www.scarlet.be/fr/mobile3g ___ 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
On Monday 02 February 2009 22:16:07 Jamie Lokier wrote: > Jamie Lokier wrote: > > On my video player, the control program just runs the media player in > > a child process and talks over a pipe to it, in simple text commands. > > So the control program can be in any language, in theory. > > > This is also quite handy when the codec crashes or gets stuck... > the control program doesn't crash, it just kills the media program > and starts another... > 8-> Worked once with this board which had an i/o processor on a daughterboard - I think it was a Toshiba 8089 clone. For a token-passing ring. The 8089 would get wedged regularly when a certain sequence of interrupts occurred, and the solution was for the controlling CPU to detect the wedgedness and quietly reset the 8089 by writing to a certain physical address. Frames would get lost but they would be retransmitted, and as far as the customer was concerned the problem was solved. You can also apply the same kind of thinking within a single-process multi- threaded model, if you can find the right boundaries. For example in OSGi the unit of granularity might be the service: if a service is critical then some other service should be monitoring it and be ready to take action if it appears to be stuck. The last resort is to exit the JVM, and then at the linux scripting level save the stack trace and relaunch Java. -- 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
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. 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. -- 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
On Sunday 01 February 2009 06:44:38 Jamie Lokier wrote: > EM8623 is an ARM7 I believe, with no MMU. > > For SMP8634 and beyond, they switched to MIPS with MMU :-) > > The codesourcery toolchain uses ARM EABI, but the Sigma Designs > libraries as OABI, so watch out. You have to use the right > compilers... Presumably the the media player will need to talk to the Sigma libraries (using JNI), so the JVM will need to be compiled with their compiler. (actually there is an alternative - wrap the the libraries in a C program which receives commands from the Java part via a socket. But that's getting complex.) I'm pretty sure Mika can still be compiled with gcc 2.95.3, J9 might be more problematic - but if it's physically possible the Apogee guys can do it. :-) > [Jonathan Wong == OP] > > I need to create a media player and include web connectivity (very thin > > web client). Do I use CLDC or CDC? It could come down to size > > constraints, though. > > Your main constraint will be memory, indeed. Max RAM with EM8623 is > 128MB, and some portion, about 40MB, must be kept separate for video. > > That does not leave much for a web browser.[...] OP hasn't told us much about the web connectivity requirements, but if it's just a matter of detching stuff via HTTP then that's built into the Java libraries and he doesn't need a web browser. Most of our customers' devices seem to have between 32 and 64 megs of RAM, so this doesn't sound like an insuperable problem. The JVM will probably allocate its heap in one go, and then it's up to the garbage collector to fight against fragmentation. -- 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
On Tuesday 27 January 2009 06:09, Jonathan Wong wrote: > Anyone happens to know the minimum size of IBM's J9? Anyone tried to run > J9 on uCLinux? I don't know off the top of my head, but I could find out for you. It will depend on the type of Java profile you need to support, for example the very restricted J2ME CLDC or the somewhat larger CDC/FP. Our own "Mika" VM needs a bit less than 2 MB of ROM and is equivalent to CDC/FP. On the whole I would say that what you are proposing is just about doable with 8 MB, although I'm not an expert in codecs so I don't know how much all the necessary libraries will add up to. You'll also need a reasonable amount of RAM, I don't see any mention of that in your hardware specs. More about Mika at our website, www.k-embedded-java.com. Best people for porting J9 to your system: www.apogee.com (and tell them I sent you). -- 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] patch file for the "e2fsprogs" app of uClinux-dist-20080808.tar.bz2
On Monday 20 October 2008 19:23, Jamie Lokier wrote:
> Mike Frysinger wrote:
> > > @@ -237,9 +237,9 @@ int main(int argc, char **argv)
> > > send_output("\n", 0, send_flag);
> > >
> > > if (outbuf) {
> > > -pid = fork();
> > > +pid = vfork();
> > > if (pid < 0) {
> > > -perror("fork");
> > > +perror("vfork");
> > > exit(1);
> > > }
> > > if (pid) {
> >
> > but this one is wrong because the child will call exit() after
> > writing its log
>
> It's ok to call _exit() in a vfork-child, but not exit().
> So that should be changed.
>
> Writing the log in a vfork-child is dodgy, depending on how it's done.
If vfork returns < 0 then the fork failed and no child process was created,
n'est-ce pas? So we are executing in the parent.
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
Skype: k.embedded.chris
___
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] Re: Porting to a new proc
Valentin Manea wrote: > Hi, > >Sorry for my english, its not my first language. >Anyways, I was searching for a cool PhD project and I had this > ideea: running a linux environment(kernel & busybox) on a new > arhitecture. My question would be how much effort would be needed to > see this through? > >Some notes: the new arch is Starcore so I can't really use gcc or > related tools, I have to use the inhouse compiler/linker. Also I'm not > starting from scratch since I have access to a in house OS. The Linux kernel (and hence also µcLinux) does not aim to be compilable with any compiler other than GCC, adn I've never heard of anyone successfully trying to do this. If your Starcore has an MMU then you may have more luck with NetBSD; or you could try porting eCos, which is a much smaller OS but does offer a certain level of Posix compatibility. Good luck -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Skype: k.embedded.chris ___ 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] M5329evb usb & compact flash driver
Are there any compact flash drivers for the m5329evb board? I didn't see them in the kernel as an option but I want to check since all of the other hardware has support. Also, where did the usb drivers go for the M5329EVB? I'm using the latest patch for uclinux, but was working from the 2006117 ltib and it fully supports the usb devices. I don't understand why usb support was nearly striped from the uclinux kernel. Could someone layout steps on what has to been done to add them back in, such as the source, edit makefile, etc. . Thank you for any help. - Chris ___ 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] m5329evb mtd devices missed / Need older busybox
I'm attempting to follow the post http://mailman.uclinux.org/pipermail/uclinux-dev/2007-August/043779.html to get my flash working. I have built the latest uclinux, uClinux-dist-test-20070823, I believe that this patch was incorporated in this build for nand.c, but not for the vendor makefile. I added the missed lines so the mtd devices would show up in /dev, but I'm not sure about the minor number for mtd1, shouldn't it be 1? > *+ \*> *+ mtdblock0,c,31,0 mtdblock1,c,31,1 \*> *+ mtd0,b,90,0 > mtd1,b,90,2* Now I'm getting very weird functionality from busybox ver 1.5.1. From what I can tell the mtd devices were installed correctly, but they don't respond. *eraseall /dev/mtd1**eraseall: /dev/mtd1: No such device or address * *#mknod mtd2 c 90 1**# eraseall mtd2**eraseall: mtd2: Permission denied* #cp jffs2.img /dev/mtdblock1'/dev/mtdblock1' exists # mknod mtdblock2 b 31 1# cp jffs2.img mtdblock2end_request: I/O error, dev mtdblock1, sector 8cp: write error: Input/output errorend_request: I/O error, dev mtdblock1, sector 0Buffer I/O error on device mtdblock1, logical block 0lost page write due to I/O error on mtdblock1 Mounting mtdblock1 always failed!I also noticed in the post that I was missing a line in my output for my nand chip. NAND device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V 8-bit) Scanning device for bad blocks Creating 1 MTD partitions on "NAND 16MiB 3,3V 8-bit": 0x-0x0100 : "M5329 flash partition 1" Should also output, mtd: Giving out device 1 to M5329 flash partition 1 Matt or anybody, could you tell me how to include an older busybox in my source tree and what I left out in my config to cause me not to have this line and errors for cpy. ___ 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] MCF5329 JFFS2 Flash patch and bootup
Hi, I'm currently using the 20061117 ltib from Freescale that came with my MCF5329EVB. I have made progress developing drivers, but need to get my flash working. I know it's buggy and have been goggling this problem. I'm new to the uclinux development so I don't know where the patch is located that they refer to at the bottom. The http://www.uclinux.org/ports/coldfire/patches link doesn't work so I'm kind of lost where to get it. I would be very grateful for any help, especially from anybody who has gotten this board to boot up to a RW file system and would like to share some pointers. Also where in the kernel source is it that it mounts your file system? My second problem might be because I'm on such an old dist but here it is, the problem really is that it stops the bootup because of mount errors. Sorry for such a long post. Thanks in advance. -Chris Mounting filesystems mount: Mounting /proc on /proc failed: Bad address mount: Mounting rwfs on /mnt/rwfs failed: Bad address mount: /proc/filesystems: No such file or directory cp: cannot create directory `/mnt/rwfs/tmp': Read-only file system mount: /proc/filesystems: No such file or directory cp: cannot create directory `/mnt/rwfs/etc': Read-only file system mount: /proc/filesystems: No such file or directory cp: cannot create directory `/mnt/rwfs/var': Read-only file system mount: /proc/filesystems: No such file or directory ln: /etc/mtab: Read-only file system Starting syslogd and klogd syslogd: Could not connect to socket /dev/log: Read-only file system Setting up networking on loopback device: rm: unable to remove `/etc/resolv.conf': Read-only file system Setting up networking on eth0: eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. Adding static route for default gateway to 192.168.1.1: tmp/hosts: cannot create mv: overwrite `/etc/hosts'? no Setting nameserver to 66.82.4.8 in /etc/resolv.conf: /etc/resolv.conf: cannot create Starting the boa webserver: [30/Nov/1999:00:07:13 +] log.c:53 (open_logs) - unable to open error log: Read-only file system BusyBox v1.00 (2006.11.17-19:56+) Built-in shell (msh) Enter 'help' for a list of built-in commands. # ___Post___ Thanks! I have already used your precious patch! Regards Claudia - Original Message - From: Tarani, Andrea To: uClinux development list Sent: Thursday, June 21, 2007 11:22 AM Subject: R: [uClinux-dev] Mouting JFFS2 file system Warning!! The nand flash driver is bugged (wrong use of nand ce signal). Hi have recently posted a patch that solve the problem (8 June) -- Da: uclinux-dev-bounces at uclinux.org [mailto:uclinux-dev-bounces at uclinux.org] Per conto di Claudia De Bartolomeis Inviato: giovedì 21 giugno 2007 11.02 A: uClinux development list Oggetto: [uClinux-dev] Mouting JFFS2 file system Hi Vanitha, what "kernel boot command" did you use to mount the file system from the Nand flash? Something like "root=/dev/mtdblockx"? I'm also trying to use my Nand Flash as root file system, (I'm working now on the MCF5329 platform) and I gave up creating a jffs2 image and mounting it because i had "Magic bitmask ... not found" messages and I can't solve it ( I used this commands flash_eraseall /dev/mtd1 nandwrite -jf /dev/mtd1 rootfs.jffs2 mount -t jffs2 /dev/mtdblock1 /mnt ) >From freescale I received this hint: Try to create JFFS2 directly on NAND device without making image. Than just copy some file there. I followed this passes: flash_eraseall /dev/mtd1 mount -t jffs2 /dev/mtdblock1 /mnt cd /mnt copying into it my file system, in this way it works every time you mount it, but I can't find the proper "boot kernel command" to mount it automatically at boot time. If you can please help me. Regards Claudia ___ 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] write peripheral user
On Thursday 26 July 2007 11:08, Sebastien Baldacchino wrote: > [...] > I have seen on internet that uclinux has no MMU. So I think to I can > write and read directly to the physical address of my peripheral. Operating systems don't have an MMU, CPUs have an MMU. What CPU are you using? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Skype: k.embedded.chris ___ 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] uClinux and Java
Hi Benoit, > I would like know if one or more implementation of "Java" (open > sources) exists for uClinux with linux 2.4. > I work with a M5475EVB Coldfire and uClinux20070130. We have ported Mika (http://www.k-embedded-java.com/mika/) to PowerPC-Linux and to uClinux on ARM7 and MIPS, so this combination should also be possible. Mika is an uncertified implementation of JavaME CDC 1.1. Mika is BSD licensed and a "headless" implementation requires about 2 MB of ROM and 6 MB free RAM (depending obviously on what you want to do with it). Contact me off-list for more info. Other possibilities would be Kaffe and JamVM, both GPL. Both of these provide JavaSE support using the Classpath libraries, with the consequence that the libraries are rather large and you will probably have to spend some effort "shoehorning" the VM into your system. Best regards Chris Gray -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 ___ 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] Looking for white papers
On Sunday 25 February 2007 11:22, David Harel wrote: > Hi, > > > I would like to learn more about uCLinux as well as other RTOSs uCLinux is not an RTOS. End of story. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 ___ 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
