diff --git a/README.md b/README.md
index 6b5f8ec..99db1fa 100644
--- a/README.md
+++ b/README.md
@@ -16,7 +16,7 @@
  - [host-management.md](host-management.md): Performing host management tasks
    with OpenBMC
 
- - [code-update.md](code-update.md): Updating OpenBMC and host platform firmware
+ - [code-update](code-update): Updating OpenBMC and host platform firmware
 
 
 OpenBMC Development
diff --git a/code-update.md b/code-update.md
deleted file mode 100644
index 0976c42..0000000
--- a/code-update.md
+++ /dev/null
@@ -1,321 +0,0 @@
-OpenBMC & Host Code Update
-===================
-
-After building OpenBMC, you will end up with a set of image files in
-`tmp/deploy/images/<platform>/`. The `image-*` symlinks correspond to components
-that can be updated on the BMC:
-
- * `image-bmc` → `flash-<platform>-<timestamp>`
-
-    The whole-of-flash image for the BMC
-
- * `image-initramfs` → `core-image-minimal-initramfs-palmetto.cpio.lzma.u-boot`
-
-    The small initramfs image; used for early init and flash management
-
- * `image-kernel` → `cuImage`
-
-    The OpenBMC kernel cuImage (combined kernel and device tree)
-
- * `image-rofs` → `obmc-phosphor-image-palmetto.squashfs-xz`
-
-    The read-only OpenBMC filesystem
-
- * `image-rwfs` → `rwfs.jffs2`
-
-    The read-write filesystem for persistent changes to the OpenBMC filesystem
-
- * `image-u-boot` → `u-boot.bin`
-
-    The OpenBMC bootloader
-
-Additionally, there are two tarballs created that can be deployed and unpacked by REST:
-
- * `<platform>-<timestamp>.all.tar`
-
-    The complete BMC flash content: A single file wrapped in a tar archive
-
- * `<platform>-<timestamp>.tar`
-
-    Partitioned BMC flash content: Multiple files wrapped in a tar archive,
-    one for each of the u-boot, kernel, initramfs, ro and rw partitions.
-
-Preparing for BMC code Update
------------------------------
-
-The BMC normally runs with the read-write and read-only file systems
-mounted, which means these images may be read (and written, for the
-read-write filesystem) at any time.  Because the updates are distributed
-as complete file system images, these filesystems have to be unmounted
-to replace them with new images.  To unmount these file systems all
-applications must be stopped.
-
-By default, an orderly `reboot` will stop all applications and unmount
-the root filesystem, and the images copied into the `/run/initramfs`
-directory will be applied at that point before restarting.  This also
-applied to the `shutdown` and `halt` commands -- they will write the
-flash before stopping.
-
-As an alternative, an option can be parsed by the `init` script in
-the initramfs to copy the required contents of these filesystems into
-RAM so the images can be applied while the rest of the application stack
-is running and progress can be monitored over the network.  The
-`update` script can then be called to write the images while the
-system is operational and its progress output monitored.
-
-Update from the OpenBMC shell
------------------------------
-
-To update from the OpenBMC shell, follow the steps in this section.
-
-It is recommended that the BMC be prepared for update (note that the
-environment variable needs to be set twice for initramfs be able to
-read it due to the U-Boot redundant environments):
-
-    fw_setenv openbmconce copy-files-to-ram copy-base-filesystem-to-ram
-    fw_setenv openbmconce copy-files-to-ram copy-base-filesystem-to-ram
-    reboot
-
-Copy one or more of these `image-*` files to the directory:
-
-    /run/initramfs/
-
-(preserving the filename), then run the `update` script to apply the images:
-
-    /run/initramfs/update
-
-then reboot to finish applying:
-
-    reboot
-
-During the reboot process, the `update` script will be invoked after
-the file systems are unmounted to complete the update process.
-
-Some optional features are available, see the help for more details:
-
-    /run/initramfs/update --help
-
-Update via REST
----------------
-
-An OpenBMC system can download an update image from a TFTP server, and apply
-updates, controlled via REST. The general procedure is:
-
- 1. Prepare system for update
- 2. Configure update settings
- 3. Initiate update
- 4. Check flash status
- 5. Apply update
- 6. Reboot the BMC
-
-### Prepare system for update
-
-Perform a POST to invoke the `PrepareForUpdate` method of the `/flash/bmc` object:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data":  []}' \
-        https://${bmc}/org/openbmc/control/flash/bmc/action/prepareForUpdate
-
-This will setup the u-boot environment and reboot the BMC.   If no other
-images were pending the BMC should return in about 2 minutes.
-
-
-### Configure update settings
-
-There are a few settings available to control the update process:
-
- * `preserve_network_settings`: Preserve network settings, only needed if updating the whole flash
- * `restore_application_defaults`: update (clear) the read-write file system
- * `update_kernel_and_apps`: update kernel and initramfs.
-                             If the partitioned tarball will be used for update then this option
-                             must be set. Otherwise, if the complete tarball will be used then
-                             this option must not be set.
- * `clear_persistent_files`: ignore the persistent file list when resetting applications defaults
- * `auto_apply`: Attempt to write the images by invoking the `Apply` method after the images are unpacked.
-
-To configure the update settings, perform a REST PUT to
-`/control/flash/bmc/attr/<setting>`. For example:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X PUT \
-        -d '{"data": 1}' \
-        https://${bmc}/org/openbmc/control/flash/bmc/attr/preserve_network_settings
-
-### Initiate update
-
-Perform a POST to invoke the `updateViaTftp` method of the `/flash/bmc` object:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data": ["<TFTP server IP address>", "<filename>"]}' \
-        https://${bmc}/org/openbmc/control/flash/bmc/action/updateViaTftp
-
-Note the `<filename>` shall be a tarball.
-
-### Check flash status
-
-You can query the progress of the download and image verification with
-a simple GET request:
-
-    curl -b cjar -k https://${bmc}/org/openbmc/control/flash/bmc
-
-Or perform a POST to invoke the `GetUpdateProgress` method of the `/flash/bmc` object:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data": []}' \
-        https://${bmc}/org/openbmc/control/flash/bmc/action/GetUpdateProgress
-
-Note:
-
- * During downloading the tarball, the progress status is `Downloading`
- * After the tarball is downloaded and verified, the progress status becomes `Image ready to apply`.
-
-### Apply update
-If the status is `Image ready to apply.` then you can either initiate
-a reboot or call the Apply method to start the process of writing the
-flash:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data": []}' \
-        https://${bmc}/org/openbmc/control/flash/bmc/action/Apply
-
-Now the image is being flashed, you can check the progress with above step’s command as well.
-
-* During flashing the image, the status becomes `Writing images to flash`
-* After it’s flashed and verified, the status becomes `Apply Complete. Reboot to take effect.`
-
-### Reboot the BMC
-
-To start using the new images, reboot the BMC using the warmReset method
-of the BMC control object:
-
-    curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data": []}' \
-        https://${bmc}/org/openbmc/control/bmc0/action/warmReset
-
-
-Host code update
-================
-
-Reference:
-https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software
-
-Following are the steps to update the host firmware (or "BIOS"). This assumes
-the host is not accessing its firmware.
-
-1. Get a squashfs image:
-  * Build op-build: https://github.com/open-power/op-build
-  * After building, the image should be a tarball in the output/images
-    directory called <system type>.pnor.squashfs.tar
-
-2. Transfer the generated squashfs image to the BMC via one of the following
-methods:
-  * Method 1: Via scp: Copy the generated squashfs image to the `/tmp/images/`
-    directory on the BMC.
-  * Method 2: Via REST Upload:
-  https://github.com/openbmc/docs/blob/master/rest-api.md#uploading-images
-  * Method 3: Via TFTP: Perform a POST request to call the `DownloadViaTFTP`
-    method of `/xyz/openbmc_project/software`.
-
-      ```
-      curl -b cjar -k -H "Content-Type: application/json" -X POST \
-        -d '{"data": ["<filename>", "<TFTP server IP address"]}' \
-        https://${bmc}/xyz/openbmc_project/software/action/DownloadViaTFTP
-      ```
-
-3. Note the version id generated for that image file. The version id is a hash
-value of 8 hexadecimal numbers, generated by SHA-512 hashing the version
-string contained in the image and taking the first 8 characters. Get the
-version id via one of the following methods:
-
-  * Method 1: From the BMC command line, note the most recent directory name
-    created under `/tmp/images/`, in this example it'd be `2a1022fe`:
-
-      ```
-      # ls -l /tmp/images/
-      total 0
-      drwx------    2 root     root            80 Aug 22 07:54 2a1022fe
-      drwx------    2 root     root            80 Aug 22 07:53 488449a2
-      ```
-
-  * Method 2: This method *only* works if there are no `Ready` images at the
-    start of transferring the image. Using the REST API, note the object that
-    has its Activation property set to Ready, in this example it'd be `2a1022fe`:
-
-      ```
-      $ curl -b cjar -k https://${bmc}/xyz/openbmc_project/software/enumerate
-      {
-        "data": {
-          "/xyz/openbmc_project/software/2a1022fe": {
-            "Activation": "xyz.openbmc_project.Software.Activation.Activations.Ready",
-      ```
-
-  * Method 3: Calculate the version id beforehand from the image with:
-
-      ```
-      tar xfO <squashfs image tar> MANIFEST | sed -ne '/version=/ {s/version=//;p}' | head -n1 | tr -d '\n' | sha512sum | cut -b 1-8
-      ```
-
-4. To initiate the update, set the `RequestedActivation` property of the desired
-image to `Active`, substitute ``<id>`` with the hash value noted on the previous
-step, this will write the contents of the image to a UBI volume in the PNOR chip
-via one of the following methods:
-
-  * Method 1: From the BMC command line:
-
-      ```
-      busctl set-property org.open_power.Software.Host.Updater \
-        /xyz/openbmc_project/software/<id> \
-        xyz.openbmc_project.Software.Activation RequestedActivation s \
-        xyz.openbmc_project.Software.Activation.RequestedActivations.Active
-
-      ```
-
-  * Method 2: Using the REST API:
-
-      ```
-      curl -b cjar -k -H "Content-Type: application/json" -X PUT \
-        -d '{"data":
-        "xyz.openbmc_project.Software.Activation.RequestedActivations.Active"}' \
-        https://${bmc}/xyz/openbmc_project/software/<id>/attr/RequestedActivation
-      ```
-
-5. (Optional) Check the flash progress. This interface is only available during
-the activation progress and is not present once the activation is completed
-via one of the following:
-
-  * Method 1: From the BMC command line:
-
-      ```
-      busctl get-property org.open_power.Software.Host.Updater \
-        /xyz/openbmc_project/software/<id> \
-        xyz.openbmc_project.Software.Activation Progress
-      ```
-
-  * Method 2: Using the REST API:
-
-      ```
-      curl -b cjar -k https://${bmc}/xyz/openbmc_project/software/<id>/attr/Progress
-      ```
-
-6. Check the activation is complete by verifying the Activation property is set
-to Active via one of the following methods:
-
-  * Method 1: From the BMC command line:
-
-      ```
-      busctl get-property org.open_power.Software.Host.Updater \
-        /xyz/openbmc_project/software/<id> \
-        xyz.openbmc_project.Software.Activation Activation
-      ```
-
-  * Method 2: Using the REST API:
-
-      ```
-      curl -b cjar -k https://${bmc}/xyz/openbmc_project/software/<id>
-      ```
-
-### Patching the host firmware
-
-Copy the partition binary file to `/usr/local/share/pnor/` on the BMC.
-
-The partition binary file must be named the same as the partition name that
-intends to patch, ex: `ATTR_TMP`.
diff --git a/code-update/code-update.md b/code-update/code-update.md
new file mode 100644
index 0000000..dcef10c
--- /dev/null
+++ b/code-update/code-update.md
@@ -0,0 +1,205 @@
+OpenBMC non-UBI Code Update
+===================
+
+Two BMC Code Updates layouts are available:
+
+ * Static, non-UBI layout - The default code update
+
+ * UBI layout - enabled via obmc-ubi-fs machine feature
+
+This document describes the non-UBI, default code update. The UBI code update
+can be found here: [ubi-code-update.md](ubi-code-update.md)
+
+The host code update can be found here:
+[host-code-update.md](host-code-update.md)
+
+After building OpenBMC, you will end up with a set of image files in
+`tmp/deploy/images/<platform>/`. The `image-*` symlinks correspond to components
+that can be updated on the BMC:
+
+ * `image-bmc` → `flash-<platform>-<timestamp>`
+
+    The whole-of-flash image for the BMC
+
+ * `image-initramfs` → `core-image-minimal-initramfs-palmetto.cpio.lzma.u-boot`
+
+    The small initramfs image; used for early init and flash management
+
+ * `image-kernel` → `cuImage`
+
+    The OpenBMC kernel cuImage (combined kernel and device tree)
+
+ * `image-rofs` → `obmc-phosphor-image-palmetto.squashfs-xz`
+
+    The read-only OpenBMC filesystem
+
+ * `image-rwfs` → `rwfs.jffs2`
+
+    The read-write filesystem for persistent changes to the OpenBMC filesystem
+
+ * `image-u-boot` → `u-boot.bin`
+
+    The OpenBMC bootloader
+
+Additionally, there are two tarballs created that can be deployed and unpacked by REST:
+
+ * `<platform>-<timestamp>.all.tar`
+
+    The complete BMC flash content: A single file wrapped in a tar archive
+
+ * `<platform>-<timestamp>.tar`
+
+    Partitioned BMC flash content: Multiple files wrapped in a tar archive,
+    one for each of the u-boot, kernel, initramfs, ro and rw partitions.
+
+Preparing for BMC code Update
+-----------------------------
+
+The BMC normally runs with the read-write and read-only file systems
+mounted, which means these images may be read (and written, for the
+read-write filesystem) at any time.  Because the updates are distributed
+as complete file system images, these filesystems have to be unmounted
+to replace them with new images.  To unmount these file systems all
+applications must be stopped.
+
+By default, an orderly `reboot` will stop all applications and unmount
+the root filesystem, and the images copied into the `/run/initramfs`
+directory will be applied at that point before restarting.  This also
+applied to the `shutdown` and `halt` commands -- they will write the
+flash before stopping.
+
+As an alternative, an option can be parsed by the `init` script in
+the initramfs to copy the required contents of these filesystems into
+RAM so the images can be applied while the rest of the application stack
+is running and progress can be monitored over the network.  The
+`update` script can then be called to write the images while the
+system is operational and its progress output monitored.
+
+Update from the OpenBMC shell
+-----------------------------
+
+To update from the OpenBMC shell, follow the steps in this section.
+
+It is recommended that the BMC be prepared for update (note that the
+environment variable needs to be set twice for initramfs be able to
+read it due to the U-Boot redundant environments):
+
+    fw_setenv openbmconce copy-files-to-ram copy-base-filesystem-to-ram
+    fw_setenv openbmconce copy-files-to-ram copy-base-filesystem-to-ram
+    reboot
+
+Copy one or more of these `image-*` files to the directory:
+
+    /run/initramfs/
+
+(preserving the filename), then run the `update` script to apply the images:
+
+    /run/initramfs/update
+
+then reboot to finish applying:
+
+    reboot
+
+During the reboot process, the `update` script will be invoked after
+the file systems are unmounted to complete the update process.
+
+Some optional features are available, see the help for more details:
+
+    /run/initramfs/update --help
+
+Update via REST
+---------------
+
+An OpenBMC system can download an update image from a TFTP server, and apply
+updates, controlled via REST. The general procedure is:
+
+ 1. Prepare system for update
+ 2. Configure update settings
+ 3. Initiate update
+ 4. Check flash status
+ 5. Apply update
+ 6. Reboot the BMC
+
+### Prepare system for update
+
+Perform a POST to invoke the `PrepareForUpdate` method of the `/flash/bmc` object:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data":  []}' \
+        https://${bmc}/org/openbmc/control/flash/bmc/action/prepareForUpdate
+
+This will setup the u-boot environment and reboot the BMC.   If no other
+images were pending the BMC should return in about 2 minutes.
+
+
+### Configure update settings
+
+There are a few settings available to control the update process:
+
+ * `preserve_network_settings`: Preserve network settings, only needed if updating the whole flash
+ * `restore_application_defaults`: update (clear) the read-write file system
+ * `update_kernel_and_apps`: update kernel and initramfs.
+                             If the partitioned tarball will be used for update then this option
+                             must be set. Otherwise, if the complete tarball will be used then
+                             this option must not be set.
+ * `clear_persistent_files`: ignore the persistent file list when resetting applications defaults
+ * `auto_apply`: Attempt to write the images by invoking the `Apply` method after the images are unpacked.
+
+To configure the update settings, perform a REST PUT to
+`/control/flash/bmc/attr/<setting>`. For example:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X PUT \
+        -d '{"data": 1}' \
+        https://${bmc}/org/openbmc/control/flash/bmc/attr/preserve_network_settings
+
+### Initiate update
+
+Perform a POST to invoke the `updateViaTftp` method of the `/flash/bmc` object:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data": ["<TFTP server IP address>", "<filename>"]}' \
+        https://${bmc}/org/openbmc/control/flash/bmc/action/updateViaTftp
+
+Note the `<filename>` shall be a tarball.
+
+### Check flash status
+
+You can query the progress of the download and image verification with
+a simple GET request:
+
+    curl -b cjar -k https://${bmc}/org/openbmc/control/flash/bmc
+
+Or perform a POST to invoke the `GetUpdateProgress` method of the `/flash/bmc` object:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data": []}' \
+        https://${bmc}/org/openbmc/control/flash/bmc/action/GetUpdateProgress
+
+Note:
+
+ * During downloading the tarball, the progress status is `Downloading`
+ * After the tarball is downloaded and verified, the progress status becomes `Image ready to apply`.
+
+### Apply update
+If the status is `Image ready to apply.` then you can either initiate
+a reboot or call the Apply method to start the process of writing the
+flash:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data": []}' \
+        https://${bmc}/org/openbmc/control/flash/bmc/action/Apply
+
+Now the image is being flashed, you can check the progress with above steps command as well.
+
+* During flashing the image, the status becomes `Writing images to flash`
+* After it's flashed and verified, the status becomes `Apply Complete. Reboot to take effect.`
+
+### Reboot the BMC
+
+To start using the new images, reboot the BMC using the warmReset method
+of the BMC control object:
+
+    curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data": []}' \
+        https://${bmc}/org/openbmc/control/bmc0/action/warmReset
+
diff --git a/ubi-code-update.md b/code-update/host-code-update.md
similarity index 60%
copy from ubi-code-update.md
copy to code-update/host-code-update.md
index d416668..e388de6 100644
--- a/ubi-code-update.md
+++ b/code-update/host-code-update.md
@@ -1,40 +1,32 @@
-BMC UBI Code Update
-==============
+Host Code Update
+================
 
