You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/09/12 19:57:46 UTC
incubator-mynewt-site git commit: autocompletion of newt commands
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/asf-site e5deb3933 -> 106051e2a
autocompletion of newt commands
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/106051e2
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/106051e2
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/106051e2
Branch: refs/heads/asf-site
Commit: 106051e2a8c8376e58a3143e4bdd3988c64f42b6
Parents: e5deb39
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Sep 12 12:57:32 2016 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Sep 12 12:57:32 2016 -0700
----------------------------------------------------------------------
develop/about/index.html | 1 +
develop/mkdocs/search_index.json | 15 ++++++++++-----
develop/newt/newt_intro/index.html | 12 ++++++++++++
develop/os/modules/split/split/index.html | 2 +-
develop/sitemap.xml | 20 ++++++++++----------
latest/sitemap.xml | 20 ++++++++++----------
sitemap.xml | 20 ++++++++++----------
v0_9_0/sitemap.xml | 20 ++++++++++----------
8 files changed, 64 insertions(+), 46 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/develop/about/index.html
----------------------------------------------------------------------
diff --git a/develop/about/index.html b/develop/about/index.html
index ffd5f13..dbb720c 100644
--- a/develop/about/index.html
+++ b/develop/about/index.html
@@ -191,6 +191,7 @@
<li>HAL redesign to abstract across a diverse set of chip peripherals (<a href="http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C06CB0682-8F67-4C3F-93E4-6A20444487A1%40apache.org%3E">View discussion thread</a>)</li>
<li>HAL for SPI access (master and slave)</li>
<li>Ability for drivers to turn on/off low power settings automatically</li>
+<li>Support for Wi-Fi controllers via a socket interface</li>
</ul>
<p><font color="#F2853F"> The detailed roadmap is tracked on <a href="https://issues.apache.org/jira/browse/MYNEWT/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel">JIRA for Mynewt</a>. </font></p>
<p><br></p>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/develop/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/develop/mkdocs/search_index.json b/develop/mkdocs/search_index.json
index 69e52de..b63a85a 100644
--- a/develop/mkdocs/search_index.json
+++ b/develop/mkdocs/search_index.json
@@ -27,12 +27,12 @@
},
{
"location": "/about/",
- "text": "Roadmap\n\n\nSome upcoming features:\n\n\n\n\nHost-only BLE stack\n\n\nSerial upgrade of image in bootloader\n\n\nHAL redesign to abstract across a diverse set of chip peripherals (\nView discussion thread\n)\n\n\nHAL for SPI access (master and slave)\n\n\nAbility for drivers to turn on/off low power settings automatically\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Introduce it in the \ndev@\n mailing list with a link to the JI
RA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.\n\n\n\n\nFAQ\n\n\n Questions? \n Click \nhere",
+ "text": "Roadmap\n\n\nSome upcoming features:\n\n\n\n\nHost-only BLE stack\n\n\nSerial upgrade of image in bootloader\n\n\nHAL redesign to abstract across a diverse set of chip peripherals (\nView discussion thread\n)\n\n\nHAL for SPI access (master and slave)\n\n\nAbility for drivers to turn on/off low power settings automatically\n\n\nSupport for Wi-Fi controllers via a socket interface\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Intro
duce it in the \ndev@\n mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.\n\n\n\n\nFAQ\n\n\n Questions? \n Click \nhere",
"title": "About"
},
{
"location": "/about/#roadmap",
- "text": "Some upcoming features: Host-only BLE stack Serial upgrade of image in bootloader HAL redesign to abstract across a diverse set of chip peripherals ( View discussion thread ) HAL for SPI access (master and slave) Ability for drivers to turn on/off low power settings automatically The detailed roadmap is tracked on JIRA for Mynewt .",
+ "text": "Some upcoming features: Host-only BLE stack Serial upgrade of image in bootloader HAL redesign to abstract across a diverse set of chip peripherals ( View discussion thread ) HAL for SPI access (master and slave) Ability for drivers to turn on/off low power settings automatically Support for Wi-Fi controllers via a socket interface The detailed roadmap is tracked on JIRA for Mynewt .",
"title": "Roadmap"
},
{
@@ -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 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.",
+ "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\n 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 withi
n 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/sli
nky\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
produced 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
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:\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
\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 (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
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.\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 b
ootable=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) an
d 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\
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.",
"title": "toc"
},
{
@@ -4842,7 +4842,7 @@
},
{
"location": "/os/modules/split/split/#newt-create-image",
- "text": "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.",
+ "text": "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.",
"title": "newt create-image"
},
{
@@ -9532,7 +9532,7 @@
},
{
"location": "/newt/newt_intro/",
- "text": "Newt Tool\n\n\nIntroduction\n\n\nNewt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:\n\n\n\n\nsource package management \n\n\nbuild, debug and install.\n\n\n\n\nRationale\n\n\nIn order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.\n\n\nThe build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:\n\n\n\n\nBuilding for multiple targets\n\n\nDeciding what to build in and what not to build in\n\n\nManaging dependencies between components\n\n\n\n\nFortunately, solutions addressi
ng these very issues can be found in source package management systems in higher level languages such as Javascript \n(Node), Go, PHP and Ruby. We decided to fuse their source management \nsystems with a make system built for embedded systems and create Newt.\n\n\nBuild System\n\n\nA good build system must allow the user to take a few common steps while developing embedded applications:\n\n\n\n\nGenerate full flash images\n\n\nDownload debug images to a target board using a debugger\n\n\nConditionally compile libraries \n code based upon build settings\n\n\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u25
00\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file, it is smart enough to recognize it as the base directory of a project, and \nautomatically builds a package tree. It also recognizes two important package directories in the package tree - \"apps\" and \"targets\". More on these directories in \nNewt Theory of Ops\n.\n\n\nWhen Newt is told to build a project, it recursively resolves all package dependencies and generates artifacts that are placed in the bin/ directory at the top-level of the project. The artifact directory is prefixed by the target name being built - \nmy_blinky_sim\n for example:\n\n\n$ tree bin\n
bin\n\u2514\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Contents\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 Info.plist\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Resources\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 DWARF\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.lst\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.d\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.o\n \
u2502\u00a0\u00a0 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 bsp\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 native\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.d\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o.cmd\n\nsnip\n\n\n\n\n\n\n\n\nMore operations using Newt\n\n\nOnce a target has been built, Newt allows additional operations on the target. \n\n\n\n\ndownload\n: Download built target to board\n\n\ndebug\n: Open debugger session to target\n\n\nsize\n: Get size of target components\n\n\ncreate-image\n: Add image header to the binary image\n\n\n\n\nFor more details on how Newt works, go to \nNewt - Theory of Operations\n.\n\n\n\n\nSource Management and Repositories\n\n\nThe other major element of the Newt tool is the ability to create reusable source distributions from
a collection of code. \nA project can be a reusable container of source code.\n In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.\n\n\nA project that has been made redistributable is known as a \nrepository\n. \nRepositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:\n\n\n$ more project.yml\n\nsnip\n\nproject.repositories:\n - apache-mynewt-core\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\n\n\nWhen you specify this repository in the blinky's project file, you can then use the Newt t
ool to install dependencies:\n\n\n$ newt install\nDownloading repository description for apache-mynewt-core... success!\nDownloading repository incubator-mynewt-core (branch: develop) at \nhttps://github.com/apache/incubator-mynewt-core.git\nCloning into \n\n/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459\n...\nremote: Counting objects: 17601, done.\nremote: Compressing objects: 100% (300/300), done.\nremote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284\nReceiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.\nResolving deltas: 100% (10347/10347), done.\nChecking connectivity... done.\nRepos successfully installed\n\n\n\n\n\n\n\nNewt will install this repository in the \n/repos directory. In the case of blinky, the directory structure ends up looking like:\n\n\n$ tree -L 2\n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 apps\n\u2502 \u2514\u
2500\u2500 blinky\n\u251c\u2500\u2500 project.state\n\u251c\u2500\u2500 project.yml\n\u251c\u2500\u2500 repos\n\u2502 \u2514\u2500\u2500 apache-mynewt-core\n\u2514\u2500\u2500 targets\n \u251c\u2500\u2500 my_blinky_sim\n \u2514\u2500\u2500 unittest\n\n\n\n\n\n\n\nIn order to reference the installed repositories in packages, the \"@\" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the \nlibs/os\n, \nhw/hal\n, and \nlibs/console/full\n packages.\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.deps:\n - \n@apache-mynewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full",
+ "text": "Newt Tool\n\n\nIntroduction\n\n\nNewt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:\n\n\n\n\nsource package management \n\n\nbuild, debug and install.\n\n\n\n\nRationale\n\n\nIn order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.\n\n\nThe build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:\n\n\n\n\nBuilding for multiple targets\n\n\nDeciding what to build in and what not to build in\n\n\nManaging dependencies between components\n\n\n\n\nFortunately, solutions addressi
ng these very issues can be found in source package management systems in higher level languages such as Javascript \n(Node), Go, PHP and Ruby. We decided to fuse their source management \nsystems with a make system built for embedded systems and create Newt.\n\n\nBuild System\n\n\nA good build system must allow the user to take a few common steps while developing embedded applications:\n\n\n\n\nGenerate full flash images\n\n\nDownload debug images to a target board using a debugger\n\n\nConditionally compile libraries \n code based upon build settings\n\n\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u25
00\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file, it is smart enough to recognize it as the base directory of a project, and \nautomatically builds a package tree. It also recognizes two important package directories in the package tree - \"apps\" and \"targets\". More on these directories in \nNewt Theory of Ops\n.\n\n\nWhen Newt is told to build a project, it recursively resolves all package dependencies and generates artifacts that are placed in the bin/ directory at the top-level of the project. The artifact directory is prefixed by the target name being built - \nmy_blinky_sim\n for example:\n\n\n$ tree bin\n
bin\n\u2514\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Contents\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 Info.plist\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Resources\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 DWARF\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.lst\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.d\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.o\n \
u2502\u00a0\u00a0 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 bsp\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 native\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.d\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o.cmd\n\nsnip\n\n\n\n\n\n\n\n\nMore operations using Newt\n\n\nOnce a target has been built, Newt allows additional operations on the target. \n\n\n\n\ndownload\n: Download built target to board\n\n\ndebug\n: Open debugger session to target\n\n\nsize\n: Get size of target components\n\n\ncreate-image\n: Add image header to the binary image\n\n\n\n\nFor more details on how Newt works, go to \nNewt - Theory of Operations\n.\n\n\n\n\nSource Management and Repositories\n\n\nThe other major element of the Newt tool is the ability to create reusable source distributions from
a collection of code. \nA project can be a reusable container of source code.\n In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.\n\n\nA project that has been made redistributable is known as a \nrepository\n. \nRepositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:\n\n\n$ more project.yml\n\nsnip\n\nproject.repositories:\n - apache-mynewt-core\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\n\n\nWhen you specify this repository in the blinky's project file, you can then use the Newt t
ool to install dependencies:\n\n\n$ newt install\nDownloading repository description for apache-mynewt-core... success!\nDownloading repository incubator-mynewt-core (branch: develop) at \nhttps://github.com/apache/incubator-mynewt-core.git\nCloning into \n\n/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459\n...\nremote: Counting objects: 17601, done.\nremote: Compressing objects: 100% (300/300), done.\nremote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284\nReceiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.\nResolving deltas: 100% (10347/10347), done.\nChecking connectivity... done.\nRepos successfully installed\n\n\n\n\n\n\n\nNewt will install this repository in the \n/repos directory. In the case of blinky, the directory structure ends up looking like:\n\n\n$ tree -L 2\n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 apps\n\u2502 \u2514\u
2500\u2500 blinky\n\u251c\u2500\u2500 project.state\n\u251c\u2500\u2500 project.yml\n\u251c\u2500\u2500 repos\n\u2502 \u2514\u2500\u2500 apache-mynewt-core\n\u2514\u2500\u2500 targets\n \u251c\u2500\u2500 my_blinky_sim\n \u2514\u2500\u2500 unittest\n\n\n\n\n\n\n\nIn order to reference the installed repositories in packages, the \"@\" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the \nlibs/os\n, \nhw/hal\n, and \nlibs/console/full\n packages.\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.deps:\n - \n@apache-mynewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\n\n\nAutocompletion in Bash\n\n\nNewt has the ability to autocomplete within \nbash\n. The following instructions allow MAC users to enable autocompl
ete within \nbash\n.\n\n\n\n\nInstall the autocomplete tools for bash via \nbrew install bash-completion\n\n\nTell your shell to use newt for autocompletion of newt via \ncomplete -C \"newt complete\" newt\n. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.\n\n\n\n\nNotes:\n\n\n\n\nAutocomplete will give you flag hints, but only if you type a '-'. \n\n\nAutocomplete will not give you completion hints for the flag arguments (those optional things after the flag like \n-l DEBUG\n)\n\n\nAutocomplete uses newt to parse the project to find targets and libs.",
"title": "toc"
},
{
@@ -9566,6 +9566,11 @@
"title": "Source Management and Repositories"
},
{
+ "location": "/newt/newt_intro/#autocompletion-in-bash",
+ "text": "Newt has the ability to autocomplete within bash . The following instructions allow MAC users to enable autocomplete within bash . Install the autocomplete tools for bash via brew install bash-completion Tell your shell to use newt for autocompletion of newt via complete -C \"newt complete\" newt . You can add this to your .bashrc or other init file to have it automatically set for all bash shells. Notes: Autocomplete will give you flag hints, but only if you type a '-'. Autocomplete will not give you completion hints for the flag arguments (those optional things after the flag like -l DEBUG ) Autocomplete uses newt to parse the project to find targets and libs.",
+ "title": "Autocompletion in Bash"
+ },
+ {
"location": "/newt/newt_operation/",
"text": "Newt Tool - Theory of Operations\n\n\nNewt has a fairly smart package manager that can read a directory tree, build a dependency tree, and emit the right build artifacts.\n\n\nBuilding dependencies\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u2500\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\
n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file it knows that it is in the base directory of a project, and automatically builds a package tree. You can see that there are two essential package directories, \"apps\" and \"targets.\" \n\n\n\n\n\"apps\" Package Directory\n\n\napps\n is where applications are stored, and applications are where the main() function is contained. Along with the \ntargets\n directory, \napps\n represents the top-level of the build tree, and define the dependencies and features for the rest of the system.\n\n\nThe app definition is contained in a \npkg.yml\n file. An example of blinky's \npkg.yml\n file is:\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.name: apps/blinky\npkg.vers: 0.8.0\npkg.description: Basic example application which blinks an LED.\npkg.author: \nApache Mynewt \ndev@mynewt.incubator.apache.org\n\npkg.homepage: \nhttp://mynewt.apache.org/\n\npkg.repository:\npkg.keywords:\n\npkg.deps:\n - \n@apache-myn
ewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\n\n\nThis file says that the name of the package is apps/blinky, and it \ndepends on libs/os, hw/hal and libs/console/full packages.\n\n\nNOTE:\n @apache-mynewt-core is a repository descriptor, and this will be \ncovered in the \"repository\" section. \n\n\n\n\n\"targets\" Package Directory\n\n\ntargets\n is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the \napps\n directory, \ntargets\n represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies.\n\n\nMost targets consist of:\n\n\n\n\napp: The application to build\n\n\nbsp: The board support package to combine with that application\n\n\nbuild_profile: Either debug or optimized.\n\n\n\n\nThe \nmy_blinky_sim\n target in the example below has t
he following settings:\n\n\n$ newt target show\ntargets/my_blinky_sim\n app=apps/blinky\n bsp=@apache-mynewt-core/hw/bsp/native\n build_profile=debug\n$ ls my_blinky_sim/\npkg.yml target.yml\n\n\n\n\n\nIn general, the three basic parameters of a target (\napp\n, \nbsp\n, and \nbuild_profile\n) are stored in the \ntarget.yml\n file in that target's build directory under \ntargets\n. You will also see a \npkg.yml\n file in the same directory. Since targets are packages, a \npkg.yml\n is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following:\n\n\n\n\nCflags: Any additional compiler flags you might want to specify to the build\n\n\nAflags: Any additional assembler flags you might want to specify to the build\n\n\nLflags: Any additional linker flags you might want to specify to the build\n\n\nfeatures: Any system level features you want to enable.\n\n\n\n\n\n\nResolving dependencies\n\n\nWhen newt is told to build a
project, it will:\n\n\n\n\nfind the top-level project.yml file\n\n\nrecurse the packages in the package tree, and build a list of all \nsource packages\n\n\n\n\nNewt then looks at the target that the user set, for example, blinky_sim:\n\n\n$ more targets/my_blinky_sim/\npkg.yml target.yml\n$ more targets/my_blinky_sim/target.yml\n### Target: targets/my_blinky_sim\ntarget.app: \napps/blinky\n\ntarget.bsp: \n@apache-mynewt-core/hw/bsp/native\n\ntarget.build_profile: \ndebug\n\n\n\n\n\n\n\n\nThe target specifies two major things:\n\n\n\n\nApplication (target.app): The application to build\n\n\nBoard Support Package (target.bsp): The board support package to build \nalong with that application.\n\n\n\n\nNewt goes and builds the dependency tree specified by all the packages. While building this tree, it does a few other things:\n\n\n\n\nAny package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the\nne
wt structure must always be prefixed by the package name. For example, libs/os has the following include tree and its include directory files contains the package name \"os\" before any header files. This is so in order to avoid any header file conflicts.\n\n\n\n\n$ tree\n.\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 include\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 arch\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m0\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m4\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 sim\n\u25
02\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 endian.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_callout.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_cfg.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_eventq.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_heap.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_malloc.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mbuf.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mempool.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mutex.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sanity.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sched.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sem.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_task.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_test.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_time.h
\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 queue.h\n\u251c\u2500\u2500 pkg.yml\n\u2514\u2500\u2500 src\n \u251c\u2500\u2500 arch\n\nsnip\n\n\n\n\n\n\n\n\n\n\n\n\nAPI requirements are validated. Packages can export APIs they \nimplement, (i.e. pkg.api: hw-hal-impl), and other packages can require \nthose APIs (i.e. pkg.req_api: hw-hal-impl).\n\n\n\n\n\n\n\"Features\" options are supported. Packages can change what dependencies \nthey have, or what flags they are using based upon what features are enabled in the system. As an example, many packages will add additional software, based on whether the shell package is present. To do this, they can overwrite cflags or deps based upon the shell \"feature.\"\n\n\n\n\n\n\npkg.cflags.SHELL: -DSHELL_PRESENT\n\n\n\n\n\n\n\nIn order to properly resolve all dependencies in the build system, Newt recursively processes the package dependencies until there are no new dependencies or features (because features can add dependencies.) And it b
uilds a big list of all the packages that need to be build.\n\n\nNewt then goes through this package list, and builds every package into \nan archive file.\n\n\nNOTE:\n The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package \n project dependencies are also taken into account. It is smart, after all!\n\n\nProducing artifacts\n\n\nOnce Newt has built all the archive files, it then links the archive files together. The linkerscript to use is specified by the board support package (BSP.)\n\n\nNOTE: One common use of the \"features\" option above is to overwrite \nwhich linkerscript is used, based upon whether or not the BSP is being \nbuild for a raw image, bootable image or bootloader itself.\n\n\nThe newt tool places all of it's artifacts into the bin/ directory at \nthe top-level of the project, prefixed by the target name being built, \nfor example:\n\n\n$ tree -L 4 bin/\nbin/\n\u25
14\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502 \u2514\u2500\u2500 blinky\n \u2502 \u251c\u2500\u2500 blinky.a\n \u2502 \u251c\u2500\u2500 blinky.a.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf\n \u2502 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502 \u251c\u2500\u2500 blinky.elf.lst\n \u2502 \u251c\u2500\u2500 main.d\n \u2502 \u251c\u2500\u2500 main.o\n \u2502 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502 \u251c\u2500\u2500 bsp\n \u2502 \u2502 \u2514\u2500\u2500 native\n \u2502 \u251c\u2500\u2500 hal\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.d\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.o\n\nsnip\n\n\n\n\n\n\n\n\nAs you can see, a number of files are generated:\n\n\n\n\nArchive File\n\n\n*.cmd: The command use to generate the object or archive file\n\n\n*.lst: The list fil
e where symbols are located\n\n\n*.o The object files that get put into the archive file\n\n\n\n\nDownload/Debug Support\n\n\nOnce a target has been build, there are a number of helper functions \nthat work on the target. These are:\n\n\n\n\ndownload\n Download built target to board\n\n\ndebug\n Open debugger session to target\n\n\nsize Size of target components\n\n\ncreate-image Add image header to target binary\n\n\n\n\nDownload and debug handles driving GDB and the system debugger. These \ncommands call out to scripts that are defined by the BSP.\n\n\n$ more repos/apache-mynewt-core/hw/bsp/nrf52pdk/nrf52pdk_debug.sh\n\nsnip\n\n#\nif [ $# -lt 1 ]; then\n echo \nNeed binary to download\n\n exit 1\nfi\n\nFILE_NAME=$2.elf\nGDB_CMD_FILE=.gdb_cmds\n\necho \nDebugging\n $FILE_NAME\n\n# Monitor mode. Background process gets it\ns own process group.\nset -m\nJLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 3333 -singlerun \n\nset +m\n\necho \ntarget remo
te localhost:3333\n \n $GDB_CMD_FILE\n\narm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME\n\nrm $GDB_CMD_FILE\n\n\n\n\n\nThe idea is that every BSP will add support for the debugger environment \nfor that board. That way common tools can be used across various development boards and kits.\n\n\nNOTE:\n Both for compiler definitions and debugger scripts, the plan is to \ncreate Dockerizable containers of these toolchains. This should make \nthings much easier to support across Mac OS X, Linux and Windows. Newt \nwill know how to call out to Docker to perform these processes.",
"title": "Newt Theory of Ops"
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/develop/newt/newt_intro/index.html
----------------------------------------------------------------------
diff --git a/develop/newt/newt_intro/index.html b/develop/newt/newt_intro/index.html
index 6853c03..b9bf5b3 100644
--- a/develop/newt/newt_intro/index.html
+++ b/develop/newt/newt_intro/index.html
@@ -488,6 +488,18 @@ pkg.deps:
<p><br></p>
+<h3 id="autocompletion-in-bash">Autocompletion in Bash</h3>
+<p>Newt has the ability to autocomplete within <code>bash</code>. The following instructions allow MAC users to enable autocomplete within <code>bash</code>.</p>
+<ol>
+<li>Install the autocomplete tools for bash via <code>brew install bash-completion</code></li>
+<li>Tell your shell to use newt for autocompletion of newt via <code>complete -C "newt complete" newt</code>. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.</li>
+</ol>
+<p>Notes:</p>
+<ol>
+<li>Autocomplete will give you flag hints, but only if you type a '-'. </li>
+<li>Autocomplete will not give you completion hints for the flag arguments (those optional things after the flag like <code>-l DEBUG</code>)</li>
+<li>Autocomplete uses newt to parse the project to find targets and libs.</li>
+</ol>
<div class="row">
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/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 0492489..a07bb34 100644
--- a/develop/os/modules/split/split/index.html
+++ b/develop/os/modules/split/split/index.html
@@ -636,7 +636,7 @@
<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><code>create-image</code> 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>
<ul>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/develop/sitemap.xml
----------------------------------------------------------------------
diff --git a/develop/sitemap.xml b/develop/sitemap.xml
index 3dd3456..88d40e9 100644
--- a/develop/sitemap.xml
+++ b/develop/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -12,7 +12,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -20,7 +20,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -53,7 +53,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -65,7 +65,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -105,13 +105,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/latest/sitemap.xml
----------------------------------------------------------------------
diff --git a/latest/sitemap.xml b/latest/sitemap.xml
index 3dd3456..88d40e9 100644
--- a/latest/sitemap.xml
+++ b/latest/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -12,7 +12,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -20,7 +20,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -53,7 +53,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -65,7 +65,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -105,13 +105,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/sitemap.xml
----------------------------------------------------------------------
diff --git a/sitemap.xml b/sitemap.xml
index 3dd3456..88d40e9 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -12,7 +12,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -20,7 +20,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -53,7 +53,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -65,7 +65,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -105,13 +105,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/106051e2/v0_9_0/sitemap.xml
----------------------------------------------------------------------
diff --git a/v0_9_0/sitemap.xml b/v0_9_0/sitemap.xml
index 3dd3456..88d40e9 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-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -12,7 +12,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -20,7 +20,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -53,7 +53,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -65,7 +65,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -105,13 +105,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-09-01</lastmod>
+ <lastmod>2016-09-12</lastmod>
<changefreq>daily</changefreq>
</url>