incubator-mynewt-site git commit: Updated split image doc with list of bsp that supports this feature

[ad...@apache.org]

Repository: incubator-mynewt-site
Updated Branches:
  refs/heads/asf-site b1d73298b -> e5deb3933


Updated split image doc with list of bsp that supports this feature


Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/e5deb393
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/e5deb393
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/e5deb393

Branch: refs/heads/asf-site
Commit: e5deb39336ae40dab08ac07c94f3bb221a53510f
Parents: b1d7329
Author: aditihilbert <ad...@runtime.io>
Authored: Thu Sep 1 14:00:29 2016 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Thu Sep 1 14:00:29 2016 -0700

----------------------------------------------------------------------
 develop/mkdocs/search_index.json          | 37 +++++++++----
 develop/os/modules/split/split/index.html | 72 ++++++++++++++++++--------
 develop/sitemap.xml                       | 20 +++----
 latest/sitemap.xml                        | 20 +++----
 sitemap.xml                               | 20 +++----
 v0_9_0/sitemap.xml                        | 20 +++----
 6 files changed, 115 insertions(+), 74 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/develop/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/develop/mkdocs/search_index.json b/develop/mkdocs/search_index.json
index d1e6f14..69e52de 100644
--- a/develop/mkdocs/search_index.json
+++ b/develop/mkdocs/search_index.json
@@ -4772,7 +4772,7 @@
         }, 
         {
             "location": "/os/modules/split/split/", 
-            "text": "Split Images\n\n\nDescription\n\n\nSplit images allow the user to build the application content separate from the library content by splitting an application into two pieces:\n\n\n\n\nA \"loader\" which contains a separate application that can perform upgrades and manage split images. The \"loader\" resides in slot 1.\n\n\nA \"split app\" which contains the main application content and references the libraries in the loader by static linkage. The \"split app\" resides in slot 2.\n\n\n\n\nGoals\n\n\nThe goal of split images is to allow a larger application to run along with large components of mynewt such as \nnimble BLE stack\n and \nneutron flash file system(nffs)\n.\n\n\nConcept\n\n\nIn a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image. 
  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.   \n\n\nOn a typical 256 kbyte flash, a flash layout might look like this:\n\n\n\n\n\n\n\n\nName\n\n\nSize\n\n\n\n\n\n\n\n\n\n\nbootloader\n\n\n16 k\n\n\n\n\n\n\nimage slot 1\n\n\n108 k\n\n\n\n\n\n\nimage slot 2\n\n\n108 k\n\n\n\n\n\n\nscratch\n\n\n8 k\n\n\n\n\n\n\nFlash file system\n\n\n16 k\n\n\n\n\n\n\n\n\nNow, suppose the desired image contains:\n\n\n\n\n\n\n\n\nPackage\n\n\nSize\n\n\n\n\n\n\n\n\n\n\nnimble\n\n\n69 k\n\n\n\n\n\n\nos\n\n\n6 k\n\n\n\n\n\n\nlogging\n\n\n3 k\n\n\n\n\n\n\nimagemgr\n\n\n3 k\n\n\n\n\n\n\nconfig\n\n\n3 k\n\n\n\n\n\n\nnffs\n\n\n15 k\n\n\n\n\n\n\nnewtmgr\n\n\n7 k\n\n\n\n\n\n\n\n\nwhich total 106k.  With an image slot size of 108k this leaves only a small amount of code space remaining for the application.\n\n\nHowever, we can see that these packages contain everything you need to upgrade and configure, so if we build a stand-alone loader 
 with these components, we can build the app as a split image and get the entire second image slot to store application code and constant data.\n\n\nWhen do I use split images\n\n\nIf your application fits into the available image slots, there is no advantage to using split images.  In general, split images are harder to debug and more complicated to upload. However for a larger application, there may not be enough flash space to have two copies of the entire application. This is when split image becomes necessary.\n\n\nHow do I tell Newt I am building a split image?\n\n\nNewt looks for the variable \nloader\n in your target file. If it finds \nloader\n variable, it will build a split image.  For example, \n\n\ntargets/app\n    app=@apache-mynewt-core/apps/splitty\n    loader=@apache-mynewt-core/apps/slinky\n    bsp=@apache-mynewt-core/hw/bsp/nrf52dk\n    build_profile=optimized\n\n\n\n\n\nshows an application called splitty which uses slinky as its loader.\n\n\nPlatforms\n\n\nSplit 
 image requires BSP support.  The following BSPs support split images:\n\n\n\n\nnrf52dk\n\n\n\n\nLoaders\n\n\nThe following applications have been enabled as loaders. You may choose to build your own loader application, and these can serve as samples.\n\n\n\n\n@apache-mynewt-core/apps/slinky\n\n\n@apache-mynewt-core/apps/bleprph\n\n\n\n\nSplit Apps\n\n\nThe following applications have been enabled as split applications. If you choose to build your own split application these can serve as samples. Note that slinky can be either a loader image or a split app image.\n\n\n\n\n@apache-mynewt-core/apps/slinky\n\n\n@apache-mynewt-core/apps/splitty\n\n\n\n\nTheory of Operation\n\n\nA split image is built as follows:\n\n\nFirst newt builds the \napp\n and \nloader\n images separately to ensure they are consistent (no errors) and to generate elf files which can inform newt of the symbols used by each part.\n\n\nThen newt collects the symbols used by both \napp\n and \nloader\n in two ways.  It
  collects the set of symbols from the \n.elf\n files. It also collects all the possible symbols from the \n.a\n files for each application.\n\n\nNewt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.  \n\n\nThen newt creates the list of symbols that the two applications share from those packages (using the .elf files).\n\n\nNewt re-links the loader to ensure all of these symbols are present in the loader application (by forcing the linker to include them in the \n.elf\n).  \n\n\nNewt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking section above).\n\n\nFinally, newt links the application, replacing the common .a libraries with the special loader.elf image d
 uring the link. \n\n\nDesign\n\n\nBootloader\n\n\nThe bootloader has been modified to support \"non bootable\" images like split app images.  A flag in the image header denotes the image as \"non-bootable\". When this flag is set, the bootloader will not boot the split app image, nor will it copy it to the slot 1 location. Loader images are bootable, split app images are not.\n\n\nNewt\n\n\nNewt builds a split image when the token \nloader=@apache-mynewt-core/apps/slinky\n is present in the target file.\n\n\nNewt has a \nBuilder\n object that is responsible for building an image.  This features a \ntargetBuilder\n object that contains two builders (one for the app and one for the loader).\n\n\nThe \nBuilder\n object has been expanded to include options for building as part of a split image.\n\n Ability to specify the linker file during the link\n\n Ability to specify a set of keep_symbols during the link\n\n\nNewt commands like download, size, create-image have been expanded to perf
 orm operations twice (once for loader and once for app) if the loader target is present.\n\n\nDuring normal single-image builds, the \ntargetBuilder\n initializes and builds the application \nbuilder\n. During the split image build, the \ntargetBuilder\n performs the steps outlined in the section above using the two \nbuilder\ns for the loader and app.\n\n\nSpecial symbol and link features are designed as follows:\n\n\n\n\nNewt uses objdump to parse the symbol maps in the \n.a\n and \n.elf\n files. \n\n\nNewt uses the \n--undefined=\n option of the linker to force the loader to keep symbols used by the app (but not used by the linker)\n\n\nNewt uses objcopy with the \n-K\n (keep) option when building the special linker \n.elf\n.\n\n\nNewt uses the \n--just-symbols\n option of the linker to link against the loader \n.elf\n file.  \n\n\n\n\nnewt create-image\n\n\nCreate image uses two different methods to compute the image hash for standard and split images.  For split images, the has
 h is computed starting with the 32-byte hash of the loader, then continuing with the hashing algorithm used by the standard application.  This ensures that the split app can be \"validated\" against a loader image specifically.  \n\n\nnewt errors\n\n\nNewt has several new build errors when building split images.  \n\n\n\n\nLinker script undefined.  If the BSP for your application does not define a split image linker script the build will fail.\n\n\n\n\nIf newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when \n#ifdef\n or features are included in one app and not the other.  For example, it the loader includes \nlibs/console/stubs\n and the app includes \nlibs/console/full\n this may change implementations of certain functions within other packages.  \n\n\nImage manifest\n\n\nnewt builds a single manifest for split images, adding extra tags to the mani
 fest when the image is a split image.\n\n\n  \nloader\n: \nslinky.img\n,\n  \nloader_hash\n: \n55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n,\n    \nloader_pkgs\n: [\n        ...\n        ]\n\n\n\n\n\nThe manifest lists packages in both the loader and app.  The app package list only contains those packages that reside in the app image itself.  \n\n\nlibs/bootutil\n\n\nBootutil has been expanded to include a function that looks for a split app image in slot 2, verifies that it matches the loader image in slot 1 and then fetches the entry information for the split app.\n\n\nlibs/split\n\n\nA small split image library was created to provide newtmgr commands for split image and to hold the configuration for split image. See newtmgr below for details.\n\n\nIt also contains the function used by a loader to validate and boot a split image.  \n\n\napps/slinky\n\n\nA sample app that can be built as a split image with slinky.\n\n\nTips when Building Split images\n\n\nTo b
 e added\n\n\nAdding BSP support for split images\n\n\nA BSP needs additional components to be \"split image ready\".\n\n\nThe split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition).  It needs to reserve space for RAM used by the loader.  It also does not need to include the vector table (just a bit of it).\n\n\nThe startup of the split image is different than a typical image.  It needs to copy \n.data\n from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.  \n\n\nSeveral of the bsp scripts need to handle additional agruments to deal with the two images produced by newt when building split images - mainly download and debug.\n\n\nAdd the following components to enab
 le your BSP for split images:\n\n\n\n\nA split image linker file\n\n\nA startup file for the split image\n\n\nA property in the pkg.yml file to tell newt what linker script to use for partition 2 images.  The property is defined as \npkg.part2linkerscript: \"split-nrf52dk.ld\n for example.\n\n\nModified download script\n\n\n\n\nAn example can be found in the \n/hw/bsp/nrf52dk\n\n\nsplit image linker script\n\n\nThe split image linker script must have the following.\n\n\nThe split linker must define the entry symbol as Reset_Handler_split.   For example:\n\n\nENTRY(Reset_Handler_split)\n\n\n\n\n\nThe split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:\n\n\n    .text :\n    {\n        __split_isr_vector_start = .;\n        KEEP(*(.isr_vector_split))\n        __split_isr_vector_end = .;\n
         ...     \n\n\n\n\n\nThe split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are both using RAM).  Note, the two apps don't run at the same time, but the loader has global data that its libraries use.  This cannot be overwritten by the application. An example linker section that accomplishes this can be found in \n/hw/bsp/nrf52dk/split-nrf52dk.ld\n. When linking against the loader, the loader exports the following symbosl which can be used by the split app code:\n\n\n\n\n__HeapBase_loader\n\n\n__bss_start___loader\n\n\n__bss_end___loader\n\n\n__etext_loader\n\n\n__data_start___loader\n\n\n__data_end___loader\n\n\n\n\nThe split app linker can use \n__HeapBase_loader\n to skip RAM used by the loader as follows.\n\n\n    /* save RAM used by the split image. This assumes that \n     * the loader uses all the RAM up to its HeapBase  */\n    .loader_ram_contents :\n    {\n        _loader_ram_start = .;\n\n    /* this symbol comes from th
 e loader linker */\n    . = . + (ABSOLUTE(__HeapBase_loader) - _loader_ram_start);\n        _loader_ram_end = .;\n    } \n RAM\n\n\n\n\n\nsplit image startup code\n\n\nThe split application needs separate startup code to intialize the split image before running main.  THe split image is specially linked so that _start and main are included individually for the loader and split app.\n\n\nThe split app startup code must have the following.\n\n\n\n\nA definition of the split image vector table (first two words). \n\n\nThe entry point function to start the code \nReset_Handler_split\n\n\nCode that copies the .data section for the loader from Flash to RAM\n\n\nCode that zeros the .bss section for the loader.\n\n\nCode that calls _sbrkInit to set the heap pointers for the application\n\n\n\n\nAn example can be found in the \n/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s\n\n\nnewtmgr and split Images\n\n\nnewtmgr has support for split images.\n\n\nnewtmgr image list2\n lists
  the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.\n\n\nImages:\n slot=1\n    version=1.2.3\n    bootable=true\n    hash=55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n slot=2\n    version=1.2.3\n    bootable=false\n    hash=1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe\n\n\n\n\n\nThe bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the \nboot2\n command to instruct mynewt to boot slot 2.  \n\n\nInstead, use the new \nsplit status\n command to see the status of split images and to set their boot status.  The split status command with no arguments returns status of the split image.  The Split Value tells the loader how to boot the split app. Options are:\n\n\n\n\nnone\n Don't boot the split application. Just remain running in the loader.\n\n\ntest\n Boot the split application, but revert back to the loader on the next reset.\n\n\nrun\n
  Boot the split application.\n\n\n\n\nThe split status command also verified the hash of the split application (using the hash of the loader as shown above) and returns the status of the check (matching or non-matching).\n\n\nnewtmgr -c connection split status \n  Split value is none\n  Split status is matching\n\n\n\n\n\nWhen the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:\n\n\nprompt$ newtmgr -c foo1 image boot2\n   Test image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Main image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Active img: 1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe\n\n\n\n\n\nUpgrading a split image with newtmgr\n\n\nWhen running via newt, the \nnewt load\n command will load both parts of a split image, the loader and application.\n\n\nWhen running via newtmgr a sequence of commands is required to
  upgrade.  Assuming you are running the split app in \nrun\n mode the following sequence will upgrade\n\n\n\n\nnewtmgr split status none\n\n\nnewtmgr reboot\n\n\nnewtmgr image upload \n\n\nnewtmgr image boot2 \n\n\nnewtmgr reboot\n\n\nnewtmgr image upload \n\n\nnewtmgr split status test\n\n\nnewtmgr reboot\n\n\nnewtmgr boot2 (check status to ensure new app is running)\n\n\nnewtmgr split status run\n\n\n\n\nThis upgrade is robust.  In all steps there is a loader image that is capable of upgrading (or reverting) images.", 