-Two BMC Code Updates layouts are available:
+Reference:
+https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software
 
- * Static, non-UBI layout - The default code update
+Following are the steps to update the host firmware (or "BIOS"). This assumes
+the host is not accessing its firmware.
 
- * UBI layout - enabled via obmc-ubi-fs machine feature
+1. Get a squashfs image:
+  * Build op-build: https://github.com/open-power/op-build
+  * After building, the image should be a tarball in the output/images
+    directory called <system type>.pnor.squashfs.tar
 
-This document describes the UBI code update. The non-UBI code update can be
-found here: https://github.com/openbmc/docs/blob/master/code-update.md#openbmc--host-code-update
-
-### Steps to Update
-
-The following are the steps to update the BMC if the UBI layout is enabled.
-
-1. Get a UBI BMC image tar:
-After building OpenBMC, you will end up with a set of image files in
-`tmp/deploy/images/<platform>/`. `obmc-phosphor-image-<platform>.ubi.mtd.tar` is
-the UBI BMC tar image. The UBI BMC tar image contains 5 files: u-boot,
-kernel, ro, and rw partitions and the MANIFEST file, which contains information
-about the image such as the image purpose and version. A MANIFEST file might
-look like
-```
-purpose=xyz.openbmc_project.Software.Version.VersionPurpose.BMC
-version=v1.99.10
-```
-
-2. Transfer the generated UBI BMC image to the BMC via one of the following
+2. Transfer the generated squashfs image to the BMC via one of the following
 methods:
