My NeTV stucks at firmware < 20 and doesn't auto-update

Bad news is firmware before 23 or so is looking for chumby.com.sg server, which has gone down permanently.
Good news is you can force it update to later firmware (31 or later) and bring back auto-update mechanism.

You’ll need Internet access on NeTV for this update, so first, please configure WiFi with the IR remote control or Android app.
Then follow the following steps:

• Enable SSH under Settings menu (still using IR remote control)
• Go into your NeTV with a SSH client (Windows users can use PuTTY, Mac/Linux users can use ssh from a terminal window)
  ssh 192.168.1.123    #substitue with your NeTV's IP address
• Change to temp folder
  cd /tmp
• Download new update script
  curl -o update.sh http://netv.bunnie-bar.com/updates/chumby-silvermoon-netv/update.sh
• Make the script executable
  chmod +x update.sh
• Execute it and wait… It may take as long as 15 minutes on a good Internet connection.
  ./update.sh

Here’s shorter version if you are a power user.

The overlay effect is done using chroma key compositing.
Any pixel color that is (240,0,240 or #F000F0) will be transparent & hence reveals the background video stream.

Start/stop

The executable file is located at /usr/bin/NeTVBrowser
In order to initialize supporting drivers & start it correctly, use the helper script
/etc/init.d/chumby-netvbrowser start
/etc/init.d/chumby-netvbrowser stop
/etc/init.d/chumby-netvbrowser restart

Setting URL

By default, tab 0 of the browser is pointing to http://localhost
In order to point the browser at a different URL, use:
NeTVBrowser SetUrl http://www.yoururl.com
Note:
files:// protocol is not supported
A keep-alive timer will kick in within 1 minute and switch it back to default URL. See “Keep-alive timer” section below

Multitab

The recommended way to keep a page on screen without losing the Control Panel is to use the browser’s multi-tab feature
NeTVBrowser Tab hideall #(hide all tabs except tab 0, will keep the tabs running)
NeTVBrowser Tab closeall #(destroy all tabs except tab 0)
NeTVBrowser Tab 1 http://www.yoururl.com
NeTVBrowser Tab 1 load http://www.yoururl.com
NeTVBrowser Tab 1 hide #(will keep the tab running)
NeTVBrowser Tab 1 show #(will not destroy other tabs)
NeTVBrowser Tab 1 close #(destroy the tab)
Where the ’1′ argument is the index of the tab. Maximum 10 tabs are supported (index 9).
Tab 0 is reserved for NeTV UI, can be changed but do keep in mind there’s a keep-alive timer.

Keep-alive timer

A keep-alive timer kicks in every 1 minute to check that tab 0 is alive & the modules are loaded correctly.
The timer essentially calls a JavaScript function fCheckAlive() and make sure that it returns ‘true’, otherwise it will reset tab 0 to default URL.
To turn off the keep-alive timer
NeTVBrowser KeepAlive off
If you are using custom UI on tab 0, it is recommended to take advantage of this keep-alive timer rather than shutting it off.
This is to make sure your UI doesn’t freeze and become useless.

Inject JavaScript

To call or inject JavaScript function from SSH console (remember to escape special characters):
NeTVBrowser JavaScript "console.log('hello console');"
A new JavaScript function can be injected as followed:
NeTVBrowser JavaScript "my_function();  function my_function() { console.log('hello console'); }"

Screen rotation

By default, NeTV displays in landscape mode.
It can be switched to inverted landscape, portrait and inverted portrait modes by the following command:
NeTVBrowser Rotate 0/90/180/270 #pick one of the values
When changing mode, a native browser resize event is triggered. JavaScript code can hook to this event to customize the behaviour.

Show debug traces & JavaScript output

By default, all console output from NeTVBrowser, including JavaScript print out, are muted.
To re-enable them, NeTVBrowser’s start up script needs to be modified.
mount -o remount,rw /
vi /etc/init.d/chumby-netvbrowser
Replace ”’NeTVBrowser -qws -nomouse > /dev/null 2>&1 &”’ with ”’NeTVBrowser -qws -nomouse &”’
mount -o remount,ro /

Simulate/Inject a keyboard event

A keyboard event can be triggered from console as followed:
NeTVBrowser Key valid_key_name
Some commonly used key names are: cpanel,widget,up,down,left,right,enter,center,esc,del,backspace,space & alphanumeric keys.
A full list of supported key names can be seen at the bottom of this [https://github.com/sutajiokousagi/chumby-netvbrowser/blob/master/mainwindow_common.cpp source file]
This was designed only for quick testing from console terminal. It is very efficient for injecting long text string.

Non-native keyboard input

By default, buttons on infra-red remote control are override converted to JavaScript function calls on the current tab.
To catch this event, implement a JavaScript function as below in the top level JavaScript document.

Example code is available in /usr/share/netvserver/docroot/js/NeTV.js -> fButtonPress function

Native keyboard input

Buttons on infra-red remote control are treated as native keyboard keys in NeTV’s Linux kernel (/dev/input/event1).
However, by default NeTVBrowser overrides key press events in order to handle key counting, key sequence/combo, page scrolling & delivered directly to HTML Control panel as a JavaScript function call.
Example: Hold the control panel button on IR remote for more than 3 seconds & release it will reload/reset the Control Panel.
In order to have the IR buttons events delivered directly to JavaScript as normal keyboard events, use:
NeTVBrowser Nativekb on
The JavaScript in the loaded HTML page will have to handle scrolling & counting of key presses manually.
The above mentioned reset functionality will be lost.
An example of JavaScript code for handling keyboard event (based on jQuery) is available in /usr/share/netvserver/docroot/html_config/js/index.js

Native mouse input

If an external mouse is connected to NeTV via USB extension board, NeTVBrowser will initialize its driver at start.
However, by default NeTVBrowser hides mouse cursor.
In order to show the mouse cursors, use:
NeTVBrowser MouseCursor on
NeTV UI was not design to work with mouse. Therefore clicking on the menu items has no effects.
The WiFi configuration was partially made mouse-compatible. To try, go to Setting -> Reconnect to WIFI and turn on mouse cursor.

• Plug NeTV into the USB port of your computer
• wait for NeTV to boot and register as an ethernet device.
  If this is the first time you’re plugging the device in, you’ll probably have to wait for the NeTV to boot, register as an ethernet device, and then reboot it. The reason is that there is a 10-second window where the startup script checks for a valid ethernet connection to decide if to turn on sshd or not. If you miss the window, even though netv is booted and connected via USB, sshd will not be on.
• ssh to 10.0.88.1 as root
• from here, you will need to do the following:

This should get your device onto the wifi network with the specified SSID and encryption mechanism.

Other example network_config templates:

Introduction

What is AMI Instance?

The Amazon AMI is a preconfigured machine image that can be used for developing on the chumby NeTV board. It comes with a copy of the chumby build system and source code, as well as a precompiled image suitable for burning directly onto an SD card.

The public AMI ID is ami-e68ff4b4 ami-c0b3f692 (v1.3 now points to github for source), and it is bound to the Asia-Pacific (Singapore) region. For instructions on how to start an AMI, please see Quickstarting OE for a step-by-step howto. Please note that in order to access the more advanced features such as buildbot and gitweb, you will need to also add port 80 to the security group.

Screenshots

Here are some screenshots of the NeTV AMI in action.

Getting started

To get started, log onto the instance as the “ubuntu” user. Then switch to building image for chumby-silvermoon-netv, and build the chumby-image:

Then, download the resulting ROM image by using your web browser to go to /output/ on your instance. For example, http://169.254.169.254/output/. Click on “images”, then on “chumby-silvermoon-netv”, then download “rom-chumby-silvermoon-netv-chumby-image.img.gz”.

Development Flows

The system comes configured to support several development flows, including command line and GUI-assisted flows.
Here are a couple of suggested flows:
”’Local editing and building”’
# ssh into the AMI
# edit code locally on the AMI
# initiate bitbake manually (e.g. bitbake chumby-image)
# (first time only) copy ROM image from server and dd onto a microSD card
# (successive builds, assuming network connectivity) use opkg update; opkg upgrade to grab the latest build and install on your local test machine

”’Remote editing and building”’
# check out git repo from the AMI using ssh (git clone ssh://ubuntu@instance-address:chumby-oe/meta-chumby/.git)
# edit code locally, and do a git push
# buildbot will pick up the push and within a few minutes automatically kick off a build, or you can use the UI on the webpage to manually start a build
# (first time only) navigate to the web directory on the server and copy the file locally, and burn to SD card
# (successive builds, assuming network connectivity) use opkg update; opkg upgrade to grab the latest build and install on your local test machine

Burning images to disk

To burn a ROM image to disk, you’ll first need to uncompress it. Usually you can just double-click on the .gz file. Once you have an uncompressed .img file, you’ll need to write it to a micro-SD card. Place the card into a USB reader, and insert the card into your computer.

The instructions for writing a .img file to an SD card is described in detail at the [https://help.ubuntu.com/community/Installation/FromImgFiles Ubuntu IMG-install page].

Once the card has been burned, insert it into the NeTV and turn it on. The
blue light should begin flashing, which indicates the FPGA firmware has been
loaded and the device is booting.

If the light doesn’t come on, then the image didn’t work. Possible causes are:
* Dirty contacts. The SD card is very sensitive to dirt and grease. Wipe off the contacts with a cloth and try the card again.
* Card not inserted correctly. The door should not be able to open on its own, even when the board is turned upside-down.
* ROM file not uncompressed. You must un-gzip the file before burning it.
* ROM file copied, not burned. You must burn the ROM file to the card, not copy it using e.g. Windows file explorer. If you can add files to the SD card in either Windows or Mac, then the card has not been burned properly.

Git

All chumby code used in this AMI instance comes from git. Because git is a distributed version control system, you can make changes and commit code, and still track the main trunk. This allows you to make changes and submit patches without having to set up your own server.

Basics

Before you check in any changes, you should set up your git username and email address. This allows you to mail patches around and still be given credit for fixes and feature additions. Run these commands inside the instance to personalize your settings:

To update a repository from the remote copy, run “git pull”. To mark files as having changed, or to add new files to git, run “git add [filename]“. To remove files, run “git rm [filename]“. To commit a series of added/changed/removed files, run “git commit”.

chumby-oe

There are three primary git repositories you will encounter while building images:
* chumby-oe – Contains setup scripts and the bitbake program
* openembedded – A mirror of the openembedded monolithic project
* meta-chumby – An overlay on top of openembedded that implements chumby code

Most development will take place under meta-chumby. You can sync your copy of the code by running “git pull” in each
of the directories.

Local mirrors

In order to make development easier, local mirrors of the kernel and u-boot have been made. They are located under ~/git/. New recipes have been added under meta-chumby that cause locally-built images to look in this directory for source code rather than going to chumby’s git repo.

You can make and commit changes in the mirrored repos and still pull changes from master. To submit a patch, use the “git format-patch” command.

Cgit

You can use the web-based git interface by going to /cgit/cgit.cgi on your EC2 instance’s web server. Checked-in changes are automatically displayed here. CGit is configured by editing the file /etc/cgitrc. Pages are cached in the directory /var/cache/cgit/, so if you update the config file you’ll need to clear the cache by removing the contents of /var/cache/cgit/.

Openembedded

Overview

The build system is based on openembedded, which uses the **bitbake** tool to assemble packages that are described by **recipes**. The bitbake command uses recipes to determine how to compile and package software, as well as to build bootable images for various devices.

A recipe is a series of steps that are executed in order to fetch source, unpack source, configure, build, and install the package(s), and then distribute the resulting packages. Recipes are defined in files that end in .bb, and are located in subdirectories under the recipes/ directory. Each step is a shell script by default, unless explicitly defined as a python step.

Many steps are inherited automatically from chumby-oe/openembedded/classes/base.bbclass, and you can override any steps by explicitly specifying them in your recipe file. You can inherit additional classes such as “qt4e” that will give you a pre-defined set of steps to draw from by adding “inherit qt4e” at the top of your recipe.

A package name (PN) is defined as the portion of a .bb filename before the underscore (_). A package version (PV) is the portion after the underscore. Thus, the PN for meta-chumby/recipes/netv-utils_0.bb is “netv-utils”, and the PV is 0. Unless told otherwise, bitbake will always use the package with the highest PV.

meta-chumby Overlay

There is a chumby “overlay” on top of a minimally-modified openembedded tree that adds chumby-specific machine definitions and recipes. If there are identically-named packages in both openembedded and meta-chumby, the package from meta-chumby will take precedence. Additionally, the configuration file inside meta-chumby inherits the “amend” bbclass, which allows for meta-chumby to provide additional steps and patches to recipes in the openembedded directory.

In this way, meta-chumby modifies openembedded, allowing for it to work better with chumby devices. If possible, avoid modifying files in the openembedded directory, and instead modify/add files to the meta-chumby directory.

Packages

A package is a combination of files and meta-data such as platform, dependencies, and install scripts. A single recipe will usually build four packages, but can end up building any number of packages. The four packages that will get built by default are:

* Application package. Has the same package name (PN) as the recipe.
* Debug package. Named PN-dbg. Contains debugging symbols for the binaries in the application package.
* Development package. Named PN-dev. Usually empty. Contains static libraries and headers useful for compilers.
* Documentation package. Named PN-doc. Contains manpages, info pages, and any other documentation.

To install a package, copy it over to the device through scp, then install it:

To remove a package, specify only the PN:

Working with software

A hello-world Package

There is a “hello world” recipe that creates a package containing an executable that simply prints the canonical “Hello, world!” message. It is located under meta-chumby/recipes/examples/hello-world_1.0.bb, and the source code is located under meta-chumby/recipes/examples/hello-world/.

To build the hello-world program, run “bitbake hello-world”. This will cause openembedded to parse the .bb file, run each step in turn, and then generate a package. You can find the resulting .ipk in ~/chumby-oe/output-angstrom-.9/deploy/eglibc/ipk/armv5te/ and it will be called hello-world_1.0-r1.9_armv5te.ipk.

If you run “bitbake hello-world” again, nothing will happen. This is because the package has been marked as “already built”. You have two options for forcing the package to get rebuilt:

* Run “bitbake -c clean hello-world; bitbake hello-world” to clean the package, then rebuild it
* Edit hello_world-1.0.bb and change the PR variable from “r1″ to “r2″

The last option is called “bumping the PR”, and is required if you share your changes. If you change any source the package relies on, or if you modify the recipe in any way, you should bump the PR prior to checking the changes in. That way, anyone who checks out your code will be forced to rebuild the package, and will get the new version.

Modifying the kernel

In order to make kernel development easier, a local mirror of the chumby kernel has been made. You can view and edit the source in the ~/ubuntu/git/linux-2.6.28-silvermoon directory. Since it is a read-only git repo, you can pull from trunk and commit changes, but not push patches. Any patches you make can be submitted upstream using the “git format-patch” command, and then emailing the resulting files.

The kernel configuration used in bitbake is stored in ~/chumby-oe/meta-chumby/recipes/linux/linux-silvermoon-netv/defconfig. You will need to copy this before making any kernel changes.

You have several options for building the test kernel. Perhaps the easiest method is to use the build scripts from bitbake. You can manually run the do_compile script:

The kernel itself will get compiled and the output image will be placed in arch/arm/boot/zImage. Copy this image to your running NeTV board and install it there by connecting through SSH and running:

You will need to reboot to try out the new kernel.

When you are satisfied with your changes, add them to git:

Bump the PR in ~/chumby-oe/meta-chumby/recipes/linux/linux-silvermoon-netv_2.6.28.local.bb and rebuild the kernel package:

Changing kernel config

You will first need to install ncurses-dev, in order to be able to use the graphical kernel configuration screen:

The kernel config used in the chumby distribution is located under meta-chumby. To restore the default kernel config, copy it from meta-chumby to the kernel src directory:

To change kernel config, change to ~/git/linux-2.6.28-silvermoon/src/ and run “make ARCH=arm menuconfig”. Make any changes you like. When you’re satisfied with your changes, save and exit the editor. To add the changes to the build system, run the following:

If you get errors such as “ERROR: “kmalloc_caches” [sound/usb/snd-usb-lib.ko] undefined!”, then you will need to re-run the do_compile step before running the do_compile_kernelmodules step.

Modifying the bootloader

The bootloader can be modified using the same process as the kernel. Like the kernel, an additional bootloader recipe has been added that takes precedence over the stock u-boot recipe, and pulls from the git repository located at /home/ubuntu/git/u-boot-2009.07-silvermoon/. When you want to make changes and want to force a rebuild, bump the PR in chumby-oe/meta-chumby/recipes/u-boot/u-boot-silvermoon_local.bb and rebuild the bootloader:

Buildbot

There is a copy of buildbot running on the system. Any time you check in changes to meta-chumby, openembedded, or chumby-oe, a five-minute timer starts. If no more changes are checked in after five minutes, it automatically runs “bitbake chumby-image” to generate a new compressed rom image.

There is a second buildbot factory called netv-trunk, which automatically pulls the latest code from chumby’s master git repository. This is separate from any development you do on the EC2 instance, and exists to demonstrate the ability to build a stock chumby firmware. It will never automatically trigger.

oth builders have openembedded trees separate from ~/chumby-oe/. They reside in ~/buildslave/(netv|netv-trunk)/work/ and have their own output directories. You should avoid doing developent in these directories unless you’re trying to troubleshoot build system failures.

Accessing

You can monitor build progress by going to /waterfall on your build machine’s web server. When the build has completed, you can download the automatically-built images by navigating to /output-buildbot/ on the web server. This is separate from builds you make on the command line, which can be accessed by going to /output/.

To start a build, navigate to /builders/netv and click “Force Build”.

Modifying

Nearly all of the configuration takes place on the build master. The configuration file is stored in ~/buildbot/master.cfg. It is a python script. It is documented at the [http://buildbot.net/buildbot/docs/0.8.4p2/full.html buildbot documentation] page.

Whenever you change the configuration file, be sure run a syntax check by running:

To apply the config, restart buildbot:

The patch

A patch was made to the buildbot source in order to support multiple git repos. Without the patch, the automated builder would pull the wrong branch. It is unclear whether this change will be accepted to buildbot trunk, but be aware of it if you decide to upgrade the installed copy of buildbot:

Advanced

Creating images

An image recipe is defined as a recipe that inherits from image.bbclass. When built, an image will create a burnable ROM file that you can uncompress and write directly to an SD card. The starter image recipe is located in ~/chumby-oe/meta-chumby/recipes/images/chumby-starter-image.bb. A full chumby image, including the control panel and browser code, may be found in ~/chumby-oe/meta-chumby/recipes/images/chumby-image.bb. Other images can be found under ~/chumby-ie/openembedded/recipes/images/. Some of these image recipes won’t build due to missing dependencies such as OpenGL acceleration, which aren’t available on this particular platform.

To create your own image, copy “chumby-starter-image.bb” to another file, say “my-starter-image.bb”. Then, add files to the “IMAGE_INSTALL” and the “DEPENDS” variables. If you don’t add the package name to DEPENDS, then it might not get built. On the other hand, if you don’t add the package to IMAGE_INSTALL, then it won’t get included in the image.

Package repositories

When you build an image, bitbake looks at the environment variable “FEED_DEPLOYDIR_BASE_URI”. If set, it instructs the resulting image to look to that URL to find packages. If not, it will look up your hostname during the buld process by consulting http://ifconfig.me/host, and set the URL to “http://hostname/${FEED_DEPLOYDIR_PATH}”. If FEED_DEPLOYDIR_PATH is not defined, it defaults to /build/localhost/LATEST. The setup-chumby.sh sets it to /output/ipk/, so the defaults should be okay.

The NeTV device will consult this URL if it needs to install packages. To install packages, mount the root filesystem as read-write, update the list of packages, and install the package. For example, to install “hello-world”, run:

The opkg command will examine the list of dependencies and install any required packages.

Running programs at startup

The system uses a Sys-V startup style. That means scripts are placed under /etc/init.d/ that accept “start”, “stop”, and “restart” arguments. The system boots and runs every script in /etc/rc5.d/ alphabetically, and allows you to log on only after all the scripts have run.

There is an example recipe located in meta-chumby/recipes/examples/ called init_example-1.0.bb that uses the update-rc.d class to install a startup/shutdown script. It installs a simple daemon that basically does nothing but stay running.

Build the package by running “bitbake init-example”, and then install it on your device. As part of the package installation, the package will be added to /etc/rc5.d/ and the startup script will be called as “/etc/init.d/init-example-script start”. When the system starts up in the future, the script will be called automatically.

If you remove the package, opkg will call “/etc/init.d/init-example-script stop” immediately prior to removing the package. If you bump the package’s PR, and rebuild it, and then reinstall it, opkg will call “/etc/init.d/init-example-script restart”.

Postinstall scripts

Packages can run scripts after being installed. For example, this is used by the bootloader recipe to load a new copy of the bootloader to the config block when it is installed.

The basic template of a postinstall script is:

The postinst script will get run as part of the do_rootfs when you bitbake an image. If the script fails, or if you copy the package directly to the device, it will be run when it’s installed. In order to force a package to get run on the device and not during do_rootfs, add this to the top of your postinst script:

Debugging binary programs

All packages are built with debugging symbols included, all of which are stripped as part of the do_package step. Each binary in your package will have its symbols placed in a -dbg package. For example, the “regutil” recipe creates a regutil package, as well as a regutil-dbg package.

In order to use these symbols, you must first install the “gdb” package. Either add gdb to a custom image, or run “mount -oremount,rw /; opkg install gdb”. If you try to install regutil-dbg, it will try to pull in all of the symbols for eglibc, so install the debug symbols package by running “opkg install -nodeps regutil-dbg”.

You can now launch regutil under gdb and step code by typing “gdb regutil”. Alternately, you can attach to a running instance of regutil by figuring out its process id and running “gdb regutil “. When you end a debugging session attached this way, the program will continue running.

Background

Amazon offers pay-as-you-use cloud servers. You can attach disks to virtual machines just like you would a physical machine. Disk images can be shared between users, and they are identified by a code known as an “AMI” (Amazon Machine Image).

Chumby has pre-built an OE image, so that all of the packages are resident and built, thus allowing you to get started on developing your application right away, without having to spend hours configuring and downloading the source code for the entire universe. You can use these AMIs as a starting point for development; and if you mess up, you can always restart the instance from a fresh image again (but back up your changes before you do that!).

Amazon offers several tiers of machines, with varying prices (http://aws.amazon.com/ec2/pricing/). We recommend using a “medium high-CPU” or “small” instance type, which cost $0.17 and $0.085 per hour, respectively (pricing as of April 2011). Building is a very CPU and memory-intensive task, and on a “medium high-CPU” instance, a full build from clean takes 6 hours to complete.

Amazon also offers a free “micro” tier, but there are a number of restrictions on it, including a very tight 600 MB RAM limit, and a 10 GB EBS disk limit. Open embedded barely fits in a 10GB EBS volume, and in fact will not build from clean in 600 MB of RAM. However, we offer the pre-built image for micro tiers for users who just want to evaluate the solution to see if this is something they want to pay for. On a micro tier you can build a couple small packages and re-create images, sufficient for a quick hack or evaluation, but we do not recommend doing serious development on a micro instance.

”’Note”’: “free” micro images have limits on the amount of disk operations and bandwidth you can use before you are automatically charged, and there is no warning for when billing starts. On the other hand, most charges are on the order of pennies per quanta, so you are unlikely to run up a big bill during evaluation.

If you want to build your own OE image entirely from scratch, please see Building OpenEmbedded for instructions on how to do that.

”Warning”: something that is not obvious is that if you use an “instance” store (/mnt by default), all data on that disk is lost when you reboot the instance. Instance stores are fast and free for access, but ephemeral and unreliable. EBS, which is the mechanism we use to distribute the OE image (mounted on “/” in our instance), is a reliable, permanent medium that is slower, archiveable and costs money to access, but at least you don’t lose the data when you reboot.

AMI numbers

The AMI for an EBS image with 30GB of space (enough to build a large number of packages, but not eligible for the free tier) is ”’ami-840871d6”’.

The AMI for an EBS image with 10GB of space (eligible for free tier but not a lot of space to build) is ”’ami-ee176ebc”’. NOTE: AWS has notified us that we needed to remove the SSH keys on the image to prevent a security breach, so a new AMI should be used: ”’ami-062c5454”’.

The AMI for an EBS image with 50GB and a very complete, pre-built NeTV image with buildbot and gitweb pre-installed is ”’ami-c0b3f692”’. We strongly recommend using at least a small instance, if not a medium-sized high-CPU instance, otherwise large builds can take forever.

”’Note”’: these AMI numbers are available only in the Singapore availability zone. It is possible to copy the AMI to any availability zone, you do so by creating a snapshot of the image and then creating a new volume in your zone.

How to create an instance

First, register for the Amazon EC2 service. The process is fairly self-explanatory, and they do require a credit card to register. I believe you can even link this to an existing consumer/personal Amazon account, but we haven’t tested this.

You will be asked to make a key pair for yourself, certificates, and so forth; save them, as you will need the key pair to log into your instance.

Once you are approved for an account, you will see a console similar to the following:

Set security groups

Before moving forward, click on Security Groups and enable ssh. If you are using the NeTV pre-built image, you will also want to enable HTTP (port 80) as well, to access buildbot and gitweb.

Launching an instance

Now, click on Launch Instance, and do the following:

* Click on community AMIs and enter the AMI number. Note that it can take up to a couple of minutes for the community AMI list to load, so be patient — the UI gives no hint of the loading process,
so it’s easy to think nothing was found.

* Select your instance type.

http://kosagi.com/oe/request_instance1.png

* Configure your instance details. I typically turn on termination protection, but here you can also map a new kernel to the device, if you need to do so. Sometimes I find I have to enter an explicit kernel ID, especially if after you start the instance nothing seems to happen. The default kernel ID is aki-13d5aa41 for both images, in case you need it.

* Give your instance a name.

* Pick your key pair. I can’t test this theory because I only have one account, but I believe the keypair you generated when you created your amazon account should be usable, and you don’t need the keypair that I made with the instance.

* Pick your security group — default should be okay (assuming you enabled ssh access; your “new” account has all access shut off)

* Launch the instance!

* Go back to the dashboard, and wait until the instance is running. Right click on the instance, and select connect. It will give you detailed instructions on how to connect. Note that the DNS mapping of your instance changes every time you restart it, but you can use elastic IP to make it fixed (at a charge!).

* Finally, log in with the username “ubuntu”. No password is needed, since you are already validated through the key pair. “ubuntu” has sudo privileges as well, so protect your keypair!

Once you are logged in, there is a readme.txt that will help guide you through the rest.

Hardware

Placeholder.

Software

All operations on motor board can be controlled via console terminal or various HTTP API.

From console:

Load motor firmware

Motor firmware needs to be first loaded to FPGA to enable motor board features.
To check if motor firmware is currently loaded.
mot_ctl V
If a single number is returned, eg. 139, it means the motor firmware is currently loaded. Otherwise, a long string as below is returned.

Perform just that to load motor firmware to FPGA.

HTTP API

A demo page showing all capabilities of the motor board is available at http://10.0.88.1/html_motor/
It is recommended to try this page from a computer as the UI is heavily implemented with jQueryUI.
Most features are implemented with NeCommand HTTP API calling mot_ctl command above.
However, some features such as the sliders controlling motor speed & PWM frequency are implemented using Motor HTTP API for better efficiency.

JavaScript library

All motor board features are encapsulated in a single stand_alone JS file at http://10.0.88.1/html_motor/js/utils_motor.js or /usr/share/netvserver/docroot/html_motor/js/utils_motor.js
It is self-explainatory through comments.
Feel free to include or copy this file to your project folder if you are developing your own UI for motor board.

Android app is available for free in Android Market
iOS app is available for free in AppStore

Full source code is posted on github in the following respositories
http://github.com/sutajiokousagi/netv-android
http://github.com/sutajiokousagi/netv-ios

Both platforms uses a combination of HTTP & UDP API.

The only significant new feature added in this push is iOS foundation API support.

Overview

OpenEmbedded[http://www.openembedded.org/index.php/Main_Page] is a build environment that contains a large number of packages. It’s possible to use OpenEmbedded to build a bootable image for certain chumby devices, such as the Falconwing-series of devices. These instructions assume you’re using Ubuntu 10.04 LTE, though they can be adapted to work on different platforms.

Re-imaging a device requires access to the internal micro-SD port. You will also need a USB micro-SD reader of some sort. These can be obtained very cheaply, and sometimes can be found bundled with micro-SD media.

These instructions assume you’re running on a Falconwing platform, such as the Hacker Board or a chumby One. If you’re using a Silvermoon-based platform such as Infocast 8 or chumby 8, replace all instances of “falconwing” with “silvermoon”.

Quickstart

Building OE can take several hours, since it pulls down the source for the entire world and builds every piece from scratch; the initial build configuration is also a bit finicky at times.

In order to facilitate rapid evaluation and development, you can launch one of our public, pre-built Amazon EC2 cloud instance images. Please see [[quickstarting OE]] for directions on how to do this.

Setting up the Environment

This assumes you’re using Ubuntu 10.04 LTE, and also tested on Ubuntu 11.10 64-bit desktop

• Install prerequisites
  sudo aptitude install sed wget cvs subversion git-core coreutils unzip texi2html texinfo libtool docbook-utils gawk python-pysqlite2 diffstat help2man make gcc build-essential g++ desktop-file-utils chrpath libxml2-utils xmlto screen python-ply libxml2-utils xsltproc libssl-dev python-progressbar
• Make /bin/sh not be part of dash
  sudo dpkg-reconfigure dash # Select "No" at the prompt
• Fix mmap_min_addr (required for qemu to run, generating libc keymap files, etc. has a potential security risk associated with this)
  sudo sh -c 'echo 0 > /proc/sys/vm/mmap_min_addr'
sudo sh -c 'echo "vm.mmap_min_addr = 0" >> /etc/sysctl.conf'
• Download OpenEmbedded
  cd
git clone git://github.com/sutajiokousagi/chumby-oe.git
cd chumby-oe
git clone git://github.com/sutajiokousagi/openembedded.git
git clone git://github.com/sutajiokousagi/meta-chumby.git

If desired, see Advanced OpenEmbedded.

Building with OpenEmbedded

Every time you log onto your build system, you must set up the environment. There is a command called “setup-chumby.sh” that will do this for you. You must source the command and not run it. If you’ve installed openembedded to a path other than ~/chumby-oe/ you must edit the command and change the variable TOPDIR.
source setup-chumby.sh # Select your platform at the prompt

Once setup, you use the bitbake command to build packages and images. Valid image files can be found in openembedded/recipes/images/and meta-chumby/recipes/images, and a full build from scratch can take ten hours or more. Building individual recipes is much quicker.
bitbake chumby-starter-image # As an example, build chumby-starter-image

”Need to add information here on how to roll back to a buildable snap-shot as it seems that packages are often checked into the git repository without validating this build process.”

Writing images to disk

Built images go in output-angstrom-.9/deploy/eglibc/images/. Full, bootable ROM images are named rom-chumby-MACHINE-IMAGENAME.img. Other interesting files, such as the bootloader, boot shell, kernel, and boot graphics are also present in this directory.

To write a ROM file to disk, use dd, or on Windows use win32-image-writer. If you’re working on a remote system, use SCP or SFTP to download the image file locally. Then write the file out to an SD card:

Linux

• Determine what drive letter your SD card is. After inserting the card, run “dmesg” and note the drive name. For example, it might be “sdb” or “sdc” depending on how many hard drives your system has.
• Unmount the drives

for i in $(ls -1 /dev/sdb*); do sudo umount $i; done

• Write the ROM image out
  sudo dd if=rom-chumby-silvermoon-chumby-starter-image.img of=/dev/sdX bs=8M

Windows

• Download win32-image-writer from https://launchpad.net/win32-image-writer

An example of a ROM image may be downloaded from http://files.chumby.com/hacks/rom-chumby-falconwing-chumby-starter-image.img.gz. Un-gzip this file and write it to an SD card, then insert the card in a Falconwing-based device. It should boot, and eventually bring up a prompt on the serial console.