+            "text": "Split Images\n\n\nDescription\n\n\nSplit images allow the user to build the application content separate from the library content by splitting an application into two pieces:\n\n\n\n\nA \"loader\" which contains a separate application that can perform upgrades and manage split images. The \"loader\" resides in slot 1.\n\n\nA \"split app\" which contains the main application content and references the libraries in the loader by static linkage. The \"split app\" resides in slot 2.\n\n\n\n\nGoals\n\n\nThe goal of split images is to allow a larger application to run along with large components of mynewt such as \nnimble BLE stack\n and \nneutron flash file system(nffs)\n.\n\n\nConcept\n\n\nIn a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image. 
  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.\n\n\nOn a typical 256 kbyte flash, a flash layout might look like this:\n\n\n\n\n\n\n\n\nName\n\n\nSize\n\n\n\n\n\n\n\n\n\n\nbootloader\n\n\n16 k\n\n\n\n\n\n\nimage slot 1\n\n\n108 k\n\n\n\n\n\n\nimage slot 2\n\n\n108 k\n\n\n\n\n\n\nscratch\n\n\n8 k\n\n\n\n\n\n\nFlash file system\n\n\n16 k\n\n\n\n\n\n\n\n\nNow, suppose the desired image contains:\n\n\n\n\n\n\n\n\nPackage\n\n\nSize\n\n\n\n\n\n\n\n\n\n\nnimble\n\n\n69 k\n\n\n\n\n\n\nos\n\n\n6 k\n\n\n\n\n\n\nlogging\n\n\n3 k\n\n\n\n\n\n\nimagemgr\n\n\n3 k\n\n\n\n\n\n\nconfig\n\n\n3 k\n\n\n\n\n\n\nnffs\n\n\n15 k\n\n\n\n\n\n\nnewtmgr\n\n\n7 k\n\n\n\n\n\n\n\n\nwhich total 106k.  With an image slot size of 108k this leaves only a small amount of code space remaining for the application.\n\n\nHowever, we can see that these packages contain everything you need to upgrade and configure, so if we build a stand-alone loader wit
 h these components, we can build the app as a split image and get the entire second image slot to store application code and constant data.\n\n\nWhen do I use split images\n\n\nIf your application fits into the available image slots, there is no advantage to using split images.  In general, split images are harder to debug and more complicated to upload. However for a larger application, there may not be enough flash space to have two copies of the entire application. This is when split image becomes necessary.\n\n\nHow do I tell Newt I am building a split image?\n\n\nNewt looks for the variable \nloader\n in your target file. If it finds \nloader\n variable, it will build a split image.  For example,\n\n\ntargets/app\n    app=@apache-mynewt-core/apps/splitty\n    loader=@apache-mynewt-core/apps/slinky\n    bsp=@apache-mynewt-core/hw/bsp/nrf52dk\n    build_profile=optimized\n\n\n\n\n\nshows an application called splitty which uses slinky as its loader.\n\n\nPlatforms\n\n\nSplit imag
 e requires BSP support.  The following BSPs support split images:\n\n\n\n\nhw/bsp/arduino_primo_nrf52\n\n\nhw/bsp/bmd300eval\n\n\nhw/bsp/nrf51-blenano\n\n\nhw/bsp/nrf51dk\n\n\nhw/bsp/nrf51dk-16kbram\n\n\nhw/bsp/nrf52dk\n\n\n\n\nLoaders\n\n\nThe following applications have been enabled as loaders. You may choose to build your own loader application, and these can serve as samples.\n\n\n\n\n@apache-mynewt-core/apps/slinky\n\n\n@apache-mynewt-core/apps/bleprph\n\n\n\n\nSplit Apps\n\n\nThe following applications have been enabled as split applications. If you choose to build your own split application these can serve as samples. Note that slinky can be either a loader image or a split app image.\n\n\n\n\n@apache-mynewt-core/apps/slinky\n\n\n@apache-mynewt-core/apps/splitty\n\n\n\n\nTheory of Operation\n\n\nA split image is built as follows:\n\n\nFirst newt builds the \napp\n and \nloader\n images separately to ensure they are consistent (no errors) and to generate elf files which can in
 form newt of the symbols used by each part.\n\n\nThen newt collects the symbols used by both \napp\n and \nloader\n in two ways.  It collects the set of symbols from the \n.elf\n files. It also collects all the possible symbols from the \n.a\n files for each application.\n\n\nNewt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.\n\n\nThen newt creates the list of symbols that the two applications share from those packages (using the .elf files).\n\n\nNewt re-links the loader to ensure all of these symbols are present in the loader application (by forcing the linker to include them in the \n.elf\n).\n\n\nNewt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking
  section above).\n\n\nFinally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link.\n\n\nDesign\n\n\nBootloader\n\n\nThe bootloader has been modified to support \"non bootable\" images like split app images.  A flag in the image header denotes the image as \"non-bootable\". When this flag is set, the bootloader will not boot the split app image, nor will it copy it to the slot 1 location. Loader images are bootable, split app images are not.\n\n\nNewt\n\n\nNewt builds a split image when the token \nloader=@apache-mynewt-core/apps/slinky\n is present in the target file.\n\n\nNewt has a \nBuilder\n object that is responsible for building an image.  This features a \ntargetBuilder\n object that contains two builders (one for the app and one for the loader).\n\n\nThe \nBuilder\n object has been expanded to include options for building as part of a split image.\n\n Ability to specify the linker file during the link\n\n Ability t
 o specify a set of keep_symbols during the link\n\n\nNewt commands like download, size, create-image have been expanded to perform operations twice (once for loader and once for app) if the loader target is present.\n\n\nDuring normal single-image builds, the \ntargetBuilder\n initializes and builds the application \nbuilder\n. During the split image build, the \ntargetBuilder\n performs the steps outlined in the section above using the two \nbuilder\ns for the loader and app.\n\n\nSpecial symbol and link features are designed as follows:\n\n\n\n\nNewt uses objdump to parse the symbol maps in the \n.a\n and \n.elf\n files.\n\n\nNewt uses the \n--undefined=\n option of the linker to force the loader to keep symbols used by the app (but not used by the linker)\n\n\nNewt uses objcopy with the \n-K\n (keep) option when building the special linker \n.elf\n.\n\n\nNewt uses the \n--just-symbols\n option of the linker to link against the loader \n.elf\n file.\n\n\n\n\nnewt create-image\n\n\
 nCreate image uses two different methods to compute the image hash for standard and split images.  For split images, the hash is computed starting with the 32-byte hash of the loader, then continuing with the hashing algorithm used by the standard application.  This ensures that the split app can be \"validated\" against a loader image specifically.\n\n\nnewt errors\n\n\nNewt has several new build errors when building split images.\n\n\n\n\nLinker script undefined.  If the BSP for your application does not define a split image linker script the build will fail.\n\n\n\n\nIf newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when \n#ifdef\n or features are included in one app and not the other.  For example, it the loader includes \nlibs/console/stubs\n and the app includes \nlibs/console/full\n this may change implementations of certain functions within 
 other packages.\n\n\nImage manifest\n\n\nnewt builds a single manifest for split images, adding extra tags to the manifest when the image is a split image.\n\n\n  \nloader\n: \nslinky.img\n,\n  \nloader_hash\n: \n55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n,\n    \nloader_pkgs\n: [\n        ...\n        ]\n\n\n\n\n\nThe manifest lists packages in both the loader and app.  The app package list only contains those packages that reside in the app image itself.\n\n\nlibs/bootutil\n\n\nBootutil has been expanded to include a function that looks for a split app image in slot 2, verifies that it matches the loader image in slot 1 and then fetches the entry information for the split app.\n\n\nlibs/split\n\n\nA small split image library was created to provide newtmgr commands for split image and to hold the configuration for split image. See newtmgr below for details.\n\n\nIt also contains the function used by a loader to validate and boot a split image.\n\n\napps/slink
 y\n\n\nA sample app that can be built as a split image with slinky.\n\n\nTips when Building Split images\n\n\nTo be added\n\n\nAdding BSP support for split images\n\n\nA BSP needs additional components to be \"split image ready\".\n\n\nThe split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition).  It needs to reserve space for RAM used by the loader.  It also does not need to include the vector table (just a bit of it).\n\n\nThe startup of the split image is different than a typical image.  It needs to copy \n.data\n from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.\n\n\nSeveral of the bsp scripts need to handle additional agruments to deal with the two images pr
 oduced by newt when building split images - mainly download and debug.\n\n\nAdd the following components to enable your BSP for split images:\n\n\n\n\nA split image linker file\n\n\nA startup file for the split image\n\n\nA property in the pkg.yml file to tell newt what linker script to use for partition 2 images.  The property is defined as \npkg.part2linkerscript: \"split-nrf52dk.ld\n for example.\n\n\nModified download script\n\n\nModified sbrk functionality\n\n\n\n\nAn example can be found in the \n/hw/bsp/nrf52dk\n\n\nsplit image linker script\n\n\nThe split image linker script must have the following.\n\n\nThe split linker must be linked to run from the second flash image slot. For example:\n\n\nMEMORY\n{\n  FLASH (rx) : ORIGIN =  0x00042000, LENGTH = 0x3a000\n  RAM  (rwx) : ORIGIN =  0x20000000, LENGTH = 0x10000\n}\n\n\n\n\n\nThe split linker must define the entry symbol as Reset_Handler_split.   For example:\n\n\nENTRY(Reset_Handler_split)\n\n\n\n\n\nThe split linker must de
 fine the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader and are not needed in the split image. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:\n\n\n    .text :\n    {\n        __split_isr_vector_start = .;\n        KEEP(*(.isr_vector_split))\n        __split_isr_vector_end = .;\n        ...     \n\n\n\n\n\nThe split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are both using RAM).  Note, the two apps don't run at the same time, but the loader has global data that its libraries use.  This cannot be overwritten by the application. An example linker section that accomplishes this can be found in \n/hw/bsp/nrf52dk/split-nrf52dk.ld\n. When linking against the loader, the loader exports the following symbosl which can be used by the split app code:\n\n\n\n\n__HeapBase_loader\n\n\n__bss_start___loader\n\n\n__bss_end___
 loader\n\n\n__etext_loader\n\n\n__data_start___loader\n\n\n__data_end___loader\n\n\n\n\nThe split app linker can use \n__HeapBase_loader\n to skip RAM used by the loader as follows.\n\n\n    /* save RAM used by the split image. This assumes that\n     * the loader uses all the RAM up to its HeapBase  */\n    .loader_ram_contents :\n    {\n        _loader_ram_start = .;\n\n    /* this symbol comes from the loader linker */\n    . = . + (ABSOLUTE(__HeapBase_loader) - _loader_ram_start);\n        _loader_ram_end = .;\n    } \n RAM\n\n\n\n\n\nsplit image startup code\n\n\nThe split application needs separate startup code to intialize the split image before running main.  THe split image is specially linked so that _start and main are included individually for the loader and split app.\n\n\nThe split app startup code must have the following.\n\n\n\n\nA definition of the split image vector table (first two words).\n\n\nThe entry point function to start the code \nReset_Handler_split\n\n\n
 Code that copies the .data section for the loader from Flash to RAM\n\n\nCode that zeros the .bss section for the loader.\n\n\nCode that calls _sbrkInit to set the heap pointers for the application (see below)\n\n\nCode that calls the \nbsp_slot_init_split_application\n function (see below)\n\n\n\n\nAn example can be found in the \n/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s\n\n\nDownload script\n\n\nThe download script needs to be modified to include support for passing the image slot number in the build.  Image slots are referenced as 0 and 1. Loading bootloaders ignore the image slot numbers.\n\n\nSee and example in \n/hw/bsp/bmd300eval/bmd300eval_download.sh\n.\n\n\nSbrk functionality\n\n\nSplit image (either a loader or app) references a single set of heap managment functions.  But the heap location and size is different depending which image is running.  Special functionality is needed to handle the dynamic setting of the heap base and limit.\n\n\nInstead of h
 ard-coding the heap base and limit at link time (depending on the size of data and bss), sbrk needs to be dynamically initialized with these values from the startup code.\n\n\nSee an example in \n/hw/bsp/bmd300eval/src/sbrk.c\n in the core repository.  The function \n_sbrkInit\n must be called from the startup code of the split image and normal image startup code with the appropriate values of heap base and limit.\n\n\nSlot Init\n\n\nA global variable tells mynewt whether the split image is runnning as just a stand-alone loader, or as the combined loader/app image.  Its the responsibility of the startup code to set this global variable.\n\n\nSee \nhw/bsp/bmd300eval/src/os_bsp.c\n for and implementation of the functionality.\n\n\nnewtmgr and split Images\n\n\nnewtmgr has support for split images.\n\n\nnewtmgr image list\n lists the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.\n\n\nImages:\n slot=1\n    version=1.2.3\n    boo
 table=true\n    hash=55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n slot=2\n    version=1.2.3\n    bootable=false\n    hash=1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe\n\n\n\n\n\nThe bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the \nboot2\n command to instruct mynewt to boot slot 2.\n\n\nInstead, use the new \nsplit status\n command to see the status of split images and to set their boot status.  The split status command with no arguments returns status of the split image.  The Split Value tells the loader how to boot the split app. Options are:\n\n\n\n\nnone\n Don't boot the split application. Just remain running in the loader.\n\n\ntest\n Boot the split application, but revert back to the loader on the next reset.\n\n\nrun\n Boot the split application.\n\n\n\n\nThe split status command also verified the hash of the split application (using the hash of the loader as shown above) and 
 returns the status of the check (matching or non-matching).\n\n\nnewtmgr -c connection split status\n  Split value is none\n  Split status is matching\n\n\n\n\n\nWhen the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:\n\n\nprompt$ newtmgr -c foo1 image boot\n   Test image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Main image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Active img: 1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe\n\n\n\n\n\nUpgrading a split image with newtmgr\n\n\nWhen running via newt, the \nnewt load\n command will load both parts of a split image, the loader and application.\n\n\nWhen running via newtmgr a sequence of commands is required to upgrade.  Assuming you are running the split app in \nrun\n mode the following sequence will upgrade\n\n\n\n\nnewtmgr split status none\n\n\nnewtmgr reboot\n\n\nn
 ewtmgr image upload \n\n\nnewtmgr image boot2 \n\n\nnewtmgr reboot\n\n\nnewtmgr image upload \n\n\nnewtmgr split status test\n\n\nnewtmgr reboot\n\n\nnewtmgr boot2 (check status to ensure new app is running)\n\n\nnewtmgr split status run\n\n\n\n\nThis upgrade is robust.  In all steps there is a loader image that is capable of upgrading (or reverting) images.", 
             "title": "toc"
         }, 
         {
@@ -4792,7 +4792,7 @@
         }, 
         {
             "location": "/os/modules/split/split/#concept", 
-            "text": "In a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image.  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.     On a typical 256 kbyte flash, a flash layout might look like this:     Name  Size      bootloader  16 k    image slot 1  108 k    image slot 2  108 k    scratch  8 k    Flash file system  16 k     Now, suppose the desired image contains:     Package  Size      nimble  69 k    os  6 k    logging  3 k    imagemgr  3 k    config  3 k    nffs  15 k    newtmgr  7 k     which total 106k.  With an image slot size of 108k this leaves only a small amount of code space remaining for the application.  However, we can see that these packages contain everything you need to upgra
 de and configure, so if we build a stand-alone loader with these components, we can build the app as a split image and get the entire second image slot to store application code and constant data.", 
+            "text": "In a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image.  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.  On a typical 256 kbyte flash, a flash layout might look like this:     Name  Size      bootloader  16 k    image slot 1  108 k    image slot 2  108 k    scratch  8 k    Flash file system  16 k     Now, suppose the desired image contains:     Package  Size      nimble  69 k    os  6 k    logging  3 k    imagemgr  3 k    config  3 k    nffs  15 k    newtmgr  7 k     which total 106k.  With an image slot size of 108k this leaves only a small amount of code space remaining for the application.  However, we can see that these packages contain everything you need to upgrade 
 and configure, so if we build a stand-alone loader with these components, we can build the app as a split image and get the entire second image slot to store application code and constant data.", 
             "title": "Concept"
         }, 
         {
@@ -4802,12 +4802,12 @@
         }, 
         {
             "location": "/os/modules/split/split/#how-do-i-tell-newt-i-am-building-a-split-image", 
-            "text": "Newt looks for the variable  loader  in your target file. If it finds  loader  variable, it will build a split image.  For example,   targets/app\n    app=@apache-mynewt-core/apps/splitty\n    loader=@apache-mynewt-core/apps/slinky\n    bsp=@apache-mynewt-core/hw/bsp/nrf52dk\n    build_profile=optimized  shows an application called splitty which uses slinky as its loader.", 
+            "text": "Newt looks for the variable  loader  in your target file. If it finds  loader  variable, it will build a split image.  For example,  targets/app\n    app=@apache-mynewt-core/apps/splitty\n    loader=@apache-mynewt-core/apps/slinky\n    bsp=@apache-mynewt-core/hw/bsp/nrf52dk\n    build_profile=optimized  shows an application called splitty which uses slinky as its loader.", 
             "title": "How do I tell Newt I am building a split image?"
         }, 
         {
             "location": "/os/modules/split/split/#platforms", 
-            "text": "Split image requires BSP support.  The following BSPs support split images:   nrf52dk", 
+            "text": "Split image requires BSP support.  The following BSPs support split images:   hw/bsp/arduino_primo_nrf52  hw/bsp/bmd300eval  hw/bsp/nrf51-blenano  hw/bsp/nrf51dk  hw/bsp/nrf51dk-16kbram  hw/bsp/nrf52dk", 
             "title": "Platforms"
         }, 
         {
@@ -4822,7 +4822,7 @@
         }, 
         {
             "location": "/os/modules/split/split/#theory-of-operation", 
-            "text": "A split image is built as follows:  First newt builds the  app  and  loader  images separately to ensure they are consistent (no errors) and to generate elf files which can inform newt of the symbols used by each part.  Then newt collects the symbols used by both  app  and  loader  in two ways.  It collects the set of symbols from the  .elf  files. It also collects all the possible symbols from the  .a  files for each application.  Newt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.    Then newt creates the list of symbols that the two applications share from those packages (using the .elf files).  Newt re-links the loader to ensure all of these symbols are present in the loader application (by forci
 ng the linker to include them in the  .elf ).    Newt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking section above).  Finally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link.", 