-  * Method 1: Via scp: Copy the generated UBI BMC image to the `/tmp/images/`
+  * Method 1: Via scp: Copy the generated squashfs image to the `/tmp/images/`
     directory on the BMC.
   * Method 2: Via REST Upload:
   https://github.com/openbmc/docs/blob/master/rest-api.md#uploading-images
   * Method 3: Via TFTP: Perform a POST request to call the `DownloadViaTFTP`
     method of `/xyz/openbmc_project/software`.
 
+      ```
+      curl -b cjar -k -H "Content-Type: application/json" -X POST \
+        -d '{"data": ["<filename>", "<TFTP server IP address"]}' \
+        https://${bmc}/xyz/openbmc_project/software/action/DownloadViaTFTP
+      ```
+
 3. Note the version id generated for that image file. The version id is a hash
 value of 8 hexadecimal numbers, generated by SHA-512 hashing the version
 string contained in the image and taking the first 8 characters. Get the
@@ -62,22 +54,21 @@
             "Activation": "xyz.openbmc_project.Software.Activation.Activations.Ready",
       ```
 
- * Method 3: Calculate the version id beforehand from the image with:
+  * Method 3: Calculate the version id beforehand from the image with:
 
       ```
-      tar xfO <UBI BMC tar image> MANIFEST | sed -ne '/version=/ {s/version=//;p}' | head -n1 | tr -d '\n' | sha512sum | cut -b 1-8
+      tar xfO <squashfs image tar> MANIFEST | sed -ne '/version=/ {s/version=//;p}' | head -n1 | tr -d '\n' | sha512sum | cut -b 1-8
       ```
 
-
 4. To initiate the update, set the `RequestedActivation` property of the desired
 image to `Active`, substitute ``<id>`` with the hash value noted on the previous
-step, this will write the contents of the image to a UBI volume in the BMC chip
+step, this will write the contents of the image to a UBI volume in the PNOR chip
 via one of the following methods:
 
   * Method 1: From the BMC command line:
 
       ```
