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/02/20 03:52:04 UTC
[1/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/master 87e9d34c3 -> 9b0bc2e09
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 59d5f5a..e070556 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -1,5 +1,6 @@
site_name: Apache Mynewt
-site_url: http://mynewt.incubator.apache.org
+#site_url: http://mynewt.incubator.apache.org
+site_url: http://127.0.0.1:8000
theme_dir: 'custom-theme'
@@ -9,154 +10,248 @@ pages:
- Download: 'download.md'
- Community: 'community.md'
- Events: 'events.md'
-- Chapter 1 - Get Started:
- - 'Newt Concepts': 'get_started/newt_concepts.md'
- - 'Blinky, The First Project': 'get_started/project1.md'
- - 'How to edit docs': 'get_started/how_to_edit_docs.md'
- - 'Sample doc to edit': 'get_started/try_markdown.md'
-- Chapter 2 - Get Acclimated:
- - 'Understanding Newt Terms': 'get_acclimated/vocabulary.md'
- - 'Project 2': 'get_acclimated/project2.md'
- - 'Project 3': 'get_acclimated/project3.md'
-- Chapter 3 - Newt Tool:
- - 'Command structure': 'newt/newt_ops.md'
- - 'Command list': 'newt/newt_tool_reference.md'
-- Chapter 4 - Mynewt OS:
- - 'Overview': 'os/mynewt_os.md'
- - 'Scheduler/Context Switching': 'os/context_switch.md'
- - 'Time': 'os/time.md'
- - 'Tasks': 'os/task.md'
- - 'Event Queues': 'os/event_queue.md'
- - 'Semaphores': 'os/semaphore.md'
- - 'Mutexes': 'os/mutex.md'
- - 'Memory Pools': 'os/memory_pool.md'
- - 'Heap': 'os/heap.md'
- - 'Mbufs': 'os/mbufs.md'
- - 'Sanity': 'os/sanity.md'
- - 'Callout Functions': 'os/callout.md'
- - 'Porting to other Platforms': 'os/port_os.md'
-- Chapter 5 - Modules:
- - Console:
- - 'console overview': 'modules/console/console.md'
- - 'console_add_char': 'modules/console/console_add_char.md'
- - 'console_blocking_mode': 'modules/console/console_blocking_mode.md'
- - 'console_blocking_tx': 'modules/console/console_blocking_tx.md'
- - 'console_init': 'modules/console/console_init.md'
- - 'console_printf': 'modules/console/console_printf.md'
- - 'console_pull_char': 'modules/console/console_pull_char.md'
- - 'console_pull_char_head': 'modules/console/console_pull_char_head.md'
- - 'console_queue_char': 'modules/console/console_queue_char.md'
- - 'console_read': 'modules/console/console_read.md'
- - 'console_rx_char': 'modules/console/console_rx_char.md'
- - 'console_tx_char': 'modules/console/console_tx_char.md'
- - 'console_write': 'modules/console/console_write.md'
- - Shell:
- - 'shell overview': 'modules/shell/shell.md'
- - 'shell_cmd': 'modules/shell/shell_cmd.md'
- - 'shell_cmd_list_lock': 'modules/shell/shell_cmd_list_lock.md'
- - 'shell_cmd_list_unlock': 'modules/shell/shell_cmd_list_unlock.md'
- - 'shell_cmd_register': 'modules/shell/shell_cmd_register.md'
- - 'shell_console_rx_cb': 'modules/shell/shell_console_rx_cb.md'
- - 'shell_echo_cmd': 'modules/shell/shell_echo_cmd.md'
- - 'shell_help_cmd': 'modules/shell/shell_help_cmd.md'
- - 'shell_nlip_input_register': 'modules/shell/shell_nlip_input_register.md'
- - 'shell_nlip_mqueue_process': 'modules/shell/shell_nlip_mqueue_process.md'
- - 'shell_nlip_mtx': 'modules/shell/shell_nlip_mtx.md'
- - 'shell_nlip_output': 'modules/shell/shell_nlip_output.md'
- - 'shell_nlip_process': 'modules/shell/shell_nlip_process.md'
- - 'shell_os_mpool_display_cmd': 'modules/shell/shell_os_mpool_display_cmd.md'
- - 'shell_os_tasks_display_cmd': 'modules/shell/shell_os_tasks_display_cmd.md'
- - 'shell_process_command': 'modules/shell/shell_process_command.md'
- - 'shell_read_console': 'modules/shell/shell_read_console.md'
- - 'shell_task_func': 'modules/shell/shell_task_func.md'
- - 'shell_task_init': 'modules/shell/shell_task_init.md'
- - Bootloader:
- - 'bootloader overview': 'modules/bootloader/bootloader.md'
- - 'boot_build_status': 'modules/bootloader/boot_build_status.md'
- - 'boot_build_status_one': 'modules/bootloader/boot_build_status_one.md'
- - 'boot_clear_status': 'modules/bootloader/boot_clear_status.md'
- - 'boot_copy_area': 'modules/bootloader/boot_copy_area.md'
- - 'boot_copy_image': 'modules/bootloader/boot_copy_image.md'
- - 'boot_erase_area': 'modules/bootloader/boot_erase_area.md'
- - 'boot_fill_slot': 'modules/bootloader/boot_fill_slot.md'
- - 'boot_find_image_area_idx': 'modules/bootloader/boot_find_image_area_idx.md'
- - 'boot_find_image_part': 'modules/bootloader/boot_find_image_part.md'
- - 'boot_find_image_slot': 'modules/bootloader/boot_find_image_slot.md'
- - 'boot_go': 'modules/bootloader/boot_go.md'
- - 'boot_init_flash': 'modules/bootloader/boot_init_flash.md'
- - 'boot_move_area': 'modules/bootloader/boot_move_area.md'
- - 'boot_read_image_header': 'modules/bootloader/boot_read_image_header.md'
- - 'boot_read_image_headers': 'modules/bootloader/boot_read_image_headers.md'
- - 'boot_read_status': 'modules/bootloader/boot_read_status.md'
- - 'boot_select_image_slot': 'modules/bootloader/boot_select_image_slot.md'
- - 'boot_slot_addr': 'modules/bootloader/boot_slot_addr.md'
- - 'boot_slot_to_area_idx': 'modules/bootloader/boot_slot_to_area_idx.md'
- - 'boot_swap_areas': 'modules/bootloader/boot_swap_areas.md'
- - 'boot_vect_delete_main': 'modules/bootloader/boot_vect_delete_main.md'
- - 'boot_vect_delete_test': 'modules/bootloader/boot_vect_delete_test.md'
- - 'boot_vect_read_main': 'modules/bootloader/boot_vect_read_main.md'
- - 'boot_vect_read_one': 'modules/bootloader/boot_vect_read_one.md'
- - 'boot_vect_read_test': 'modules/bootloader/boot_vect_read_test.md'
- - 'boot_write_status': 'modules/bootloader/boot_write_status.md'
- - 'File System Abstraction': 'modules/filesystem.md'
- - 'Newtron Flash File System': 'modules/nffs.md'
- - Test Utilities:
- - 'testutil overview': 'modules/testutil/testutil.md'
- - 'tu_case_abort': 'modules/testutil/tu_case_abort.md'
- - 'tu_case_append_assert_msg': 'modules/testutil/tu_case_append_assert_msg.md'
- - 'tu_case_append_buf': 'modules/testutil/tu_case_append_buf.md'
- - 'tu_case_append_file_info': 'modules/testutil/tu_case_append_file_info.md'
- - 'tu_case_append_manual_pass_msg': 'modules/testutil/tu_case_append_manual_pass_msg.md'
- - 'tu_case_complete': 'modules/testutil/tu_case_complete.md'
- - 'tu_case_fail_assert': 'modules/testutil/tu_case_fail_assert.md'
- - 'tu_case_init': 'modules/testutil/tu_case_init.md'
- - 'tu_case_pass_manual': 'modules/testutil/tu_case_pass_manual.md'
- - 'tu_case_set_name': 'modules/testutil/tu_case_set_name.md'
- - 'tu_case_vappend_buf': 'modules/testutil/tu_case_vappend_buf.md'
- - 'tu_case_write_fail_buf': 'modules/testutil/tu_case_write_fail_buf.md'
- - 'tu_case_write_pass_auto': 'modules/testutil/tu_case_write_pass_auto.md'
- - 'tu_case_write_pass_buf': 'modules/testutil/tu_case_write_pass_buf.md'
- - 'tu_init': 'modules/testutil/tu_init.md'
- - 'tu_restart': 'modules/testutil/tu_restart.md'
- - 'tu_suite_init': 'modules/testutil/tu_suite_init.md'
- - 'tu_suite_set_name': 'modules/testutil/tu_suite_set_name.md'
- - Image Manager:
- - 'imgmgr overview': 'modules/imgmgr/imgmgr.md'
- - 'imgmgr_module_init': 'modules/imgmgr/imgmgr_module_init.md'
- - 'imgr_boot_read': 'modules/imgmgr/imgr_boot_read.md'
- - 'imgr_boot_write': 'modules/imgmgr/imgr_boot_write.md'
- - 'imgr_file_download': 'modules/imgmgr/imgr_file_download.md'
- - 'imgr_file_upload': 'modules/imgmgr/imgr_file_upload.md'
- - 'imgr_list': 'modules/imgmgr/imgr_list.md'
- - 'imgr_noop': 'modules/imgmgr/imgr_noop.md'
- - 'imgr_read_file': 'modules/imgmgr/imgr_read_file.md'
- - 'imgr_read_main': 'modules/imgmgr/imgr_read_main.md'
- - 'imgr_read_test': 'modules/imgmgr/imgr_read_test.md'
- - 'imgr_read_ver': 'modules/imgmgr/imgr_read_ver.md'
- - 'imgr_upload': 'modules/imgmgr/imgr_upload.md'
- - 'imgr_ver_jsonstr': 'modules/imgmgr/imgr_ver_jsonstr.md'
- - 'imgr_ver_parse': 'modules/imgmgr/imgr_ver_parse.md'
- - 'imgr_ver_str': 'modules/imgmgr/imgr_ver_str.md'
- - 'imgr_write_file': 'modules/imgmgr/imgr_write_file.md'
- - 'Baselibc library': 'modules/baselibc.md'
- - 'Embedded Lua': 'modules/elua.md'
- - JSON:
- - 'JSON overview': 'modules/json/json.md'
- - 'json_encode_object_entry': 'modules/json/json_encode_object_entry.md'
- - 'json_encode_object_finish': 'modules/json/json_encode_object_finish.md'
- - 'json_encode_object_key': 'modules/json/json_encode_object_key.md'
- - 'json_encode_object_start': 'modules/json/json_encode_object_start.md'
- - 'json_encode_value': 'modules/json/json_encode_value.md'
- - 'json_internal_read_object': 'modules/json/json_internal_read_object.md'
- - 'json_read_array': 'modules/json/json_read_array.md'
- - 'json_read_object': 'modules/json/json_read_object.md'
- - 'json_target_address': 'modules/json/json_target_address.md'
-- Chapter 6 - Newt Manager:
+- Manual for Mynewt OS:
+ - Get Started:
+ - 'Introduction': 'os/get_started/newt_concepts.md'
+ - 'Blinky, The First Project': 'os/get_started/project1.md'
+ - 'Understanding Newt Terms': 'os/get_started/vocabulary.md'
+ - 'How to edit docs': 'os/get_started/how_to_edit_docs.md'
+ - 'Sample doc to edit': 'os/get_started/try_markdown.md'
+ - More Projects:
+ - 'Project 2': 'os/get_acclimated/project2.md'
+ - 'Project 3': 'os/get_acclimated/project3.md'
+ - Mynewt OS:
+ - 'OS Fundamentals':
+ - 'OS Fundamentals overview': 'os/core_os/mynewt_os.md'
+ - 'os_idle_task': 'os/core_os/os_idle_task.md'
+ - 'os_init': 'os/core_os/os_init.md'
+ - 'os_init_idle_task': 'os/core_os/os_init_idle_task.md'
+ - 'os_start': 'os/core_os/os_start.md'
+ - 'os_started': 'os/core_os/os_started.md'
+ - Scheduler/Context Switching:
+ - 'context_switch overview': 'os/core_os/context_switch/context_switch.md'
+ - 'os_sched': 'os/core_os/context_switch/os_sched.md'
+ - 'os_sched_ctx_sw_hook': 'os/core_os/context_switch/os_sched_ctx_sw_hook.md'
+ - 'os_sched_get_current_task': 'os/core_os/context_switch/os_sched_get_current_task.md'
+ - 'os_sched_insert': 'os/core_os/context_switch/os_sched_insert.md'
+ - 'os_sched_next_task': 'os/core_os/context_switch/os_sched_next_task.md'
+ - 'os_sched_os_timer_exp': 'os/core_os/context_switch/os_sched_os_timer_exp.md'
+ - 'os_sched_resort': 'os/core_os/context_switch/os_sched_resort.md'
+ - 'os_sched_set_current_task': 'os/core_os/context_switch/os_sched_set_current_task.md'
+ - 'os_sched_sleep': 'os/core_os/context_switch/os_sched_sleep.md'
+ - 'os_sched_wakeup': 'os/core_os/context_switch/os_sched_wakeup.md'
+ - 'Time':
+ - 'time overview': 'os/core_os/time/time.md'
+ - 'os_time_delay': 'os/core_os/time/os_time_delay.md'
+ - 'os_time_get': 'os/core_os/time/os_time_get.md'
+ - 'os_time_tick': 'os/core_os/time/os_time_tick.md'
+ - 'Tasks':
+ - 'task overview': 'os/core_os/task/task.md'
+ - '_clear_stack': 'os/core_os/task/_clear_stack.md'
+ - 'os_task_count': 'os/core_os/task/os_task_count.md'
+ - 'os_task_info_get_next': 'os/core_os/task/os_task_info_get_next.md'
+ - 'os_task_init': 'os/core_os/task/os_task_init.md'
+ - 'os_task_next_id': 'os/core_os/task/os_task_next_id.md'
+ - 'os_task_sanity_checkin': 'os/core_os/task/os_task_sanity_checkin.md'
+ - 'Event Queues':
+ - 'event_queue overview': 'os/core_os/event_queue/event_queue.md'
+ - 'os_eventq_get': 'os/core_os/event_queue/os_eventq_get.md'
+ - 'os_eventq_init': 'os/core_os/event_queue/os_eventq_init.md'
+ - 'os_eventq_put': 'os/core_os/event_queue/os_eventq_put.md'
+ - 'os_eventq_put2': 'os/core_os/event_queue/os_eventq_put2.md'
+ - 'os_eventq_remove': 'os/core_os/event_queue/os_eventq_remove.md'
+ - 'Semaphores':
+ - 'semaphore overview': 'os/core_os/semaphore/semaphore.md'
+ - 'os_sem_delete': 'os/core_os/semaphore/os_sem_delete.md'
+ - 'os_sem_init': 'os/core_os/semaphore/os_sem_init.md'
+ - 'os_sem_pend': 'os/core_os/semaphore/os_sem_pend.md'
+ - 'os_sem_release': 'os/core_os/semaphore/os_sem_release.md'
+ - 'Mutexes':
+ - 'mutex overview': 'os/core_os/mutex/mutex.md'
+ - 'os_mutex_delete': 'os/core_os/mutex/os_mutex_delete.md'
+ - 'os_mutex_init': 'os/core_os/mutex/os_mutex_pend.md'
+ - 'os_mutex_release': 'os/core_os/mutex/os_mutex_release.md'
+ - 'Memory Pools':
+ - 'mempool overview': 'os/core_os/memory_pool/memory_pool.md'
+ - 'os_memblock_get': 'os/core_os/memory_pool/os_memblock_get.md'
+ - 'os_mempool_init': 'os/core_os/memory_pool/os_mempool_init.md'
+ - 'os_memblock_put': 'os/core_os/memory_pool/os_memblock_put.md'
+ - 'OS_MEMPOOL_BYTES': 'os/core_os/memory_pool/OS_MEMPOOL_BYTES.md'
+ - 'Heap':
+ - 'heap overview': 'os/core_os/heap/heap.md'
+ - 'os_free': 'os/core_os/heap/os_free.md'
+ - 'os_malloc': 'os/core_os/heap/os_malloc.md'
+ - 'os_realloc': 'os/core_os/heap/os_realloc.md'
+ - 'Mbufs':
+ - 'mbuf overview': 'os/core_os/mbuf/mbuf.md'
+ - '_os_mbuf_copypkthdr': 'os/core_os/mbuf/_os_mbuf_copypkthdr.md'
+ - '_os_msys_find_pool': 'os/core_os/mbuf/_os_msys_find_pool.md'
+ - 'os_mbuf_adj': 'os/core_os/mbuf/os_mbuf_adj.md'
+ - 'os_mbuf_append': 'os/core_os/mbuf/os_mbuf_append.md'
+ - 'os_mbuf_concat': 'os/core_os/mbuf/os_mbuf_concat.md'
+ - 'os_mbuf_copydata': 'os/core_os/mbuf/os_mbuf_copydata.md'
+ - 'os_mbuf_copyinto': 'os/core_os/mbuf/os_mbuf_copyinto.md'
+ - 'os_mbuf_dup': 'os/core_os/mbuf/os_mbuf_dup.md'
+ - 'os_mbuf_extend': 'os/core_os/mbuf/os_mbuf_extend.md'
+ - 'os_mbuf_free': 'os/core_os/mbuf/os_mbuf_free.md'
+ - 'os_mbuf_free_chain': 'os/core_os/mbuf/os_mbuf_free_chain.md'
+ - 'os_mbuf_get': 'os/core_os/mbuf/os_mbuf_get.md'
+ - 'os_mbuf_get_pkthdr': 'os/core_os/mbuf/os_mbuf_get_pkthdr.md'
+ - 'os_mbuf_memcmp': 'os/core_os/mbuf/os_mbuf_memcmp.md'
+ - 'os_mbuf_off': 'os/core_os/mbuf/os_mbuf_off.md'
+ - 'os_mbuf_pool_init': 'os/core_os/mbuf/os_mbuf_pool_init.md'
+ - 'os_mbuf_prepend': 'os/core_os/mbuf/os_mbuf_prepend.md'
+ - 'os_mbuf_pullup': 'os/core_os/mbuf/os_mbuf_pullup.md'
+ - 'os_mqueue_get': 'os/core_os/mbuf/os_mqueue_get.md'
+ - 'os_mqueue_init': 'os/core_os/mbuf/os_mqueue_init.md'
+ - 'os_mqueue_put': 'os/core_os/mbuf/os_mqueue_put.md'
+ - 'os_msys_get': 'os/core_os/mbuf/os_msys_get.md'
+ - 'os_msys_get_pkthdr': 'os/core_os/mbuf/os_msys_get_pkthdr.md'
+ - 'os_msys_register': 'os/core_os/mbuf/os_msys_register.md'
+ - 'os_msys_reset': 'os/core_os/mbuf/os_msys_reset.md'
+ - 'Sanity':
+ - 'sanity overview': 'os/core_os/sanity/sanity.md'
+ - 'os_sanity_check_init': 'os/core_os/sanity/os_sanity_check_init.md'
+ - 'os_sanity_check_list_lock': 'os/core_os/sanity/os_sanity_check_list_lock.md'
+ - 'os_sanity_check_list_unlock': 'os/core_os/sanity/os_sanity_check_list_unlock.md'
+ - 'os_sanity_check_register': 'os/core_os/sanity/os_sanity_check_register.md'
+ - 'os_sanity_check_reset': 'os/core_os/sanity/os_sanity_check_reset.md'
+ - 'os_sanity_task_init': 'os/core_os/sanity/os_sanity_task_init.md'
+ - 'os_sanity_task_loop': 'os/core_os/sanity/os_sanity_task_loop.md'
+ - 'Callout Functions':
+ - 'callout overview': 'os/core_os/callout/callout.md'
+ - 'os_callout_func_init': 'os/core_os/callout/os_callout_func_init.md'
+ - 'os_callout_init': 'os/core_os/callout/os_callout_init.md'
+ - 'os_callout_queued': 'os/core_os/callout/os_callout_queued.md'
+ - 'os_callout_reset': 'os/core_os/callout/os_callout_reset.md'
+ - 'os_callout_stop': 'os/core_os/callout/os_callout_stop.md'
+ - 'Porting to other Platforms': 'os/core_os/port_os.md'
+ - Modules:
+ - Console:
+ - 'console overview': 'os/modules/console/console.md'
+ - 'console_add_char': 'os/modules/console/console_add_char.md'
+ - 'console_blocking_mode': 'os/modules/console/console_blocking_mode.md'
+ - 'console_blocking_tx': 'os/modules/console/console_blocking_tx.md'
+ - 'console_init': 'os/modules/console/console_init.md'
+ - 'console_printf': 'os/modules/console/console_printf.md'
+ - 'console_pull_char': 'os/modules/console/console_pull_char.md'
+ - 'console_pull_char_head': 'os/modules/console/console_pull_char_head.md'
+ - 'console_queue_char': 'os/modules/console/console_queue_char.md'
+ - 'console_read': 'os/modules/console/console_read.md'
+ - 'console_rx_char': 'os/modules/console/console_rx_char.md'
+ - 'console_tx_char': 'os/modules/console/console_tx_char.md'
+ - 'console_write': 'os/modules/console/console_write.md'
+ - Shell:
+ - 'shell overview': 'os/modules/shell/shell.md'
+ - 'shell_cmd': 'os/modules/shell/shell_cmd.md'
+ - 'shell_cmd_list_lock': 'os/modules/shell/shell_cmd_list_lock.md'
+ - 'shell_cmd_list_unlock': 'os/modules/shell/shell_cmd_list_unlock.md'
+ - 'shell_cmd_register': 'os/modules/shell/shell_cmd_register.md'
+ - 'shell_console_rx_cb': 'os/modules/shell/shell_console_rx_cb.md'
+ - 'shell_echo_cmd': 'os/modules/shell/shell_echo_cmd.md'
+ - 'shell_help_cmd': 'os/modules/shell/shell_help_cmd.md'
+ - 'shell_nlip_input_register': 'os/modules/shell/shell_nlip_input_register.md'
+ - 'shell_nlip_mqueue_process': 'os/modules/shell/shell_nlip_mqueue_process.md'
+ - 'shell_nlip_mtx': 'os/modules/shell/shell_nlip_mtx.md'
+ - 'shell_nlip_output': 'os/modules/shell/shell_nlip_output.md'
+ - 'shell_nlip_process': 'os/modules/shell/shell_nlip_process.md'
+ - 'shell_os_mpool_display_cmd': 'os/modules/shell/shell_os_mpool_display_cmd.md'
+ - 'shell_os_tasks_display_cmd': 'os/modules/shell/shell_os_tasks_display_cmd.md'
+ - 'shell_process_command': 'os/modules/shell/shell_process_command.md'
+ - 'shell_read_console': 'os/modules/shell/shell_read_console.md'
+ - 'shell_task_func': 'os/modules/shell/shell_task_func.md'
+ - 'shell_task_init': 'os/modules/shell/shell_task_init.md'
+ - Bootloader:
+ - 'bootloader overview': 'os/modules/bootloader/bootloader.md'
+ - 'boot_build_status': 'os/modules/bootloader/boot_build_status.md'
+ - 'boot_build_status_one': 'os/modules/bootloader/boot_build_status_one.md'
+ - 'boot_clear_status': 'os/modules/bootloader/boot_clear_status.md'
+ - 'boot_copy_area': 'os/modules/bootloader/boot_copy_area.md'
+ - 'boot_copy_image': 'os/modules/bootloader/boot_copy_image.md'
+ - 'boot_erase_area': 'os/modules/bootloader/boot_erase_area.md'
+ - 'boot_fill_slot': 'os/modules/bootloader/boot_fill_slot.md'
+ - 'boot_find_image_area_idx': 'os/modules/bootloader/boot_find_image_area_idx.md'
+ - 'boot_find_image_part': 'os/modules/bootloader/boot_find_image_part.md'
+ - 'boot_find_image_slot': 'os/modules/bootloader/boot_find_image_slot.md'
+ - 'boot_go': 'os/modules/bootloader/boot_go.md'
+ - 'boot_init_flash': 'os/modules/bootloader/boot_init_flash.md'
+ - 'boot_move_area': 'os/modules/bootloader/boot_move_area.md'
+ - 'boot_read_image_header': 'os/modules/bootloader/boot_read_image_header.md'
+ - 'boot_read_image_headers': 'os/modules/bootloader/boot_read_image_headers.md'
+ - 'boot_read_status': 'os/modules/bootloader/boot_read_status.md'
+ - 'boot_select_image_slot': 'os/modules/bootloader/boot_select_image_slot.md'
+ - 'boot_slot_addr': 'os/modules/bootloader/boot_slot_addr.md'
+ - 'boot_slot_to_area_idx': 'os/modules/bootloader/boot_slot_to_area_idx.md'
+ - 'boot_swap_areas': 'os/modules/bootloader/boot_swap_areas.md'
+ - 'boot_vect_delete_main': 'os/modules/bootloader/boot_vect_delete_main.md'
+ - 'boot_vect_delete_test': 'os/modules/bootloader/boot_vect_delete_test.md'
+ - 'boot_vect_read_main': 'os/modules/bootloader/boot_vect_read_main.md'
+ - 'boot_vect_read_one': 'os/modules/bootloader/boot_vect_read_one.md'
+ - 'boot_vect_read_test': 'os/modules/bootloader/boot_vect_read_test.md'
+ - 'boot_write_status': 'os/modules/bootloader/boot_write_status.md'
+ - 'File System Abstraction': 'os/modules/filesystem.md'
+ - 'Newtron Flash File System': 'os/modules/nffs.md'
+ - Test Utilities:
+ - 'testutil overview': 'os/modules/testutil/testutil.md'
+ - 'tu_case_abort': 'os/modules/testutil/tu_case_abort.md'
+ - 'tu_case_append_assert_msg': 'os/modules/testutil/tu_case_append_assert_msg.md'
+ - 'tu_case_append_buf': 'os/modules/testutil/tu_case_append_buf.md'
+ - 'tu_case_append_file_info': 'os/modules/testutil/tu_case_append_file_info.md'
+ - 'tu_case_append_manual_pass_msg': 'os/modules/testutil/tu_case_append_manual_pass_msg.md'
+ - 'tu_case_complete': 'os/modules/testutil/tu_case_complete.md'
+ - 'tu_case_fail_assert': 'os/modules/testutil/tu_case_fail_assert.md'
+ - 'tu_case_init': 'os/modules/testutil/tu_case_init.md'
+ - 'tu_case_pass_manual': 'os/modules/testutil/tu_case_pass_manual.md'
+ - 'tu_case_set_name': 'os/modules/testutil/tu_case_set_name.md'
+ - 'tu_case_vappend_buf': 'os/modules/testutil/tu_case_vappend_buf.md'
+ - 'tu_case_write_fail_buf': 'os/modules/testutil/tu_case_write_fail_buf.md'
+ - 'tu_case_write_pass_auto': 'os/modules/testutil/tu_case_write_pass_auto.md'
+ - 'tu_case_write_pass_buf': 'os/modules/testutil/tu_case_write_pass_buf.md'
+ - 'tu_init': 'os/modules/testutil/tu_init.md'
+ - 'tu_restart': 'os/modules/testutil/tu_restart.md'
+ - 'tu_suite_init': 'os/modules/testutil/tu_suite_init.md'
+ - 'tu_suite_set_name': 'os/modules/testutil/tu_suite_set_name.md'
+ - Image Manager:
+ - 'imgmgr overview': 'os/modules/imgmgr/imgmgr.md'
+ - 'imgmgr_module_init': 'os/modules/imgmgr/imgmgr_module_init.md'
+ - 'imgr_boot_read': 'os/modules/imgmgr/imgr_boot_read.md'
+ - 'imgr_boot_write': 'os/modules/imgmgr/imgr_boot_write.md'
+ - 'imgr_file_download': 'os/modules/imgmgr/imgr_file_download.md'
+ - 'imgr_file_upload': 'os/modules/imgmgr/imgr_file_upload.md'
+ - 'imgr_list': 'os/modules/imgmgr/imgr_list.md'
+ - 'imgr_noop': 'os/modules/imgmgr/imgr_noop.md'
+ - 'imgr_read_file': 'os/modules/imgmgr/imgr_read_file.md'
+ - 'imgr_read_main': 'os/modules/imgmgr/imgr_read_main.md'
+ - 'imgr_read_test': 'os/modules/imgmgr/imgr_read_test.md'
+ - 'imgr_read_ver': 'os/modules/imgmgr/imgr_read_ver.md'
+ - 'imgr_upload': 'os/modules/imgmgr/imgr_upload.md'
+ - 'imgr_ver_jsonstr': 'os/modules/imgmgr/imgr_ver_jsonstr.md'
+ - 'imgr_ver_parse': 'os/modules/imgmgr/imgr_ver_parse.md'
+ - 'imgr_ver_str': 'os/modules/imgmgr/imgr_ver_str.md'
+ - 'imgr_write_file': 'os/modules/imgmgr/imgr_write_file.md'
+ - 'Baselibc library': 'os/modules/baselibc.md'
+ - 'Embedded Lua': 'os/modules/elua.md'
+ - JSON:
+ - 'JSON overview': 'os/modules/json/json.md'
+ - 'json_encode_object_entry': 'os/modules/json/json_encode_object_entry.md'
+ - 'json_encode_object_finish': 'os/modules/json/json_encode_object_finish.md'
+ - 'json_encode_object_key': 'os/modules/json/json_encode_object_key.md'
+ - 'json_encode_object_start': 'os/modules/json/json_encode_object_start.md'
+ - 'json_encode_value': 'os/modules/json/json_encode_value.md'
+ - 'json_internal_read_object': 'os/modules/json/json_internal_read_object.md'
+ - 'json_read_array': 'os/modules/json/json_read_array.md'
+ - 'json_read_object': 'os/modules/json/json_read_object.md'
+ - 'json_target_address': 'os/modules/json/json_target_address.md'
+- Manual for Newt Tool:
+ - Newt Tool:
+ - 'Command structure': 'newt/newt_ops.md'
+ - 'Command list': 'newt/newt_tool_reference.md'
+ - Packaging it:
+ - 'Creating Packages': 'newt/packaging/dist.md'
+- Manual for Newt Manager:
- 'Overview': 'newtmgr/overview.md'
- 'Protocol': 'newtmgr/protocol.md'
- 'Project Slinky': 'newtmgr/project-slinky.md'
-- Chapter 7 - Packaging it:
- - 'Creating Packages': 'packaging/dist.md'
markdown_extensions:
- toc:
[7/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_pull_char.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_pull_char.md b/docs/modules/console/console_pull_char.md
deleted file mode 100644
index 7f06172..0000000
--- a/docs/modules/console/console_pull_char.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_pull_char </font>
-
-```no-highlight
- static uint8_t
- console_pull_char(struct console_ring *cr)
-```
-
-Reads (remove) a byte from the console ring buffer. When you read (pull) an item, you read it at the current tail location, and the tail advances to the next position.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *cr | Pointer to the console ring buffer from where a character is to be removed |
-
-
-#### Returned values
-
-Returns the character pulled from the ring buffer.
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Read the characters in the ring buffer into a string.
-
-```no-highlight
-void
-task(struct console_ring *cr, char *str, int cnt)
-{
- for (i = 0; i < cnt; i++) {
- if (cr->cr_head == cr->cr_tail) {
- i = -1;
- break;
- }
- ch = console_pull_char(cr);
- *str++ = ch;
- }
-}
-```
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_pull_char_head.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_pull_char_head.md b/docs/modules/console/console_pull_char_head.md
deleted file mode 100644
index c266e41..0000000
--- a/docs/modules/console/console_pull_char_head.md
+++ /dev/null
@@ -1,57 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_pull_char_head </font>
-
-```no-highlight
- static void
- console_pull_char_head(struct console_ring *cr)
-```
-
-Removes the last character inserted into the ring buffer by moving back the head location and shrinking the ring size by 1.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| cr | Pointer to the console ring buffer from which the last inserted character must be deleted |
-
-
-#### Returned values
-
-None
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-In order to see a character getting deleted when a user hits backspace while typying a command, the following needs to happen in sequence:
-
-* output a backspace (move cursor back one character)
-* output space (erasing whatever character there was before)
-* output backspace (move cursor back one character)
-* remove the previous character from incoming RX queue
-
-The example below shows console_pull_char_head being used for the last step.
-
-```no-highlight
-void
-task(uint8_t data)
-{
- struct console_tty *ct = (struct console_tty *)arg;
- struct console_ring *tx = &ct->ct_tx;
- struct console_ring *rx = &ct->ct_rx;
-
- switch (data) {
- case '\b':
- console_add_char(tx, '\b');
- console_add_char(tx, ' ');
- console_add_char(tx, '\b');
- console_pull_char_head(rx);
- break;
- }
-}
-
-```
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_queue_char.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_queue_char.md b/docs/modules/console/console_queue_char.md
deleted file mode 100644
index 74e34f3..0000000
--- a/docs/modules/console/console_queue_char.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_queue_char </font>
-
-```no-highlight
- static void
- console_queue_char(char ch)
-```
-
-Manage the buffer queue before inserting a character into it. If the head of the output (transmit) console ring is right up to its tail, the queue needs to be drained first before any data can be added. Then it uses console_add_char function to add the character.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ch | Character to be inserted to the queue |
-
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Function blocks interrupts as a way of protecting against concurrent access to TX buffer.
-
-If TX buffer is full, the function waits for TX buffer to drain. And the way it does it currently is by calling os_time_delay(). Therefore this function should only be called from within a task context, not from an interrupt handler. We might want to change this...
-
-#### Example
-
-```no-highlight
-Insert example
-```
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_read.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_read.md b/docs/modules/console/console_read.md
deleted file mode 100644
index 9c7460f..0000000
--- a/docs/modules/console/console_read.md
+++ /dev/null
@@ -1,31 +0,0 @@
-i## <font color="#F2853F" style="font-size:24pt"> console_read </font>
-
-```no-highlight
- int
- console_read(char *str, int cnt)
-```
- Calls hal function hal_uart_start_rx to start receiving input from console terminal over serial port.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Give at least one example of usage.
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_rx_char.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_rx_char.md b/docs/modules/console/console_rx_char.md
deleted file mode 100644
index bb3c338..0000000
--- a/docs/modules/console/console_rx_char.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_rx_char </font>
-
-```no-highlight
- static int
- console_rx_char(void *arg, uint8_t data)
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Give at least one example of usage.
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_tx_char.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_tx_char.md b/docs/modules/console/console_tx_char.md
deleted file mode 100644
index d3f0dec..0000000
--- a/docs/modules/console/console_tx_char.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_tx_char </font>
-
-```no-highlight
- static int
- console_tx_char(void *arg)
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Give at least one example of usage.
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_write.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_write.md b/docs/modules/console/console_write.md
deleted file mode 100644
index 1d7a524..0000000
--- a/docs/modules/console/console_write.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_write </font>
-
-```no-highlight
- void
- console_write(char *str, int cnt)
-```
-Transmit characters to console display over serial port.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *str | pointer to the character or packet to be transmitted |
-| cnt | size of the character or packet |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Here is an example of the function being used in an echo command with a newline at the end.
-
-```no-highlight
-static int
-shell_echo_cmd(int argc, char **argv)
-{
- int i;
-
- for (i = 1; i < argc; i++) {
- console_write(argv[i], strlen(argv[i]));
- console_write(" ", sizeof(" ")-1);
- }
- console_write("\n", sizeof("\n")-1);
-
- return (0);
-}
-```
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/elua.md
----------------------------------------------------------------------
diff --git a/docs/modules/elua.md b/docs/modules/elua.md
deleted file mode 100644
index d49d9bb..0000000
--- a/docs/modules/elua.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# elua
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/filesystem.md
----------------------------------------------------------------------
diff --git a/docs/modules/filesystem.md b/docs/modules/filesystem.md
deleted file mode 100644
index 6f40d4c..0000000
--- a/docs/modules/filesystem.md
+++ /dev/null
@@ -1,750 +0,0 @@
-# Filesystem
-
-Mynewt provides a Flash File System abstraction layer (fs) to allow you to swap out the default Newtron File System (nffs) with a different file system of your choice.
-
-## Description
-
-The default file system used in the Mynewt OS is the Newtron Flash File System (nffs). Hence the `nffs` egg description lists `libs/fs` as a dependency.
-
-```no-highlight
-egg.name: libs/nffs
-egg.vers: 0.1
-egg.identities: NFFS
-egg.deps:
- - libs/os
- - libs/fs
- - libs/testutil
- - hw/hal
-```
-
-If the user wishes to use a different flash file system (say, "ownffs"), the directory containing "ownffs" code must include the `egg.yml` file stating the dependency on `libs/fs` listed as shown above. "ownffs" uses the `libs/fs` API available in mynewt, thus minimizing changes to other parts of the project.
-
-Note that this generic file system (`fs`) API does not expose any file system detection, initialization, and formatting functions. These function calls remain specific to the chosen file system. For example, Project Slinky uses the default Newtron File System (nffs) and therefore calls nffs_init() to initialize the nffs memory and data structures before any other file system operations are attempted. As shown below, the egg for Project Slinky includes the `libs/imgmgr` egg which in turn includes the `libs/bootutil ` egg. The egg description for `libs/bootutil` specifies `fs/nffs` as a dependency.
-
-```no-highlight
-
- egg.name: project/slinky
- egg.vers: 0.1
- egg.deps:
- - libs/os
- - libs/console/full
- - libs/shell
- - libs/newtmgr
- - libs/imgmgr
- - sys/config
- - sys/log
- - sys/stats
-```
-
-```no-highlight
-
- egg.name: libs/imgmgr
- egg.vers: 0.1
- egg.deps:
- - libs/newtmgr
- - libs/bootutil
- egg.deps.FS:
- - fs/fs
- egg.cflags.FS: -DFS_PRESENT
-```
-
-```no-highlight
-
- egg.name: libs/bootutil
- egg.vers: 0.1
- egg.deps:
- - fs/nffs
- - libs/os
- - libs/testutil
- - hw/hal
-```
-
-## Data Structures
-
-
-## API
-
-```no-highlight
- struct fs_file;
-```
-
-The functions available in this OS feature are:
-
-* [fs_open](#fs_open)
-* [fs_close](#fs_close)
-* [fs_read](#fs_read)
-* [fs_write](#fs_write)
-* [fs_seek](#fs_seek)
-* [fs_getpos](#fs_getpos)
-* [fs_filelen](#fs_filelen)
-* [fs_unlink](#fs_unlink)
-* [fs_rename](#fs_rename)
-* [fs_mkdir](#fs_mkdir)
-* [fs_opendir](#fs_opendir)
-* [fs_readdir](#fs_readdir)
-* [fs_closedir](#fs_closedir)
-* [fs_dirent_name](#fs_dirent_name)
-* [fs_dirent_is_dir](#fs_dirent_is_dir)
-
-Additional file system utilities that bundle some of the basic functions above are:
-
-* [fsutil_read_file](#fsutil_read_file)
-* [fsutil_write_file](#fsutil_write_file)
-
-
-## API Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> fs_open </font>
-
-```no-highlight
- int
- fs_open(const char *filename, uint8_t access_flags, struct fs_file **out_file);
-```
-
-Opens a file at the specified path. The result of opening a nonexistent file depends on the access flags specified. All intermediate directories must already exist.
-
-The mode strings passed to fopen() map to fs_open()'s access flags as follows:
-
-```no-highlight
- "r" - FS_ACCESS_READ
- "r+" - FS_ACCESS_READ | FS_ACCESS_WRITE
- "w" - FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
- "w+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
- "a" - FS_ACCESS_WRITE | FS_ACCESS_APPEND
- "a+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_APPEND
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| filename | Pointer to the file created at the path of the specified filename |
-| access_flags | Flags controlling file access; see above table |
-| out_file | On success, a pointer to the newly-created file handle gets written here|
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-There is no concept of current working directory. Therefore all file names should start with '/'.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_close </font>
-
-```no-highlight
- int
- fs_close(struct fs_file *file)
-```
-
-Closes the specified file and invalidates the file handle. If the file has already been unlinked, and this is the last open handle to the file, this operation causes the file to be deleted from disk.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the file to close |
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-Don't use file handle after closing the file.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_read </font>
-
-```no-highlight
- int
- fs_read(struct fs_file *file, uint32_t len, void *out_data, uint32_t *out_len);
-```
-
-Reads data from the specified file. If more data is requested than remains in the file, all available data is retrieved. Function returns in `out_len` the actual number of bytes read (less or equal to `len`).
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the the file to read from |
-| len | The number of bytes to attempt to read |
-| out_data | The destination buffer to read into
-| out_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-This type of short read results in a success return code.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_write </font>
-
-```no-highlight
- int
- fs_write(struct fs_file *file, const void *data, int len);
-```
-
-Writes the supplied data to the current offset of the specified file handle.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the file to write to |
-| data | The data to write |
-| len | The number of bytes to write |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_seek </font>
-
-```no-highlight
- int
- fs_seek(struct fs_file *file, uint32_t offset);
-```
-
-Positions a file's read and write pointer at the specified offset. The offset is expressed as the number of bytes from the start of the file (i.e., seeking to offset 0 places the pointer at the first byte in the file).
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the file to reposition |
-| offset | The 0-based file offset to seek to |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_getpos </font>
-
-```no-highlight
- uint32_t
- fs_getpos(const struct fs_file *file);
-```
-
-Retrieves the current read and write position of the specified open file.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the file to query |
-
-
-#### Returned values
-
-* The file offset, in bytes
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_filelen </font>
-
-```no-highlight
- int
- fs_filelen(const struct fs_file *file, uint32_t *out_len);
-
-```
-
-Retrieves the current length of the specified open file.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| file | Pointer to the file to query |
-| out_len | On success, the number of bytes in the file gets written here |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_unlink </font>
-
-```no-highlight
- int
- fs_unlink(const char *filename);
-
-```
-
-Unlinks the file or directory at the specified path. If the path refers to a directory, all the directory's descendants are recursively unlinked. Any open file handles refering to an unlinked file remain valid, and can be read from and written to.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| filename | The path of the file or directory to unlink |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_rename </font>
-
-```no-highlight
- int
- fs_rename(const char *from, const char *to);
-
-```
-
-Performs a rename and / or move of the specified source path to the specified destination.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| from | The source path |
-| to | The destination path |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-The source path can refer to either a file or a directory. All intermediate directories in the destination path must already exist. If the source path refers to a file, the destination path must contain a full filename path, rather than just the new parent directory. If an object already exists at the specified destination path, this function causes it to be unlinked prior to the rename (i.e., the destination gets clobbered).
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_mkdir </font>
-
-```no-highlight
- int
- fs_mkdir(const char *path);
-
-```
-
-Creates the directory represented by the specified path.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| path | Pointer to the directory to create |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure.
-
-#### Notes
-
-All intermediate directories must already exist. The specified path must start with a '/' character.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_opendir </font>
-
-```no-highlight
-
- int
- fs_opendir(const char *path, struct fs_dir **out_dir);
-
-```
-
-Opens the directory at the specified path. The directory's contents can be read with subsequent calls to fs_readdir(). When you are done with the directory handle, close it with fs_closedir().
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| path | Pointer to the directory to create |
-| out_dir | On success, points to the directory handle |
-
-
-#### Returned values
-
-* 0 on success
-* FS_ENOENT if the specified directory does not exist (no such file)
-* Other nonzero on error.
-
-#### Notes
-
-Unlinking files from the directory while it is open may result in unpredictable behavior. New files can be created inside the directory.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_readdir </font>
-
-```no-highlight
- int
- fs_readdir(struct fs_dir *dir, struct fs_dirent **out_dirent);
-
-```
-
-Reads the next entry in an open directory.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dir | The directory handle to read from |
-| out_dirent | On success, points to the next child entry in the specified directory |
-
-
-#### Returned values
-
-* 0 on success
-* FS_ENOENT if there are no more entries in the parent directory
-* Other nonzero on error.
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_closedir </font>
-
-```no-highlight
- int
- fs_closedir(struct fs_dir *dir);
-
-```
-
-Closes the specified directory handle.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dir | Pointer to the directory to close |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_dirent_name </font>
-
-```no-highlight
- int
- fs_dirent_name(const struct fs_dirent *dirent, size_t max_len,
- char *out_name, uint8_t *out_name_len);
-
-```
-
-Retrieves the filename of the specified directory entry.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dirent | Pointer to the directory entry to query |
-| max_len | Size of the "out_name" character buffer |
-| out_name | On success, the entry's filename is written here; always null-terminated |
-| out_name_len | On success, contains the actual length of the filename, NOT including the null-terminator |
-
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-The retrieved filename is always null-terminated. To ensure enough space to hold the full filename plus a null-termintor, a destination buffer of size (filename max length + 1) should be used.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fs_dirent_is_dir </font>
-
-```no-highlight
- int
- fs_dirent_is_dir(const struct fs_dirent *dirent);
-
-```
-
-Tells you whether the specified directory entry is a sub-directory or a regular file.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dirent | Pointer to the directory entry to query |
-
-
-#### Returned values
-
-* 1: The entry is a directory
-* 0: The entry is a regular file.
-
-#### Notes
-
-<any notes?>
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fsutil_read_file </font>
-
-```no-highlight
- int
- fsutil_read_file(const char *path, uint32_t offset, uint32_t len, void *dst,
- uint32_t *out_len);
-```
-
-Calls fs_open(), fs_read(), and fs_close() to open a file at the specified path, retrieve data from the file starting from the specified offset, and close the file and invalidate the file handle.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| path | Pointer to the directory entry to query |
-| offset | Position of the file's read pointer |
-| len | Number of bytes to attempt to read |
-| dst | Destination buffer to read into |
-| out_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-This is a convenience function. You can use it if the file is small (caller has enough buffer space to hold all the file contents in memory).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> fsutil_write_file </font>
-
-```no-highlight
- int
- fsutil_write_file(const char *path, const void *data, uint32_t len);
-```
-
-Calls fs_open(), fs_write(), and fs_close() to open a file at the specified path, write the supplied data to the current offset of the specified file handle, and close the file and invalidate the file handle.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| path | Pointer to the file to write to |
-| data | The data to write |
-| len | The number of bytes to write |
-
-#### Returned values
-
-* 0 on success
-* nonzero on failure
-
-#### Notes
-
-<any notes?>
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgmgr.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgmgr.md b/docs/modules/imgmgr/imgmgr.md
deleted file mode 100644
index 650314b..0000000
--- a/docs/modules/imgmgr/imgmgr.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Image Manager
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in imgmgr are:
-
-* [imgmgr_module_init](imgmgr_module_init.md)
-* [imgr_boot_read](imgr_boot_read.md)
-* [imgr_boot_write](imgr_boot_write.md)
-* [imgr_file_download](imgr_file_download.md)
-* [imgr_file_upload](imgr_file_upload.md)
-* [imgr_list](imgr_list.md)
-* [imgr_noop](imgr_noop.md)
-* [imgr_read_file](imgr_read_file.md)
-* [imgr_read_main](imgr_read_main.md)
-* [imgr_read_test](imgr_read_test.md)
-* [imgr_read_ver](imgr_read_ver.md)
-* [imgr_upload](imgr_upload.md)
-* [imgr_ver_jsonstr](imgr_ver_jsonstr.md)
-* [imgr_ver_parse](imgr_ver_parse.md)
-* [imgr_ver_str](imgr_ver_str.md)
-* [imgr_write_file](imgr_write_file.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgmgr_module_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgmgr_module_init.md b/docs/modules/imgmgr/imgmgr_module_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_boot_read.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_boot_read.md b/docs/modules/imgmgr/imgr_boot_read.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_boot_write.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_boot_write.md b/docs/modules/imgmgr/imgr_boot_write.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_file_download.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_file_download.md b/docs/modules/imgmgr/imgr_file_download.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_file_upload.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_file_upload.md b/docs/modules/imgmgr/imgr_file_upload.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_list.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_list.md b/docs/modules/imgmgr/imgr_list.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_noop.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_noop.md b/docs/modules/imgmgr/imgr_noop.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_read_file.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_read_file.md b/docs/modules/imgmgr/imgr_read_file.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_read_main.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_read_main.md b/docs/modules/imgmgr/imgr_read_main.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_read_test.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_read_test.md b/docs/modules/imgmgr/imgr_read_test.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_read_ver.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_read_ver.md b/docs/modules/imgmgr/imgr_read_ver.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_upload.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_upload.md b/docs/modules/imgmgr/imgr_upload.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_ver_jsonstr.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_ver_jsonstr.md b/docs/modules/imgmgr/imgr_ver_jsonstr.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_ver_parse.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_ver_parse.md b/docs/modules/imgmgr/imgr_ver_parse.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_ver_str.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_ver_str.md b/docs/modules/imgmgr/imgr_ver_str.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/imgmgr/imgr_write_file.md
----------------------------------------------------------------------
diff --git a/docs/modules/imgmgr/imgr_write_file.md b/docs/modules/imgmgr/imgr_write_file.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json.md b/docs/modules/json/json.md
deleted file mode 100644
index 4e1f920..0000000
--- a/docs/modules/json/json.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# JSON
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in json are:
-
-* [json_encode_object_entry](json_encode_object_entry.md)
-* [json_encode_object_finish](json_encode_object_finish.md)
-* [json_encode_object_key](json_encode_object_key.md)
-* [json_encode_object_start](json_encode_object_start.md)
-* [json_encode_value](json_encode_value.md)
-* [json_internal_read_object](json_internal_read_object.md)
-* [json_read_array](json_read_array.md)
-* [json_read_object](json_read_object.md)
-* [json_target_address](json_target_address.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_encode_object_entry.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_encode_object_entry.md b/docs/modules/json/json_encode_object_entry.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_encode_object_finish.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_encode_object_finish.md b/docs/modules/json/json_encode_object_finish.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_encode_object_key.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_encode_object_key.md b/docs/modules/json/json_encode_object_key.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_encode_object_start.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_encode_object_start.md b/docs/modules/json/json_encode_object_start.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_encode_value.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_encode_value.md b/docs/modules/json/json_encode_value.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_internal_read_object.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_internal_read_object.md b/docs/modules/json/json_internal_read_object.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_read_array.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_read_array.md b/docs/modules/json/json_read_array.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_read_object.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_read_object.md b/docs/modules/json/json_read_object.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/json/json_target_address.md
----------------------------------------------------------------------
diff --git a/docs/modules/json/json_target_address.md b/docs/modules/json/json_target_address.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/newtmgr.md
----------------------------------------------------------------------
diff --git a/docs/modules/newtmgr.md b/docs/modules/newtmgr.md
deleted file mode 100644
index a17a2c5..0000000
--- a/docs/modules/newtmgr.md
+++ /dev/null
@@ -1,139 +0,0 @@
-# Bootloader
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [boot_slot_addr](#boot_slot_addr)
-* [boot_find_image_slot](#boot_find_image_slot)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> boot_slot_addr </font>
-
-```no-highlight
- static void
- boot_slot_addr(int slot_num, uint8_t *flash_id, uint32_t *address)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> boot_find_image_slot </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/nffs.md
----------------------------------------------------------------------
diff --git a/docs/modules/nffs.md b/docs/modules/nffs.md
deleted file mode 100644
index 97ff43d..0000000
--- a/docs/modules/nffs.md
+++ /dev/null
@@ -1,564 +0,0 @@
-# Newtron Flash Filesystem (nffs)
-
-Mynewt comes with the flash file system called the Newtron Flash File System (nffs) which is designed with two priorities that makes it suitable for embedded use:
-
-* Minimal RAM usage
-* Reliability
-
-Mynewt also provides an abstraction layer API (fs) to allow you to swap out nffs with a different file system of your choice.
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Disk and data structures
-
-At the top level, an nffs disk is partitioned into areas. An area is a region
-of disk with the following properties:
-
-1. An area can be fully erased without affecting any other areas.
-2. A write to one area does not restrict writes to other areas.
-
- **Note**: Some flash hardware divides its memory space into "blocks." Writes within a block must be sequential, but writes to one block have no effect on what parts of other blocks can be written. Thus, for flash hardware with such a restriction, each area must comprise a discrete number of blocks.
-
-While not strictly necessary, it is recommended that all areas have the same
-size.
-
-On disk, each area is prefixed with the following header:
-
-```no-highlight
-/** On-disk representation of an area header. */
-struct nffs_disk_area {
- uint32_t nda_magic[4]; /* NFFS_AREA_MAGIC{0,1,2,3} */
- uint32_t nda_length; /* Total size of area, in bytes. */
- uint8_t nda_ver; /* Current nffs version: 0 */
- uint8_t nda_gc_seq; /* Garbage collection count. */
- uint8_t reserved8;
- uint8_t nda_id; /* 0xff if scratch area. */
-};
-```
-
-Beyond its header, an area contains a sequence of disk objects, representing
-the contents of the file system. There are two types of objects: **inodes** and
-**data blocks**. An inode represents a file or directory; a data block represents
-part of a file's contents.
-
-```no-highlight
-/** On-disk representation of an inode (file or directory). */
-struct nffs_disk_inode {
- uint32_t ndi_magic; /* NFFS_INODE_MAGIC */
- uint32_t ndi_id; /* Unique object ID. */
- uint32_t ndi_seq; /* Sequence number; greater supersedes
- lesser. */
- uint32_t ndi_parent_id; /* Object ID of parent directory inode. */
- uint8_t reserved8;
- uint8_t ndi_filename_len; /* Length of filename, in bytes. */
- uint16_t ndi_crc16; /* Covers rest of header and filename. */
- /* Followed by filename. */
-};
-```
-
-An inode filename's length cannot exceed 256 bytes. The filename is not
-null-terminated. The following ASCII characters are not allowed in a
-filename:
- * / (slash character)
- * \0 (NUL character)
-
-```no-highlight
-/** On-disk representation of a data block. */
-struct nffs_disk_block {
- uint32_t ndb_magic; /* NFFS_BLOCK_MAGIC */
- uint32_t ndb_id; /* Unique object ID. */
- uint32_t ndb_seq; /* Sequence number; greater supersedes lesser. */
- uint32_t ndb_inode_id; /* Object ID of owning inode. */
- uint32_t ndb_prev_id; /* Object ID of previous block in file;
- NFFS_ID_NONE if this is the first block. */
- uint16_t ndb_data_len; /* Length of data contents, in bytes. */
- uint16_t ndb_crc16; /* Covers rest of header and data. */
- /* Followed by 'ndb_data_len' bytes of data. */
-};
-```
-
-Each data block contains the ID of the previous data block in the file.
-Together, the set of blocks in a file form a reverse singly-linked list.
-
-The maximum number of data bytes that a block can contain is determined at
-initialization-time. The result is the greatest number which satisfies all of
-the following restrictions:
- o No more than 2048.
- o At least two maximum-sized blocks can fit in the smallest area.
-
-The 2048 number was chosen somewhat arbitrarily, and may change in the future.
-
-### ID space
-
-All disk objects have a unique 32-bit ID. The ID space is partitioned as
-follows:
- * 0x00000000 - 0x0fffffff: Directory inodes.
- * 0x10000000 - 0x7fffffff: File inodes.
- * 0x80000000 - 0xfffffffe: Data blocks.
- * 0xffffffff : Reserved (NFFS_ID_NONE)
-
-### Scratch area
-
-A valid nffs file system must contain a single "scratch area." The scratch
-area does not contain any objects of its own, and is only used during garbage
-collection. The scratch area must have a size greater than or equal to each
-of the other areas in flash.
-
-
-### RAM representation
-
-Every object in the file system is stored in a 256-entry hash table. An
-object's hash key is derived from its 32-bit ID. Each list in the hash table
-is sorted by time of use; most-recently-used is at the front of the list. All
-objects are represented by the following structure:
-
-```no-highlight
-/**
- * What gets stored in the hash table. Each entry represents a data block or
- * an inode.
- */
-struct nffs_hash_entry {
- SLIST_ENTRY(nffs_hash_entry) nhe_next;
- uint32_t nhe_id; /* 0 - 0x7fffffff if inode; else if block. */
- uint32_t nhe_flash_loc; /* Upper-byte = area idx; rest = area offset. */
-};
-```
-
-For each data block, the above structure is all that is stored in RAM. To
-acquire more information about a data block, the block header must be read
-from flash.
-
-Inodes require a fuller RAM representation to capture the structure of the
-file system. There are two types of inodes: **files** and **directories**. Each
-inode hash entry is actually an instance of the following structure:
-
-```no-highlight
-/** Each inode hash entry is actually one of these. */
-struct nffs_inode_entry {
- struct nffs_hash_entry nie_hash_entry;
- SLIST_ENTRY(nffs_inode_entry) nie_sibling_next;
- union {
- struct nffs_inode_list nie_child_list; /* If directory */
- struct nffs_hash_entry *nie_last_block_entry; /* If file */
- };
- uint8_t nie_refcnt;
-};
-```
-
-A directory inode contains a list of its child files and directories
-(fie_child_list). These entries are sorted alphabetically using the ASCII
-character set.
-
-A file inode contains a pointer to the last data block in the file
-(nie_last_block_entry). For most file operations, the reversed block list must
-be walked backwards. This introduces a number of speed inefficiencies:
- * All data blocks must be read to determine the length of the file.
- * Data blocks often need to be processed sequentially. The reversed
- nature of the block list transforms this from linear time to an O(n^2)
- operation.
-
-Furthermore, obtaining information about any constituent data block requires a
-separate flash read.
-
-### Inode cache and Data Block cache
-
-The speed issues are addressed by a pair of caches. Cached inodes entries
-contain the file length and a much more convenient doubly-linked list of
-cached data blocks. The benefit of using caches is that the size of the
-caches need not be proportional to the size of the file system. In other
-words, caches can address speed efficiency concerns without negatively
-impacting the file system's scalability.
-
-nffs requires both caches during normal operation, so it is not possible to
-disable them. However, the cache sizes are configurable, and both caches can
-be configured with a size of one if RAM usage must be minimized.
-
-The following data structures are used in the inode and data block caches.
-
-```no-highlight
-/** Full data block representation; not stored permanently in RAM. */
-struct nffs_block {
- struct nffs_hash_entry *nb_hash_entry; /* Points to real block entry. */
- uint32_t nb_seq; /* Sequence number; greater
- supersedes lesser. */
- struct nffs_inode_entry *nb_inode_entry; /* Owning inode. */
- struct nffs_hash_entry *nb_prev; /* Previous block in file. */
- uint16_t nb_data_len; /* # of data bytes in block. */
- uint16_t reserved16;
-};
-
-/** Represents a single cached data block. */
-struct nffs_cache_block {
- TAILQ_ENTRY(nffs_cache_block) ncb_link; /* Next / prev cached block. */
- struct nffs_block ncb_block; /* Full data block. */
- uint32_t ncb_file_offset; /* File offset of this block. */
-};
-
-/** Full inode representation; not stored permanently in RAM. */
-struct nffs_inode {
- struct nffs_inode_entry *ni_inode_entry; /* Points to real inode entry. */
- uint32_t ni_seq; /* Sequence number; greater
- supersedes lesser. */
- struct nffs_inode_entry *ni_parent; /* Points to parent directory. */
- uint8_t ni_filename_len; /* # chars in filename. */
- uint8_t ni_filename[NFFS_SHORT_FILENAME_LEN]; /* First 3 bytes. */
-};
-
-/** Doubly-linked tail queue of cached blocks; contained in cached inodes. */
-TAILQ_HEAD(nffs_block_cache_list, nffs_block_cache_entry);
-
-/** Represents a single cached file inode. */
-struct nffs_cache_inode {
- TAILQ_ENTRY(nffs_cache_inode) nci_link; /* Sorted; LRU at tail. */
- struct nffs_inode nci_inode; /* Full inode. */
- struct nffs_cache_block_list nci_block_list; /* List of cached blocks. */
- uint32_t nci_file_size; /* Total file size. */
-};
-```
-
-Only file inodes are cached; directory inodes are never cached.
-
-Within a cached inode, all cached data blocks are contiguous. E.g., if the
-start and end of a file are cached, then the middle must also be cached. A
-data block is only cached if its owning file is also cached.
-
-Internally, cached inodes are stored in a singly-linked list, ordered by time
-of use. The most-recently-used entry is the first element in the list. If a
-new inode needs to be cached, but the inode cache is full, the
-least-recently-used entry is freed to make room for the new one. The
-following operations cause an inode to be cached:
-
-* Querying a file's length.
-* Seeking within a file.
-* Reading from a file.
-* Writing to a file.
-
-The following operations cause a data block to be cached:
-
-* Reading from the block.
-* Writing to the block.
-
-If one of the above operations is applied to a data block that is not currently
-cached, nffs uses the following procedure to cache the necessary block:
-
-1. If none of the owning inode's blocks are currently cached, allocate a
- cached block entry corresponding to the requested block and insert it
- into the inode's list.
-2. Else if the requested file offset is less than that of the first cached
- block, bridge the gap between the inode's sequence of cached blocks and
- the block that now needs to be cached. This is accomplished by caching
- each block in the gap, finishing with the requested block.
-3. Else (the requested offset is beyond the end of the cache),
- a. If the requested offset belongs to the block that immediately follows the end of the cache, cache the block and append it to the list.
- b. Else, clear the cache, and populate it with the single entry corresponding to the requested block.
-
-If the system is unable to allocate a cached block entry at any point during
-the above procedure, the system frees up other blocks currently in the cache. This is accomplished as follows:
-
-* Iterate the inode cache in reverse (i.e., start with the least-recently-used entry). For each entry:
- a. If the entry's cached block list is empty, advance to the next entry.
- b. Else, free all the cached blocks in the entry's list.
-
-Because the system imposes a minimum block cache size of one, the above
-procedure will always reclaim at least one cache block entry. The above
-procedure may result in the freeing of the block list that belongs to the very
-inode being operated on. This is OK, as the final block to get cached is
-always the block being requested.
-
-
-## Configuration
-
-The file system is configured by populating fields in a global structure.
-Each field in the structure corresponds to a setting. All configuration must
-be done prior to calling nffs_init(). The configuration structure is defined
-as follows:
-
-```no-highlight
-
-struct nffs_config {
- /** Maximum number of inodes; default=1024. */
- uint32_t nc_num_inodes;
-
- /** Maximum number of data blocks; default=4096. */
- uint32_t nc_num_blocks;
-
- /** Maximum number of open files; default=4. */
- uint32_t nc_num_files;
-
- /** Inode cache size; default=4. */
- uint32_t nc_num_cache_inodes;
-
- /** Data block cache size; default=64. */
- uint32_t nc_num_cache_blocks;
- };
-
-extern struct nffs_config nffs_config;
-```
-
-Any fields that are set to 0 (or not set at all) inherit the corresponding
-default value. This means that it is impossible to configure any setting with
-a value of zero.
-
-
-## Initialization
-
-There are two means of initializing an nffs file system:
-
-1. Restore an existing file system via detection.
-2. Create a new file system via formatting.
-
-Both methods require the user to describe how the flash memory is divided into
-areas. This is accomplished with an array of struct nffs_area_desc, defined as
-follows:
-
-```no-highlight
-struct nffs_area_desc {
- uint32_t nad_offset; /* Flash offset of start of area. */
- uint32_t nad_length; /* Size of area, in bytes. */
-};
-```
-
-An array of area descriptors is terminated by an entry with a fad_length field
-of 0.
-
-One common initialization sequence is the following:
-
-1. Detect an nffs file system anywhere in flash.
-2. If no file system detected, format a new file system in a specific
- region of flash.
-
-
-## Detection
-
-The file system detection process consists of scanning a specified set of
-flash regions for valid nffs areas, and then populating the RAM representation
-of the file system with the detected objects. Detection is initiated with the
-following function:
-
-```no-highlight
-/**
- * Searches for a valid nffs file system among the specified areas. This
- * function succeeds if a file system is detected among any subset of the
- * supplied areas. If the area set does not contain a valid file system,
- * a new one can be created via a separate call to nffs_format().
- *
- * @param area_descs The area set to search. This array must be
- * terminated with a 0-length area.
- *
- * @return 0 on success;
- * NFFS_ECORRUPT if no valid file system was detected;
- * other nonzero on error.
- */
-int nffs_detect(const struct nffs_area_desc *area_descs);
-```
-As indicated, not every area descriptor needs to reference a valid nffs area.
-Detection is successful as long as a complete file system is detected
-somewhere in the specified regions of flash. If an application is unsure
-where a file system might be located, it can initiate detection across the
-entire flash region.
-
-A detected file system is valid if:
-
-1. At least one non-scratch area is present.
-2. At least one scratch area is present (only the first gets used if there is more than one).
-3. The root directory inode is present.
-
-During detection, each indicated region of flash is checked for a valid area
-header. The contents of each valid non-scratch area are then restored into
-the nffs RAM representation. The following procedure is applied to each object
-in the area:
-
-1. Verify the object's integrity via a crc16 check. If invalid, the object is discarded and the procedure restarts on the next object in the area.
-
-2. Convert the disk object into its corresponding RAM representation and insert it into the hash table. If the object is an inode, its reference count is initialized to 1, indicating ownership by its parent directory.
-
-3. If an object with the same ID is already present, then one supersedes the other. Accept the object with the greater sequence number and discard the other.
-
-4. If the object references a nonexistant inode (parent directory in the case of an inode; owning file in the case of a data block), insert a temporary "dummy" inode into the hash table so that inter-object links can be maintained until the absent inode is eventually restored. Dummy inodes are identified by a reference count of 0.
-
-5. If a delete record for an inode is encountered, the inode's parent pointer is set to null to indicate that it should be removed from RAM.
-
-If nffs encounters an object that cannot be identified (i.e., its magic number
-is not valid), it scans the remainder of the flash area for the next valid
-magic number. Upon encountering a valid object, nffs resumes the procedure
-described above.
-
-After all areas have been restored, a sweep is performed across the entire RAM
-representation so that invalid inodes can be deleted from memory.
-
-For each directory inode:
-
-* If its reference count is 0 (i.e., it is a dummy), migrate its children to the /lost+found directory, and delete it from the RAM representation. This should only happen in the case of file system corruption.
- * If its parent reference is null (i.e., it was deleted), delete it and all its children from the RAM representation.
-
-For each file inode:
-
-* If its reference count is 0 (i.e., it is a dummy), delete it from the RAM representation. This should only happen in the case of file system corruption. (We should try to migrate the file to the lost+found directory in this case, as mentioned in the todo section).
-
-When an object is deleted during this sweep, it is only deleted from the RAM
-representation; nothing is written to disk.
-
-When objects are migrated to the lost+found directory, their parent inode
-reference is permanently updated on the disk.
-
-In addition, a single scratch area is identified during the detection process.
-The first area whose 'fda_id' value is set to 0xff is designated as the file
-system scratch area. If no valid scratch area is found, the cause could be
-that the system was restarted while a garbage collection cycle was in progress.
-Such a condition is identified by the presence of two areas with the same ID.
-In such a case, the shorter of the two areas is erased and designated as the
-scratch area.
-
-
-## Formatting
-
-A new file system is created via formatting. Formatting is achieved via the
-following function:
-
-```no-highlight
-/**
- * Erases all the specified areas and initializes them with a clean nffs
- * file system.
- *
- * @param area_descs The set of areas to format.
- *
- * @return 0 on success;
- * nonzero on failure.
- */
-int nffs_format(const struct nffs_area_desc *area_descs);
-```
-
-On success, an area header is written to each of the specified locations. The
-largest area in the set is designated as the initial scratch area.
-
-
-## Flash writes
-
-The nffs implementation always writes in a strictly sequential fashion within an
-area. For each area, the system keeps track of the current offset. Whenever
-an object gets written to an area, it gets written to that area's current
-offset, and the offset is increased by the object's disk size.
-
-When a write needs to be performed, the nffs implementation selects the
-appropriate destination area by iterating though each area until one with
-sufficient free space is encountered.
-
-There is no write buffering. Each call to a write function results in a write
-operation being sent to the flash hardware.
-
-
-### New objects
-
-Whenever a new object is written to disk, it is assigned the following
-properties:
- * ID: A unique value is selected from the 32-bit ID space, as appropriate
- for the object's type.
- * Sequence number: 0
-
-When a new file or directory is created, a corresponding inode is written to
-flash. Likewise, a new data block also results in the writing of a
-corresponding disk object.
-
-
-### Moving/Renaming files and directories
-
-When a file or directory is moved or renamed, its corresponding inode is
-rewritten to flash with the following properties:
-
-* ID: Unchanged
-* Sequence number: Previous value plus one.
-* Parent inode: As specified by the move / rename operation.
-* Filename: As specified by the move / rename operation.
-
-Because the inode's ID is unchanged, all dependent objects remain valid.
-
-
-### Unlinking files and directories
-
-When a file or directory is unlinked from its parent directory, a deletion
-record for the unlinked inode gets written to flash. The deletion record is an
-inode with the following properties:
-
-* ID: Unchanged
-* Sequence number: Previous value plus one.
-* Parent inode ID: NFFS_ID_NONE
-
-When an inode is unlinked, no deletion records need to be written for the
-inode's dependent objects (constituent data blocks or child inodes). During
-the next file system detection, it is recognized that the objects belong to
-a deleted inode, so they are not restored into the RAM representation.
-
-If a file has an open handle at the time it gets unlinked, application code
-can continued to use the file handle to read and write data. All files retain
-a reference count, and a file isn't deleted from the RAM representation until
-its reference code drops to 0. Any attempt to open an unlinked file fails,
-even if the file is referenced by other file handles.
-
-
-### Writing to a file
-
-The following procedure is used whenever the application code writes to a file.
-First, if the write operation specifies too much data to fit into a single
-block, the operation is split into several separate write operations. Then,
-for each write operation:
-
-1\. Determine which existing blocks the write operation overlaps (n = number of overwritten blocks).
-
-2\. If n = 0, this is an append operation. Write a data block with the following properties:
-
- * ID: New unique value.
- * Sequence number: 0.
-
-3\. Else (n > 1), this write overlaps existing data.
-
- (a) For each block in [1, 2, ... n-1], write a new block containing the updated contents. Each new block supersedes the block it overwrites. That is, each block has the following properties:
-
- * ID: Unchanged
- * Sequence number: Previous value plus one.
-
- (b) Write the nth block. The nth block includes all appended data, if any. As with the other blocks, its ID is unchanged and its sequence number is incremented.
-
-Appended data can only be written to the end of the file. That is, "holes" are
-not supported.
-
-
-## Garbage collection
-
-When the file system is too full to accomodate a write operation, the system
-must perform garbage collection to make room. The garbage collection
-procedure is described below:
-
-* The non-scratch area with the lowest garbage collection sequence number is selected as the "source area." If there are other areas with the same sequence number, the one with the smallest flash offset is selected.
-
-* The source area's ID is written to the scratch area's header, transforming it into a non-scratch ID. This former scratch area is now known as the "destination area."
-
-* The RAM representation is exhaustively searched for collectible objects. The following procedure is applied to each inode in the system:
- * If the inode is resident in the source area, copy the inode record to the destination area.
- * If the inode is a file inode, walk the inode's list of data blocks, starting with the last block in the file. Each block that is resident in the source area is copied to the destination area. If there is a run of two or more blocks that are resident in the source area, they are consolidated and copied to the destination area as a single new block (subject to the maximum block size restriction).
-
-* The source area is reformatted as a scratch sector (i.e., is is fully erased, and its header is rewritten with an ID of 0xff). The area's garbage collection sequence number is incremented prior to rewriting the header. This area is now the new scratch sector.
-
-
-## Miscellaneous measures
-
-* RAM usage:
- * 24 bytes per inode
- * 12 bytes per data block
- * 36 bytes per inode cache entry
- * 32 bytes per data block cache entry
-
-* Maximum filename size: 256 characters (no null terminator required)
-* Disallowed filename characters: '/' and '\0'
-
-
-## Future enhancements
-
-* API function to traverse a directory.
-* Migrate corrupt files to the /lost+found directory during restore, rather than discarding them from RAM.
-* Error correction.
-* Encryption.
-* Compression.
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell.md b/docs/modules/shell/shell.md
deleted file mode 100644
index db575bc..0000000
--- a/docs/modules/shell/shell.md
+++ /dev/null
@@ -1,115 +0,0 @@
-# Shell
-
-The shell is the program which puts up a prompt for a command, processes commands, and returns output. Interacting with the console of a device is done using a shell program.
-
-
-## Description
-
-Shell processes console input one line at a time. Eggs can register handlers for their commands. Shell parses the input, matches it against the set of registered commands, and then calls the handler it finds.
-
-A few commands are currently available in the shell - `tasks`, `log`, and `stat stat`. A $ prompt sign will be coming soon!
-
-Create a sim target to check out these commands available in shell.
-
-```no-highlight
-user@~/dev/larva$ newt target create blinky_sim
-Creating target blinky_sim
-Target blinky_sim successfully created!
-user@~/dev/larva$ newt target set blinky_sim name=blinky_sim
-Target blinky_sim successfully set name to blinky_sim
-user@~/dev/larva$ newt target set blinky_sim arch=sim
-Target blinky_sim successfully set arch to sim
-user@~/dev/larva$ newt target set blinky_sim project=blinky
-Target blinky_sim successfully set project to blinky
-user@~/dev/larva$ newt target set blinky_sim bsp=hw/bsp/native
-Target blinky_sim successfully set bsp to hw/bsp/native
-user@~/dev/larva$ newt target set blinky_sim compiler_def=debug
-Target blinky_sim successfully set compiler_def to debug
-user@~/dev/larva$ newt target set blinky_sim compiler=sim
-Target blinky_sim successfully set compiler to sim
-user@~/dev/larva$ newt target show
-blinky_sim
- arch: sim
- bsp: hw/bsp/native
- compiler: sim
- compiler_def: debug
- name: blinky_sim
- project: blinky
-user@~/dev/larva$ newt target build blinky_sim
-Building target blinky_sim (project = blinky)
-Compiling case.c
-Compiling suite.c
-Compiling testutil.c
-..
-..
-Building project blinky
-Linking blinky.elf
-Successfully run!
-
-user@~/dev/larva$ ./project/blinky/bin/blinky_sim/blinky.elf
-uart0 at /dev/ttys005
-
-```
-
-Open up a new terminal to run minicom, a text-based serial port control and terminal emulation program. Set device name to the serial port of the target.
-
-```no-highlight
-user@~$ minicom -D /dev/ttys005
-Welcome to minicom 2.7
-
-OPTIONS:
-Compiled on Nov 24 2015, 16:14:21.
-Port /dev/ttys005, 11:32:17
-
-Press Meta-Z for help on special keys
-
-log
-174578:[0] bla
-174578:[0] bab
-
-tasks
-217809:6 tasks:
-217809: shell (prio: 3, nw: 0, flags: 0x0, ssize: 0, cswcnt: 59, tot_run_time: 0ms)
-217840: idle (prio: 255, nw: 0, flags: 0x0, ssize: 0, cswcnt: 18763, tot_run_time: 217809ms)
-217878: uart_poller (prio: 0, nw: 217819, flags: 0x0, ssize: 0, cswcnt: 18667, tot_run_time: 0ms)
-217923: task1 (prio: 1, nw: 218710, flags: 0x0, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
-217953: os_sanity (prio: 254, nw: 218710, flags: 0x0, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
-218010: task2 (prio: 2, nw: 217709, flags: 0x3, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
-
-stat stat
-229881:s0: 1
-
-```
-
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [shell_cmd](shell_cmd.md)
-* [shell_cmd_list_lock](shell_cmd_list_lock.md)
-* [shell_cmd_list_unlock](shell_cmd_list_unlock.md)
-* [shell_cmd_register](shell_cmd_register.md)
-* [shell_console_rx_cb](shell_console_rx_cb.md)
-* [shell_echo_cmd](shell_echo_cmd.md)
-* [shell_help_cmd](shell_help_cmd.md)
-* [shell_nlip_input_register](shell_nlip_input_register.md)
-* [shell_nlip_mqueue_process](shell_nlip_mqueue_process.md)
-* [shell_nlip_mtx](shell_nlip_mtx.md)
-* [shell_nlip_output](shell_nlip_output.md)
-* [shell_nlip_process](shell_nlip_process.md)
-* [shell_os_mpool_display_cmd](shell_os_mpool_display_cmd.md)
-* [shell_os_tasks_display_cmd](shell_os_tasks_display_cmd.md)
-* [shell_process_command](shell_process_command.md)
-* [shell_read_console](shell_read_console.md)
-* [shell_task_func](shell_task_func.md)
-* [shell_task_init](shell_task_init.md)
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_cmd.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_cmd.md b/docs/modules/shell/shell_cmd.md
deleted file mode 100644
index 4aad702..0000000
--- a/docs/modules/shell/shell_cmd.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> shell_cmd </font>
-
-```no-highlight
- static int
- shell_cmd(char *cmd, char **argv, int argc)
-```
-
-<Put description here>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| arg1 | description |
-| arg2 | description |
-| arg3 | description |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-What to look out for, special cases, things to consider
-
-#### Example
-
-
-
-```no-highlight
-
- give an example
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_cmd_list_lock.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_cmd_list_lock.md b/docs/modules/shell/shell_cmd_list_lock.md
deleted file mode 100644
index 44977cb..0000000
--- a/docs/modules/shell/shell_cmd_list_lock.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> shell_cmd_list_lock </font>
-
-```no-highlight
- static int
- shell_cmd_list_lock(void)
-```
-
-<Put description here>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| arg1 | description |
-| arg2 | description |
-| arg3 | description |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-What to look out for, special cases, things to consider
-
-#### Example
-
-
-
-```no-highlight
-
- give an example
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_cmd_list_unlock.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_cmd_list_unlock.md b/docs/modules/shell/shell_cmd_list_unlock.md
deleted file mode 100644
index 6604294..0000000
--- a/docs/modules/shell/shell_cmd_list_unlock.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> shell_cmd_list_unlock </font>
-
-```no-highlight
- static int
- shell_cmd_list_unlock(void)
-```
-
-<Put description here>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| arg1 | description |
-| arg2 | description |
-| arg3 | description |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-What to look out for, special cases, things to consider
-
-#### Example
-
-
-
-```no-highlight
-
- give an example
-
-```
-
----------------------
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_cmd_register.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_cmd_register.md b/docs/modules/shell/shell_cmd_register.md
deleted file mode 100644
index 9d2b3d6..0000000
--- a/docs/modules/shell/shell_cmd_register.md
+++ /dev/null
@@ -1,46 +0,0 @@
-```no-highlight
- int
- shell_cmd_register(struct shell_cmd *sc, char *cmd, shell_cmd_func_t func)
-```
-
-Register a shell command. When shell reads a line of input which starts with `cmd`, it calls the handler `func`. Caller must allocate data structure `sc`. Shell internally links this to it's list of command handlers.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| sc | Pointer to data structure shell egg uses to store info about the registered command |
-| cmd | Command getting registered |
-| func | Function to call when command is received from console |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Shell splits the arguments following the command into an array of character pointers, and passes these to registered handler. The function will be called in shell task's context, so the command handler should look out for possible issues due to concurrency.
-
-#### Example
-
-Here is FS registering command for 'ls'.
-
-```no-highlight
-static struct shell_cmd fs_ls_struct;
-
-void
-fs_cli_init(void)
-{
- int rc;
-
- rc = shell_cmd_register(&fs_ls_struct, "ls", fs_ls_cmd);
- if (rc != 0) {
- return;
- }
-}
-
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_console_rx_cb.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_console_rx_cb.md b/docs/modules/shell/shell_console_rx_cb.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_echo_cmd.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_echo_cmd.md b/docs/modules/shell/shell_echo_cmd.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_help_cmd.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_help_cmd.md b/docs/modules/shell/shell_help_cmd.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_nlip_input_register.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_nlip_input_register.md b/docs/modules/shell/shell_nlip_input_register.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_nlip_mqueue_process.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_nlip_mqueue_process.md b/docs/modules/shell/shell_nlip_mqueue_process.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_nlip_mtx.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_nlip_mtx.md b/docs/modules/shell/shell_nlip_mtx.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_nlip_output.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_nlip_output.md b/docs/modules/shell/shell_nlip_output.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_nlip_process.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_nlip_process.md b/docs/modules/shell/shell_nlip_process.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_os_mpool_display_cmd.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_os_mpool_display_cmd.md b/docs/modules/shell/shell_os_mpool_display_cmd.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_os_tasks_display_cmd.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_os_tasks_display_cmd.md b/docs/modules/shell/shell_os_tasks_display_cmd.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_process_command.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_process_command.md b/docs/modules/shell/shell_process_command.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_read_console.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_read_console.md b/docs/modules/shell/shell_read_console.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_task_func.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_task_func.md b/docs/modules/shell/shell_task_func.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shell/shell_task_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/shell/shell_task_init.md b/docs/modules/shell/shell_task_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgmgr_module_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgmgr_module_init.md b/docs/modules/shelltest/imgmgr_module_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_boot_read.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_boot_read.md b/docs/modules/shelltest/imgr_boot_read.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_boot_write.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_boot_write.md b/docs/modules/shelltest/imgr_boot_write.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_file_download.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_file_download.md b/docs/modules/shelltest/imgr_file_download.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_file_upload.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_file_upload.md b/docs/modules/shelltest/imgr_file_upload.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_list.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_list.md b/docs/modules/shelltest/imgr_list.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_noop.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_noop.md b/docs/modules/shelltest/imgr_noop.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_read_file.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_read_file.md b/docs/modules/shelltest/imgr_read_file.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_read_main.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_read_main.md b/docs/modules/shelltest/imgr_read_main.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_read_test.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_read_test.md b/docs/modules/shelltest/imgr_read_test.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_read_ver.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_read_ver.md b/docs/modules/shelltest/imgr_read_ver.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_upload.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_upload.md b/docs/modules/shelltest/imgr_upload.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_ver_jsonstr.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_ver_jsonstr.md b/docs/modules/shelltest/imgr_ver_jsonstr.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_ver_parse.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_ver_parse.md b/docs/modules/shelltest/imgr_ver_parse.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_ver_str.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_ver_str.md b/docs/modules/shelltest/imgr_ver_str.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/imgr_write_file.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/imgr_write_file.md b/docs/modules/shelltest/imgr_write_file.md
deleted file mode 100644
index e69de29..0000000
[9/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
added pages for the Core OS functions
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/9b0bc2e0
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/9b0bc2e0
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/9b0bc2e0
Branch: refs/heads/master
Commit: 9b0bc2e09cf22ff7fb00f3b0bd43aab846294af7
Parents: 87e9d34
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Feb 19 18:51:49 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Feb 19 18:51:49 2016 -0800
----------------------------------------------------------------------
custom-theme/documentation.html | 4 +-
custom-theme/toc.html | 2 +-
.../pics/STM32f3discovery_connector.png | Bin 612760 -> 0 bytes
docs/get_acclimated/project2.md | 380 -------
docs/get_acclimated/project3.md | 1 -
docs/get_acclimated/vocabulary.md | 170 ---
docs/get_started/how_to_edit_docs.md | 187 ---
docs/get_started/newt_concepts.md | 48 -
docs/get_started/pics/bottomview.png | Bin 1995826 -> 0 bytes
docs/get_started/pics/topview.png | Bin 1945584 -> 0 bytes
docs/get_started/project1.md | 1075 ------------------
docs/get_started/try_markdown.md | 32 -
docs/modules/baselibc.md | 174 ---
docs/modules/bootloader/boot_build_status.md | 0
.../modules/bootloader/boot_build_status_one.md | 0
docs/modules/bootloader/boot_clear_status.md | 0
docs/modules/bootloader/boot_copy_area.md | 0
docs/modules/bootloader/boot_copy_image.md | 0
docs/modules/bootloader/boot_erase_area.md | 0
docs/modules/bootloader/boot_fill_slot.md | 0
.../bootloader/boot_find_image_area_idx.md | 0
docs/modules/bootloader/boot_find_image_part.md | 0
docs/modules/bootloader/boot_find_image_slot.md | 0
docs/modules/bootloader/boot_go.md | 0
docs/modules/bootloader/boot_init_flash.md | 0
docs/modules/bootloader/boot_move_area.md | 0
.../bootloader/boot_read_image_header.md | 0
.../bootloader/boot_read_image_headers.md | 0
docs/modules/bootloader/boot_read_status.md | 0
.../bootloader/boot_select_image_slot.md | 0
docs/modules/bootloader/boot_slot_addr.md | 0
.../modules/bootloader/boot_slot_to_area_idx.md | 0
docs/modules/bootloader/boot_swap_areas.md | 0
.../modules/bootloader/boot_vect_delete_main.md | 0
.../modules/bootloader/boot_vect_delete_test.md | 0
docs/modules/bootloader/boot_vect_read_main.md | 0
docs/modules/bootloader/boot_vect_read_one.md | 0
docs/modules/bootloader/boot_vect_read_test.md | 0
docs/modules/bootloader/boot_write_status.md | 0
docs/modules/bootloader/bootloader.md | 46 -
docs/modules/console/console.md | 92 --
docs/modules/console/console_add_char.md | 41 -
docs/modules/console/console_blocking_mode.md | 46 -
docs/modules/console/console_blocking_tx.md | 46 -
docs/modules/console/console_init.md | 32 -
docs/modules/console/console_printf.md | 61 -
docs/modules/console/console_pull_char.md | 47 -
docs/modules/console/console_pull_char_head.md | 57 -
docs/modules/console/console_queue_char.md | 33 -
docs/modules/console/console_read.md | 31 -
docs/modules/console/console_rx_char.md | 30 -
docs/modules/console/console_tx_char.md | 30 -
docs/modules/console/console_write.md | 46 -
docs/modules/elua.md | 17 -
docs/modules/filesystem.md | 750 ------------
docs/modules/imgmgr/imgmgr.md | 35 -
docs/modules/imgmgr/imgmgr_module_init.md | 0
docs/modules/imgmgr/imgr_boot_read.md | 0
docs/modules/imgmgr/imgr_boot_write.md | 0
docs/modules/imgmgr/imgr_file_download.md | 0
docs/modules/imgmgr/imgr_file_upload.md | 0
docs/modules/imgmgr/imgr_list.md | 0
docs/modules/imgmgr/imgr_noop.md | 0
docs/modules/imgmgr/imgr_read_file.md | 0
docs/modules/imgmgr/imgr_read_main.md | 0
docs/modules/imgmgr/imgr_read_test.md | 0
docs/modules/imgmgr/imgr_read_ver.md | 0
docs/modules/imgmgr/imgr_upload.md | 0
docs/modules/imgmgr/imgr_ver_jsonstr.md | 0
docs/modules/imgmgr/imgr_ver_parse.md | 0
docs/modules/imgmgr/imgr_ver_str.md | 0
docs/modules/imgmgr/imgr_write_file.md | 0
docs/modules/json/json.md | 28 -
docs/modules/json/json_encode_object_entry.md | 0
docs/modules/json/json_encode_object_finish.md | 0
docs/modules/json/json_encode_object_key.md | 0
docs/modules/json/json_encode_object_start.md | 0
docs/modules/json/json_encode_value.md | 0
docs/modules/json/json_internal_read_object.md | 0
docs/modules/json/json_read_array.md | 0
docs/modules/json/json_read_object.md | 0
docs/modules/json/json_target_address.md | 0
docs/modules/newtmgr.md | 139 ---
docs/modules/nffs.md | 564 ---------
docs/modules/shell/shell.md | 115 --
docs/modules/shell/shell_cmd.md | 39 -
docs/modules/shell/shell_cmd_list_lock.md | 39 -
docs/modules/shell/shell_cmd_list_unlock.md | 38 -
docs/modules/shell/shell_cmd_register.md | 46 -
docs/modules/shell/shell_console_rx_cb.md | 0
docs/modules/shell/shell_echo_cmd.md | 0
docs/modules/shell/shell_help_cmd.md | 0
docs/modules/shell/shell_nlip_input_register.md | 0
docs/modules/shell/shell_nlip_mqueue_process.md | 0
docs/modules/shell/shell_nlip_mtx.md | 0
docs/modules/shell/shell_nlip_output.md | 0
docs/modules/shell/shell_nlip_process.md | 0
.../modules/shell/shell_os_mpool_display_cmd.md | 0
.../modules/shell/shell_os_tasks_display_cmd.md | 0
docs/modules/shell/shell_process_command.md | 0
docs/modules/shell/shell_read_console.md | 0
docs/modules/shell/shell_task_func.md | 0
docs/modules/shell/shell_task_init.md | 0
docs/modules/shelltest/imgmgr_module_init.md | 0
docs/modules/shelltest/imgr_boot_read.md | 0
docs/modules/shelltest/imgr_boot_write.md | 0
docs/modules/shelltest/imgr_file_download.md | 0
docs/modules/shelltest/imgr_file_upload.md | 0
docs/modules/shelltest/imgr_list.md | 0
docs/modules/shelltest/imgr_noop.md | 0
docs/modules/shelltest/imgr_read_file.md | 0
docs/modules/shelltest/imgr_read_main.md | 0
docs/modules/shelltest/imgr_read_test.md | 0
docs/modules/shelltest/imgr_read_ver.md | 0
docs/modules/shelltest/imgr_upload.md | 0
docs/modules/shelltest/imgr_ver_jsonstr.md | 0
docs/modules/shelltest/imgr_ver_parse.md | 0
docs/modules/shelltest/imgr_ver_str.md | 0
docs/modules/shelltest/imgr_write_file.md | 0
docs/modules/shelltest/shelltest.md | 92 --
docs/modules/testutil/testutil.md | 38 -
docs/modules/testutil/tu_case_abort.md | 0
.../testutil/tu_case_append_assert_msg.md | 0
docs/modules/testutil/tu_case_append_buf.md | 0
.../testutil/tu_case_append_file_info.md | 0
.../testutil/tu_case_append_manual_pass_msg.md | 0
docs/modules/testutil/tu_case_complete.md | 0
docs/modules/testutil/tu_case_fail_assert.md | 0
docs/modules/testutil/tu_case_init.md | 0
docs/modules/testutil/tu_case_pass_manual.md | 0
docs/modules/testutil/tu_case_set_name.md | 0
docs/modules/testutil/tu_case_vappend_buf.md | 0
docs/modules/testutil/tu_case_write_fail_buf.md | 0
.../modules/testutil/tu_case_write_pass_auto.md | 0
docs/modules/testutil/tu_case_write_pass_buf.md | 0
docs/modules/testutil/tu_init.md | 0
docs/modules/testutil/tu_restart.md | 0
docs/modules/testutil/tu_suite_init.md | 0
docs/modules/testutil/tu_suite_set_name.md | 0
docs/newt/packaging/dist.md | 0
docs/os/callout.md | 261 -----
docs/os/context_switch.md | 141 ---
docs/os/core_os/callout/callout.md | 62 +
docs/os/core_os/callout/os_callout_func_init.md | 45 +
docs/os/core_os/callout/os_callout_init.md | 40 +
docs/os/core_os/callout/os_callout_queued.md | 34 +
docs/os/core_os/callout/os_callout_reset.md | 35 +
docs/os/core_os/callout/os_callout_stop.md | 36 +
.../os/core_os/context_switch/context_switch.md | 29 +
docs/os/core_os/context_switch/os_sched.md | 0
.../context_switch/os_sched_ctx_sw_hook.md | 0
.../context_switch/os_sched_get_current_task.md | 0
.../core_os/context_switch/os_sched_insert.md | 0
.../context_switch/os_sched_next_task.md | 0
.../context_switch/os_sched_os_timer_exp.md | 0
.../core_os/context_switch/os_sched_resort.md | 0
.../context_switch/os_sched_set_current_task.md | 0
.../os/core_os/context_switch/os_sched_sleep.md | 0
.../core_os/context_switch/os_sched_wakeup.md | 0
docs/os/core_os/event_queue/event_queue.md | 66 ++
docs/os/core_os/event_queue/os_eventq_get.md | 40 +
docs/os/core_os/event_queue/os_eventq_init.md | 45 +
docs/os/core_os/event_queue/os_eventq_put.md | 49 +
docs/os/core_os/event_queue/os_eventq_put2.md | 41 +
docs/os/core_os/event_queue/os_eventq_remove.md | 36 +
docs/os/core_os/heap/heap.md | 25 +
docs/os/core_os/heap/os_free.md | 32 +
docs/os/core_os/heap/os_malloc.md | 39 +
docs/os/core_os/heap/os_realloc.md | 33 +
docs/os/core_os/mbuf/_os_mbuf_copypkthdr.md | 0
docs/os/core_os/mbuf/_os_msys_find_pool.md | 0
docs/os/core_os/mbuf/mbuf.md | 43 +
docs/os/core_os/mbuf/os_mbuf_adj.md | 0
docs/os/core_os/mbuf/os_mbuf_append.md | 0
docs/os/core_os/mbuf/os_mbuf_concat.md | 0
docs/os/core_os/mbuf/os_mbuf_copydata.md | 0
docs/os/core_os/mbuf/os_mbuf_copyinto.md | 0
docs/os/core_os/mbuf/os_mbuf_dup.md | 0
docs/os/core_os/mbuf/os_mbuf_extend.md | 0
docs/os/core_os/mbuf/os_mbuf_free.md | 0
docs/os/core_os/mbuf/os_mbuf_free_chain.md | 0
docs/os/core_os/mbuf/os_mbuf_get.md | 0
docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md | 0
docs/os/core_os/mbuf/os_mbuf_memcmp.md | 0
docs/os/core_os/mbuf/os_mbuf_off.md | 0
docs/os/core_os/mbuf/os_mbuf_pool_init.md | 0
docs/os/core_os/mbuf/os_mbuf_prepend.md | 0
docs/os/core_os/mbuf/os_mbuf_pullup.md | 0
docs/os/core_os/mbuf/os_mqueue_get.md | 0
docs/os/core_os/mbuf/os_mqueue_init.md | 0
docs/os/core_os/mbuf/os_mqueue_put.md | 0
docs/os/core_os/mbuf/os_msys_get.md | 0
docs/os/core_os/mbuf/os_msys_get_pkthdr.md | 0
docs/os/core_os/mbuf/os_msys_register.md | 0
docs/os/core_os/mbuf/os_msys_reset.md | 0
docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md | 40 +
docs/os/core_os/memory_pool/memory_pool.md | 42 +
docs/os/core_os/memory_pool/os_memblock_get.md | 38 +
docs/os/core_os/memory_pool/os_memblock_put.md | 39 +
docs/os/core_os/memory_pool/os_mempool_init.md | 49 +
docs/os/core_os/mutex/mutex.md | 48 +
docs/os/core_os/mutex/os_mutex_delete.md | 33 +
docs/os/core_os/mutex/os_mutex_init.md | 39 +
docs/os/core_os/mutex/os_mutex_pend.md | 49 +
docs/os/core_os/mutex/os_mutex_release.md | 42 +
docs/os/core_os/mynewt_os.md | 44 +
docs/os/core_os/os_idle_task.md | 0
docs/os/core_os/os_init.md | 0
docs/os/core_os/os_init_idle_task.md | 0
docs/os/core_os/os_start.md | 0
docs/os/core_os/os_started.md | 0
docs/os/core_os/port_os.md | 12 +
docs/os/core_os/sanity/os_sanity_check_init.md | 0
.../core_os/sanity/os_sanity_check_list_lock.md | 0
.../sanity/os_sanity_check_list_unlock.md | 0
.../core_os/sanity/os_sanity_check_register.md | 0
docs/os/core_os/sanity/os_sanity_check_reset.md | 0
docs/os/core_os/sanity/os_sanity_task_init.md | 0
docs/os/core_os/sanity/os_sanity_task_loop.md | 0
docs/os/core_os/sanity/sanity.md | 25 +
docs/os/core_os/semaphore/os_sem_delete.md | 37 +
docs/os/core_os/semaphore/os_sem_init.md | 41 +
docs/os/core_os/semaphore/os_sem_pend.md | 46 +
docs/os/core_os/semaphore/os_sem_release.md | 42 +
docs/os/core_os/semaphore/semaphore.md | 43 +
docs/os/core_os/task/_clear_stack.md | 0
docs/os/core_os/task/os_task_count.md | 0
docs/os/core_os/task/os_task_info_get_next.md | 0
docs/os/core_os/task/os_task_init.md | 0
docs/os/core_os/task/os_task_next_id.md | 0
docs/os/core_os/task/os_task_sanity_checkin.md | 0
docs/os/core_os/task/task.md | 24 +
docs/os/core_os/time/os_time_delay.md | 0
docs/os/core_os/time/os_time_get.md | 0
docs/os/core_os/time/os_time_tick.md | 0
docs/os/core_os/time/time.md | 21 +
docs/os/event_queue.md | 287 -----
.../pics/STM32f3discovery_connector.png | Bin 0 -> 612760 bytes
docs/os/get_acclimated/project2.md | 380 +++++++
docs/os/get_acclimated/project3.md | 1 +
docs/os/get_started/how_to_edit_docs.md | 187 +++
docs/os/get_started/newt_concepts.md | 48 +
docs/os/get_started/pics/bottomview.png | Bin 0 -> 1995826 bytes
docs/os/get_started/pics/topview.png | Bin 0 -> 1945584 bytes
docs/os/get_started/project1.md | 1075 ++++++++++++++++++
docs/os/get_started/try_markdown.md | 32 +
docs/os/get_started/vocabulary.md | 170 +++
docs/os/heap.md | 136 ---
docs/os/mbufs.md | 142 ---
docs/os/memory_pool.md | 217 ----
docs/os/modules/baselibc.md | 174 +++
docs/os/modules/bootloader/boot_build_status.md | 0
.../modules/bootloader/boot_build_status_one.md | 0
docs/os/modules/bootloader/boot_clear_status.md | 0
docs/os/modules/bootloader/boot_copy_area.md | 0
docs/os/modules/bootloader/boot_copy_image.md | 0
docs/os/modules/bootloader/boot_erase_area.md | 0
docs/os/modules/bootloader/boot_fill_slot.md | 0
.../bootloader/boot_find_image_area_idx.md | 0
.../modules/bootloader/boot_find_image_part.md | 0
.../modules/bootloader/boot_find_image_slot.md | 0
docs/os/modules/bootloader/boot_go.md | 0
docs/os/modules/bootloader/boot_init_flash.md | 0
docs/os/modules/bootloader/boot_move_area.md | 0
.../bootloader/boot_read_image_header.md | 0
.../bootloader/boot_read_image_headers.md | 0
docs/os/modules/bootloader/boot_read_status.md | 0
.../bootloader/boot_select_image_slot.md | 0
docs/os/modules/bootloader/boot_slot_addr.md | 0
.../modules/bootloader/boot_slot_to_area_idx.md | 0
docs/os/modules/bootloader/boot_swap_areas.md | 0
.../modules/bootloader/boot_vect_delete_main.md | 0
.../modules/bootloader/boot_vect_delete_test.md | 0
.../modules/bootloader/boot_vect_read_main.md | 0
.../os/modules/bootloader/boot_vect_read_one.md | 0
.../modules/bootloader/boot_vect_read_test.md | 0
docs/os/modules/bootloader/boot_write_status.md | 0
docs/os/modules/bootloader/bootloader.md | 46 +
docs/os/modules/console/console.md | 92 ++
docs/os/modules/console/console_add_char.md | 41 +
.../os/modules/console/console_blocking_mode.md | 46 +
docs/os/modules/console/console_blocking_tx.md | 46 +
docs/os/modules/console/console_init.md | 32 +
docs/os/modules/console/console_printf.md | 61 +
docs/os/modules/console/console_pull_char.md | 47 +
.../modules/console/console_pull_char_head.md | 57 +
docs/os/modules/console/console_queue_char.md | 33 +
docs/os/modules/console/console_read.md | 31 +
docs/os/modules/console/console_rx_char.md | 30 +
docs/os/modules/console/console_tx_char.md | 30 +
docs/os/modules/console/console_write.md | 46 +
docs/os/modules/elua.md | 17 +
docs/os/modules/filesystem.md | 750 ++++++++++++
docs/os/modules/imgmgr/imgmgr.md | 35 +
docs/os/modules/imgmgr/imgmgr_module_init.md | 0
docs/os/modules/imgmgr/imgr_boot_read.md | 0
docs/os/modules/imgmgr/imgr_boot_write.md | 0
docs/os/modules/imgmgr/imgr_file_download.md | 0
docs/os/modules/imgmgr/imgr_file_upload.md | 0
docs/os/modules/imgmgr/imgr_list.md | 0
docs/os/modules/imgmgr/imgr_noop.md | 0
docs/os/modules/imgmgr/imgr_read_file.md | 0
docs/os/modules/imgmgr/imgr_read_main.md | 0
docs/os/modules/imgmgr/imgr_read_test.md | 0
docs/os/modules/imgmgr/imgr_read_ver.md | 0
docs/os/modules/imgmgr/imgr_upload.md | 0
docs/os/modules/imgmgr/imgr_ver_jsonstr.md | 0
docs/os/modules/imgmgr/imgr_ver_parse.md | 0
docs/os/modules/imgmgr/imgr_ver_str.md | 0
docs/os/modules/imgmgr/imgr_write_file.md | 0
docs/os/modules/json/json.md | 28 +
.../os/modules/json/json_encode_object_entry.md | 0
.../modules/json/json_encode_object_finish.md | 0
docs/os/modules/json/json_encode_object_key.md | 0
.../os/modules/json/json_encode_object_start.md | 0
docs/os/modules/json/json_encode_value.md | 0
.../modules/json/json_internal_read_object.md | 0
docs/os/modules/json/json_read_array.md | 0
docs/os/modules/json/json_read_object.md | 0
docs/os/modules/json/json_target_address.md | 0
docs/os/modules/newtmgr.md | 139 +++
docs/os/modules/nffs.md | 564 +++++++++
docs/os/modules/shell/shell.md | 115 ++
docs/os/modules/shell/shell_cmd.md | 39 +
docs/os/modules/shell/shell_cmd_list_lock.md | 39 +
docs/os/modules/shell/shell_cmd_list_unlock.md | 38 +
docs/os/modules/shell/shell_cmd_register.md | 46 +
docs/os/modules/shell/shell_console_rx_cb.md | 0
docs/os/modules/shell/shell_echo_cmd.md | 0
docs/os/modules/shell/shell_help_cmd.md | 0
.../modules/shell/shell_nlip_input_register.md | 0
.../modules/shell/shell_nlip_mqueue_process.md | 0
docs/os/modules/shell/shell_nlip_mtx.md | 0
docs/os/modules/shell/shell_nlip_output.md | 0
docs/os/modules/shell/shell_nlip_process.md | 0
.../modules/shell/shell_os_mpool_display_cmd.md | 0
.../modules/shell/shell_os_tasks_display_cmd.md | 0
docs/os/modules/shell/shell_process_command.md | 0
docs/os/modules/shell/shell_read_console.md | 0
docs/os/modules/shell/shell_task_func.md | 0
docs/os/modules/shell/shell_task_init.md | 0
docs/os/modules/shelltest/imgmgr_module_init.md | 0
docs/os/modules/shelltest/imgr_boot_read.md | 0
docs/os/modules/shelltest/imgr_boot_write.md | 0
docs/os/modules/shelltest/imgr_file_download.md | 0
docs/os/modules/shelltest/imgr_file_upload.md | 0
docs/os/modules/shelltest/imgr_list.md | 0
docs/os/modules/shelltest/imgr_noop.md | 0
docs/os/modules/shelltest/imgr_read_file.md | 0
docs/os/modules/shelltest/imgr_read_main.md | 0
docs/os/modules/shelltest/imgr_read_test.md | 0
docs/os/modules/shelltest/imgr_read_ver.md | 0
docs/os/modules/shelltest/imgr_upload.md | 0
docs/os/modules/shelltest/imgr_ver_jsonstr.md | 0
docs/os/modules/shelltest/imgr_ver_parse.md | 0
docs/os/modules/shelltest/imgr_ver_str.md | 0
docs/os/modules/shelltest/imgr_write_file.md | 0
docs/os/modules/shelltest/shelltest.md | 92 ++
docs/os/modules/testutil/testutil.md | 38 +
docs/os/modules/testutil/tu_case_abort.md | 0
.../testutil/tu_case_append_assert_msg.md | 0
docs/os/modules/testutil/tu_case_append_buf.md | 0
.../testutil/tu_case_append_file_info.md | 0
.../testutil/tu_case_append_manual_pass_msg.md | 0
docs/os/modules/testutil/tu_case_complete.md | 0
docs/os/modules/testutil/tu_case_fail_assert.md | 0
docs/os/modules/testutil/tu_case_init.md | 0
docs/os/modules/testutil/tu_case_pass_manual.md | 0
docs/os/modules/testutil/tu_case_set_name.md | 0
docs/os/modules/testutil/tu_case_vappend_buf.md | 0
.../modules/testutil/tu_case_write_fail_buf.md | 0
.../modules/testutil/tu_case_write_pass_auto.md | 0
.../modules/testutil/tu_case_write_pass_buf.md | 0
docs/os/modules/testutil/tu_init.md | 0
docs/os/modules/testutil/tu_restart.md | 0
docs/os/modules/testutil/tu_suite_init.md | 0
docs/os/modules/testutil/tu_suite_set_name.md | 0
docs/os/mutex.md | 217 ----
docs/os/mynewt_os.md | 159 ---
docs/os/port_os.md | 12 -
docs/os/sanity.md | 141 ---
docs/os/semaphore.md | 217 ----
docs/os/task.md | 140 ---
docs/os/time.md | 145 ---
docs/packaging/dist.md | 0
mkdocs.yml | 387 ++++---
386 files changed, 6373 insertions(+), 7009 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/custom-theme/documentation.html
----------------------------------------------------------------------
diff --git a/custom-theme/documentation.html b/custom-theme/documentation.html
index 1844490..36aefe0 100644
--- a/custom-theme/documentation.html
+++ b/custom-theme/documentation.html
@@ -16,10 +16,10 @@
</div>
</form>
</div>
- </div>
+ </div>
<div class="row">
{% for nav_item in nav %}
- {% if 'Chapter' in nav_item.title %}
+ {% if 'Manual' in nav_item.title %}
<div class="col-md-6 doc-section">
<div class="outline-title">{{ nav_item.title }}</div>
<p>{{ config.extra.chapters[nav_item.title] }}</p>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/custom-theme/toc.html
----------------------------------------------------------------------
diff --git a/custom-theme/toc.html b/custom-theme/toc.html
index b525a56..d49e728 100644
--- a/custom-theme/toc.html
+++ b/custom-theme/toc.html
@@ -12,7 +12,7 @@
</div>
<ul class="nav bs-sidenav">
{% for nav_item in nav %}
- {% if 'Chapter' in nav_item.title %}
+ {% if 'Manual' in nav_item.title %}
{% include 'nested_toc.html' %}
{% endif %}
{% endfor %}
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_acclimated/pics/STM32f3discovery_connector.png
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/pics/STM32f3discovery_connector.png b/docs/get_acclimated/pics/STM32f3discovery_connector.png
deleted file mode 100644
index 1f4437a..0000000
Binary files a/docs/get_acclimated/pics/STM32f3discovery_connector.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_acclimated/project2.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/project2.md b/docs/get_acclimated/project2.md
deleted file mode 100644
index 23cf001..0000000
--- a/docs/get_acclimated/project2.md
+++ /dev/null
@@ -1,380 +0,0 @@
-## Project 2 - Blinky on additional boards
-
-### Objective
-
-The goal of this tutorial is to download a generic firmware skeleton ("bootstrap image") that applies to any hardware and then throw in additional applicable eggs to generate a build for a specific board. In the process you will be exposed to more Mynewt terms and Newt tool commands.
-
-The following target hardware chips are covered:
-
-* [STM32F303VC MCU](#stm32f303vc-mcu) from STMicroelectronics
-* [nRF52 Series](#nrf52-series) from Nordic Semiconductors
-
-
-### STM32F303VC MCU
-
-#### Hardware needed
-
-* Discovery kit with STM32F303VC MCU
-* Laptop running Mac OS
-
-
-#### Step by Step Instructions to build image
-
-* The first step is to download the generic skeleton of the project. The eggs constituting the skeleton are not hardware architecture specific. The skeleton is maintained as a nest in a separate repository on Apache. You know it is a nest because there is a nest.yml file.
-
-```no-highlight
- [user:~/dev]$ newt nest create test_project
- Downloading nest skeleton from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole.git... ok!
- Nest test_project successfully created in ~/dev/go/test_project
-
- [user:~/dev]$ cd test_project/
- [user:~/dev/test_project]$ ls
- README.md compiler hw libs nest.yml
-```
-
-* Next, the clutch of eggs named larva is added from the nest (also named larva) from another repository on Apache. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
-```no-highlight
- [user:~/dev/test_project]$ newt nest add-clutch larva https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
- Downloading clutch.yml from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git/master... ok!
- Verifying clutch.yml format...
- ok!
- Clutch larva successfully installed to Nest.
-```
-
-* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
-
-```no-highlight
-
- [user:~/dev/test_project]$ newt egg install project/blinky
- Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
- Installing project/blinky
- Installing libs/console/full
- Installing libs/shell
- Installation was a success!
-
- [user:~/dev/test_project]$ newt egg install hw/bsp/stm32f3discovery
- Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
- Installing hw/bsp/stm32f3discovery
- Installing hw/mcu/stm/stm32f3xx
- Installing libs/cmsis-core
- Installing compiler/arm-none-eabi-m4
- Installation was a success!
-```
-
-* It's time to create a target for the project and define the target attributes.
-```no-highlight
- [user:~/dev/test_project]$ newt target create blink_f3disc
- Creating target blink_f3disc
- Target blink_f3disc successfully created!
-
- [user:~/dev/test_project]$ newt target set blink_f3disc project=blinky
- Target blink_f3disc successfully set project to blinky
-
- [user:~/dev/test_project]$ newt target set blink_f3disc bsp=hw/bsp/stm32f3discovery
- Target blink_f3disc successfully set bsp to hw/bsp/stm32f3discovery
-
- [user:~/dev/test_project]$ newt target set blink_f3disc compiler_def=debug
- Target blink_f3disc successfully set compiler_def to debug
-
- [user:~/dev/test_project]$ newt target set blink_f3disc compiler=arm-none-eabi-m4
- Target blink_f3disc successfully set compiler to arm-none-eabi-m4
-
- [user:~/dev/test_project]$ newt target set blink_f3disc arch=cortex_m4
- Target blink_f3disc successfully set arch to cortex_m4
-
- [user:~/dev/test_project]$ newt target show blink_f3disc
- blink_f3disc
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/stm32f3discovery
- compiler_def: debug
- compiler: arm-none-eabi-m4
- name: blink_f3disc
-```
-* Next, you get to build the target and generate an executable that can then be uploaded to the board. The STM32F3DISCOVERY board includes an ST-LINK/V2 embedded debug tool interface that will be used to program/debug the board. To program the MCU on the board, simply plug in the two jumpers on CN4, as shown in the picture in red. If you want to learn more about the board you will find the User Manual at [http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf](http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf)
-
-* 
-
-```no-highlight
- [user:~/dev/test_project]$ newt target build blink_f3disc
- Building target blink_f3disc (project = blinky)
- Compiling case.c
- Compiling suite.c
- Compiling testutil.c
- Compiling testutil_arch_arm.c
- Archiving libtestutil.a
- Compiling os.c
- Compiling os_callout.c
- Compiling os_eventq.c
- Compiling os_heap.c
- Compiling os_mbuf.c
- Compiling os_mempool.c
- Compiling os_mutex.c
- Compiling os_sanity.c
- Compiling os_sched.c
- Compiling os_sem.c
- Compiling os_task.c
- Compiling os_time.c
- Compiling os_arch_arm.c
- Assembling HAL_CM4.s
- Assembling SVC_Table.s
- Archiving libos.a
- Compiling hal_gpio.c
- Compiling stm32f3xx_hal_gpio.c
- Archiving libstm32f3xx.a
- Compiling cmsis_nvic.c
- Compiling libc_stubs.c
- Compiling os_bsp.c
- Compiling sbrk.c
- Compiling system_stm32f3xx.c
- Assembling startup_stm32f303xc.s
- Archiving libstm32f3discovery.a
- Compiling main.c
- Building project blinky
- Linking blinky.elf
- Successfully run!
-```
-
-* Finally, you have to download the image on to the board. You will see a blue light start to blink.
-```no-highlight
- [user:~/dev/test_project]$ newt target download blink_f3disc
- Downloading with /Users/user/dev/test_project/hw/bsp/stm32f3discovery/stm32f3discovery_download.sh
-```
-
-
-### nRF52 Series
-
-
-#### Hardware needed
-
-* nRF52 Development Kit
-* Laptop running Mac OS
-
-
-#### Step by Step Instructions to build image
-
-* The first step is to download the generic skeleton of the project. The eggs installed are not hardware architecture specific.
-```no-highlight
- []user@~/dev]$ newt nest create nordic_blinky
- Downloading nest skeleton from https://www.github.com/mynewt/tadpole... ok!
- Nest nordic_blinky successfully created in ~dev/nordic_blinky
-
- user@~/dev$ cd nordic_blinky/
-```
-
-* Then, the clutch of eggs named larva is added from the nest (also named larva) on the github. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
-```no-highlight
- []user@~/dev/nordic_blinky]$ newt nest add-clutch larva https://github.com/mynewt/larva
- Downloading clutch.yml from https://github.com/mynewt/larva/master... ok!
- Verifying clutch.yml format...ok!
- Clutch larva successfully installed to Nest.
-```
-* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
-```no-highlight
- [user@~/dev/nordic_blinky]$ newt egg install project/blinky
- Downloading larva from https://github.com/mynewt/larva//master... ok!
- Installing project/blinky
- Installation was a success!
-
-
- [user@~/dev/nordic_blinky]$ newt egg install hw/bsp/nrf52pdk
- Downloading larva from https://github.com/mynewt/larva//master... ok!
- Installing hw/bsp/nrf52pdk
- Installing hw/mcu/nordic/nrf52xxx
- Installing libs/cmsis-core
- Installing compiler/arm-none-eabi-m4
- Installation was a success!
-```
-
-* It's time to create a target for the project and define the target attributes.
-```no-highlight
- [user@~/dev/nordic_blinky]$ newt target create blink_nordic
- Creating target blink_nordic
- Target blink_nordic successfully created!
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic project=blinky
- Target blink_nordic successfully set project to blinky
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic bsp=hw/bsp/nrf52pdk
- Target blink_nordic successfully set bsp to hw/bsp/nrf52pdk
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler_def=debug
- Target blink_nordic successfully set compiler_def to debug
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler=arm-none-eabi-m4
- Target blink_nordic successfully set compiler to arm-none-eabi-m4
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic arch=cortex_m4
- Target blink_nordic successfully set arch to cortex_m4
- [user@~/dev/nordic_blinky]$ newt target show
- blink_nordic
- compiler: arm-none-eabi-m4
- name: blink_nordic
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/nrf52pdk
- compiler_def: debug
-```
-
-* Finally, you get to build the target and generate an executable that can now be uploaded to the board via the on-board SEGGER J-Link debugger.
-```no-highlight
- [user@~/dev/nordic_blinky]$ newt target build blink_nordic
- Building target blink_nordic (project = blinky)
- Compiling case.c
- Compiling suite.c
- Compiling testutil.c
- Compiling testutil_arch_arm.c
- Archiving libtestutil.a
- Compiling os.c
- Compiling os_callout.c
- Compiling os_eventq.c
- Compiling os_heap.c
- Compiling os_mbuf.c
- Compiling os_mempool.c
- Compiling os_mutex.c
- Compiling os_sanity.c
- Compiling os_sched.c
- Compiling os_sem.c
- Compiling os_task.c
- Compiling os_time.c
- Compiling os_arch_arm.c
- Assembling HAL_CM4.s
- Assembling SVC_Table.s
- Archiving libos.a
- Compiling hal_cputime.c
- Compiling hal_gpio.c
- Compiling hal_uart.c
- Archiving libnrf52xxx.a
- Compiling cmsis_nvic.c
- Compiling hal_bsp.c
- Compiling libc_stubs.c
- Compiling os_bsp.c
- Compiling sbrk.c
- Compiling system_nrf52.c
- Assembling gcc_startup_nrf52.s
- Archiving libnrf52pdk.a
- Compiling main.c
- Building project blinky
- Linking blinky.elf
- Successfully run!
-```
-* In order to be able to communicate with the SEGGER J-Link debugger on the dev board, you have to download and install the J-Link GDB Server software on to your laptop. You may download the "Software and documentation pack for Mac OS X" from [https://www.segger.com/jlink-software.html](https://www.segger.com/jlink-software.html). The command line version of the server is used in the steps below.
-
-* Open a new terminal and start a J-Link session.
-```no-highlight
- [user@~/dev/nordic_blinky/project/blinky/bin]$ which JLinkGDBServer
- /usr/local/bin/JLinkGDBServer
- [user@~/dev/nordic_blinky/project/blinky/bin]$ JLinkGDBServer -if SWD
- SEGGER J-Link GDB Server V5.02f Command Line Version
-
- JLinkARM.dll V5.02f (DLL compiled Oct 2 2015 20:55:03)
-
- -----GDB Server start settings-----
- GDBInit file: none
- GDB Server Listening port: 2331
- SWO raw output listening port: 2332
- Terminal I/O port: 2333
- Accept remote connection: yes
- Generate logfile: off
- Verify download: off
- Init regs on start: off
- Silent mode: off
- Single run mode: off
- Target connection timeout: 0 ms
- ------J-Link related settings------
- J-Link Host interface: USB
- J-Link script: none
- J-Link settings file: none
- ------Target related settings------
- Target device: unspecified
- Target interface: SWD
- Target interface speed: 1000kHz
- Target endian: little
-
- Connecting to J-Link...
- J-Link is connected.
- Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Aug 28 2015 19:26:24
- Hardware: V1.00
- S/N: 682371959
- Checking target voltage...
- Target voltage: 3.30 V
- Listening on TCP/IP port 2331
- Connecting to target...Connected to target
- Waiting for GDB connection...Connected to 127.0.0.1
-```
-
-* You need a configuration file for the GDB session to be opened correctly and the image ("blinky.elf") you built for this target downloaded to flash. A sample config script is given below. Alternatively, you could choose to type each command at the gdb prompt.
-```no-highlight
- [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ cat jlink-gdb.cfg
- echo ***Setting up the environment for debugging gdb.***\n
- set complaints 1
- set prompt (gdb)
- set endian little
- echo \n*** Set target charset ASCII\n
- set target-charset ASCII
- echo \n*** Connecting over port #2331 ***\n
- target remote localhost:2331
- echo \n*** Enable flash write and set device to nrf52 ***\n
- monitor flash download=1
- monitor flash device=nRF52
- echo \n*** loading blinky.elf ***\n
- load ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
- symbol-file ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
- echo \n*** Resetting target ***\n
- monitor reset
- echo \n*** Halting target ***\n
- monitor halt
-```
-* Start the gdb session and monitor that it loads the image, resets the target, and halts for a command to continue.
-```no-highlight
- [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ arm-none-eabi-gdb -x ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/jlink-gdb.cfg
-
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
- Type "show configuration" for configuration details.
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>.
- Find the GDB manual and other documentation resources online at:
- <http://www.gnu.org/software/gdb/documentation/>.
- For help, type "help".
- Type "apropos word" to search for commands related to "word".
-
- ***Setting up the environment for debugging gdb.***
- The target is assumed to be little endian
-
- *** Set target charset ASCII
-
- *** Connecting over port #2331 ***
- 0x00003c34 in ?? ()
-
- *** Enable flash write and set device to nrf52 ***
- Flash download enabled
- Selecting device: nRF52
-
- *** loading blinky.elf ***
- Loading section .text, size 0x5c84 lma 0x0
- Loading section .ARM.extab, size 0x24 lma 0x5c84
- Loading section .ARM.exidx, size 0xd8 lma 0x5ca8
- Loading section .data, size 0x8f8 lma 0x5d80
- Start address 0x48c, load size 26232
- Transfer rate: 12808 KB/sec, 2914 bytes/write.
- During symbol reading, unexpected overlap between:
- (A) section `.text' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x5c84)
- (B) section `*COM*' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x0).
- Will ignore section B.
-
- *** Resetting target ***
- Resetting target
-
- *** Halting target ***
-```
-* Type 'c' to continue. The LED on the board will start to blink. You will also see some activity in the terminal showing the open J-Link GDB server connection. The LED will continue to blink after you quit out of that connection.
-```no-highlight
- (gdb) c
- Continuing.
-```
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_acclimated/project3.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/project3.md b/docs/get_acclimated/project3.md
deleted file mode 100644
index 43e6a59..0000000
--- a/docs/get_acclimated/project3.md
+++ /dev/null
@@ -1 +0,0 @@
-## How to Test an Egg
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_acclimated/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/vocabulary.md b/docs/get_acclimated/vocabulary.md
deleted file mode 100644
index 4b6216f..0000000
--- a/docs/get_acclimated/vocabulary.md
+++ /dev/null
@@ -1,170 +0,0 @@
-## Understanding Newt Terms
-
-### Nest
-
-The nest is the base directory of your embedded software. It is meant to be the workspace containing a logical collection of the source code for one or more of your projects. A nest can contain multiple projects, and reflect multiple end products.
-
-As the base repository of your source code, the nest has a master branch and several other branches off it. You may choose any branch to nest on. Each project in your nest will typically consist of several [eggs](#egg). A project could be an egg itself as well. In addition to eggs, a local nest will contain additional items such as [target](#target) or build definitions, clutch description files, scripts etc.
-
-For example, a walk through the "larva" nest at [https://github.com/mynewt/larva.git](https://github.com/mynewt/larva.git) shows the following structure. The nest.yml file in the larva directory indicates that it is a nest. An egg will have the egg.yml file in it as shown below. By this nomenclature, each board support package for a particular chip is an egg, the API for the hardware abstraction layer is an egg, and so on.
-
-```no-highlight
-larva
- |- nest.yml
- |- compiler
- |- arm-none-eabi-m4
- |- sim
- |- hw (hardware)
- |- bsp (board support package)
- |- nrf52pdk (Nordic nRF52 series chip)
- |- egg.yml
- |- ...
- |- olimex_stm32-e407_devboard (used in Project Blinky)
- |- egg.yml
- |- ...
- |- stm32f3discovery (another board with stm32f3 mcu)
- |- egg.yml
- |- ...
- |- yet another board
- |- egg.yml
- |- ...
- |- hal (hardware abstraction layer APIs)
- |- egg.yml
- |- include
- |- hal_cputime.h
- |- hal_flash.h
- |- hal_gpio.h
- |- ... (header files for other peripherals)
- |- mcu (microcontroller)
- |- stm (STMicro family)
- |- stm32f3xx (STM32f3 series, 32-bit ARM Cortex-M4 core)
- |- egg.yml
- |- src
- |- hal_gpio.c (specific to the STM32f3 mcu)
- |- hal_cputime.c
- |- ... (code for other peripherals)
- |- nordic (Nordic Semiconductor family)
- |- nrf52xxx (nRF52 Series SoC, Cortex-M4F core)
- |- egg.yml
- |- src
- |- hal_gpio.c (specific to the nRF52 mcu )
- |- hal_cputime.c
- |- ... (code for other peripherals)
- |- yet another family of mcu
- |- ...
- |- libs
- |- bootutil (hw architecture independent boot loader library)
- |- egg.yml
- |- src
- |- loader.c
- |- ... (related source code files)
- |- nffs (hw architecture independent Newtron Flash File System)
- |- egg.yml
- |- src
- |- nffs.c
- |- ... (related source code files)
- |- another library
- |- egg.yml
- |- src
- |- ... (related source code files)
- |- project
- |- scripts
-
-
-```
-
-The newt tool offers the `nest` command to create and manage nests. In general, commands represent actions and flags are modifiers for those actions. A command can have children commands and optionally run an action. A full description of the `nest` command can be found in the newt tool reference in Chapter 3.
-```no-highlight
- newt nest [flags]
- newt nest [child-commands]
-```
-A complete list of all the nest commands can be found in the newt tool reference in [Newt Tool](../newt/newt_tool_reference.md).
-
-### Project
-
-Projects represent the individual build configurations of your embedded system and essentially defines your application. The project files are what dictate the resulting binary that is generated.
-
-Layout-wise, a project is a directory inside a nest and contains eggs required for a certain application. For example, the `blinky` egg sits in `project/blinky` directory of the `larva` nest. This egg is used in the blinky project (application) outlined in [Get Started](../get_started/project1.md). <*Note: This Will Change*>
-
-A project has the following concepts or properties associated with it. You can find them in the `<project-name>.yml` file in the project directory. For example, the `project/blinky` directory has the `blinky.yml` file indicating some or all of the properties below. Only the name of a project is required for the project to exist, however additional properties may need to be specified for the eggs in it to compile properly and produce an executable.
-
-* Project name
-* Base path of the project (nest/project/project-name by default)
-* Eggs belonging to the project
-* [Capabilities](#capabilities) that are required for the project or target
-* [Identity](#identity) to classify the type of project or target
-* Compiler flags to call out any specific compiler requirement
-
-A project could itself be an egg if it is a distributable package for a specific application.
-
-The newt tool offers various commands that you can use with a project. For example, if your project is an egg, you can use the following command to install a project from a nest.
-```no-highlight
- newt egg install [flags] <project egg name>
-```
-### Egg
-
-An egg is a distributable package of libraries. Just as an egg in nature has various parts each of which serves a certain purpose, the Mynewt egg consists of software parcels or modules that have different functions. However, unlike the egg in nature these software modules can exist by itself and may be distributed; therefore, they too are essentially eggs. Once this concept is grasped it is easy to see how an egg may consist of other eggs.
-
-The two main directories in an egg are `/include` and `/src`.
-
-The newt tool offers several egg commands to list, inspect, install, and do other operations on eggs. For example, the following command
-```no-highlight
- newt egg list
-```
-outputs all the eggs in the current nest where each egg has details on its version, path, and dependencies. A sample output for an egg is given below.
-```no-highlight
- Egg libs/os, version 0.1.0
- path: /Users/aditihilbert/dev/test_project/libs/os
- deps: libs/testutil@none#stable
-```
-A complete list of all the egg commands can be found in the newt tool reference in [Newt Tool](../newt/newt_tool_reference.md).
-
-### Clutch
-
-A clutch is a snapshot of all eggs in a remote nest at any point in time. On any given github branch, a nest with a clutch of eggs will contain a `clutch.yml` file that specifies the version number, dependencies, and hash value for each constituent egg as well as the name of the entire clutch and the github url for it. [Note: Currently ]
-
-You may download multiple clutches into your local nest as long as the names of the clutches are different. This allows you to mix and match various features and functionality coming from different clutches of eggs. You can see all the clutches in the `.nest/clutches` directory in your nest.
-
-The newt tool offers clutch management commands within the `newt nest` command. For example, the following command creates a new clutch using all the eggs in the current directory. It requires that a clutch name be specified and the url for the location of that clutch in the online repository. These two inputs go into the `clutch.yml` file in the nest.
-```no-highlight
- newt nest generate-clutch <name> <url>
-```
-Note that a clutch merely defines the eggs belonging together and requires the eggs to be installed (hatched) for the source code to be populated in the project.
-
-### Eggshell
-
-The term eggshell is used to refer to the eggs of a clutch in a remote repository. They are not useful on your local machine until you actually install them. So they are mere shells of themselves while sitting on the online repository. When you enter the following command outputs the total number of shells in each remote clutch.
-```no-highlight
- newt nest list-clutches
-```
-So, if you had two clutches installed, the output could be:
-```no-highlight
- Remote clutch larva (eggshells: 19)
- Remote clutch ble_test (eggshells: 15)
-```
-### Target
-
-A target is the hardware build or its software equivalent (e.g. test, simulator) set for a project. It tells the newt tool how to build the source code within a given nest. Once a new target is created, its architecture and other details needs to be defined. An example of a defined target named "blink_f3disc" is given below.
-```no-highlight
- blink_f3disc
- compiler_def: debug
- compiler: arm-none-eabi-m4
- name: blink_f3disc
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/stm32f3discovery
-```
-The newt tool offers commands to create, set up and manipulate targets. For example, the create command below creates an empty target named `my_target1` and the set command sets one detail of its definition, namely the architecture.
-```no-highlight
- newt target create my_target1
- newt target set my_target1 arch=cortex_m4
-```
-### Capability
-
-Capability is functionality that is exposed by an egg. A capability is tracked by its name and version. An egg may require capabilities exposed by another egg, thus establishing a dependency tracked through the egg.yml files.
-
-The newt tool can ascertain a map of all the egg capabilities and use it to check dependencies and make sure all the necessary eggs are in a project for a particular target.
-
-### Identity
-
-Identity is a property of a target or project in the newt world. A target may inherit it from a project or vice versa. It may be used to determine what eggs to include or how an egg code should behave in a build or which linkerscripts to use. For example, the identity of a lock is different from the identity of a wearable monitor. Even if they were to be built on the same hardware target, different features and behavior are required. Their different identities result in differing sets of eggs in the projects and/or the same egg behaving differently depending on the identity.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/how_to_edit_docs.md
----------------------------------------------------------------------
diff --git a/docs/get_started/how_to_edit_docs.md b/docs/get_started/how_to_edit_docs.md
deleted file mode 100644
index eb12868..0000000
--- a/docs/get_started/how_to_edit_docs.md
+++ /dev/null
@@ -1,187 +0,0 @@
-## How to Edit Docs
-
-### Objective
-
-We will go through the process of downloading existing doccumentation and adding some content to a test document.
-
-### Markdown, MkDocs, Mou
-
-The Mynewt documentation you see on the Apache incubator website is a bunch of HTML files generated using MkDocs which is a simple static site generation tool geared towards building project documentation. You can read about it at [http://www.mkdocs.org](http://www.mkdocs.org). Documentation source files are written in Markdown, and configured with a single YAML configuration file. Markdown is a lightweight markup language with plain text formatting syntax designed so that it can be converted to HTML and many other formats using a tool (which in our case is MkDocs).
-
-You do not need to install MkDocs unless you want to actually render your documentation in HTML in order to preview it before pushing your content to the remote repository. Typically, using a Markdown editor such as [Mou](http://25.io/mou/) is enough to check how it will look after the document has gone through MkDocs. Go ahead and download [Mou](http://25.io/mou/). If you are on a Windows machine, download the [editor of your choice](http://alternativeto.net/software/mou/?platform=windows).
-
-Currently someone in the project is designated to use MkDocs to generate the HTML pages periodically after changes have been reviewed and accepted into the master branch.
-
-
-### Access to the Apache repo
-
-Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
-
-If you are not a committer, you may follow the proposed non-committer workflow to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html). You will find the steps described in more detail later in this tutorial.
-
-### Making a local copy
-
-* Copy the document source files into a local directory and look at the contents of the copied directory to get an idea of the directory structure. Use http instead of https if you are a non-committer.
-```no-highlight
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git
- Cloning into 'incubator-mynewt-site'...
- remote: Counting objects: 330, done.
- remote: Compressing objects: 100% (263/263), done.
- remote: Total 330 (delta 120), reused 0 (delta 0)
- Receiving objects: 100% (330/330), 4.34 MiB | 830.00 KiB/s, done.
- Resolving deltas: 100% (120/120), done.
- Checking connectivity... done.
- $ ls
- incubator-mynewt-site
- $ ls incubator-mynewt-site/
- docs images mkdocs.yml
-```
-* Create a new branch to work on your documentation and move to that branch.
-```no-highlight
- $ git checkout -b <your-branch-name>
-```
-
-### File to be edited
-
-The file you will edit is [try_markdown.md](./try_markdown.md).
-
-### Editing an existing page
-
-* Open the application Mou.
-
-* Open the file incubator-mynewt-site/docs/get_started/try_markdown.md in Mou.
-
-* Edit the last item on the list.
-
-* Save and quit the application.
-
-You may want to review the documentation organization back in [Home](../index.md) to remind you how to locate files easily. The corresponding directory tree structure is shown below.
-```no-highlight
- .
- ├── docs
- │ ├── get_started
- │ │ ├── how_to_edit_docs.md
- │ │ ├── newt_concepts.md
- │ │ ├── pics
- │ │ │ ├── bottomview.png
- │ │ │ └── topview.png
- │ │ ├── project1.md
- │ │ └── try_markdown.md
- │ ├── get_acclimated
- │ │ ├── project2.md
- │ │ ├── project3.md
- │ │ ├── ... (more to be added)
- │ │ └── vocabulary.md
- │ ├── newt
- │ │ ├── newt_ops.md
- │ │ └── newt_tool_reference.md
- │ ├── os
- │ │ ├── context_switch.md
- │ │ ├── event_queue.md
- │ │ ├── heap.md
- │ │ ├── mbufs.md
- │ │ ├── memory_pool.md
- │ │ ├── mutex.md
- │ │ ├── mynewt_os.md
- │ │ ├── port_os.md
- │ │ ├── sanity.md
- │ │ ├── semaphore.md
- │ │ ├── task.md
- │ │ ├── time.md
- │ │ └── ... (more to be added)
- │ ├── modules
- │ │ ├── bootloader.md
- │ │ ├── console.md
- │ │ ├── filesystem.md
- │ │ ├── shell.md
- │ │ ├── testutil.md
- │ │ └── ... (more to be added)
- │ ├── packaging
- │ │ ├── dist.md
- │ │ └── ... (more to be added)
- │ ├── extra.css
- │ ├── images
- │ │ └── egg-logo.png
- │ └── index.md
- ├── images
- │ ├── asf_logo_wide.gif
- │ ├── content-bg.png
- │ └── egg-logo.png
- ├── mkdocs.yml
-```
-
-### Adding a new page
-
-If you create a new file somewhere in the `docs` subdirectory to add a new page, you have to add a line in the `mkdocs.yml` file at the correct level. For example, if you add a new module named "Ethernet" by creating a new file named `ethernet.md` in the `modules` subdirectory, you have to insert the following line under `Modules:` in the `mkdocs.yml` file.
-```no-highlight
- - 'Ethernet': 'modules/ethernet.md'
-```
-### Pushing changes to remote as a committer
-
-If you are not a committer yet, skip this section and proceed to the [next section](#sharing-changes-as-a-non-committer).
-
-* Check whether your remote git repository is set up. If you see the remote location as shown below you can skip the next step.
-```no-highlight
- $ git remote -v
- origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (fetch)
- origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (push)
-```
-* If, however, you do not see your remote repository, then set it up as follows.
-
-```no-highlight
- $ git remote add origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git
-```
-* First check the git status. It will show you that the `try_markdown.md` document has been modified. So you will stage a commit, and then commit the change. Finally, you will push the changes to the remote repository.
-
- During staging below using `git add`, we use the `-A` option indicating you want to stage all your modifications. Instead, you can choose to specify only the files that you want to. The commit message (specified after `-m`) should summarize what your changes are about.
-```no-highlight
- $ git status
- $ git add -A
- $ git commit -m "My first doc change as a trial run"
- $ git push -u origin <your-branch-name>
-```
-* You can see the changed Markdown file if you traverse the tree on the git repository [ https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git]( https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git).
-
-* A commit notification automatically goes out to the commits@mynewt.incubator.apache.org mailing list. The "upstream" manager pulls the notified changes, reviews it, and merges it to the master branch if all is well. Otherwise you get an email for further changes.
-
-### Sharing changes as a non-committer
-
-We suggest you follow the proposed non-committer workflow at Apache to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html).
-
-* Assuming you have made changes to the example file, you will first commit your changes.
-```no-highlight
- $ git add -A
- $ git commit -m "My first doc change as a trial run"
-```
-* Once you're ready to share your changes with the rest of the project team, you can use the git format-patch command to produce a patch file (or a nice set of patches in the future):
-```no-highlight
- $ git format-patch origin/trunk
-```
-* Email the patch file to dev@mynewt.incubator.apache.org. Later on you may attach multiple files in your email to the mailing list as part of an existing thread or a new one. Remember to summarize the issue you have tackled and your work if the commit message is not detailed enough.
-
- If there is a JIRA ticket associated with your work you should post your patch files to the ticket.
-
-
-### Conversion to HTML
-
-The conversion of the Markdown files to HTML for the website happens manually and statically using MkDocs. You cannot see automatic and immediate rendering in HTML upon making a change in the Markdown file. You can choose to stop here and proceed to changing other Markdown files in your branch.
-
-### Local preview of HTML files
-
-However, you have the option to download MkDocs and do a local conversion yourself to preview the pages using the built-in devserver that comes with MkDocs. But first you will have to install MkDocs for that. In order to install MkDocs you'll need Python installed on your system, as well as the Python package manager, pip. You can check if you have them already (usually you will).
-```no-highlight
- $ python --version
- Python 2.7.2
- $ pip --version
- pip 1.5.2
- $ pip install mkdocs
-```
-You will then run the built-in webserver from the root of the documentation directory using the command `mkdocs serve`. The root directory for documentation is `incubator-mynewt-site` or the directory with the `mkdocs.yml` file.
-```no-highlight
- $ ls
- docs images mkdocs.yml
- $ mkdocs serve
-```
-Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website! Remember that the Myself website itself will not be updated.
-
-For more information on MkDocs go to [http://www.mkdocs.org](http://www.mkdocs.org).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/newt_concepts.md
----------------------------------------------------------------------
diff --git a/docs/get_started/newt_concepts.md b/docs/get_started/newt_concepts.md
deleted file mode 100644
index 6ac28da..0000000
--- a/docs/get_started/newt_concepts.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Newt Concepts
-
-This page introduces the basic terms you will need to find your way around the Mynewt ecosystem.
-
-### Basic components in the ecosystem
-
-* NewtOS is an open-source RTOS (Real Time Operating System) that works on a variety of hardware. The goal is to develop a pre-emptive, multitasking OS that is highly modular, making it possible to mix and match components to enable desired features and capabilities on multiple hardware architectures. Examples of components being worked on are the Core RTOS, a flash file system, utility functions, a variety of board support packages, packages of microcontrollers etc.
-
-
-* Network protocol stacks such as Bluetooth Low Energy, and more
-
-
-* Newt Tool helps you mix the specific packages for the combination of hardware and low-level embedded architecture features of the user's choice and generate the corresponding run-time image based on the NewtOS. It provides the infrastructure to manage and build for different CPU architectures, memory units, board support packages etc., allowing a user to formulate the contents according to the low-level features needed by his or her project.
-
-
-### Terminology
-
-A Mynewt user starts with a project in mind that defines the application or utility that he or she wants to implement on an embedded device. Making an LED blink on an electronics prototyping board is a common starter project. Enabling a BLE (Bluetooth Low Energy) peripheral mode on a development board is a more complex project. Specifying a project requires naming it, at the very least, and then adding the desired properties or attributes. In order to actualize a project, it needs to be applied to a target which is essentially a combination of some specified hardware and the execution environment.
-
-In the mynewt lifecycle, a project grows in a nest. A nest may house multiple projects. The nest is, therefore, a repository where various component packages for one or more projects reside. Each package is an egg (naturally!). However, in the world of Mynewt an egg may consist of other eggs! For example, the starter project Blinky is an egg consisting of several constituent eggs that enable core features. The egg form is suitable for elemental units of code as it explicitly exposes characteristics such as dependencies, versions, capabilities, requirements etc., thus making assembling appropriate components for a project and building an image for it easy to follow, modular, and robust.
-
-A nest can be given any name. For example, you will see a nest named "tadpole" in Mynewt ([https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git](https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git)). It contains all the core libraries of the operating system for the native platform which currently supports compilation on Mac OS X. The core libraries are contained in the form of eggs where an egg is a basic unit of implementation of any aspect of the RTOS. The eggs are distributed in the following directory structure inside the nest:
-
-* libs: contains the two eggs `os` and `testutil`
-* hw: contains three eggs - (i) `hal` which has the abstraction layer (HAL) API definitions that all BSP and MCU implementations must support, (ii) `/mcu/native` which in an MCU implementation for the native platform (a simulator, in this case), and (iii) `bsp/native` which is a BSP implementation for the native platform
-* compiler: contains the `sim` egg which bundles the compiler specifications for the native platform.
-
-Let's explore this sample nest a bit further. The `libs/os` egg contains code for scheduler, process/thread/memory management, semaphores etc. It is the core RTOS which ports to all supported chip platforms.The `libs/testutil` egg contains code for testing packages on hardware or simulated environment. The `hw/hal` egg contains header files that provide abstraction for physical hardware components such as GPIO (general purpose input/output), network adapters, timers, and UARTs. This `hw/hal` egg is an MCU peripheral abstraction designed to make it easy to port to different MCUs (microcontrollers). The `hw/mcu/native` egg contains code for microcontroller operations on the native platform. The `hw/bsp/native` egg contains the board support package for the native platform. And finally, the sixth egg `sim` contains the compiler specifications such as path and flags. Currently the compilation is supported on Mac OS X.
-
-You can see another nest in the mynewt ecosystem called the "larva". It was spawned from the skeletal "tadpole" nest using the newt tool. Spawning is easy - ` $ newt create nest <your_nest_name> `. "larva" is the developer's test repository containing all sorts of eggs being written and incubated, including ones to enhance the core operating system which should eventually make their way into the "tadpole" nest. There is a `hatch_tadpole` script to update the "tadpole" nest when the core OS related eggs in "larva" are ready.
-
-There is a third nest named "newt" that contains all the eggs needed to support the build and release process of mynewt software. In the future, there will also be pre-built nests for certain common hardware devices to enable a user to quickly get started with a project.
-
-
-### A Mynewt contributor
-
-A contributor can choose to work on any area(s) of the Mynewt endeavor that appeals to him or her. Hence, you can work on one or more eggs or an entire nest. You can create your own nest (master) or create a branch in an existing nest. For now, Runtime contributors will review any new areas of support that you may wish to introduce e.g. a new board support package (BSP) or a new network protocol.
-
-A contributer role necessarily implies he or she is a Mynewt user (see below) of some or all of the products developed.
-
-### A Mynewt user
-
-An application developer is interested only in using software available in this ecosystem to build a top level build artifact. He or she may either:
-
-* Use a pre-built nest, or
-* Spawn a new nest using the newt tool for a target where a target is a custom combination of supported hardware components
-
-In either case, the user would use the newt tool to create and set the target in the chosen nest. The newt tool would then be used to build out the target profile which would determine which eggs to choose. Finally, the user would use the newt tool to generate a run-time image that can be run on the device.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/pics/bottomview.png
----------------------------------------------------------------------
diff --git a/docs/get_started/pics/bottomview.png b/docs/get_started/pics/bottomview.png
deleted file mode 100644
index fb7bf0a..0000000
Binary files a/docs/get_started/pics/bottomview.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/pics/topview.png
----------------------------------------------------------------------
diff --git a/docs/get_started/pics/topview.png b/docs/get_started/pics/topview.png
deleted file mode 100644
index e57995e..0000000
Binary files a/docs/get_started/pics/topview.png and /dev/null differ
[8/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/project1.md
----------------------------------------------------------------------
diff --git a/docs/get_started/project1.md b/docs/get_started/project1.md
deleted file mode 100644
index 89d3c9f..0000000
--- a/docs/get_started/project1.md
+++ /dev/null
@@ -1,1075 +0,0 @@
-## Blinky, the First Project
-
-### Objective
-
-We will show you how you can use eggs from a nest on Mynewt to make an LED on a target board blink. We will call it ** Project Blinky**. The goals of this tutorial are threefold:
-
-1. First, you will learn how to set up your environment to be ready to use Mynewt OS and newt tool.
-2. Second, we will walk you through a download of eggs for building and testing [on a simulated target](#building-test-code-on-simulator).
-3. Third, you will download eggs and use tools to create a runtime image for a board to make its LED blink. You have two choices here - you can [download an image to SRAM](#using-sram-to-make-led-blink) or you can [download it to flash](#using-flash-to-make-led-blink).
-
-** Time Requirement**: Allow yourself a couple of hours for this project if you are relatively new to embedded systems and playing with development boards. Those jumpers can be pesky!
-
-
-### What you need
-
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
-2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
-3. USB A-B type cable to connect the debugger to your personal computer
-4. Personal Computer
-
-The instructions assume the user is using a Bourne-compatible shell (e.g. bash or zsh) on your computer. The given instructions have been tested with the following releases of operating systems:
-
-* Mac: OS X Yosemite Version 10.10.5
-* Linux: Ubuntu 14.10 (Utopic Unicorn)
-* Windows: Windows 10
-
-
-### Access to the Apache repo
-
-* Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
-
-* The latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
-
-* The latest codebase for the Newt tool is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git
-
-The following shows how to clone a Mynewt OS code repository:
-
-* Non Committers
-```no-highlight
- $ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
-```
-* Committers
-```no-highlight
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
-```
-
-
-### Getting your Mac Ready
-
-#### Installing Homebrew to ease installs on OS X
-
-* Do you have Homebrew? If not, open a terminal on your Mac and paste the following at a Terminal prompt. It will ask you for your sudo password.
-
-```no-highlight
- $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
-```
- Alternatively, you can just extract (or `git clone`) Homebrew and install it to `/usr/local`.
-
-#### Installing Go
-
-* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
-
- * src contains Go source files organized into packages (one package per directory),
-
- * pkg contains package objects, and
-
- * bin contains executable commands.
-
- The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.
-
-```no-highlight
- $ cd $HOME
- $ mkdir -p dev/go
- $ cd dev/go
- $ export GOPATH=`pwd`
-```
- Note that you need to add export statements to ~/.bash_profile to export variables permanently. Don't forget to source the file for the change to go into effect.
-
-```no-highlight
- $ vi ~/.bash_profile
- $ source ~/.bash_profile
-```
-* Next you will use Homebrew to install Go. The summary message at the end of the installation should indicate that it is installed in the /usr/local/Cellar/go/ directory. You will use the Go command 'install' to compile and install packages (called eggs in the Mynewt world) and dependencies.
-
-```no-highlight
- $ brew install go
- ==>
- ...
- ...
- ==> *Summary*
- 🍺 /usr/local/Cellar/go/1.5.1: 5330 files, 273M
-```
- Alternatively, you can download the Go package directly from (https://golang.org/dl/) instead of brewing it. Install it in /usr/local directory.
-
-
-#### Creating local repository
-
-* You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.
-```no-highlight
- $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ ls
- bin pkg src
- $ ls src
- git-wip-us.apache.org github.com gopkg.in
-```
-
-* Check that newt.go is in place.
-```no-highlight
- $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-
-#### Building the Newt tool
-
-* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
-```no-highlight
- $ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ go install
- $ ls "$GOPATH"/bin/
- godep incubator-mynewt-newt.git newt
-```
-* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
-
- Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in `export newt="go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go"` in your .bash_profile and execute it by calling `$newt` at the prompt instead of `newt`. Here, you use `go run` which runs the compiled binary directly without producing an executable. Don't forget to reload the updated bash profile by typing `source ~/.bash_profile` at the prompt!
-```no-highlight
- $ newt version
- Newt version: 1.0
- $ newt -h
- Newt allows you to create your own embedded project based on the Mynewt
- operating system. Newt provides both build and package management in a
- single tool, which allows you to compose an embedded workspace, and set
- of projects, and then build the necessary artifacts from those projects.
- For more information on the Mynewt operating system, please visit
- https://www.github.com/mynewt/documentation.
-
- Please use the newt help command, and specify the name of the command
- you want help for, for help on how to use a specific command
-
- Usage:
- newt [flags]
- newt [command]
-
- Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-
- Available Commands:
- version Display the Newt version number.
- target Set and view target information
- egg Commands to list and inspect eggs on a nest
- nest Commands to manage nests & clutches (remote egg repositories)
- help Help about any command
-
- Flags:
- -h, --help=false: help for newt
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-
- Use "newt help [command]" for more information about a command.
-```
-* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
-
-#### Getting the debugger ready
-
-* Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. So, first install gcc. You will see the brew steps and a final summary confirming install.
-```no-highlight
- $ brew install gcc
- ...
- ...
- ==> Summary
- 🍺 /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M
-```
-
-* ARM maintains a pre-built GNU toolchain with a GCC source branch targeted at Embedded ARM Processors namely Cortex-R/Cortex-M processor families. Install the PX4 Toolchain and check the version installed. Make sure that the symbolic link installed by Homebrew points to the correct version of the debugger. If not, you can either change the symbolic link using the "ln -f -s" command or just go ahead and try with the version it points to!
-```no-highlight
- $ brew tap PX4/homebrew-px4
- $ brew update
- $ brew install gcc-arm-none-eabi-49
- $ arm-none-eabi-gcc --version
- arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]
- Copyright (C) 2014 Free Software Foundation, Inc.
- This is free software; see the source for copying conditions. There is NO
- warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- $ ls -al /usr/local/bin/arm-none-eabi-gdb
- lrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -> /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb
-```
- Note: If no version is specified, brew will install the latest version available. MynewtOS will eventually work with multiple versions available including the latest releases. However, at present we have tested only with this version and recommend it for getting started.
-
-* You have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. Use brew to install it. Brew adds a simlink /usr/local/bin/openocd to the openocd directory in the Cellar. For more on OpenOCD go to [http://openocd.org](http://openocd.org).
-```no-highlight
- $ brew install open-ocd
- $ which openocd
- /usr/local/bin/openocd
- $ ls -l $(which openocd)
- lrwxr-xr-x 1 <user> admin 36 Sep 17 16:22 /usr/local/bin/openocd -> ../Cellar/open-ocd/0.9.0/bin/openocd
-```
-* Proceed to the [Building test code on simulator](#building-test-code-on-simulator) section.
-
-
-### Getting your Ubuntu machine Ready
-
-
-#### Installing some prerequisites
-
-* Install git, libcurl, and the Go language if you do not have them already.
-```no-highlight
- $ sudo apt-get install git
- $ sudo apt-get install libcurl4-gnutls-dev
- $ sudo apt-get install golang
-```
-
-#### Creating local repository
-
-* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
-
- * src contains Go source files organized into packages (one package per directory),
-
- * pkg contains package objects, and
-
- * bin contains executable commands.
-
- The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.
-```no-highlight
- $ cd $HOME
- $ mkdir -p dev/go
- $ cd dev/go
- $ export GOPATH=$PWD
-```
- Note that you need to add export statements to ~/.bashrc (or equivalent) to export variables permanently.
-
-* You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.
-```no-highlight
- $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ ls
- bin pkg src
- $ ls src
- git-wip-us.apache.org github.com gopkg.in
-```
-
-* Check that newt is in place.
-```no-highlight
- $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-#### Building the newt tool
-
-
-* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
-```no-highlight
- $ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ go install
- $ ls "$GOPATH"/bin/
- godep incubator-mynewt-newt.git newt
-```
-* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
-
- Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in `export newt="go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go"` in your ~/.bashrc (or equivalent) and execute it by calling `$newt` at the prompt instead of `newt`. Here, you use `go run` which runs the compiled binary directly without producing an executable.
-
-```no-highlight
- $ newt version
- Newt version: 1.0
- $ newt -h
- Newt allows you to create your own embedded project based on the Mynewt
- operating system. Newt provides both build and package management in a
- single tool, which allows you to compose an embedded workspace, and set
- of projects, and then build the necessary artifacts from those projects.
- For more information on the Mynewt operating system, please visit
- https://www.github.com/mynewt/documentation.
-
- Please use the newt help command, and specify the name of the command
- you want help for, for help on how to use a specific command
-
- Usage:
- newt [flags]
- newt [command]
-
- Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-
- Available Commands:
- version Display the Newt version number.
- target Set and view target information
- egg Commands to list and inspect eggs on a nest
- nest Commands to manage nests & clutches (remote egg repositories)
- help Help about any command
-
- Flags:
- -h, --help=false: help for newt
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-
- Use "newt help [command]" for more information about a command.
-```
-* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
-
-#### Getting the debugger ready
-
-* Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. You can install these as follows:
-```no-highlight
- $ sudo apt-get install gcc-multilib libc6-i386
-```
-* For the LED project on the Olimex hardware, you have to install gcc for AM 4.9.3. This package can be installed with apt-get as documented below. The steps are explained in depth at [https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded](https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded).
-```no-highlight
- $ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
- $ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
- $ sudo apt-get update
- $ sudo apt-get install gcc-arm-none-eabi
-```
-* And finally, you have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0.
-
- If you are running Ubuntu 15.x, then you are in luck and you can simply run:
-```no-highlight
- $ sudo apt-get install openocd
-```
- Other versions of Ubuntu may not have the correct version of openocd available. In this case, you should download the openocd 0.8.0 package from [https://launchpad.net/ubuntu/vivid/+source/openocd](https://launchpad.net/ubuntu/vivid/+source/openocd). The direct link to the amd64 build is [http://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb](http://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb).
-
-* Proceed to the [Building test code on simulator](#building-test-code-on-simulator) section.
-
-### Getting your Windows machine ready for simulated target
-
-The `newt` tool is the build software used to build Mynewt OS images or executables for any embedded hardware device/board, including the one for the current tutorial (STM32-E407 development board from Olimex). You can run the `newt` tool natively on a computer running any of the three Operating System machines - OSX, Linux, or Windows.
-
-However, Mynewt OS images for a simulated target are built on the Windows machine by using Linux versions of the build software (newt)in a virtual machine on your Windows box. The Linux VM is set up by installing the Docker Toolbox. Your Windows machine will communicate with the Linux VM via transient ssh connections. You will then download a Docker image (`newtvm.exe`)that allows you to run the newt commands in the Linux Docker instance. The Docker image contains:
-
- * The newt command-line tool
- * Go
- * A multilib-capable native gcc / glibc
- * An arm-none-eabi gcc
- * Native gdb
-
- The sequence of events when using the Docker image is as follows:
-
- 1. A new docker environment is created in the Linux VM.
- 2. The specified command with the newtvm prefix (`newtvm newt` command) is sent to the docker environment via ssh.
- 3. The Linux command runs.
- 4. The output from the command is sent back to Windows via ssh.
- 5. The output is displayed in the Windows command prompt.
-
-
-#### Install Linux virtual machine
-
-* Download the Docker Toolbox for Windows (version 1.9.0c or later) from [https://www.docker.com/docker-toolbox](https://www.docker.com/docker-toolbox). The Docker toolbox creates a consistently reproducible and self-contained environment in Linux.
-
-* Run the Docker Toolbox installer. All the default settings are OK.
-
-* You may need to add "C:\Program Files\Git\usr\bin" to your PATH
-environment variable. To add to the PATH environment variable, right-click on the Start button in the bottom left corner. Choose System -> Advanced system settings -> Environment Variables. Click on the PATH variable under "System variables" and click Edit to check and add it if it is not already there.
-
-#### Install newtvm tool
-
-* From your base user (home) directory, pull or clone the latest code from the newt repository into the `newt` directory. It includes the executable `newtvm.exe` for the newtvm tool in the `newtvm` directory.
-```no-highlight
- C:\Users\admin> git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt newt
-```
- The newtvm tool is what allows you to run programs in the Linux docker
-instance.
-
-* Run the Docker Quickstart Terminal application inside the Docker folder under Programs. You can find it by clicking Start button -> All apps. By default, the Docker Toolbox installer creates a shortcut to this program on your desktop. Wait until you see an ASCII art whale displayed in the terminal window and the Docker prompt given.
-
-
-```no-highlight
- ## .
- ## ## ## ==
- ## ## ## ## ## ===
- /"""""""""""""""""\___/ ===
- ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
- \______ o __/
- \ \ __/
- \____\_______/
-
- docker is configured to use the default machine with IP 192.168.99.100
- For help getting started, check out the docs at https://docs.docker.com
-
- admin@dev1 MINGW64 ~ (master)
- $
-```
-
- The first time you run this, it may take several minutes to complete. You will need to run the Docker Quickstart Terminal once each time you
-restart your computer.
-
-* Open a command prompt (e.g., Windows-R, "cmd", enter). You execute the newt tool commands as though you were running newt in Linux, but you prefix each command with "newtvm". For example:
-```no-highlight
- C:\Users\admin\newt\newtvm> newtvm newt help
-```
-
- The newtvm tool will take a long time to run the first time you execute
-it. The delay is due to the fact that the tool must download the mynewt
-docker instance.
-
-* You are now ready to proceed to [building the image for the simulated target](#building-test-code-on-simulator).
-
-
-### Getting your Windows machine ready for hardware target
-
-When you want to produce images for actual hardware board on your Windows machine, go through the following setup procedure and then proceed to the [blinky project on the Olimex board](#Using-SRAM-to-make-LED-blink) with this method.
-
-#### Installing some prerequisites
-
-* You have to install the following if you do not have them already. The steps below indicate specific folders where each of these programs should be installed. You can choose different locations, but the remainder of this
-tutorial for a Windows machine assumes the specified folders.
-
- * win-builds-i686
- * win-builds-x86_64
- * MSYS
- * gcc for ARM
- * openocd
- * zadig
- * git
- * go
-
- - *win-builds (mingw64) 1.5 for i686*
-
- Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at: "C:\win-builds-i686".
-
- Be sure to click the i686 option (not x86_64). The defaults for all other options are OK. The installer will want to download a bunch of additional packages. They are not all necessary, but it is simplest to just accept the defaults.
-
- - *win-builds (mingw64) 1.5 for x86_64*
-
- Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at "C:\win-builds-x86_64"
-
- Run the installer a second time, but this time click the x86_64 option, NOT i686. The defaults for all other options are OK.
-
- - *MSYS*
-
- Start your download from [http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip](http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip)
-
- Unzip to "C:\msys"
-
- - *gcc for ARM, 4.9.3*
-
- Download the Windows installer from [https://launchpad.net/gcc-arm-embedded/+download](https://launchpad.net/gcc-arm-embedded/+download) and install at "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3".
-
- - OpenOCD 0.8.0
-
- Download OpenOCD 0.8.0 from [http://www.freddiechopin.info/en/download/category/4-openocd](http://www.freddiechopin.info/en/download/category/4-openocd). Unzip to "C:\openocd".
-
- - Zadig 2.1.2
-
- Download it from [http://zadig.akeo.ie](http://zadig.akeo.ie) and install it at "C:\zadig".
-
- - Git
-
- Click on [https://git-scm.com/download/win](https://git-scm.com/download/win) to start the download. Install at "C:\Program Files (x86)\Git". Specify the "Use Git from the Windows Command Prompt" option. The defaults for all other options are OK.
-
- - Go
-
- Download the release for Microsoft Windows from [https://golang.org/dl/](https://golang.org/dl/) and install it "C:\Go".
-
-
-#### Creating local repository
-
-* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
-
- * src contains Go source files organized into packages (one package per directory),
-
- * pkg contains package objects, and
-
- * bin contains executable commands.
-
- The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory and then proceed to create the directory for cloning the newt tool repository.
-```no-highlight
- $ cd c:\
- $ mkdir dev\go
- $ cd dev\go
-```
-* Set the following user environment variables using the steps outlined here.
-```no-highlight
- * GOPATH: C:\dev\go
- * PATH: C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin;%GOPATH%\bin;C:\win-builds-x86_64\bin;C:\win-builds-i686\bin;C:\msys\bin
-```
- Steps:
-
- 1. Right-click the start button
- 2. Click "Control panel"
- 3. Click "System and Security"
- 4. Click "System"
- 5. Click "Advanced system settings" in the left panel
- 6. Click the "Envoronment Variables..." button
- 7. There will be two sets of environment variables: user variables
- in the upper half of the screen, and system variables in the lower
- half. Configuring the user variables is recommended and tested
- (though system variables will work as well).
-
-
-* Next, install godep. Note that the following command produces no output.
-```no-highlight
- $ go get github.com/tools/godep
-```
-* Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the contents of the directory.
-```no-highlight
- $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ dir
- bin pkg src
- $ dir src
- git-wip-us.apache.org github.com gopkg.in
- $ dir
- newt
- $ cd newt
- $ dir
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-* Check that newt is in place.
-```no-highlight
- $ dir $GOPATH\src\git-wip-us.apache.org\repos\asf\incubator-mynewt-newt.git\newt
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-
-
-#### Building the newt tool
-
-* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
-```no-highlight
- $ go install
- $ ls "$GOPATH"/bin/
- godep incubator-mynewt-newt.git newt
-```
-* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
-
- Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to define the newt environment variable that allows you to execute the command via `%newt%`. Use `set newt=go run %GOPATH%\src\github.com\mynewt\newt\newt.go` or set it from the GUI. Here, you use `go run` which runs the compiled binary directly without producing an executable.
-```no-highlight
- $ newt version
- Newt version: 1.0
- $ newt -h
- Newt allows you to create your own embedded project based on the Mynewt
- operating system. Newt provides both build and package management in a
- single tool, which allows you to compose an embedded workspace, and set
- of projects, and then build the necessary artifacts from those projects.
- For more information on the Mynewt operating system, please visit
- https://www.github.com/mynewt/documentation.
-
- Please use the newt help command, and specify the name of the command
- you want help for, for help on how to use a specific command
-
- Usage:
- newt [flags]
- newt [command]
-
- Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-
- Available Commands:
- version Display the Newt version number.
- target Set and view target information
- egg Commands to list and inspect eggs on a nest
- nest Commands to manage nests & clutches (remote egg repositories)
- help Help about any command
-
- Flags:
- -h, --help=false: help for newt
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-
- Use "newt help [command]" for more information about a command.
-```
-* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
-
-#### Getting the debugger ready
-
-* Use Zadig to configure the USB driver for your Olimex debugger. If your debugger is already set up, you can skip this step.
-
- 1. Plug in your Olimex debugger.
- 2. Start Zadig.
- 3. Check the Options -> List All Devices checkbox.
- 4. Select "Olimex OpenOCD JTAG ARM-USB-TINY-H" in the dropdown menu.
- 5. Select the "WinUSB" driver.
- 6. Click the "Install Driver" button.
-
-* Proceed to the section on how to [make an LED blink](#using-sram-to-make-led-blink) section.
-
-
-### Building test code on simulator
-
-Note: On a Windows computer, the simulator can be run only in a Linux virtual environment. Make sure you have installed the Docker instance as outlined in [an earlier section](#getting-your-windows-machine-ready-for-simulated-target). Consequently, all `newt` commands must be prefaced with `newtvm`.
-
-1. First, you have to create a repository for the project i.e. build your first nest! Go to ~/dev (or your base user directory on a Windows machine)and clone the larva repository from the apache git repository into a local directory named `larva`.
-
- Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.
-
-```no-highlight
- $ cd ~/dev
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
- $ ls
- go larva
- $ cd larva
- $ ls
- LICENSE clutch.yml hw nest.yml project
- README.md compiler libs net scripts
-```
- On Windows, open a command prompt (e.g., Windows-R, "cmd", enter) and work from your home directory:
-```no-highlight
- C:\Users\admin> git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
- C:\Users\admin> cd larva
- C:\Users\admin\larva> dir
- Volume in drive C is Windows
- Volume Serial Number is 4CBB-0920
-
- Directory of C:\Users\admin\larva
-
- <DIR> .
- <DIR> ..
- 76 .gitignore
- 0 .gitmodules
- .nest
- 6,133 clutch.yml
- <DIR> compiler
- <DIR> hw
- <DIR> libs
- 11,560 LICENSE
- 20 nest.yml
- <DIR> net
- <DIR> project
- 2,263 README.md
- <DIR> scripts
- 6 File(s) 20,052 bytes
- 9 Dir(s) 90,723,442,688 bytes free
-```
-
-2\. You will now create a new target using the newt tool. You can either use the compiled binary `newt` or run the newt.go program using `$newt` (assuming you have stored the command in a variable in your .bash_profile or .bashrc). When you do a `newt target show` or `$newt target show` it should list all the projects you have created so far.
-```no-highlight
- $ newt target create sim_test
- Creating target sim_test
- Target sim_test sucessfully created!
- $ newt target show
- sim_test
- name: sim_test
- arch: sim
-```
- Remember, on a Windows machine you will have to preface `newt` with `newtvm`!
-```no-highlight
- C:\Users\admin\larva>newtvm newt target create sim_test
-```
-3\. Now continue to populate and build out the sim project.
-```no-highlight
- $ newt target set sim_test project=test
- Target sim_test successfully set project to test
- $ newt target set sim_test compiler_def=debug
- Target sim_test successfully set compiler_def to debug
- $ newt target set sim_test bsp=hw/bsp/native
- Target sim_test successfully set bsp to hw/bsp/native
- $ newt target set sim_test compiler=sim
- Target sim_test successfully set compiler to sim
- $ newt target show sim_test
- sim_test
- arch: sim
- project: test
- compiler_def: debug
- bsp: hw/bsp/native
- compiler: sim
- name: sim_test
-```
- Again remember to preface `newt` with `newtvm`on a Windows machine as shown below. Continue to fill out all the project attributes.
-```no-highlight
- C:\Users\admin\larva>newtvm newt target set sim_test project=test
- Target sim_test successfully set project to test
-```
-
-4\. Configure newt to use the gnu build tools native to OS X or linux. In order for sim to work properly, it needs to be using 32-bit gcc (gcc-5). Replace
-~/dev/larva/compiler/sim/compiler.yml with the compiler/sim/osx-compiler.yml or linux-compiler.yml file, depending on the system. On a Windows machine follow the instruction for the Linux machine as you are running commands in a Linux VM.
-
- For a Mac OS X environment:
-```no-highlight
- $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml
-```
- For a Linux machine:
-```no-highlight
- $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml
-```
-
-5\. Next, create (hatch!) the eggs for this project using the newt tool - basically, build the packages for it. You can specify the VERBOSE option if you want to see the gory details. Always remember to preface `newt` with `newtvm`on a Windows machine.
-```no-highlight
- $ newt target build sim_test
- Successfully run!
-```
- You can specify the VERBOSE option if you want to see the gory details.
-```no-highlight
- $newt -l VERBOSE target build sim_test
- 2015/09/29 09:46:12 [INFO] Building project test
- 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...
- 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...
- 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..
- ...
- Successfully run!
-```
-6\. Try running the test suite executable inside this project and enjoy your first successful hatch.
-```no-highlight
- $ newt ./project/test/bin/sim_test/test.elf
- [pass] os_mempool_test_suite/os_mempool_test_case
- [pass] os_mutex_test_suite/os_mutex_test_basic
- [pass] os_mutex_test_suite/os_mutex_test_case_1
- [pass] os_mutex_test_suite/os_mutex_test_case_2
- [pass] os_sem_test_suite/os_sem_test_basic
- [pass] os_sem_test_suite/os_sem_test_case_1
- [pass] os_sem_test_suite/os_sem_test_case_2
- [pass] os_sem_test_suite/os_sem_test_case_3
- [pass] os_sem_test_suite/os_sem_test_case_4
- [pass] os_mbuf_test_suite/os_mbuf_test_case_1
- [pass] os_mbuf_test_suite/os_mbuf_test_case_2
- [pass] os_mbuf_test_suite/os_mbuf_test_case_3
- [pass] gen_1_1/ffs_test_unlink
- [pass] gen_1_1/ffs_test_rename
- [pass] gen_1_1/ffs_test_truncate
- [pass] gen_1_1/ffs_test_append
- [pass] gen_1_1/ffs_test_read
- [pass] gen_1_1/ffs_test_overwrite_one
- [pass] gen_1_1/ffs_test_overwrite_two
- [pass] gen_1_1/ffs_test_overwrite_three
- ...
- ...
- [pass] boot_test_main/boot_test_vb_ns_11
-```
-
-### Using SRAM to make LED blink
-
-You are here because you want to build an image to be run from internal SRAM on the Olimex board.
-
-#### Preparing the Software
-
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory (or C:\%GOPATH%\bin on Windows machine).
-
- Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows (e.g. `cd dev\go` instead of `cd dev/go`). The newt tool commands do not change.
-
-
-* If you have cloned the larva repository for the simulator test in the previous section you can skip this step. Otherwise, you have to create a repository for the project i.e. build your first nest! Go to ~/dev and clone the larva repository from the apache git repository into a local directory named `larva`.
-
- Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.
-
-```no-highlight
- $ cd ~/dev
- $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
- $ ls
- go larva
- $ cd larva
- $ ls
- LICENSE clutch.yml hw nest.yml project
- README.md compiler libs net scripts
-```
-
-* You first have to create a repository for the project. Go to the ~dev/larva directory and build out a second project inside larva. The project name is "blinky", in keeping with the objective. Starting with the target name, you have to specify the different aspects of the project to pull the appropriate eggs and build the right package for the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.
-
- Remember to prefix each command with "newtvm" if you are executing the newt command in a Linux virtual machine on your Windows box!
-
-```no-highlight
- $ newt target create blinky
- Creating target blinky
- Target blinky sucessfully created!
- $ newt target set blinky arch=cortex_m4
- Target blinky successfully set arch to arm
- $ newt target set blinky compiler=arm-none-eabi-m4
- Target blinky successfully set compiler to arm-none-eabi-m4
- $ newt target set blinky project=blinky
- Target blinky successfully set project to blinky
- $ newt target set blinky compiler_def=debug
- Target blinky successfully set compiler_def to debug
- $ newt target set blinky bsp=hw/bsp/olimex_stm32-e407_devboard
- Target blinky successfully set bsp to hw/bsp/olimex_stm32-e407_devboard
- $ newt target show blinky
- blinky
- compiler: arm-none-eabi-m4
- project: blinky
- compiler_def: debug
- bsp: hw/bsp/olimex_stm32-e407_devboard
- name: blinky
- arch: cortex_m4
-```
-
-* Now you have to build the image. The linker script within the `hw/bsp/olimex_stm32-e407_devboard` egg builds an image for flash memory by default. Since you want an image for the SRAM, you need to switch that script with `run_from_sram.ld` in order to get the egg to produce an image for SRAM. <font color="red"> We are working on making it easier to specify where the executable will be run from for a particular project and automatically choose the correct linker scripts and generate the appropriate image. It will be specified as a project identity e.g. bootloader, RAM, flash (default) and the target will build accordingly. </font>.
-
- Once the target is built, you can find the executable "blinky.elf" in the project directory at ~/dev/larva/project/blinky/bin/blinky. It's a good idea to take a little time to understand the directory structure.
-```no-highlight
- $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
- $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
- $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld
- $ cd ~/dev/larva/project/blinky/bin/blinky
- $ newt target build blinky
- Building target blinky (project = blinky)
- Compiling case.c
- Compiling suite.c
- ...
- Successfully run!
- $ ls
- LICENSE clutch.yml hw nest.yml project
- README.md compiler libs net scripts
- $ cd project
- $ ls
- bin2img bletest blinky boot ffs2native test
- $ cd blinky
- $ ls
- bin blinky.yml egg.yml src
- $ cd bin
- $ ls
- blinky
- $ cd blinky
- $ ls
- blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map
-```
-
-* Check that you have all the scripts needed to get OpenOCD up and talking with the project's specific hardware. Depending on your system (Ubuntu, Windows) you may already have the scripts in your `/usr/share/openocd/scripts/ ` directory as they may have been part of the openocd download. If yes, you are all set and can proceed to preparing the hardware.
-
- Otherwise check the `~/dev/larva/hw/bsp/olimex_stm32-e407_devboard` directory for a file named `f407.cfg`. That is the config we will use to talk to this specific hardware using OpenOCD. You are all set if you see it.
-```no-highlight
- $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
- bin olimex_stm32-e407_devboard_debug.sh
- boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard_download.sh
- egg.yml run_from_flash.ld
- f407.cfg run_from_loader.ld
- include run_from_sram.ld
- olimex_stm32-e407_devboard.ld src
-```
-
-#### Preparing the hardware to boot from embedded SRAM
-
-1. Locate the boot jumpers on the board.
-
-
-
-2. B1_1/B1_0 and B0_1/B0_0 are PTH jumpers which can be moved relatively easy. Note that the markings on the board may not always be accurate. Always refer to the manual for the correct positioning of jumpers in case of doubt. The two jumpers must always be moved together – they are responsible for the boot mode if bootloader is present. The board can search for bootloader on three places – User Flash Memory, System Memory or the Embedded SRAM. We will configure it to boot from SRAM by jumpering B0_1 and B1_1.
-
-3. Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
-
-4. The red PWR LED should be lit.
-
-5. Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
-
-
-
-#### Let's Go!
-
-* Make sure you are in the blinky project directory with the blinky.elf executable. Run the debug command in the newt tool. You should see some status messages are shown below. There is an inbuilt `-c "reset halt"` flag that tells it to halt after opening the session.
-```no-highlight
- $ cd dev/larva/project/blinky/bin/blinky
- $ newt target debug blinky
- Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky
- Debugging /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
- Type "show configuration" for configuration details.
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>.
- Find the GDB manual and other documentation resources online at:
- <http://www.gnu.org/software/gdb/documentation/>.
- For help, type "help".
- Type "apropos word" to search for commands related to "word"...
- Reading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/ blinky/blinky.elf...done.
- Open On-Chip Debugger 0.8.0 (2015-09-22-18:21)
- Licensed under GNU GPL v2
- For bug reports, read
- http://openocd.sourceforge.net/doc/doxygen/bugs.html
- Info : only one transport option; autoselect 'jtag'
- adapter speed: 1000 kHz
- adapter_nsrst_delay: 100
- jtag_ntrst_delay: 100
- Warn : target name is deprecated use: 'cortex_m'
- DEPRECATED! use 'cortex_m' not 'cortex_m3'
- cortex_m reset_config sysresetreq
- Info : clock speed 1000 kHz
- Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
- Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
- Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
- Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
- Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
- target state: halted
- target halted due to debug-request, current mode: Thread
- xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000
- Info : accepting 'gdb' connection from 3333
- Info : device id = 0x10036413
- Info : flash size = 1024kbytes
- Reset_Handler () at startup_STM32F40x.s:199
- 199 ldr r1, =__etext
-```
-
- Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdp tool and load the image on it.
-```no-highlight
- (gdb) set $msp=0x10010000
-```
- Now load the image and type "c" or "continue" from the GNU debugger.
-
-```no-highlight
- (gdb) load ~/dev/larva/project/blinky/bin/blinky/blinky.elf
- Loading section .text, size 0x4294 lma 0x20000000
- Loading section .ARM.extab, size 0x24 lma 0x20004294
- Loading section .ARM.exidx, size 0xd8 lma 0x200042b8
- Loading section .data, size 0x874 lma 0x20004390
- Start address 0x20000250, load size 19460
- Transfer rate: 81 KB/sec, 2432 bytes/write.
- (gdb) c
- Continuing.
-```
-
-* Voilà! The board's LED should be blinking at 1 Hz.
-
-### Using flash to make LED blink
-
-You are here because you want to build an image to be run from flash memory on the Olimex board.
-
-* Configure the board to boot from flash by moving the two jumpers together to B0_0 and B1_0. Refer to the pictures of the board under the section titled ["Preparing the hardware to boot from embedded SRAM"](#preparing-the-hardware-to-boot-from-embedded-sram).
-
- You will have to reset the board once the image is uploaded to it.
-
-* If you skipped the first option for the project [(downloading an image to SRAM)](#using-sram-to-make-led-blink), then skip this step. Otherwise, continue with this step.
-
- By default, the linker script (`olimex_stm32-e407_devboard.ld`) is configured to run from bootloader and flash. However, if you first ran the image from SRAM you had changed `olimex_stm32-e407_devboard.ld` to match `run_from_sram.ld`. You will therefore return to defaults with `olimex_stm32-e407_devboard.ld` linker script matching the contents of 'run_from_loader.ld'. Return to the project directory.
-```no-highlight
- $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
- $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
- $ diff olimex_stm32-e407_devboard.ld run_from_loader.ld
- $ cp run_from_loader.ld olimex_stm32-e407_devboard.ld
- $ cd ~/dev/larva/project/blinky/bin/blinky
-```
-
-* In order to run the image from flash, you need to build the bootloader as well. The bootloader does the initial bring up of the Olimex board and then transfers control to the image stored at a location in flash known to it. The bootloader in turn requires the bin2image tool to check the image header for version information, CRC checks etc. So, we will need to build these two additional targets (bootloader and bin2img).
-
- Let's first create bin2img:
-```no-highlight
- $ newt target create bin2img
- Creating target bin2img
- Target bin2img successfully created!
- $ newt target set bin2img arch=sim
- Target bin2img successfully set arch to sim
- $ newt target set bin2img compiler=sim
- Target bin2img successfully set compiler to sim
- $ newt target set bin2img project=bin2img
- Target bin2img successfully set project to bin2img
- $ newt target set bin2img compiler_def=debug
- Target bin2img successfully set compiler_def to debug
- $ newt target set bin2img bsp=hw/bsp/native
- Target bin2img successfully set bsp to hw/bsp/native
- $ newt target show bin2img
- bin2img
- arch: sim
- compiler: sim
- project: bin2img
- compiler_def: debug
- bsp: hw/bsp/native
- name: bin2img
-```
- And then let's create boot_olimex:
-```no-highlight
- $ newt target create boot_olimex
- Creating target boot_olimex
- Target boot_olimex successfully created!
- $ newt target set boot_olimex arch=cortex_m4
- Target boot_olimex successfully set arch to cortex_m4
- $ newt target set boot_olimex compiler=arm-none-eabi-m4
- Target boot_olimex successfully set compiler to arm-none-eabi-m4
- $ newt target set boot_olimex project=boot
- Target boot_olimex successfully set project to boot
- $ newt target set boot_olimex compiler_def=optimized
- Target boot_olimex successfully set compiler_def to optimized
- $ newt target set boot_olimex bsp=hw/bsp/olimex_stm32-e407_devboard
- Target boot_olimex successfully set bsp to hw/bsp/olimex_stm32-e407_devboard
- $ newt target show boot_olimex
- boot_olimex
- project: boot
- compiler_def: optimized
- bsp: hw/bsp/olimex_stm32-e407_devboard
- name: boot_olimex
- arch: cortex_m4
- compiler: arm-none-eabi-m4
-```
-* Let's build all the three targets now.
-```no-highlight
- $ newt target build bin2img
- Building target bin2img (project = bin2img)
- Building project bin2img
- Successfully run!
- $ newt target build boot_olimex
- Building target boot_olimex (project = boot)
- Building project boot
- Successfully run!
- $ newt target build blinky
- Building target blinky (project = blinky)
- Building project blinky
- Successfully run!
-```
-
-* Go to the project directory and download the bootloader and the image to flash ... in a flash!
-```no-highlight
- $ cd ~/dev/larva/project/blinky/bin/blinky
- $ newt target download boot_olimex
- Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh
- $ newt target download blinky
- Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh
-```
-
-* The LED should be blinking!
-
-* But wait...let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor. The debug connection to the JTAG port is now severed. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
-
- The LED light will start blinking again. Success!
-
- Note #1: If you want to download the image to flash and a gdb session opened up, use `newt target debug blinky` instead of `newt target download blinky`.
-```no-highlight
- $ newt target debug blinky
- Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky
- Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
- Type "show configuration" for configuration details.
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>.
- Find the GDB manual and other documentation resources online at:
- <http://www.gnu.org/software/gdb/documentation/>.
- For help, type "help".
- Type "apropos word" to search for commands related to "word"...
- Reading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf...done.
- Open On-Chip Debugger 0.8.0 (2015-09-22-18:21)
- Licensed under GNU GPL v2
- For bug reports, read
- http://openocd.sourceforge.net/doc/doxygen/bugs.html
- Info : only one transport option; autoselect 'jtag'
- adapter speed: 1000 kHz
- adapter_nsrst_delay: 100
- jtag_ntrst_delay: 100
- Warn : target name is deprecated use: 'cortex_m'
- DEPRECATED! use 'cortex_m' not 'cortex_m3'
- cortex_m reset_config sysresetreq
- Info : clock speed 1000 kHz
- Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
- Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
- Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
- Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
- Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
- target state: halted
- target halted due to debug-request, current mode: Thread
- xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
- Info : accepting 'gdb' connection from 3333
- Info : device id = 0x10036413
- Info : flash size = 1024kbytes
- Reset_Handler () at startup_STM32F40x.s:199
- 199 ldr r1, =__etext
- (gdb)
-```
-
- Note #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. `flash erase_sector 0 0 x` tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma' you should therefore see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.
-```no-highlight
- (gdb) monitor flash erase_sector 0 0 4
- erased sectors 0 through 4 on flash bank 0 in 2.296712s
- (gdb) monitor mdw 0x08000000 16
- 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (gdb) monitor flash info 0
-```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/get_started/try_markdown.md
----------------------------------------------------------------------
diff --git a/docs/get_started/try_markdown.md b/docs/get_started/try_markdown.md
deleted file mode 100644
index e35707c..0000000
--- a/docs/get_started/try_markdown.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Try Markdown
-
-### Heading3
-
-#### Heading4
-
-- - -
-
-##### List
-
-* Start with one # for the largest heading (Heading1). The next smaller heading (Heading2) starts with ##. You can go all the way up to Heading 6 (######).
-
-* Heading4 (####) and Heading5 (#####) has been styled to show up underlined. Yes, it can be changed. If you are curious, you can look at the extra.css file in your repo branch.
-
-* It's **very** easy to do **bold** and *italics*.
-
-* See how this list has been made using *
-
-* Click on "Help" in Mou and then on "Markdown Syntax Reference".
-
-* <font color="red"> Substitute a sentence of your own here </font>
-
-* <font color="red"> Guinea Pig!!! </font>
-
----
-
-> <font color="red"> Note! </font>
->> You will not be able to see the change immediately by refreshing your browser right after editign the Markdown file. You can only push the change to the Apache repository. So continue with the steps in [how_to_edit_docs.md](how_to_edit_docs.md).
->>
->> You can see the change on the website if/when a doc builder on the project team merges your changes to the master branch and generates the pages for the website.
->>
->> You do have the option to download MkDocs and preview the change by hosting the pages locally using its built-in web server. The steps are described in [how_to_edit_docs.md](how_to_edit_docs.md).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/baselibc.md
----------------------------------------------------------------------
diff --git a/docs/modules/baselibc.md b/docs/modules/baselibc.md
deleted file mode 100644
index 38cf2a3..0000000
--- a/docs/modules/baselibc.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# Baselibc
-
-baselibc is a very simple libc for embedded systems geared primarily for 32-bit microcontrollers in the 10-100kB memory range. The library of basic system calls and facilities compiles to less than 5kB total on Cortex-M3, and much less if some functions aren't used.
-
-The code is based on klibc and tinyprintf modules, and licensed under the BSD license.
-
-## Description
-
-Mynewt Os comes bundled with libc (the standard C library). However, you may choose to replace libc functions with baselibc ones for a reduced image size.
-
-## How to switch to baselibc
-
-In order to switch from using libc to using baselibc you have to add the baselibc egg as dependency in the project egg. Specifying this dependency ensures that the linker first looks for the functions in baselibc before falling back to libc while creating the executable. For example, project `boot` uses baselibc. Its project description file `boot.yml` looks like the following:
-
-```no-highlight
- project.name: boot
- project.identities: bootloader
- project.eggs:
- - libs/os
- - libs/bootutil
- - libs/nffs
- - libs/console/stub
- - libs/util
- - libs/baselibc
- ```
-
-## List of Functions
-
-The functions available in this OS feature are listed below. Documentation is available in the form of on-line manual pages or at [https://www.freebsd.org/cgi/man.cgi](#https://www.freebsd.org/cgi/man.cgi). `mynewt.c` adds two new functions listed in the Function reference section.
-
-* asprintf.c
-* atoi.c
-* atol.c
-* atoll.c
-* bsearch.c
-* bzero.c
-* calloc.c
-* fgets.c
-* inline.c
-* jrand48.c
-* lrand48.c
-* malloc.c
-* malloc.h
-* memccpy.c
-* memchr.c
-* memcmp.c
-* memcpy.c
-* memfile.c
-* memmem.c
-* memmove.c
-* memrchr.c
-* memset.c
-* memswap.c
-* mrand48.c
-* mynewt.c
-* nrand48.c
-* qsort.c
-* realloc.c
-* sprintf.c
-* srand48.c
-* sscanf.c
-* strcasecmp.c
-* strcat.c
-* strchr.c
-* strcmp.c
-* strcpy.c
-* strcspn.c
-* strdup.c
-* strlcat.c
-* strlcpy.c
-* strlen.c
-* strncasecmp.c
-* strncat.c
-* strncmp.c
-* strncpy.c
-* strndup.c
-* strnlen.c
-* strntoimax.c
-* strntoumax.c
-* strpbrk.c
-* strrchr.c
-* strsep.c
-* strspn.c
-* strstr.c
-* strtoimax.c
-* strtok.c
-* strtok_r.c
-* strtol.c
-* strtoll.c
-* strtoul.c
-* strtoull.c
-* strtoumax.c
-* templates
-* test
-* tinyprintf.c
-* vasprintf.c
-* vprintf.c
-* vsprintf.c
-* vsscanf.c
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> stdin_read </font>
-
-```no-highlight
- static size_t
- stdin_read(FILE *fp, char *bp, size_t n)
-```
-
-Read from a file.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fp | pointer to the input file |
-| bp | pointer to the string to be read |
-| n | size of buffer (number of characters) to be read |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-N/A
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> stdout_write </font>
-
-```no-highlight
- static size_t
- stdout_write(FILE *fp, const char *bp, size_t n)
-```
-
-Write to a file or console.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fp | pointer to the output file |
-| bp | pointer to the string to be written |
-| n | size of buffer (number of characters) to be output |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-N/A
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_build_status.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_build_status.md b/docs/modules/bootloader/boot_build_status.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_build_status_one.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_build_status_one.md b/docs/modules/bootloader/boot_build_status_one.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_clear_status.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_clear_status.md b/docs/modules/bootloader/boot_clear_status.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_copy_area.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_copy_area.md b/docs/modules/bootloader/boot_copy_area.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_copy_image.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_copy_image.md b/docs/modules/bootloader/boot_copy_image.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_erase_area.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_erase_area.md b/docs/modules/bootloader/boot_erase_area.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_fill_slot.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_fill_slot.md b/docs/modules/bootloader/boot_fill_slot.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_find_image_area_idx.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_find_image_area_idx.md b/docs/modules/bootloader/boot_find_image_area_idx.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_find_image_part.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_find_image_part.md b/docs/modules/bootloader/boot_find_image_part.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_find_image_slot.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_find_image_slot.md b/docs/modules/bootloader/boot_find_image_slot.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_go.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_go.md b/docs/modules/bootloader/boot_go.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_init_flash.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_init_flash.md b/docs/modules/bootloader/boot_init_flash.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_move_area.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_move_area.md b/docs/modules/bootloader/boot_move_area.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_read_image_header.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_read_image_header.md b/docs/modules/bootloader/boot_read_image_header.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_read_image_headers.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_read_image_headers.md b/docs/modules/bootloader/boot_read_image_headers.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_read_status.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_read_status.md b/docs/modules/bootloader/boot_read_status.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_select_image_slot.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_select_image_slot.md b/docs/modules/bootloader/boot_select_image_slot.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_slot_addr.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_slot_addr.md b/docs/modules/bootloader/boot_slot_addr.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_slot_to_area_idx.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_slot_to_area_idx.md b/docs/modules/bootloader/boot_slot_to_area_idx.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_swap_areas.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_swap_areas.md b/docs/modules/bootloader/boot_swap_areas.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_vect_delete_main.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_vect_delete_main.md b/docs/modules/bootloader/boot_vect_delete_main.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_vect_delete_test.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_vect_delete_test.md b/docs/modules/bootloader/boot_vect_delete_test.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_vect_read_main.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_vect_read_main.md b/docs/modules/bootloader/boot_vect_read_main.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_vect_read_one.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_vect_read_one.md b/docs/modules/bootloader/boot_vect_read_one.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_vect_read_test.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_vect_read_test.md b/docs/modules/bootloader/boot_vect_read_test.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/boot_write_status.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/boot_write_status.md b/docs/modules/bootloader/boot_write_status.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/bootloader/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/modules/bootloader/bootloader.md b/docs/modules/bootloader/bootloader.md
deleted file mode 100644
index fd4bc8e..0000000
--- a/docs/modules/bootloader/bootloader.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Bootloader
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-
-The functions available in bootloader are:
-
-* [boot_build_status](boot_build_status.md)
-* [boot_build_status_one](boot_build_status_one.md)
-* [boot_clear_status](boot_clear_status.md)
-* [boot_copy_area](boot_copy_area.md)
-* [boot_copy_image](boot_copy_image.md)
-* [boot_erase_area](boot_erase_area.md)
-* [boot_fill_slot](boot_fill_slot.md)
-* [boot_find_image_area_idx](boot_find_image_area_idx.md)
-* [boot_find_image_part](boot_find_image_part.md)
-* [boot_find_image_slot](boot_find_image_slot.md)
-* [boot_go](boot_go.md)
-* [boot_init_flash](boot_init_flash.md)
-* [boot_move_area](boot_move_area.md)
-* [boot_read_image_header](boot_read_image_header.md)
-* [boot_read_image_headers](boot_read_image_headers.md)
-* [boot_read_status](boot_read_status.md)
-* [boot_select_image_slot](boot_select_image_slot.md)
-* [boot_slot_addr](boot_slot_addr.md)
-* [boot_slot_to_area_idx](boot_slot_to_area_idx.md)
-* [boot_swap_areas](boot_swap_areas.md)
-* [boot_vect_delete_main](boot_vect_delete_main.md)
-* [boot_vect_delete_test](boot_vect_delete_test.md)
-* [boot_vect_read_main](boot_vect_read_main.md)
-* [boot_vect_read_one](boot_vect_read_one.md)
-* [boot_vect_read_test](boot_vect_read_test.md)
-* [boot_write_status](boot_write_status.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console.md b/docs/modules/console/console.md
deleted file mode 100644
index 60c2b88..0000000
--- a/docs/modules/console/console.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Console
-
-
-The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS.
-
-Support is currently available for console access via the serial port on the hardware board.
-
-
-## Description
-
-In the Mynewt OS, the console library comes in two versions:
-
-* full - containing the full implementation
-* stub - containing stubs for the API
-
-Both of these have `egg.yml` file which states that they provide the `console` API. If an egg uses this API, it should list `console` as a requirement.
-For example, the shell egg is defined by the following egg.yml file:
-```no-highlight
- egg.name: libs/shell
- egg.vers: 0.1
- egg.deps:
- - libs/os
- - libs/util
- egg.reqs:
- - console
- egg.identities:
- - SHELL
-```
-The project .yml file decides which version of the console egg should be included.
-If project requires the full console capability it lists dependency `libs/console/full` in its egg.yml file.
-On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` egg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead and the egg.yml file for the project boot egg looks like the following:
-```no-highlight
- project.name: boot
- project.identities: bootloader
- project.eggs:
- - libs/os
- - libs/bootutil
- - libs/nffs
- - libs/console/stub
- - libs/util
-```
-
-Console has 2 modes for transmit; blocking and non-blocking mode. Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.
-Blocking mode is used when we don't want TX completion interrupts. This is used when system crashes, and we still want to output info related to that crash.
-
-## Data structures
-
-
-Console interaction is intrinsically composed of two unidirectional systems. The console implementation uses two ring buffers containing input (receive) and output (transmit) characters, respectively. Read and write operations on the console_ring structure are managed by labeling the read location indicator the `cr_tail` and the write location indicator the `cr_head`. The console ring length is variable and is specified as the `cr_size` member of the data structure. `cr_buf` is the pointer to the actual array of data contained.
-
-
-```no-highlight
-struct console_ring {
- 32 uint8_t cr_head;
- 33 uint8_t cr_tail;
- 34 uint8_t cr_size;
- 35 uint8_t _pad;
- 36 uint8_t *cr_buf;
- 37 }
-```
-
-
-```no-highlight
-struct console_tty {
- 40 struct console_ring ct_tx;
- 41 uint8_t ct_tx_buf[CONSOLE_TX_BUF_SZ]; /* must be after console_ring */
- 42 struct console_ring ct_rx;
- 43 uint8_t ct_rx_buf[CONSOLE_RX_BUF_SZ]; /* must be after console_ring */
- 44 console_rx_cb ct_rx_cb; /* callback that input is ready */
- 45 console_write_char ct_write_char;
- 46 } console_tty
-```
-
-## List of Functions
-
-The functions available in console are:
-
-* [console_add_char](console_add_char.md)
-* [console_blocking_mode](console_blocking_mode.md)
-* [console_blocking_tx](console_blocking_tx.md)
-* [console_init](console_init.md)
-* [console_printf](console_printf.md)
-* [console_pull_char](console_pull_char.md)
-* [console_pull_char_head](console_pull_char_head.md)
-* [console_queue_char](console_queue_char.md)
-* [console_read](console_read.md)
-* [console_rx_char](console_rx_char.md)
-* [console_tx_char](console_tx_char.md)
-* [console_write](console_write.md)
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_add_char.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_add_char.md b/docs/modules/console/console_add_char.md
deleted file mode 100644
index 739722d..0000000
--- a/docs/modules/console/console_add_char.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_add_char</font>
-
-```no-highlight
- static void
- console_add_char(struct console_ring *cr, char ch)
-```
-
-Adds a character to the console ring buffer. When you store an item in the buffer you store it at the head location, and the head advances to the next location.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *cr | Pointer to a console ring data structure whose `cr_head` variable is to be set to the second argument in this function call|
-| ch | Character to be inserted to the ring |
-
-#### Returned values
-
-None
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Add a new line character to the output (transmit) buffer.
-
-```no-highlight
-void
-task()
-{
- struct console_ring *tx = &ct->ct_tx;
-
- console_add_char(tx, '\n');
-}
-```
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_blocking_mode.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_blocking_mode.md b/docs/modules/console/console_blocking_mode.md
deleted file mode 100644
index 7023547..0000000
--- a/docs/modules/console/console_blocking_mode.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_blocking_mode </font>
-
-```no-highlight
- void
- console_blocking_mode(void)
-```
- Calls the console_blocking_tx function to flush the buffered console output (transmit) queue. The function OS_ENTER_CRITICAL() is called to disable interrupts and OS_EXIT_CRITICAL() is called to enable interrupts back again once the buffer is flushed.
-
-#### Arguments
-
-| Arguments | Description |
-|-------------------------|
-| none | none |
-
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Here is an example of calling `console_blocking_mode` and printing crash information from an assert to help debug.
-
-```no-highlight
-void
-_assert_func(const char *file, int line, const char *func, const char *e)
-{
- int sr;
-
- OS_ENTER_CRITICAL(sr);
- (void)sr;
- os_die_line = line;
- os_die_module = file;
- console_blocking_mode();
- console_printf("Assert %s; failed in %s:%d\n", e ? e : "", file, line);
- system_reset();
-}
-```
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_blocking_tx.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_blocking_tx.md b/docs/modules/console/console_blocking_tx.md
deleted file mode 100644
index ee18b55..0000000
--- a/docs/modules/console/console_blocking_tx.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_blocking_tx </font>
-
-```no-highlight
- static void
- console_blocking_tx(char ch)
-```
-
- Calls the hal function hal_uart_blocking_tx to transmit a byte to the console over UART in a blocking mode until the entire character has been sent. Hence it must be called with interrupts disabled. It is used when printing diagnostic output from system crash.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ch | 8 bit character (data) to be transmitted |
-
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Here is an example of a console output queue being flushed.
-
-```no-highlight
-void
-task(void)
-{
- struct console_tty *ct = &console_tty;
- uint8_t byte;
-
- while (ct->ct_tx.cr_head != ct->ct_tx.cr_tail) {
- byte = console_pull_char(&ct->ct_tx);
- console_blocking_tx(byte);
- }
-}
-```
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_init.md b/docs/modules/console/console_init.md
deleted file mode 100644
index e9598c5..0000000
--- a/docs/modules/console/console_init.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_init </font>
-
-```no-highlight
- int
- console_init(console_rx_cb rx_cb)
-```
-
- Initializes console receive buffer and calls hal funtions hal_uart_init_cbs and hal_uart_config to initialize serial port connection and configure it (e.g. baud rate, flow control etc.)
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-Give at least one example of usage.
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/console/console_printf.md
----------------------------------------------------------------------
diff --git a/docs/modules/console/console_printf.md b/docs/modules/console/console_printf.md
deleted file mode 100644
index 8eb2280..0000000
--- a/docs/modules/console/console_printf.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> console_printf</font>
-
-```no-highlight
- void
- console_printf(const char *fmt, ...)
-```
-
-Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fmt | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
-
-#### Returned values
-
-None
-
-#### Notes
-
-While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
-
-#### Example
-Example #1:
-
-```no-highlight
-char adv_data_buf[32];
-
-void
-task()
-{
- char adv_data_buf[32];
-
- console_printf("%s", adv_data_buf);
-}
-```
-
-Example #2:
-
-```no-highlight
-struct exception_frame {
- uint32_t r0;
- uint32_t r1;
-
-struct trap_frame {
- struct exception_frame *ef;
- uint32_t r2;
- uint32_t r3;
-};
-
-void
-task(struct trap_frame *tf)
-{
- console_printf(" r0:%8.8x r1:%8.8x", tf->ef->r0, tf->ef->r1);
- console_printf(" r8:%8.8x r9:%8.8x", tf->r2, tf->r3);
-}
-```
-
[2/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/nffs.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/nffs.md b/docs/os/modules/nffs.md
new file mode 100644
index 0000000..97ff43d
--- /dev/null
+++ b/docs/os/modules/nffs.md
@@ -0,0 +1,564 @@
+# Newtron Flash Filesystem (nffs)
+
+Mynewt comes with the flash file system called the Newtron Flash File System (nffs) which is designed with two priorities that makes it suitable for embedded use:
+
+* Minimal RAM usage
+* Reliability
+
+Mynewt also provides an abstraction layer API (fs) to allow you to swap out nffs with a different file system of your choice.
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Disk and data structures
+
+At the top level, an nffs disk is partitioned into areas. An area is a region
+of disk with the following properties:
+
+1. An area can be fully erased without affecting any other areas.
+2. A write to one area does not restrict writes to other areas.
+
+ **Note**: Some flash hardware divides its memory space into "blocks." Writes within a block must be sequential, but writes to one block have no effect on what parts of other blocks can be written. Thus, for flash hardware with such a restriction, each area must comprise a discrete number of blocks.
+
+While not strictly necessary, it is recommended that all areas have the same
+size.
+
+On disk, each area is prefixed with the following header:
+
+```no-highlight
+/** On-disk representation of an area header. */
+struct nffs_disk_area {
+ uint32_t nda_magic[4]; /* NFFS_AREA_MAGIC{0,1,2,3} */
+ uint32_t nda_length; /* Total size of area, in bytes. */
+ uint8_t nda_ver; /* Current nffs version: 0 */
+ uint8_t nda_gc_seq; /* Garbage collection count. */
+ uint8_t reserved8;
+ uint8_t nda_id; /* 0xff if scratch area. */
+};
+```
+
+Beyond its header, an area contains a sequence of disk objects, representing
+the contents of the file system. There are two types of objects: **inodes** and
+**data blocks**. An inode represents a file or directory; a data block represents
+part of a file's contents.
+
+```no-highlight
+/** On-disk representation of an inode (file or directory). */
+struct nffs_disk_inode {
+ uint32_t ndi_magic; /* NFFS_INODE_MAGIC */
+ uint32_t ndi_id; /* Unique object ID. */
+ uint32_t ndi_seq; /* Sequence number; greater supersedes
+ lesser. */
+ uint32_t ndi_parent_id; /* Object ID of parent directory inode. */
+ uint8_t reserved8;
+ uint8_t ndi_filename_len; /* Length of filename, in bytes. */
+ uint16_t ndi_crc16; /* Covers rest of header and filename. */
+ /* Followed by filename. */
+};
+```
+
+An inode filename's length cannot exceed 256 bytes. The filename is not
+null-terminated. The following ASCII characters are not allowed in a
+filename:
+ * / (slash character)
+ * \0 (NUL character)
+
+```no-highlight
+/** On-disk representation of a data block. */
+struct nffs_disk_block {
+ uint32_t ndb_magic; /* NFFS_BLOCK_MAGIC */
+ uint32_t ndb_id; /* Unique object ID. */
+ uint32_t ndb_seq; /* Sequence number; greater supersedes lesser. */
+ uint32_t ndb_inode_id; /* Object ID of owning inode. */
+ uint32_t ndb_prev_id; /* Object ID of previous block in file;
+ NFFS_ID_NONE if this is the first block. */
+ uint16_t ndb_data_len; /* Length of data contents, in bytes. */
+ uint16_t ndb_crc16; /* Covers rest of header and data. */
+ /* Followed by 'ndb_data_len' bytes of data. */
+};
+```
+
+Each data block contains the ID of the previous data block in the file.
+Together, the set of blocks in a file form a reverse singly-linked list.
+
+The maximum number of data bytes that a block can contain is determined at
+initialization-time. The result is the greatest number which satisfies all of
+the following restrictions:
+ o No more than 2048.
+ o At least two maximum-sized blocks can fit in the smallest area.
+
+The 2048 number was chosen somewhat arbitrarily, and may change in the future.
+
+### ID space
+
+All disk objects have a unique 32-bit ID. The ID space is partitioned as
+follows:
+ * 0x00000000 - 0x0fffffff: Directory inodes.
+ * 0x10000000 - 0x7fffffff: File inodes.
+ * 0x80000000 - 0xfffffffe: Data blocks.
+ * 0xffffffff : Reserved (NFFS_ID_NONE)
+
+### Scratch area
+
+A valid nffs file system must contain a single "scratch area." The scratch
+area does not contain any objects of its own, and is only used during garbage
+collection. The scratch area must have a size greater than or equal to each
+of the other areas in flash.
+
+
+### RAM representation
+
+Every object in the file system is stored in a 256-entry hash table. An
+object's hash key is derived from its 32-bit ID. Each list in the hash table
+is sorted by time of use; most-recently-used is at the front of the list. All
+objects are represented by the following structure:
+
+```no-highlight
+/**
+ * What gets stored in the hash table. Each entry represents a data block or
+ * an inode.
+ */
+struct nffs_hash_entry {
+ SLIST_ENTRY(nffs_hash_entry) nhe_next;
+ uint32_t nhe_id; /* 0 - 0x7fffffff if inode; else if block. */
+ uint32_t nhe_flash_loc; /* Upper-byte = area idx; rest = area offset. */
+};
+```
+
+For each data block, the above structure is all that is stored in RAM. To
+acquire more information about a data block, the block header must be read
+from flash.
+
+Inodes require a fuller RAM representation to capture the structure of the
+file system. There are two types of inodes: **files** and **directories**. Each
+inode hash entry is actually an instance of the following structure:
+
+```no-highlight
+/** Each inode hash entry is actually one of these. */
+struct nffs_inode_entry {
+ struct nffs_hash_entry nie_hash_entry;
+ SLIST_ENTRY(nffs_inode_entry) nie_sibling_next;
+ union {
+ struct nffs_inode_list nie_child_list; /* If directory */
+ struct nffs_hash_entry *nie_last_block_entry; /* If file */
+ };
+ uint8_t nie_refcnt;
+};
+```
+
+A directory inode contains a list of its child files and directories
+(fie_child_list). These entries are sorted alphabetically using the ASCII
+character set.
+
+A file inode contains a pointer to the last data block in the file
+(nie_last_block_entry). For most file operations, the reversed block list must
+be walked backwards. This introduces a number of speed inefficiencies:
+ * All data blocks must be read to determine the length of the file.
+ * Data blocks often need to be processed sequentially. The reversed
+ nature of the block list transforms this from linear time to an O(n^2)
+ operation.
+
+Furthermore, obtaining information about any constituent data block requires a
+separate flash read.
+
+### Inode cache and Data Block cache
+
+The speed issues are addressed by a pair of caches. Cached inodes entries
+contain the file length and a much more convenient doubly-linked list of
+cached data blocks. The benefit of using caches is that the size of the
+caches need not be proportional to the size of the file system. In other
+words, caches can address speed efficiency concerns without negatively
+impacting the file system's scalability.
+
+nffs requires both caches during normal operation, so it is not possible to
+disable them. However, the cache sizes are configurable, and both caches can
+be configured with a size of one if RAM usage must be minimized.
+
+The following data structures are used in the inode and data block caches.
+
+```no-highlight
+/** Full data block representation; not stored permanently in RAM. */
+struct nffs_block {
+ struct nffs_hash_entry *nb_hash_entry; /* Points to real block entry. */
+ uint32_t nb_seq; /* Sequence number; greater
+ supersedes lesser. */
+ struct nffs_inode_entry *nb_inode_entry; /* Owning inode. */
+ struct nffs_hash_entry *nb_prev; /* Previous block in file. */
+ uint16_t nb_data_len; /* # of data bytes in block. */
+ uint16_t reserved16;
+};
+
+/** Represents a single cached data block. */
+struct nffs_cache_block {
+ TAILQ_ENTRY(nffs_cache_block) ncb_link; /* Next / prev cached block. */
+ struct nffs_block ncb_block; /* Full data block. */
+ uint32_t ncb_file_offset; /* File offset of this block. */
+};
+
+/** Full inode representation; not stored permanently in RAM. */
+struct nffs_inode {
+ struct nffs_inode_entry *ni_inode_entry; /* Points to real inode entry. */
+ uint32_t ni_seq; /* Sequence number; greater
+ supersedes lesser. */
+ struct nffs_inode_entry *ni_parent; /* Points to parent directory. */
+ uint8_t ni_filename_len; /* # chars in filename. */
+ uint8_t ni_filename[NFFS_SHORT_FILENAME_LEN]; /* First 3 bytes. */
+};
+
+/** Doubly-linked tail queue of cached blocks; contained in cached inodes. */
+TAILQ_HEAD(nffs_block_cache_list, nffs_block_cache_entry);
+
+/** Represents a single cached file inode. */
+struct nffs_cache_inode {
+ TAILQ_ENTRY(nffs_cache_inode) nci_link; /* Sorted; LRU at tail. */
+ struct nffs_inode nci_inode; /* Full inode. */
+ struct nffs_cache_block_list nci_block_list; /* List of cached blocks. */
+ uint32_t nci_file_size; /* Total file size. */
+};
+```
+
+Only file inodes are cached; directory inodes are never cached.
+
+Within a cached inode, all cached data blocks are contiguous. E.g., if the
+start and end of a file are cached, then the middle must also be cached. A
+data block is only cached if its owning file is also cached.
+
+Internally, cached inodes are stored in a singly-linked list, ordered by time
+of use. The most-recently-used entry is the first element in the list. If a
+new inode needs to be cached, but the inode cache is full, the
+least-recently-used entry is freed to make room for the new one. The
+following operations cause an inode to be cached:
+
+* Querying a file's length.
+* Seeking within a file.
+* Reading from a file.
+* Writing to a file.
+
+The following operations cause a data block to be cached:
+
+* Reading from the block.
+* Writing to the block.
+
+If one of the above operations is applied to a data block that is not currently
+cached, nffs uses the following procedure to cache the necessary block:
+
+1. If none of the owning inode's blocks are currently cached, allocate a
+ cached block entry corresponding to the requested block and insert it
+ into the inode's list.
+2. Else if the requested file offset is less than that of the first cached
+ block, bridge the gap between the inode's sequence of cached blocks and
+ the block that now needs to be cached. This is accomplished by caching
+ each block in the gap, finishing with the requested block.
+3. Else (the requested offset is beyond the end of the cache),
+ a. If the requested offset belongs to the block that immediately follows the end of the cache, cache the block and append it to the list.
+ b. Else, clear the cache, and populate it with the single entry corresponding to the requested block.
+
+If the system is unable to allocate a cached block entry at any point during
+the above procedure, the system frees up other blocks currently in the cache. This is accomplished as follows:
+
+* Iterate the inode cache in reverse (i.e., start with the least-recently-used entry). For each entry:
+ a. If the entry's cached block list is empty, advance to the next entry.
+ b. Else, free all the cached blocks in the entry's list.
+
+Because the system imposes a minimum block cache size of one, the above
+procedure will always reclaim at least one cache block entry. The above
+procedure may result in the freeing of the block list that belongs to the very
+inode being operated on. This is OK, as the final block to get cached is
+always the block being requested.
+
+
+## Configuration
+
+The file system is configured by populating fields in a global structure.
+Each field in the structure corresponds to a setting. All configuration must
+be done prior to calling nffs_init(). The configuration structure is defined
+as follows:
+
+```no-highlight
+
+struct nffs_config {
+ /** Maximum number of inodes; default=1024. */
+ uint32_t nc_num_inodes;
+
+ /** Maximum number of data blocks; default=4096. */
+ uint32_t nc_num_blocks;
+
+ /** Maximum number of open files; default=4. */
+ uint32_t nc_num_files;
+
+ /** Inode cache size; default=4. */
+ uint32_t nc_num_cache_inodes;
+
+ /** Data block cache size; default=64. */
+ uint32_t nc_num_cache_blocks;
+ };
+
+extern struct nffs_config nffs_config;
+```
+
+Any fields that are set to 0 (or not set at all) inherit the corresponding
+default value. This means that it is impossible to configure any setting with
+a value of zero.
+
+
+## Initialization
+
+There are two means of initializing an nffs file system:
+
+1. Restore an existing file system via detection.
+2. Create a new file system via formatting.
+
+Both methods require the user to describe how the flash memory is divided into
+areas. This is accomplished with an array of struct nffs_area_desc, defined as
+follows:
+
+```no-highlight
+struct nffs_area_desc {
+ uint32_t nad_offset; /* Flash offset of start of area. */
+ uint32_t nad_length; /* Size of area, in bytes. */
+};
+```
+
+An array of area descriptors is terminated by an entry with a fad_length field
+of 0.
+
+One common initialization sequence is the following:
+
+1. Detect an nffs file system anywhere in flash.
+2. If no file system detected, format a new file system in a specific
+ region of flash.
+
+
+## Detection
+
+The file system detection process consists of scanning a specified set of
+flash regions for valid nffs areas, and then populating the RAM representation
+of the file system with the detected objects. Detection is initiated with the
+following function:
+
+```no-highlight
+/**
+ * Searches for a valid nffs file system among the specified areas. This
+ * function succeeds if a file system is detected among any subset of the
+ * supplied areas. If the area set does not contain a valid file system,
+ * a new one can be created via a separate call to nffs_format().
+ *
+ * @param area_descs The area set to search. This array must be
+ * terminated with a 0-length area.
+ *
+ * @return 0 on success;
+ * NFFS_ECORRUPT if no valid file system was detected;
+ * other nonzero on error.
+ */
+int nffs_detect(const struct nffs_area_desc *area_descs);
+```
+As indicated, not every area descriptor needs to reference a valid nffs area.
+Detection is successful as long as a complete file system is detected
+somewhere in the specified regions of flash. If an application is unsure
+where a file system might be located, it can initiate detection across the
+entire flash region.
+
+A detected file system is valid if:
+
+1. At least one non-scratch area is present.
+2. At least one scratch area is present (only the first gets used if there is more than one).
+3. The root directory inode is present.
+
+During detection, each indicated region of flash is checked for a valid area
+header. The contents of each valid non-scratch area are then restored into
+the nffs RAM representation. The following procedure is applied to each object
+in the area:
+
+1. Verify the object's integrity via a crc16 check. If invalid, the object is discarded and the procedure restarts on the next object in the area.
+
+2. Convert the disk object into its corresponding RAM representation and insert it into the hash table. If the object is an inode, its reference count is initialized to 1, indicating ownership by its parent directory.
+
+3. If an object with the same ID is already present, then one supersedes the other. Accept the object with the greater sequence number and discard the other.
+
+4. If the object references a nonexistant inode (parent directory in the case of an inode; owning file in the case of a data block), insert a temporary "dummy" inode into the hash table so that inter-object links can be maintained until the absent inode is eventually restored. Dummy inodes are identified by a reference count of 0.
+
+5. If a delete record for an inode is encountered, the inode's parent pointer is set to null to indicate that it should be removed from RAM.
+
+If nffs encounters an object that cannot be identified (i.e., its magic number
+is not valid), it scans the remainder of the flash area for the next valid
+magic number. Upon encountering a valid object, nffs resumes the procedure
+described above.
+
+After all areas have been restored, a sweep is performed across the entire RAM
+representation so that invalid inodes can be deleted from memory.
+
+For each directory inode:
+
+* If its reference count is 0 (i.e., it is a dummy), migrate its children to the /lost+found directory, and delete it from the RAM representation. This should only happen in the case of file system corruption.
+ * If its parent reference is null (i.e., it was deleted), delete it and all its children from the RAM representation.
+
+For each file inode:
+
+* If its reference count is 0 (i.e., it is a dummy), delete it from the RAM representation. This should only happen in the case of file system corruption. (We should try to migrate the file to the lost+found directory in this case, as mentioned in the todo section).
+
+When an object is deleted during this sweep, it is only deleted from the RAM
+representation; nothing is written to disk.
+
+When objects are migrated to the lost+found directory, their parent inode
+reference is permanently updated on the disk.
+
+In addition, a single scratch area is identified during the detection process.
+The first area whose 'fda_id' value is set to 0xff is designated as the file
+system scratch area. If no valid scratch area is found, the cause could be
+that the system was restarted while a garbage collection cycle was in progress.
+Such a condition is identified by the presence of two areas with the same ID.
+In such a case, the shorter of the two areas is erased and designated as the
+scratch area.
+
+
+## Formatting
+
+A new file system is created via formatting. Formatting is achieved via the
+following function:
+
+```no-highlight
+/**
+ * Erases all the specified areas and initializes them with a clean nffs
+ * file system.
+ *
+ * @param area_descs The set of areas to format.
+ *
+ * @return 0 on success;
+ * nonzero on failure.
+ */
+int nffs_format(const struct nffs_area_desc *area_descs);
+```
+
+On success, an area header is written to each of the specified locations. The
+largest area in the set is designated as the initial scratch area.
+
+
+## Flash writes
+
+The nffs implementation always writes in a strictly sequential fashion within an
+area. For each area, the system keeps track of the current offset. Whenever
+an object gets written to an area, it gets written to that area's current
+offset, and the offset is increased by the object's disk size.
+
+When a write needs to be performed, the nffs implementation selects the
+appropriate destination area by iterating though each area until one with
+sufficient free space is encountered.
+
+There is no write buffering. Each call to a write function results in a write
+operation being sent to the flash hardware.
+
+
+### New objects
+
+Whenever a new object is written to disk, it is assigned the following
+properties:
+ * ID: A unique value is selected from the 32-bit ID space, as appropriate
+ for the object's type.
+ * Sequence number: 0
+
+When a new file or directory is created, a corresponding inode is written to
+flash. Likewise, a new data block also results in the writing of a
+corresponding disk object.
+
+
+### Moving/Renaming files and directories
+
+When a file or directory is moved or renamed, its corresponding inode is
+rewritten to flash with the following properties:
+
+* ID: Unchanged
+* Sequence number: Previous value plus one.
+* Parent inode: As specified by the move / rename operation.
+* Filename: As specified by the move / rename operation.
+
+Because the inode's ID is unchanged, all dependent objects remain valid.
+
+
+### Unlinking files and directories
+
+When a file or directory is unlinked from its parent directory, a deletion
+record for the unlinked inode gets written to flash. The deletion record is an
+inode with the following properties:
+
+* ID: Unchanged
+* Sequence number: Previous value plus one.
+* Parent inode ID: NFFS_ID_NONE
+
+When an inode is unlinked, no deletion records need to be written for the
+inode's dependent objects (constituent data blocks or child inodes). During
+the next file system detection, it is recognized that the objects belong to
+a deleted inode, so they are not restored into the RAM representation.
+
+If a file has an open handle at the time it gets unlinked, application code
+can continued to use the file handle to read and write data. All files retain
+a reference count, and a file isn't deleted from the RAM representation until
+its reference code drops to 0. Any attempt to open an unlinked file fails,
+even if the file is referenced by other file handles.
+
+
+### Writing to a file
+
+The following procedure is used whenever the application code writes to a file.
+First, if the write operation specifies too much data to fit into a single
+block, the operation is split into several separate write operations. Then,
+for each write operation:
+
+1\. Determine which existing blocks the write operation overlaps (n = number of overwritten blocks).
+
+2\. If n = 0, this is an append operation. Write a data block with the following properties:
+
+ * ID: New unique value.
+ * Sequence number: 0.
+
+3\. Else (n > 1), this write overlaps existing data.
+
+ (a) For each block in [1, 2, ... n-1], write a new block containing the updated contents. Each new block supersedes the block it overwrites. That is, each block has the following properties:
+
+ * ID: Unchanged
+ * Sequence number: Previous value plus one.
+
+ (b) Write the nth block. The nth block includes all appended data, if any. As with the other blocks, its ID is unchanged and its sequence number is incremented.
+
+Appended data can only be written to the end of the file. That is, "holes" are
+not supported.
+
+
+## Garbage collection
+
+When the file system is too full to accomodate a write operation, the system
+must perform garbage collection to make room. The garbage collection
+procedure is described below:
+
+* The non-scratch area with the lowest garbage collection sequence number is selected as the "source area." If there are other areas with the same sequence number, the one with the smallest flash offset is selected.
+
+* The source area's ID is written to the scratch area's header, transforming it into a non-scratch ID. This former scratch area is now known as the "destination area."
+
+* The RAM representation is exhaustively searched for collectible objects. The following procedure is applied to each inode in the system:
+ * If the inode is resident in the source area, copy the inode record to the destination area.
+ * If the inode is a file inode, walk the inode's list of data blocks, starting with the last block in the file. Each block that is resident in the source area is copied to the destination area. If there is a run of two or more blocks that are resident in the source area, they are consolidated and copied to the destination area as a single new block (subject to the maximum block size restriction).
+
+* The source area is reformatted as a scratch sector (i.e., is is fully erased, and its header is rewritten with an ID of 0xff). The area's garbage collection sequence number is incremented prior to rewriting the header. This area is now the new scratch sector.
+
+
+## Miscellaneous measures
+
+* RAM usage:
+ * 24 bytes per inode
+ * 12 bytes per data block
+ * 36 bytes per inode cache entry
+ * 32 bytes per data block cache entry
+
+* Maximum filename size: 256 characters (no null terminator required)
+* Disallowed filename characters: '/' and '\0'
+
+
+## Future enhancements
+
+* API function to traverse a directory.
+* Migrate corrupt files to the /lost+found directory during restore, rather than discarding them from RAM.
+* Error correction.
+* Encryption.
+* Compression.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell.md b/docs/os/modules/shell/shell.md
new file mode 100644
index 0000000..db575bc
--- /dev/null
+++ b/docs/os/modules/shell/shell.md
@@ -0,0 +1,115 @@
+# Shell
+
+The shell is the program which puts up a prompt for a command, processes commands, and returns output. Interacting with the console of a device is done using a shell program.
+
+
+## Description
+
+Shell processes console input one line at a time. Eggs can register handlers for their commands. Shell parses the input, matches it against the set of registered commands, and then calls the handler it finds.
+
+A few commands are currently available in the shell - `tasks`, `log`, and `stat stat`. A $ prompt sign will be coming soon!
+
+Create a sim target to check out these commands available in shell.
+
+```no-highlight
+user@~/dev/larva$ newt target create blinky_sim
+Creating target blinky_sim
+Target blinky_sim successfully created!
+user@~/dev/larva$ newt target set blinky_sim name=blinky_sim
+Target blinky_sim successfully set name to blinky_sim
+user@~/dev/larva$ newt target set blinky_sim arch=sim
+Target blinky_sim successfully set arch to sim
+user@~/dev/larva$ newt target set blinky_sim project=blinky
+Target blinky_sim successfully set project to blinky
+user@~/dev/larva$ newt target set blinky_sim bsp=hw/bsp/native
+Target blinky_sim successfully set bsp to hw/bsp/native
+user@~/dev/larva$ newt target set blinky_sim compiler_def=debug
+Target blinky_sim successfully set compiler_def to debug
+user@~/dev/larva$ newt target set blinky_sim compiler=sim
+Target blinky_sim successfully set compiler to sim
+user@~/dev/larva$ newt target show
+blinky_sim
+ arch: sim
+ bsp: hw/bsp/native
+ compiler: sim
+ compiler_def: debug
+ name: blinky_sim
+ project: blinky
+user@~/dev/larva$ newt target build blinky_sim
+Building target blinky_sim (project = blinky)
+Compiling case.c
+Compiling suite.c
+Compiling testutil.c
+..
+..
+Building project blinky
+Linking blinky.elf
+Successfully run!
+
+user@~/dev/larva$ ./project/blinky/bin/blinky_sim/blinky.elf
+uart0 at /dev/ttys005
+
+```
+
+Open up a new terminal to run minicom, a text-based serial port control and terminal emulation program. Set device name to the serial port of the target.
+
+```no-highlight
+user@~$ minicom -D /dev/ttys005
+Welcome to minicom 2.7
+
+OPTIONS:
+Compiled on Nov 24 2015, 16:14:21.
+Port /dev/ttys005, 11:32:17
+
+Press Meta-Z for help on special keys
+
+log
+174578:[0] bla
+174578:[0] bab
+
+tasks
+217809:6 tasks:
+217809: shell (prio: 3, nw: 0, flags: 0x0, ssize: 0, cswcnt: 59, tot_run_time: 0ms)
+217840: idle (prio: 255, nw: 0, flags: 0x0, ssize: 0, cswcnt: 18763, tot_run_time: 217809ms)
+217878: uart_poller (prio: 0, nw: 217819, flags: 0x0, ssize: 0, cswcnt: 18667, tot_run_time: 0ms)
+217923: task1 (prio: 1, nw: 218710, flags: 0x0, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
+217953: os_sanity (prio: 254, nw: 218710, flags: 0x0, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
+218010: task2 (prio: 2, nw: 217709, flags: 0x3, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
+
+stat stat
+229881:s0: 1
+
+```
+
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+The functions available in this OS feature are:
+
+* [shell_cmd](shell_cmd.md)
+* [shell_cmd_list_lock](shell_cmd_list_lock.md)
+* [shell_cmd_list_unlock](shell_cmd_list_unlock.md)
+* [shell_cmd_register](shell_cmd_register.md)
+* [shell_console_rx_cb](shell_console_rx_cb.md)
+* [shell_echo_cmd](shell_echo_cmd.md)
+* [shell_help_cmd](shell_help_cmd.md)
+* [shell_nlip_input_register](shell_nlip_input_register.md)
+* [shell_nlip_mqueue_process](shell_nlip_mqueue_process.md)
+* [shell_nlip_mtx](shell_nlip_mtx.md)
+* [shell_nlip_output](shell_nlip_output.md)
+* [shell_nlip_process](shell_nlip_process.md)
+* [shell_os_mpool_display_cmd](shell_os_mpool_display_cmd.md)
+* [shell_os_tasks_display_cmd](shell_os_tasks_display_cmd.md)
+* [shell_process_command](shell_process_command.md)
+* [shell_read_console](shell_read_console.md)
+* [shell_task_func](shell_task_func.md)
+* [shell_task_init](shell_task_init.md)
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_cmd.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_cmd.md b/docs/os/modules/shell/shell_cmd.md
new file mode 100644
index 0000000..4aad702
--- /dev/null
+++ b/docs/os/modules/shell/shell_cmd.md
@@ -0,0 +1,39 @@
+## <font color="F2853F" style="font-size:24pt"> shell_cmd </font>
+
+```no-highlight
+ static int
+ shell_cmd(char *cmd, char **argv, int argc)
+```
+
+<Put description here>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| arg1 | description |
+| arg2 | description |
+| arg3 | description |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+What to look out for, special cases, things to consider
+
+#### Example
+
+
+
+```no-highlight
+
+ give an example
+
+```
+
+---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_cmd_list_lock.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_cmd_list_lock.md b/docs/os/modules/shell/shell_cmd_list_lock.md
new file mode 100644
index 0000000..44977cb
--- /dev/null
+++ b/docs/os/modules/shell/shell_cmd_list_lock.md
@@ -0,0 +1,39 @@
+## <font color="F2853F" style="font-size:24pt"> shell_cmd_list_lock </font>
+
+```no-highlight
+ static int
+ shell_cmd_list_lock(void)
+```
+
+<Put description here>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| arg1 | description |
+| arg2 | description |
+| arg3 | description |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+What to look out for, special cases, things to consider
+
+#### Example
+
+
+
+```no-highlight
+
+ give an example
+
+```
+
+---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_cmd_list_unlock.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_cmd_list_unlock.md b/docs/os/modules/shell/shell_cmd_list_unlock.md
new file mode 100644
index 0000000..6604294
--- /dev/null
+++ b/docs/os/modules/shell/shell_cmd_list_unlock.md
@@ -0,0 +1,38 @@
+## <font color="F2853F" style="font-size:24pt"> shell_cmd_list_unlock </font>
+
+```no-highlight
+ static int
+ shell_cmd_list_unlock(void)
+```
+
+<Put description here>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| arg1 | description |
+| arg2 | description |
+| arg3 | description |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+What to look out for, special cases, things to consider
+
+#### Example
+
+
+
+```no-highlight
+
+ give an example
+
+```
+
+---------------------
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_cmd_register.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_cmd_register.md b/docs/os/modules/shell/shell_cmd_register.md
new file mode 100644
index 0000000..9d2b3d6
--- /dev/null
+++ b/docs/os/modules/shell/shell_cmd_register.md
@@ -0,0 +1,46 @@
+```no-highlight
+ int
+ shell_cmd_register(struct shell_cmd *sc, char *cmd, shell_cmd_func_t func)
+```
+
+Register a shell command. When shell reads a line of input which starts with `cmd`, it calls the handler `func`. Caller must allocate data structure `sc`. Shell internally links this to it's list of command handlers.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| sc | Pointer to data structure shell egg uses to store info about the registered command |
+| cmd | Command getting registered |
+| func | Function to call when command is received from console |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Shell splits the arguments following the command into an array of character pointers, and passes these to registered handler. The function will be called in shell task's context, so the command handler should look out for possible issues due to concurrency.
+
+#### Example
+
+Here is FS registering command for 'ls'.
+
+```no-highlight
+static struct shell_cmd fs_ls_struct;
+
+void
+fs_cli_init(void)
+{
+ int rc;
+
+ rc = shell_cmd_register(&fs_ls_struct, "ls", fs_ls_cmd);
+ if (rc != 0) {
+ return;
+ }
+}
+
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_console_rx_cb.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_console_rx_cb.md b/docs/os/modules/shell/shell_console_rx_cb.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_echo_cmd.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_echo_cmd.md b/docs/os/modules/shell/shell_echo_cmd.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_help_cmd.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_help_cmd.md b/docs/os/modules/shell/shell_help_cmd.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_nlip_input_register.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_input_register.md b/docs/os/modules/shell/shell_nlip_input_register.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_nlip_mqueue_process.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_mqueue_process.md b/docs/os/modules/shell/shell_nlip_mqueue_process.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_nlip_mtx.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_mtx.md b/docs/os/modules/shell/shell_nlip_mtx.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_nlip_output.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_output.md b/docs/os/modules/shell/shell_nlip_output.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_nlip_process.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_process.md b/docs/os/modules/shell/shell_nlip_process.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_os_mpool_display_cmd.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_os_mpool_display_cmd.md b/docs/os/modules/shell/shell_os_mpool_display_cmd.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_os_tasks_display_cmd.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_os_tasks_display_cmd.md b/docs/os/modules/shell/shell_os_tasks_display_cmd.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_process_command.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_process_command.md b/docs/os/modules/shell/shell_process_command.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_read_console.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_read_console.md b/docs/os/modules/shell/shell_read_console.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_task_func.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_task_func.md b/docs/os/modules/shell/shell_task_func.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shell/shell_task_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_task_init.md b/docs/os/modules/shell/shell_task_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgmgr_module_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgmgr_module_init.md b/docs/os/modules/shelltest/imgmgr_module_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_boot_read.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_boot_read.md b/docs/os/modules/shelltest/imgr_boot_read.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_boot_write.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_boot_write.md b/docs/os/modules/shelltest/imgr_boot_write.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_file_download.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_file_download.md b/docs/os/modules/shelltest/imgr_file_download.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_file_upload.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_file_upload.md b/docs/os/modules/shelltest/imgr_file_upload.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_list.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_list.md b/docs/os/modules/shelltest/imgr_list.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_noop.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_noop.md b/docs/os/modules/shelltest/imgr_noop.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_read_file.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_read_file.md b/docs/os/modules/shelltest/imgr_read_file.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_read_main.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_read_main.md b/docs/os/modules/shelltest/imgr_read_main.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_read_test.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_read_test.md b/docs/os/modules/shelltest/imgr_read_test.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_read_ver.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_read_ver.md b/docs/os/modules/shelltest/imgr_read_ver.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_upload.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_upload.md b/docs/os/modules/shelltest/imgr_upload.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_ver_jsonstr.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_ver_jsonstr.md b/docs/os/modules/shelltest/imgr_ver_jsonstr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_ver_parse.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_ver_parse.md b/docs/os/modules/shelltest/imgr_ver_parse.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_ver_str.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_ver_str.md b/docs/os/modules/shelltest/imgr_ver_str.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/imgr_write_file.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/imgr_write_file.md b/docs/os/modules/shelltest/imgr_write_file.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/shelltest/shelltest.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shelltest/shelltest.md b/docs/os/modules/shelltest/shelltest.md
new file mode 100644
index 0000000..45535b5
--- /dev/null
+++ b/docs/os/modules/shelltest/shelltest.md
@@ -0,0 +1,92 @@
+# Console
+
+
+The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS.
+
+Support is currently available for console access via the serial port on the hardware board.
+
+
+## Description
+
+In the Mynewt OS, the console library comes in two versions:
+
+* full - containing the full implementation
+* stub - containing stubs for the API
+
+Both of these have `egg.yml` file which states that they provide the `console` API. If an egg uses this API, it should list `console` as a requirement.
+For example, the shell egg is defined by the following egg.yml file:
+```no-highlight
+ egg.name: libs/shell
+ egg.vers: 0.1
+ egg.deps:
+ - libs/os
+ - libs/util
+ egg.reqs:
+ - console
+ egg.identities:
+ - SHELL
+```
+The project .yml file decides which version of the console egg should be included.
+If project requires the full console capability it lists dependency `libs/console/full` in its egg.yml file.
+On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` egg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead and the egg.yml file for the project boot egg looks like the following:
+```no-highlight
+ project.name: boot
+ project.identities: bootloader
+ project.eggs:
+ - libs/os
+ - libs/bootutil
+ - libs/nffs
+ - libs/console/stub
+ - libs/util
+```
+
+Console has 2 modes for transmit; blocking and non-blocking mode. Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.
+Blocking mode is used when we don't want TX completion interrupts. This is used when system crashes, and we still want to output info related to that crash.
+
+## Data structures
+
+
+Console interaction is intrinsically composed of two unidirectional systems. The console implementation uses two ring buffers containing input (receive) and output (transmit) characters, respectively. Read and write operations on the console_ring structure are managed by labeling the read location indicator the `cr_tail` and the write location indicator the `cr_head`. The console ring length is variable and is specified as the `cr_size` member of the data structure. `cr_buf` is the pointer to the actual array of data contained.
+
+
+```no-highlight
+struct console_ring {
+ 32 uint8_t cr_head;
+ 33 uint8_t cr_tail;
+ 34 uint8_t cr_size;
+ 35 uint8_t _pad;
+ 36 uint8_t *cr_buf;
+ 37 }
+```
+
+
+```no-highlight
+struct console_tty {
+ 40 struct console_ring ct_tx;
+ 41 uint8_t ct_tx_buf[CONSOLE_TX_BUF_SZ]; /* must be after console_ring */
+ 42 struct console_ring ct_rx;
+ 43 uint8_t ct_rx_buf[CONSOLE_RX_BUF_SZ]; /* must be after console_ring */
+ 44 console_rx_cb ct_rx_cb; /* callback that input is ready */
+ 45 console_write_char ct_write_char;
+ 46 } console_tty
+```
+
+## List of Functions
+The functions available in shelltest are:
+
+* [imgmgr_module_init](imgmgr_module_init.md)
+* [imgr_boot_read](imgr_boot_read.md)
+* [imgr_boot_write](imgr_boot_write.md)
+* [imgr_file_download](imgr_file_download.md)
+* [imgr_file_upload](imgr_file_upload.md)
+* [imgr_list](imgr_list.md)
+* [imgr_noop](imgr_noop.md)
+* [imgr_read_file](imgr_read_file.md)
+* [imgr_read_main](imgr_read_main.md)
+* [imgr_read_test](imgr_read_test.md)
+* [imgr_read_ver](imgr_read_ver.md)
+* [imgr_upload](imgr_upload.md)
+* [imgr_ver_jsonstr](imgr_ver_jsonstr.md)
+* [imgr_ver_parse](imgr_ver_parse.md)
+* [imgr_ver_str](imgr_ver_str.md)
+* [imgr_write_file](imgr_write_file.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/testutil.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/testutil.md b/docs/os/modules/testutil/testutil.md
new file mode 100644
index 0000000..821f64b
--- /dev/null
+++ b/docs/os/modules/testutil/testutil.md
@@ -0,0 +1,38 @@
+# testutil
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+The functions available in testutil are:
+
+* [tu_case_abort](tu_case_abort.md)
+* [tu_case_append_assert_msg](tu_case_append_assert_msg.md)
+* [tu_case_append_buf](tu_case_append_buf.md)
+* [tu_case_append_file_info](tu_case_append_file_info.md)
+* [tu_case_append_manual_pass_msg](tu_case_append_manual_pass_msg.md)
+* [tu_case_complete](tu_case_complete.md)
+* [tu_case_fail_assert](tu_case_fail_assert.md)
+* [tu_case_init](tu_case_init.md)
+* [tu_case_pass_manual](tu_case_pass_manual.md)
+* [tu_case_set_name](tu_case_set_name.md)
+* [tu_case_vappend_buf](tu_case_vappend_buf.md)
+* [tu_case_write_fail_buf](tu_case_write_fail_buf.md)
+* [tu_case_write_pass_auto](tu_case_write_pass_auto.md)
+* [tu_case_write_pass_buf](tu_case_write_pass_buf.md)
+* [tu_init](tu_init.md)
+* [tu_restart](tu_restart.md)
+* [tu_suite_init](tu_suite_init.md)
+* [tu_suite_set_name](tu_suite_set_name.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_abort.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_abort.md b/docs/os/modules/testutil/tu_case_abort.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_append_assert_msg.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_append_assert_msg.md b/docs/os/modules/testutil/tu_case_append_assert_msg.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_append_buf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_append_buf.md b/docs/os/modules/testutil/tu_case_append_buf.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_append_file_info.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_append_file_info.md b/docs/os/modules/testutil/tu_case_append_file_info.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_append_manual_pass_msg.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_append_manual_pass_msg.md b/docs/os/modules/testutil/tu_case_append_manual_pass_msg.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_complete.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_complete.md b/docs/os/modules/testutil/tu_case_complete.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_fail_assert.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_fail_assert.md b/docs/os/modules/testutil/tu_case_fail_assert.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_init.md b/docs/os/modules/testutil/tu_case_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_pass_manual.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_pass_manual.md b/docs/os/modules/testutil/tu_case_pass_manual.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_set_name.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_set_name.md b/docs/os/modules/testutil/tu_case_set_name.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_vappend_buf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_vappend_buf.md b/docs/os/modules/testutil/tu_case_vappend_buf.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_write_fail_buf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_write_fail_buf.md b/docs/os/modules/testutil/tu_case_write_fail_buf.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_write_pass_auto.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_write_pass_auto.md b/docs/os/modules/testutil/tu_case_write_pass_auto.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_case_write_pass_buf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_case_write_pass_buf.md b/docs/os/modules/testutil/tu_case_write_pass_buf.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_init.md b/docs/os/modules/testutil/tu_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_restart.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_restart.md b/docs/os/modules/testutil/tu_restart.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_suite_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_suite_init.md b/docs/os/modules/testutil/tu_suite_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/testutil/tu_suite_set_name.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/testutil/tu_suite_set_name.md b/docs/os/modules/testutil/tu_suite_set_name.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/mutex.md
----------------------------------------------------------------------
diff --git a/docs/os/mutex.md b/docs/os/mutex.md
deleted file mode 100644
index 484b1fb..0000000
--- a/docs/os/mutex.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# Mutex
-
-
-Mutex is short for "mutual exclusion"; a mutex provides mutually exclusive access to a shared resource. A mutex provides *priority inheritance* in order to prevent *priority inversion*. Priority inversion occurs when a higher priority task is waiting on a resource owned by a lower priority task. Using a mutex, the lower priority task will inherit the highest priority of any task waiting on the mutex.
-
-
-## Description
-
-The first order of business when using a mutex is to declare the mutex globally. The mutex needs to be initialized before it is used (see the examples). It is generally a good idea to initialize the mutex before tasks start running in order to avoid a task possibly using the mutex before it is initialized.
-
-When a task wants exclusive access to a shared resource it needs to obtain the mutex by calling *os_mutex_pend*. If the mutex is currently owned by a different task (a lower priority task), the requesting task will be put to sleep and the owners priority will be elevated to the priority of the requesting task. Note that multiple tasks can request ownership and the current owner is elevated to the highest priority of any task waitin on the mutex. When the task is done using the shared resource, it needs to release the mutex by called *os_mutex_release*. There needs to be one release per call to pend. Note that nested calls to *os_mutex_pend* are allowed but there needs to be one release per pend.
-
-The following example will illustrate how priority inheritance works. In this example, the task number is the same as its priority. Remember that the lower the number, the higher the priority (i.e. priority 0 is higher priority than priority 1). Suppose that task 5 gets ownership of a mutex but is preempted by task 4. Task 4 attempts to gain ownership of the mutex but cannot as it is owned by task 5. Task 4 is put to sleep and task 5 is temporarily raised to priority 4. Before task 5 can release the mutex, task 3 runs and attempts to acquire the mutex. At this point, both task 3 and task 4 are waiting on the mutex (sleeping). Task 5 now runs at priority 3 (the highest priority of all the tasks waiting on the mutex). When task 5 finally releases the mutex it will be preempted as two higher priority tasks are waiting for it.
-
-Note that when multiple tasks are waiting on a mutex owned by another task, once the mutex is released the highest priority task waiting on the mutex is run.
-
-## Data structures
-
-```no-highlight
-struct os_mutex
-{
- SLIST_HEAD(, os_task) mu_head;
- uint8_t _pad;
- uint8_t mu_prio;
- uint16_t mu_level;
- struct os_task *mu_owner;
-};
-```
-
-| Element | Description |
-|-----------|-------------|
-| mu_head | Queue head for list of tasks waiting on mutex |
-| _pad | Padding |
-| mu_prio | Default priority of owner of mutex. Used to reset priority of task when mutex released |
-| mu_level | Call nesting level (for nested calls) |
-| mu_owner | Pointer to task structure which owns mutex |
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_mutex_init](#os_mutex_init)
-* [os_mutex_release](#os_mutex_release)
-* [os_mutex_pend](#os_mutex_pend)
-* [os_mutex_delete](#os_mutex_delete)
-
-## Function Reference
-
-------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_mutex_init</font>
-
-```no-highlight
-os_error_t os_mutex_init(struct os_mutex *mu)
-```
-
-Initialize the mutex. Must be called before the mutex can be used.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu| Pointer to mutex |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex initialized successfully.
-
-#### Notes
-
-<Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).>
-
-#### Example
-
-
-```no-highlight
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_init(&g_mutex1);
-assert(err == OS_OK);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_mutex_release</font>
-
-```no-highlight
-os_error_t os_mutex_release(struct os_mutex *mu)
-```
-
-Release ownership of a mutex
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu| Pointer to mutex |
-
-#### Returned values
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex initialized successfully.
-
-OS_BAD_MUTEX: The mutex was not owned by the task attempting to release it.
-
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
-
-
-#### Example
-
-
-```no-highlight
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_pend(&g_mutex1, 0);
-assert(err == OS_OK);
-
-/* Perform operations requiring exclusive access */
-
-err = os_mutex_release(&g_mutex1);
-assert(err == OS_OK);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_mutex_pend </font>
-
-```no-highlight
-os_error_t os_mutex_pend(struct os_mutex *mu, uint32_t timeout)
-```
-
-Acquire ownership of a mutex.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu | Pointer to mutex |
-| timeout | Timeout, in os ticks. A value of 0 means no timeout. A value of 0xFFFFFFFF means to wait forever. |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex was successfully acquired.
-
-OS_TIMEOUT: the mutex was not available within the timeout specified.
-
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
-
-
-#### Notes
-
-If the mutex is owned by another task and the timeout is 0 the function returns immediately with the error code OS_TIMEOUT. The calling task *does not* own the mutex when this occurs.
-
-#### Example
-
-
-
-```no-highlight
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_pend(&g_mutex1, 0);
-assert(err == OS_OK);
-
-/* Perform operations requiring exclusive access */
-
-err = os_mutex_release(&g_mutex1);
-assert(err == OS_OK);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_mutex_delete </font>
-
-```no-highlight
-os_error_t os_mutex_pend(struct os_mutex *mu)
-```
-
-Delete a mutex
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu | Pointer to mutex |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex initialized successfully.
-
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
-
-#### Example
-
-```no-highlight
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_delete(&g_mutex1);
-assert(err == OS_OK);
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/mynewt_os.md
----------------------------------------------------------------------
diff --git a/docs/os/mynewt_os.md b/docs/os/mynewt_os.md
deleted file mode 100644
index c1064ba..0000000
--- a/docs/os/mynewt_os.md
+++ /dev/null
@@ -1,159 +0,0 @@
-# Mynewt OS
-
-Insert introduction here
-
-## Real-Time Kernel <Modify as you Wish>
-
- Description
-
-## Real-Time OS <Modify as you Wish>
-
- Description
-
-
-## Insert topic of your choice
-
- Description
-
-## Features
-
-<Insert basic feature descriptions, how the various pieces fit together etc., what's special in Mynewt OS>
-
-* [Scheduler/context switching](context_switch.md)
-* [Time](time.md)
-* [Tasks](task.md)
-* [Event queues/callouts](event_queue.md)
-* [Semaphores](semaphore.md)
-* [Mutexes](mutex.md)
-* [Memory pools](memory_pool.md)
-* [Heap](heap.md)
-* [Mbufs](mbufs.md)
-* [Sanity](sanity.md)
-* [Porting OS to other platforms](port_os.md)
-
-## OS Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_idle_task](#os_idle_task)
-* [os_started](#os_started)
-* add the rest
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_idle_task</font>
-
-```no-highlight
- void
- os_idle_task(void *arg)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_started</font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/port_os.md
----------------------------------------------------------------------
diff --git a/docs/os/port_os.md b/docs/os/port_os.md
deleted file mode 100644
index 1331dde..0000000
--- a/docs/os/port_os.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Porting Mynewt OS
-
-
-This chapter describes how to adapt Newt OS to different processors. Adapting μC/OS-III to a microprocessor or a microcontroller is called porting.
-
-
-## Description
-
-
-## Insert sections as you wish
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/sanity.md
----------------------------------------------------------------------
diff --git a/docs/os/sanity.md b/docs/os/sanity.md
deleted file mode 100644
index 6d950ff..0000000
--- a/docs/os/sanity.md
+++ /dev/null
@@ -1,141 +0,0 @@
-# Sanity
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_sanity_check_init](#os_sanity_check_init)
-* [os_sanity_check_list_lock](#os_sanity_check_list_lock)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_sanity_check_init</font>
-
-```no-highlight
- int
- os_sanity_check_init(struct os_sanity_check *sc)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_sanity_check_list_lock </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/semaphore.md
----------------------------------------------------------------------
diff --git a/docs/os/semaphore.md b/docs/os/semaphore.md
deleted file mode 100644
index e55fe01..0000000
--- a/docs/os/semaphore.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# Semaphore
-
-A semaphore is a structure used for gaining exclusive access (much like a mutex), synchronizing task operations and/or use in a "producer/consumer" roles. Semaphores like the ones used by the myNewt OS are called "counting" semaphores as they are allowed to have more than one token (explained below).
-
-
-## Description
-
-A semaphore is a fairly simple construct consisting of a queue for waiting tasks and the number of tokens currently owned by the semaphore. A semaphore can be obtained as long as there are tokens in the semaphore. Any task can add tokens to the semaphore and any task can request the semaphore, thereby removing tokens. When creating the semaphore, the initial number of tokens can be set as well.
-
-When used for exclusive access to a shared resource the semaphore only needs a single token. In this case, a single task "creates" the semaphore by calling *os_sem_init* with a value of one (1) for the token. When a task desires exclusive access to the shared resource it requests the semaphore by calling *os_sem_pend*. If there is a token the requesting task will acquire the semaphore and continue operation. If no tokens are available the task will be put to sleep until there is a token. A common "problem" with using a semaphore for exclusive access is called *priority inversion*. Consider the following scenario: a high and low priority task both share a resource which is locked using a semaphore. If the low priority task obtains the semaphore and then the high priority task requests the semaphore, the high priority task is now blocked until the low priority task releases the semaphore. Now suppose that there are tasks between the low priority task and the high priority task that wa
nt to run. These tasks will preempt the low priority task which owns the semaphore. Thus, the high priority task is blocked waiting for the low priority task to finish using the semaphore but the low priority task cannot run since other tasks are running. Thus, the high priority tasks is "inverted" in priority; in effect running at a much lower priority as normally it would preempt the other (lower priority) tasks. If this is an issue a mutex should be used instead of a semaphore.
-
-Semaphores can also be used for task synchronization. A simple example of this would be the following. A task creates a semaphore and initializes it with no tokens. The task then waits on the semaphore, and since there are no tokens, the task is put to sleep. When other tasks want to wake up the sleeping task they simply add a token by calling *os_sem_release*. This will cause the sleeping task to wake up (instantly if no other higher priority tasks want to run).
-
-The other common use of a counting semaphore is in what is commonly called a "producer/consumer" relationship. The producer adds tokens (by calling *os_sem_release*) and the consumer consumes them by calling *os_sem_pend*. In this relationship, the producer has work for the consumer to do. Each token added to the semaphore will cause the consumer to do whatever work is required. A simple example could be the following: every time a button is pressed there is some work to do (ring a bell). Each button press causes the producer to add a token. Each token consumed rings the bell. There will exactly the same number of bell rings as there are button presses. In other words, each call to *os_sem_pend* subtracts exactly one token and each call to *os_sem_release* adds exactly one token.
-
-## Data structures
-
-```no-highlight
-struct os_sem
-{
- SLIST_HEAD(, os_task) sem_head; /* chain of waiting tasks */
- uint16_t _pad;
- uint16_t sem_tokens; /* # of tokens */
-};
-```
-
-| Element | Description |
-|-----------|-------------|
-| sem_head | Queue head for list of tasks waiting on semaphore |
-| _pad | Padding for alignment |
-| sem_tokens | Current number of tokens |
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_sem_init](#os_sem_init)
-* [os_sem_release](#os_sem_release)
-* [os_sem_pend](#os_sem_pend)
-* [os_sem_delete](#os_sem_delete)
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_sem_init</font>
-
-```no-highlight
-os_error_t os_sem_init(struct os_sem *sem, uint16_t tokens)
-```
-
-Initialize a semaphore with a given number of tokens. Should be called before the semaphore is used.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-| tokens | Initial number of tokens allocated to semaphore |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore initialized successfully.
-
-#### Notes
-
-<Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).>
-
-#### Example
-
-The following example shows how to initialize a semaphore used for exclusive access.
-
-```no-highlight
-struct os_mutex g_os_sem;
-os_error_t err;
-
-err = os_sem_init(&g_os_sem, 1);
-assert(err == OS_OK);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_sem_release </font>
-
-```no-highlight
-os_error_t os_sem_release(struct os_sem *sem)
-```
-
-Release a semaphore that you are holding. This adds a token to the semaphore.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-
-#### Returned values
-
-OS_NOT_STARTED: Called before os has been started.
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore released successfully.
-
-#### Notes
-
-
-#### Example
-
-```no-highlight
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
-assert(err == OS_OK);
-
-/* Perform operations requiring semaphore lock */
-
-err = os_sem_release(&g_os_sem);
-assert(err == OS_OK);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_sem_pend </font>
-
-```no-highlight
-os_error_t os_sem_pend(struct os_sem *sem, uint32_t timeout)
-```
-
-Wait for a semaphore for a given amount of time.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-| timeout | Amount of time, in os ticks, to wait for semaphore. A value of 0 means no wait. A value of 0xFFFFFFFF means wait forever. |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore acquired successfully.
-
-OS_TIMEOUT: the semaphore was not available within the timeout specified.
-
-OS_NOT_STARTED: Attempt to release a semaphore before os started.
-
-#### Notes
-
-If a timeout of 0 is used and the function returns OS_TIMEOUT, the semaphore was not available and was not acquired. No release of the semaphore should occur and the calling task does not own the semaphore.
-
-#### Example
-
-```no-highlight
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
-assert(err == OS_OK);
-
-/* Perform operations requiring semaphore lock */
-
-err = os_sem_release(&g_os_sem);
-assert(err == OS_OK);
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_sem_delete </font>
-
-```no-highlight
-os_error_t os_sem_delete(struct os_sem *sem)
-```
-
-Delete a semaphore
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore deleted successfully.
-
-OS_NOT_STARTED: Attempt to release a semaphore before os started.
-
-#### Notes
-
-Care must be taken when deleting a semaphore as deleting a semaphore used by other tasks could causes unexpected/unwanted behavior.
-
-#### Example
-
-```no-highlight
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_delete(&g_os_sem);
-assert(err == OS_OK);
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/task.md
----------------------------------------------------------------------
diff --git a/docs/os/task.md b/docs/os/task.md
deleted file mode 100644
index 00d3c34..0000000
--- a/docs/os/task.md
+++ /dev/null
@@ -1,140 +0,0 @@
-# Tasks
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [_clear_stack](#_clear_stack)
-* [os_task_next_id](#os_task_next_id)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> _clear_stack </font>
-
-```no-highlight
-static void
- _clear_stack(os_stack_t *stack_bottom, int size)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_task_next_id </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/time.md
----------------------------------------------------------------------
diff --git a/docs/os/time.md b/docs/os/time.md
deleted file mode 100644
index a749083..0000000
--- a/docs/os/time.md
+++ /dev/null
@@ -1,145 +0,0 @@
-# Time
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_time_get](#os_time_get)
-* [os_time_tick](#os_time_tick)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_time_get </font>
-
-```no-highlight
- os_time_t
- os_time_get(void)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_time_tick </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/packaging/dist.md
----------------------------------------------------------------------
diff --git a/docs/packaging/dist.md b/docs/packaging/dist.md
deleted file mode 100644
index e69de29..0000000
[5/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/semaphore/os_sem_release.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_release.md b/docs/os/core_os/semaphore/os_sem_release.md
new file mode 100644
index 0000000..c80e9b7
--- /dev/null
+++ b/docs/os/core_os/semaphore/os_sem_release.md
@@ -0,0 +1,42 @@
+## <font color="#F2853F" style="font-size:24pt"> os_sem_release </font>
+
+```no-highlight
+os_error_t os_sem_release(struct os_sem *sem)
+```
+
+Release a semaphore that you are holding. This adds a token to the semaphore.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *sem | Pointer to semaphore |
+
+#### Returned values
+
+OS_NOT_STARTED: Called before os has been started.
+
+OS_INVALID_PARM: returned when *sem is NULL on entry.
+
+OS_OK: semaphore released successfully.
+
+#### Notes
+
+
+#### Example
+
+```no-highlight
+struct os_sem g_os_sem;
+os_error_t err;
+
+err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
+assert(err == OS_OK);
+
+/* Perform operations requiring semaphore lock */
+
+err = os_sem_release(&g_os_sem);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/semaphore/semaphore.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/semaphore.md b/docs/os/core_os/semaphore/semaphore.md
new file mode 100644
index 0000000..b36a624
--- /dev/null
+++ b/docs/os/core_os/semaphore/semaphore.md
@@ -0,0 +1,43 @@
+# Semaphore
+
+A semaphore is a structure used for gaining exclusive access (much like a mutex), synchronizing task operations and/or use in a "producer/consumer" roles. Semaphores like the ones used by the myNewt OS are called "counting" semaphores as they are allowed to have more than one token (explained below).
+
+
+## Description
+
+A semaphore is a fairly simple construct consisting of a queue for waiting tasks and the number of tokens currently owned by the semaphore. A semaphore can be obtained as long as there are tokens in the semaphore. Any task can add tokens to the semaphore and any task can request the semaphore, thereby removing tokens. When creating the semaphore, the initial number of tokens can be set as well.
+
+When used for exclusive access to a shared resource the semaphore only needs a single token. In this case, a single task "creates" the semaphore by calling *os_sem_init* with a value of one (1) for the token. When a task desires exclusive access to the shared resource it requests the semaphore by calling *os_sem_pend*. If there is a token the requesting task will acquire the semaphore and continue operation. If no tokens are available the task will be put to sleep until there is a token. A common "problem" with using a semaphore for exclusive access is called *priority inversion*. Consider the following scenario: a high and low priority task both share a resource which is locked using a semaphore. If the low priority task obtains the semaphore and then the high priority task requests the semaphore, the high priority task is now blocked until the low priority task releases the semaphore. Now suppose that there are tasks between the low priority task and the high priority task that wa
nt to run. These tasks will preempt the low priority task which owns the semaphore. Thus, the high priority task is blocked waiting for the low priority task to finish using the semaphore but the low priority task cannot run since other tasks are running. Thus, the high priority tasks is "inverted" in priority; in effect running at a much lower priority as normally it would preempt the other (lower priority) tasks. If this is an issue a mutex should be used instead of a semaphore.
+
+Semaphores can also be used for task synchronization. A simple example of this would be the following. A task creates a semaphore and initializes it with no tokens. The task then waits on the semaphore, and since there are no tokens, the task is put to sleep. When other tasks want to wake up the sleeping task they simply add a token by calling *os_sem_release*. This will cause the sleeping task to wake up (instantly if no other higher priority tasks want to run).
+
+The other common use of a counting semaphore is in what is commonly called a "producer/consumer" relationship. The producer adds tokens (by calling *os_sem_release*) and the consumer consumes them by calling *os_sem_pend*. In this relationship, the producer has work for the consumer to do. Each token added to the semaphore will cause the consumer to do whatever work is required. A simple example could be the following: every time a button is pressed there is some work to do (ring a bell). Each button press causes the producer to add a token. Each token consumed rings the bell. There will exactly the same number of bell rings as there are button presses. In other words, each call to *os_sem_pend* subtracts exactly one token and each call to *os_sem_release* adds exactly one token.
+
+## Data structures
+
+```no-highlight
+struct os_sem
+{
+ SLIST_HEAD(, os_task) sem_head; /* chain of waiting tasks */
+ uint16_t _pad;
+ uint16_t sem_tokens; /* # of tokens */
+};
+```
+
+| Element | Description |
+|-----------|-------------|
+| sem_head | Queue head for list of tasks waiting on semaphore |
+| _pad | Padding for alignment |
+| sem_tokens | Current number of tokens |
+
+## List of Functions
+
+
+The functions available in semaphore are:
+
+* [os_sem_delete](os_sem_delete)
+* [os_sem_init](os_sem_init)
+* [os_sem_pend](os_sem_pend)
+* [os_sem_release](os_sem_release)
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/_clear_stack.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/_clear_stack.md b/docs/os/core_os/task/_clear_stack.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/os_task_count.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_count.md b/docs/os/core_os/task/os_task_count.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/os_task_info_get_next.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_info_get_next.md b/docs/os/core_os/task/os_task_info_get_next.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/os_task_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_init.md b/docs/os/core_os/task/os_task_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/os_task_next_id.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_next_id.md b/docs/os/core_os/task/os_task_next_id.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/os_task_sanity_checkin.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_sanity_checkin.md b/docs/os/core_os/task/os_task_sanity_checkin.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/task/task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/task.md b/docs/os/core_os/task/task.md
new file mode 100644
index 0000000..cc80328
--- /dev/null
+++ b/docs/os/core_os/task/task.md
@@ -0,0 +1,24 @@
+# Task
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe OS feature here
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+The functions available in task are:
+
+* [_clear_stack](_clear_stack.md)
+* [os_task_count](os_task_count.md)
+* [os_task_info_get_next](os_task_info_get_next.md)
+* [os_task_init](os_task_init.md)
+* [os_task_next_id](os_task_next_id.md)
+* [os_task_sanity_checkin](os_task_sanity_checkin.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/time/os_time_delay.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_delay.md b/docs/os/core_os/time/os_time_delay.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/time/os_time_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_get.md b/docs/os/core_os/time/os_time_get.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/time/os_time_tick.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_tick.md b/docs/os/core_os/time/os_time_tick.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/time/time.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/time.md b/docs/os/core_os/time/time.md
new file mode 100644
index 0000000..7de2b6a
--- /dev/null
+++ b/docs/os/core_os/time/time.md
@@ -0,0 +1,21 @@
+# Time
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe OS feature here
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+The functions available in time are:
+
+* [os_time_delay](os_time_delay.md)
+* [os_time_get](os_time_get.md)
+* [os_time_tick](os_time_tick.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/event_queue.md
----------------------------------------------------------------------
diff --git a/docs/os/event_queue.md b/docs/os/event_queue.md
deleted file mode 100644
index bfc69f8..0000000
--- a/docs/os/event_queue.md
+++ /dev/null
@@ -1,287 +0,0 @@
-# Event Queues
-
-
-Event queue is a way of serializing events arring to a task. This makes it easy to queue processing to happen inside task's context. This would be done either from an interrupt handler, or from another task.
-
-Events arrive in a form of a data structure *struct os_event*.
-
-## Description
-
-Events are in form of a data structure *struct os_event*, and they are queued to data structure *struct os_eventq*.
-
-Queue must be initialized before trying to add events to it. This is done using *os_eventq_init()*.
-
-Common way of using event queues is to have a task loop while calling *os_eventq_get()*, waiting for work to do.
-Other tasks (or interrupts) then call *os_eventq_put()* to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
-Processing task would then act according to event type.
-
-When *os_event* is queued, it should not be freed until processing task is done with it.
-
-It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular *os_eventq* at a time.
-
-Note that os_callout subsystem assumes that event queue is used as the wakeup mechanism.
-
-## Data structures
-
-```no-highlight
-struct os_event {
- uint8_t ev_queued;
- uint8_t ev_type;
- void *ev_arg;
- STAILQ_ENTRY(os_event) ev_next;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| ev_queued | Internal field, which tells whether event is linked into an *os_eventq* already |
-| ev_type | Type of an event. This should be unique, as it should be used by processing task to figure out what the event means |
-| ev_arg | Can be used further as input to task processing this event |
-| ev_next | Linkage attaching this event to an event queue |
-
-
-```no-highlight
-struct os_eventq {
- struct os_task *evq_task;
- STAILQ_HEAD(, os_event) evq_list;
-};
-```
-
-
-| Element | Description |
-|---------|-------------|
-| evq_task | Pointer to task if there is task sleeping on *os_eventq_get()* |
-| evq_list | Queue head for list of events in this queue |
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_eventq_init](#os_eventq_init)
-* [os_eventq_put](#os_eventq_put)
-* [os_eventq_put2](#os_eventq_put2)
-* [os_eventq_get](#os_eventq_get)
-* [os_eventq_remove](#os_eventq_remove)
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_eventq_init</font>
-
-```no-highlight
- void
- os_eventq_init(struct os_eventq *evq)
-```
-
-Initializes *struct os_eventq*, making it ready for use.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| evq | Pointer to event queue getting initialized |
-
-#### Returned values
-
-None
-
-#### Notes
-
-Usually done at subsystem init time; before OS has been started, and before interrupts generating events have been enabled.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This initializes event queue used by newtmgr task.
-
-
-```no-highlight
-struct os_eventq g_nmgr_evq;
-
-int
-nmgr_task_init(uint8_t prio, os_stack_t *stack_ptr, uint16_t stack_len)
-{
- /* variable declarations here */
-
- os_eventq_init(&g_nmgr_evq);
-
- /* initialization continues here */
-}
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_put</font>
-
-```no-highlight
-void
-os_eventq_put(struct os_eventq *evq, struct os_event *ev)
-```
-
-Queues an event to tail of the event queue.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| evq | Queue where event is being placed |
-| ev | Event which is being queued |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Functionality is of *os_eventq_put2()*, but this is to be called from a task context only.
-
-#### Example
-
-<Add text to set up the context for the example here>
-This is used to pass info about an event to a task handling it.
-
-```no-highlight
- /* Get an event structure off the queue */
- ev = (struct os_event *)os_memblock_get(&g_hci_os_event_pool);
- if (!ev) {
- err = os_memblock_put(&g_hci_cmd_pool, hci_ev);
- assert(err == OS_OK);
- return -1;
- }
-
- /* Fill out the event and post to Link Layer */
- ev->ev_queued = 0;
- ev->ev_type = BLE_HOST_HCI_EVENT_CTLR_EVENT;
- ev->ev_arg = hci_ev;
- os_eventq_put(&ble_hs_evq, ev);
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_put2</font>
-
-```no-highlight
-void
-os_eventq_put2(struct os_eventq *evq, struct os_event *ev, int isr)
-```
-
-Queues an event to tail of the event queue.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| evq | Queue where event is being placed |
-| ev | Event which is being queued |
-| isr | Tells whether call is being made from within interrupt handler or not |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-If the event has already been queued, nothing happens. Including event's relative position within the queue itself.
-
-This can be called either from interrupt handler (in which case *isr* should be set to 1), or from another task context (in which case *isr should be set as 0).
-
-#### Example
-
-This wakes up the task waiting on task1_evq, which processes console input (console input comes from UART, and is passed in in interrupt context).
-
-```no-highlight
-static void
-my_cons_input(int full_line)
-{
- os_eventq_put2(&task1_evq, &cons_ev, 1);
-}
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_get</font>
-
-```no-highlight
-void
-os_eventq_get(struct os_eventq *evq)
-```
-
-Fetches the first event from a queue. Task will sleep until something gets queued.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| evq | Queue to wait on |
-
-
-#### Returned values
-
-Will return with a pointer to first *struct event* which is in the queue.
-
-#### Notes
-
-
-#### Example
-
-Main loop of an example task.
-
-```no-highlight
- while (1) {
- ev = os_eventq_get(&task1_evq);
- assert(ev);
- if (ev->ev_type == CONS_EV_TYPE) {
- /* XXX do stuff */
- }
- }
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_remove</font>
-
-```no-highlight
-void
-os_eventq_remove(struct os_eventq *evq, struct os_event *ev)
-```
-
-Removes an event which has been placed in a queue.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| evq | Queue where event is being removed from |
-| ev | Event which is being removed |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This is from os_callout_stop(). User wants to stop a callout from getting passed to a task. If the event has already been queued, then remove it before it is seen.
-
-```no-highlight
- if (c->c_evq) {
- os_eventq_remove(c->c_evq, &c->c_ev);
- }
-```
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_acclimated/pics/STM32f3discovery_connector.png
----------------------------------------------------------------------
diff --git a/docs/os/get_acclimated/pics/STM32f3discovery_connector.png b/docs/os/get_acclimated/pics/STM32f3discovery_connector.png
new file mode 100644
index 0000000..1f4437a
Binary files /dev/null and b/docs/os/get_acclimated/pics/STM32f3discovery_connector.png differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_acclimated/project2.md
----------------------------------------------------------------------
diff --git a/docs/os/get_acclimated/project2.md b/docs/os/get_acclimated/project2.md
new file mode 100644
index 0000000..23cf001
--- /dev/null
+++ b/docs/os/get_acclimated/project2.md
@@ -0,0 +1,380 @@
+## Project 2 - Blinky on additional boards
+
+### Objective
+
+The goal of this tutorial is to download a generic firmware skeleton ("bootstrap image") that applies to any hardware and then throw in additional applicable eggs to generate a build for a specific board. In the process you will be exposed to more Mynewt terms and Newt tool commands.
+
+The following target hardware chips are covered:
+
+* [STM32F303VC MCU](#stm32f303vc-mcu) from STMicroelectronics
+* [nRF52 Series](#nrf52-series) from Nordic Semiconductors
+
+
+### STM32F303VC MCU
+
+#### Hardware needed
+
+* Discovery kit with STM32F303VC MCU
+* Laptop running Mac OS
+
+
+#### Step by Step Instructions to build image
+
+* The first step is to download the generic skeleton of the project. The eggs constituting the skeleton are not hardware architecture specific. The skeleton is maintained as a nest in a separate repository on Apache. You know it is a nest because there is a nest.yml file.
+
+```no-highlight
+ [user:~/dev]$ newt nest create test_project
+ Downloading nest skeleton from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole.git... ok!
+ Nest test_project successfully created in ~/dev/go/test_project
+
+ [user:~/dev]$ cd test_project/
+ [user:~/dev/test_project]$ ls
+ README.md compiler hw libs nest.yml
+```
+
+* Next, the clutch of eggs named larva is added from the nest (also named larva) from another repository on Apache. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
+```no-highlight
+ [user:~/dev/test_project]$ newt nest add-clutch larva https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
+ Downloading clutch.yml from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git/master... ok!
+ Verifying clutch.yml format...
+ ok!
+ Clutch larva successfully installed to Nest.
+```
+
+* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
+
+```no-highlight
+
+ [user:~/dev/test_project]$ newt egg install project/blinky
+ Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
+ Installing project/blinky
+ Installing libs/console/full
+ Installing libs/shell
+ Installation was a success!
+
+ [user:~/dev/test_project]$ newt egg install hw/bsp/stm32f3discovery
+ Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
+ Installing hw/bsp/stm32f3discovery
+ Installing hw/mcu/stm/stm32f3xx
+ Installing libs/cmsis-core
+ Installing compiler/arm-none-eabi-m4
+ Installation was a success!
+```
+
+* It's time to create a target for the project and define the target attributes.
+```no-highlight
+ [user:~/dev/test_project]$ newt target create blink_f3disc
+ Creating target blink_f3disc
+ Target blink_f3disc successfully created!
+
+ [user:~/dev/test_project]$ newt target set blink_f3disc project=blinky
+ Target blink_f3disc successfully set project to blinky
+
+ [user:~/dev/test_project]$ newt target set blink_f3disc bsp=hw/bsp/stm32f3discovery
+ Target blink_f3disc successfully set bsp to hw/bsp/stm32f3discovery
+
+ [user:~/dev/test_project]$ newt target set blink_f3disc compiler_def=debug
+ Target blink_f3disc successfully set compiler_def to debug
+
+ [user:~/dev/test_project]$ newt target set blink_f3disc compiler=arm-none-eabi-m4
+ Target blink_f3disc successfully set compiler to arm-none-eabi-m4
+
+ [user:~/dev/test_project]$ newt target set blink_f3disc arch=cortex_m4
+ Target blink_f3disc successfully set arch to cortex_m4
+
+ [user:~/dev/test_project]$ newt target show blink_f3disc
+ blink_f3disc
+ arch: cortex_m4
+ project: blinky
+ bsp: hw/bsp/stm32f3discovery
+ compiler_def: debug
+ compiler: arm-none-eabi-m4
+ name: blink_f3disc
+```
+* Next, you get to build the target and generate an executable that can then be uploaded to the board. The STM32F3DISCOVERY board includes an ST-LINK/V2 embedded debug tool interface that will be used to program/debug the board. To program the MCU on the board, simply plug in the two jumpers on CN4, as shown in the picture in red. If you want to learn more about the board you will find the User Manual at [http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf](http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf)
+
+* 
+
+```no-highlight
+ [user:~/dev/test_project]$ newt target build blink_f3disc
+ Building target blink_f3disc (project = blinky)
+ Compiling case.c
+ Compiling suite.c
+ Compiling testutil.c
+ Compiling testutil_arch_arm.c
+ Archiving libtestutil.a
+ Compiling os.c
+ Compiling os_callout.c
+ Compiling os_eventq.c
+ Compiling os_heap.c
+ Compiling os_mbuf.c
+ Compiling os_mempool.c
+ Compiling os_mutex.c
+ Compiling os_sanity.c
+ Compiling os_sched.c
+ Compiling os_sem.c
+ Compiling os_task.c
+ Compiling os_time.c
+ Compiling os_arch_arm.c
+ Assembling HAL_CM4.s
+ Assembling SVC_Table.s
+ Archiving libos.a
+ Compiling hal_gpio.c
+ Compiling stm32f3xx_hal_gpio.c
+ Archiving libstm32f3xx.a
+ Compiling cmsis_nvic.c
+ Compiling libc_stubs.c
+ Compiling os_bsp.c
+ Compiling sbrk.c
+ Compiling system_stm32f3xx.c
+ Assembling startup_stm32f303xc.s
+ Archiving libstm32f3discovery.a
+ Compiling main.c
+ Building project blinky
+ Linking blinky.elf
+ Successfully run!
+```
+
+* Finally, you have to download the image on to the board. You will see a blue light start to blink.
+```no-highlight
+ [user:~/dev/test_project]$ newt target download blink_f3disc
+ Downloading with /Users/user/dev/test_project/hw/bsp/stm32f3discovery/stm32f3discovery_download.sh
+```
+
+
+### nRF52 Series
+
+
+#### Hardware needed
+
+* nRF52 Development Kit
+* Laptop running Mac OS
+
+
+#### Step by Step Instructions to build image
+
+* The first step is to download the generic skeleton of the project. The eggs installed are not hardware architecture specific.
+```no-highlight
+ []user@~/dev]$ newt nest create nordic_blinky
+ Downloading nest skeleton from https://www.github.com/mynewt/tadpole... ok!
+ Nest nordic_blinky successfully created in ~dev/nordic_blinky
+
+ user@~/dev$ cd nordic_blinky/
+```
+
+* Then, the clutch of eggs named larva is added from the nest (also named larva) on the github. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
+```no-highlight
+ []user@~/dev/nordic_blinky]$ newt nest add-clutch larva https://github.com/mynewt/larva
+ Downloading clutch.yml from https://github.com/mynewt/larva/master... ok!
+ Verifying clutch.yml format...ok!
+ Clutch larva successfully installed to Nest.
+```
+* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
+```no-highlight
+ [user@~/dev/nordic_blinky]$ newt egg install project/blinky
+ Downloading larva from https://github.com/mynewt/larva//master... ok!
+ Installing project/blinky
+ Installation was a success!
+
+
+ [user@~/dev/nordic_blinky]$ newt egg install hw/bsp/nrf52pdk
+ Downloading larva from https://github.com/mynewt/larva//master... ok!
+ Installing hw/bsp/nrf52pdk
+ Installing hw/mcu/nordic/nrf52xxx
+ Installing libs/cmsis-core
+ Installing compiler/arm-none-eabi-m4
+ Installation was a success!
+```
+
+* It's time to create a target for the project and define the target attributes.
+```no-highlight
+ [user@~/dev/nordic_blinky]$ newt target create blink_nordic
+ Creating target blink_nordic
+ Target blink_nordic successfully created!
+ [user@~/dev/nordic_blinky]$ newt target set blink_nordic project=blinky
+ Target blink_nordic successfully set project to blinky
+ [user@~/dev/nordic_blinky]$ newt target set blink_nordic bsp=hw/bsp/nrf52pdk
+ Target blink_nordic successfully set bsp to hw/bsp/nrf52pdk
+ [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler_def=debug
+ Target blink_nordic successfully set compiler_def to debug
+ [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler=arm-none-eabi-m4
+ Target blink_nordic successfully set compiler to arm-none-eabi-m4
+ [user@~/dev/nordic_blinky]$ newt target set blink_nordic arch=cortex_m4
+ Target blink_nordic successfully set arch to cortex_m4
+ [user@~/dev/nordic_blinky]$ newt target show
+ blink_nordic
+ compiler: arm-none-eabi-m4
+ name: blink_nordic
+ arch: cortex_m4
+ project: blinky
+ bsp: hw/bsp/nrf52pdk
+ compiler_def: debug
+```
+
+* Finally, you get to build the target and generate an executable that can now be uploaded to the board via the on-board SEGGER J-Link debugger.
+```no-highlight
+ [user@~/dev/nordic_blinky]$ newt target build blink_nordic
+ Building target blink_nordic (project = blinky)
+ Compiling case.c
+ Compiling suite.c
+ Compiling testutil.c
+ Compiling testutil_arch_arm.c
+ Archiving libtestutil.a
+ Compiling os.c
+ Compiling os_callout.c
+ Compiling os_eventq.c
+ Compiling os_heap.c
+ Compiling os_mbuf.c
+ Compiling os_mempool.c
+ Compiling os_mutex.c
+ Compiling os_sanity.c
+ Compiling os_sched.c
+ Compiling os_sem.c
+ Compiling os_task.c
+ Compiling os_time.c
+ Compiling os_arch_arm.c
+ Assembling HAL_CM4.s
+ Assembling SVC_Table.s
+ Archiving libos.a
+ Compiling hal_cputime.c
+ Compiling hal_gpio.c
+ Compiling hal_uart.c
+ Archiving libnrf52xxx.a
+ Compiling cmsis_nvic.c
+ Compiling hal_bsp.c
+ Compiling libc_stubs.c
+ Compiling os_bsp.c
+ Compiling sbrk.c
+ Compiling system_nrf52.c
+ Assembling gcc_startup_nrf52.s
+ Archiving libnrf52pdk.a
+ Compiling main.c
+ Building project blinky
+ Linking blinky.elf
+ Successfully run!
+```
+* In order to be able to communicate with the SEGGER J-Link debugger on the dev board, you have to download and install the J-Link GDB Server software on to your laptop. You may download the "Software and documentation pack for Mac OS X" from [https://www.segger.com/jlink-software.html](https://www.segger.com/jlink-software.html). The command line version of the server is used in the steps below.
+
+* Open a new terminal and start a J-Link session.
+```no-highlight
+ [user@~/dev/nordic_blinky/project/blinky/bin]$ which JLinkGDBServer
+ /usr/local/bin/JLinkGDBServer
+ [user@~/dev/nordic_blinky/project/blinky/bin]$ JLinkGDBServer -if SWD
+ SEGGER J-Link GDB Server V5.02f Command Line Version
+
+ JLinkARM.dll V5.02f (DLL compiled Oct 2 2015 20:55:03)
+
+ -----GDB Server start settings-----
+ GDBInit file: none
+ GDB Server Listening port: 2331
+ SWO raw output listening port: 2332
+ Terminal I/O port: 2333
+ Accept remote connection: yes
+ Generate logfile: off
+ Verify download: off
+ Init regs on start: off
+ Silent mode: off
+ Single run mode: off
+ Target connection timeout: 0 ms
+ ------J-Link related settings------
+ J-Link Host interface: USB
+ J-Link script: none
+ J-Link settings file: none
+ ------Target related settings------
+ Target device: unspecified
+ Target interface: SWD
+ Target interface speed: 1000kHz
+ Target endian: little
+
+ Connecting to J-Link...
+ J-Link is connected.
+ Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Aug 28 2015 19:26:24
+ Hardware: V1.00
+ S/N: 682371959
+ Checking target voltage...
+ Target voltage: 3.30 V
+ Listening on TCP/IP port 2331
+ Connecting to target...Connected to target
+ Waiting for GDB connection...Connected to 127.0.0.1
+```
+
+* You need a configuration file for the GDB session to be opened correctly and the image ("blinky.elf") you built for this target downloaded to flash. A sample config script is given below. Alternatively, you could choose to type each command at the gdb prompt.
+```no-highlight
+ [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ cat jlink-gdb.cfg
+ echo ***Setting up the environment for debugging gdb.***\n
+ set complaints 1
+ set prompt (gdb)
+ set endian little
+ echo \n*** Set target charset ASCII\n
+ set target-charset ASCII
+ echo \n*** Connecting over port #2331 ***\n
+ target remote localhost:2331
+ echo \n*** Enable flash write and set device to nrf52 ***\n
+ monitor flash download=1
+ monitor flash device=nRF52
+ echo \n*** loading blinky.elf ***\n
+ load ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
+ symbol-file ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
+ echo \n*** Resetting target ***\n
+ monitor reset
+ echo \n*** Halting target ***\n
+ monitor halt
+```
+* Start the gdb session and monitor that it loads the image, resets the target, and halts for a command to continue.
+```no-highlight
+ [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ arm-none-eabi-gdb -x ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/jlink-gdb.cfg
+
+ GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+ and "show warranty" for details.
+ This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
+ Type "show configuration" for configuration details.
+ For bug reporting instructions, please see:
+ <http://www.gnu.org/software/gdb/bugs/>.
+ Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+ For help, type "help".
+ Type "apropos word" to search for commands related to "word".
+
+ ***Setting up the environment for debugging gdb.***
+ The target is assumed to be little endian
+
+ *** Set target charset ASCII
+
+ *** Connecting over port #2331 ***
+ 0x00003c34 in ?? ()
+
+ *** Enable flash write and set device to nrf52 ***
+ Flash download enabled
+ Selecting device: nRF52
+
+ *** loading blinky.elf ***
+ Loading section .text, size 0x5c84 lma 0x0
+ Loading section .ARM.extab, size 0x24 lma 0x5c84
+ Loading section .ARM.exidx, size 0xd8 lma 0x5ca8
+ Loading section .data, size 0x8f8 lma 0x5d80
+ Start address 0x48c, load size 26232
+ Transfer rate: 12808 KB/sec, 2914 bytes/write.
+ During symbol reading, unexpected overlap between:
+ (A) section `.text' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x5c84)
+ (B) section `*COM*' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x0).
+ Will ignore section B.
+
+ *** Resetting target ***
+ Resetting target
+
+ *** Halting target ***
+```
+* Type 'c' to continue. The LED on the board will start to blink. You will also see some activity in the terminal showing the open J-Link GDB server connection. The LED will continue to blink after you quit out of that connection.
+```no-highlight
+ (gdb) c
+ Continuing.
+```
+
+
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_acclimated/project3.md
----------------------------------------------------------------------
diff --git a/docs/os/get_acclimated/project3.md b/docs/os/get_acclimated/project3.md
new file mode 100644
index 0000000..43e6a59
--- /dev/null
+++ b/docs/os/get_acclimated/project3.md
@@ -0,0 +1 @@
+## How to Test an Egg
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/how_to_edit_docs.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/how_to_edit_docs.md b/docs/os/get_started/how_to_edit_docs.md
new file mode 100644
index 0000000..2c30f3e
--- /dev/null
+++ b/docs/os/get_started/how_to_edit_docs.md
@@ -0,0 +1,187 @@
+## How to Edit Docs
+
+### Objective
+
+We will go through the process of downloading existing doccumentation and adding some content to a test document.
+
+### Markdown, MkDocs, Mou
+
+The Mynewt documentation you see on the Apache incubator website is a bunch of HTML files generated using MkDocs which is a simple static site generation tool geared towards building project documentation. You can read about it at [http://www.mkdocs.org](http://www.mkdocs.org). Documentation source files are written in Markdown, and configured with a single YAML configuration file. Markdown is a lightweight markup language with plain text formatting syntax designed so that it can be converted to HTML and many other formats using a tool (which in our case is MkDocs).
+
+You do not need to install MkDocs unless you want to actually render your documentation in HTML in order to preview it before pushing your content to the remote repository. Typically, using a Markdown editor such as [Mou](http://25.io/mou/) is enough to check how it will look after the document has gone through MkDocs. Go ahead and download [Mou](http://25.io/mou/). If you are on a Windows machine, download the [editor of your choice](http://alternativeto.net/software/mou/?platform=windows).
+
+Currently someone in the project is designated to use MkDocs to generate the HTML pages periodically after changes have been reviewed and accepted into the master branch.
+
+
+### Access to the Apache repo
+
+Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
+
+If you are not a committer, you may follow the proposed non-committer workflow to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html). You will find the steps described in more detail later in this tutorial.
+
+### Making a local copy
+
+* Copy the document source files into a local directory and look at the contents of the copied directory to get an idea of the directory structure. Use http instead of https if you are a non-committer.
+```no-highlight
+ $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git
+ Cloning into 'incubator-mynewt-site'...
+ remote: Counting objects: 330, done.
+ remote: Compressing objects: 100% (263/263), done.
+ remote: Total 330 (delta 120), reused 0 (delta 0)
+ Receiving objects: 100% (330/330), 4.34 MiB | 830.00 KiB/s, done.
+ Resolving deltas: 100% (120/120), done.
+ Checking connectivity... done.
+ $ ls
+ incubator-mynewt-site
+ $ ls incubator-mynewt-site/
+ docs images mkdocs.yml
+```
+* Create a new branch to work on your documentation and move to that branch.
+```no-highlight
+ $ git checkout -b <your-branch-name>
+```
+
+### File to be edited
+
+The file you will edit is [try_markdown.md](./try_markdown.md).
+
+### Editing an existing page
+
+* Open the application Mou.
+
+* Open the file incubator-mynewt-site/docs/get_started/try_markdown.md in Mou.
+
+* Edit the last item on the list.
+
+* Save and quit the application.
+
+You may want to review the documentation organization back in [Home](../../index.md) to remind you how to locate files easily. The corresponding directory tree structure is shown below.
+```no-highlight
+ .
+ ├── docs
+ │ ├── get_started
+ │ │ ├── how_to_edit_docs.md
+ │ │ ├── newt_concepts.md
+ │ │ ├── pics
+ │ │ │ ├── bottomview.png
+ │ │ │ └── topview.png
+ │ │ ├── project1.md
+ │ │ └── try_markdown.md
+ │ ├── get_acclimated
+ │ │ ├── project2.md
+ │ │ ├── project3.md
+ │ │ ├── ... (more to be added)
+ │ │ └── vocabulary.md
+ │ ├── newt
+ │ │ ├── newt_ops.md
+ │ │ └── newt_tool_reference.md
+ │ ├── os
+ │ │ ├── context_switch.md
+ │ │ ├── event_queue.md
+ │ │ ├── heap.md
+ │ │ ├── mbufs.md
+ │ │ ├── memory_pool.md
+ │ │ ├── mutex.md
+ │ │ ├── mynewt_os.md
+ │ │ ├── port_os.md
+ │ │ ├── sanity.md
+ │ │ ├── semaphore.md
+ │ │ ├── task.md
+ │ │ ├── time.md
+ │ │ └── ... (more to be added)
+ │ ├── modules
+ │ │ ├── bootloader.md
+ │ │ ├── console.md
+ │ │ ├── filesystem.md
+ │ │ ├── shell.md
+ │ │ ├── testutil.md
+ │ │ └── ... (more to be added)
+ │ ├── packaging
+ │ │ ├── dist.md
+ │ │ └── ... (more to be added)
+ │ ├── extra.css
+ │ ├── images
+ │ │ └── egg-logo.png
+ │ └── index.md
+ ├── images
+ │ ├── asf_logo_wide.gif
+ │ ├── content-bg.png
+ │ └── egg-logo.png
+ ├── mkdocs.yml
+```
+
+### Adding a new page
+
+If you create a new file somewhere in the `docs` subdirectory to add a new page, you have to add a line in the `mkdocs.yml` file at the correct level. For example, if you add a new module named "Ethernet" by creating a new file named `ethernet.md` in the `modules` subdirectory, you have to insert the following line under `Modules:` in the `mkdocs.yml` file.
+```no-highlight
+ - 'Ethernet': 'modules/ethernet.md'
+```
+### Pushing changes to remote as a committer
+
+If you are not a committer yet, skip this section and proceed to the [next section](#sharing-changes-as-a-non-committer).
+
+* Check whether your remote git repository is set up. If you see the remote location as shown below you can skip the next step.
+```no-highlight
+ $ git remote -v
+ origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (fetch)
+ origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (push)
+```
+* If, however, you do not see your remote repository, then set it up as follows.
+
+```no-highlight
+ $ git remote add origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git
+```
+* First check the git status. It will show you that the `try_markdown.md` document has been modified. So you will stage a commit, and then commit the change. Finally, you will push the changes to the remote repository.
+
+ During staging below using `git add`, we use the `-A` option indicating you want to stage all your modifications. Instead, you can choose to specify only the files that you want to. The commit message (specified after `-m`) should summarize what your changes are about.
+```no-highlight
+ $ git status
+ $ git add -A
+ $ git commit -m "My first doc change as a trial run"
+ $ git push -u origin <your-branch-name>
+```
+* You can see the changed Markdown file if you traverse the tree on the git repository [ https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git]( https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git).
+
+* A commit notification automatically goes out to the commits@mynewt.incubator.apache.org mailing list. The "upstream" manager pulls the notified changes, reviews it, and merges it to the master branch if all is well. Otherwise you get an email for further changes.
+
+### Sharing changes as a non-committer
+
+We suggest you follow the proposed non-committer workflow at Apache to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html).
+
+* Assuming you have made changes to the example file, you will first commit your changes.
+```no-highlight
+ $ git add -A
+ $ git commit -m "My first doc change as a trial run"
+```
+* Once you're ready to share your changes with the rest of the project team, you can use the git format-patch command to produce a patch file (or a nice set of patches in the future):
+```no-highlight
+ $ git format-patch origin/trunk
+```
+* Email the patch file to dev@mynewt.incubator.apache.org. Later on you may attach multiple files in your email to the mailing list as part of an existing thread or a new one. Remember to summarize the issue you have tackled and your work if the commit message is not detailed enough.
+
+ If there is a JIRA ticket associated with your work you should post your patch files to the ticket.
+
+
+### Conversion to HTML
+
+The conversion of the Markdown files to HTML for the website happens manually and statically using MkDocs. You cannot see automatic and immediate rendering in HTML upon making a change in the Markdown file. You can choose to stop here and proceed to changing other Markdown files in your branch.
+
+### Local preview of HTML files
+
+However, you have the option to download MkDocs and do a local conversion yourself to preview the pages using the built-in devserver that comes with MkDocs. But first you will have to install MkDocs for that. In order to install MkDocs you'll need Python installed on your system, as well as the Python package manager, pip. You can check if you have them already (usually you will).
+```no-highlight
+ $ python --version
+ Python 2.7.2
+ $ pip --version
+ pip 1.5.2
+ $ pip install mkdocs
+```
+You will then run the built-in webserver from the root of the documentation directory using the command `mkdocs serve`. The root directory for documentation is `incubator-mynewt-site` or the directory with the `mkdocs.yml` file.
+```no-highlight
+ $ ls
+ docs images mkdocs.yml
+ $ mkdocs serve
+```
+Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website! Remember that the Myself website itself will not be updated.
+
+For more information on MkDocs go to [http://www.mkdocs.org](http://www.mkdocs.org).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/newt_concepts.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/newt_concepts.md b/docs/os/get_started/newt_concepts.md
new file mode 100644
index 0000000..6ac28da
--- /dev/null
+++ b/docs/os/get_started/newt_concepts.md
@@ -0,0 +1,48 @@
+## Newt Concepts
+
+This page introduces the basic terms you will need to find your way around the Mynewt ecosystem.
+
+### Basic components in the ecosystem
+
+* NewtOS is an open-source RTOS (Real Time Operating System) that works on a variety of hardware. The goal is to develop a pre-emptive, multitasking OS that is highly modular, making it possible to mix and match components to enable desired features and capabilities on multiple hardware architectures. Examples of components being worked on are the Core RTOS, a flash file system, utility functions, a variety of board support packages, packages of microcontrollers etc.
+
+
+* Network protocol stacks such as Bluetooth Low Energy, and more
+
+
+* Newt Tool helps you mix the specific packages for the combination of hardware and low-level embedded architecture features of the user's choice and generate the corresponding run-time image based on the NewtOS. It provides the infrastructure to manage and build for different CPU architectures, memory units, board support packages etc., allowing a user to formulate the contents according to the low-level features needed by his or her project.
+
+
+### Terminology
+
+A Mynewt user starts with a project in mind that defines the application or utility that he or she wants to implement on an embedded device. Making an LED blink on an electronics prototyping board is a common starter project. Enabling a BLE (Bluetooth Low Energy) peripheral mode on a development board is a more complex project. Specifying a project requires naming it, at the very least, and then adding the desired properties or attributes. In order to actualize a project, it needs to be applied to a target which is essentially a combination of some specified hardware and the execution environment.
+
+In the mynewt lifecycle, a project grows in a nest. A nest may house multiple projects. The nest is, therefore, a repository where various component packages for one or more projects reside. Each package is an egg (naturally!). However, in the world of Mynewt an egg may consist of other eggs! For example, the starter project Blinky is an egg consisting of several constituent eggs that enable core features. The egg form is suitable for elemental units of code as it explicitly exposes characteristics such as dependencies, versions, capabilities, requirements etc., thus making assembling appropriate components for a project and building an image for it easy to follow, modular, and robust.
+
+A nest can be given any name. For example, you will see a nest named "tadpole" in Mynewt ([https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git](https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git)). It contains all the core libraries of the operating system for the native platform which currently supports compilation on Mac OS X. The core libraries are contained in the form of eggs where an egg is a basic unit of implementation of any aspect of the RTOS. The eggs are distributed in the following directory structure inside the nest:
+
+* libs: contains the two eggs `os` and `testutil`
+* hw: contains three eggs - (i) `hal` which has the abstraction layer (HAL) API definitions that all BSP and MCU implementations must support, (ii) `/mcu/native` which in an MCU implementation for the native platform (a simulator, in this case), and (iii) `bsp/native` which is a BSP implementation for the native platform
+* compiler: contains the `sim` egg which bundles the compiler specifications for the native platform.
+
+Let's explore this sample nest a bit further. The `libs/os` egg contains code for scheduler, process/thread/memory management, semaphores etc. It is the core RTOS which ports to all supported chip platforms.The `libs/testutil` egg contains code for testing packages on hardware or simulated environment. The `hw/hal` egg contains header files that provide abstraction for physical hardware components such as GPIO (general purpose input/output), network adapters, timers, and UARTs. This `hw/hal` egg is an MCU peripheral abstraction designed to make it easy to port to different MCUs (microcontrollers). The `hw/mcu/native` egg contains code for microcontroller operations on the native platform. The `hw/bsp/native` egg contains the board support package for the native platform. And finally, the sixth egg `sim` contains the compiler specifications such as path and flags. Currently the compilation is supported on Mac OS X.
+
+You can see another nest in the mynewt ecosystem called the "larva". It was spawned from the skeletal "tadpole" nest using the newt tool. Spawning is easy - ` $ newt create nest <your_nest_name> `. "larva" is the developer's test repository containing all sorts of eggs being written and incubated, including ones to enhance the core operating system which should eventually make their way into the "tadpole" nest. There is a `hatch_tadpole` script to update the "tadpole" nest when the core OS related eggs in "larva" are ready.
+
+There is a third nest named "newt" that contains all the eggs needed to support the build and release process of mynewt software. In the future, there will also be pre-built nests for certain common hardware devices to enable a user to quickly get started with a project.
+
+
+### A Mynewt contributor
+
+A contributor can choose to work on any area(s) of the Mynewt endeavor that appeals to him or her. Hence, you can work on one or more eggs or an entire nest. You can create your own nest (master) or create a branch in an existing nest. For now, Runtime contributors will review any new areas of support that you may wish to introduce e.g. a new board support package (BSP) or a new network protocol.
+
+A contributer role necessarily implies he or she is a Mynewt user (see below) of some or all of the products developed.
+
+### A Mynewt user
+
+An application developer is interested only in using software available in this ecosystem to build a top level build artifact. He or she may either:
+
+* Use a pre-built nest, or
+* Spawn a new nest using the newt tool for a target where a target is a custom combination of supported hardware components
+
+In either case, the user would use the newt tool to create and set the target in the chosen nest. The newt tool would then be used to build out the target profile which would determine which eggs to choose. Finally, the user would use the newt tool to generate a run-time image that can be run on the device.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/pics/bottomview.png
----------------------------------------------------------------------
diff --git a/docs/os/get_started/pics/bottomview.png b/docs/os/get_started/pics/bottomview.png
new file mode 100644
index 0000000..fb7bf0a
Binary files /dev/null and b/docs/os/get_started/pics/bottomview.png differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/pics/topview.png
----------------------------------------------------------------------
diff --git a/docs/os/get_started/pics/topview.png b/docs/os/get_started/pics/topview.png
new file mode 100644
index 0000000..e57995e
Binary files /dev/null and b/docs/os/get_started/pics/topview.png differ
[3/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_build_status_one.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_build_status_one.md b/docs/os/modules/bootloader/boot_build_status_one.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_clear_status.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_clear_status.md b/docs/os/modules/bootloader/boot_clear_status.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_copy_area.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_copy_area.md b/docs/os/modules/bootloader/boot_copy_area.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_copy_image.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_copy_image.md b/docs/os/modules/bootloader/boot_copy_image.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_erase_area.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_erase_area.md b/docs/os/modules/bootloader/boot_erase_area.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_fill_slot.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_fill_slot.md b/docs/os/modules/bootloader/boot_fill_slot.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_find_image_area_idx.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_find_image_area_idx.md b/docs/os/modules/bootloader/boot_find_image_area_idx.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_find_image_part.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_find_image_part.md b/docs/os/modules/bootloader/boot_find_image_part.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_find_image_slot.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_find_image_slot.md b/docs/os/modules/bootloader/boot_find_image_slot.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_go.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_go.md b/docs/os/modules/bootloader/boot_go.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_init_flash.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_init_flash.md b/docs/os/modules/bootloader/boot_init_flash.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_move_area.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_move_area.md b/docs/os/modules/bootloader/boot_move_area.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_read_image_header.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_read_image_header.md b/docs/os/modules/bootloader/boot_read_image_header.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_read_image_headers.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_read_image_headers.md b/docs/os/modules/bootloader/boot_read_image_headers.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_read_status.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_read_status.md b/docs/os/modules/bootloader/boot_read_status.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_select_image_slot.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_select_image_slot.md b/docs/os/modules/bootloader/boot_select_image_slot.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_slot_addr.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_slot_addr.md b/docs/os/modules/bootloader/boot_slot_addr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_slot_to_area_idx.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_slot_to_area_idx.md b/docs/os/modules/bootloader/boot_slot_to_area_idx.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_swap_areas.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_swap_areas.md b/docs/os/modules/bootloader/boot_swap_areas.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_vect_delete_main.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_vect_delete_main.md b/docs/os/modules/bootloader/boot_vect_delete_main.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_vect_delete_test.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_vect_delete_test.md b/docs/os/modules/bootloader/boot_vect_delete_test.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_vect_read_main.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_vect_read_main.md b/docs/os/modules/bootloader/boot_vect_read_main.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_vect_read_one.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_vect_read_one.md b/docs/os/modules/bootloader/boot_vect_read_one.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_vect_read_test.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_vect_read_test.md b/docs/os/modules/bootloader/boot_vect_read_test.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_write_status.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_write_status.md b/docs/os/modules/bootloader/boot_write_status.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/bootloader.md b/docs/os/modules/bootloader/bootloader.md
new file mode 100644
index 0000000..fd4bc8e
--- /dev/null
+++ b/docs/os/modules/bootloader/bootloader.md
@@ -0,0 +1,46 @@
+# Bootloader
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+
+The functions available in bootloader are:
+
+* [boot_build_status](boot_build_status.md)
+* [boot_build_status_one](boot_build_status_one.md)
+* [boot_clear_status](boot_clear_status.md)
+* [boot_copy_area](boot_copy_area.md)
+* [boot_copy_image](boot_copy_image.md)
+* [boot_erase_area](boot_erase_area.md)
+* [boot_fill_slot](boot_fill_slot.md)
+* [boot_find_image_area_idx](boot_find_image_area_idx.md)
+* [boot_find_image_part](boot_find_image_part.md)
+* [boot_find_image_slot](boot_find_image_slot.md)
+* [boot_go](boot_go.md)
+* [boot_init_flash](boot_init_flash.md)
+* [boot_move_area](boot_move_area.md)
+* [boot_read_image_header](boot_read_image_header.md)
+* [boot_read_image_headers](boot_read_image_headers.md)
+* [boot_read_status](boot_read_status.md)
+* [boot_select_image_slot](boot_select_image_slot.md)
+* [boot_slot_addr](boot_slot_addr.md)
+* [boot_slot_to_area_idx](boot_slot_to_area_idx.md)
+* [boot_swap_areas](boot_swap_areas.md)
+* [boot_vect_delete_main](boot_vect_delete_main.md)
+* [boot_vect_delete_test](boot_vect_delete_test.md)
+* [boot_vect_read_main](boot_vect_read_main.md)
+* [boot_vect_read_one](boot_vect_read_one.md)
+* [boot_vect_read_test](boot_vect_read_test.md)
+* [boot_write_status](boot_write_status.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console.md b/docs/os/modules/console/console.md
new file mode 100644
index 0000000..60c2b88
--- /dev/null
+++ b/docs/os/modules/console/console.md
@@ -0,0 +1,92 @@
+# Console
+
+
+The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS.
+
+Support is currently available for console access via the serial port on the hardware board.
+
+
+## Description
+
+In the Mynewt OS, the console library comes in two versions:
+
+* full - containing the full implementation
+* stub - containing stubs for the API
+
+Both of these have `egg.yml` file which states that they provide the `console` API. If an egg uses this API, it should list `console` as a requirement.
+For example, the shell egg is defined by the following egg.yml file:
+```no-highlight
+ egg.name: libs/shell
+ egg.vers: 0.1
+ egg.deps:
+ - libs/os
+ - libs/util
+ egg.reqs:
+ - console
+ egg.identities:
+ - SHELL
+```
+The project .yml file decides which version of the console egg should be included.
+If project requires the full console capability it lists dependency `libs/console/full` in its egg.yml file.
+On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` egg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead and the egg.yml file for the project boot egg looks like the following:
+```no-highlight
+ project.name: boot
+ project.identities: bootloader
+ project.eggs:
+ - libs/os
+ - libs/bootutil
+ - libs/nffs
+ - libs/console/stub
+ - libs/util
+```
+
+Console has 2 modes for transmit; blocking and non-blocking mode. Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.
+Blocking mode is used when we don't want TX completion interrupts. This is used when system crashes, and we still want to output info related to that crash.
+
+## Data structures
+
+
+Console interaction is intrinsically composed of two unidirectional systems. The console implementation uses two ring buffers containing input (receive) and output (transmit) characters, respectively. Read and write operations on the console_ring structure are managed by labeling the read location indicator the `cr_tail` and the write location indicator the `cr_head`. The console ring length is variable and is specified as the `cr_size` member of the data structure. `cr_buf` is the pointer to the actual array of data contained.
+
+
+```no-highlight
+struct console_ring {
+ 32 uint8_t cr_head;
+ 33 uint8_t cr_tail;
+ 34 uint8_t cr_size;
+ 35 uint8_t _pad;
+ 36 uint8_t *cr_buf;
+ 37 }
+```
+
+
+```no-highlight
+struct console_tty {
+ 40 struct console_ring ct_tx;
+ 41 uint8_t ct_tx_buf[CONSOLE_TX_BUF_SZ]; /* must be after console_ring */
+ 42 struct console_ring ct_rx;
+ 43 uint8_t ct_rx_buf[CONSOLE_RX_BUF_SZ]; /* must be after console_ring */
+ 44 console_rx_cb ct_rx_cb; /* callback that input is ready */
+ 45 console_write_char ct_write_char;
+ 46 } console_tty
+```
+
+## List of Functions
+
+The functions available in console are:
+
+* [console_add_char](console_add_char.md)
+* [console_blocking_mode](console_blocking_mode.md)
+* [console_blocking_tx](console_blocking_tx.md)
+* [console_init](console_init.md)
+* [console_printf](console_printf.md)
+* [console_pull_char](console_pull_char.md)
+* [console_pull_char_head](console_pull_char_head.md)
+* [console_queue_char](console_queue_char.md)
+* [console_read](console_read.md)
+* [console_rx_char](console_rx_char.md)
+* [console_tx_char](console_tx_char.md)
+* [console_write](console_write.md)
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_add_char.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_add_char.md b/docs/os/modules/console/console_add_char.md
new file mode 100644
index 0000000..739722d
--- /dev/null
+++ b/docs/os/modules/console/console_add_char.md
@@ -0,0 +1,41 @@
+## <font color="#F2853F" style="font-size:24pt"> console_add_char</font>
+
+```no-highlight
+ static void
+ console_add_char(struct console_ring *cr, char ch)
+```
+
+Adds a character to the console ring buffer. When you store an item in the buffer you store it at the head location, and the head advances to the next location.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *cr | Pointer to a console ring data structure whose `cr_head` variable is to be set to the second argument in this function call|
+| ch | Character to be inserted to the ring |
+
+#### Returned values
+
+None
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Add a new line character to the output (transmit) buffer.
+
+```no-highlight
+void
+task()
+{
+ struct console_ring *tx = &ct->ct_tx;
+
+ console_add_char(tx, '\n');
+}
+```
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_blocking_mode.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_blocking_mode.md b/docs/os/modules/console/console_blocking_mode.md
new file mode 100644
index 0000000..7023547
--- /dev/null
+++ b/docs/os/modules/console/console_blocking_mode.md
@@ -0,0 +1,46 @@
+## <font color="#F2853F" style="font-size:24pt"> console_blocking_mode </font>
+
+```no-highlight
+ void
+ console_blocking_mode(void)
+```
+ Calls the console_blocking_tx function to flush the buffered console output (transmit) queue. The function OS_ENTER_CRITICAL() is called to disable interrupts and OS_EXIT_CRITICAL() is called to enable interrupts back again once the buffer is flushed.
+
+#### Arguments
+
+| Arguments | Description |
+|-------------------------|
+| none | none |
+
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Here is an example of calling `console_blocking_mode` and printing crash information from an assert to help debug.
+
+```no-highlight
+void
+_assert_func(const char *file, int line, const char *func, const char *e)
+{
+ int sr;
+
+ OS_ENTER_CRITICAL(sr);
+ (void)sr;
+ os_die_line = line;
+ os_die_module = file;
+ console_blocking_mode();
+ console_printf("Assert %s; failed in %s:%d\n", e ? e : "", file, line);
+ system_reset();
+}
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_blocking_tx.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_blocking_tx.md b/docs/os/modules/console/console_blocking_tx.md
new file mode 100644
index 0000000..ee18b55
--- /dev/null
+++ b/docs/os/modules/console/console_blocking_tx.md
@@ -0,0 +1,46 @@
+## <font color="#F2853F" style="font-size:24pt"> console_blocking_tx </font>
+
+```no-highlight
+ static void
+ console_blocking_tx(char ch)
+```
+
+ Calls the hal function hal_uart_blocking_tx to transmit a byte to the console over UART in a blocking mode until the entire character has been sent. Hence it must be called with interrupts disabled. It is used when printing diagnostic output from system crash.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| ch | 8 bit character (data) to be transmitted |
+
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Here is an example of a console output queue being flushed.
+
+```no-highlight
+void
+task(void)
+{
+ struct console_tty *ct = &console_tty;
+ uint8_t byte;
+
+ while (ct->ct_tx.cr_head != ct->ct_tx.cr_tail) {
+ byte = console_pull_char(&ct->ct_tx);
+ console_blocking_tx(byte);
+ }
+}
+```
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_init.md b/docs/os/modules/console/console_init.md
new file mode 100644
index 0000000..e9598c5
--- /dev/null
+++ b/docs/os/modules/console/console_init.md
@@ -0,0 +1,32 @@
+## <font color="#F2853F" style="font-size:24pt"> console_init </font>
+
+```no-highlight
+ int
+ console_init(console_rx_cb rx_cb)
+```
+
+ Initializes console receive buffer and calls hal funtions hal_uart_init_cbs and hal_uart_config to initialize serial port connection and configure it (e.g. baud rate, flow control etc.)
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Give at least one example of usage.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_printf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_printf.md b/docs/os/modules/console/console_printf.md
new file mode 100644
index 0000000..8eb2280
--- /dev/null
+++ b/docs/os/modules/console/console_printf.md
@@ -0,0 +1,61 @@
+## <font color="F2853F" style="font-size:24pt"> console_printf</font>
+
+```no-highlight
+ void
+ console_printf(const char *fmt, ...)
+```
+
+Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| fmt | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
+| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
+
+#### Returned values
+
+None
+
+#### Notes
+
+While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
+
+#### Example
+Example #1:
+
+```no-highlight
+char adv_data_buf[32];
+
+void
+task()
+{
+ char adv_data_buf[32];
+
+ console_printf("%s", adv_data_buf);
+}
+```
+
+Example #2:
+
+```no-highlight
+struct exception_frame {
+ uint32_t r0;
+ uint32_t r1;
+
+struct trap_frame {
+ struct exception_frame *ef;
+ uint32_t r2;
+ uint32_t r3;
+};
+
+void
+task(struct trap_frame *tf)
+{
+ console_printf(" r0:%8.8x r1:%8.8x", tf->ef->r0, tf->ef->r1);
+ console_printf(" r8:%8.8x r9:%8.8x", tf->r2, tf->r3);
+}
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_pull_char.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_pull_char.md b/docs/os/modules/console/console_pull_char.md
new file mode 100644
index 0000000..7f06172
--- /dev/null
+++ b/docs/os/modules/console/console_pull_char.md
@@ -0,0 +1,47 @@
+## <font color="#F2853F" style="font-size:24pt"> console_pull_char </font>
+
+```no-highlight
+ static uint8_t
+ console_pull_char(struct console_ring *cr)
+```
+
+Reads (remove) a byte from the console ring buffer. When you read (pull) an item, you read it at the current tail location, and the tail advances to the next position.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *cr | Pointer to the console ring buffer from where a character is to be removed |
+
+
+#### Returned values
+
+Returns the character pulled from the ring buffer.
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Read the characters in the ring buffer into a string.
+
+```no-highlight
+void
+task(struct console_ring *cr, char *str, int cnt)
+{
+ for (i = 0; i < cnt; i++) {
+ if (cr->cr_head == cr->cr_tail) {
+ i = -1;
+ break;
+ }
+ ch = console_pull_char(cr);
+ *str++ = ch;
+ }
+}
+```
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_pull_char_head.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_pull_char_head.md b/docs/os/modules/console/console_pull_char_head.md
new file mode 100644
index 0000000..c266e41
--- /dev/null
+++ b/docs/os/modules/console/console_pull_char_head.md
@@ -0,0 +1,57 @@
+## <font color="#F2853F" style="font-size:24pt"> console_pull_char_head </font>
+
+```no-highlight
+ static void
+ console_pull_char_head(struct console_ring *cr)
+```
+
+Removes the last character inserted into the ring buffer by moving back the head location and shrinking the ring size by 1.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| cr | Pointer to the console ring buffer from which the last inserted character must be deleted |
+
+
+#### Returned values
+
+None
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+In order to see a character getting deleted when a user hits backspace while typying a command, the following needs to happen in sequence:
+
+* output a backspace (move cursor back one character)
+* output space (erasing whatever character there was before)
+* output backspace (move cursor back one character)
+* remove the previous character from incoming RX queue
+
+The example below shows console_pull_char_head being used for the last step.
+
+```no-highlight
+void
+task(uint8_t data)
+{
+ struct console_tty *ct = (struct console_tty *)arg;
+ struct console_ring *tx = &ct->ct_tx;
+ struct console_ring *rx = &ct->ct_rx;
+
+ switch (data) {
+ case '\b':
+ console_add_char(tx, '\b');
+ console_add_char(tx, ' ');
+ console_add_char(tx, '\b');
+ console_pull_char_head(rx);
+ break;
+ }
+}
+
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_queue_char.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_queue_char.md b/docs/os/modules/console/console_queue_char.md
new file mode 100644
index 0000000..74e34f3
--- /dev/null
+++ b/docs/os/modules/console/console_queue_char.md
@@ -0,0 +1,33 @@
+## <font color="#F2853F" style="font-size:24pt"> console_queue_char </font>
+
+```no-highlight
+ static void
+ console_queue_char(char ch)
+```
+
+Manage the buffer queue before inserting a character into it. If the head of the output (transmit) console ring is right up to its tail, the queue needs to be drained first before any data can be added. Then it uses console_add_char function to add the character.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| ch | Character to be inserted to the queue |
+
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Function blocks interrupts as a way of protecting against concurrent access to TX buffer.
+
+If TX buffer is full, the function waits for TX buffer to drain. And the way it does it currently is by calling os_time_delay(). Therefore this function should only be called from within a task context, not from an interrupt handler. We might want to change this...
+
+#### Example
+
+```no-highlight
+Insert example
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_read.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_read.md b/docs/os/modules/console/console_read.md
new file mode 100644
index 0000000..9c7460f
--- /dev/null
+++ b/docs/os/modules/console/console_read.md
@@ -0,0 +1,31 @@
+i## <font color="#F2853F" style="font-size:24pt"> console_read </font>
+
+```no-highlight
+ int
+ console_read(char *str, int cnt)
+```
+ Calls hal function hal_uart_start_rx to start receiving input from console terminal over serial port.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Give at least one example of usage.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_rx_char.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_rx_char.md b/docs/os/modules/console/console_rx_char.md
new file mode 100644
index 0000000..bb3c338
--- /dev/null
+++ b/docs/os/modules/console/console_rx_char.md
@@ -0,0 +1,30 @@
+## <font color="#F2853F" style="font-size:24pt"> console_rx_char </font>
+
+```no-highlight
+ static int
+ console_rx_char(void *arg, uint8_t data)
+```
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Give at least one example of usage.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_tx_char.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_tx_char.md b/docs/os/modules/console/console_tx_char.md
new file mode 100644
index 0000000..d3f0dec
--- /dev/null
+++ b/docs/os/modules/console/console_tx_char.md
@@ -0,0 +1,30 @@
+## <font color="#F2853F" style="font-size:24pt"> console_tx_char </font>
+
+```no-highlight
+ static int
+ console_tx_char(void *arg)
+```
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Give at least one example of usage.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/console/console_write.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_write.md b/docs/os/modules/console/console_write.md
new file mode 100644
index 0000000..1d7a524
--- /dev/null
+++ b/docs/os/modules/console/console_write.md
@@ -0,0 +1,46 @@
+## <font color="#F2853F" style="font-size:24pt"> console_write </font>
+
+```no-highlight
+ void
+ console_write(char *str, int cnt)
+```
+Transmit characters to console display over serial port.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *str | pointer to the character or packet to be transmitted |
+| cnt | size of the character or packet |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+Here is an example of the function being used in an echo command with a newline at the end.
+
+```no-highlight
+static int
+shell_echo_cmd(int argc, char **argv)
+{
+ int i;
+
+ for (i = 1; i < argc; i++) {
+ console_write(argv[i], strlen(argv[i]));
+ console_write(" ", sizeof(" ")-1);
+ }
+ console_write("\n", sizeof("\n")-1);
+
+ return (0);
+}
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/elua.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/elua.md b/docs/os/modules/elua.md
new file mode 100644
index 0000000..d49d9bb
--- /dev/null
+++ b/docs/os/modules/elua.md
@@ -0,0 +1,17 @@
+# elua
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/filesystem.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/filesystem.md b/docs/os/modules/filesystem.md
new file mode 100644
index 0000000..6f40d4c
--- /dev/null
+++ b/docs/os/modules/filesystem.md
@@ -0,0 +1,750 @@
+# Filesystem
+
+Mynewt provides a Flash File System abstraction layer (fs) to allow you to swap out the default Newtron File System (nffs) with a different file system of your choice.
+
+## Description
+
+The default file system used in the Mynewt OS is the Newtron Flash File System (nffs). Hence the `nffs` egg description lists `libs/fs` as a dependency.
+
+```no-highlight
+egg.name: libs/nffs
+egg.vers: 0.1
+egg.identities: NFFS
+egg.deps:
+ - libs/os
+ - libs/fs
+ - libs/testutil
+ - hw/hal
+```
+
+If the user wishes to use a different flash file system (say, "ownffs"), the directory containing "ownffs" code must include the `egg.yml` file stating the dependency on `libs/fs` listed as shown above. "ownffs" uses the `libs/fs` API available in mynewt, thus minimizing changes to other parts of the project.
+
+Note that this generic file system (`fs`) API does not expose any file system detection, initialization, and formatting functions. These function calls remain specific to the chosen file system. For example, Project Slinky uses the default Newtron File System (nffs) and therefore calls nffs_init() to initialize the nffs memory and data structures before any other file system operations are attempted. As shown below, the egg for Project Slinky includes the `libs/imgmgr` egg which in turn includes the `libs/bootutil ` egg. The egg description for `libs/bootutil` specifies `fs/nffs` as a dependency.
+
+```no-highlight
+
+ egg.name: project/slinky
+ egg.vers: 0.1
+ egg.deps:
+ - libs/os
+ - libs/console/full
+ - libs/shell
+ - libs/newtmgr
+ - libs/imgmgr
+ - sys/config
+ - sys/log
+ - sys/stats
+```
+
+```no-highlight
+
+ egg.name: libs/imgmgr
+ egg.vers: 0.1
+ egg.deps:
+ - libs/newtmgr
+ - libs/bootutil
+ egg.deps.FS:
+ - fs/fs
+ egg.cflags.FS: -DFS_PRESENT
+```
+
+```no-highlight
+
+ egg.name: libs/bootutil
+ egg.vers: 0.1
+ egg.deps:
+ - fs/nffs
+ - libs/os
+ - libs/testutil
+ - hw/hal
+```
+
+## Data Structures
+
+
+## API
+
+```no-highlight
+ struct fs_file;
+```
+
+The functions available in this OS feature are:
+
+* [fs_open](#fs_open)
+* [fs_close](#fs_close)
+* [fs_read](#fs_read)
+* [fs_write](#fs_write)
+* [fs_seek](#fs_seek)
+* [fs_getpos](#fs_getpos)
+* [fs_filelen](#fs_filelen)
+* [fs_unlink](#fs_unlink)
+* [fs_rename](#fs_rename)
+* [fs_mkdir](#fs_mkdir)
+* [fs_opendir](#fs_opendir)
+* [fs_readdir](#fs_readdir)
+* [fs_closedir](#fs_closedir)
+* [fs_dirent_name](#fs_dirent_name)
+* [fs_dirent_is_dir](#fs_dirent_is_dir)
+
+Additional file system utilities that bundle some of the basic functions above are:
+
+* [fsutil_read_file](#fsutil_read_file)
+* [fsutil_write_file](#fsutil_write_file)
+
+
+## API Reference
+
+------------------
+
+## <font color="F2853F" style="font-size:24pt"> fs_open </font>
+
+```no-highlight
+ int
+ fs_open(const char *filename, uint8_t access_flags, struct fs_file **out_file);
+```
+
+Opens a file at the specified path. The result of opening a nonexistent file depends on the access flags specified. All intermediate directories must already exist.
+
+The mode strings passed to fopen() map to fs_open()'s access flags as follows:
+
+```no-highlight
+ "r" - FS_ACCESS_READ
+ "r+" - FS_ACCESS_READ | FS_ACCESS_WRITE
+ "w" - FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
+ "w+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
+ "a" - FS_ACCESS_WRITE | FS_ACCESS_APPEND
+ "a+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_APPEND
+```
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| filename | Pointer to the file created at the path of the specified filename |
+| access_flags | Flags controlling file access; see above table |
+| out_file | On success, a pointer to the newly-created file handle gets written here|
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+There is no concept of current working directory. Therefore all file names should start with '/'.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+
+<Insert the code snippet here>
+
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_close </font>
+
+```no-highlight
+ int
+ fs_close(struct fs_file *file)
+```
+
+Closes the specified file and invalidates the file handle. If the file has already been unlinked, and this is the last open handle to the file, this operation causes the file to be deleted from disk.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the file to close |
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+Don't use file handle after closing the file.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+
+<Insert the code snippet here>
+
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_read </font>
+
+```no-highlight
+ int
+ fs_read(struct fs_file *file, uint32_t len, void *out_data, uint32_t *out_len);
+```
+
+Reads data from the specified file. If more data is requested than remains in the file, all available data is retrieved. Function returns in `out_len` the actual number of bytes read (less or equal to `len`).
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the the file to read from |
+| len | The number of bytes to attempt to read |
+| out_data | The destination buffer to read into
+| out_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+This type of short read results in a success return code.
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_write </font>
+
+```no-highlight
+ int
+ fs_write(struct fs_file *file, const void *data, int len);
+```
+
+Writes the supplied data to the current offset of the specified file handle.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the file to write to |
+| data | The data to write |
+| len | The number of bytes to write |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_seek </font>
+
+```no-highlight
+ int
+ fs_seek(struct fs_file *file, uint32_t offset);
+```
+
+Positions a file's read and write pointer at the specified offset. The offset is expressed as the number of bytes from the start of the file (i.e., seeking to offset 0 places the pointer at the first byte in the file).
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the file to reposition |
+| offset | The 0-based file offset to seek to |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_getpos </font>
+
+```no-highlight
+ uint32_t
+ fs_getpos(const struct fs_file *file);
+```
+
+Retrieves the current read and write position of the specified open file.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the file to query |
+
+
+#### Returned values
+
+* The file offset, in bytes
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_filelen </font>
+
+```no-highlight
+ int
+ fs_filelen(const struct fs_file *file, uint32_t *out_len);
+
+```
+
+Retrieves the current length of the specified open file.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| file | Pointer to the file to query |
+| out_len | On success, the number of bytes in the file gets written here |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_unlink </font>
+
+```no-highlight
+ int
+ fs_unlink(const char *filename);
+
+```
+
+Unlinks the file or directory at the specified path. If the path refers to a directory, all the directory's descendants are recursively unlinked. Any open file handles refering to an unlinked file remain valid, and can be read from and written to.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| filename | The path of the file or directory to unlink |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_rename </font>
+
+```no-highlight
+ int
+ fs_rename(const char *from, const char *to);
+
+```
+
+Performs a rename and / or move of the specified source path to the specified destination.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| from | The source path |
+| to | The destination path |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+The source path can refer to either a file or a directory. All intermediate directories in the destination path must already exist. If the source path refers to a file, the destination path must contain a full filename path, rather than just the new parent directory. If an object already exists at the specified destination path, this function causes it to be unlinked prior to the rename (i.e., the destination gets clobbered).
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_mkdir </font>
+
+```no-highlight
+ int
+ fs_mkdir(const char *path);
+
+```
+
+Creates the directory represented by the specified path.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| path | Pointer to the directory to create |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure.
+
+#### Notes
+
+All intermediate directories must already exist. The specified path must start with a '/' character.
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_opendir </font>
+
+```no-highlight
+
+ int
+ fs_opendir(const char *path, struct fs_dir **out_dir);
+
+```
+
+Opens the directory at the specified path. The directory's contents can be read with subsequent calls to fs_readdir(). When you are done with the directory handle, close it with fs_closedir().
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| path | Pointer to the directory to create |
+| out_dir | On success, points to the directory handle |
+
+
+#### Returned values
+
+* 0 on success
+* FS_ENOENT if the specified directory does not exist (no such file)
+* Other nonzero on error.
+
+#### Notes
+
+Unlinking files from the directory while it is open may result in unpredictable behavior. New files can be created inside the directory.
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_readdir </font>
+
+```no-highlight
+ int
+ fs_readdir(struct fs_dir *dir, struct fs_dirent **out_dirent);
+
+```
+
+Reads the next entry in an open directory.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| dir | The directory handle to read from |
+| out_dirent | On success, points to the next child entry in the specified directory |
+
+
+#### Returned values
+
+* 0 on success
+* FS_ENOENT if there are no more entries in the parent directory
+* Other nonzero on error.
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_closedir </font>
+
+```no-highlight
+ int
+ fs_closedir(struct fs_dir *dir);
+
+```
+
+Closes the specified directory handle.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| dir | Pointer to the directory to close |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_dirent_name </font>
+
+```no-highlight
+ int
+ fs_dirent_name(const struct fs_dirent *dirent, size_t max_len,
+ char *out_name, uint8_t *out_name_len);
+
+```
+
+Retrieves the filename of the specified directory entry.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| dirent | Pointer to the directory entry to query |
+| max_len | Size of the "out_name" character buffer |
+| out_name | On success, the entry's filename is written here; always null-terminated |
+| out_name_len | On success, contains the actual length of the filename, NOT including the null-terminator |
+
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+The retrieved filename is always null-terminated. To ensure enough space to hold the full filename plus a null-termintor, a destination buffer of size (filename max length + 1) should be used.
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fs_dirent_is_dir </font>
+
+```no-highlight
+ int
+ fs_dirent_is_dir(const struct fs_dirent *dirent);
+
+```
+
+Tells you whether the specified directory entry is a sub-directory or a regular file.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| dirent | Pointer to the directory entry to query |
+
+
+#### Returned values
+
+* 1: The entry is a directory
+* 0: The entry is a regular file.
+
+#### Notes
+
+<any notes?>
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fsutil_read_file </font>
+
+```no-highlight
+ int
+ fsutil_read_file(const char *path, uint32_t offset, uint32_t len, void *dst,
+ uint32_t *out_len);
+```
+
+Calls fs_open(), fs_read(), and fs_close() to open a file at the specified path, retrieve data from the file starting from the specified offset, and close the file and invalidate the file handle.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| path | Pointer to the directory entry to query |
+| offset | Position of the file's read pointer |
+| len | Number of bytes to attempt to read |
+| dst | Destination buffer to read into |
+| out_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+This is a convenience function. You can use it if the file is small (caller has enough buffer space to hold all the file contents in memory).
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> fsutil_write_file </font>
+
+```no-highlight
+ int
+ fsutil_write_file(const char *path, const void *data, uint32_t len);
+```
+
+Calls fs_open(), fs_write(), and fs_close() to open a file at the specified path, write the supplied data to the current offset of the specified file handle, and close the file and invalidate the file handle.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| path | Pointer to the file to write to |
+| data | The data to write |
+| len | The number of bytes to write |
+
+#### Returned values
+
+* 0 on success
+* nonzero on failure
+
+#### Notes
+
+<any notes?>
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgmgr.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgmgr.md b/docs/os/modules/imgmgr/imgmgr.md
new file mode 100644
index 0000000..650314b
--- /dev/null
+++ b/docs/os/modules/imgmgr/imgmgr.md
@@ -0,0 +1,35 @@
+# Image Manager
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+The functions available in imgmgr are:
+
+* [imgmgr_module_init](imgmgr_module_init.md)
+* [imgr_boot_read](imgr_boot_read.md)
+* [imgr_boot_write](imgr_boot_write.md)
+* [imgr_file_download](imgr_file_download.md)
+* [imgr_file_upload](imgr_file_upload.md)
+* [imgr_list](imgr_list.md)
+* [imgr_noop](imgr_noop.md)
+* [imgr_read_file](imgr_read_file.md)
+* [imgr_read_main](imgr_read_main.md)
+* [imgr_read_test](imgr_read_test.md)
+* [imgr_read_ver](imgr_read_ver.md)
+* [imgr_upload](imgr_upload.md)
+* [imgr_ver_jsonstr](imgr_ver_jsonstr.md)
+* [imgr_ver_parse](imgr_ver_parse.md)
+* [imgr_ver_str](imgr_ver_str.md)
+* [imgr_write_file](imgr_write_file.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgmgr_module_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgmgr_module_init.md b/docs/os/modules/imgmgr/imgmgr_module_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_boot_read.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_boot_read.md b/docs/os/modules/imgmgr/imgr_boot_read.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_boot_write.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_boot_write.md b/docs/os/modules/imgmgr/imgr_boot_write.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_file_download.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_file_download.md b/docs/os/modules/imgmgr/imgr_file_download.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_file_upload.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_file_upload.md b/docs/os/modules/imgmgr/imgr_file_upload.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_list.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_list.md b/docs/os/modules/imgmgr/imgr_list.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_noop.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_noop.md b/docs/os/modules/imgmgr/imgr_noop.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_read_file.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_read_file.md b/docs/os/modules/imgmgr/imgr_read_file.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_read_main.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_read_main.md b/docs/os/modules/imgmgr/imgr_read_main.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_read_test.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_read_test.md b/docs/os/modules/imgmgr/imgr_read_test.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_read_ver.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_read_ver.md b/docs/os/modules/imgmgr/imgr_read_ver.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_upload.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_upload.md b/docs/os/modules/imgmgr/imgr_upload.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_ver_jsonstr.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_ver_jsonstr.md b/docs/os/modules/imgmgr/imgr_ver_jsonstr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_ver_parse.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_ver_parse.md b/docs/os/modules/imgmgr/imgr_ver_parse.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_ver_str.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_ver_str.md b/docs/os/modules/imgmgr/imgr_ver_str.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/imgmgr/imgr_write_file.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/imgmgr/imgr_write_file.md b/docs/os/modules/imgmgr/imgr_write_file.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json.md b/docs/os/modules/json/json.md
new file mode 100644
index 0000000..4e1f920
--- /dev/null
+++ b/docs/os/modules/json/json.md
@@ -0,0 +1,28 @@
+# JSON
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+The functions available in json are:
+
+* [json_encode_object_entry](json_encode_object_entry.md)
+* [json_encode_object_finish](json_encode_object_finish.md)
+* [json_encode_object_key](json_encode_object_key.md)
+* [json_encode_object_start](json_encode_object_start.md)
+* [json_encode_value](json_encode_value.md)
+* [json_internal_read_object](json_internal_read_object.md)
+* [json_read_array](json_read_array.md)
+* [json_read_object](json_read_object.md)
+* [json_target_address](json_target_address.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_encode_object_entry.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_encode_object_entry.md b/docs/os/modules/json/json_encode_object_entry.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_encode_object_finish.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_encode_object_finish.md b/docs/os/modules/json/json_encode_object_finish.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_encode_object_key.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_encode_object_key.md b/docs/os/modules/json/json_encode_object_key.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_encode_object_start.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_encode_object_start.md b/docs/os/modules/json/json_encode_object_start.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_encode_value.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_encode_value.md b/docs/os/modules/json/json_encode_value.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_internal_read_object.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_internal_read_object.md b/docs/os/modules/json/json_internal_read_object.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_read_array.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_read_array.md b/docs/os/modules/json/json_read_array.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_read_object.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_read_object.md b/docs/os/modules/json/json_read_object.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/json/json_target_address.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/json/json_target_address.md b/docs/os/modules/json/json_target_address.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/newtmgr.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/newtmgr.md b/docs/os/modules/newtmgr.md
new file mode 100644
index 0000000..a17a2c5
--- /dev/null
+++ b/docs/os/modules/newtmgr.md
@@ -0,0 +1,139 @@
+# Bootloader
+
+Insert synopsis here
+
+
+## Description
+
+Describe module here, special features, how pieces fit together etc.
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
+
+The functions available in this OS feature are:
+
+* [boot_slot_addr](#boot_slot_addr)
+* [boot_find_image_slot](#boot_find_image_slot)
+* add the rest
+
+
+## Function Reference
+
+------------------
+
+## <font color="F2853F" style="font-size:24pt"> boot_slot_addr </font>
+
+```no-highlight
+ static void
+ boot_slot_addr(int slot_num, uint8_t *flash_id, uint32_t *address)
+```
+
+<Insert short description>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> boot_find_image_slot </font>
+
+```no-highlight
+ <Insert function callout here >
+```
+
+<Insert short description>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> next_one </font>
+
+```no-highlight
+ <Insert function callout here >
+```
+
+<Insert short description>
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| xx | explain argument xx |
+| yy | explain argument yy |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
[4/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/project1.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/project1.md b/docs/os/get_started/project1.md
new file mode 100644
index 0000000..89d3c9f
--- /dev/null
+++ b/docs/os/get_started/project1.md
@@ -0,0 +1,1075 @@
+## Blinky, the First Project
+
+### Objective
+
+We will show you how you can use eggs from a nest on Mynewt to make an LED on a target board blink. We will call it ** Project Blinky**. The goals of this tutorial are threefold:
+
+1. First, you will learn how to set up your environment to be ready to use Mynewt OS and newt tool.
+2. Second, we will walk you through a download of eggs for building and testing [on a simulated target](#building-test-code-on-simulator).
+3. Third, you will download eggs and use tools to create a runtime image for a board to make its LED blink. You have two choices here - you can [download an image to SRAM](#using-sram-to-make-led-blink) or you can [download it to flash](#using-flash-to-make-led-blink).
+
+** Time Requirement**: Allow yourself a couple of hours for this project if you are relatively new to embedded systems and playing with development boards. Those jumpers can be pesky!
+
+
+### What you need
+
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
+3. USB A-B type cable to connect the debugger to your personal computer
+4. Personal Computer
+
+The instructions assume the user is using a Bourne-compatible shell (e.g. bash or zsh) on your computer. The given instructions have been tested with the following releases of operating systems:
+
+* Mac: OS X Yosemite Version 10.10.5
+* Linux: Ubuntu 14.10 (Utopic Unicorn)
+* Windows: Windows 10
+
+
+### Access to the Apache repo
+
+* Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
+
+* The latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
+
+* The latest codebase for the Newt tool is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git
+
+The following shows how to clone a Mynewt OS code repository:
+
+* Non Committers
+```no-highlight
+ $ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
+```
+* Committers
+```no-highlight
+ $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
+```
+
+
+### Getting your Mac Ready
+
+#### Installing Homebrew to ease installs on OS X
+
+* Do you have Homebrew? If not, open a terminal on your Mac and paste the following at a Terminal prompt. It will ask you for your sudo password.
+
+```no-highlight
+ $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
+```
+ Alternatively, you can just extract (or `git clone`) Homebrew and install it to `/usr/local`.
+
+#### Installing Go
+
+* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
+
+ * src contains Go source files organized into packages (one package per directory),
+
+ * pkg contains package objects, and
+
+ * bin contains executable commands.
+
+ The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.
+
+```no-highlight
+ $ cd $HOME
+ $ mkdir -p dev/go
+ $ cd dev/go
+ $ export GOPATH=`pwd`
+```
+ Note that you need to add export statements to ~/.bash_profile to export variables permanently. Don't forget to source the file for the change to go into effect.
+
+```no-highlight
+ $ vi ~/.bash_profile
+ $ source ~/.bash_profile
+```
+* Next you will use Homebrew to install Go. The summary message at the end of the installation should indicate that it is installed in the /usr/local/Cellar/go/ directory. You will use the Go command 'install' to compile and install packages (called eggs in the Mynewt world) and dependencies.
+
+```no-highlight
+ $ brew install go
+ ==>
+ ...
+ ...
+ ==> *Summary*
+ 🍺 /usr/local/Cellar/go/1.5.1: 5330 files, 273M
+```
+ Alternatively, you can download the Go package directly from (https://golang.org/dl/) instead of brewing it. Install it in /usr/local directory.
+
+
+#### Creating local repository
+
+* You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.
+```no-highlight
+ $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ $ ls
+ bin pkg src
+ $ ls src
+ git-wip-us.apache.org github.com gopkg.in
+```
+
+* Check that newt.go is in place.
+```no-highlight
+ $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ Godeps README.md coding_style.txt newt.go
+ LICENSE cli design.txt
+```
+
+#### Building the Newt tool
+
+* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
+```no-highlight
+ $ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ $ go install
+ $ ls "$GOPATH"/bin/
+ godep incubator-mynewt-newt.git newt
+```
+* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
+
+ Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in `export newt="go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go"` in your .bash_profile and execute it by calling `$newt` at the prompt instead of `newt`. Here, you use `go run` which runs the compiled binary directly without producing an executable. Don't forget to reload the updated bash profile by typing `source ~/.bash_profile` at the prompt!
+```no-highlight
+ $ newt version
+ Newt version: 1.0
+ $ newt -h
+ Newt allows you to create your own embedded project based on the Mynewt
+ operating system. Newt provides both build and package management in a
+ single tool, which allows you to compose an embedded workspace, and set
+ of projects, and then build the necessary artifacts from those projects.
+ For more information on the Mynewt operating system, please visit
+ https://www.github.com/mynewt/documentation.
+
+ Please use the newt help command, and specify the name of the command
+ you want help for, for help on how to use a specific command
+
+ Usage:
+ newt [flags]
+ newt [command]
+
+ Examples:
+ newt
+ newt help [<command-name>]
+ For help on <command-name>. If not specified, print this message.
+
+
+ Available Commands:
+ version Display the Newt version number.
+ target Set and view target information
+ egg Commands to list and inspect eggs on a nest
+ nest Commands to manage nests & clutches (remote egg repositories)
+ help Help about any command
+
+ Flags:
+ -h, --help=false: help for newt
+ -l, --loglevel="WARN": Log level, defaults to WARN.
+ -q, --quiet=false: Be quiet; only display error output.
+ -s, --silent=false: Be silent; don't output anything.
+ -v, --verbose=false: Enable verbose output when executing commands.
+
+
+ Use "newt help [command]" for more information about a command.
+```
+* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
+
+#### Getting the debugger ready
+
+* Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. So, first install gcc. You will see the brew steps and a final summary confirming install.
+```no-highlight
+ $ brew install gcc
+ ...
+ ...
+ ==> Summary
+ 🍺 /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M
+```
+
+* ARM maintains a pre-built GNU toolchain with a GCC source branch targeted at Embedded ARM Processors namely Cortex-R/Cortex-M processor families. Install the PX4 Toolchain and check the version installed. Make sure that the symbolic link installed by Homebrew points to the correct version of the debugger. If not, you can either change the symbolic link using the "ln -f -s" command or just go ahead and try with the version it points to!
+```no-highlight
+ $ brew tap PX4/homebrew-px4
+ $ brew update
+ $ brew install gcc-arm-none-eabi-49
+ $ arm-none-eabi-gcc --version
+ arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ This is free software; see the source for copying conditions. There is NO
+ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ $ ls -al /usr/local/bin/arm-none-eabi-gdb
+ lrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -> /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb
+```
+ Note: If no version is specified, brew will install the latest version available. MynewtOS will eventually work with multiple versions available including the latest releases. However, at present we have tested only with this version and recommend it for getting started.
+
+* You have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. Use brew to install it. Brew adds a simlink /usr/local/bin/openocd to the openocd directory in the Cellar. For more on OpenOCD go to [http://openocd.org](http://openocd.org).
+```no-highlight
+ $ brew install open-ocd
+ $ which openocd
+ /usr/local/bin/openocd
+ $ ls -l $(which openocd)
+ lrwxr-xr-x 1 <user> admin 36 Sep 17 16:22 /usr/local/bin/openocd -> ../Cellar/open-ocd/0.9.0/bin/openocd
+```
+* Proceed to the [Building test code on simulator](#building-test-code-on-simulator) section.
+
+
+### Getting your Ubuntu machine Ready
+
+
+#### Installing some prerequisites
+
+* Install git, libcurl, and the Go language if you do not have them already.
+```no-highlight
+ $ sudo apt-get install git
+ $ sudo apt-get install libcurl4-gnutls-dev
+ $ sudo apt-get install golang
+```
+
+#### Creating local repository
+
+* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
+
+ * src contains Go source files organized into packages (one package per directory),
+
+ * pkg contains package objects, and
+
+ * bin contains executable commands.
+
+ The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.
+```no-highlight
+ $ cd $HOME
+ $ mkdir -p dev/go
+ $ cd dev/go
+ $ export GOPATH=$PWD
+```
+ Note that you need to add export statements to ~/.bashrc (or equivalent) to export variables permanently.
+
+* You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.
+```no-highlight
+ $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ $ ls
+ bin pkg src
+ $ ls src
+ git-wip-us.apache.org github.com gopkg.in
+```
+
+* Check that newt is in place.
+```no-highlight
+ $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ Godeps README.md coding_style.txt newt.go
+ LICENSE cli design.txt
+```
+#### Building the newt tool
+
+
+* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
+```no-highlight
+ $ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ $ go install
+ $ ls "$GOPATH"/bin/
+ godep incubator-mynewt-newt.git newt
+```
+* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
+
+ Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in `export newt="go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go"` in your ~/.bashrc (or equivalent) and execute it by calling `$newt` at the prompt instead of `newt`. Here, you use `go run` which runs the compiled binary directly without producing an executable.
+
+```no-highlight
+ $ newt version
+ Newt version: 1.0
+ $ newt -h
+ Newt allows you to create your own embedded project based on the Mynewt
+ operating system. Newt provides both build and package management in a
+ single tool, which allows you to compose an embedded workspace, and set
+ of projects, and then build the necessary artifacts from those projects.
+ For more information on the Mynewt operating system, please visit
+ https://www.github.com/mynewt/documentation.
+
+ Please use the newt help command, and specify the name of the command
+ you want help for, for help on how to use a specific command
+
+ Usage:
+ newt [flags]
+ newt [command]
+
+ Examples:
+ newt
+ newt help [<command-name>]
+ For help on <command-name>. If not specified, print this message.
+
+
+ Available Commands:
+ version Display the Newt version number.
+ target Set and view target information
+ egg Commands to list and inspect eggs on a nest
+ nest Commands to manage nests & clutches (remote egg repositories)
+ help Help about any command
+
+ Flags:
+ -h, --help=false: help for newt
+ -l, --loglevel="WARN": Log level, defaults to WARN.
+ -q, --quiet=false: Be quiet; only display error output.
+ -s, --silent=false: Be silent; don't output anything.
+ -v, --verbose=false: Enable verbose output when executing commands.
+
+
+ Use "newt help [command]" for more information about a command.
+```
+* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
+
+#### Getting the debugger ready
+
+* Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. You can install these as follows:
+```no-highlight
+ $ sudo apt-get install gcc-multilib libc6-i386
+```
+* For the LED project on the Olimex hardware, you have to install gcc for AM 4.9.3. This package can be installed with apt-get as documented below. The steps are explained in depth at [https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded](https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded).
+```no-highlight
+ $ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
+ $ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
+ $ sudo apt-get update
+ $ sudo apt-get install gcc-arm-none-eabi
+```
+* And finally, you have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0.
+
+ If you are running Ubuntu 15.x, then you are in luck and you can simply run:
+```no-highlight
+ $ sudo apt-get install openocd
+```
+ Other versions of Ubuntu may not have the correct version of openocd available. In this case, you should download the openocd 0.8.0 package from [https://launchpad.net/ubuntu/vivid/+source/openocd](https://launchpad.net/ubuntu/vivid/+source/openocd). The direct link to the amd64 build is [http://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb](http://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb).
+
+* Proceed to the [Building test code on simulator](#building-test-code-on-simulator) section.
+
+### Getting your Windows machine ready for simulated target
+
+The `newt` tool is the build software used to build Mynewt OS images or executables for any embedded hardware device/board, including the one for the current tutorial (STM32-E407 development board from Olimex). You can run the `newt` tool natively on a computer running any of the three Operating System machines - OSX, Linux, or Windows.
+
+However, Mynewt OS images for a simulated target are built on the Windows machine by using Linux versions of the build software (newt)in a virtual machine on your Windows box. The Linux VM is set up by installing the Docker Toolbox. Your Windows machine will communicate with the Linux VM via transient ssh connections. You will then download a Docker image (`newtvm.exe`)that allows you to run the newt commands in the Linux Docker instance. The Docker image contains:
+
+ * The newt command-line tool
+ * Go
+ * A multilib-capable native gcc / glibc
+ * An arm-none-eabi gcc
+ * Native gdb
+
+ The sequence of events when using the Docker image is as follows:
+
+ 1. A new docker environment is created in the Linux VM.
+ 2. The specified command with the newtvm prefix (`newtvm newt` command) is sent to the docker environment via ssh.
+ 3. The Linux command runs.
+ 4. The output from the command is sent back to Windows via ssh.
+ 5. The output is displayed in the Windows command prompt.
+
+
+#### Install Linux virtual machine
+
+* Download the Docker Toolbox for Windows (version 1.9.0c or later) from [https://www.docker.com/docker-toolbox](https://www.docker.com/docker-toolbox). The Docker toolbox creates a consistently reproducible and self-contained environment in Linux.
+
+* Run the Docker Toolbox installer. All the default settings are OK.
+
+* You may need to add "C:\Program Files\Git\usr\bin" to your PATH
+environment variable. To add to the PATH environment variable, right-click on the Start button in the bottom left corner. Choose System -> Advanced system settings -> Environment Variables. Click on the PATH variable under "System variables" and click Edit to check and add it if it is not already there.
+
+#### Install newtvm tool
+
+* From your base user (home) directory, pull or clone the latest code from the newt repository into the `newt` directory. It includes the executable `newtvm.exe` for the newtvm tool in the `newtvm` directory.
+```no-highlight
+ C:\Users\admin> git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt newt
+```
+ The newtvm tool is what allows you to run programs in the Linux docker
+instance.
+
+* Run the Docker Quickstart Terminal application inside the Docker folder under Programs. You can find it by clicking Start button -> All apps. By default, the Docker Toolbox installer creates a shortcut to this program on your desktop. Wait until you see an ASCII art whale displayed in the terminal window and the Docker prompt given.
+
+
+```no-highlight
+ ## .
+ ## ## ## ==
+ ## ## ## ## ## ===
+ /"""""""""""""""""\___/ ===
+ ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
+ \______ o __/
+ \ \ __/
+ \____\_______/
+
+ docker is configured to use the default machine with IP 192.168.99.100
+ For help getting started, check out the docs at https://docs.docker.com
+
+ admin@dev1 MINGW64 ~ (master)
+ $
+```
+
+ The first time you run this, it may take several minutes to complete. You will need to run the Docker Quickstart Terminal once each time you
+restart your computer.
+
+* Open a command prompt (e.g., Windows-R, "cmd", enter). You execute the newt tool commands as though you were running newt in Linux, but you prefix each command with "newtvm". For example:
+```no-highlight
+ C:\Users\admin\newt\newtvm> newtvm newt help
+```
+
+ The newtvm tool will take a long time to run the first time you execute
+it. The delay is due to the fact that the tool must download the mynewt
+docker instance.
+
+* You are now ready to proceed to [building the image for the simulated target](#building-test-code-on-simulator).
+
+
+### Getting your Windows machine ready for hardware target
+
+When you want to produce images for actual hardware board on your Windows machine, go through the following setup procedure and then proceed to the [blinky project on the Olimex board](#Using-SRAM-to-make-LED-blink) with this method.
+
+#### Installing some prerequisites
+
+* You have to install the following if you do not have them already. The steps below indicate specific folders where each of these programs should be installed. You can choose different locations, but the remainder of this
+tutorial for a Windows machine assumes the specified folders.
+
+ * win-builds-i686
+ * win-builds-x86_64
+ * MSYS
+ * gcc for ARM
+ * openocd
+ * zadig
+ * git
+ * go
+
+ - *win-builds (mingw64) 1.5 for i686*
+
+ Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at: "C:\win-builds-i686".
+
+ Be sure to click the i686 option (not x86_64). The defaults for all other options are OK. The installer will want to download a bunch of additional packages. They are not all necessary, but it is simplest to just accept the defaults.
+
+ - *win-builds (mingw64) 1.5 for x86_64*
+
+ Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at "C:\win-builds-x86_64"
+
+ Run the installer a second time, but this time click the x86_64 option, NOT i686. The defaults for all other options are OK.
+
+ - *MSYS*
+
+ Start your download from [http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip](http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip)
+
+ Unzip to "C:\msys"
+
+ - *gcc for ARM, 4.9.3*
+
+ Download the Windows installer from [https://launchpad.net/gcc-arm-embedded/+download](https://launchpad.net/gcc-arm-embedded/+download) and install at "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3".
+
+ - OpenOCD 0.8.0
+
+ Download OpenOCD 0.8.0 from [http://www.freddiechopin.info/en/download/category/4-openocd](http://www.freddiechopin.info/en/download/category/4-openocd). Unzip to "C:\openocd".
+
+ - Zadig 2.1.2
+
+ Download it from [http://zadig.akeo.ie](http://zadig.akeo.ie) and install it at "C:\zadig".
+
+ - Git
+
+ Click on [https://git-scm.com/download/win](https://git-scm.com/download/win) to start the download. Install at "C:\Program Files (x86)\Git". Specify the "Use Git from the Windows Command Prompt" option. The defaults for all other options are OK.
+
+ - Go
+
+ Download the release for Microsoft Windows from [https://golang.org/dl/](https://golang.org/dl/) and install it "C:\Go".
+
+
+#### Creating local repository
+
+* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
+
+ * src contains Go source files organized into packages (one package per directory),
+
+ * pkg contains package objects, and
+
+ * bin contains executable commands.
+
+ The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory and then proceed to create the directory for cloning the newt tool repository.
+```no-highlight
+ $ cd c:\
+ $ mkdir dev\go
+ $ cd dev\go
+```
+* Set the following user environment variables using the steps outlined here.
+```no-highlight
+ * GOPATH: C:\dev\go
+ * PATH: C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin;%GOPATH%\bin;C:\win-builds-x86_64\bin;C:\win-builds-i686\bin;C:\msys\bin
+```
+ Steps:
+
+ 1. Right-click the start button
+ 2. Click "Control panel"
+ 3. Click "System and Security"
+ 4. Click "System"
+ 5. Click "Advanced system settings" in the left panel
+ 6. Click the "Envoronment Variables..." button
+ 7. There will be two sets of environment variables: user variables
+ in the upper half of the screen, and system variables in the lower
+ half. Configuring the user variables is recommended and tested
+ (though system variables will work as well).
+
+
+* Next, install godep. Note that the following command produces no output.
+```no-highlight
+ $ go get github.com/tools/godep
+```
+* Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the contents of the directory.
+```no-highlight
+ $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
+ $ dir
+ bin pkg src
+ $ dir src
+ git-wip-us.apache.org github.com gopkg.in
+ $ dir
+ newt
+ $ cd newt
+ $ dir
+ Godeps README.md coding_style.txt newt.go
+ LICENSE cli design.txt
+```
+* Check that newt is in place.
+```no-highlight
+ $ dir $GOPATH\src\git-wip-us.apache.org\repos\asf\incubator-mynewt-newt.git\newt
+ Godeps README.md coding_style.txt newt.go
+ LICENSE cli design.txt
+```
+
+
+#### Building the newt tool
+
+* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
+```no-highlight
+ $ go install
+ $ ls "$GOPATH"/bin/
+ godep incubator-mynewt-newt.git newt
+```
+* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
+
+ Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to define the newt environment variable that allows you to execute the command via `%newt%`. Use `set newt=go run %GOPATH%\src\github.com\mynewt\newt\newt.go` or set it from the GUI. Here, you use `go run` which runs the compiled binary directly without producing an executable.
+```no-highlight
+ $ newt version
+ Newt version: 1.0
+ $ newt -h
+ Newt allows you to create your own embedded project based on the Mynewt
+ operating system. Newt provides both build and package management in a
+ single tool, which allows you to compose an embedded workspace, and set
+ of projects, and then build the necessary artifacts from those projects.
+ For more information on the Mynewt operating system, please visit
+ https://www.github.com/mynewt/documentation.
+
+ Please use the newt help command, and specify the name of the command
+ you want help for, for help on how to use a specific command
+
+ Usage:
+ newt [flags]
+ newt [command]
+
+ Examples:
+ newt
+ newt help [<command-name>]
+ For help on <command-name>. If not specified, print this message.
+
+
+ Available Commands:
+ version Display the Newt version number.
+ target Set and view target information
+ egg Commands to list and inspect eggs on a nest
+ nest Commands to manage nests & clutches (remote egg repositories)
+ help Help about any command
+
+ Flags:
+ -h, --help=false: help for newt
+ -l, --loglevel="WARN": Log level, defaults to WARN.
+ -q, --quiet=false: Be quiet; only display error output.
+ -s, --silent=false: Be silent; don't output anything.
+ -v, --verbose=false: Enable verbose output when executing commands.
+
+
+ Use "newt help [command]" for more information about a command.
+```
+* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
+
+#### Getting the debugger ready
+
+* Use Zadig to configure the USB driver for your Olimex debugger. If your debugger is already set up, you can skip this step.
+
+ 1. Plug in your Olimex debugger.
+ 2. Start Zadig.
+ 3. Check the Options -> List All Devices checkbox.
+ 4. Select "Olimex OpenOCD JTAG ARM-USB-TINY-H" in the dropdown menu.
+ 5. Select the "WinUSB" driver.
+ 6. Click the "Install Driver" button.
+
+* Proceed to the section on how to [make an LED blink](#using-sram-to-make-led-blink) section.
+
+
+### Building test code on simulator
+
+Note: On a Windows computer, the simulator can be run only in a Linux virtual environment. Make sure you have installed the Docker instance as outlined in [an earlier section](#getting-your-windows-machine-ready-for-simulated-target). Consequently, all `newt` commands must be prefaced with `newtvm`.
+
+1. First, you have to create a repository for the project i.e. build your first nest! Go to ~/dev (or your base user directory on a Windows machine)and clone the larva repository from the apache git repository into a local directory named `larva`.
+
+ Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.
+
+```no-highlight
+ $ cd ~/dev
+ $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
+ $ ls
+ go larva
+ $ cd larva
+ $ ls
+ LICENSE clutch.yml hw nest.yml project
+ README.md compiler libs net scripts
+```
+ On Windows, open a command prompt (e.g., Windows-R, "cmd", enter) and work from your home directory:
+```no-highlight
+ C:\Users\admin> git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
+ C:\Users\admin> cd larva
+ C:\Users\admin\larva> dir
+ Volume in drive C is Windows
+ Volume Serial Number is 4CBB-0920
+
+ Directory of C:\Users\admin\larva
+
+ <DIR> .
+ <DIR> ..
+ 76 .gitignore
+ 0 .gitmodules
+ .nest
+ 6,133 clutch.yml
+ <DIR> compiler
+ <DIR> hw
+ <DIR> libs
+ 11,560 LICENSE
+ 20 nest.yml
+ <DIR> net
+ <DIR> project
+ 2,263 README.md
+ <DIR> scripts
+ 6 File(s) 20,052 bytes
+ 9 Dir(s) 90,723,442,688 bytes free
+```
+
+2\. You will now create a new target using the newt tool. You can either use the compiled binary `newt` or run the newt.go program using `$newt` (assuming you have stored the command in a variable in your .bash_profile or .bashrc). When you do a `newt target show` or `$newt target show` it should list all the projects you have created so far.
+```no-highlight
+ $ newt target create sim_test
+ Creating target sim_test
+ Target sim_test sucessfully created!
+ $ newt target show
+ sim_test
+ name: sim_test
+ arch: sim
+```
+ Remember, on a Windows machine you will have to preface `newt` with `newtvm`!
+```no-highlight
+ C:\Users\admin\larva>newtvm newt target create sim_test
+```
+3\. Now continue to populate and build out the sim project.
+```no-highlight
+ $ newt target set sim_test project=test
+ Target sim_test successfully set project to test
+ $ newt target set sim_test compiler_def=debug
+ Target sim_test successfully set compiler_def to debug
+ $ newt target set sim_test bsp=hw/bsp/native
+ Target sim_test successfully set bsp to hw/bsp/native
+ $ newt target set sim_test compiler=sim
+ Target sim_test successfully set compiler to sim
+ $ newt target show sim_test
+ sim_test
+ arch: sim
+ project: test
+ compiler_def: debug
+ bsp: hw/bsp/native
+ compiler: sim
+ name: sim_test
+```
+ Again remember to preface `newt` with `newtvm`on a Windows machine as shown below. Continue to fill out all the project attributes.
+```no-highlight
+ C:\Users\admin\larva>newtvm newt target set sim_test project=test
+ Target sim_test successfully set project to test
+```
+
+4\. Configure newt to use the gnu build tools native to OS X or linux. In order for sim to work properly, it needs to be using 32-bit gcc (gcc-5). Replace
+~/dev/larva/compiler/sim/compiler.yml with the compiler/sim/osx-compiler.yml or linux-compiler.yml file, depending on the system. On a Windows machine follow the instruction for the Linux machine as you are running commands in a Linux VM.
+
+ For a Mac OS X environment:
+```no-highlight
+ $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml
+```
+ For a Linux machine:
+```no-highlight
+ $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml
+```
+
+5\. Next, create (hatch!) the eggs for this project using the newt tool - basically, build the packages for it. You can specify the VERBOSE option if you want to see the gory details. Always remember to preface `newt` with `newtvm`on a Windows machine.
+```no-highlight
+ $ newt target build sim_test
+ Successfully run!
+```
+ You can specify the VERBOSE option if you want to see the gory details.
+```no-highlight
+ $newt -l VERBOSE target build sim_test
+ 2015/09/29 09:46:12 [INFO] Building project test
+ 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...
+ 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...
+ 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..
+ ...
+ Successfully run!
+```
+6\. Try running the test suite executable inside this project and enjoy your first successful hatch.
+```no-highlight
+ $ newt ./project/test/bin/sim_test/test.elf
+ [pass] os_mempool_test_suite/os_mempool_test_case
+ [pass] os_mutex_test_suite/os_mutex_test_basic
+ [pass] os_mutex_test_suite/os_mutex_test_case_1
+ [pass] os_mutex_test_suite/os_mutex_test_case_2
+ [pass] os_sem_test_suite/os_sem_test_basic
+ [pass] os_sem_test_suite/os_sem_test_case_1
+ [pass] os_sem_test_suite/os_sem_test_case_2
+ [pass] os_sem_test_suite/os_sem_test_case_3
+ [pass] os_sem_test_suite/os_sem_test_case_4
+ [pass] os_mbuf_test_suite/os_mbuf_test_case_1
+ [pass] os_mbuf_test_suite/os_mbuf_test_case_2
+ [pass] os_mbuf_test_suite/os_mbuf_test_case_3
+ [pass] gen_1_1/ffs_test_unlink
+ [pass] gen_1_1/ffs_test_rename
+ [pass] gen_1_1/ffs_test_truncate
+ [pass] gen_1_1/ffs_test_append
+ [pass] gen_1_1/ffs_test_read
+ [pass] gen_1_1/ffs_test_overwrite_one
+ [pass] gen_1_1/ffs_test_overwrite_two
+ [pass] gen_1_1/ffs_test_overwrite_three
+ ...
+ ...
+ [pass] boot_test_main/boot_test_vb_ns_11
+```
+
+### Using SRAM to make LED blink
+
+You are here because you want to build an image to be run from internal SRAM on the Olimex board.
+
+#### Preparing the Software
+
+* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory (or C:\%GOPATH%\bin on Windows machine).
+
+ Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows (e.g. `cd dev\go` instead of `cd dev/go`). The newt tool commands do not change.
+
+
+* If you have cloned the larva repository for the simulator test in the previous section you can skip this step. Otherwise, you have to create a repository for the project i.e. build your first nest! Go to ~/dev and clone the larva repository from the apache git repository into a local directory named `larva`.
+
+ Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.
+
+```no-highlight
+ $ cd ~/dev
+ $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
+ $ ls
+ go larva
+ $ cd larva
+ $ ls
+ LICENSE clutch.yml hw nest.yml project
+ README.md compiler libs net scripts
+```
+
+* You first have to create a repository for the project. Go to the ~dev/larva directory and build out a second project inside larva. The project name is "blinky", in keeping with the objective. Starting with the target name, you have to specify the different aspects of the project to pull the appropriate eggs and build the right package for the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.
+
+ Remember to prefix each command with "newtvm" if you are executing the newt command in a Linux virtual machine on your Windows box!
+
+```no-highlight
+ $ newt target create blinky
+ Creating target blinky
+ Target blinky sucessfully created!
+ $ newt target set blinky arch=cortex_m4
+ Target blinky successfully set arch to arm
+ $ newt target set blinky compiler=arm-none-eabi-m4
+ Target blinky successfully set compiler to arm-none-eabi-m4
+ $ newt target set blinky project=blinky
+ Target blinky successfully set project to blinky
+ $ newt target set blinky compiler_def=debug
+ Target blinky successfully set compiler_def to debug
+ $ newt target set blinky bsp=hw/bsp/olimex_stm32-e407_devboard
+ Target blinky successfully set bsp to hw/bsp/olimex_stm32-e407_devboard
+ $ newt target show blinky
+ blinky
+ compiler: arm-none-eabi-m4
+ project: blinky
+ compiler_def: debug
+ bsp: hw/bsp/olimex_stm32-e407_devboard
+ name: blinky
+ arch: cortex_m4
+```
+
+* Now you have to build the image. The linker script within the `hw/bsp/olimex_stm32-e407_devboard` egg builds an image for flash memory by default. Since you want an image for the SRAM, you need to switch that script with `run_from_sram.ld` in order to get the egg to produce an image for SRAM. <font color="red"> We are working on making it easier to specify where the executable will be run from for a particular project and automatically choose the correct linker scripts and generate the appropriate image. It will be specified as a project identity e.g. bootloader, RAM, flash (default) and the target will build accordingly. </font>.
+
+ Once the target is built, you can find the executable "blinky.elf" in the project directory at ~/dev/larva/project/blinky/bin/blinky. It's a good idea to take a little time to understand the directory structure.
+```no-highlight
+ $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
+ $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
+ $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld
+ $ cd ~/dev/larva/project/blinky/bin/blinky
+ $ newt target build blinky
+ Building target blinky (project = blinky)
+ Compiling case.c
+ Compiling suite.c
+ ...
+ Successfully run!
+ $ ls
+ LICENSE clutch.yml hw nest.yml project
+ README.md compiler libs net scripts
+ $ cd project
+ $ ls
+ bin2img bletest blinky boot ffs2native test
+ $ cd blinky
+ $ ls
+ bin blinky.yml egg.yml src
+ $ cd bin
+ $ ls
+ blinky
+ $ cd blinky
+ $ ls
+ blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map
+```
+
+* Check that you have all the scripts needed to get OpenOCD up and talking with the project's specific hardware. Depending on your system (Ubuntu, Windows) you may already have the scripts in your `/usr/share/openocd/scripts/ ` directory as they may have been part of the openocd download. If yes, you are all set and can proceed to preparing the hardware.
+
+ Otherwise check the `~/dev/larva/hw/bsp/olimex_stm32-e407_devboard` directory for a file named `f407.cfg`. That is the config we will use to talk to this specific hardware using OpenOCD. You are all set if you see it.
+```no-highlight
+ $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
+ bin olimex_stm32-e407_devboard_debug.sh
+ boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard_download.sh
+ egg.yml run_from_flash.ld
+ f407.cfg run_from_loader.ld
+ include run_from_sram.ld
+ olimex_stm32-e407_devboard.ld src
+```
+
+#### Preparing the hardware to boot from embedded SRAM
+
+1. Locate the boot jumpers on the board.
+
+
+
+2. B1_1/B1_0 and B0_1/B0_0 are PTH jumpers which can be moved relatively easy. Note that the markings on the board may not always be accurate. Always refer to the manual for the correct positioning of jumpers in case of doubt. The two jumpers must always be moved together – they are responsible for the boot mode if bootloader is present. The board can search for bootloader on three places – User Flash Memory, System Memory or the Embedded SRAM. We will configure it to boot from SRAM by jumpering B0_1 and B1_1.
+
+3. Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
+
+4. The red PWR LED should be lit.
+
+5. Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
+
+
+
+#### Let's Go!
+
+* Make sure you are in the blinky project directory with the blinky.elf executable. Run the debug command in the newt tool. You should see some status messages are shown below. There is an inbuilt `-c "reset halt"` flag that tells it to halt after opening the session.
+```no-highlight
+ $ cd dev/larva/project/blinky/bin/blinky
+ $ newt target debug blinky
+ Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky
+ Debugging /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf
+ GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+ and "show warranty" for details.
+ This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
+ Type "show configuration" for configuration details.
+ For bug reporting instructions, please see:
+ <http://www.gnu.org/software/gdb/bugs/>.
+ Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+ For help, type "help".
+ Type "apropos word" to search for commands related to "word"...
+ Reading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/ blinky/blinky.elf...done.
+ Open On-Chip Debugger 0.8.0 (2015-09-22-18:21)
+ Licensed under GNU GPL v2
+ For bug reports, read
+ http://openocd.sourceforge.net/doc/doxygen/bugs.html
+ Info : only one transport option; autoselect 'jtag'
+ adapter speed: 1000 kHz
+ adapter_nsrst_delay: 100
+ jtag_ntrst_delay: 100
+ Warn : target name is deprecated use: 'cortex_m'
+ DEPRECATED! use 'cortex_m' not 'cortex_m3'
+ cortex_m reset_config sysresetreq
+ Info : clock speed 1000 kHz
+ Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
+ Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
+ Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
+ Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
+ Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
+ target state: halted
+ target halted due to debug-request, current mode: Thread
+ xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000
+ Info : accepting 'gdb' connection from 3333
+ Info : device id = 0x10036413
+ Info : flash size = 1024kbytes
+ Reset_Handler () at startup_STM32F40x.s:199
+ 199 ldr r1, =__etext
+```
+
+ Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdp tool and load the image on it.
+```no-highlight
+ (gdb) set $msp=0x10010000
+```
+ Now load the image and type "c" or "continue" from the GNU debugger.
+
+```no-highlight
+ (gdb) load ~/dev/larva/project/blinky/bin/blinky/blinky.elf
+ Loading section .text, size 0x4294 lma 0x20000000
+ Loading section .ARM.extab, size 0x24 lma 0x20004294
+ Loading section .ARM.exidx, size 0xd8 lma 0x200042b8
+ Loading section .data, size 0x874 lma 0x20004390
+ Start address 0x20000250, load size 19460
+ Transfer rate: 81 KB/sec, 2432 bytes/write.
+ (gdb) c
+ Continuing.
+```
+
+* Voilà! The board's LED should be blinking at 1 Hz.
+
+### Using flash to make LED blink
+
+You are here because you want to build an image to be run from flash memory on the Olimex board.
+
+* Configure the board to boot from flash by moving the two jumpers together to B0_0 and B1_0. Refer to the pictures of the board under the section titled ["Preparing the hardware to boot from embedded SRAM"](#preparing-the-hardware-to-boot-from-embedded-sram).
+
+ You will have to reset the board once the image is uploaded to it.
+
+* If you skipped the first option for the project [(downloading an image to SRAM)](#using-sram-to-make-led-blink), then skip this step. Otherwise, continue with this step.
+
+ By default, the linker script (`olimex_stm32-e407_devboard.ld`) is configured to run from bootloader and flash. However, if you first ran the image from SRAM you had changed `olimex_stm32-e407_devboard.ld` to match `run_from_sram.ld`. You will therefore return to defaults with `olimex_stm32-e407_devboard.ld` linker script matching the contents of 'run_from_loader.ld'. Return to the project directory.
+```no-highlight
+ $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
+ $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
+ $ diff olimex_stm32-e407_devboard.ld run_from_loader.ld
+ $ cp run_from_loader.ld olimex_stm32-e407_devboard.ld
+ $ cd ~/dev/larva/project/blinky/bin/blinky
+```
+
+* In order to run the image from flash, you need to build the bootloader as well. The bootloader does the initial bring up of the Olimex board and then transfers control to the image stored at a location in flash known to it. The bootloader in turn requires the bin2image tool to check the image header for version information, CRC checks etc. So, we will need to build these two additional targets (bootloader and bin2img).
+
+ Let's first create bin2img:
+```no-highlight
+ $ newt target create bin2img
+ Creating target bin2img
+ Target bin2img successfully created!
+ $ newt target set bin2img arch=sim
+ Target bin2img successfully set arch to sim
+ $ newt target set bin2img compiler=sim
+ Target bin2img successfully set compiler to sim
+ $ newt target set bin2img project=bin2img
+ Target bin2img successfully set project to bin2img
+ $ newt target set bin2img compiler_def=debug
+ Target bin2img successfully set compiler_def to debug
+ $ newt target set bin2img bsp=hw/bsp/native
+ Target bin2img successfully set bsp to hw/bsp/native
+ $ newt target show bin2img
+ bin2img
+ arch: sim
+ compiler: sim
+ project: bin2img
+ compiler_def: debug
+ bsp: hw/bsp/native
+ name: bin2img
+```
+ And then let's create boot_olimex:
+```no-highlight
+ $ newt target create boot_olimex
+ Creating target boot_olimex
+ Target boot_olimex successfully created!
+ $ newt target set boot_olimex arch=cortex_m4
+ Target boot_olimex successfully set arch to cortex_m4
+ $ newt target set boot_olimex compiler=arm-none-eabi-m4
+ Target boot_olimex successfully set compiler to arm-none-eabi-m4
+ $ newt target set boot_olimex project=boot
+ Target boot_olimex successfully set project to boot
+ $ newt target set boot_olimex compiler_def=optimized
+ Target boot_olimex successfully set compiler_def to optimized
+ $ newt target set boot_olimex bsp=hw/bsp/olimex_stm32-e407_devboard
+ Target boot_olimex successfully set bsp to hw/bsp/olimex_stm32-e407_devboard
+ $ newt target show boot_olimex
+ boot_olimex
+ project: boot
+ compiler_def: optimized
+ bsp: hw/bsp/olimex_stm32-e407_devboard
+ name: boot_olimex
+ arch: cortex_m4
+ compiler: arm-none-eabi-m4
+```
+* Let's build all the three targets now.
+```no-highlight
+ $ newt target build bin2img
+ Building target bin2img (project = bin2img)
+ Building project bin2img
+ Successfully run!
+ $ newt target build boot_olimex
+ Building target boot_olimex (project = boot)
+ Building project boot
+ Successfully run!
+ $ newt target build blinky
+ Building target blinky (project = blinky)
+ Building project blinky
+ Successfully run!
+```
+
+* Go to the project directory and download the bootloader and the image to flash ... in a flash!
+```no-highlight
+ $ cd ~/dev/larva/project/blinky/bin/blinky
+ $ newt target download boot_olimex
+ Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh
+ $ newt target download blinky
+ Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh
+```
+
+* The LED should be blinking!
+
+* But wait...let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor. The debug connection to the JTAG port is now severed. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
+
+ The LED light will start blinking again. Success!
+
+ Note #1: If you want to download the image to flash and a gdb session opened up, use `newt target debug blinky` instead of `newt target download blinky`.
+```no-highlight
+ $ newt target debug blinky
+ Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky
+ Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf
+ GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+ and "show warranty" for details.
+ This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
+ Type "show configuration" for configuration details.
+ For bug reporting instructions, please see:
+ <http://www.gnu.org/software/gdb/bugs/>.
+ Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+ For help, type "help".
+ Type "apropos word" to search for commands related to "word"...
+ Reading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf...done.
+ Open On-Chip Debugger 0.8.0 (2015-09-22-18:21)
+ Licensed under GNU GPL v2
+ For bug reports, read
+ http://openocd.sourceforge.net/doc/doxygen/bugs.html
+ Info : only one transport option; autoselect 'jtag'
+ adapter speed: 1000 kHz
+ adapter_nsrst_delay: 100
+ jtag_ntrst_delay: 100
+ Warn : target name is deprecated use: 'cortex_m'
+ DEPRECATED! use 'cortex_m' not 'cortex_m3'
+ cortex_m reset_config sysresetreq
+ Info : clock speed 1000 kHz
+ Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
+ Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
+ Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
+ Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
+ Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
+ target state: halted
+ target halted due to debug-request, current mode: Thread
+ xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
+ Info : accepting 'gdb' connection from 3333
+ Info : device id = 0x10036413
+ Info : flash size = 1024kbytes
+ Reset_Handler () at startup_STM32F40x.s:199
+ 199 ldr r1, =__etext
+ (gdb)
+```
+
+ Note #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. `flash erase_sector 0 0 x` tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma' you should therefore see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.
+```no-highlight
+ (gdb) monitor flash erase_sector 0 0 4
+ erased sectors 0 through 4 on flash bank 0 in 2.296712s
+ (gdb) monitor mdw 0x08000000 16
+ 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (gdb) monitor flash info 0
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/try_markdown.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/try_markdown.md b/docs/os/get_started/try_markdown.md
new file mode 100644
index 0000000..e35707c
--- /dev/null
+++ b/docs/os/get_started/try_markdown.md
@@ -0,0 +1,32 @@
+## Try Markdown
+
+### Heading3
+
+#### Heading4
+
+- - -
+
+##### List
+
+* Start with one # for the largest heading (Heading1). The next smaller heading (Heading2) starts with ##. You can go all the way up to Heading 6 (######).
+
+* Heading4 (####) and Heading5 (#####) has been styled to show up underlined. Yes, it can be changed. If you are curious, you can look at the extra.css file in your repo branch.
+
+* It's **very** easy to do **bold** and *italics*.
+
+* See how this list has been made using *
+
+* Click on "Help" in Mou and then on "Markdown Syntax Reference".
+
+* <font color="red"> Substitute a sentence of your own here </font>
+
+* <font color="red"> Guinea Pig!!! </font>
+
+---
+
+> <font color="red"> Note! </font>
+>> You will not be able to see the change immediately by refreshing your browser right after editign the Markdown file. You can only push the change to the Apache repository. So continue with the steps in [how_to_edit_docs.md](how_to_edit_docs.md).
+>>
+>> You can see the change on the website if/when a doc builder on the project team merges your changes to the master branch and generates the pages for the website.
+>>
+>> You do have the option to download MkDocs and preview the change by hosting the pages locally using its built-in web server. The steps are described in [how_to_edit_docs.md](how_to_edit_docs.md).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/get_started/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/vocabulary.md b/docs/os/get_started/vocabulary.md
new file mode 100644
index 0000000..e240f62
--- /dev/null
+++ b/docs/os/get_started/vocabulary.md
@@ -0,0 +1,170 @@
+## Understanding Newt Terms
+
+### Nest
+
+The nest is the base directory of your embedded software. It is meant to be the workspace containing a logical collection of the source code for one or more of your projects. A nest can contain multiple projects, and reflect multiple end products.
+
+As the base repository of your source code, the nest has a master branch and several other branches off it. You may choose any branch to nest on. Each project in your nest will typically consist of several [eggs](#egg). A project could be an egg itself as well. In addition to eggs, a local nest will contain additional items such as [target](#target) or build definitions, clutch description files, scripts etc.
+
+For example, a walk through the "larva" nest at [https://github.com/mynewt/larva.git](https://github.com/mynewt/larva.git) shows the following structure. The nest.yml file in the larva directory indicates that it is a nest. An egg will have the egg.yml file in it as shown below. By this nomenclature, each board support package for a particular chip is an egg, the API for the hardware abstraction layer is an egg, and so on.
+
+```no-highlight
+larva
+ |- nest.yml
+ |- compiler
+ |- arm-none-eabi-m4
+ |- sim
+ |- hw (hardware)
+ |- bsp (board support package)
+ |- nrf52pdk (Nordic nRF52 series chip)
+ |- egg.yml
+ |- ...
+ |- olimex_stm32-e407_devboard (used in Project Blinky)
+ |- egg.yml
+ |- ...
+ |- stm32f3discovery (another board with stm32f3 mcu)
+ |- egg.yml
+ |- ...
+ |- yet another board
+ |- egg.yml
+ |- ...
+ |- hal (hardware abstraction layer APIs)
+ |- egg.yml
+ |- include
+ |- hal_cputime.h
+ |- hal_flash.h
+ |- hal_gpio.h
+ |- ... (header files for other peripherals)
+ |- mcu (microcontroller)
+ |- stm (STMicro family)
+ |- stm32f3xx (STM32f3 series, 32-bit ARM Cortex-M4 core)
+ |- egg.yml
+ |- src
+ |- hal_gpio.c (specific to the STM32f3 mcu)
+ |- hal_cputime.c
+ |- ... (code for other peripherals)
+ |- nordic (Nordic Semiconductor family)
+ |- nrf52xxx (nRF52 Series SoC, Cortex-M4F core)
+ |- egg.yml
+ |- src
+ |- hal_gpio.c (specific to the nRF52 mcu )
+ |- hal_cputime.c
+ |- ... (code for other peripherals)
+ |- yet another family of mcu
+ |- ...
+ |- libs
+ |- bootutil (hw architecture independent boot loader library)
+ |- egg.yml
+ |- src
+ |- loader.c
+ |- ... (related source code files)
+ |- nffs (hw architecture independent Newtron Flash File System)
+ |- egg.yml
+ |- src
+ |- nffs.c
+ |- ... (related source code files)
+ |- another library
+ |- egg.yml
+ |- src
+ |- ... (related source code files)
+ |- project
+ |- scripts
+
+
+```
+
+The newt tool offers the `nest` command to create and manage nests. In general, commands represent actions and flags are modifiers for those actions. A command can have children commands and optionally run an action. A full description of the `nest` command can be found in the newt tool reference in Chapter 3.
+```no-highlight
+ newt nest [flags]
+ newt nest [child-commands]
+```
+A complete list of all the nest commands can be found in the newt tool reference in [Newt Tool](../../newt/newt_tool_reference.md).
+
+### Project
+
+Projects represent the individual build configurations of your embedded system and essentially defines your application. The project files are what dictate the resulting binary that is generated.
+
+Layout-wise, a project is a directory inside a nest and contains eggs required for a certain application. For example, the `blinky` egg sits in `project/blinky` directory of the `larva` nest. This egg is used in the blinky project (application) outlined in [Get Started](../get_started/project1.md). <*Note: This Will Change*>
+
+A project has the following concepts or properties associated with it. You can find them in the `<project-name>.yml` file in the project directory. For example, the `project/blinky` directory has the `blinky.yml` file indicating some or all of the properties below. Only the name of a project is required for the project to exist, however additional properties may need to be specified for the eggs in it to compile properly and produce an executable.
+
+* Project name
+* Base path of the project (nest/project/project-name by default)
+* Eggs belonging to the project
+* [Capabilities](#capabilities) that are required for the project or target
+* [Identity](#identity) to classify the type of project or target
+* Compiler flags to call out any specific compiler requirement
+
+A project could itself be an egg if it is a distributable package for a specific application.
+
+The newt tool offers various commands that you can use with a project. For example, if your project is an egg, you can use the following command to install a project from a nest.
+```no-highlight
+ newt egg install [flags] <project egg name>
+```
+### Egg
+
+An egg is a distributable package of libraries. Just as an egg in nature has various parts each of which serves a certain purpose, the Mynewt egg consists of software parcels or modules that have different functions. However, unlike the egg in nature these software modules can exist by itself and may be distributed; therefore, they too are essentially eggs. Once this concept is grasped it is easy to see how an egg may consist of other eggs.
+
+The two main directories in an egg are `/include` and `/src`.
+
+The newt tool offers several egg commands to list, inspect, install, and do other operations on eggs. For example, the following command
+```no-highlight
+ newt egg list
+```
+outputs all the eggs in the current nest where each egg has details on its version, path, and dependencies. A sample output for an egg is given below.
+```no-highlight
+ Egg libs/os, version 0.1.0
+ path: /Users/aditihilbert/dev/test_project/libs/os
+ deps: libs/testutil@none#stable
+```
+A complete list of all the egg commands can be found in the newt tool reference in [Newt Tool](../../newt/newt_tool_reference.md).
+
+### Clutch
+
+A clutch is a snapshot of all eggs in a remote nest at any point in time. On any given github branch, a nest with a clutch of eggs will contain a `clutch.yml` file that specifies the version number, dependencies, and hash value for each constituent egg as well as the name of the entire clutch and the github url for it. [Note: Currently ]
+
+You may download multiple clutches into your local nest as long as the names of the clutches are different. This allows you to mix and match various features and functionality coming from different clutches of eggs. You can see all the clutches in the `.nest/clutches` directory in your nest.
+
+The newt tool offers clutch management commands within the `newt nest` command. For example, the following command creates a new clutch using all the eggs in the current directory. It requires that a clutch name be specified and the url for the location of that clutch in the online repository. These two inputs go into the `clutch.yml` file in the nest.
+```no-highlight
+ newt nest generate-clutch <name> <url>
+```
+Note that a clutch merely defines the eggs belonging together and requires the eggs to be installed (hatched) for the source code to be populated in the project.
+
+### Eggshell
+
+The term eggshell is used to refer to the eggs of a clutch in a remote repository. They are not useful on your local machine until you actually install them. So they are mere shells of themselves while sitting on the online repository. When you enter the following command outputs the total number of shells in each remote clutch.
+```no-highlight
+ newt nest list-clutches
+```
+So, if you had two clutches installed, the output could be:
+```no-highlight
+ Remote clutch larva (eggshells: 19)
+ Remote clutch ble_test (eggshells: 15)
+```
+### Target
+
+A target is the hardware build or its software equivalent (e.g. test, simulator) set for a project. It tells the newt tool how to build the source code within a given nest. Once a new target is created, its architecture and other details needs to be defined. An example of a defined target named "blink_f3disc" is given below.
+```no-highlight
+ blink_f3disc
+ compiler_def: debug
+ compiler: arm-none-eabi-m4
+ name: blink_f3disc
+ arch: cortex_m4
+ project: blinky
+ bsp: hw/bsp/stm32f3discovery
+```
+The newt tool offers commands to create, set up and manipulate targets. For example, the create command below creates an empty target named `my_target1` and the set command sets one detail of its definition, namely the architecture.
+```no-highlight
+ newt target create my_target1
+ newt target set my_target1 arch=cortex_m4
+```
+### Capability
+
+Capability is functionality that is exposed by an egg. A capability is tracked by its name and version. An egg may require capabilities exposed by another egg, thus establishing a dependency tracked through the egg.yml files.
+
+The newt tool can ascertain a map of all the egg capabilities and use it to check dependencies and make sure all the necessary eggs are in a project for a particular target.
+
+### Identity
+
+Identity is a property of a target or project in the newt world. A target may inherit it from a project or vice versa. It may be used to determine what eggs to include or how an egg code should behave in a build or which linkerscripts to use. For example, the identity of a lock is different from the identity of a wearable monitor. Even if they were to be built on the same hardware target, different features and behavior are required. Their different identities result in differing sets of eggs in the projects and/or the same egg behaving differently depending on the identity.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/heap.md
----------------------------------------------------------------------
diff --git a/docs/os/heap.md b/docs/os/heap.md
deleted file mode 100644
index 61aea3c..0000000
--- a/docs/os/heap.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Heap
-
-
-API for doing dynamic memory allocation.
-
-
-## Description
-
-This provides malloc()/free() functionality with locking. The shared resource heap needs to be protected from concurrent access when OS has been started. *os_malloc()* function grabs a mutex before calling *malloc()*.
-
-## Data structures
-
-N/A
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_malloc](#os_malloc)
-* [os_free](#os_free)
-* [os_realloc](#os_realloc)
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_malloc</font>
-
-```no-highlight
-void *os_malloc(size_t size)
-```
-
-Allocates *size* number of bytes from heap and returns a pointer to it.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| size | Number of bytes to allocate |
-
-#### Returned values
-
-<ptr>: pointer to memory allocated from heap.
-NULL: not enough memory available.
-
-#### Notes
-
-*os_malloc()* calls *malloc()*, which is provided by C-library. The heap must be set up during platform initialization.
-Depending on which C-library you use, you might have to do the heap setup differently. Most often *malloc()* implementation will maintain a list of allocated and then freed memory blocks. If user asks for memory which cannot be satisfied from free list, they'll call platform's *sbrk()*, which then tries to grow the heap.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- info = (struct os_task_info *) os_malloc(
- sizeof(struct os_task_info) * tcount);
- if (!info) {
- rc = -1;
- goto err;
- }
-```
-
----------------------
-
-## <font color="F2853F" style="font-size:24pt">os_free</font>
-
-```no-highlight
-void os_free(void *mem)
-```
-
-Frees previously allocated memory back to the heap.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mem | Pointer to memory being released |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Calls C-library *free()* behind the covers.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- os_free(info);
-```
-
----------------------
-
-## <font color="F2853F" style="font-size:24pt">os_realloc</font>
-
-```no-highlight
-void *os_realloc(void *ptr, size_t size)
-```
-
-Tries to resize previously allocated memory block, and returns pointer to resized memory.
-ptr can be NULL, in which case the call is similar to calling *os_malloc()*.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ptr | Pointer to previously allocated memory |
-| size | New size to adjust the memory block to |
-
-#### Returned values
-
-NULL: size adjustment was not successful. <br>
-ptr: pointer to new start of memory block
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/mbufs.md
----------------------------------------------------------------------
diff --git a/docs/os/mbufs.md b/docs/os/mbufs.md
deleted file mode 100644
index 3086b3c..0000000
--- a/docs/os/mbufs.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Mbufs
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_mbuf_pool_init](#os_mbuf_pool_init)
-* [os_mbuf_get](#os_mbuf_get)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_mbuf_pool_init</font>
-
-```no-highlight
- int
- os_mbuf_pool_init(struct os_mbuf_pool *omp, struct os_mempool *mp,
- uint16_t hdr_len, uint16_t buf_len, uint16_t nbufs)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_mbuf_get</font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-## <font color="F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
- <Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/memory_pool.md
----------------------------------------------------------------------
diff --git a/docs/os/memory_pool.md b/docs/os/memory_pool.md
deleted file mode 100644
index f030de8..0000000
--- a/docs/os/memory_pool.md
+++ /dev/null
@@ -1,217 +0,0 @@
-# Memory Pools
-
-
-Memory can be pre-allocated to a pool of fixed size elements.
-
-
-## Description
-
-Sometimes it's useful to have several memory blocks of same size preallocated for specific use. E.g. you want to limit the amount of memory used for it, or you want to make sure that there is memory available when you ask for it.
-
-This can be done using a memory pool. You allocate memory either statically or from heap, and then designate that memory to be used as storage for fixed size elements.
-
-Pool will be initialized by calling *os_mempool_init()*. Element can be allocated from it with *os_mempool_get()*, and released back with *os_mempool_put()*.
-
-## Data structures
-
-```no-highlight
-struct os_mempool {
- int mp_block_size;
- int mp_num_blocks;
- int mp_num_free;
- SLIST_HEAD(,os_memblock);
- char *name;
-};
-```
-| Element | Description |
-|-----------|-------------|
-| mp_block_size | Size of the memory blocks, in bytes |
-| mp_num_blocks | Number of memory blocks in the pool |
-| mp_num_free | Number of free blocks left |
-| name | Name for the memory block |
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-* [os_mempool_init](#os_mempool_init)
-* [os_memblock_get](#os_memblock_get)
-* [os_memblock_put](#os_memblock_put)
-* [OS_MEMPOOL_BYTES](#OS_MEMPOOL_BYTES)
-
-
-## Function Reference
-
-------------------
-
-## <font color="F2853F" style="font-size:24pt"> os_mempool_init</font>
-
-```no-highlight
-os_error_t os_mempool_init(struct os_mempool *mp, int blocks, int block_size, void *membuf, char *name)
-```
-
-Initializes the memory pool. Memory pointed by *membuf* is taken and *blocks* number of elements of size *block_size* are added to the pool. *name* is optional, and names the memory pool.
-
-It is assumed that the amount of memory pointed by *membuf* has at least *OS_MEMPOOL_BYTES(blocks, block_size)* number of bytes.
-
-*name* is not copied, so caller should make sure that the memory does not get reused.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Memory pool being initialized |
-| blocks | Number of elements in the pool |
-| block_size | Size of an individual element in pool |
-| membuf | Backing store for the memory pool elements |
-| name | Name of the memory pool |
-
-#### Returned values
-
-OS_OK: operation was successful.
-OS_INVALID_PARAM: invalid parameters. Block count or block size was negative, or membuf or mp was NULL.
-OS_MEM_NOT_ALIGNED: membuf has to be aligned to 4 byte boundary.
-
-#### Notes
-
-Note that os_mempool_init() does not allocate backing storage. *membuf* has to be allocated by the caller.
-
-It's recommended that you use *OS_MEMPOOL_BYTES()* to figure out how much memory to allocate for the pool.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- rc = os_mempool_init(&nffs_file_pool, nffs_config.nc_num_files,
- sizeof (struct nffs_file), nffs_file_mem,
- "nffs_file_pool");
- if (rc != 0) {
- return FS_EOS;
- }
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_memblock_get</font>
-
-```no-highlight
-void *os_memblock_get(struct os_mempool *mp)
-```
-
-Allocate an element from the memory pool. If succesful, you'll get a pointer to allocated element. If there are no elements available, you'll get NULL as response.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Pool where element is getting allocated from |
-
-#### Returned values
-
-NULL: no elements available.
-<pointer>: pointer to allocated element.
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- struct nffs_file *file;
-
- file = os_memblock_get(&nffs_file_pool);
- if (file != NULL) {
- memset(file, 0, sizeof *file);
- }
-
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_memblock_put</font>
-
-```no-highlight
-os_error_t os_memblock_put(struct os_mempool *mp, void *block_addr)
-```
-
-Releases previously allocated element back to the pool.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Pointer to memory pool where element is put |
-| block_addr | Pointer to element getting freed |
-
-#### Returned values
-
-OS_OK: operation was a success:
-OS_INVALID_PARAM: If either mp or block_addr were NULL.
-
-#### Notes
-
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- if (file != NULL) {
- rc = os_memblock_put(&nffs_file_pool, file);
- if (rc != 0) {
- return FS_EOS;
- }
- }
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">OS_MEMPOOL_BYTES</font>
-
-```no-highlight
-OS_MEMPOOL_BYTES(n,blksize)
-```
-
-Calculates how many bytes of memory is used by *n* number of elements, when individual element size is *blksize* bytes.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| n | Number of elements |
-| blksize | Size of an element is number of bytes |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-
-#### Example
-
-Here we allocate memory to be used as a pool.
-
-```no-highlight
-void *nffs_file_mem;
-
-nffs_file_mem = malloc(
- OS_MEMPOOL_BYTES(nffs_config.nc_num_files, sizeof (struct nffs_file)));
- if (nffs_file_mem == NULL) {
- return FS_ENOMEM;
- }
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/baselibc.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/baselibc.md b/docs/os/modules/baselibc.md
new file mode 100644
index 0000000..38cf2a3
--- /dev/null
+++ b/docs/os/modules/baselibc.md
@@ -0,0 +1,174 @@
+# Baselibc
+
+baselibc is a very simple libc for embedded systems geared primarily for 32-bit microcontrollers in the 10-100kB memory range. The library of basic system calls and facilities compiles to less than 5kB total on Cortex-M3, and much less if some functions aren't used.
+
+The code is based on klibc and tinyprintf modules, and licensed under the BSD license.
+
+## Description
+
+Mynewt Os comes bundled with libc (the standard C library). However, you may choose to replace libc functions with baselibc ones for a reduced image size.
+
+## How to switch to baselibc
+
+In order to switch from using libc to using baselibc you have to add the baselibc egg as dependency in the project egg. Specifying this dependency ensures that the linker first looks for the functions in baselibc before falling back to libc while creating the executable. For example, project `boot` uses baselibc. Its project description file `boot.yml` looks like the following:
+
+```no-highlight
+ project.name: boot
+ project.identities: bootloader
+ project.eggs:
+ - libs/os
+ - libs/bootutil
+ - libs/nffs
+ - libs/console/stub
+ - libs/util
+ - libs/baselibc
+ ```
+
+## List of Functions
+
+The functions available in this OS feature are listed below. Documentation is available in the form of on-line manual pages or at [https://www.freebsd.org/cgi/man.cgi](#https://www.freebsd.org/cgi/man.cgi). `mynewt.c` adds two new functions listed in the Function reference section.
+
+* asprintf.c
+* atoi.c
+* atol.c
+* atoll.c
+* bsearch.c
+* bzero.c
+* calloc.c
+* fgets.c
+* inline.c
+* jrand48.c
+* lrand48.c
+* malloc.c
+* malloc.h
+* memccpy.c
+* memchr.c
+* memcmp.c
+* memcpy.c
+* memfile.c
+* memmem.c
+* memmove.c
+* memrchr.c
+* memset.c
+* memswap.c
+* mrand48.c
+* mynewt.c
+* nrand48.c
+* qsort.c
+* realloc.c
+* sprintf.c
+* srand48.c
+* sscanf.c
+* strcasecmp.c
+* strcat.c
+* strchr.c
+* strcmp.c
+* strcpy.c
+* strcspn.c
+* strdup.c
+* strlcat.c
+* strlcpy.c
+* strlen.c
+* strncasecmp.c
+* strncat.c
+* strncmp.c
+* strncpy.c
+* strndup.c
+* strnlen.c
+* strntoimax.c
+* strntoumax.c
+* strpbrk.c
+* strrchr.c
+* strsep.c
+* strspn.c
+* strstr.c
+* strtoimax.c
+* strtok.c
+* strtok_r.c
+* strtol.c
+* strtoll.c
+* strtoul.c
+* strtoull.c
+* strtoumax.c
+* templates
+* test
+* tinyprintf.c
+* vasprintf.c
+* vprintf.c
+* vsprintf.c
+* vsscanf.c
+
+## Function Reference
+
+------------------
+
+## <font color="F2853F" style="font-size:24pt"> stdin_read </font>
+
+```no-highlight
+ static size_t
+ stdin_read(FILE *fp, char *bp, size_t n)
+```
+
+Read from a file.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| fp | pointer to the input file |
+| bp | pointer to the string to be read |
+| n | size of buffer (number of characters) to be read |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+N/A
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
+## <font color="#F2853F" style="font-size:24pt"> stdout_write </font>
+
+```no-highlight
+ static size_t
+ stdout_write(FILE *fp, const char *bp, size_t n)
+```
+
+Write to a file or console.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| fp | pointer to the output file |
+| bp | pointer to the string to be written |
+| n | size of buffer (number of characters) to be output |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+N/A
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/modules/bootloader/boot_build_status.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/boot_build_status.md b/docs/os/modules/bootloader/boot_build_status.md
new file mode 100644
index 0000000..e69de29
[6/9] incubator-mynewt-site git commit: added pages for the Core OS
functions
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/shelltest/shelltest.md
----------------------------------------------------------------------
diff --git a/docs/modules/shelltest/shelltest.md b/docs/modules/shelltest/shelltest.md
deleted file mode 100644
index 45535b5..0000000
--- a/docs/modules/shelltest/shelltest.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Console
-
-
-The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS.
-
-Support is currently available for console access via the serial port on the hardware board.
-
-
-## Description
-
-In the Mynewt OS, the console library comes in two versions:
-
-* full - containing the full implementation
-* stub - containing stubs for the API
-
-Both of these have `egg.yml` file which states that they provide the `console` API. If an egg uses this API, it should list `console` as a requirement.
-For example, the shell egg is defined by the following egg.yml file:
-```no-highlight
- egg.name: libs/shell
- egg.vers: 0.1
- egg.deps:
- - libs/os
- - libs/util
- egg.reqs:
- - console
- egg.identities:
- - SHELL
-```
-The project .yml file decides which version of the console egg should be included.
-If project requires the full console capability it lists dependency `libs/console/full` in its egg.yml file.
-On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` egg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead and the egg.yml file for the project boot egg looks like the following:
-```no-highlight
- project.name: boot
- project.identities: bootloader
- project.eggs:
- - libs/os
- - libs/bootutil
- - libs/nffs
- - libs/console/stub
- - libs/util
-```
-
-Console has 2 modes for transmit; blocking and non-blocking mode. Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.
-Blocking mode is used when we don't want TX completion interrupts. This is used when system crashes, and we still want to output info related to that crash.
-
-## Data structures
-
-
-Console interaction is intrinsically composed of two unidirectional systems. The console implementation uses two ring buffers containing input (receive) and output (transmit) characters, respectively. Read and write operations on the console_ring structure are managed by labeling the read location indicator the `cr_tail` and the write location indicator the `cr_head`. The console ring length is variable and is specified as the `cr_size` member of the data structure. `cr_buf` is the pointer to the actual array of data contained.
-
-
-```no-highlight
-struct console_ring {
- 32 uint8_t cr_head;
- 33 uint8_t cr_tail;
- 34 uint8_t cr_size;
- 35 uint8_t _pad;
- 36 uint8_t *cr_buf;
- 37 }
-```
-
-
-```no-highlight
-struct console_tty {
- 40 struct console_ring ct_tx;
- 41 uint8_t ct_tx_buf[CONSOLE_TX_BUF_SZ]; /* must be after console_ring */
- 42 struct console_ring ct_rx;
- 43 uint8_t ct_rx_buf[CONSOLE_RX_BUF_SZ]; /* must be after console_ring */
- 44 console_rx_cb ct_rx_cb; /* callback that input is ready */
- 45 console_write_char ct_write_char;
- 46 } console_tty
-```
-
-## List of Functions
-The functions available in shelltest are:
-
-* [imgmgr_module_init](imgmgr_module_init.md)
-* [imgr_boot_read](imgr_boot_read.md)
-* [imgr_boot_write](imgr_boot_write.md)
-* [imgr_file_download](imgr_file_download.md)
-* [imgr_file_upload](imgr_file_upload.md)
-* [imgr_list](imgr_list.md)
-* [imgr_noop](imgr_noop.md)
-* [imgr_read_file](imgr_read_file.md)
-* [imgr_read_main](imgr_read_main.md)
-* [imgr_read_test](imgr_read_test.md)
-* [imgr_read_ver](imgr_read_ver.md)
-* [imgr_upload](imgr_upload.md)
-* [imgr_ver_jsonstr](imgr_ver_jsonstr.md)
-* [imgr_ver_parse](imgr_ver_parse.md)
-* [imgr_ver_str](imgr_ver_str.md)
-* [imgr_write_file](imgr_write_file.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/testutil.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/testutil.md b/docs/modules/testutil/testutil.md
deleted file mode 100644
index 821f64b..0000000
--- a/docs/modules/testutil/testutil.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# testutil
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in testutil are:
-
-* [tu_case_abort](tu_case_abort.md)
-* [tu_case_append_assert_msg](tu_case_append_assert_msg.md)
-* [tu_case_append_buf](tu_case_append_buf.md)
-* [tu_case_append_file_info](tu_case_append_file_info.md)
-* [tu_case_append_manual_pass_msg](tu_case_append_manual_pass_msg.md)
-* [tu_case_complete](tu_case_complete.md)
-* [tu_case_fail_assert](tu_case_fail_assert.md)
-* [tu_case_init](tu_case_init.md)
-* [tu_case_pass_manual](tu_case_pass_manual.md)
-* [tu_case_set_name](tu_case_set_name.md)
-* [tu_case_vappend_buf](tu_case_vappend_buf.md)
-* [tu_case_write_fail_buf](tu_case_write_fail_buf.md)
-* [tu_case_write_pass_auto](tu_case_write_pass_auto.md)
-* [tu_case_write_pass_buf](tu_case_write_pass_buf.md)
-* [tu_init](tu_init.md)
-* [tu_restart](tu_restart.md)
-* [tu_suite_init](tu_suite_init.md)
-* [tu_suite_set_name](tu_suite_set_name.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_abort.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_abort.md b/docs/modules/testutil/tu_case_abort.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_append_assert_msg.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_append_assert_msg.md b/docs/modules/testutil/tu_case_append_assert_msg.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_append_buf.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_append_buf.md b/docs/modules/testutil/tu_case_append_buf.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_append_file_info.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_append_file_info.md b/docs/modules/testutil/tu_case_append_file_info.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_append_manual_pass_msg.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_append_manual_pass_msg.md b/docs/modules/testutil/tu_case_append_manual_pass_msg.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_complete.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_complete.md b/docs/modules/testutil/tu_case_complete.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_fail_assert.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_fail_assert.md b/docs/modules/testutil/tu_case_fail_assert.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_init.md b/docs/modules/testutil/tu_case_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_pass_manual.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_pass_manual.md b/docs/modules/testutil/tu_case_pass_manual.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_set_name.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_set_name.md b/docs/modules/testutil/tu_case_set_name.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_vappend_buf.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_vappend_buf.md b/docs/modules/testutil/tu_case_vappend_buf.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_write_fail_buf.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_write_fail_buf.md b/docs/modules/testutil/tu_case_write_fail_buf.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_write_pass_auto.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_write_pass_auto.md b/docs/modules/testutil/tu_case_write_pass_auto.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_case_write_pass_buf.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_case_write_pass_buf.md b/docs/modules/testutil/tu_case_write_pass_buf.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_init.md b/docs/modules/testutil/tu_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_restart.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_restart.md b/docs/modules/testutil/tu_restart.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_suite_init.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_suite_init.md b/docs/modules/testutil/tu_suite_init.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/modules/testutil/tu_suite_set_name.md
----------------------------------------------------------------------
diff --git a/docs/modules/testutil/tu_suite_set_name.md b/docs/modules/testutil/tu_suite_set_name.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/newt/packaging/dist.md
----------------------------------------------------------------------
diff --git a/docs/newt/packaging/dist.md b/docs/newt/packaging/dist.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/callout.md
----------------------------------------------------------------------
diff --git a/docs/os/callout.md b/docs/os/callout.md
deleted file mode 100644
index cc7bbc6..0000000
--- a/docs/os/callout.md
+++ /dev/null
@@ -1,261 +0,0 @@
-# Callout
-
-Callouts are MyNewt OS timers.
-
-## Description
-
-Callout is a way of setting up an OS timer. When the timer fires, it is delivered as an event to task's event queue.
-
-User would initialize their callout structure using *os_callout_init()*, or *os_callout_func_init()* and then arm it with *os_callout_reset()*.
-
-If user wants to cancel the timer before it expires, they can either use *os_callout_reset()* to arm it for later expiry, or stop it altogether by calling *os_callout_stop()*.
-
-There are 2 different options for data structure to use. First is *struct os_callout*, which is a bare-bones version. You would initialize this with *os_callout_init()*.
-
-Second option is *struct os_callout_func*. This you can use if you expect to have multiple different types of timers in your task, running concurrently. The structure contains a function pointer, and you would call that function from your task's event processing loop.
-
-Time unit when arming the timer is OS ticks. This rate of this ticker depends on the platform this is running on. You should use OS define *OS_TICKS_PER_SEC* to convert wallclock time to OS ticks.
-
-Callout timer fires out just once. For periodic timer type of operation you need to rearm it once it fires.
-
-## Data structures
-
-```no-highlight
-struct os_callout {
- struct os_event c_ev;
- struct os_eventq *c_evq;
- uint32_t c_ticks;
- TAILQ_ENTRY(os_callout) c_next;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| c_ev | Event structure of this callout |
-| c_evq | Event queue where this callout is placed on timer expiry |
-| c_ticks | OS tick amount when timer fires |
-| c_next | Linkage to other unexpired callouts |
-
-```no-highlight
-struct os_callout_func {
- struct os_callout cf_c;
- os_callout_func_t cf_func;
- void *cf_arg;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| cf_c | struct os_callout. See above |
-| cf_func | Function pointer which should be called by event queue processing |
-| cf_arg | Generic void * argument to that function |
-
-## List of Functions
-
-
-The functions available in this OS feature are:
-
-* [os_callout_init](#os_callout_init)
-* [os_callout_func_init](#os_callout_func_init)
-* [os_callout_stop](#os_callout_stop)
-* [os_callout_reset](#os_callout_reset)
-* [os_callout_queued](#os_callout_queued)
-
-## Function Reference
-
-------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_callout_init </font>
-
-```no-highlight
-void os_callout_init(struct os_callout *c, struct os_eventq *evq, void *ev_arg)
-```
-
-Initializes *struct os_callout*. Event type will be set to *OS_EVENT_T_TIMER*.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout to initialize |
-| evq | Event queue where this gets delivered to |
-| ev_arg | Generic argument which is filled in for the event |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Be careful not to call this if the callout is armed, because that will mess up the list of pending callouts.
-Or if the timer has already fired, it will mess up the event queue where the callout was delivered to.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-struct os_eventq my_evq;
-struct os_callout my_callouts[8];
-
- for (i = 0; i < 8; i++) {
- os_callout_init(&my_callouts[i], &my_evq, (void *)i);
- }
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_callout_func_init </font>
-
-```no-highlight
-void os_callout_func_init(struct os_callout_func *cf, struct os_eventq *evq, os_callout_func_t timo_func, void *ev_arg)
-```
-
-Initializes the given *struct os_callout_func*. Data structure is filled in with elements given as argument.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| cf | Pointer to os_callout_func being initialized |
-| evq | Event queue where this gets delivered to |
-| timo_func | Timeout function. Event processing should call this |
-| ev_arg | Generic argument for the event |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-The same notes as with *os_callout_init()*.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-struct os_callout_func g_native_cputimer;
-struct os_eventq g_native_cputime_evq;
-void native_cputimer_cb(void *arg);
-
- /* Initialize the callout function */
- os_callout_func_init(&g_native_cputimer,
- &g_native_cputime_evq,
- native_cputimer_cb,
- NULL);
-
-```
-
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_callout_stop </font>
-
-```no-highlight
-void os_callout_stop(struct os_callout *c)
-```
-
-Disarms a timer.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout being stopped |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-struct os_callout_func g_native_cputimer;
-
- os_callout_stop(&g_native_cputimer.cf_c);
-```
-
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt"> os_callout_reset </font>
-
-```no-highlight
-void os_callout_reset(struct os_callout *c, int32_t timo)
-```
-
-Resets the callout to happen *timo* in OS ticks.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout being reset |
-| timo | OS ticks the timer is being set to |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
- /* Re-start the timer (run every 50 msecs) */
- os_callout_reset(&g_bletest_timer.cf_c, OS_TICKS_PER_SEC / 20);
-```
-
----------------------
-
-## <font color="#F2853F" style="font-size:24pt">os_callout_queued</font>
-
-```no-highlight
-int os_callout_queued(struct os_callout *c)
-```
-
-Tells whether the callout has been armed or not.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to callout being checked |
-
-#### Returned values
-
-0: timer is not armed
-non-zero: timer is armed
-
-#### Notes
-
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/context_switch.md
----------------------------------------------------------------------
diff --git a/docs/os/context_switch.md b/docs/os/context_switch.md
deleted file mode 100644
index f4c4276..0000000
--- a/docs/os/context_switch.md
+++ /dev/null
@@ -1,141 +0,0 @@
-# Scheduler/Context Switching
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe scheduler here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in the scheduler are:
-
-* [os_sched_insert](#os_sched_insert)
-* [os_sched_walk](#os_sched_walk)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="#F2853F" style="font-size:24pt"> os_sched_insert</font>
-
-```no-highlight
- os_error_t
- os_sched_insert(struct os_task *t)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-### <font color="#F2853F" style="font-size:24pt"> os_sched_walk</font>
-
-```no-highlight
-<Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
-### <font color="#F2853F" style="font-size:24pt"> next_one </font>
-
-```no-highlight
-<Insert function callout here >
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```no-highlight
-<Insert the code snippet here>
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/callout.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/callout.md b/docs/os/core_os/callout/callout.md
new file mode 100644
index 0000000..2facdfa
--- /dev/null
+++ b/docs/os/core_os/callout/callout.md
@@ -0,0 +1,62 @@
+# Callout
+
+Callouts are MyNewt OS timers.
+
+## Description
+
+Callout is a way of setting up an OS timer. When the timer fires, it is delivered as an event to task's event queue.
+
+User would initialize their callout structure using *os_callout_init()*, or *os_callout_func_init()* and then arm it with *os_callout_reset()*.
+
+If user wants to cancel the timer before it expires, they can either use *os_callout_reset()* to arm it for later expiry, or stop it altogether by calling *os_callout_stop()*.
+
+There are 2 different options for data structure to use. First is *struct os_callout*, which is a bare-bones version. You would initialize this with *os_callout_init()*.
+
+Second option is *struct os_callout_func*. This you can use if you expect to have multiple different types of timers in your task, running concurrently. The structure contains a function pointer, and you would call that function from your task's event processing loop.
+
+Time unit when arming the timer is OS ticks. This rate of this ticker depends on the platform this is running on. You should use OS define *OS_TICKS_PER_SEC* to convert wallclock time to OS ticks.
+
+Callout timer fires out just once. For periodic timer type of operation you need to rearm it once it fires.
+
+## Data structures
+
+```no-highlight
+struct os_callout {
+ struct os_event c_ev;
+ struct os_eventq *c_evq;
+ uint32_t c_ticks;
+ TAILQ_ENTRY(os_callout) c_next;
+};
+```
+
+| Element | Description |
+|---------|-------------|
+| c_ev | Event structure of this callout |
+| c_evq | Event queue where this callout is placed on timer expiry |
+| c_ticks | OS tick amount when timer fires |
+| c_next | Linkage to other unexpired callouts |
+
+```no-highlight
+struct os_callout_func {
+ struct os_callout cf_c;
+ os_callout_func_t cf_func;
+ void *cf_arg;
+};
+```
+
+| Element | Description |
+|---------|-------------|
+| cf_c | struct os_callout. See above |
+| cf_func | Function pointer which should be called by event queue processing |
+| cf_arg | Generic void * argument to that function |
+
+## List of Functions
+
+The functions available in callout are:
+
+* [os_callout_func_init](os_callout_func_init)
+* [os_callout_init](os_callout_init)
+* [os_callout_queued](os_callout_queued)
+* [os_callout_reset](os_callout_reset)
+* [os_callout_stop](os_callout_stop)
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/os_callout_func_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_func_init.md b/docs/os/core_os/callout/os_callout_func_init.md
new file mode 100644
index 0000000..a80092a
--- /dev/null
+++ b/docs/os/core_os/callout/os_callout_func_init.md
@@ -0,0 +1,45 @@
+## <font color="#F2853F" style="font-size:24pt"> os_callout_func_init </font>
+
+```no-highlight
+void os_callout_func_init(struct os_callout_func *cf, struct os_eventq *evq, os_callout_func_t timo_func, void *ev_arg)
+```
+
+Initializes the given *struct os_callout_func*. Data structure is filled in with elements given as argument.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| cf | Pointer to os_callout_func being initialized |
+| evq | Event queue where this gets delivered to |
+| timo_func | Timeout function. Event processing should call this |
+| ev_arg | Generic argument for the event |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+The same notes as with *os_callout_init()*.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+struct os_callout_func g_native_cputimer;
+struct os_eventq g_native_cputime_evq;
+void native_cputimer_cb(void *arg);
+
+ /* Initialize the callout function */
+ os_callout_func_init(&g_native_cputimer,
+ &g_native_cputime_evq,
+ native_cputimer_cb,
+ NULL);
+
+```
+
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/os_callout_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_init.md b/docs/os/core_os/callout/os_callout_init.md
new file mode 100644
index 0000000..920f398
--- /dev/null
+++ b/docs/os/core_os/callout/os_callout_init.md
@@ -0,0 +1,40 @@
+## <font color="#F2853F" style="font-size:24pt">os_callout_init </font>
+
+```no-highlight
+void os_callout_init(struct os_callout *c, struct os_eventq *evq, void *ev_arg)
+```
+
+Initializes *struct os_callout*. Event type will be set to *OS_EVENT_T_TIMER*.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| c | Pointer to os_callout to initialize |
+| evq | Event queue where this gets delivered to |
+| ev_arg | Generic argument which is filled in for the event |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+Be careful not to call this if the callout is armed, because that will mess up the list of pending callouts.
+Or if the timer has already fired, it will mess up the event queue where the callout was delivered to.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+struct os_eventq my_evq;
+struct os_callout my_callouts[8];
+
+ for (i = 0; i < 8; i++) {
+ os_callout_init(&my_callouts[i], &my_evq, (void *)i);
+ }
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/os_callout_queued.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_queued.md b/docs/os/core_os/callout/os_callout_queued.md
new file mode 100644
index 0000000..02fbf6c
--- /dev/null
+++ b/docs/os/core_os/callout/os_callout_queued.md
@@ -0,0 +1,34 @@
+## <font color="#F2853F" style="font-size:24pt">os_callout_queued</font>
+
+```no-highlight
+int os_callout_queued(struct os_callout *c)
+```
+
+Tells whether the callout has been armed or not.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| c | Pointer to callout being checked |
+
+#### Returned values
+
+0: timer is not armed
+non-zero: timer is armed
+
+#### Notes
+
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/os_callout_reset.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_reset.md b/docs/os/core_os/callout/os_callout_reset.md
new file mode 100644
index 0000000..645abf0
--- /dev/null
+++ b/docs/os/core_os/callout/os_callout_reset.md
@@ -0,0 +1,35 @@
+## <font color="#F2853F" style="font-size:24pt"> os_callout_reset </font>
+
+```no-highlight
+void os_callout_reset(struct os_callout *c, int32_t timo)
+```
+
+Resets the callout to happen *timo* in OS ticks.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| c | Pointer to os_callout being reset |
+| timo | OS ticks the timer is being set to |
+
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ /* Re-start the timer (run every 50 msecs) */
+ os_callout_reset(&g_bletest_timer.cf_c, OS_TICKS_PER_SEC / 20);
+```
+
+---------------------
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/callout/os_callout_stop.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_stop.md b/docs/os/core_os/callout/os_callout_stop.md
new file mode 100644
index 0000000..c1a681c
--- /dev/null
+++ b/docs/os/core_os/callout/os_callout_stop.md
@@ -0,0 +1,36 @@
+## <font color="#F2853F" style="font-size:24pt"> os_callout_stop </font>
+
+```no-highlight
+void os_callout_stop(struct os_callout *c)
+```
+
+Disarms a timer.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| c | Pointer to os_callout being stopped |
+
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+struct os_callout_func g_native_cputimer;
+
+ os_callout_stop(&g_native_cputimer.cf_c);
+```
+
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/context_switch.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/context_switch.md b/docs/os/core_os/context_switch/context_switch.md
new file mode 100644
index 0000000..9cb8297
--- /dev/null
+++ b/docs/os/core_os/context_switch/context_switch.md
@@ -0,0 +1,29 @@
+# Scheduler/Context Switching
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe scheduler here
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+
+The functions available in context_switch are:
+
+* [os_sched](os_sched.md)
+* [os_sched_ctx_sw_hook](os_sched_ctx_sw_hook.md)
+* [os_sched_get_current_task](os_sched_get_current_task.md)
+* [os_sched_insert](os_sched_insert.md)
+* [os_sched_next_task](os_sched_next_task.md)
+* [os_sched_os_timer_exp](os_sched_os_timer_exp.md)
+* [os_sched_resort](os_sched_resort.md)
+* [os_sched_set_current_task](os_sched_set_current_task.md)
+* [os_sched_sleep](os_sched_sleep.md)
+* [os_sched_wakeup](os_sched_wakeup.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched.md b/docs/os/core_os/context_switch/os_sched.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md b/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_get_current_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_get_current_task.md b/docs/os/core_os/context_switch/os_sched_get_current_task.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_insert.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_insert.md b/docs/os/core_os/context_switch/os_sched_insert.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_next_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_next_task.md b/docs/os/core_os/context_switch/os_sched_next_task.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_os_timer_exp.md b/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_resort.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_resort.md b/docs/os/core_os/context_switch/os_sched_resort.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_set_current_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_set_current_task.md b/docs/os/core_os/context_switch/os_sched_set_current_task.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_sleep.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_sleep.md b/docs/os/core_os/context_switch/os_sched_sleep.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/context_switch/os_sched_wakeup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_wakeup.md b/docs/os/core_os/context_switch/os_sched_wakeup.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/event_queue.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/event_queue.md b/docs/os/core_os/event_queue/event_queue.md
new file mode 100644
index 0000000..9469326
--- /dev/null
+++ b/docs/os/core_os/event_queue/event_queue.md
@@ -0,0 +1,66 @@
+# Event Queues
+
+
+Event queue is a way of serializing events arring to a task. This makes it easy to queue processing to happen inside task's context. This would be done either from an interrupt handler, or from another task.
+
+Events arrive in a form of a data structure *struct os_event*.
+
+## Description
+
+Events are in form of a data structure *struct os_event*, and they are queued to data structure *struct os_eventq*.
+
+Queue must be initialized before trying to add events to it. This is done using *os_eventq_init()*.
+
+Common way of using event queues is to have a task loop while calling *os_eventq_get()*, waiting for work to do.
+Other tasks (or interrupts) then call *os_eventq_put()* to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
+Processing task would then act according to event type.
+
+When *os_event* is queued, it should not be freed until processing task is done with it.
+
+It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular *os_eventq* at a time.
+
+Note that os_callout subsystem assumes that event queue is used as the wakeup mechanism.
+
+## Data structures
+
+```no-highlight
+struct os_event {
+ uint8_t ev_queued;
+ uint8_t ev_type;
+ void *ev_arg;
+ STAILQ_ENTRY(os_event) ev_next;
+};
+```
+
+| Element | Description |
+|---------|-------------|
+| ev_queued | Internal field, which tells whether event is linked into an *os_eventq* already |
+| ev_type | Type of an event. This should be unique, as it should be used by processing task to figure out what the event means |
+| ev_arg | Can be used further as input to task processing this event |
+| ev_next | Linkage attaching this event to an event queue |
+
+
+```no-highlight
+struct os_eventq {
+ struct os_task *evq_task;
+ STAILQ_HEAD(, os_event) evq_list;
+};
+```
+
+
+| Element | Description |
+|---------|-------------|
+| evq_task | Pointer to task if there is task sleeping on *os_eventq_get()* |
+| evq_list | Queue head for list of events in this queue |
+
+## List of Functions
+
+
+The functions available in event queue feature are:
+
+* [os_eventq_get](os_eventq_get)
+* [os_eventq_init](os_eventq_init)
+* [os_eventq_put](os_eventq_put)
+* [os_eventq_put2](os_eventq_put2)
+* [os_eventq_remove](os_eventq_remove)
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/os_eventq_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_get.md b/docs/os/core_os/event_queue/os_eventq_get.md
new file mode 100644
index 0000000..1c1e3eb
--- /dev/null
+++ b/docs/os/core_os/event_queue/os_eventq_get.md
@@ -0,0 +1,40 @@
+## <font color="#F2853F" style="font-size:24pt"> os_eventq_get</font>
+
+```no-highlight
+void
+os_eventq_get(struct os_eventq *evq)
+```
+
+Fetches the first event from a queue. Task will sleep until something gets queued.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| evq | Queue to wait on |
+
+
+#### Returned values
+
+Will return with a pointer to first *struct event* which is in the queue.
+
+#### Notes
+
+
+#### Example
+
+Main loop of an example task.
+
+```no-highlight
+ while (1) {
+ ev = os_eventq_get(&task1_evq);
+ assert(ev);
+ if (ev->ev_type == CONS_EV_TYPE) {
+ /* XXX do stuff */
+ }
+ }
+
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/os_eventq_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_init.md b/docs/os/core_os/event_queue/os_eventq_init.md
new file mode 100644
index 0000000..2cfd2a5
--- /dev/null
+++ b/docs/os/core_os/event_queue/os_eventq_init.md
@@ -0,0 +1,45 @@
+## <font color="F2853F" style="font-size:24pt"> os_eventq_init</font>
+
+```no-highlight
+ void
+ os_eventq_init(struct os_eventq *evq)
+```
+
+Initializes *struct os_eventq*, making it ready for use.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| evq | Pointer to event queue getting initialized |
+
+#### Returned values
+
+None
+
+#### Notes
+
+Usually done at subsystem init time; before OS has been started, and before interrupts generating events have been enabled.
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+This initializes event queue used by newtmgr task.
+
+
+```no-highlight
+struct os_eventq g_nmgr_evq;
+
+int
+nmgr_task_init(uint8_t prio, os_stack_t *stack_ptr, uint16_t stack_len)
+{
+ /* variable declarations here */
+
+ os_eventq_init(&g_nmgr_evq);
+
+ /* initialization continues here */
+}
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/os_eventq_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_put.md b/docs/os/core_os/event_queue/os_eventq_put.md
new file mode 100644
index 0000000..aad5826
--- /dev/null
+++ b/docs/os/core_os/event_queue/os_eventq_put.md
@@ -0,0 +1,49 @@
+## <font color="#F2853F" style="font-size:24pt"> os_eventq_put</font>
+
+```no-highlight
+void
+os_eventq_put(struct os_eventq *evq, struct os_event *ev)
+```
+
+Queues an event to tail of the event queue.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| evq | Queue where event is being placed |
+| ev | Event which is being queued |
+
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+Functionality is of *os_eventq_put2()*, but this is to be called from a task context only.
+
+#### Example
+
+<Add text to set up the context for the example here>
+This is used to pass info about an event to a task handling it.
+
+```no-highlight
+ /* Get an event structure off the queue */
+ ev = (struct os_event *)os_memblock_get(&g_hci_os_event_pool);
+ if (!ev) {
+ err = os_memblock_put(&g_hci_cmd_pool, hci_ev);
+ assert(err == OS_OK);
+ return -1;
+ }
+
+ /* Fill out the event and post to Link Layer */
+ ev->ev_queued = 0;
+ ev->ev_type = BLE_HOST_HCI_EVENT_CTLR_EVENT;
+ ev->ev_arg = hci_ev;
+ os_eventq_put(&ble_hs_evq, ev);
+
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/os_eventq_put2.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_put2.md b/docs/os/core_os/event_queue/os_eventq_put2.md
new file mode 100644
index 0000000..6894ebd
--- /dev/null
+++ b/docs/os/core_os/event_queue/os_eventq_put2.md
@@ -0,0 +1,41 @@
+## <font color="#F2853F" style="font-size:24pt"> os_eventq_put2</font>
+
+```no-highlight
+void
+os_eventq_put2(struct os_eventq *evq, struct os_event *ev, int isr)
+```
+
+Queues an event to tail of the event queue.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| evq | Queue where event is being placed |
+| ev | Event which is being queued |
+| isr | Tells whether call is being made from within interrupt handler or not |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+If the event has already been queued, nothing happens. Including event's relative position within the queue itself.
+
+This can be called either from interrupt handler (in which case *isr* should be set to 1), or from another task context (in which case *isr should be set as 0).
+
+#### Example
+
+This wakes up the task waiting on task1_evq, which processes console input (console input comes from UART, and is passed in in interrupt context).
+
+```no-highlight
+static void
+my_cons_input(int full_line)
+{
+ os_eventq_put2(&task1_evq, &cons_ev, 1);
+}
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/event_queue/os_eventq_remove.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_remove.md b/docs/os/core_os/event_queue/os_eventq_remove.md
new file mode 100644
index 0000000..08583e7
--- /dev/null
+++ b/docs/os/core_os/event_queue/os_eventq_remove.md
@@ -0,0 +1,36 @@
+## <font color="#F2853F" style="font-size:24pt"> os_eventq_remove</font>
+
+```no-highlight
+void
+os_eventq_remove(struct os_eventq *evq, struct os_event *ev)
+```
+
+Removes an event which has been placed in a queue.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| evq | Queue where event is being removed from |
+| ev | Event which is being removed |
+
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+This is from os_callout_stop(). User wants to stop a callout from getting passed to a task. If the event has already been queued, then remove it before it is seen.
+
+```no-highlight
+ if (c->c_evq) {
+ os_eventq_remove(c->c_evq, &c->c_ev);
+ }
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/heap/heap.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/heap.md b/docs/os/core_os/heap/heap.md
new file mode 100644
index 0000000..5599d71
--- /dev/null
+++ b/docs/os/core_os/heap/heap.md
@@ -0,0 +1,25 @@
+# Heap
+
+
+API for doing dynamic memory allocation.
+
+
+## Description
+
+This provides malloc()/free() functionality with locking. The shared resource heap needs to be protected from concurrent access when OS has been started. *os_malloc()* function grabs a mutex before calling *malloc()*.
+
+## Data structures
+
+N/A
+
+## List of Functions
+
+
+The functions available in heap are:
+
+* [os_free](os_free)
+* [os_malloc](os_malloc)
+* [os_realloc](os_realloc)
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/heap/os_free.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_free.md b/docs/os/core_os/heap/os_free.md
new file mode 100644
index 0000000..e13be51
--- /dev/null
+++ b/docs/os/core_os/heap/os_free.md
@@ -0,0 +1,32 @@
+## <font color="F2853F" style="font-size:24pt">os_free</font>
+
+```no-highlight
+void os_free(void *mem)
+```
+
+Frees previously allocated memory back to the heap.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| mem | Pointer to memory being released |
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+Calls C-library *free()* behind the covers.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ os_free(info);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/heap/os_malloc.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_malloc.md b/docs/os/core_os/heap/os_malloc.md
new file mode 100644
index 0000000..296fd00
--- /dev/null
+++ b/docs/os/core_os/heap/os_malloc.md
@@ -0,0 +1,39 @@
+## <font color="F2853F" style="font-size:24pt"> os_malloc</font>
+
+```no-highlight
+void *os_malloc(size_t size)
+```
+
+Allocates *size* number of bytes from heap and returns a pointer to it.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| size | Number of bytes to allocate |
+
+#### Returned values
+
+<ptr>: pointer to memory allocated from heap.
+NULL: not enough memory available.
+
+#### Notes
+
+*os_malloc()* calls *malloc()*, which is provided by C-library. The heap must be set up during platform initialization.
+Depending on which C-library you use, you might have to do the heap setup differently. Most often *malloc()* implementation will maintain a list of allocated and then freed memory blocks. If user asks for memory which cannot be satisfied from free list, they'll call platform's *sbrk()*, which then tries to grow the heap.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ info = (struct os_task_info *) os_malloc(
+ sizeof(struct os_task_info) * tcount);
+ if (!info) {
+ rc = -1;
+ goto err;
+ }
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/heap/os_realloc.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_realloc.md b/docs/os/core_os/heap/os_realloc.md
new file mode 100644
index 0000000..809d9cf
--- /dev/null
+++ b/docs/os/core_os/heap/os_realloc.md
@@ -0,0 +1,33 @@
+## <font color="F2853F" style="font-size:24pt">os_realloc</font>
+
+```no-highlight
+void *os_realloc(void *ptr, size_t size)
+```
+
+Tries to resize previously allocated memory block, and returns pointer to resized memory.
+ptr can be NULL, in which case the call is similar to calling *os_malloc()*.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| ptr | Pointer to previously allocated memory |
+| size | New size to adjust the memory block to |
+
+#### Returned values
+
+NULL: size adjustment was not successful. <br>
+ptr: pointer to new start of memory block
+
+#### Notes
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+<Insert the code snippet here>
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/_os_mbuf_copypkthdr.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/_os_mbuf_copypkthdr.md b/docs/os/core_os/mbuf/_os_mbuf_copypkthdr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/_os_msys_find_pool.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/_os_msys_find_pool.md b/docs/os/core_os/mbuf/_os_msys_find_pool.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/mbuf.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/mbuf.md b/docs/os/core_os/mbuf/mbuf.md
new file mode 100644
index 0000000..976f425
--- /dev/null
+++ b/docs/os/core_os/mbuf/mbuf.md
@@ -0,0 +1,43 @@
+# Mbufs
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe OS feature here
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+The functions available in mbuf are:
+
+* [_os_mbuf_copypkthdr](_os_mbuf_copypkthdr.md)
+* [_os_msys_find_pool](_os_msys_find_pool.md)
+* [os_mbuf_adj](os_mbuf_adj.md)
+* [os_mbuf_append](os_mbuf_append.md)
+* [os_mbuf_concat](os_mbuf_concat.md)
+* [os_mbuf_copydata](os_mbuf_copydata.md)
+* [os_mbuf_copyinto](os_mbuf_copyinto.md)
+* [os_mbuf_dup](os_mbuf_dup.md)
+* [os_mbuf_extend](os_mbuf_extend.md)
+* [os_mbuf_free](os_mbuf_free.md)
+* [os_mbuf_free_chain](os_mbuf_free_chain.md)
+* [os_mbuf_get](os_mbuf_get.md)
+* [os_mbuf_get_pkthdr](os_mbuf_get_pkthdr.md)
+* [os_mbuf_memcmp](os_mbuf_memcmp.md)
+* [os_mbuf_off](os_mbuf_off.md)
+* [os_mbuf_pool_init](os_mbuf_pool_init.md)
+* [os_mbuf_prepend](os_mbuf_prepend.md)
+* [os_mbuf_pullup](os_mbuf_pullup.md)
+* [os_mqueue_get](os_mqueue_get.md)
+* [os_mqueue_init](os_mqueue_init.md)
+* [os_mqueue_put](os_mqueue_put.md)
+* [os_msys_get](os_msys_get.md)
+* [os_msys_get_pkthdr](os_msys_get_pkthdr.md)
+* [os_msys_register](os_msys_register.md)
+* [os_msys_reset](os_msys_reset.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_adj.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_adj.md b/docs/os/core_os/mbuf/os_mbuf_adj.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_append.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_append.md b/docs/os/core_os/mbuf/os_mbuf_append.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_concat.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_concat.md b/docs/os/core_os/mbuf/os_mbuf_concat.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_copydata.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_copydata.md b/docs/os/core_os/mbuf/os_mbuf_copydata.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_copyinto.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_copyinto.md b/docs/os/core_os/mbuf/os_mbuf_copyinto.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_dup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_dup.md b/docs/os/core_os/mbuf/os_mbuf_dup.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_extend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_extend.md b/docs/os/core_os/mbuf/os_mbuf_extend.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_free.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_free.md b/docs/os/core_os/mbuf/os_mbuf_free.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_free_chain.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_free_chain.md b/docs/os/core_os/mbuf/os_mbuf_free_chain.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_get.md b/docs/os/core_os/mbuf/os_mbuf_get.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md b/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_memcmp.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_memcmp.md b/docs/os/core_os/mbuf/os_mbuf_memcmp.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_off.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_off.md b/docs/os/core_os/mbuf/os_mbuf_off.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_pool_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_pool_init.md b/docs/os/core_os/mbuf/os_mbuf_pool_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_prepend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_prepend.md b/docs/os/core_os/mbuf/os_mbuf_prepend.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mbuf_pullup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_pullup.md b/docs/os/core_os/mbuf/os_mbuf_pullup.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mqueue_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mqueue_get.md b/docs/os/core_os/mbuf/os_mqueue_get.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mqueue_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mqueue_init.md b/docs/os/core_os/mbuf/os_mqueue_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_mqueue_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mqueue_put.md b/docs/os/core_os/mbuf/os_mqueue_put.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_msys_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_msys_get.md b/docs/os/core_os/mbuf/os_msys_get.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_msys_get_pkthdr.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_msys_get_pkthdr.md b/docs/os/core_os/mbuf/os_msys_get_pkthdr.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_msys_register.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_msys_register.md b/docs/os/core_os/mbuf/os_msys_register.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mbuf/os_msys_reset.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_msys_reset.md b/docs/os/core_os/mbuf/os_msys_reset.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md b/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
new file mode 100644
index 0000000..b08fdea
--- /dev/null
+++ b/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
@@ -0,0 +1,40 @@
+## <font color="#F2853F" style="font-size:24pt">OS_MEMPOOL_BYTES</font>
+
+```no-highlight
+OS_MEMPOOL_BYTES(n,blksize)
+```
+
+Calculates how many bytes of memory is used by *n* number of elements, when individual element size is *blksize* bytes.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| n | Number of elements |
+| blksize | Size of an element is number of bytes |
+
+#### Returned values
+
+List any values returned.
+Error codes?
+
+#### Notes
+
+
+#### Example
+
+Here we allocate memory to be used as a pool.
+
+```no-highlight
+void *nffs_file_mem;
+
+nffs_file_mem = malloc(
+ OS_MEMPOOL_BYTES(nffs_config.nc_num_files, sizeof (struct nffs_file)));
+ if (nffs_file_mem == NULL) {
+ return FS_ENOMEM;
+ }
+```
+
+---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/memory_pool/memory_pool.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/memory_pool.md b/docs/os/core_os/memory_pool/memory_pool.md
new file mode 100644
index 0000000..25d0554
--- /dev/null
+++ b/docs/os/core_os/memory_pool/memory_pool.md
@@ -0,0 +1,42 @@
+# Memory Pools
+
+
+Memory can be pre-allocated to a pool of fixed size elements.
+
+
+## Description
+
+Sometimes it's useful to have several memory blocks of same size preallocated for specific use. E.g. you want to limit the amount of memory used for it, or you want to make sure that there is memory available when you ask for it.
+
+This can be done using a memory pool. You allocate memory either statically or from heap, and then designate that memory to be used as storage for fixed size elements.
+
+Pool will be initialized by calling *os_mempool_init()*. Element can be allocated from it with *os_mempool_get()*, and released back with *os_mempool_put()*.
+
+## Data structures
+
+```no-highlight
+struct os_mempool {
+ int mp_block_size;
+ int mp_num_blocks;
+ int mp_num_free;
+ SLIST_HEAD(,os_memblock);
+ char *name;
+};
+```
+| Element | Description |
+|-----------|-------------|
+| mp_block_size | Size of the memory blocks, in bytes |
+| mp_num_blocks | Number of memory blocks in the pool |
+| mp_num_free | Number of free blocks left |
+| name | Name for the memory block |
+
+## List of Functions
+
+The functions available in mem_pool are:
+
+* [os_memblock_get](os_memblock_get)
+* [os_mempool_init](os_mempool_init)
+* [os_memblock_put](os_memblock_put)
+* [OS_MEMPOOL_BYTES](OS_MEMPOOL_BYTES)
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/memory_pool/os_memblock_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_memblock_get.md b/docs/os/core_os/memory_pool/os_memblock_get.md
new file mode 100644
index 0000000..81ed839
--- /dev/null
+++ b/docs/os/core_os/memory_pool/os_memblock_get.md
@@ -0,0 +1,38 @@
+## <font color="#F2853F" style="font-size:24pt"> os_memblock_get</font>
+
+```no-highlight
+void *os_memblock_get(struct os_mempool *mp)
+```
+
+Allocate an element from the memory pool. If succesful, you'll get a pointer to allocated element. If there are no elements available, you'll get NULL as response.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| mp | Pool where element is getting allocated from |
+
+#### Returned values
+
+NULL: no elements available.
+<pointer>: pointer to allocated element.
+
+#### Notes
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ struct nffs_file *file;
+
+ file = os_memblock_get(&nffs_file_pool);
+ if (file != NULL) {
+ memset(file, 0, sizeof *file);
+ }
+
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/memory_pool/os_memblock_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_memblock_put.md b/docs/os/core_os/memory_pool/os_memblock_put.md
new file mode 100644
index 0000000..a790cab
--- /dev/null
+++ b/docs/os/core_os/memory_pool/os_memblock_put.md
@@ -0,0 +1,39 @@
+## <font color="#F2853F" style="font-size:24pt">os_memblock_put</font>
+
+```no-highlight
+os_error_t os_memblock_put(struct os_mempool *mp, void *block_addr)
+```
+
+Releases previously allocated element back to the pool.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| mp | Pointer to memory pool where element is put |
+| block_addr | Pointer to element getting freed |
+
+#### Returned values
+
+OS_OK: operation was a success:
+OS_INVALID_PARAM: If either mp or block_addr were NULL.
+
+#### Notes
+
+
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ if (file != NULL) {
+ rc = os_memblock_put(&nffs_file_pool, file);
+ if (rc != 0) {
+ return FS_EOS;
+ }
+ }
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/memory_pool/os_mempool_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_mempool_init.md b/docs/os/core_os/memory_pool/os_mempool_init.md
new file mode 100644
index 0000000..33a7f66
--- /dev/null
+++ b/docs/os/core_os/memory_pool/os_mempool_init.md
@@ -0,0 +1,49 @@
+## <font color="F2853F" style="font-size:24pt"> os_mempool_init</font>
+
+```no-highlight
+os_error_t os_mempool_init(struct os_mempool *mp, int blocks, int block_size, void *membuf, char *name)
+```
+
+Initializes the memory pool. Memory pointed by *membuf* is taken and *blocks* number of elements of size *block_size* are added to the pool. *name* is optional, and names the memory pool.
+
+It is assumed that the amount of memory pointed by *membuf* has at least *OS_MEMPOOL_BYTES(blocks, block_size)* number of bytes.
+
+*name* is not copied, so caller should make sure that the memory does not get reused.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| mp | Memory pool being initialized |
+| blocks | Number of elements in the pool |
+| block_size | Size of an individual element in pool |
+| membuf | Backing store for the memory pool elements |
+| name | Name of the memory pool |
+
+#### Returned values
+
+OS_OK: operation was successful.
+OS_INVALID_PARAM: invalid parameters. Block count or block size was negative, or membuf or mp was NULL.
+OS_MEM_NOT_ALIGNED: membuf has to be aligned to 4 byte boundary.
+
+#### Notes
+
+Note that os_mempool_init() does not allocate backing storage. *membuf* has to be allocated by the caller.
+
+It's recommended that you use *OS_MEMPOOL_BYTES()* to figure out how much memory to allocate for the pool.
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```no-highlight
+ rc = os_mempool_init(&nffs_file_pool, nffs_config.nc_num_files,
+ sizeof (struct nffs_file), nffs_file_mem,
+ "nffs_file_pool");
+ if (rc != 0) {
+ return FS_EOS;
+ }
+
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mutex/mutex.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/mutex.md b/docs/os/core_os/mutex/mutex.md
new file mode 100644
index 0000000..08b9487
--- /dev/null
+++ b/docs/os/core_os/mutex/mutex.md
@@ -0,0 +1,48 @@
+# Mutex
+
+
+Mutex is short for "mutual exclusion"; a mutex provides mutually exclusive access to a shared resource. A mutex provides *priority inheritance* in order to prevent *priority inversion*. Priority inversion occurs when a higher priority task is waiting on a resource owned by a lower priority task. Using a mutex, the lower priority task will inherit the highest priority of any task waiting on the mutex.
+
+
+## Description
+
+The first order of business when using a mutex is to declare the mutex globally. The mutex needs to be initialized before it is used (see the examples). It is generally a good idea to initialize the mutex before tasks start running in order to avoid a task possibly using the mutex before it is initialized.
+
+When a task wants exclusive access to a shared resource it needs to obtain the mutex by calling *os_mutex_pend*. If the mutex is currently owned by a different task (a lower priority task), the requesting task will be put to sleep and the owners priority will be elevated to the priority of the requesting task. Note that multiple tasks can request ownership and the current owner is elevated to the highest priority of any task waitin on the mutex. When the task is done using the shared resource, it needs to release the mutex by called *os_mutex_release*. There needs to be one release per call to pend. Note that nested calls to *os_mutex_pend* are allowed but there needs to be one release per pend.
+
+The following example will illustrate how priority inheritance works. In this example, the task number is the same as its priority. Remember that the lower the number, the higher the priority (i.e. priority 0 is higher priority than priority 1). Suppose that task 5 gets ownership of a mutex but is preempted by task 4. Task 4 attempts to gain ownership of the mutex but cannot as it is owned by task 5. Task 4 is put to sleep and task 5 is temporarily raised to priority 4. Before task 5 can release the mutex, task 3 runs and attempts to acquire the mutex. At this point, both task 3 and task 4 are waiting on the mutex (sleeping). Task 5 now runs at priority 3 (the highest priority of all the tasks waiting on the mutex). When task 5 finally releases the mutex it will be preempted as two higher priority tasks are waiting for it.
+
+Note that when multiple tasks are waiting on a mutex owned by another task, once the mutex is released the highest priority task waiting on the mutex is run.
+
+## Data structures
+
+```no-highlight
+struct os_mutex
+{
+ SLIST_HEAD(, os_task) mu_head;
+ uint8_t _pad;
+ uint8_t mu_prio;
+ uint16_t mu_level;
+ struct os_task *mu_owner;
+};
+```
+
+| Element | Description |
+|-----------|-------------|
+| mu_head | Queue head for list of tasks waiting on mutex |
+| _pad | Padding |
+| mu_prio | Default priority of owner of mutex. Used to reset priority of task when mutex released |
+| mu_level | Call nesting level (for nested calls) |
+| mu_owner | Pointer to task structure which owns mutex |
+
+## List of Functions
+
+<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
+
+The functions available in this OS feature are:
+
+* [os_mutex_delete](os_mutex_delete)
+* [os_mutex_init](os_mutex_init)
+* [os_mutex_pend](os_mutex_pend)
+* [os_mutex_release](os_mutex_release)
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mutex/os_mutex_delete.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_delete.md b/docs/os/core_os/mutex/os_mutex_delete.md
new file mode 100644
index 0000000..29155b6
--- /dev/null
+++ b/docs/os/core_os/mutex/os_mutex_delete.md
@@ -0,0 +1,33 @@
+## <font color="#F2853F" style="font-size:24pt">os_mutex_delete </font>
+
+```no-highlight
+os_error_t os_mutex_pend(struct os_mutex *mu)
+```
+
+Delete a mutex
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *mu | Pointer to mutex |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *mu is NULL on entry.
+
+OS_OK: mutex initialized successfully.
+
+OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
+
+#### Example
+
+```no-highlight
+struct os_mutex g_mutex1;
+os_error_t err;
+
+err = os_mutex_delete(&g_mutex1);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mutex/os_mutex_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_init.md b/docs/os/core_os/mutex/os_mutex_init.md
new file mode 100644
index 0000000..3bd248e
--- /dev/null
+++ b/docs/os/core_os/mutex/os_mutex_init.md
@@ -0,0 +1,39 @@
+## <font color="#F2853F" style="font-size:24pt">os_mutex_init</font>
+
+```no-highlight
+os_error_t os_mutex_init(struct os_mutex *mu)
+```
+
+Initialize the mutex. Must be called before the mutex can be used.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *mu| Pointer to mutex |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *mu is NULL on entry.
+
+OS_OK: mutex initialized successfully.
+
+#### Notes
+
+<Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).>
+
+#### Example
+
+
+```no-highlight
+struct os_mutex g_mutex1;
+os_error_t err;
+
+err = os_mutex_init(&g_mutex1);
+assert(err == OS_OK);
+```
+
+---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mutex/os_mutex_pend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_pend.md b/docs/os/core_os/mutex/os_mutex_pend.md
new file mode 100644
index 0000000..d325cd0
--- /dev/null
+++ b/docs/os/core_os/mutex/os_mutex_pend.md
@@ -0,0 +1,49 @@
+## <font color="#F2853F" style="font-size:24pt">os_mutex_pend </font>
+
+```no-highlight
+os_error_t os_mutex_pend(struct os_mutex *mu, uint32_t timeout)
+```
+
+Acquire ownership of a mutex.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *mu | Pointer to mutex |
+| timeout | Timeout, in os ticks. A value of 0 means no timeout. A value of 0xFFFFFFFF means to wait forever. |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *mu is NULL on entry.
+
+OS_OK: mutex was successfully acquired.
+
+OS_TIMEOUT: the mutex was not available within the timeout specified.
+
+OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
+
+
+#### Notes
+
+If the mutex is owned by another task and the timeout is 0 the function returns immediately with the error code OS_TIMEOUT. The calling task *does not* own the mutex when this occurs.
+
+#### Example
+
+
+
+```no-highlight
+struct os_mutex g_mutex1;
+os_error_t err;
+
+err = os_mutex_pend(&g_mutex1, 0);
+assert(err == OS_OK);
+
+/* Perform operations requiring exclusive access */
+
+err = os_mutex_release(&g_mutex1);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mutex/os_mutex_release.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_release.md b/docs/os/core_os/mutex/os_mutex_release.md
new file mode 100644
index 0000000..23c126e
--- /dev/null
+++ b/docs/os/core_os/mutex/os_mutex_release.md
@@ -0,0 +1,42 @@
+## <font color="#F2853F" style="font-size:24pt">os_mutex_release</font>
+
+```no-highlight
+os_error_t os_mutex_release(struct os_mutex *mu)
+```
+
+Release ownership of a mutex
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *mu| Pointer to mutex |
+
+#### Returned values
+OS_INVALID_PARM: returned when *mu is NULL on entry.
+
+OS_OK: mutex initialized successfully.
+
+OS_BAD_MUTEX: The mutex was not owned by the task attempting to release it.
+
+OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
+
+
+#### Example
+
+
+```no-highlight
+struct os_mutex g_mutex1;
+os_error_t err;
+
+err = os_mutex_pend(&g_mutex1, 0);
+assert(err == OS_OK);
+
+/* Perform operations requiring exclusive access */
+
+err = os_mutex_release(&g_mutex1);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/mynewt_os.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mynewt_os.md b/docs/os/core_os/mynewt_os.md
new file mode 100644
index 0000000..52b7c53
--- /dev/null
+++ b/docs/os/core_os/mynewt_os.md
@@ -0,0 +1,44 @@
+# Mynewt OS
+
+Insert introduction here
+
+## Real-Time Kernel <Modify as you Wish>
+
+ Description
+
+## Real-Time OS <Modify as you Wish>
+
+ Description
+
+
+## Insert topic of your choice
+
+ Description
+
+## Features
+
+<Insert basic feature descriptions, how the various pieces fit together etc., what's special in Mynewt OS>
+
+* [Scheduler/context switching](context_switch/context_switch.md)
+* [Time](time/time.md)
+* [Tasks](task/task.md)
+* [Event queues/callouts](event_queue/event_queue.md)
+* [Semaphores](semaphore/semaphore.md)
+* [Mutexes](mutex/mutex.md)
+* [Memory pools](memory_pool/memory_pool.md)
+* [Heap](heap/heap.md)
+* [Mbufs](mbuf/mbuf.md)
+* [Sanity](sanity/sanity.md)
+* [Porting OS to other platforms](port_os.md)
+
+## OS Functions
+
+
+The functions available at the OS level are:
+
+* [os_idle_task](os_idle_task.md)
+* [os_init](os_init.md)
+* [os_init_idle_task](os_init_idle_task.md)
+* [os_start](os_start.md)
+* [os_started](os_started.md)
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/os_idle_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_idle_task.md b/docs/os/core_os/os_idle_task.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/os_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_init.md b/docs/os/core_os/os_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/os_init_idle_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_init_idle_task.md b/docs/os/core_os/os_init_idle_task.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/os_start.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_start.md b/docs/os/core_os/os_start.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/os_started.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_started.md b/docs/os/core_os/os_started.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/port_os.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/port_os.md b/docs/os/core_os/port_os.md
new file mode 100644
index 0000000..1331dde
--- /dev/null
+++ b/docs/os/core_os/port_os.md
@@ -0,0 +1,12 @@
+# Porting Mynewt OS
+
+
+This chapter describes how to adapt Newt OS to different processors. Adapting μC/OS-III to a microprocessor or a microcontroller is called porting.
+
+
+## Description
+
+
+## Insert sections as you wish
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_check_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_check_init.md b/docs/os/core_os/sanity/os_sanity_check_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_check_list_lock.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_check_list_lock.md b/docs/os/core_os/sanity/os_sanity_check_list_lock.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_check_list_unlock.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_check_list_unlock.md b/docs/os/core_os/sanity/os_sanity_check_list_unlock.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_check_register.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_check_register.md b/docs/os/core_os/sanity/os_sanity_check_register.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_check_reset.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_check_reset.md b/docs/os/core_os/sanity/os_sanity_check_reset.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_task_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_task_init.md b/docs/os/core_os/sanity/os_sanity_task_init.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/os_sanity_task_loop.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/os_sanity_task_loop.md b/docs/os/core_os/sanity/os_sanity_task_loop.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/sanity/sanity.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/sanity.md b/docs/os/core_os/sanity/sanity.md
new file mode 100644
index 0000000..1e8b6c2
--- /dev/null
+++ b/docs/os/core_os/sanity/sanity.md
@@ -0,0 +1,25 @@
+# Sanity
+
+
+Insert synopsis here
+
+
+## Description
+
+Describe OS feature here
+
+## Data structures
+
+Replace this with the list of data structures used, why, any neat features
+
+## List of Functions
+
+The functions available in sanity are:
+
+* [os_sanity_check_init](os_sanity_check_init.md)
+* [os_sanity_check_list_lock](os_sanity_check_list_lock.md)
+* [os_sanity_check_list_unlock](os_sanity_check_list_unlock.md)
+* [os_sanity_check_register](os_sanity_check_register.md)
+* [os_sanity_check_reset](os_sanity_check_reset.md)
+* [os_sanity_task_init](os_sanity_task_init.md)
+* [os_sanity_task_loop](os_sanity_task_loop.md)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/semaphore/os_sem_delete.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_delete.md b/docs/os/core_os/semaphore/os_sem_delete.md
new file mode 100644
index 0000000..26a340d
--- /dev/null
+++ b/docs/os/core_os/semaphore/os_sem_delete.md
@@ -0,0 +1,37 @@
+## <font color="#F2853F" style="font-size:24pt"> os_sem_delete </font>
+
+```no-highlight
+os_error_t os_sem_delete(struct os_sem *sem)
+```
+
+Delete a semaphore
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *sem | Pointer to semaphore |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *sem is NULL on entry.
+
+OS_OK: semaphore deleted successfully.
+
+OS_NOT_STARTED: Attempt to release a semaphore before os started.
+
+#### Notes
+
+Care must be taken when deleting a semaphore as deleting a semaphore used by other tasks could causes unexpected/unwanted behavior.
+
+#### Example
+
+```no-highlight
+struct os_sem g_os_sem;
+os_error_t err;
+
+err = os_sem_delete(&g_os_sem);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/semaphore/os_sem_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_init.md b/docs/os/core_os/semaphore/os_sem_init.md
new file mode 100644
index 0000000..b586120
--- /dev/null
+++ b/docs/os/core_os/semaphore/os_sem_init.md
@@ -0,0 +1,41 @@
+## <font color="F2853F" style="font-size:24pt"> os_sem_init</font>
+
+```no-highlight
+os_error_t os_sem_init(struct os_sem *sem, uint16_t tokens)
+```
+
+Initialize a semaphore with a given number of tokens. Should be called before the semaphore is used.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *sem | Pointer to semaphore |
+| tokens | Initial number of tokens allocated to semaphore |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *sem is NULL on entry.
+
+OS_OK: semaphore initialized successfully.
+
+#### Notes
+
+<Any special feature/special benefit that we want to tout.
+Does it need to be used with some other specific functions?
+Any caveats to be careful about (e.g. high memory requirements).>
+
+#### Example
+
+The following example shows how to initialize a semaphore used for exclusive access.
+
+```no-highlight
+struct os_mutex g_os_sem;
+os_error_t err;
+
+err = os_sem_init(&g_os_sem, 1);
+assert(err == OS_OK);
+```
+
+---------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9b0bc2e0/docs/os/core_os/semaphore/os_sem_pend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_pend.md b/docs/os/core_os/semaphore/os_sem_pend.md
new file mode 100644
index 0000000..df64bcd
--- /dev/null
+++ b/docs/os/core_os/semaphore/os_sem_pend.md
@@ -0,0 +1,46 @@
+## <font color="#F2853F" style="font-size:24pt"> os_sem_pend </font>
+
+```no-highlight
+os_error_t os_sem_pend(struct os_sem *sem, uint32_t timeout)
+```
+
+Wait for a semaphore for a given amount of time.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| *sem | Pointer to semaphore |
+| timeout | Amount of time, in os ticks, to wait for semaphore. A value of 0 means no wait. A value of 0xFFFFFFFF means wait forever. |
+
+#### Returned values
+
+OS_INVALID_PARM: returned when *sem is NULL on entry.
+
+OS_OK: semaphore acquired successfully.
+
+OS_TIMEOUT: the semaphore was not available within the timeout specified.
+
+OS_NOT_STARTED: Attempt to release a semaphore before os started.
+
+#### Notes
+
+If a timeout of 0 is used and the function returns OS_TIMEOUT, the semaphore was not available and was not acquired. No release of the semaphore should occur and the calling task does not own the semaphore.
+
+#### Example
+
+```no-highlight
+struct os_sem g_os_sem;
+os_error_t err;
+
+err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
+assert(err == OS_OK);
+
+/* Perform operations requiring semaphore lock */
+
+err = os_sem_release(&g_os_sem);
+assert(err == OS_OK);
+
+```
+
+---------------------