+            "text": "A split image is built as follows:  First newt builds the  app  and  loader  images separately to ensure they are consistent (no errors) and to generate elf files which can inform newt of the symbols used by each part.  Then newt collects the symbols used by both  app  and  loader  in two ways.  It collects the set of symbols from the  .elf  files. It also collects all the possible symbols from the  .a  files for each application.  Newt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.  Then newt creates the list of symbols that the two applications share from those packages (using the .elf files).  Newt re-links the loader to ensure all of these symbols are present in the loader application (by forcing
  the linker to include them in the  .elf ).  Newt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking section above).  Finally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link.", 
             "title": "Theory of Operation"
         }, 
         {
@@ -4837,7 +4837,7 @@
         }, 
         {
             "location": "/os/modules/split/split/#newt", 
-            "text": "Newt builds a split image when the token  loader=@apache-mynewt-core/apps/slinky  is present in the target file.  Newt has a  Builder  object that is responsible for building an image.  This features a  targetBuilder  object that contains two builders (one for the app and one for the loader).  The  Builder  object has been expanded to include options for building as part of a split image.  Ability to specify the linker file during the link  Ability to specify a set of keep_symbols during the link  Newt commands like download, size, create-image have been expanded to perform operations twice (once for loader and once for app) if the loader target is present.  During normal single-image builds, the  targetBuilder  initializes and builds the application  builder . During the split image build, the  targetBuilder  performs the steps outlined in the section above using the two  builder s for the loader and app.  Special symbol and link features are designed as follow
 s:   Newt uses objdump to parse the symbol maps in the  .a  and  .elf  files.   Newt uses the  --undefined=  option of the linker to force the loader to keep symbols used by the app (but not used by the linker)  Newt uses objcopy with the  -K  (keep) option when building the special linker  .elf .  Newt uses the  --just-symbols  option of the linker to link against the loader  .elf  file.", 
+            "text": "Newt builds a split image when the token  loader=@apache-mynewt-core/apps/slinky  is present in the target file.  Newt has a  Builder  object that is responsible for building an image.  This features a  targetBuilder  object that contains two builders (one for the app and one for the loader).  The  Builder  object has been expanded to include options for building as part of a split image.  Ability to specify the linker file during the link  Ability to specify a set of keep_symbols during the link  Newt commands like download, size, create-image have been expanded to perform operations twice (once for loader and once for app) if the loader target is present.  During normal single-image builds, the  targetBuilder  initializes and builds the application  builder . During the split image build, the  targetBuilder  performs the steps outlined in the section above using the two  builder s for the loader and app.  Special symbol and link features are designed as follow
 s:   Newt uses objdump to parse the symbol maps in the  .a  and  .elf  files.  Newt uses the  --undefined=  option of the linker to force the loader to keep symbols used by the app (but not used by the linker)  Newt uses objcopy with the  -K  (keep) option when building the special linker  .elf .  Newt uses the  --just-symbols  option of the linker to link against the loader  .elf  file.", 
             "title": "Newt"
         }, 
         {
@@ -4847,7 +4847,7 @@
         }, 
         {
             "location": "/os/modules/split/split/#newt-errors", 
-            "text": "Newt has several new build errors when building split images.     Linker script undefined.  If the BSP for your application does not define a split image linker script the build will fail.   If newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when  #ifdef  or features are included in one app and not the other.  For example, it the loader includes  libs/console/stubs  and the app includes  libs/console/full  this may change implementations of certain functions within other packages.", 
+            "text": "Newt has several new build errors when building split images.   Linker script undefined.  If the BSP for your application does not define a split image linker script the build will fail.   If newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when  #ifdef  or features are included in one app and not the other.  For example, it the loader includes  libs/console/stubs  and the app includes  libs/console/full  this may change implementations of certain functions within other packages.", 
             "title": "newt errors"
         }, 
         {
@@ -4877,22 +4877,37 @@
         }, 
         {
             "location": "/os/modules/split/split/#adding-bsp-support-for-split-images", 
-            "text": "A BSP needs additional components to be \"split image ready\".  The split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition).  It needs to reserve space for RAM used by the loader.  It also does not need to include the vector table (just a bit of it).  The startup of the split image is different than a typical image.  It needs to copy  .data  from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.    Several of the bsp scripts need to handle additional agruments to deal with the two images produced by newt when building split images - mainly download and debug.  Add the following components to enable your BSP for split images:   A split image linke
 r file  A startup file for the split image  A property in the pkg.yml file to tell newt what linker script to use for partition 2 images.  The property is defined as  pkg.part2linkerscript: \"split-nrf52dk.ld  for example.  Modified download script   An example can be found in the  /hw/bsp/nrf52dk", 
+            "text": "A BSP needs additional components to be \"split image ready\".  The split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition).  It needs to reserve space for RAM used by the loader.  It also does not need to include the vector table (just a bit of it).  The startup of the split image is different than a typical image.  It needs to copy  .data  from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.  Several of the bsp scripts need to handle additional agruments to deal with the two images produced by newt when building split images - mainly download and debug.  Add the following components to enable your BSP for split images:   A split image linker 
 file  A startup file for the split image  A property in the pkg.yml file to tell newt what linker script to use for partition 2 images.  The property is defined as  pkg.part2linkerscript: \"split-nrf52dk.ld  for example.  Modified download script  Modified sbrk functionality   An example can be found in the  /hw/bsp/nrf52dk", 
             "title": "Adding BSP support for split images"
         }, 
         {
             "location": "/os/modules/split/split/#split-image-linker-script", 
-            "text": "The split image linker script must have the following.  The split linker must define the entry symbol as Reset_Handler_split.   For example:  ENTRY(Reset_Handler_split)  The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:      .text :\n    {\n        __split_isr_vector_start = .;\n        KEEP(*(.isr_vector_split))\n        __split_isr_vector_end = .;\n        ...       The split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are both using RAM).  Note, the two apps don't run at the same time, but the loader has global data that its libraries use.  This cannot be overwritten by the application. An example linker section that accomplishes this can be found in  /hw/bsp/nrf52dk/split-nrf52dk.ld . When linking against the
  loader, the loader exports the following symbosl which can be used by the split app code:   __HeapBase_loader  __bss_start___loader  __bss_end___loader  __etext_loader  __data_start___loader  __data_end___loader   The split app linker can use  __HeapBase_loader  to skip RAM used by the loader as follows.      /* save RAM used by the split image. This assumes that \n     * the loader uses all the RAM up to its HeapBase  */\n    .loader_ram_contents :\n    {\n        _loader_ram_start = .;\n\n    /* this symbol comes from the loader linker */\n    . = . + (ABSOLUTE(__HeapBase_loader) - _loader_ram_start);\n        _loader_ram_end = .;\n    }   RAM", 
+            "text": "The split image linker script must have the following.  The split linker must be linked to run from the second flash image slot. For example:  MEMORY\n{\n  FLASH (rx) : ORIGIN =  0x00042000, LENGTH = 0x3a000\n  RAM  (rwx) : ORIGIN =  0x20000000, LENGTH = 0x10000\n}  The split linker must define the entry symbol as Reset_Handler_split.   For example:  ENTRY(Reset_Handler_split)  The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader and are not needed in the split image. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:      .text :\n    {\n        __split_isr_vector_start = .;\n        KEEP(*(.isr_vector_split))\n        __split_isr_vector_end = .;\n        ...       The split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are both using RAM).  Note, the two apps don't r
 un at the same time, but the loader has global data that its libraries use.  This cannot be overwritten by the application. An example linker section that accomplishes this can be found in  /hw/bsp/nrf52dk/split-nrf52dk.ld . When linking against the loader, the loader exports the following symbosl which can be used by the split app code:   __HeapBase_loader  __bss_start___loader  __bss_end___loader  __etext_loader  __data_start___loader  __data_end___loader   The split app linker can use  __HeapBase_loader  to skip RAM used by the loader as follows.      /* save RAM used by the split image. This assumes that\n     * the loader uses all the RAM up to its HeapBase  */\n    .loader_ram_contents :\n    {\n        _loader_ram_start = .;\n\n    /* this symbol comes from the loader linker */\n    . = . + (ABSOLUTE(__HeapBase_loader) - _loader_ram_start);\n        _loader_ram_end = .;\n    }   RAM", 
             "title": "split image linker script"
         }, 
         {
             "location": "/os/modules/split/split/#split-image-startup-code", 
-            "text": "The split application needs separate startup code to intialize the split image before running main.  THe split image is specially linked so that _start and main are included individually for the loader and split app.  The split app startup code must have the following.   A definition of the split image vector table (first two words).   The entry point function to start the code  Reset_Handler_split  Code that copies the .data section for the loader from Flash to RAM  Code that zeros the .bss section for the loader.  Code that calls _sbrkInit to set the heap pointers for the application   An example can be found in the  /hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s", 
+            "text": "The split application needs separate startup code to intialize the split image before running main.  THe split image is specially linked so that _start and main are included individually for the loader and split app.  The split app startup code must have the following.   A definition of the split image vector table (first two words).  The entry point function to start the code  Reset_Handler_split  Code that copies the .data section for the loader from Flash to RAM  Code that zeros the .bss section for the loader.  Code that calls _sbrkInit to set the heap pointers for the application (see below)  Code that calls the  bsp_slot_init_split_application  function (see below)   An example can be found in the  /hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s", 
             "title": "split image startup code"
         }, 
         {
+            "location": "/os/modules/split/split/#download-script", 
+            "text": "The download script needs to be modified to include support for passing the image slot number in the build.  Image slots are referenced as 0 and 1. Loading bootloaders ignore the image slot numbers.  See and example in  /hw/bsp/bmd300eval/bmd300eval_download.sh .", 
+            "title": "Download script"
+        }, 
+        {
+            "location": "/os/modules/split/split/#sbrk-functionality", 
+            "text": "Split image (either a loader or app) references a single set of heap managment functions.  But the heap location and size is different depending which image is running.  Special functionality is needed to handle the dynamic setting of the heap base and limit.  Instead of hard-coding the heap base and limit at link time (depending on the size of data and bss), sbrk needs to be dynamically initialized with these values from the startup code.  See an example in  /hw/bsp/bmd300eval/src/sbrk.c  in the core repository.  The function  _sbrkInit  must be called from the startup code of the split image and normal image startup code with the appropriate values of heap base and limit.", 
+            "title": "Sbrk functionality"
+        }, 
+        {
+            "location": "/os/modules/split/split/#slot-init", 
+            "text": "A global variable tells mynewt whether the split image is runnning as just a stand-alone loader, or as the combined loader/app image.  Its the responsibility of the startup code to set this global variable.  See  hw/bsp/bmd300eval/src/os_bsp.c  for and implementation of the functionality.", 
+            "title": "Slot Init"
+        }, 
+        {
             "location": "/os/modules/split/split/#newtmgr-and-split-images", 
-            "text": "newtmgr has support for split images.  newtmgr image list2  lists the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.  Images:\n slot=1\n    version=1.2.3\n    bootable=true\n    hash=55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n slot=2\n    version=1.2.3\n    bootable=false\n    hash=1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe  The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the  boot2  command to instruct mynewt to boot slot 2.    Instead, use the new  split status  command to see the status of split images and to set their boot status.  The split status command with no arguments returns status of the split image.  The Split Value tells the loader how to boot the split app. Options are:   none  Don't boot the split application. Just remain running in the loader.  test  Boot the split application, but reve
 rt back to the loader on the next reset.  run  Boot the split application.   The split status command also verified the hash of the split application (using the hash of the loader as shown above) and returns the status of the check (matching or non-matching).  newtmgr -c connection split status \n  Split value is none\n  Split status is matching  When the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:  prompt$ newtmgr -c foo1 image boot2\n   Test image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Main image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Active img: 1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe", 
+            "text": "newtmgr has support for split images.  newtmgr image list  lists the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.  Images:\n slot=1\n    version=1.2.3\n    bootable=true\n    hash=55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n slot=2\n    version=1.2.3\n    bootable=false\n    hash=1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe  The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the  boot2  command to instruct mynewt to boot slot 2.  Instead, use the new  split status  command to see the status of split images and to set their boot status.  The split status command with no arguments returns status of the split image.  The Split Value tells the loader how to boot the split app. Options are:   none  Don't boot the split application. Just remain running in the loader.  test  Boot the split application, but revert 
 back to the loader on the next reset.  run  Boot the split application.   The split status command also verified the hash of the split application (using the hash of the loader as shown above) and returns the status of the check (matching or non-matching).  newtmgr -c connection split status\n  Split value is none\n  Split status is matching  When the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:  prompt$ newtmgr -c foo1 image boot\n   Test image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Main image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0\n   Active img: 1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe", 
             "title": "newtmgr and split Images"
         }, 
         {

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/develop/os/modules/split/split/index.html
----------------------------------------------------------------------
diff --git a/develop/os/modules/split/split/index.html b/develop/os/modules/split/split/index.html
index 917caa3..0492489 100644
--- a/develop/os/modules/split/split/index.html
+++ b/develop/os/modules/split/split/index.html
@@ -500,7 +500,7 @@
 <h2 id="goals">Goals</h2>
 <p>The goal of split images is to allow a larger application to run along with large components of mynewt such as <a href="../../../../network/ble/ble_intro/">nimble BLE stack</a> and <a href="../../fs/nffs/nffs/">neutron flash file system(nffs)</a>.</p>
 <h2 id="concept">Concept</h2>
-<p>In a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image.  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.   </p>
+<p>In a typical mynewt application, an application is contained wholly within an image slot.  Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot.  Each image is capable of erasing and uploading another image.  Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.</p>
 <p>On a typical 256 kbyte flash, a flash layout might look like this:</p>
 <table>
 <thead>
@@ -576,7 +576,7 @@
 <h2 id="when-do-i-use-split-images">When do I use split images</h2>
 <p>If your application fits into the available image slots, there is no advantage to using split images.  In general, split images are harder to debug and more complicated to upload. However for a larger application, there may not be enough flash space to have two copies of the entire application. This is when split image becomes necessary.</p>
 <h2 id="how-do-i-tell-newt-i-am-building-a-split-image">How do I tell Newt I am building a split image?</h2>
-<p>Newt looks for the variable <code>loader</code> in your target file. If it finds <code>loader</code> variable, it will build a split image.  For example, </p>
+<p>Newt looks for the variable <code>loader</code> in your target file. If it finds <code>loader</code> variable, it will build a split image.  For example,</p>
 <div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">targets/app
     app=@apache-mynewt-core/apps/splitty
     loader=@apache-mynewt-core/apps/slinky
@@ -589,7 +589,12 @@
 <h2 id="platforms">Platforms</h2>
 <p>Split image requires BSP support.  The following BSPs support split images:</p>
 <ul>
-<li>nrf52dk</li>
+<li>hw/bsp/arduino_primo_nrf52</li>
+<li>hw/bsp/bmd300eval</li>
+<li>hw/bsp/nrf51-blenano</li>
+<li>hw/bsp/nrf51dk</li>
+<li>hw/bsp/nrf51dk-16kbram</li>
+<li>hw/bsp/nrf52dk</li>
 </ul>
 <h2 id="loaders">Loaders</h2>
 <p>The following applications have been enabled as loaders. You may choose to build your own loader application, and these can serve as samples.</p>
@@ -607,11 +612,11 @@
 <p>A split image is built as follows:</p>
 <p>First newt builds the <code>app</code> and <code>loader</code> images separately to ensure they are consistent (no errors) and to generate elf files which can inform newt of the symbols used by each part.</p>
 <p>Then newt collects the symbols used by both <code>app</code> and <code>loader</code> in two ways.  It collects the set of symbols from the <code>.elf</code> files. It also collects all the possible symbols from the <code>.a</code> files for each application.</p>
-<p>Newt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.  </p>
+<p>Newt builds the set of packages that the two applications share.  It ensures that all the symbols used in those packages are matching.  NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same.  In this case newt generates an error and will not build a split image.</p>
 <p>Then newt creates the list of symbols that the two applications share from those packages (using the .elf files).</p>
-<p>Newt re-links the loader to ensure all of these symbols are present in the loader application (by forcing the linker to include them in the <code>.elf</code>).  </p>
+<p>Newt re-links the loader to ensure all of these symbols are present in the loader application (by forcing the linker to include them in the <code>.elf</code>).</p>
 <p>Newt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking section above).</p>
