diff --git a/mk/PX4/ROMFS/init.d/rcS b/mk/PX4/ROMFS/init.d/rcS
new file mode 100755
index 0000000000000000000000000000000000000000..c0a70f7ddc2924c0ace899edec24994fd2c28dc4
--- /dev/null
+++ b/mk/PX4/ROMFS/init.d/rcS
@@ -0,0 +1,83 @@
+#!nsh
+#
+# PX4FMU startup script.
+#
+# This script is responsible for:
+#
+# - mounting the microSD card (if present)
+# - running the user startup script from the microSD card (if present)
+# - detecting the configuration of the system and picking a suitable
+#   startup script to continue with
+#
+# Note: DO NOT add configuration-specific commands to this script;
+#       add them to the per-configuration scripts instead.
+#
+
+#
+# Default to auto-start mode.  An init script on the microSD card
+# can change this to prevent automatic startup of the flight script.
+#
+set MODE autostart
+set USB autoconnect
+
+#
+
+#
+
+
+#
+# Try to mount the microSD card.
+#
+echo "[init] looking for microSD..."
+if mount -t vfat /dev/mmcsd0 /fs/microsd
+then
+	echo "[init] card mounted at /fs/microsd"
+	# Start playing the startup tune
+	tone_alarm start
+else
+	echo "[init] no microSD card found"
+	# Play SOS
+	tone_alarm 2
+fi
+
+#
+# Look for an init script on the microSD card.
+#
+# To prevent automatic startup in the current flight mode,
+# the script should set MODE to some other value.
+#
+if [ -f /fs/microsd/etc/rc ]
+then
+	echo "[init] reading /fs/microsd/etc/rc"
+	sh /fs/microsd/etc/rc
+fi
+# Also consider rc.txt files
+if [ -f /fs/microsd/etc/rc.txt ]
+then
+	echo "[init] reading /fs/microsd/etc/rc.txt"
+	sh /fs/microsd/etc/rc.txt
+fi
+
+#
+# Check for USB host
+#
+if [ $USB != autoconnect ]
+then
+	echo "[init] not connecting USB"
+else
+	if sercon
+	then
+		echo "[init] USB interface connected"
+	else
+		echo "[init] No USB connected"
+	fi
+fi
+
+# if this is an APM build then there will be a rc.APM script
+# from an EXTERNAL_SCRIPTS build option
+if [ -f /etc/init.d/rc.APM ]
+then
+	echo Running rc.APM
+	# if APM startup is successful then nsh will exit
+	sh /etc/init.d/rc.APM
+fi
diff --git a/mk/PX4/ROMFS/mixers/FMU_pass.mix b/mk/PX4/ROMFS/mixers/FMU_pass.mix
new file mode 100644
index 0000000000000000000000000000000000000000..e9a81f2bb292e3d56c62f85bc2af4450319a5742
--- /dev/null
+++ b/mk/PX4/ROMFS/mixers/FMU_pass.mix
@@ -0,0 +1,23 @@
+Passthrough mixer for PX4FMU
+============================
+
+This file defines passthrough mixers suitable for testing.
+
+Channel group 0, channels 0-3 are passed directly through to the outputs.
+
+M: 1
+O:      10000  10000      0 -10000  10000
+S: 0 0  10000  10000      0 -10000  10000
+
+M: 1
+O:      10000  10000      0 -10000  10000
+S: 0 1  10000  10000      0 -10000  10000
+
+M: 1
+O:      10000  10000      0 -10000  10000
+S: 0 2  10000  10000      0 -10000  10000
+
+M: 1
+O:      10000  10000      0 -10000  10000
+S: 0 3  10000  10000      0 -10000  10000
+
diff --git a/mk/PX4/ROMFS/mixers/README b/mk/PX4/ROMFS/mixers/README
new file mode 100644
index 0000000000000000000000000000000000000000..6649c53c20b5a8e323d5ff3256737ef43f5c1577
--- /dev/null
+++ b/mk/PX4/ROMFS/mixers/README
@@ -0,0 +1,154 @@
+PX4 mixer definitions
+=====================
+
+Files in this directory implement example mixers that can be used as a basis
+for customisation, or for general testing purposes.
+
+Mixer basics
+------------
+
+Mixers combine control values from various sources (control tasks, user inputs,
+etc.) and produce output values suitable for controlling actuators; servos,
+motors, switches and so on.
+
+An actuator derives its value from the combination of one or more control
+values. Each of the control values is scaled according to the actuator's
+configuration and then combined to produce the actuator value, which may then be
+further scaled to suit the specific output type.
+
+Internally, all scaling is performed using floating point values. Inputs and
+outputs are clamped to the range -1.0 to 1.0.
+
+control    control   control
+   |          |         |
+   v          v         v
+ scale      scale     scale
+   |          |         |
+   |          v         |
+   +-------> mix <------+
+              |
+            scale
+              |
+              v
+             out
+
+Scaling
+-------
+
+Basic scalers provide linear scaling of the input to the output.
+
+Each scaler allows the input value to be scaled independently for inputs
+greater/less than zero. An offset can be applied to the output, and lower and
+upper boundary constraints can be applied. Negative scaling factors cause the
+output to be inverted (negative input produces positive output).
+
+Scaler pseudocode:
+
+if (input < 0)
+    output = (input * NEGATIVE_SCALE) + OFFSET
+else
+    output = (input * POSITIVE_SCALE) + OFFSET
+
+if (output < LOWER_LIMIT)
+    output = LOWER_LIMIT
+if (output > UPPER_LIMIT)
+    output = UPPER_LIMIT
+
+Syntax
+------
+
+Mixer definitions are text files; lines beginning with a single capital letter
+followed by a colon are significant. All other lines are ignored, meaning that
+explanatory text can be freely mixed with the definitions.
+
+Each file may define more than one mixer; the allocation of mixers to actuators
+is specific to the device reading the mixer definition, and the number of
+actuator outputs generated by a mixer is specific to the mixer.
+
+A mixer begins with a line of the form
+
+	<tag>: <mixer arguments>
+
+The tag selects the mixer type; 'M' for a simple summing mixer, 'R' for a 
+multirotor mixer, etc.
+
+Null Mixer
+..........
+
+A null mixer consumes no controls and generates a single actuator output whose
+value is always zero.  Typically a null mixer is used as a placeholder in a
+collection of mixers in order to achieve a specific pattern of actuator outputs.
+
+The null mixer definition has the form:
+
+  Z:
+
+Simple Mixer
+............
+
+A simple mixer combines zero or more control inputs into a single actuator
+output.  Inputs are scaled, and the mixing function sums the result before
+applying an output scaler.
+
+A simple mixer definition begins with:
+
+  M: <control count>
+  O: <-ve scale> <+ve scale> <offset> <lower limit> <upper limit>
+
+If <control count> is zero, the sum is effectively zero and the mixer will
+output a fixed value that is <offset> constrained by <lower limit> and <upper
+limit>.
+
+The second line defines the output scaler with scaler parameters as discussed
+above. Whilst the calculations are performed as floating-point operations, the
+values stored in the definition file are scaled by a factor of 10000; i.e. an
+offset of -0.5 is encoded as -5000.
+
+The definition continues with <control count> entries describing the control
+inputs and their scaling, in the form:
+
+  S: <group> <index> <-ve scale> <+ve scale> <offset> <lower limit> <upper limit>
+
+The <group> value identifies the control group from which the scaler will read,
+and the <index> value an offset within that group.  These values are specific to
+the device reading the mixer definition.
+
+When used to mix vehicle controls, mixer group zero is the vehicle attitude
+control group, and index values zero through three are normally roll, pitch,
+yaw and thrust respectively.
+
+The remaining fields on the line configure the control scaler with parameters as
+discussed above. Whilst the calculations are performed as floating-point
+operations, the values stored in the definition file are scaled by a factor of
+10000; i.e. an offset of -0.5 is encoded as -5000.
+
+Multirotor Mixer
+................
+
+The multirotor mixer combines four control inputs (roll, pitch, yaw, thrust)
+into a set of actuator outputs intended to drive motor speed controllers.
+
+The mixer definition is a single line of the form:
+
+R: <geometry> <roll scale> <pitch scale> <yaw scale> <deadband>
+
+The supported geometries include:
+
+  4x - quadrotor in X configuration
+  4+ - quadrotor in + configuration
+  6x - hexcopter in X configuration
+  6+ - hexcopter in + configuration
+  8x - octocopter in X configuration
+  8+ - octocopter in + configuration
+  
+Each of the roll, pitch and yaw scale values determine scaling of the roll,
+pitch and yaw controls relative to the thrust control.  Whilst the calculations
+are performed as floating-point operations, the values stored in the definition
+file are scaled by a factor of 10000; i.e. an factor of 0.5 is encoded as 5000.
+
+Roll, pitch and yaw inputs are expected to range from -1.0 to 1.0, whilst the
+thrust input ranges from 0.0 to 1.0.  Output for each actuator is in the 
+range -1.0 to 1.0.
+
+In the case where an actuator saturates, all actuator values are rescaled so that 
+the saturating actuator is limited to 1.0.