WARNING: LONG POST! ------------------- I work a research and development arm of a Japanese phone company. We are often asked to build prototypes of new devices, and our first tool out of the box is nearly always Linux.
Up until this point, most of our prototypes have been built either from a custom busybox (buildroot) build, or from a scaled down version of Debian. For the most part, the buildroot versions are ideal where space is concerned, and interface is unimportant. The Debian environment is ideal when we have a user interface. Recently we have moved all our development servers and desktops to Ubuntu Linux (Feisty mostly). Therefore, we would like to re-apply all our knowledge in building these trim systems to Ubuntu. Also, rather than going it alone as we have been, we would like to extend our knowledge, into the Ubuntu development universe. We would also like to build one environment that may or may not include the UI. After meeting with Joey Stanford, he suggested that I speak with the Ubuntu Mobile project. However, they are not trying to be a general purpose project, but instead, simply a port of Mameo into the Ubuntu platform. Basically, they are trying to build a sub-laptop running Ubuntu with the Hildon extentions (i.e. Mameo), which has no benefit to the general embedded marketplace. I would like to join (or lead if needed) a project that is working on bringing the Ubuntu platform to embedded devices. This requires focus on several areas not being addressed by the "Ubuntu Mobile" project. Here is my list of the 10 biggest areas not being addressed: 1) Devices without I/O. Many embedded devices do not have graphical user interfaces such as Network Attached Storage; Routers; Security Scanners; etc. Instead these devices are usually configured via a web interface. In short, they are a special purpose server (NAS=Samba; Router=Zebra; Security Scanner=Nagios or GroundWork Open Source; etc). 2) When a graphical user interface is required, it should incorporate more than just the Mameo interface. Many of our devices are kiosks that run a Opera interface direct against the frame buffer, or against K-Drive. Other interfaces are defined by the software requirements. So a true embedded platform needs to provide a choice of interfaces: Raw X (k-drive), DirectX, Qtopia and GTK/e on the low end; to matchbox, hildon, and fltk on the heavier side. 3) Embedded devices are generally memory constrained devices. Appliances and kiosks generally need to run on 16M to 64M of ram depending on what services are being supplied. 4) Embedded devices are generally storage constrained devices. Often storage is measured in megabytes, not gigabytes. Therefore a series of tools need to be deployed in order to fit the operating system into this constrained space. The tools to handle this include cloop file systems, cramfs, and unionfs. 5) Embedded devices rarely have hard drives, but instead rely upon flash memory for storage. This has some real ramifications on reliability. Tools such as jffs2 and logfs file systems are critical to supporting commercial grade products with a Linux based OS. Otherwise, data storage and retrieval will quickly wear out the storage within the embedded device. 6) In order to cut down on memory requirements, one of the popular tricks it to enable XIP (eXecute In Place) in the kernel. The prevents the entire kernel, plus all the drivers from having to reside in ram, saving it for other programs. Given the scarcity of ram on many embedded devices, this can create a benefit when used in the correct way. 7) Embedded devices are generally expected to have much lower startup times than desktops and servers. A Linux or Windows desktop that takes two minutes to startup may be a little slow, but not exactly uncommon. With embedded devices, anything over 30 seconds is completely unacceptable, and many people would say that 20 seconds is unacceptable. 8) On most Intel based desktops and laptops, power management is a huge issue. On most embedded devices, it is even more important, and less standardized. A good general purpose distro aimed at embedded devices needs to address this. It can also assist in #7. But, standard ACPI is often not available on smaller boards, especially those based on PC104 and/or ARM processors. 9) And in order to adjust the normal (K)Ubuntu environment to handle the points made above, a more modular kernel needs to be used. While a raid driver may make sense in a NAS, it makes no sense in a flash based handheld device. The regular environment makes it always available, because the increase in resources is trivial compared to the entire system. But as that system shrinks, that space will become more critical. 10) I am not going to put my 10th item here, but leave it to your imagination. As a company producing devices for a telecommunications company based in Japan, you can imagine there are several issues I have yet to address that effect the devices we produce. How about Japanese language input on a small screen. Every company selling small devices in Japan has to deal with that one. Or how about PHS networking, or the pending change to 3G. Every reader of this list can probably come up with several issues made more difficult, or are just flat different, on an embedded or mobile platform, that I did not mention. Place your own 10th item here. As I hope I have clearly pointed out, and embedded environment has some very different trade-offs from a desktop or server environment. The Ubuntu Mobile group is completely sidestepping these issues in order to build Mameo. They are planing on deploying it on a "Tablet" device. Much of what they are working on will also apply to embedded devices, such as touch screens, and onscreen keyboards. But they are ignoring anything not Mameo related, and are not building for an embedded device. Therefore, I would like to see who else is working on these issues, and work toward getting a real embedded project going. I will take the point if need be. Thanks in advance -- Kevin Fries Senior Linux Engineer Computer and Communications Technologies, Inc. a division of Japan Communications, Inc.
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