-<p>Finally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link. </p>
+<p>Finally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link.</p>
 <h2 id="design">Design</h2>
 <h3 id="bootloader">Bootloader</h3>
 <p>The bootloader has been modified to support "non bootable" images like split app images.  A flag in the image header denotes the image as "non-bootable". When this flag is set, the bootloader will not boot the split app image, nor will it copy it to the slot 1 location. Loader images are bootable, split app images are not.</p>
@@ -625,19 +630,19 @@
 <p>During normal single-image builds, the <code>targetBuilder</code> initializes and builds the application <code>builder</code>. During the split image build, the <code>targetBuilder</code> performs the steps outlined in the section above using the two <code>builder</code>s for the loader and app.</p>
 <p>Special symbol and link features are designed as follows:</p>
 <ul>
-<li>Newt uses objdump to parse the symbol maps in the <code>.a</code> and <code>.elf</code> files. </li>
+<li>Newt uses objdump to parse the symbol maps in the <code>.a</code> and <code>.elf</code> files.</li>
 <li>Newt uses the <code>--undefined=</code> option of the linker to force the loader to keep symbols used by the app (but not used by the linker)</li>
 <li>Newt uses objcopy with the <code>-K</code> (keep) option when building the special linker <code>.elf</code>.</li>
-<li>Newt uses the <code>--just-symbols</code> option of the linker to link against the loader <code>.elf</code> file.  </li>
+<li>Newt uses the <code>--just-symbols</code> option of the linker to link against the loader <code>.elf</code> file.</li>
 </ul>
 <h4 id="newt-create-image">newt create-image</h4>