-      busctl set-property xyz.openbmc_project.Software.BMC.Updater \
+      busctl set-property org.open_power.Software.Host.Updater \
         /xyz/openbmc_project/software/<id> \
         xyz.openbmc_project.Software.Activation RequestedActivation s \
         xyz.openbmc_project.Software.Activation.RequestedActivations.Active
@@ -100,7 +91,7 @@
   * Method 1: From the BMC command line:
 
       ```
-      busctl get-property xyz.openbmc_project.Software.BMC.Updater  \
+      busctl get-property org.open_power.Software.Host.Updater \
         /xyz/openbmc_project/software/<id> \
         xyz.openbmc_project.Software.Activation Progress
       ```
@@ -111,8 +102,26 @@
       curl -b cjar -k https://${bmc}/xyz/openbmc_project/software/<id>/attr/Progress
       ```
 
-### Implementation
+6. Check the activation is complete by verifying the Activation property is set
+to Active via one of the following methods:
 
-More information about the implementation of the UBI code update can be found at
-https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software
-and https://github.com/openbmc/phosphor-bmc-code-mgmt
+  * Method 1: From the BMC command line:
+
+      ```
+      busctl get-property org.open_power.Software.Host.Updater \
+        /xyz/openbmc_project/software/<id> \
+        xyz.openbmc_project.Software.Activation Activation
+      ```
+
+  * Method 2: Using the REST API:
+
+      ```
+      curl -b cjar -k https://${bmc}/xyz/openbmc_project/software/<id>
+      ```
+
+### Patching the host firmware
+
+Copy the partition binary file to `/usr/local/share/pnor/` on the BMC.
+
+The partition binary file must be named the same as the partition name that
+intends to patch, ex: `ATTR_TMP`.
diff --git a/ubi-code-update.md b/code-update/ubi-code-update.md
similarity index 96%
rename from ubi-code-update.md
rename to code-update/ubi-code-update.md
index d416668..80f6e41 100644
--- a/ubi-code-update.md
+++ b/code-update/ubi-code-update.md
@@ -1,4 +1,4 @@
-BMC UBI Code Update
+OpenBMC UBI Code Update
 ==============
 
 Two BMC Code Updates layouts are available:
@@ -8,7 +8,7 @@
  * UBI layout - enabled via obmc-ubi-fs machine feature
 
 This document describes the UBI code update. The non-UBI code update can be
-found here: https://github.com/openbmc/docs/blob/master/code-update.md#openbmc--host-code-update
+found here: [code-update.md](code-update.md)
 
 ### Steps to Update