RedBoot
This boot loader is built on the hardware abstraction layer of the eCos embedded operating system. The result is a very robust boot loader with a wide range of architecture and device support. As you can guess from the name, this software is part of the Red Hat family of projects. You can obtain the sources for RedBoot from sourceware like so:
$ mkdir ~/redboot
$ cd ~/redboot
$ wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl
$ cd ecos-install.tcl
The file downloaded is a script that downloads the rest of the RedBoot’s code. This script is written in Tcl (it was first TCL, for Tool Command Language, but now it’s frequently referred to as “tickle”). The code first prompts for a download mirror; select one close to your current location. Next, the software prompts for the installation directory; you can accept the default. The next question asks what prebuilt tools to install. The RedBoot loader is picky about the configuration of the compiler used to build it. The cross-compiler created earlier works fine under most conditions; however, the best practice is to download the toolchain offered by the installation program:
Available prebuilt GNU tools:
[1] arm-eabi
[2] arm-elf (old)
[3] i386-elf
[4] m68k-elf
[5] mipsisa32-elf
[6] powerpc-eabi
[7] sh-elf
[q] Finish selecting GNU tools
The menu lets you select several tool chains. Each architecture has one toolchain (except ARM; in that case, choose the first), After the installation process finishes, you rebuild by running ecosconfig to configure the source tree and then make to run a build. For example, to do this for an ARM Integrator board, you need the following commnds:
$ cd <redboot installation directory>
$ source ./ecosenv.sh
$ ecosconfig new integrator redboot
$ ecosconfig import ~/ecos/ecos-3.0/��
packages/hal/arm/integrator/v3_0/misc/redboot_ROMRAM.ecm
$ ecosconfig tree
$ make
The first two lines configure environment variables for eCos based on the installation script. The next line creates a skeleton project for the ARM Integrator board, and the next two lines import a configuration file for that board and create the source tree for the build. The build product is in the install/bin directory. The correct values for the parameters passed into ecosconfig for the configuration steps are contained in the http://ecos.sourceware.org/docs-latest/redboot/installationand-testing.html file. This example builds two binaries: one to be loaded into RAM and executed and the other suitable to be written into flash.
After it’s built, you can write the new boot loader into flash using RedBoot. This is platform specific. The basis process involves uploading the image on the board into RAM and then writing the data to flash. An example of the commands to perform these steps follows; again, the exact instructions vary for each board. You issue these commands d on the board using the existing redboot program:
redboot> fis init -f
redboot> load -r -b <address> redboot_ROM.bin
redboot> cksum
redboot> fiscreate redboot
When the board is reset, the new version of RedBoot is running.
Using RedBoot
The general process for using RedBoot is to load the kernel into memory and run it. A kernel comes from either flash storage or from a TFTP server. To load a kernel from flash, use these commands:
redboot> fis load -b 0x1000000 kernel
This command loads the data from the kernel flash partition named kernel and loads the data starting at address 0x100000. A flash partition is a logical division of the flash memory space that’s been assigned a name.
From TFTP, use these commands:
redboot> ip_address -l <ip address> -h <address of tftp server>
redboot> load <kernel_image_file>
The first command configures the first adapter on the board to have the IP address <ip address> (remember to use an acceptable address for your network or hardware configuration; duplicate IP addresses summon an IT staff member who won’t be impressed) and looks to address <address of tftp server> when performing a TFTP download. The TFTP server IP address should be the one of the host configured earlier in the book. After it’s loaded into memory, you can run the kernel by doing the following:
exec -b 0x100000 -l 0x80000 -c "init=runme root=/dev/mtdblock2"
This command runs the kernel loaded into memory at 0x0100000 that’s 0x80000 bytes long with the parameters sent to the kernel following the -c parameter. The kernel is now off and running. RedBoot has support for mounting, reading, and writing Journaling Flash File System (JFFS) partitions, a handy feature because reading these file systems usually requires starting Linux. However, because RedBoot is built on a very small embedded operating system, eCos, this feature isn’t surprising. In addition to being able to perform operations like listing directory contents and reading files, you can also create files. You do so by loading the file into memory and then writing it out into a flash partition. For example:
redboot> fs mount -d /dev/flash1 -t jffs2 /rfs
redboot> fis cd /opt
redboot> load <file> -b 0x80000000
redboot> fis write -b 0x80000000 -l <length> <file name>
<file> is a file loaded from the TFTP server. After it loads into memory, RedBoot returns the length of the file and uses that length in the next command when writing the data from the RAM into the flash file system using the fis write command.
Source of Information : Pro Linux Embedded Systems
Tuesday, April 20, 2010
Monday, April 19, 2010
Kernel-Land vs. Userland
In Linux, a bright line exists between the kernel’s execution context and that of the programs being run. The kernel’s context is called kernel-land or kernel space and encompasses all the device interaction, threads, interrupt handlers, data structures, and memory. When a program is executed, the kernel creates a virtual memory address, configures resource descriptors (like those for files, timers, and semaphores), loads the program into memory, and configures the processor’s registers to start execution. All of this activity occurs in userland. These two execution contexts can communicate under controlled circumstances but are otherwise separate and distinct. Although the kernel and userland are separate and distinct, they’re very much related. When the kernel boots, it initializes (and registers) devices that can be used later in the startup process or when the system is up and running. For example, when a board boots that has a USB host controller, the driver for that device initializes in the kernel; in userland, programs can run that interrogate the devices attached to the USB bus and load corresponding drivers.
Understanding the hand-off from the kernel to the first userland process helps when you’re debugging startup problems and trying to reduce startup time. From a diagnostic perspective, knowing that the kernel started successfully means booting problems have been automatically narrowed to something in the root file system or initial RAM disk. From a performance perspective, knowing that a configuration step can be done in the kernel or userland (such as assigning an IP address to a network adapter) means certain activities can be deferred until later and scheduled such that system appears to boot faster, or when you can more readily control the configuration process.
Source of Information : Pro Linux Embedded Systems
Understanding the hand-off from the kernel to the first userland process helps when you’re debugging startup problems and trying to reduce startup time. From a diagnostic perspective, knowing that the kernel started successfully means booting problems have been automatically narrowed to something in the root file system or initial RAM disk. From a performance perspective, knowing that a configuration step can be done in the kernel or userland (such as assigning an IP address to a network adapter) means certain activities can be deferred until later and scheduled such that system appears to boot faster, or when you can more readily control the configuration process.
Source of Information : Pro Linux Embedded Systems
Sunday, April 18, 2010
Free Electrons
Free Electrons started as a Linux training house by providing some of the best training materials freely available for embedded Linux engineers. The company has since branched out into providing embedded Linux consulting and training, along the lines of Embedded Alley. With its training heritage, Free Electrons focuses on helping its customers be good embedded Linux engineers, providing additional services where necessary. Free Electrons is very aggressive about making material and development work available to the open source community. Most of the training materials offered by the company are available for download free of charge. The materials include slides with comments and lab practice sessions. This wealth of information is offered without registration, which is refreshing and relieves you from using a throwaway e-mail address and fake phone number. Another interesting service that Free Electrons offers is taking the changes that your company may have made to Linux and supporting projects and getting them in shape for submission into the main development projects. Getting changes into the mainline of projects means that code will be supported with future releases of the software, so you won’t have to figure out how to get patches to apply when the base software has updated. This reduces the time and efforts involved in keeping patches synchronized with the larger open source community.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Saturday, April 17, 2010
DENX
DENX is a Linux consultancy based in Germany that does business worldwide and focuses on PowerPC architecture. The company’s deep knowledge in kernel engineering for emerging hardware means that people seek out DENX for hardware-related development. The company got its start by doing boot loader work, creating a widely used boot loader for embedded systems called U-Boot. Getting a boot loader up and running on a system is a tricky bit of engineering that’s essential to making the board able to run an operating system. In addition to creating the boot loader, DENX also does the early boot-time work necessary to get Linux running after the boot loader hands execution off to the kernel.
This deep knowledge of the Linux kernel means that DENX distributions frequently support new hardware sooner that what’s available in the general Linux kernel. DENX isn’t withholding code from the open source community; rather, it takes time for a patch to wend its way through the process for inclusion in the main Linux kernel. Unlike many companies, DENX makes available its commercial product through the Embedded Linux Development Kit (ELDK). The ELDK is a remarkably complete embedded Linux distribution that includes a root file system, kernel, and tool chain. Because DENX is focused on PowerPC, the company’s web site lists only PowerPC processors as supported; however, there are builds that aren’t officially supported by DENX for other architectures.
Source of Information : Pro Linux Embedded Systems
This deep knowledge of the Linux kernel means that DENX distributions frequently support new hardware sooner that what’s available in the general Linux kernel. DENX isn’t withholding code from the open source community; rather, it takes time for a patch to wend its way through the process for inclusion in the main Linux kernel. Unlike many companies, DENX makes available its commercial product through the Embedded Linux Development Kit (ELDK). The ELDK is a remarkably complete embedded Linux distribution that includes a root file system, kernel, and tool chain. Because DENX is focused on PowerPC, the company’s web site lists only PowerPC processors as supported; however, there are builds that aren’t officially supported by DENX for other architectures.
Source of Information : Pro Linux Embedded Systems
Friday, April 16, 2010
Embedded Alley
Embedded Alley is a Linux consultancy house that supplies customers with a mix of off-the-shelf software and services. The typical engagement with Embedded Alley begins with an interview during which the company finds out what you need; it then produces the software that matches your requirements along with support and training services. Embedded Alley doesn’t offer IDE tools like MontaVista or Wind River. Instead, the company expects that customers will use open source tools for their development process.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Thursday, April 15, 2010
MontaVista
MontaVista’s Linux operating system started as Hard Hat Linux that offered realtime performance. The company has branched out into serving the general embedded Linux market and has extended its product offerings through the addition of an IDE and other tools. MontaVista’s value proposition is around delivering a well-tested Linux distribution paired with support and tools. MontaVista has two targeted distributions: one for carrier grade for telecommunications applications, and the other Mobilinux for handsets. The company also markets a general-purpose Linux distribution, Professional Edition. Unlike Wind River, MontaVista’s focus is entirely on embedded Linux, and the company has embraced open source from its inception. The company regularly contributes to the Linux kernel (and, using number of changes contributed as a metric, is one of the top contributors to the Linux kernel project) and other open source initiatives, such as power management and special-purpose file systems. Although the software offered by MontaVista may lag behind that of the general Linux community by a year to 18 months so it can be tested and validated, the company has proven that it’s always working on the next version of Linux for its customers. A transaction with the company involves purchasing a subscription that gives you the right to a certain number of software updates, the use of tools, and support during the length of the engagement. During the sales process, it’s typical for MontaVista to sell services and training as well.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Wednesday, April 14, 2010
Wind River
Wind River is what’s called the incumbent vendor in marketing speak. Wind River has been in the embedded business since before Linux existed and has a business built on delivering everything necessary for embedded development. In this case, “everything” means software, training, services, legal advice for open source, professional services, development tools for Linux, as well as the company’s other embedded operating system, VxWorks. Wind River’s Linux business model consists of supplying a version of Linux and the root file system that have been thoroughly tested and verified for the target boards, along with packages for supporting use cases like consumer electronics and industrial control. Wind River’s strong suit is its development tools: Workbench. Workbench is a soup-to-nuts development environment that has excellent debugging and system-building tools to help with development. To provide a Linux distribution that’s been tested and validated, the distributions from Wind River usually run a year or so behind the head of line development of the kernel or patches. But not all projects need the latest Linux. Wind River’s product offerings are the most expensive of the lot. For budget-constrained companies, the pricing may take this company out of the running, the value of the services notwithstanding. Because Linux competes with Wind River’s closed source VxWorks operating system, the company has had a mixed view of Linux and open source, to the point of running a “seven levels of open source hell” campaign complete with gargoyles. Over the years, Wind River has warmed to Linux, but it’s still viewed as a secondary offering to VxWorks.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Tuesday, April 13, 2010
Getting Linux from Commercial Vendors and Consultants
Commercial vendors and consultants are different from board vendors in that they make Linux solutions for several different board vendors or processor manufacturers. Chances are, the distribution being sold or supplied with the board was created by one of these consultants under a contract arrangement. There’s nothing wrong with deciding to turn a technical problem (some portion of getting Linux up and running for a target board) into a financial problem. Often, because open source software is available for the taking, people believe they can get it working for a project if the resources are available. Just like any other mutually beneficial exchange, buying from a vendor is the right choice if the product delivered is at the right price and clears your schedule for higher-valued activities.
Vendors in the commercial Linux space focus on creating Linux distributions from a functional level. Customers come to these vendors looking for higher-level features such as quick boot-time, realtime, or graphics, and expect the vendors to get these components up and running on one or more target boards being considered for the project.
Do You Need a Commercial Vendor?
Many companies that examine their budgets, time lines, and resources decide that even though Linux could be built in-house, it makes sense to purchase. The driving element behind many embedded vendors is how the companies view working with Linux: is the operating system part of the core product value?
For example, a company that creates point-of-sale (POS) terminals has core product features like the user interface that increase user productivity or improved ways of capturing signatures that require less storage. This is very different than a company that makes a network-attachable device that aids in system backup. The POS company may be almost indifferent to the operating system used in the product, and people buying their products may care even less. In this case, purchasing Linux is probably the right choice because it allows the company to focus on features that matter to its customers.
Contrast this with the storage device company, for example. This type of device is purchased by very technical people who need to integrate the device into an existing network structure; for them, knowing what operating system the device is running is essential. Some of the work done by engineering at the storage company may give it an edge over its competitors, and the company’s management may be reluctant to help those changes make their way back to the main kernel project. In this sense, Linux is a feature of the product and part of its value proposition. This company should consider building Linux from scratch in order to have the greatest amount of control over this critical aspect of the product.
Or, consider a company that builds industrial machinery. In this company, realtime performance is a requirement that must be met. Customers who purchase the machinery may program units in the field, so having an open operating system like Linux is important. This company is another candidate where contracting with a vendor that is responsible for monitoring and understanding realtime on Linux has much to offer.
Getting a Linux environment up and running can also be a research as well as an engineering project. Some products must get to market or be delivered by a certain date, and variance isn’t acceptable. In this case, going the route of getting something ready out of the box makes perfect sense, because certainty has higher value than money.
Finally, a vendor does system configuration work that can be of very high value. Some vendors specialize in certain industry hardware protocols, like CANBus, and can supply a Linux distribution that has these drivers in working order for the project.
Source of Information : Pro Linux Embedded Systems
Vendors in the commercial Linux space focus on creating Linux distributions from a functional level. Customers come to these vendors looking for higher-level features such as quick boot-time, realtime, or graphics, and expect the vendors to get these components up and running on one or more target boards being considered for the project.
Do You Need a Commercial Vendor?
Many companies that examine their budgets, time lines, and resources decide that even though Linux could be built in-house, it makes sense to purchase. The driving element behind many embedded vendors is how the companies view working with Linux: is the operating system part of the core product value?
For example, a company that creates point-of-sale (POS) terminals has core product features like the user interface that increase user productivity or improved ways of capturing signatures that require less storage. This is very different than a company that makes a network-attachable device that aids in system backup. The POS company may be almost indifferent to the operating system used in the product, and people buying their products may care even less. In this case, purchasing Linux is probably the right choice because it allows the company to focus on features that matter to its customers.
Contrast this with the storage device company, for example. This type of device is purchased by very technical people who need to integrate the device into an existing network structure; for them, knowing what operating system the device is running is essential. Some of the work done by engineering at the storage company may give it an edge over its competitors, and the company’s management may be reluctant to help those changes make their way back to the main kernel project. In this sense, Linux is a feature of the product and part of its value proposition. This company should consider building Linux from scratch in order to have the greatest amount of control over this critical aspect of the product.
Or, consider a company that builds industrial machinery. In this company, realtime performance is a requirement that must be met. Customers who purchase the machinery may program units in the field, so having an open operating system like Linux is important. This company is another candidate where contracting with a vendor that is responsible for monitoring and understanding realtime on Linux has much to offer.
Getting a Linux environment up and running can also be a research as well as an engineering project. Some products must get to market or be delivered by a certain date, and variance isn’t acceptable. In this case, going the route of getting something ready out of the box makes perfect sense, because certainty has higher value than money.
Finally, a vendor does system configuration work that can be of very high value. Some vendors specialize in certain industry hardware protocols, like CANBus, and can supply a Linux distribution that has these drivers in working order for the project.
Source of Information : Pro Linux Embedded Systems
Monday, April 12, 2010
Open Source Embedded Distributions - OpenEmbedded (http://wiki.openembedded.net/)
The OpenEmbedded project got started as the build infrastructure for the Sharp Zaurus hand-held computer that ran Linux. The OpenEmbedded system uses the BitBake (more on that later) system for describing packages patches and their interrelationships. Formally, the project views the BitBake system as the build infrastructure for metadata supplied by the OpenEmbedded project.
OpenEmbedded, like the other distribution builders, builds a kernel, toolchain, and root file system. The BitBake software has the notion of recipes that it uses to download and cross-build packages; you can use this software to build other software as well.
Unlike many project, OpenEmbedded recommends that you check out the project from a source code repository. To get updates, refresh the project’s files from source control. You may find this disorienting; or it may leave you with the impression that the software isn’t “done.” Because of the rapid changes to OpenEmbedded and the fact that it’s implemented in Python plus shell scripts (meaning there’s no separate compilation step for you to perform), this model works well.
The BitBake model requires an earnest learning commitment. The software ships with an example configuration file that you can use to create a simple build. However, the software doesn’t have a UI, so figuring out what it can do requires that you read the documentation. The OpenEmbedded site contains quite a bit of information, but it seems to operate under the assumption that you’re already familiar with the technology.
The OpenEmbedded software models the software build into the following parts:
• Distribution: This distribution contains a list of packages for the root file system and the kernel to use for the build. It also contains the settings for the root file system type.
• Machine: The machine data describes the hardwarethe distribution will be running on: for example, the size of the flash partitions or the name device for the serial console. The machine also has an associated set of packages that address features specific to that machine.
• Package recipe: The metadata part of the OpenEmbedded project is a library of BitBake recipes. A recipe specifies where to download a package, what patches to apply, and when and how to install the package in the target machine’s root file system.
OpenEmbedded is very different from other build systems since it’s object-oriented in nature. At its core, BitBake uses the recipe to instantiate the appropriate class necessary to build a package. The object-oriented approach makes sense when you’re building packages because the overall steps are the same for every package, but the particulars for any step for a given package may be unique. By using classes intelligently, the authors don’t repeat code when a group of packages all have the same processing for certain steps in the process.
The notion of inheritance is also writ large on the configuration files used by OpenEmbedded. A file for a distribution likely includes many other files shared by other distributions. This structure has benefits in that one change can be easily applied to many distributions, but it also means the details are hidden if you’re a novice user. If you’ve slogged through other class libraries, you’ll have the same feeling when learning the ins and outs of OpenEmbedded’s data files.
Open Embedded uses two different source-control systems, which are sometimes called code librarians: Subversion (SVN) and Git (no known aliases). Both of these systems provide the same sort of functionality, keeping track of code changes from developers over time, but in very different ways. OpenEmbedded is actually two projects that work together, and each project is selected a different source-control system; that's OK, but it may be a little disorienting to new users.
Source of Information : Pro Linux Embedded Systems
OpenEmbedded, like the other distribution builders, builds a kernel, toolchain, and root file system. The BitBake software has the notion of recipes that it uses to download and cross-build packages; you can use this software to build other software as well.
Unlike many project, OpenEmbedded recommends that you check out the project from a source code repository. To get updates, refresh the project’s files from source control. You may find this disorienting; or it may leave you with the impression that the software isn’t “done.” Because of the rapid changes to OpenEmbedded and the fact that it’s implemented in Python plus shell scripts (meaning there’s no separate compilation step for you to perform), this model works well.
The BitBake model requires an earnest learning commitment. The software ships with an example configuration file that you can use to create a simple build. However, the software doesn’t have a UI, so figuring out what it can do requires that you read the documentation. The OpenEmbedded site contains quite a bit of information, but it seems to operate under the assumption that you’re already familiar with the technology.
The OpenEmbedded software models the software build into the following parts:
• Distribution: This distribution contains a list of packages for the root file system and the kernel to use for the build. It also contains the settings for the root file system type.
• Machine: The machine data describes the hardwarethe distribution will be running on: for example, the size of the flash partitions or the name device for the serial console. The machine also has an associated set of packages that address features specific to that machine.
• Package recipe: The metadata part of the OpenEmbedded project is a library of BitBake recipes. A recipe specifies where to download a package, what patches to apply, and when and how to install the package in the target machine’s root file system.
OpenEmbedded is very different from other build systems since it’s object-oriented in nature. At its core, BitBake uses the recipe to instantiate the appropriate class necessary to build a package. The object-oriented approach makes sense when you’re building packages because the overall steps are the same for every package, but the particulars for any step for a given package may be unique. By using classes intelligently, the authors don’t repeat code when a group of packages all have the same processing for certain steps in the process.
The notion of inheritance is also writ large on the configuration files used by OpenEmbedded. A file for a distribution likely includes many other files shared by other distributions. This structure has benefits in that one change can be easily applied to many distributions, but it also means the details are hidden if you’re a novice user. If you’ve slogged through other class libraries, you’ll have the same feeling when learning the ins and outs of OpenEmbedded’s data files.
Open Embedded uses two different source-control systems, which are sometimes called code librarians: Subversion (SVN) and Git (no known aliases). Both of these systems provide the same sort of functionality, keeping track of code changes from developers over time, but in very different ways. OpenEmbedded is actually two projects that work together, and each project is selected a different source-control system; that's OK, but it may be a little disorienting to new users.
Source of Information : Pro Linux Embedded Systems
Sunday, April 11, 2010
Open Source Embedded Distributions - Buildroot (http://buildroot.uclibc.org/)
Buildroot is a project that helps you create root file systems and toolchains that use uClibc and BusyBox, a small C Library, and basic set of root file system tools. Buildroot grew out of the BusyBox and uClibc projects, two of the most commonly used pieces of software for embedded projects. Because this tool integrated both of these projects, it serves as a great starting point for creating a Linux distribution for a project.
Like LTIB, Buildroot uses an interface that’s similar the tool used to configure the kernel. Although this is comforting for a system-level engineer, the tool can be confusing if you’re a new engineer. The primary problem with this tool is that you have to keep track of where you are; after you use the software for a few minutes, nearly every page looks the same, and picking the correct options becomes tedious. Buildroot configures an entire development environment—kernel, root file system, and toolchain— which means you need to configure the options for these complex projects before starting a build. There are literally hundreds of options to configure, and the sheer number of items makes the process mildly tedious. For some boards, default configuration files configure the build with the right settings. Unfortunately, there aren’t many of these default configuration files, so the chances of one matching the board you’re using are fairly low.
Buildroot uses tar files as its package system and uses a collection of make files to configure the software before building. This implementation is easy to understand if you’ve used make in the past for moderately complex projects. Each package has a .mk file containing the make rules necessary to download, configure, build, and clean the package and a Config.in that is used by the configuration tool.
Source of Information : Pro Linux Embedded Systems
Like LTIB, Buildroot uses an interface that’s similar the tool used to configure the kernel. Although this is comforting for a system-level engineer, the tool can be confusing if you’re a new engineer. The primary problem with this tool is that you have to keep track of where you are; after you use the software for a few minutes, nearly every page looks the same, and picking the correct options becomes tedious. Buildroot configures an entire development environment—kernel, root file system, and toolchain— which means you need to configure the options for these complex projects before starting a build. There are literally hundreds of options to configure, and the sheer number of items makes the process mildly tedious. For some boards, default configuration files configure the build with the right settings. Unfortunately, there aren’t many of these default configuration files, so the chances of one matching the board you’re using are fairly low.
Buildroot uses tar files as its package system and uses a collection of make files to configure the software before building. This implementation is easy to understand if you’ve used make in the past for moderately complex projects. Each package has a .mk file containing the make rules necessary to download, configure, build, and clean the package and a Config.in that is used by the configuration tool.
Source of Information : Pro Linux Embedded Systems
Saturday, April 10, 2010
Open Source Embedded Distributions - LTIB (http://www.bitshrine.org)
The Linux Target Image Builder (LTIB) user interface is much like the kernel configuration tool, which, although familiar to systems-level engineers, can be confusing if you’re new to Linux. LTIB is accommodating in that it does its best to verify the environment before starting a build and lets you know about corrective actions before starting a 3-hour build process.
One of the complaints about LTIB is that the first time it runs, it downloads the entire set of packages that it could use in a distribution. This is a mixed blessing in that after the packages are on the system, the host doesn’t need to be attached to the network in order to get a build running. Another advantage of the big download is that you can put the entire directory into a code librarian and check it out on a build machine for easy platform scripting.
The second complaint is that the software doesn’t build toolchains but downloads the binaries and installs them on the system. This is also somewhat advantageous in that building a toolchain requires at least an hour on a very fast computer and, due to the patches and configuration dependencies, is an operation that frequently fails. LTIB provides the sources for the toolchain it downloads; it just doesn’t build the toolchain during the build process running on the host machine.
One great advantage of LTIB is that it builds a JFFS2 image containing the root file system, ready to be burned on to a flash partition, as part of the build. Along with the self-contained nature of the project, LTIB is a great tool if you want or need to automate your platform build.
LTIB is an RPM-based system. This means it uses source RPM files to do the build, and integrating a package into LTIB means learning how to create RPM packages. Creating a source RPM build for an application isn’t difficult; but for some reason, it scares some users away from fully taking advantage of LTIB. Instead of having the software build your application from an RPM as part of the LTIB build, you can post-process the file system, adding the application and making any final changes.
Source of Information : Pro Linux Embedded Systems
One of the complaints about LTIB is that the first time it runs, it downloads the entire set of packages that it could use in a distribution. This is a mixed blessing in that after the packages are on the system, the host doesn’t need to be attached to the network in order to get a build running. Another advantage of the big download is that you can put the entire directory into a code librarian and check it out on a build machine for easy platform scripting.
The second complaint is that the software doesn’t build toolchains but downloads the binaries and installs them on the system. This is also somewhat advantageous in that building a toolchain requires at least an hour on a very fast computer and, due to the patches and configuration dependencies, is an operation that frequently fails. LTIB provides the sources for the toolchain it downloads; it just doesn’t build the toolchain during the build process running on the host machine.
One great advantage of LTIB is that it builds a JFFS2 image containing the root file system, ready to be burned on to a flash partition, as part of the build. Along with the self-contained nature of the project, LTIB is a great tool if you want or need to automate your platform build.
LTIB is an RPM-based system. This means it uses source RPM files to do the build, and integrating a package into LTIB means learning how to create RPM packages. Creating a source RPM build for an application isn’t difficult; but for some reason, it scares some users away from fully taking advantage of LTIB. Instead of having the software build your application from an RPM as part of the LTIB build, you can post-process the file system, adding the application and making any final changes.
Source of Information : Pro Linux Embedded Systems
Friday, April 9, 2010
MontaVista
MontaVista’s Linux operating system started as Hard Hat Linux that offered realtime performance. The company has branched out into serving the general embedded Linux market and has extended its product offerings through the addition of an IDE and other tools. MontaVista’s value proposition is around delivering a well-tested Linux distribution paired with support and tools. MontaVista has two targeted distributions: one for carrier grade for telecommunications applications, and the other Mobilinux for handsets. The company also markets a general-purpose Linux distribution, Professional Edition. Unlike Wind River, MontaVista’s focus is entirely on embedded Linux, and the company has embraced open source from its inception. The company regularly contributes to the Linux kernel (and, using number of changes contributed as a metric, is one of the top contributors to the Linux kernel project) and other open source initiatives, such as power management and special-purpose file systems. Although the software offered by MontaVista may lag behind that of the general Linux community by a year to 18 months so it can be tested and validated, the company has proven that it’s always working on the next version of Linux for its customers. A transaction with the company involves purchasing a subscription that gives you the right to a certain number of software updates, the use of tools, and support during the length of the engagement. During the sales process, it’s typical for MontaVista to sell services and training as well.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Why Embedded Linux Distribution Builders Exist
These distribution-building tools exist due to a catalyst such as supporting a particular usage scenario (for example, as small as possible or rescue disks) or a certain hardware platform (such as a cell phone). These aren’t mutually exclusive concepts, because cell phone Linux distributions are frequently small— resource consumption is very important for that hardware platform. The concept of a distribution builder isn’t limited to embedded Linux; the same concept exists for desktop Linux systems, the output being an ISO and collection of packages (think RPMs or debs) In the case of hardware platform–specific distribution builders, the vendor isn’t interested in selling the Linux distribution, but rather sees the Linux distribution as an enabler for hardware sales and also as a way to potentially harm the revenue stream of a competitor that sells a Linux distribution as an add-on product. Linux is a way to help sell hardware, plain and simple. As time progresses, the distributionbuilder project begins to support a larger variety of hardware, because adapting an existing code base makes for smart engineering. Several embedded distributions are package system based. The distributions are embedded in terms of the packages, target platform, and size that use an underlying packaging technology to achieve this aim. Although some projects use the same packaging system but have a focus on a particular technology or hardware, these projects are focused on the packaging system.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Thursday, April 8, 2010
Open Source Embedded Distributions
An ever-increasing number of projects build Linux distributions, to the point that building a Linux distribution is a rite of passage for engineers, like building a text editor was in years past. Linux distribution builders all work on the same basic principles: a kernel and group of packages are built according to a specification into a completed set of binaries suitable for deployment. Some distribution builders create a toolchain as part of the process, and others download a binary toolchain from a known location.
When you’re classifying these systems, the type of packaging system is a good first-order differentiator, because no matter how the system tries to shield you from the particulars, you eventually need to get familiar with this underlying technology. The most common packing system is a compressed tar file; that’s fortunate because this packaging technology is the lowest common denominator and is familiar to most engineers, Linux and otherwise.
Source of Information : Pro Linux Embedded Systems
When you’re classifying these systems, the type of packaging system is a good first-order differentiator, because no matter how the system tries to shield you from the particulars, you eventually need to get familiar with this underlying technology. The most common packing system is a compressed tar file; that’s fortunate because this packaging technology is the lowest common denominator and is familiar to most engineers, Linux and otherwise.
Source of Information : Pro Linux Embedded Systems
Wednesday, April 7, 2010
Obtaining Linux from the Board Vendor
Board vendors frequently include a Linux distribution with a board so that users can start up the board and see that it works, exercise critical peripherals, and otherwise make sure the board performs as expected. Embedded projects frequently start on a development board that’s a proxy for the production board that hardware designers are creating for the device. The completeness of a Linux distribution supplied with the board varies greatly from vendor to vendor and sometimes from board to board.
A development board contains every peripheral possible and has ports that make it easy to attach off-the-shelf components to the board when you’re doing development. The development board contains LEDs and sometimes a small LCD to report on the internal board state. During the hardware design process, another team creates a board that fits the industrial design of the device, with the connectors in the right places and the subset of peripherals for the device. This board operates just like the development board from a software perspective, but it doesn’t resemble the development board from a physical perspective.
Questions You Should Ask Your Board Vendor
The point of these questions is both to assess whether the product offered by the vendor is good enough for the project and to see how committed the vendor is to creating providing a complete solution that will be supported throughout the project:
• What devices does the kernel support? You’d think that the devices on the board would be supported, but that isn’t always the case! Make a checklist of the devices that will be on the production board so you don’t forget any when querying the board vendor. Some board vendors support the most commonly used devices, like network or serial ports, but don’t have proper support for a video-out port or audio device.
• Where are the source code and patches for the kernel? Open source means you’re entitled to the source code, any patches, and instructions explaining how to use those patches. Patches sometimes need to be applied in a certain order, because one patch makes changes on the assumption that some other patch has been applied first. The fact that patches are interrelated isn’t indicative of poor engineering, but rather that the company has been carefully tracking the changes it makes to the main kernel. If you’re aware of other patches that need to be applied, you should test to be sure they’re compatible with what the vendor has supplied. For example, the patches for a project like Linux-tiny1 may make changes throughout the kernel, and those changes may collide with other changes from the vendor. Not all of these issues can be identified or solved before purchasing, but you should address as many that are known.
• How compatible are patches with the current Linux kernel? This is important. In the Linux project, changes happen to the head of line (old-school speak for the version that will be released next) and are rarely back ported. That means if there’s a change to the kernel—say, to address a security issue—that change is made to the current kernel and not to the one included with the board, unless that kernel happens to be the head of line. The answer to this question is a function of how old the patches are in combination with how many other changes they contain. For some boards, the changes, although extensive, are limited to the parts of the kernel that deal specifically with the hardware and can be transferred easily to a newer version of the kernel if necessary. Even if patches can’t be applied to the newest kernel, you many never need to switch to a newer kernel, making this a moot point.
• What level of testing has been performed? One of the things a commercial vendor knows is the state of the software being delivered. Sometimes, the answer is that no testing has occurred. Depending on the project, that may or may not be sufficient. The internal testing done by your company may trump what ever testing the board vendor has or hasn’t done.
• Where’s the toolchain? Getting the sources with the binaries is part of the GPL. There’s no provision to ensure that the tools and software necessary to transform those sources into binaries are part of that equation. The toolchain supplied should be the same one used to build the kernel and the root file system (see the next item), and the supplier should include instructions on how to rebuild the toolchain as well. The GNU toolchain is a group of related projects: a compiler, libraries, linker, utilities, and a debugger. The vendor should understand this notion and be able to describe the version and patches applied to each. As a user, the chances of rebuilding the toolchain completely are fairly low, but you’re likely to need to add libraries or use a newer version of the debugger. Knowing how the toolchain is configured helps you determine compatibility with any additional or updated software. In addition, getting the answer to this question serves as a way to gauge the competency and level of engagement of the vendor with respect to their Linux efforts. Some board vendors put a great deal of care and effort into supplying a top-notch distribution, whereas others do the minimum to claim Linux support.
• What’s in the root file system? This is a deliberately broad question, mostly because it’s a broad topic. A root file system, as explained later in the book, is a complex project that involves several related projects coming together. A root file system can be anything from one file to the contents of an enterprise Linux server. The vendor should be able to describe the version for each software component used in the root file system. If you plan to use shared libraries, make sure the shared libraries in the root file system match those in the toolchain. This is a critical detail! When you’re crosscompiling applications that use shared libraries on the desktop, those binaries dynamically link to the shared libraries with the toolchain; however, when those same binaries are put in the root file system on the board, they attempt to link with those shared libraries. If there’s a mismatch between the libraries used for the compilation and those used for execution, the software may refuse to load or, even worse, may fail unpredictably. If you’re linking statically, the shared libraries aren't important, because the code that would reside in the shared library is included in the compiled binary.
• Do the devices supported on the board have their complementary userland supporting packages? This is another semi-trick question to gauge the level of care that went into creating the root file system. Devices have become more complex and, for lack of a better word, interactive. For example, supporting USB devices requires support in the kernel and complementary packages in the root file system. The Linux USB software stack includes programs in the root file system that are executed when a user plugs in or unplugs a USB device.
• Where are the root file system sources and patches, and how do I build it? Like the toolchain, the root file system is a confederation of packages that work together.
Packages included in the root file system are typically licensed under the GPL, so you’re due the source under that license agreement along with the build instructions. The build instructions need to explain how to apply any patches along with the information necessary for compilation. Because the root file system is a collection of packages, the vendor should explain how to assemble all the packages into something that you can use for booting the board. (This isn’t part of the GPL, but it’s knowledge you’re paying for as part of the purchase.)
• How often does the company plan to upgrade the kernel? The Linux project (both the kernel and the collection of projects that make up the root file system) doesn’t rest: changes are continually occurring, and that’s certainly a good thing. As a customer, understanding how the board vendor reacts to this change helps you understand how you’ll be kept up-to-date with the changes in the open source community. Will the software be updated as kernel and package updates occur? Is there a regular release cycle during which the vendor collects changes and validates and tests them before release? Or is the Linux distribution a snap-shot of the current state of the projects and never updated, leaving updates to you? All of these are valid approaches, and as the buyer, it’s important for you to know what the board vendor is supplying.
• What support do you provide? What sort of questions will you answer? The answer to these questions reveals the amount of in-house expertise the vendor has at its disposal; in general, the more resources the vendor has, the more they’re willing to share those resources with their customers. You should also ask yourself what level of support required. If this is the first embedded Linux project undertaken at your company, the type and level of support required will be different than if the company already has a high degree of Linux expertise. Some support agreements explicitly say that consulting services aren’t offered, where consulting means providing advice related to how to use the software. From the vendor’s perspective, the support contract exists to limit the support offered, so the vendor doesn’t make a commitment it can’t fulfill.
Source of Information : Pro Linux Embedded Systems
A development board contains every peripheral possible and has ports that make it easy to attach off-the-shelf components to the board when you’re doing development. The development board contains LEDs and sometimes a small LCD to report on the internal board state. During the hardware design process, another team creates a board that fits the industrial design of the device, with the connectors in the right places and the subset of peripherals for the device. This board operates just like the development board from a software perspective, but it doesn’t resemble the development board from a physical perspective.
Questions You Should Ask Your Board Vendor
The point of these questions is both to assess whether the product offered by the vendor is good enough for the project and to see how committed the vendor is to creating providing a complete solution that will be supported throughout the project:
• What devices does the kernel support? You’d think that the devices on the board would be supported, but that isn’t always the case! Make a checklist of the devices that will be on the production board so you don’t forget any when querying the board vendor. Some board vendors support the most commonly used devices, like network or serial ports, but don’t have proper support for a video-out port or audio device.
• Where are the source code and patches for the kernel? Open source means you’re entitled to the source code, any patches, and instructions explaining how to use those patches. Patches sometimes need to be applied in a certain order, because one patch makes changes on the assumption that some other patch has been applied first. The fact that patches are interrelated isn’t indicative of poor engineering, but rather that the company has been carefully tracking the changes it makes to the main kernel. If you’re aware of other patches that need to be applied, you should test to be sure they’re compatible with what the vendor has supplied. For example, the patches for a project like Linux-tiny1 may make changes throughout the kernel, and those changes may collide with other changes from the vendor. Not all of these issues can be identified or solved before purchasing, but you should address as many that are known.
• How compatible are patches with the current Linux kernel? This is important. In the Linux project, changes happen to the head of line (old-school speak for the version that will be released next) and are rarely back ported. That means if there’s a change to the kernel—say, to address a security issue—that change is made to the current kernel and not to the one included with the board, unless that kernel happens to be the head of line. The answer to this question is a function of how old the patches are in combination with how many other changes they contain. For some boards, the changes, although extensive, are limited to the parts of the kernel that deal specifically with the hardware and can be transferred easily to a newer version of the kernel if necessary. Even if patches can’t be applied to the newest kernel, you many never need to switch to a newer kernel, making this a moot point.
• What level of testing has been performed? One of the things a commercial vendor knows is the state of the software being delivered. Sometimes, the answer is that no testing has occurred. Depending on the project, that may or may not be sufficient. The internal testing done by your company may trump what ever testing the board vendor has or hasn’t done.
• Where’s the toolchain? Getting the sources with the binaries is part of the GPL. There’s no provision to ensure that the tools and software necessary to transform those sources into binaries are part of that equation. The toolchain supplied should be the same one used to build the kernel and the root file system (see the next item), and the supplier should include instructions on how to rebuild the toolchain as well. The GNU toolchain is a group of related projects: a compiler, libraries, linker, utilities, and a debugger. The vendor should understand this notion and be able to describe the version and patches applied to each. As a user, the chances of rebuilding the toolchain completely are fairly low, but you’re likely to need to add libraries or use a newer version of the debugger. Knowing how the toolchain is configured helps you determine compatibility with any additional or updated software. In addition, getting the answer to this question serves as a way to gauge the competency and level of engagement of the vendor with respect to their Linux efforts. Some board vendors put a great deal of care and effort into supplying a top-notch distribution, whereas others do the minimum to claim Linux support.
• What’s in the root file system? This is a deliberately broad question, mostly because it’s a broad topic. A root file system, as explained later in the book, is a complex project that involves several related projects coming together. A root file system can be anything from one file to the contents of an enterprise Linux server. The vendor should be able to describe the version for each software component used in the root file system. If you plan to use shared libraries, make sure the shared libraries in the root file system match those in the toolchain. This is a critical detail! When you’re crosscompiling applications that use shared libraries on the desktop, those binaries dynamically link to the shared libraries with the toolchain; however, when those same binaries are put in the root file system on the board, they attempt to link with those shared libraries. If there’s a mismatch between the libraries used for the compilation and those used for execution, the software may refuse to load or, even worse, may fail unpredictably. If you’re linking statically, the shared libraries aren't important, because the code that would reside in the shared library is included in the compiled binary.
• Do the devices supported on the board have their complementary userland supporting packages? This is another semi-trick question to gauge the level of care that went into creating the root file system. Devices have become more complex and, for lack of a better word, interactive. For example, supporting USB devices requires support in the kernel and complementary packages in the root file system. The Linux USB software stack includes programs in the root file system that are executed when a user plugs in or unplugs a USB device.
• Where are the root file system sources and patches, and how do I build it? Like the toolchain, the root file system is a confederation of packages that work together.
Packages included in the root file system are typically licensed under the GPL, so you’re due the source under that license agreement along with the build instructions. The build instructions need to explain how to apply any patches along with the information necessary for compilation. Because the root file system is a collection of packages, the vendor should explain how to assemble all the packages into something that you can use for booting the board. (This isn’t part of the GPL, but it’s knowledge you’re paying for as part of the purchase.)
• How often does the company plan to upgrade the kernel? The Linux project (both the kernel and the collection of projects that make up the root file system) doesn’t rest: changes are continually occurring, and that’s certainly a good thing. As a customer, understanding how the board vendor reacts to this change helps you understand how you’ll be kept up-to-date with the changes in the open source community. Will the software be updated as kernel and package updates occur? Is there a regular release cycle during which the vendor collects changes and validates and tests them before release? Or is the Linux distribution a snap-shot of the current state of the projects and never updated, leaving updates to you? All of these are valid approaches, and as the buyer, it’s important for you to know what the board vendor is supplying.
• What support do you provide? What sort of questions will you answer? The answer to these questions reveals the amount of in-house expertise the vendor has at its disposal; in general, the more resources the vendor has, the more they’re willing to share those resources with their customers. You should also ask yourself what level of support required. If this is the first embedded Linux project undertaken at your company, the type and level of support required will be different than if the company already has a high degree of Linux expertise. Some support agreements explicitly say that consulting services aren’t offered, where consulting means providing advice related to how to use the software. From the vendor’s perspective, the support contract exists to limit the support offered, so the vendor doesn’t make a commitment it can’t fulfill.
Source of Information : Pro Linux Embedded Systems
Tuesday, April 6, 2010
Getting Linux for Your Board
After looking at the Linux distribution included with a board or sold by the board vendor, it may make sense to start your project with a Linux distribution created by an open source project or from a commercial vendor. Commercial vendors offer deep support for certain use cases (like graphics on consumer electronics devices or Linux certified for use in telecommunications), and open source projects also focus on certain uses cases along the same lines.
Before you build a Linux distribution from scratch (that’s the next chapter—skip ahead if you’re so inclined), it makes sense to see what’s available elsewhere. As Linux has become more common, many projects have sprung into existence to build Linux in one form or another. This chapter looks at build systems that you can use to create an embedded Linux distribution and the offerings of commercial vendors that supply ready-to-use Linux distributions with training and support.
Although Linux is an open source project and the source code is generally available, having somebody else handle the engineering details particular to the selected board make sense because it relieves your schedule of some tasks in exchange for money. Even very technically adept engineers choose to make this trade-off, because frequently time is more valuable than the amount of money required to get a completed Linux platform in the can. Toward that end, this chapter examines the commercial alternatives for Linux so that if you’re interested in purchasing, you can approach the transaction as an informed customer. Some commercial embedded products track closely to what’s available in open source, whereas others are quite different. For projects that have strict requirements around hardware or software support, the commercial product meeting the requirements is the best choice.
You can obtain a Linux distribution three primary ways:
• From company that sold the board: There’s a feeling of confidence when you purchase from a board vendor. Chances are overwhelming in favor of the Linux distribution working for the board in question. The cost is usually much less than it would be from a commercial vendor. On the downside, many hardware companies aren’t in the software business and don’t have the expertise or motivation to support a software product.
• Via an open source distribution build: Several open source projects exist to build Linux. The software necessary to build something as complex as a Linux isn’t a simple undertaking. Because these projects are open source, the processor support is usually narrow; and the likelihood that the build will work for a specific board (that is, your board) is dicey. Plus, you must overcome a learning curve to use the distribution building software, on top of any learning curve involved in building the software.
• From a commercial vendor: A variety of companies offer Linux products and services. These companies do much the same job as the first two alternatives but offer support and mean less risk than trying to build on your own. In addition, these companies offer Linux features like graphics, quick boot-up, and realtime, which the board vendor may not. The support offered by a commercial vendor is also usually more attentive and focused that that available via open source.
Source of Information : Pro Linux Embedded Systems
Before you build a Linux distribution from scratch (that’s the next chapter—skip ahead if you’re so inclined), it makes sense to see what’s available elsewhere. As Linux has become more common, many projects have sprung into existence to build Linux in one form or another. This chapter looks at build systems that you can use to create an embedded Linux distribution and the offerings of commercial vendors that supply ready-to-use Linux distributions with training and support.
Although Linux is an open source project and the source code is generally available, having somebody else handle the engineering details particular to the selected board make sense because it relieves your schedule of some tasks in exchange for money. Even very technically adept engineers choose to make this trade-off, because frequently time is more valuable than the amount of money required to get a completed Linux platform in the can. Toward that end, this chapter examines the commercial alternatives for Linux so that if you’re interested in purchasing, you can approach the transaction as an informed customer. Some commercial embedded products track closely to what’s available in open source, whereas others are quite different. For projects that have strict requirements around hardware or software support, the commercial product meeting the requirements is the best choice.
You can obtain a Linux distribution three primary ways:
• From company that sold the board: There’s a feeling of confidence when you purchase from a board vendor. Chances are overwhelming in favor of the Linux distribution working for the board in question. The cost is usually much less than it would be from a commercial vendor. On the downside, many hardware companies aren’t in the software business and don’t have the expertise or motivation to support a software product.
• Via an open source distribution build: Several open source projects exist to build Linux. The software necessary to build something as complex as a Linux isn’t a simple undertaking. Because these projects are open source, the processor support is usually narrow; and the likelihood that the build will work for a specific board (that is, your board) is dicey. Plus, you must overcome a learning curve to use the distribution building software, on top of any learning curve involved in building the software.
• From a commercial vendor: A variety of companies offer Linux products and services. These companies do much the same job as the first two alternatives but offer support and mean less risk than trying to build on your own. In addition, these companies offer Linux features like graphics, quick boot-up, and realtime, which the board vendor may not. The support offered by a commercial vendor is also usually more attentive and focused that that available via open source.
Source of Information : Pro Linux Embedded Systems
Monday, April 5, 2010
GOOGLE SQUARED
www.google.com/squared - Price: free
Google Squared works just like the regular Google Search: Type in a search term and you are presented with results. What is different is how the results are presented and what you can do with the data. Google Squared presents the results in table form. Results are organized horizontally by several pieces of information (or what Google calls attributes.) All the results in each of the columns come from different places on the Web. You can find the source of the information for each result and attribute by clicking the link in the square. (Remind students that it’s always a good idea to check where information is coming from.)
PROS: You can designate which attributes you want displayed. There are suggestions for attributes, or you can type in your own. If you don’t like or don’t need one of the search results, press the X and it goes away. Your search results are customized for your needs or what your students need.
CONS: This product is still a baby, so there will be mistakes and search results that just don’t fit until the product matures.
OVERALL EVALUATION: Google Squared changes the way students find information on the Web, and the ability to customize the search makes it a good tool for research and developing information literacy.
Source of Information : Tech and Learning February 2010
Google Squared works just like the regular Google Search: Type in a search term and you are presented with results. What is different is how the results are presented and what you can do with the data. Google Squared presents the results in table form. Results are organized horizontally by several pieces of information (or what Google calls attributes.) All the results in each of the columns come from different places on the Web. You can find the source of the information for each result and attribute by clicking the link in the square. (Remind students that it’s always a good idea to check where information is coming from.)
PROS: You can designate which attributes you want displayed. There are suggestions for attributes, or you can type in your own. If you don’t like or don’t need one of the search results, press the X and it goes away. Your search results are customized for your needs or what your students need.
CONS: This product is still a baby, so there will be mistakes and search results that just don’t fit until the product matures.
OVERALL EVALUATION: Google Squared changes the way students find information on the Web, and the ability to customize the search makes it a good tool for research and developing information literacy.
Source of Information : Tech and Learning February 2010
Sunday, April 4, 2010
BACK-OFFICE BUSINESS: HOW SCHOOLS GET IT DONE
Wireless overhaul yields improved reliability, simplicity
PROBLEM: Harrisonburg City Public Schools, located in Virginia’s Shenandoah Valley, used Netgear and Apple wireless access points, but maintaining wireless coverage was a challenge.
SOLUTION: The school chose Aerohive wireless solutions and divided the wireless LAN into separate networks. One provides secure faculty access to the student-management system; another is for a library cataloging system that enables wireless scanning to check books in and out; and a third is for guest access.
New England schools improve literacy while kids have fun
PROBLEM: How to build strong foundational reading skills in nearly 1,700 schools and learningresource centers across Connecticut, Maine, Massachusetts, New Hampshire, Rhode Island, and Vermont.
SOLUTION: These schools selected the Lexia Reading program, which offers more than 900 activities for reading-skills development. Margaret Adams, director of Balanced Literacy and Title I at Malden Public Schools in Massachusetts, particularly likes the small-group instruction and Response to Intervention. Pamela Rosenberg of the Bridgeport (CT) Public Schools said they’ve been so pleased with the results, the schools expanded their program to include students in grades one through three district-wide.
Ohio schools add wind energy, save thousands a year
PROBLEM: Perkins Local Schools in Sandusky, Ohio, contended with an outdated and inefficient infrastructure. Along with improving it, the district wanted to reduce its dependence on traditional energy sources.
SOLUTION: Perkins turned to energy-services provider Honeywell to better understand the renewable landscape. The company helped the district analyze several options by using its Renewable Energy Scorecard. The district then worked from a financial forecast based on tax implications, rebates, subsidies, and other incentives for renewables, such as solar, wind, biomass, and geothermal. The resulting project is expected to generate operational and maintenance savings of around $56,000 a year without a loss of maintenance personnel.
California educators honored for communication excellence
PROBLEM: How to merge four north Sacramento area school districts into
a new district of 27,000 students in 54 schools, covering 120 square miles.
SOLUTION: The administrators created a communication model that included measurable results, face-toface communication, and a vision for expanding ways to communicate. They showed parents and communities the benefits of their vision for the future of the schools and for their children’s education. This effort led the Twin Rivers Unified School District to be named the 2010 recipient of the Leadership Through Communication Award from the AASA.
Source of Information : Tech and Learning February 2010
PROBLEM: Harrisonburg City Public Schools, located in Virginia’s Shenandoah Valley, used Netgear and Apple wireless access points, but maintaining wireless coverage was a challenge.
SOLUTION: The school chose Aerohive wireless solutions and divided the wireless LAN into separate networks. One provides secure faculty access to the student-management system; another is for a library cataloging system that enables wireless scanning to check books in and out; and a third is for guest access.
New England schools improve literacy while kids have fun
PROBLEM: How to build strong foundational reading skills in nearly 1,700 schools and learningresource centers across Connecticut, Maine, Massachusetts, New Hampshire, Rhode Island, and Vermont.
SOLUTION: These schools selected the Lexia Reading program, which offers more than 900 activities for reading-skills development. Margaret Adams, director of Balanced Literacy and Title I at Malden Public Schools in Massachusetts, particularly likes the small-group instruction and Response to Intervention. Pamela Rosenberg of the Bridgeport (CT) Public Schools said they’ve been so pleased with the results, the schools expanded their program to include students in grades one through three district-wide.
Ohio schools add wind energy, save thousands a year
PROBLEM: Perkins Local Schools in Sandusky, Ohio, contended with an outdated and inefficient infrastructure. Along with improving it, the district wanted to reduce its dependence on traditional energy sources.
SOLUTION: Perkins turned to energy-services provider Honeywell to better understand the renewable landscape. The company helped the district analyze several options by using its Renewable Energy Scorecard. The district then worked from a financial forecast based on tax implications, rebates, subsidies, and other incentives for renewables, such as solar, wind, biomass, and geothermal. The resulting project is expected to generate operational and maintenance savings of around $56,000 a year without a loss of maintenance personnel.
California educators honored for communication excellence
PROBLEM: How to merge four north Sacramento area school districts into
a new district of 27,000 students in 54 schools, covering 120 square miles.
SOLUTION: The administrators created a communication model that included measurable results, face-toface communication, and a vision for expanding ways to communicate. They showed parents and communities the benefits of their vision for the future of the schools and for their children’s education. This effort led the Twin Rivers Unified School District to be named the 2010 recipient of the Leadership Through Communication Award from the AASA.
Source of Information : Tech and Learning February 2010
Saturday, April 3, 2010
8 FREE AND EASY WAYS TO BEGIN EDUCATING INNOVATIVELY
The following tools are all free and easy to use. This means there’s no cost, nothing to download, no CDs, no manuals, and no training. Additionally, for students there is no email required, no registration, and no log in.
1 STUDENT RESPONSE SYSTEM: POLL EVERYWHERE
Poll Everywhere allows teachers to collect up to 32 responses per poll. Students can respond either by texting their answer to 99503, tweeting their answer to @poll, navigating to poll4.com on a smartphone, or simply clicking on their answer on the teacher’s online space i.e. blog, wiki, website.
2 WRITING-LEVEL TOOLS: READINGLEVEL CHECK IN GOOGLE DOCS
Google Docs provides three indicators of the reading level of the document you’re creating. They calculate the Flesch Reading Ease, the Flesch-Kincaid Grade Level, and the Automatic Readability Index.
3 READING-LEVEL TOOLS: LEXILE FIND A BOOK
This free tool allows users to type in any book and find the reading level of that book, or type in their reading level and interest and build a custom reading list for that subject.
4 INTERACTIVE-WHITEBOARD ALTERNATIVE: PROJECTOR ONLY
Use a laptop and projector to mimic the benefits of an interactive whiteboard.
5 VIDEO/AUDIO CONFERENCING: TINYCHAT
Tinychat is a free service that provides text-, audio-, and video-chat rooms. Users don’t need special software to join in, don’t need and email, and do not need to register. The teacher selects the url, provides it to students who can type it in and instantly enter the room.
6 ONLINE BULLETIN BOARD: WALLWISHER
Wallwisher allows you to leave virtual sticky notes in one place on the Web. Participants don’t need to register or join to participate. Unlike physical sticky notes, on Wallwisher, you can embed hyperlinks, pictures, and video.
7 SCREEN-CAPTURE RECORDING: SCREENJELLY
ScreenJelly is a free tool that enables you to record your screen activity with your voice, so you can spread it instantly by sharing a url, tweeting, or sharing on Facebook. You begin recording with one click of a mouse.
8 TALKING AVATARS: VOKI
Voki is a terrific tool that enables students to share a message using an animated avatar that talks created using either their writing or their own voice recorded right from their laptop or phone. Students design their avatar’s appearance, add their voice, and can
pop it into any web2.0 compatible site—Lisa Nielsen, The Innovative Educator http://TheInnovativeEducator.blogspot.com
Source of Information : Tech and Learning February 2010
1 STUDENT RESPONSE SYSTEM: POLL EVERYWHERE
Poll Everywhere allows teachers to collect up to 32 responses per poll. Students can respond either by texting their answer to 99503, tweeting their answer to @poll, navigating to poll4.com on a smartphone, or simply clicking on their answer on the teacher’s online space i.e. blog, wiki, website.
2 WRITING-LEVEL TOOLS: READINGLEVEL CHECK IN GOOGLE DOCS
Google Docs provides three indicators of the reading level of the document you’re creating. They calculate the Flesch Reading Ease, the Flesch-Kincaid Grade Level, and the Automatic Readability Index.
3 READING-LEVEL TOOLS: LEXILE FIND A BOOK
This free tool allows users to type in any book and find the reading level of that book, or type in their reading level and interest and build a custom reading list for that subject.
4 INTERACTIVE-WHITEBOARD ALTERNATIVE: PROJECTOR ONLY
Use a laptop and projector to mimic the benefits of an interactive whiteboard.
5 VIDEO/AUDIO CONFERENCING: TINYCHAT
Tinychat is a free service that provides text-, audio-, and video-chat rooms. Users don’t need special software to join in, don’t need and email, and do not need to register. The teacher selects the url, provides it to students who can type it in and instantly enter the room.
6 ONLINE BULLETIN BOARD: WALLWISHER
Wallwisher allows you to leave virtual sticky notes in one place on the Web. Participants don’t need to register or join to participate. Unlike physical sticky notes, on Wallwisher, you can embed hyperlinks, pictures, and video.
7 SCREEN-CAPTURE RECORDING: SCREENJELLY
ScreenJelly is a free tool that enables you to record your screen activity with your voice, so you can spread it instantly by sharing a url, tweeting, or sharing on Facebook. You begin recording with one click of a mouse.
8 TALKING AVATARS: VOKI
Voki is a terrific tool that enables students to share a message using an animated avatar that talks created using either their writing or their own voice recorded right from their laptop or phone. Students design their avatar’s appearance, add their voice, and can
pop it into any web2.0 compatible site—Lisa Nielsen, The Innovative Educator http://TheInnovativeEducator.blogspot.com
Source of Information : Tech and Learning February 2010
Friday, April 2, 2010
Web Tools for Enhancing Collaboration
Collaborate is one of the most often used terms in education, and there is no better way to collaborate than with 2.0 Web tools. Here are some favorites:
• DABBLEBOARD is a whiteboard that enables you to visualize, explore, and collaborate. Just draw as you would on a whiteboard and you can easily share your ideas.
• COSKETCH is another collaborative whiteboard program, and you don’t have to register or install anything. It works in all browsers, it’s real-time, and you can get an embed code for your drawing after you finish.
• STIXY lets you create an online bulletin board on which to collaborate with family, friends, and colleagues. You can share pictures, files, reminders, and notes using widgets whose sizes and colors you can change—and it’s free.
• GROU.PS lets you create your own social network. You can create your forum and your mailing list; share documents, files, and your agenda to organize events; have your own YouTube; and share links, bookmarks, and photos. You can have real-time chat, and you can let the users have subgroups. Free.
• NING is the one of the best sites for creating and joining new social networks that interest us.
• IMAGINATIONCUBED is a multiuser drawing tool. You can use a pen, stamps, shapes, lines, or type.
• If you are using Twitter, you may want to try GROUPTWEET. It lets you turn your Twitter account into a group communication tool where everyone in the group uses direct messaging. When a member gets a DM, GroupTweet turns it into a new tweet that all followers in the group can see.
• WALLWISHER is an online noticeboard maker. Use this tool to make announcements and keep notes. You can use links, pictures, music, video, and pages. You don’t have to register.
• PAGEFLAKES is a social personalized homepage that you can customize by using “flakes” of all your Web favorites. You can add Facebook, Twitter, Flickr, photos, music, videos, calendar, to-do list, message board, and RSS feed.
• WETOKU is an interview tool that automatically records interviews to play them back. You can embed it and share it with others.
• SPRINGNOTE is an online notebook for collaboration. You can write down your ideas, create to-do lists, schedule, and work together on projects. It also has an iPhone application.
• MEBEAM is a place where you can create your own chat room. You just type the name of the room and tell people to meet you there.
Source of Information : Tech and Learning February 2010
• DABBLEBOARD is a whiteboard that enables you to visualize, explore, and collaborate. Just draw as you would on a whiteboard and you can easily share your ideas.
• COSKETCH is another collaborative whiteboard program, and you don’t have to register or install anything. It works in all browsers, it’s real-time, and you can get an embed code for your drawing after you finish.
• STIXY lets you create an online bulletin board on which to collaborate with family, friends, and colleagues. You can share pictures, files, reminders, and notes using widgets whose sizes and colors you can change—and it’s free.
• GROU.PS lets you create your own social network. You can create your forum and your mailing list; share documents, files, and your agenda to organize events; have your own YouTube; and share links, bookmarks, and photos. You can have real-time chat, and you can let the users have subgroups. Free.
• NING is the one of the best sites for creating and joining new social networks that interest us.
• IMAGINATIONCUBED is a multiuser drawing tool. You can use a pen, stamps, shapes, lines, or type.
• If you are using Twitter, you may want to try GROUPTWEET. It lets you turn your Twitter account into a group communication tool where everyone in the group uses direct messaging. When a member gets a DM, GroupTweet turns it into a new tweet that all followers in the group can see.
• WALLWISHER is an online noticeboard maker. Use this tool to make announcements and keep notes. You can use links, pictures, music, video, and pages. You don’t have to register.
• PAGEFLAKES is a social personalized homepage that you can customize by using “flakes” of all your Web favorites. You can add Facebook, Twitter, Flickr, photos, music, videos, calendar, to-do list, message board, and RSS feed.
• WETOKU is an interview tool that automatically records interviews to play them back. You can embed it and share it with others.
• SPRINGNOTE is an online notebook for collaboration. You can write down your ideas, create to-do lists, schedule, and work together on projects. It also has an iPhone application.
• MEBEAM is a place where you can create your own chat room. You just type the name of the room and tell people to meet you there.
Source of Information : Tech and Learning February 2010
Thursday, April 1, 2010
Most Boards Include a Linux Distribution
Unless the selected processor doesn’t have the capability to run Linux, it ships with a Linux distribution in the box or one is available. (Early on in the embedded Linux lifeline, this wasn’t true, and getting Linux for a board involved a Quixotic search or custom engineering.) This principle holds true for COTS boards and prototyping boards for custom hardware. Linux vendors typically vie for information about their product to be included in the packing material for the board, in hopes it will boost sales or interest in their product.
The key is understanding what is packaged for the board. Some board vendors treat their Linux distribution as a check-off requirement, which is marketing speak for something that’s good enough to claim support but not adequate for project development. Other board vendors put a great deal of effort into delivering a Linux distribution that’s ready for development
Linux Distribution Inventory
Kernel
Sources must be supplied. Sometimes patches are included as well. Make sure you locate all of them and that the patches work.
GCC cross-compiler
Some kernels and root file system components require a certain version of GCC. Understand the requirements necessary to build the kernel and root file system.
C library
The kernel doesn’t require a C library, but the supporting programs, like the configuration system, do. Kernel building has few constraints; for packages in the root file system, anything is possible; but usually there are no special requirements.
Supported devices
Check out what’s on the board.
Supported file systems
Are any of these useful for the project? A file system not supported in the kernel doesn’t mean it’s unavailable, just that it isn’t in this build of the kernel.
Root file system format
How has the root file system been formatted?
Root file system contents
Are sources available? What packages have been supplied?
Source of Information : Pro Linux Embedded Systems
The key is understanding what is packaged for the board. Some board vendors treat their Linux distribution as a check-off requirement, which is marketing speak for something that’s good enough to claim support but not adequate for project development. Other board vendors put a great deal of effort into delivering a Linux distribution that’s ready for development
Linux Distribution Inventory
Kernel
Sources must be supplied. Sometimes patches are included as well. Make sure you locate all of them and that the patches work.
GCC cross-compiler
Some kernels and root file system components require a certain version of GCC. Understand the requirements necessary to build the kernel and root file system.
C library
The kernel doesn’t require a C library, but the supporting programs, like the configuration system, do. Kernel building has few constraints; for packages in the root file system, anything is possible; but usually there are no special requirements.
Supported devices
Check out what’s on the board.
Supported file systems
Are any of these useful for the project? A file system not supported in the kernel doesn’t mean it’s unavailable, just that it isn’t in this build of the kernel.
Root file system format
How has the root file system been formatted?
Root file system contents
Are sources available? What packages have been supplied?
Source of Information : Pro Linux Embedded Systems
Subscribe to:
Posts (Atom)