-<p>Create image uses two different methods to compute the image hash for standard and split images.  For split images, the hash is computed starting with the 32-byte hash of the loader, then continuing with the hashing algorithm used by the standard application.  This ensures that the split app can be "validated" against a loader image specifically.  </p>
+<p>Create image uses two different methods to compute the image hash for standard and split images.  For split images, the hash is computed starting with the 32-byte hash of the loader, then continuing with the hashing algorithm used by the standard application.  This ensures that the split app can be "validated" against a loader image specifically.</p>
 <h4 id="newt-errors">newt errors</h4>
-<p>Newt has several new build errors when building split images.  </p>
+<p>Newt has several new build errors when building split images.</p>
 <ul>
 <li>Linker script undefined.  If the BSP for your application does not define a split image linker script the build will fail.</li>
 </ul>
-<p>If newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when <code>#ifdef</code> or features are included in one app and not the other.  For example, it the loader includes <code>libs/console/stubs</code> and the app includes <code>libs/console/full</code> this may change implementations of certain functions within other packages.  </p>
+<p>If newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build.  These differences can arise when <code>#ifdef</code> or features are included in one app and not the other.  For example, it the loader includes <code>libs/console/stubs</code> and the app includes <code>libs/console/full</code> this may change implementations of certain functions within other packages.</p>
 <h3 id="image-manifest">Image manifest</h3>
 <p>newt builds a single manifest for split images, adding extra tags to the manifest when the image is a split image.</p>
 <div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">  &quot;loader&quot;: &quot;slinky.img&quot;,
