## Step 1 - Add the backports repository
-Ubuntu Hardy users need to activate the hardy-backports repository to use our
-`cp210x-module-dkms` package. Ubuntu Karmic users can skip this step. Note,
-you can also activate hardy-backports from the GUI.
+Ubuntu Hardy users need to activate the hardy-backports repository, as our
+`cp210x-module-dkms` package requires a newer dkms than is available otherwise.
+Ubuntu Karmic users can skip this step. You can also activate hardy-backports
+from the GUI.
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
cat <<+EOF+ | sudo tee -a /etc/apt/sources.list
deb http://us.archive.ubuntu.com/ubuntu hardy-backports main restricted universe multiverse
+EOF+
-## Step 2 - Adding the TMI repository to sources.list.d
+## Step 2 - Adding the TMI repository to the sources list
cat <<+EOF+ | sudo tee /etc/apt/sources.list.d/tmi.list
# TMI repository
## Step 2 - Adding the TMI package key
-When you issued `apt-get update` above, you saw a key warning. We solve this
-by installing a package from the TMI repository that contains our packaging
-key.
+When you issued `apt-get update` above, you saw a key warning. Resolve future
+key related warning messages by installing `tmi-keyring`.
sudo apt-get install --yes --allow-unauthenticated tmi-keyring
and look for the following two lines, ensuring your output matches that below:
pub 1024D/E9BE0373 2009-12-08
- uid TMI Packages <pkgs@titaniummirror.com>
+ uid TMI Packages <EMAILADDR>
+
+The email address above is 'com dot titaniummirror at pkgs', in reverse.
## Step 3 - Install packages
You can now install packages from the TMI repository. For example:
-* Install our [[cp210x]] driver: `sudo apt-get install cp210x-module-dkms`
-
* Install our [[tinyos]] development suite: `sudo apt-get install tinyos`
+
+* Install our [[cp210x]] driver: `sudo apt-get install cp210x-module-dkms`
[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge,
the [cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx).
-For windows platforms, Silicon Labs offers manufacturing support, in the form
-of a DLL and a small utility, to set the various USB descriptor fields, port
-configurations, etc. They also offer a DLL and example programs showing how
-to manipulate the GPIO pins available on the cp2103 part.
+For windows platforms, Silicon Labs offers manufacturing support for setting
+the various USB descriptor fields, port configurations, etc. They also offer a
+DLL and example programs showing how to manipulate the GPIO pins available on
+the cp2103 part.
-With approval from Silicon Labs, TMI has modified their reference Linux driver
-to support all of the features their Windows DLLs and utilities provide. This
-is accomplished via extended ioctl() calls from the kernel cp210x driver, and
-various utilities and sample code. This code is really invaluable for those
-working on hardware device designs using the cp2103. The code is released
+With support from Silicon Labs, TMI has modified their GPLv2 licensed reference
+Linux driver to support all of the features their Windows DLLs and utilities
+provide. This is accomplished via extended ioctl() calls from the kernel
+cp210x driver, and various utilities and sample code. This code is invaluable
+for those working on hardware designs using the cp2103. The code is released
under the GPLv2.
-TMI sent the modified code back to Silicon Labs, who supposedly had someone
-in-house (or contracted) who regularly works with the maintainer of the cp210x
-(formerly cp2101) driver in the mainline Linux kernel. That was over a year
-ago, and the code hasn't shown up. We will be working with the maintainer
-directly to get this code available. In the mean time, it is available
-[as source](http://repo/gitweb/?p=cp210x.git;a=summary) and from our
-[[aptrepo]]. The `cp210x-module-dkms` package in the APT repository has been
-tested on Ubuntu Hardy and Karmic systems with both 32 and 64 bit x86
-(Intel/AMD) processors.
+TMI completed these driver changes of a year ago and has since been maintaining
+it. Silicon Labs was to push these changes through to the mainline kernel, but
+this clearly has not happened yet. TMI will be working directly with the kernel
+cp210x maintainer to investigate incorporating our changes. Meanwhile, TMI
+will continue to maintain its branch of the cp210x driver. The
+`cp210x-module-dkms` package in the APT repository has been tested on Ubuntu
+Hardy and Karmic systems with both 32 and 64 bit x86 (Intel/AMD) processors.
TMI has developed a fault tolerant internetworking platform composed of a set
of proprietary cluster, event and web management applications running atop a
GNU/Linux open source platform core. Essentially, the core represents a
-customized Linux distribution geared specifically for network appliances. TMI's
-proprietary code does not link with any GPL components of the core. Some
-minor changes have been made to the core components. Those changes are
-available [here](http://www.titaniummirror.com/gpl).
+customized Linux distribution geared specifically for network appliances. The
+proprietary code developed by TMI does not link with any GPL components of the
+core and honors the terms of the license. Some minor changes have been made
+to the core components. Those changes are available
+[here](http://www.titaniummirror.com/gpl).
Over time, TMI is starting to collect a number of small utilities for git.
These are available from our [git-utils](TBD) repository. Each utility has
-a man page describing its operation, so we'll only highlight the basics here.
+a man page describing its operation.
* git-empty-branch. Create an empty branch in a local git repository.
-* git-local. Store local branches temporarily in a shared git repository,
- probably hosted on a server used by the local development team. git-local
- offers upload, download, remove and list operations.
+* git-local. Store local branches in a shared git repository under a private
+ namespace. git-local provides upload, download, remove and list operations.
+ We use this tool to backup up local commits not yet suitable for pushing into
+ a local shared branch.
-* git-publish-branch. A shell version of a ruby script created by William
+* git-publish-branch. A shell version of the ruby script created by William
Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org).
- This has been a locally popular utility, and we did not want to see ruby
- effectively become yet another pre-requisite for git.
+ We did not want to have to install ruby just for this one little utility.
# Introduction
[Titanium Mirror, Inc.](http://www.titaniummirror.com) (TMI) is a successful
-small business in part because we have can leverage the development work of
-other talented professionals who have opted to release the product of their
-labors as Open Source Software (OSS). Over time, we have made our own changes
-to support our business and customers. We publish our work to this website in
-case others find our contributions useful.
-
-Of course, we make an effort to contribute patches to the relevant upstream
-maintainers. But it takes time for patches to migrate upstream, and there is
-no guarantee that something we find useful is general enough to be incorporated
-into an upstream project. For these reasons, we publish this website.
+small business in part because we can leverage the development work of other
+talented professionals who have opted to release the fruits of their labors as
+Open Source Software (OSS). Over time, we have made our own changes to support
+our business and customers. On this website, we publish our work in case
+others find our contributions useful.
# The Projects
Select a project to browse from the Navigation panel on the left.
+
+# News
+
+This website has not yet been released to the public.
[[aptrepo]].
TMI maintains an msp430 toolchain, including [[Ubuntu packages|aptrepo]], which
-work with newer members of the msp430 family, such as the popular
-MSP430F2618 part and is properly patched for use in
-[[TinyOS]] development. The official TinyOS distribution
-provides an older msp430 toolchain that does not support some of the newer
-msp430 parts. The msp430 toolchain is composed of: binutils, gnu compiler,
+works with newer members of the msp430 family including the popular MSP430F2x1x
+parts such as the MSP430F2618. This toolchain is properly patched for use in
+[[TinyOS]] development. At the time of this writing, the official TinyOS
+distribution uses an older msp430 toolchain that does not support these newer
+msp430 parts. The msp430 toolchain is composed of binutils, gnu compiler,
and libc.
Repositories: [oss-web](http://repo/gitweb/?p=oss-web.git;a=summary).
-This website is statically generated using [[Webber]] from the source code
-link above.
+This website is statically generated from the repository using [[Webber]].
[ovz](http://repo/gitweb/?p=ovz.git;a=tree),
[esata](http://repo/gitweb/?p=esata.git;a=tree).
-# OpenVZ
-
-TMI hosts its compute resources on DELL PE1800 servers configured as a cluster
-of [OpenVZ](http://www.openvz.org) Hardware Nodes (HN's), which host multiple
-OpenVZ Virtual Environments (VE's). Open VZ VE's are virtual machines
-virtualized at the operating system. The downside is that all VE's must be
-Linux instances capable of running on the OpenVZ kernel. The upside is that
-far more OS virtualized instances can reside on a given set of hardware
-compared to virtualizers like VMWare and Xen, which (para-)virtualize hardware.
-
-# BackupPC
-
-TMI uses [BackupPC](http://backuppc.sourceforge.net) for backup services across
-our company, including notebooks, workstations and servers (OpenVZ VE's). We
-are especially happy with BackupPC and how it is integrated into our server
-environment. Each HN is backed up as a separate host, but none of the data
-for any VE's it may be hosting. Each VE is also backed up, each as a separate
-host. Our HN's use LVM, and our add-on scripts allow for backup of any VE with
-minimal downtime. The scripts actually shut down the VE, create a snapshot of
-the HN volume on which the VE's filesystem is stored, restarts the VE,
-completes the over-the-net BackupPC backup operation, then removes the snapshot.
-By shutting down the VE, we ensure the integrity of the backup without
-requiring application specific tools like database hotcopy scripts. By using
-LVM, the VE downtime is typically less than 90 seconds. We backup every system
-every evening.
-
-# Off-site backups
-
-BackupPC maintains an on-disk archive of de-duplicated backups for all hosts.
-We maintain off-site backups by cloning the BackupPC archive to removable
-eSATA disks. For fastest recovery, we run BackupPC in a VE within our
-server infrastructure, so what we clone to an external disk is the entire
-BackupPC VE filesystem. We also keep a second partition on each removable
-disk, which contains, essentially, our HN operating system. eSATA connections
-make this backup operation very fast. And because a human must connect an
-external drive prior to the backup, that person can also provide the necessary
-key that allows the external drive filesystems to be cryptographically secure.
-We clone the BackupPC archive once per week, and rotate several external
-drives through the off-site location.
-
-# Recovery
-
-A word about recovery: great. This combination of technologies allows the
-recovery of any system, directory, or file stored within the BackupPC archive
-over the network. The data need not be recovered to the same machine from
-which it was backed up, nor does it need to be placed in the same directory.
-Restore operations are done via a web interface, and the interface does not
-have to be accessed from the machine to which the data are to be restored.
-
-Disaster recovery is also a big plus. The entire TMI infrastructure can be
-reconstructed onto new hardware from just one off-site archive drive.
-
-# TMI code
-
-TMI maintains a number of code repositories containing scripts, etc. for
-integrating OpenVZ and BackupPC. Please be aware that these are formulated
-somewhat specifically for our environment. But if you have a similar setup,
-they should be usable with minimal massaging. Someday, someone here will take
-the time to merge this stuff into a single repo and document it better.
-
-# BackupPC scripts
-
-The [BackupPC scripts repository](http://repo/gitweb/?p=backuppc.git;a=tree)
-includes:
-
-* BackupPC_ovz. Installed on an HN, it allows BackupPC to backup from and
- restore to any VE hosted on any HN in the cluster. When VE's are migrated
- between HN's, the backup configuration does not need to change.
-
-* Holger Parplies' BackupPC_verifyPool.
-
-* See the [README](http://repo/gitweb/?p=backuppc.git;a=blob;f=README;hb=HEAD)
- in the repository for more information.
-
-# OpenVZ scripts
-
-The [OpenVZ scripts repository](http://repo/gitweb/?p=ovz.git;a=tree)
-includes:
-
-* bpcdump. Similar in concept to vzdump. Although fairly general in nature,
- we use it only for backing up the BackupPC VE, whose filesystem is on a
- private LVM LV (logical volume), to an eSATA drive.
-
-* bpcbackup. A script that runs from crontab on one or more HN's to launch
- the bpcdump program. Since all our HN's are configured the same, each has
- an eSATA port and can be used to perform a backup of the BackupPC VE.
-
-* See the [README.recover](http://repo/gitweb/?p=ovz.git;a=blob;f=README.recover;hb=HEAD)
- file for mroe information.
-
-# eSATA scripts
-
-The [eSATA scripts repository](http://repo/gitweb/?p=esata.git;a=tree)
-contains the esata script, which wraps the `scsiadd` utility for properly
-handling esternal drives on the Dell PE1800 and PE1900 platforms. Newer
-hardware and better Linux kernel support should someday make scripts like this
-unnecessary. See the included
-[README](http://repo/gitweb/?p=esata.git;a=blob;f=README;hb=HEAD) file for
-more information.
+# TMI backup strategy
+
+TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual
+Environments (VE) running on a cluster of Dell PE1800 servers. The contents
+of each VE, as well as the servers hosting them, are backed up using
+[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the
+BackupPC disk archive is made on one of a pool of external eSATA drives, which
+are rotated off-site for disaster recovery. TMI has authored a few program
+scripts which integrate these backup components.
+
+* [BackupPC_ovz](http://repo/gitweb/?p=backuppc.git;a=blob;f=README;hb=HEAD)
+ allows an OpenVZ VE to be backed up and restored via BackupPC without
+ special configuration of the VE, nor with BackupPC being told on which
+ hardware node the VE is running.
+
+* bpcdump and friends support cloning the BackupPC VE to a removeable eSATA
+ drive for disaster recovery. See [README.recover](http://repo/gitweb/?p=ovz.git;a=blob;f=README.recover;hb=HEAD)
+ for more information.
+
+* The [esata](http://repo/gitweb/?p=esata.git;a=tree) wraps the `scsiadd`
+ utility for properly handling eSATA drives on Dell PE1800 and PE1900
+ platforms. Newer hardware and better Linux kernel support will someday make
+ scripts like this unnecessary. See the included
+ [README](http://repo/gitweb/?p=esata.git;a=blob;f=README;hb=HEAD) for more
+ information.
Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary),
[[aptrepo]].
-TMI uses [TinyOS](http://www.tinyos.net) for various data acquisition
-applications, and we maintain a modified tree that supports certain features
-not available in the official tree. We maintain a
-[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) containing
-our TinyOS tree, in which we also maintain a cogent patchset against the
-official tree.
+TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain
+features not available in the official tree. The TMI repository contains
+code imported from CVS upstream, our internal working branches, and tags
+marking a series commits that are a clean patch series of the TMI enhancements
+against an official upstream release.
* Current patchset tag: patchset/2.1.0-3
-* Build from official release tag: tinyos/2.1.0
-* View the patchset [here](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.0-3).
+* Derived from official release tag: tinyos/2.1.0
+* View the latest patchset [here](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.0-3).
-Our TinyOS requires a newer [[msp430]] toolchain. A complete TinyOS
+The TMI TinyOS code requires a newer [[msp430]] toolchain. A complete TinyOS
development environment including a newer toolchain is available for
installation from our [[APT repository|aptrepo]].
Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary),
[[aptrepo]].
-## Package versioning
+# Package versioning
The TinyOS packages are built from the TMI
[TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary). The
package version number is of the form `tosver-tmiver`, where `tosver` is the
official TinyOS release version on which the code is based, and `tmiver` is the
-version of the modifications applied by TMI.
-
-These version numbers are present in the
-[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) in the form
-of release and patchset tags. For example, the code from which package version
-`2.1.0-3` is built is tagged `release/2.1.0-3`. This code is based on the
-upstream version `2.1.0`, which is tagged in the repository as `tinyos/2.1.0`.
-A clean patchset is tagged `patchset/2.1.0-3`, where the commits between these
-two tags represent a clean set of patches that apply the TMI modifications to
-the upstream version.
-
-## Git/CVS issues
-
-Because CVS and git tags are fundamentally incompatible, we cannot guarantee
-that a git repo using `git-cvs` and tracking the upstream CVS repository will
-result in the exact same checkout tree state at each tag. We resolve this
-issue as follows:
-
-* TMI tracks the upstream CVS in a git mirror repository updated periodically
- via a script using `git-cvsimport`.
-
-* When TMI wants to rebase its local modifications on a newer version of
- upstream TinyOS, it pulls changes in from this mirror git repo into the
- [TMI TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary)
- onto the `upstream` branch. Release tags, such as `release_tinyos_2_1_0_0`
- from CVS are also pulled.
-
-* In git, a new release branch is created at the release tag. In this example,
- release tag `release_tinyos_2_1_0_0` is the branch point for the new branch
- `release/2.1.0`.
-
-* The tag `tinyos/2.1.0` is the tag of git tree along the `release/2.1.0`
- branch where the checkout of git at `tinyos/2.1.0` exactly matches the
- checkout of upstream CVS at `release_tinyos_2_1_0_0`.
-
- * If the git and CVS tags checkout trees that match at tag
- `release_tinyos_2_1_0_0`, then `tinyos/2.1.0` tags that same commit.
-
- * If the git and CVS checkouts diverge, then the first commit along the new
- `release/2.1.0` branch contains the changes necessary to sync git with CVS
- at the release tag. This is accomplished by using `git_load_dirs`. This
- new commit to the release branch is tagged `tinyos/2.1.0`.
-
-## Multiple source trees
-
-TMI TinyOS packages allow for the installation of multiple TinyOS source trees.
-This allows us to maintain older programs built against older versions of
-TinyOS while simultaneously working on new applications. It also allows us to
-compile code against the official TinyOS releases in addition to the TMI
-enhanced releases.
-
-This is accomplished by altering how TinyOS source is installed. The standard
-convention is for the TinyOS source tree to be installed on a development
-workstation at `/opt/tinyos-2.x`. The TMI packages install the source trees
-at `/opt/tinyos/VER`. For example, the official TinyOS 2.0.2.2 source tree
-would install at `/opt/tinyos/2.0.2.2`, and the TMI enhanced TinyOS 2.1.0-3
-tree installs at `/opt/tinyos/2.1.0-3`. A sourceable script,
-`/opt/tinyos/tinyos.sh`, is used to set which source tree is used by the
-TinyOS development tools and build system. The script is also sourced in
-the user's profile to provide persistence of settings across logins and reboots.
-
-Each TinyOS source tree has its own package. Here are the currently available
-trees as of this writing:
+version of the modifications applied by TMI. Released APT package versions are
+associated with tags in the source code repository. Consider the latest
+package version, 2.1.0-3, for which these tags exist in the repository:
+
+* `debian/2.1.0-3-2tmi` is the tag of the 'debianized' code from which the APT
+ packages version 2.1.0-3-2tmi were built.
+
+* `release/2.1.0-3` is the tag of the TinyOS code of which
+ `debian/2.1.0-3-2tmi` is a superset, the latter containing the debian
+ packaging files.
+
+* `tinyos/2.1.0` is the official upstream release on which `release/2.1.0-3` is
+ based, the difference being the TMI enhancements.
+
+* `patchset/2.1.0-3` is the head of a string of commits from the
+ `tinyos/2.1.0` tag that represent a clean patch series that applies the
+ TMI enhancements to the official upstream release.
+
+# Multiple source trees
+
+Often it is impractical to maintain an older application by porting it forward
+to the latest TinyOS version. The TMI approach allows multiple TinyOS trees
+to be installed simultaneously, thereby allowing different applications to be
+compiled against different TinyOS versions.
+
+The official TinyOS installs the source tree at /opt/tinyos-2.x. The TMI
+version installs source trees at /opt/tinyos/VER. For example, the latest TMI
+tree is installed at /opt/tinyos/2.1.0-3. TMI also maintains in its repository
+the last few official source trees. At least one must be installed, and the
+developer may install others as needed. When installing or upgrading TMI
+TinyOS packages via APT, the latest TMI tree package is automatically installed.
+Source the script `/opt/tinyos/tinyos.sh` to set the three you wish to use.
+Source this script from your login profile with no argument to ensure that your
+tree selection is persistent across logins.
+
+This is the currently available trees as of this writing. You can use the
+command shown below to at any time view the available source trees.
$ sudo apt-cache search tinyos-source
tinyos-source - TinyOS source meta package
tinyos-source-2.1.0 - TinyOS source code tree
tinyos-source-2.1.0-3 - TinyOS source code tree
-At least one tree must be installed, and the latest tree is installed each time
-the tinyos packages are installed or upgraded. However, the developer may
-keep multiple trees installed if necessary. The APT package upgrade
-mechanisms work properly.
-
-## Installing TinyOS
+# Installing TinyOS
-To install TinyOS, perform the steps above to configure the TMI repository on
-the workstation, then type:
+To install TinyOS, perform the steps shown for the [[aptrepo]], then type:
sudo apt-get install tinyos
-title: TMIcore
-linktitle: tmicore
+title: tmicore
parent: TOP
ctime: 2009-12-02
TMI has developed an [[msp430]] target board for low power data acquisition.
Its design is not complete yet, but it is (SOON) available under an open
source license. The design was created using [Eagle](http://www.cadsoft.de).
+It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger,
+and a USB interface for communications and programming.
-We call our target board TMIcore. In actuality, the board shown in the design
-is the TMIrws board, which contains at its core the TMIcore design. The PCB
-design shows where it can be 'cut' to build a stand-alone TMIcore board.
-The full TMIrws board is the heart of a solar powered remote weather station
-that reports its observations to an internet server via the cellular network.
+The actual design files are for the tmirws board, which is a superset of the
+tmicore design. One can trivially derive the tmicore design by simply cutting
+the board layout at the inner rectangle. The tmirws design is the heart of an
+off-grid solar powered remote weather station that reports its observations to
+an internet server via the cellular network.
+
+TMI enhanced [[tinyos]] contains platform support for both the tmicore and
+tmirws variants of this design.
projects / oss-web.git / commitdiff