@@ -648,12 +653,12 @@
 </pre></div>
 
 
-<p>The manifest lists packages in both the loader and app.  The app package list only contains those packages that reside in the app image itself.  </p>
+<p>The manifest lists packages in both the loader and app.  The app package list only contains those packages that reside in the app image itself.</p>
 <h3 id="libsbootutil">libs/bootutil</h3>
 <p>Bootutil has been expanded to include a function that looks for a split app image in slot 2, verifies that it matches the loader image in slot 1 and then fetches the entry information for the split app.</p>
 <h3 id="libssplit">libs/split</h3>
 <p>A small split image library was created to provide newtmgr commands for split image and to hold the configuration for split image. See newtmgr below for details.</p>
-<p>It also contains the function used by a loader to validate and boot a split image.  </p>
+<p>It also contains the function used by a loader to validate and boot a split image.</p>
 <h3 id="appsslinky">apps/slinky</h3>
 <p>A sample app that can be built as a split image with slinky.</p>
 <h2 id="tips-when-building-split-images">Tips when Building Split images</h2>
@@ -661,7 +666,7 @@
 <h2 id="adding-bsp-support-for-split-images">Adding BSP support for split images</h2>
 <p>A BSP needs additional components to be "split image ready".</p>
 <p>The split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition).  It needs to reserve space for RAM used by the loader.  It also does not need to include the vector table (just a bit of it).</p>
-<p>The startup of the split image is different than a typical image.  It needs to copy <code>.data</code> from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.  </p>
+<p>The startup of the split image is different than a typical image.  It needs to copy <code>.data</code> from the loader image, and zero the loader image bss.  For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.</p>
 <p>Several of the bsp scripts need to handle additional agruments to deal with the two images produced by newt when building split images - mainly download and debug.</p>
 <p>Add the following components to enable your BSP for split images:</p>
 <ol>
@@ -669,16 +674,26 @@
 <li>A startup file for the split image</li>
 <li>A property in the pkg.yml file to tell newt what linker script to use for partition 2 images.  The property is defined as <code>pkg.part2linkerscript: "split-nrf52dk.ld</code> for example.</li>
 <li>Modified download script</li>
+<li>Modified sbrk functionality</li>
 </ol>
 <p>An example can be found in the <code>/hw/bsp/nrf52dk</code></p>
 <h3 id="split-image-linker-script">split image linker script</h3>
 <p>The split image linker script must have the following.</p>
+<p>The split linker must be linked to run from the second flash image slot. For example:</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">MEMORY
+{
+  FLASH (rx) : ORIGIN =  0x00042000, LENGTH = 0x3a000
+  RAM  (rwx) : ORIGIN =  0x20000000, LENGTH = 0x10000
+}
+</pre></div>
+
+
 <p>The split linker must define the entry symbol as Reset_Handler_split.   For example:</p>
 <div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">ENTRY(Reset_Handler_split)
 </pre></div>
 
 
-<p>The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:</p>
+<p>The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader and are not needed in the split image. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:</p>
 <div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">    .text :
     {
         __split_isr_vector_start = .;
@@ -698,7 +713,7 @@
 <li><code>__data_end___loader</code></li>
 </ul>
 <p>The split app linker can use <code>__HeapBase_loader</code> to skip RAM used by the loader as follows.</p>
-<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">    /* save RAM used by the split image. This assumes that 
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">    /* save RAM used by the split image. This assumes that
      * the loader uses all the RAM up to its HeapBase  */
     .loader_ram_contents :
     {
@@ -715,16 +730,27 @@
 <p>The split application needs separate startup code to intialize the split image before running main.  THe split image is specially linked so that _start and main are included individually for the loader and split app.</p>
 <p>The split app startup code must have the following.</p>
 <ol>
-<li>A definition of the split image vector table (first two words). </li>
+<li>A definition of the split image vector table (first two words).</li>
 <li>The entry point function to start the code <code>Reset_Handler_split</code></li>
 <li>Code that copies the .data section for the loader from Flash to RAM</li>
 <li>Code that zeros the .bss section for the loader.</li>
-<li>Code that calls _sbrkInit to set the heap pointers for the application</li>
+<li>Code that calls _sbrkInit to set the heap pointers for the application (see below)</li>
+<li>Code that calls the <code>bsp_slot_init_split_application</code> function (see below)</li>
 </ol>
 <p>An example can be found in the <code>/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s</code></p>
+<h3 id="download-script">Download script</h3>
+<p>The download script needs to be modified to include support for passing the image slot number in the build.  Image slots are referenced as 0 and 1. Loading bootloaders ignore the image slot numbers.</p>
+<p>See and example in <code>/hw/bsp/bmd300eval/bmd300eval_download.sh</code>.</p>
+<h3 id="sbrk-functionality">Sbrk functionality</h3>
+<p>Split image (either a loader or app) references a single set of heap managment functions.  But the heap location and size is different depending which image is running.  Special functionality is needed to handle the dynamic setting of the heap base and limit.</p>
+<p>Instead of hard-coding the heap base and limit at link time (depending on the size of data and bss), sbrk needs to be dynamically initialized with these values from the startup code.</p>
+<p>See an example in <code>/hw/bsp/bmd300eval/src/sbrk.c</code> in the core repository.  The function <code>_sbrkInit</code> must be called from the startup code of the split image and normal image startup code with the appropriate values of heap base and limit.</p>
+<h3 id="slot-init">Slot Init</h3>
+<p>A global variable tells mynewt whether the split image is runnning as just a stand-alone loader, or as the combined loader/app image.  Its the responsibility of the startup code to set this global variable.</p>
+<p>See <code>hw/bsp/bmd300eval/src/os_bsp.c</code> for and implementation of the functionality.</p>
 <h2 id="newtmgr-and-split-images">newtmgr and split Images</h2>
 <p>newtmgr has support for split images.</p>
-<p><code>newtmgr image list2</code> lists the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.</p>
+<p><code>newtmgr image list</code> lists the current images in the flash.  Its clear from the output that some images are non-bootable.  For example.</p>
 <div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">Images:
  slot=1
     version=1.2.3
@@ -737,7 +763,7 @@
 </pre></div>
 
 
-<p>The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the <code>boot2</code> command to instruct mynewt to boot slot 2.  </p>
+<p>The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the <code>boot2</code> command to instruct mynewt to boot slot 2.</p>
 <p>Instead, use the new <code>split status</code> command to see the status of split images and to set their boot status.  The split status command with no arguments returns status of the split image.  The Split Value tells the loader how to boot the split app. Options are:</p>
 <ul>
 <li><code>none</code> Don't boot the split application. Just remain running in the loader.</li>
@@ -745,14 +771,14 @@
 <li><code>run</code> Boot the split application.</li>
 </ul>
 <p>The split status command also verified the hash of the split application (using the hash of the loader as shown above) and returns the status of the check (matching or non-matching).</p>
-<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">newtmgr -c connection split status 
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">newtmgr -c connection split status
   Split value is none
   Split status is matching
 </pre></div>
 
 
 <p>When the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:</p>
-<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">prompt$ newtmgr -c foo1 image boot2
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">prompt$ newtmgr -c foo1 image boot
    Test image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0
    Main image: 55e254f133bedf640fc7be7b5bfe3e5fb387cf5e29ecd0d4ea02b5ba617e27e0
    Active img: 1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe
@@ -774,7 +800,7 @@
 <li>newtmgr boot2 (check status to ensure new app is running)</li>
 <li>newtmgr split status run</li>
 </ol>
-<p>This upgrade is robust.  In all steps there is a loader image that is capable of upgrading (or reverting) images.  </p>
+<p>This upgrade is robust.  In all steps there is a loader image that is capable of upgrading (or reverting) images.</p>
                         
                         <div class="row">
                             

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/develop/sitemap.xml
----------------------------------------------------------------------
diff --git a/develop/sitemap.xml b/develop/sitemap.xml
index f083716..3dd3456 100644
--- a/develop/sitemap.xml
+++ b/develop/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -12,7 +12,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/quick-start/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -20,7 +20,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/about/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -28,7 +28,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/download/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -36,7 +36,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/community/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -44,7 +44,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/events/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -53,7 +53,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/introduction/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -65,7 +65,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -105,13 +105,13 @@
         
     <url>
      <loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://mynewt.apache.org/faq/answers/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/latest/sitemap.xml
----------------------------------------------------------------------
diff --git a/latest/sitemap.xml b/latest/sitemap.xml
index f083716..3dd3456 100644
--- a/latest/sitemap.xml
+++ b/latest/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -12,7 +12,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/quick-start/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -20,7 +20,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/about/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -28,7 +28,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/download/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -36,7 +36,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/community/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -44,7 +44,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/events/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -53,7 +53,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/introduction/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -65,7 +65,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -105,13 +105,13 @@
         
     <url>
      <loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://mynewt.apache.org/faq/answers/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/sitemap.xml
----------------------------------------------------------------------
diff --git a/sitemap.xml b/sitemap.xml
index f083716..3dd3456 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -12,7 +12,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/quick-start/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -20,7 +20,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/about/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -28,7 +28,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/download/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -36,7 +36,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/community/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -44,7 +44,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/events/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -53,7 +53,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/introduction/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -65,7 +65,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -105,13 +105,13 @@
         
     <url>
      <loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://mynewt.apache.org/faq/answers/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/e5deb393/v0_9_0/sitemap.xml
----------------------------------------------------------------------
diff --git a/v0_9_0/sitemap.xml b/v0_9_0/sitemap.xml
index f083716..3dd3456 100644
--- a/v0_9_0/sitemap.xml
+++ b/v0_9_0/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -12,7 +12,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/quick-start/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -20,7 +20,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/about/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -28,7 +28,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/download/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -36,7 +36,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/community/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -44,7 +44,7 @@
     
     <url>
      <loc>http://mynewt.apache.org/events/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -53,7 +53,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/introduction/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -65,7 +65,7 @@
         
     <url>
      <loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -105,13 +105,13 @@
         
     <url>
      <loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://mynewt.apache.org/faq/answers/</loc>
-     <lastmod>2016-08-31</lastmod>
+     <lastmod>2016-09-01</lastmod>
      <changefreq>daily</changefreq>
     </url>