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/27 06:12:14 UTC
incubator-mynewt-site git commit: information to download newt tool
executable added
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/asf-site 39977ba0a -> 343a7af4f
information to download newt tool executable added
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/343a7af4
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/343a7af4
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/343a7af4
Branch: refs/heads/asf-site
Commit: 343a7af4f5a6e36e6004e5a0e4d33eae64f2df78
Parents: 39977ba
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Feb 26 21:11:59 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Feb 26 21:11:59 2016 -0800
----------------------------------------------------------------------
mkdocs/search_index.json | 4 ++--
os/get_started/project1/index.html | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/343a7af4/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index 4705de7..8f49478 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -57,7 +57,7 @@
},
{
"location": "/os/get_started/project1/",
- "text": "Blinky, the First Project\n\n\nObjective\n\n\nTo use available packages from the default application repository for Mynewt to make an LED on a target board blink. We call it \nProject Blinky\n. The goals of this tutorial are threefold:\n\n\n\n\nSet up the environment on your computer to use Mynewt OS and newt tool. \n\n\nDownload packages for building and testing the project \non a simulated target\n.\n\n\nDownload packages and use tools to create a runtime image for a board to make its LED blink. You have two choices here:\n\n\nDownload an image to SRAM\n, or \n\n\nDownload it to flash\n.\n\n\n\n\n\n\n\n\n Time Requirement\n: 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!\n\n\nWhat you need\n\n\n\n\nSTM32-E407 development board from Olimex. You can order it from \nhttp://www.mouser.com\n, \nhttp://www.digikey.com\n, and other places.\n\n\nARM-USB-TI
NY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)\n\n\nUSB A-B type cable to connect the debugger to your personal computer\n\n\nPersonal Computer\n\n\n\n\nThe 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:\n\n\n\n\nMac: OS X Yosemite Version 10.10.5\n\n\nLinux: Ubuntu 14.10 (Utopic Unicorn)\n\n\n\n\nAccess to the Apache repo\n\n\n\n\n\n\nGet an account on Apache. You do not need a committer account to view the website or clone the repository. You only need a committer account to push changes to it.\n\n\n\n\n\n\nThe latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\nThe latest codebase for the Newt tool is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-m
ynewt-newt.git . You do not need to download source code and build the newt tool for this project. You will simply use the available executable instead.\n\n\n\n\n\n\nThe following shows how to clone a Mynewt OS code repository:\n\n\n\n\nNon Committers\n\n\n\n\n $ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\nCommitters\n\n\n\n\n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\nSetting up toolchain if you have a Mac\n\n\n\n\nYou have to install gcc/libc that can produce 32-bit executables. Use homebrew to install gcc.\n\n\n\n\n $ brew install gcc\n ...\n ...\n ==\n Summary\n \ud83c\udf7a /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M\n\n\n\n\n\n\nARM 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 su
re 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!\n\n\n\n\n $ brew tap PX4/homebrew-px4\n $ brew update\n $ brew install gcc-arm-none-eabi-49\n $ arm-none-eabi-gcc --version \n arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\n Copyright (C) 2014 Free Software Foundation, Inc.\n This is free software; see the source for copying conditions. There is NO\n warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n $ ls -al /usr/local/bin/arm-none-eabi-gdb\n lrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -\n /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb\n\n\n\n\nNote: If no version is s
pecified, 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. \n\n\n\n\nYou 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 \nhttp://openocd.org\n.\n\n\n\n\n $ brew install open-ocd\n $ which openocd\n /usr/local/bin/openocd\n $ ls -l $(which openocd)\n lrwxr-xr-x 1 \nuser\n admin 36 Sep 17 16:22 /usr/local/bin/openocd -\n ../Cellar/open-ocd/0.9.0/bin/openocd\n\n\n\n\n\n\nProceed to the \nBuilding test code
on simulator\n section.\n\n\n\n\nSetting up toolchain if you have Linux\n\n\n\n\nYou have to install gcc / libc that can produce 32-bit executables. You can install these as follows: \n\n\n\n\n $ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\nFor 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 \nhttps://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded\n.\n\n\n\n\n $ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi \n $ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded \n $ sudo apt-get update \n $ sudo apt-get install gcc-arm-none-eabi\n\n\n\n\n\n\n\n\nAnd 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 embedde
d target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0. \n\n\nIf you are running Ubuntu 15.x, then you are in luck and you can simply run: \n\n\n\n\n\n\n $ sudo apt-get install openocd \n\n\n\n\nOther 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 \nhttps://launchpad.net/ubuntu/vivid/+source/openocd\n. The direct link to the amd64 build is \nhttp://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb\n. \n\n\n\n\nProceed to the \nBuilding test code on simulator\n section.\n\n\n\n\nDownload newt tool\n\n\nInsert the loaction of the newt tool executable.\n\n\nTry building test code on simulator\n\n\n\n\nClone the larva repository from the Apache git repository into a local directory named \nlarva\n.\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n
go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n2. Create a target using the newt tool. \n\n\n $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim\n\n\n\n\n3. Now continue to populate and build out the sim project.\n\n\n $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set
compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test\n\n\n\n\n4. 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 \n~/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.\n\n\nFor a Mac OS X environment:\n\n\n $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml \n\n\n\n\nFor a Linux machine:\n\n\n $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml\n\n\n\n\n5. Next, build the packages for the sim project using the newt tool. You can specify the VERBOSE option if you want to see the gory det
ails. \n\n\n $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run!\n\n\n\n\nYou can specify the VERBOSE option if you want to see the gory details.\n\n\n $newt -l VERBOSE target build sim_test\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run!\n\n\n\n\n6. Try running the test suite executable inside this project and enjoy your first successful test!\n\n\n $ project/test/bin/sim_test/test.elf\n [pass] os_mempool_test_suite/os_mempool_test_case\n [pass] os_mutex_test_suite/os_mutex_test_basic\n [pass] os_mutex_test_suite/os_mutex
_test_case_1\n ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3\n\n\n\n\nUsing SRAM to make LED blink\n\n\nYou are here because you want to build an image to be run from internal SRAM on the Olimex board.\n\n\nPreparing the Software\n\n\n\n\n\n\nMake sure the PATH environment variable includes the $HOME/dev/go/bin directory. \n\n\n\n\n\n\nIf 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. Go to ~/dev and clone the larva repository from the apache git repository into a local directory named \nlarva\n.\n\n\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scr
ipts\n\n\n\n\n\n\n\n\nYou now have to go to the ~dev/larva directory and build out a second project inside larva (the first one being the sim project). 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 packages and build the right bundle or list for the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.\n\n\nRemember to prefix each command with \"newtvm\" if you are executing the newt command in a Linux virtual machine on your Windows box!\n\n\n\n\n\n\n $ newt target create blinky\n Creating target blinky\n Target blinky sucessfully created!\n $ newt target set blinky arch=cortex_m4\n Target blinky successfully set arch to arm\n $ newt target set blinky compiler=arm-none-eabi-m4\n Target blinky successfully set compiler to arm-none-e
abi-m4\n $ newt target set blinky project=blinky\n Target blinky successfully set project to blinky\n $ newt target set blinky compiler_def=debug\n Target blinky successfully set compiler_def to debug\n $ newt target set blinky bsp=hw/bsp/olimex_stm32-e407_devboard\n Target blinky successfully set bsp to hw/bsp/olimex_stm32-e407_devboard\n $ newt target show blinky\n blinky\n arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=debug\n name=blinky\n project=blinky\n\n\n\n\n\n\n\n\nNow you have to build the image. The linker script within the \nhw/bsp/olimex_stm32-e407_devboard\n package builds an image for flash memory by default. Since you want an image for the SRAM, you need to switch that script with \nrun_from_sram.ld\n in order to get the package to produce an image for SRAM. \n 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. \n. \n\n\nOnce 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.\n\n\n\n\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n (some diff will be displayed)\n $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/\n $ newt target build blinky\n Building target blinky (project = blinky)\n Compiling case.c\n Compiling suite.c\n ...\n Successfully run!\n $ ls bin/blinky\n
blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map\n\n\n\n\n\n\n\n\nCheck 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 \n/usr/share/openocd/scripts/\n directory as they may have been part of the openocd download. If yes, you are all set and can proceed to preparing the hardware.\n\n\nOtherwise check the \n~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n directory for a file named \nf407.cfg\n. That is the config we will use to talk to this specific hardware using OpenOCD. You are all set if you see it.\n\n\n\n\n\n\n $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n bin include olimex_stm32-e407_devboard_download.sh run_from_loader.ld\n boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard.ld pkg.yml run_from_sram.ld\n f407.cfg olimex_stm32-e407_devboard_debu
g.sh run_from_flash.ld src\n\n\n\n\nPreparing the hardware to boot from embedded SRAM\n\n\n\n\n\n\nLocate the boot jumpers on the board.\n\n\n\n\n\n\n\n\n\nB1_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 \u2013 they are responsible for the boot mode if bootloader is present. The board can search for bootloader on three places \u2013 User Flash Memory, System Memory or the Embedded SRAM. We will configure it to boot from SRAM by jumpering B0_1 and B1_1.\n\n\n\n\n\n\nConnect 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). \n\n\n\n\n\n\nThe red PWR LED should be lit. \n\n\n\n\n\n\nConnect 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.\n\n\n\n\n\n\nLet's Go!\n\n\n\n\nMake 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 \n-c \"reset halt\"\n flag that tells it to halt after opening the session.\n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target debug blinky\n Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n targe
t halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n\n\n\n\nCheck 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. \n\n\n (gdb) set $msp=0x10010000\n\n\n\n\nNow load the image and type \"c\" or \"continue\" from the GNU debugger. \n\n\n (gdb) load ~/dev/larva/project/blinky/bin/blinky/blinky.elf \n Loading section .text, size 0x4294 lma 0x20000000\n Loading section .ARM.extab, size 0x24 lma 0x20004294\n Loading section .ARM.exidx, size 0xd8 lma 0x200042b8\n Loading section .data, size 0x874 lma 0x20004390\n Start addr
ess 0x20000250, load size 19460\n Transfer rate: 81 KB/sec, 2432 bytes/write.\n (gdb) c\n Continuing.\n\n\n\n\n\n\nVoil\u00e0! The board's LED should be blinking at 1 Hz.\n\n\n\n\nUsing flash to make LED blink\n\n\nYou are here because you want to build an image to be run from flash memory on the Olimex board.\n\n\n\n\nConfigure 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 \n\"Preparing the hardware to boot from embedded SRAM\"\n.\n\n\n\n\nYou will have to reset the board once the image is uploaded to it.\n\n\n\n\nIf you skipped the first option for the project \n(downloading an image to SRAM)\n, then skip this step. Otherwise, continue with this step. \n\n\n\n\nBy default, the linker script (\nolimex_stm32-e407_devboard.ld\n) is configured to run from bootloader and flash. However, if you first ran the image from SRAM you had changed \nolimex_stm32-e407_devboard.ld\
n to match \nrun_from_sram.ld\n. You will therefore return to defaults with \nolimex_stm32-e407_devboard.ld\n linker script matching the contents of 'run_from_loader.ld'. Return to the project directory.\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n $ diff olimex_stm32-e407_devboard.ld run_from_loader.ld\n (some diff will be displayed)\n $ cp run_from_loader.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/bin/blinky\n\n\n\n\n\n\nIn 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).\n\n\n\n\nLe
t's first create bin2img:\n\n\n $ newt target create bin2img\n Creating target bin2img\n Target bin2img successfully created!\n $ newt target set bin2img arch=sim\n Target bin2img successfully set arch to sim\n $ newt target set bin2img compiler=sim\n Target bin2img successfully set compiler to sim\n $ newt target set bin2img project=bin2img\n Target bin2img successfully set project to bin2img\n $ newt target set bin2img compiler_def=debug\n Target bin2img successfully set compiler_def to debug\n $ newt target set bin2img bsp=hw/bsp/native\n Target bin2img successfully set bsp to hw/bsp/native\n $ newt target show bin2img\n bin2img\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=bin2img\n project=bin2img\n\n\n\n\nAnd then let's create boot_olimex:\n\n\n $ new
t target create boot_olimex\n Creating target boot_olimex\n Target boot_olimex successfully created!\n $ newt target set boot_olimex arch=cortex_m4\n Target boot_olimex successfully set arch to cortex_m4\n $ newt target set boot_olimex compiler=arm-none-eabi-m4\n Target boot_olimex successfully set compiler to arm-none-eabi-m4\n $ newt target set boot_olimex project=boot\n Target boot_olimex successfully set project to boot\n $ newt target set boot_olimex compiler_def=optimized\n Target boot_olimex successfully set compiler_def to optimized\n $ newt target set boot_olimex bsp=hw/bsp/olimex_stm32-e407_devboard\n Target boot_olimex successfully set bsp to hw/bsp/olimex_stm32-e407_devboard\n $ newt target show boot_olimex\n boot_olimex\n arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_
def=optimized\n name=boot_olimex\n project=boot\n\n\n\n\n\n\nLet's build all the three targets now.\n\n\n\n\n $ newt target build bin2img\n Building target bin2img (project = bin2img)\n Building project bin2img\n ...\n Successfully run!\n $ newt target build boot_olimex\n Building target boot_olimex (project = boot)\n Building project boot\n ...\n Successfully run!\n $ newt target build blinky\n Building target blinky (project = blinky)\n Building project blinky\n Successfully run!\n\n\n\n\n\n\nGo to the project directory and download the bootloader and the image to flash ... in a flash! \n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target download boot_olimex\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n $ newt target download blinky\n Downloadin
g with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n\n\n\n\n\n\n\n\nThe LED should be blinking!\n\n\n\n\n\n\nBut 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. \n\n\n\n\n\n\nThe LED light will start blinking again. Success!\n\n\nNote #1: If you want to download the image to flash and a gdb session opened up, use \nnewt target debug blinky\n instead of \nnewt target download blinky\n.\n\n\n $ newt target debug blinky\n Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for
ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n (gdb)\n\n\n\n\nNote #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. \nflash erase_sector 0 0 x\n 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.\n\n\n (gdb) monitor flash erase_sector 0 0 4\n erased sectors 0 through 4 on flash bank 0 in 2.296712s\n (gdb) monitor mdw 0x08000000 16\n 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (gdb) monitor flash info 0",
+ "text": "Blinky, the First Project\n\n\nObjective\n\n\nTo use available packages from the default application repository for Mynewt to make an LED on a target board blink. We call it \nProject Blinky\n. The goals of this tutorial are threefold:\n\n\n\n\nSet up the environment on your computer to use Mynewt OS and newt tool. \n\n\nDownload packages for building and testing the project \non a simulated target\n.\n\n\nDownload packages and use tools to create a runtime image for a board to make its LED blink. You have two choices here:\n\n\nDownload an image to SRAM\n, or \n\n\nDownload it to flash\n.\n\n\n\n\n\n\n\n\n Time Requirement\n: 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!\n\n\nWhat you need\n\n\n\n\nSTM32-E407 development board from Olimex. You can order it from \nhttp://www.mouser.com\n, \nhttp://www.digikey.com\n, and other places.\n\n\nARM-USB-TI
NY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)\n\n\nUSB A-B type cable to connect the debugger to your personal computer\n\n\nPersonal Computer\n\n\n\n\nThe 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:\n\n\n\n\nMac: OS X Yosemite Version 10.10.5\n\n\nLinux: Ubuntu 14.10 (Utopic Unicorn)\n\n\n\n\nAccess to the Apache repo\n\n\n\n\n\n\nGet an account on Apache. You do not need a committer account to view the website or clone the repository. You only need a committer account to push changes to it.\n\n\n\n\n\n\nThe latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\nThe latest codebase for the Newt tool is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-m
ynewt-newt.git . You do not need to download source code and build the newt tool for this project. You will simply use the available executable instead.\n\n\n\n\n\n\nThe following shows how to clone a Mynewt OS code repository:\n\n\n\n\nNon Committers\n\n\n\n\n $ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\nCommitters\n\n\n\n\n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\nSetting up toolchain if you have a Mac\n\n\n\n\nYou have to install gcc/libc that can produce 32-bit executables. Use homebrew to install gcc.\n\n\n\n\n $ brew install gcc\n ...\n ...\n ==\n Summary\n \ud83c\udf7a /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M\n\n\n\n\n\n\nARM 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 su
re 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!\n\n\n\n\n $ brew tap PX4/homebrew-px4\n $ brew update\n $ brew install gcc-arm-none-eabi-49\n $ arm-none-eabi-gcc --version \n arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\n Copyright (C) 2014 Free Software Foundation, Inc.\n This is free software; see the source for copying conditions. There is NO\n warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n $ ls -al /usr/local/bin/arm-none-eabi-gdb\n lrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -\n /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb\n\n\n\n\nNote: If no version is s
pecified, 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. \n\n\n\n\nYou 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 \nhttp://openocd.org\n.\n\n\n\n\n $ brew install open-ocd\n $ which openocd\n /usr/local/bin/openocd\n $ ls -l $(which openocd)\n lrwxr-xr-x 1 \nuser\n admin 36 Sep 17 16:22 /usr/local/bin/openocd -\n ../Cellar/open-ocd/0.9.0/bin/openocd\n\n\n\n\n\n\nProceed to the \nBuilding test code
on simulator\n section.\n\n\n\n\nSetting up toolchain if you have Linux\n\n\n\n\nYou have to install gcc / libc that can produce 32-bit executables. You can install these as follows: \n\n\n\n\n $ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\nFor 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 \nhttps://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded\n.\n\n\n\n\n $ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi \n $ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded \n $ sudo apt-get update \n $ sudo apt-get install gcc-arm-none-eabi\n\n\n\n\n\n\n\n\nAnd 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 embedde
d target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0. \n\n\nIf you are running Ubuntu 15.x, then you are in luck and you can simply run: \n\n\n\n\n\n\n $ sudo apt-get install openocd \n\n\n\n\nOther 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 \nhttps://launchpad.net/ubuntu/vivid/+source/openocd\n. The direct link to the amd64 build is \nhttp://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb\n. \n\n\n\n\nProceed to the \nBuilding test code on simulator\n section.\n\n\n\n\nDownload newt tool\n\n\nIf you are working on a Mac you can download the newt tool executable \napache-newt-osx-0.8.0-b1-incubating.zip\nhere\n. Open it in the \n~/dev/go/bin/\n directory.\n\n\nIf you are working on a Linux machine you can download the newt tool executable \napache-newt-linux-0.8.0-b1-incubating.zip\n \nhere\n. Open it in the \n~/dev/go/bin/\n dire
ctory.\n\n\nAlternatively, you can choose to set up the environment on your computer, install the Go language, and build the newt tool from source as explained in the tutorials in the Newt Tool Manual. See \nInstall newt from source on Mac\n if you have a Mac and \nInstall newt from source on Linux\n if you have a Linux machine.\n\n\nTry building test code on simulator\n\n\n\n\nClone the larva repository from the Apache git repository into a local directory named \nlarva\n.\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n2. Create a target using the newt tool. \n\n\n $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test
sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim\n\n\n\n\n3. Now continue to populate and build out the sim project.\n\n\n $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test\n\n\n\n\n4. 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 \n~/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.\n\n\nFor a Mac OS X environment:\n\n\n $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml \n\n\n\n\nFor a Linux machine:\n\n\n $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml\n\n\n\n\n5. Next, build the packages for the sim project using the newt tool. You can specify the VERBOSE option if you want to see the gory details. \n\n\n $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run!\n\n\n\n\nYou can specify the VERBOSE option if you want to see the gory details.\n\n\n $newt -l VERBOSE target build sim_test\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12
[INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run!\n\n\n\n\n6. Try running the test suite executable inside this project and enjoy your first successful test!\n\n\n $ project/test/bin/sim_test/test.elf\n [pass] os_mempool_test_suite/os_mempool_test_case\n [pass] os_mutex_test_suite/os_mutex_test_basic\n [pass] os_mutex_test_suite/os_mutex_test_case_1\n ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3\n\n\n\n\nUsing SRAM to make LED blink\n\n\nYou are here because you want to build an image to be run from internal SRAM on the Olimex board.\n\n\nPreparing the Software\n\n\n\n\n\n\nMake sure the PATH environment variable includes the $HOME/dev/go/bin directory. \n\n\n\n\n\n\nIf yo
u 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. Go to ~/dev and clone the larva repository from the apache git repository into a local directory named \nlarva\n.\n\n\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n\n\n\n\nYou now have to go to the ~dev/larva directory and build out a second project inside larva (the first one being the sim project). 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 packages and build the right bundle or list f
or the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.\n\n\nRemember to prefix each command with \"newtvm\" if you are executing the newt command in a Linux virtual machine on your Windows box!\n\n\n\n\n\n\n $ newt target create blinky\n Creating target blinky\n Target blinky sucessfully created!\n $ newt target set blinky arch=cortex_m4\n Target blinky successfully set arch to arm\n $ newt target set blinky compiler=arm-none-eabi-m4\n Target blinky successfully set compiler to arm-none-eabi-m4\n $ newt target set blinky project=blinky\n Target blinky successfully set project to blinky\n $ newt target set blinky compiler_def=debug\n Target blinky successfully set compiler_def to debug\n $ newt target set blinky bsp=hw/bsp/olimex_stm32-e407_devboard\n Target blinky successfully set bsp to hw/bsp/olimex_stm32-e407
_devboard\n $ newt target show blinky\n blinky\n arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=debug\n name=blinky\n project=blinky\n\n\n\n\n\n\n\n\nNow you have to build the image. The linker script within the \nhw/bsp/olimex_stm32-e407_devboard\n package builds an image for flash memory by default. Since you want an image for the SRAM, you need to switch that script with \nrun_from_sram.ld\n in order to get the package to produce an image for SRAM. \n 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. \n. \n\n\nOnce the target is built, you can find the executable \"blinky.elf\" in the proj
ect directory at ~/dev/larva/project/blinky/bin/blinky. It's a good idea to take a little time to understand the directory structure.\n\n\n\n\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n (some diff will be displayed)\n $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/\n $ newt target build blinky\n Building target blinky (project = blinky)\n Compiling case.c\n Compiling suite.c\n ...\n Successfully run!\n $ ls bin/blinky\n blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map\n\n\n\n\n\n\n\n\nCheck 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 \n/usr/share/openocd/scripts/\n directory as they may have been part of the openocd d
ownload. If yes, you are all set and can proceed to preparing the hardware.\n\n\nOtherwise check the \n~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n directory for a file named \nf407.cfg\n. That is the config we will use to talk to this specific hardware using OpenOCD. You are all set if you see it.\n\n\n\n\n\n\n $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n bin include olimex_stm32-e407_devboard_download.sh run_from_loader.ld\n boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard.ld pkg.yml run_from_sram.ld\n f407.cfg olimex_stm32-e407_devboard_debug.sh run_from_flash.ld src\n\n\n\n\nPreparing the hardware to boot from embedded SRAM\n\n\n\n\n\n\nLocate the boot jumpers on the board.\n\n\n\n\n\n\n\n\n\nB1_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 \u2013 they are responsible for the boot mode if bootloader is present. The board can search for bootloader on three places \u2013 User Flash Memory, System Memory or the Embedded SRAM. We will configure it to boot from SRAM by jumpering B0_1 and B1_1.\n\n\n\n\n\n\nConnect 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). \n\n\n\n\n\n\nThe red PWR LED should be lit. \n\n\n\n\n\n\nConnect 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.\n\n\n\n\n\n\nLet's Go!\n\n\n\n\nMake 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 \n-c \"reset halt\"\n flag that tells it to halt after opening the session
.\n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target debug blinky\n Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n\n\n\n\nCheck the value of the msp (mai
n 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. \n\n\n (gdb) set $msp=0x10010000\n\n\n\n\nNow load the image and type \"c\" or \"continue\" from the GNU debugger. \n\n\n (gdb) load ~/dev/larva/project/blinky/bin/blinky/blinky.elf \n Loading section .text, size 0x4294 lma 0x20000000\n Loading section .ARM.extab, size 0x24 lma 0x20004294\n Loading section .ARM.exidx, size 0xd8 lma 0x200042b8\n Loading section .data, size 0x874 lma 0x20004390\n Start address 0x20000250, load size 19460\n Transfer rate: 81 KB/sec, 2432 bytes/write.\n (gdb) c\n Continuing.\n\n\n\n\n\n\nVoil\u00e0! The board's LED should be blinking at 1 Hz.\n\n\n\n\nUsing flash to make LED blink\n\n\nYou are here because you want to build an image to be run from flash memory on the Olimex board.\n\n\n\n\nConfigure the board to boot fr
om flash by moving the two jumpers together to B0_0 and B1_0. Refer to the pictures of the board under the section titled \n\"Preparing the hardware to boot from embedded SRAM\"\n.\n\n\n\n\nYou will have to reset the board once the image is uploaded to it.\n\n\n\n\nIf you skipped the first option for the project \n(downloading an image to SRAM)\n, then skip this step. Otherwise, continue with this step. \n\n\n\n\nBy default, the linker script (\nolimex_stm32-e407_devboard.ld\n) is configured to run from bootloader and flash. However, if you first ran the image from SRAM you had changed \nolimex_stm32-e407_devboard.ld\n to match \nrun_from_sram.ld\n. You will therefore return to defaults with \nolimex_stm32-e407_devboard.ld\n linker script matching the contents of 'run_from_loader.ld'. Return to the project directory.\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n $ diff olimex_stm32-e407_devboar
d.ld run_from_loader.ld\n (some diff will be displayed)\n $ cp run_from_loader.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/bin/blinky\n\n\n\n\n\n\nIn 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).\n\n\n\n\nLet's first create bin2img:\n\n\n $ newt target create bin2img\n Creating target bin2img\n Target bin2img successfully created!\n $ newt target set bin2img arch=sim\n Target bin2img successfully set arch to sim\n $ newt target set bin2img compiler=sim\n Target bin2img successfully set compiler to sim\n $ newt target
set bin2img project=bin2img\n Target bin2img successfully set project to bin2img\n $ newt target set bin2img compiler_def=debug\n Target bin2img successfully set compiler_def to debug\n $ newt target set bin2img bsp=hw/bsp/native\n Target bin2img successfully set bsp to hw/bsp/native\n $ newt target show bin2img\n bin2img\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=bin2img\n project=bin2img\n\n\n\n\nAnd then let's create boot_olimex:\n\n\n $ newt target create boot_olimex\n Creating target boot_olimex\n Target boot_olimex successfully created!\n $ newt target set boot_olimex arch=cortex_m4\n Target boot_olimex successfully set arch to cortex_m4\n $ newt target set boot_olimex compiler=arm-none-eabi-m4\n Target boot_olimex successfully set compiler to arm-none-eabi-m4\n
$ newt target set boot_olimex project=boot\n Target boot_olimex successfully set project to boot\n $ newt target set boot_olimex compiler_def=optimized\n Target boot_olimex successfully set compiler_def to optimized\n $ newt target set boot_olimex bsp=hw/bsp/olimex_stm32-e407_devboard\n Target boot_olimex successfully set bsp to hw/bsp/olimex_stm32-e407_devboard\n $ newt target show boot_olimex\n boot_olimex\n arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=optimized\n name=boot_olimex\n project=boot\n\n\n\n\n\n\nLet's build all the three targets now.\n\n\n\n\n $ newt target build bin2img\n Building target bin2img (project = bin2img)\n Building project bin2img\n ...\n Successfully run!\n $ newt target build boot_olimex\n Building target boot
_olimex (project = boot)\n Building project boot\n ...\n Successfully run!\n $ newt target build blinky\n Building target blinky (project = blinky)\n Building project blinky\n Successfully run!\n\n\n\n\n\n\nGo to the project directory and download the bootloader and the image to flash ... in a flash! \n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target download boot_olimex\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n $ newt target download blinky\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n\n\n\n\n\n\n\n\nThe LED should be blinking!\n\n\n\n\n\n\nBut 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. Nex
t 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. \n\n\n\n\n\n\nThe LED light will start blinking again. Success!\n\n\nNote #1: If you want to download the image to flash and a gdb session opened up, use \nnewt target debug blinky\n instead of \nnewt target download blinky\n.\n\n\n $ newt target debug blinky\n Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x08000250
msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n (gdb)\n\n\n\n\nNote #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. \nflash erase_sector 0 0 x\n 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.\n\n\n (gdb) monitor flash erase_sector 0 0 4\n erased sectors 0 through 4 on flash bank 0 in 2.296712s\n (gdb) monitor mdw 0x08000000 16\n 0x08000000: ffffffff ffffffff ffffffff fff
fffff ffffffff ffffffff ffffffff ffffffff \n (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n (gdb) monitor flash info 0",
"title": "Blinky, The First Project"
},
{
@@ -92,7 +92,7 @@
},
{
"location": "/os/get_started/project1/#download-newt-tool",
- "text": "Insert the loaction of the newt tool executable.",
+ "text": "If you are working on a Mac you can download the newt tool executable apache-newt-osx-0.8.0-b1-incubating.zip here . Open it in the ~/dev/go/bin/ directory. If you are working on a Linux machine you can download the newt tool executable apache-newt-linux-0.8.0-b1-incubating.zip here . Open it in the ~/dev/go/bin/ directory. Alternatively, you can choose to set up the environment on your computer, install the Go language, and build the newt tool from source as explained in the tutorials in the Newt Tool Manual. See Install newt from source on Mac if you have a Mac and Install newt from source on Linux if you have a Linux machine.",
"title": "Download newt tool"
},
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/343a7af4/os/get_started/project1/index.html
----------------------------------------------------------------------
diff --git a/os/get_started/project1/index.html b/os/get_started/project1/index.html
index 63dea45..f5c2178 100644
--- a/os/get_started/project1/index.html
+++ b/os/get_started/project1/index.html
@@ -364,7 +364,9 @@
<li>Proceed to the <a href="#building-test-code-on-simulator">Building test code on simulator</a> section.</li>
</ul>
<h3 id="download-newt-tool">Download newt tool<a class="headerlink" href="#download-newt-tool" title="Permanent link">¶</a></h3>
-<p>Insert the loaction of the newt tool executable.</p>
+<p>If you are working on a Mac you can download the newt tool executable <code>apache-newt-osx-0.8.0-b1-incubating.zip</code><a href="https://github.com/runtimeinc/binary-releases/tree/master/mynewt-0.8.0-b1-incubation">here</a>. Open it in the <code>~/dev/go/bin/</code> directory.</p>
+<p>If you are working on a Linux machine you can download the newt tool executable <code>apache-newt-linux-0.8.0-b1-incubating.zip</code> <a href="https://github.com/runtimeinc/binary-releases/tree/master/mynewt-0.8.0-b1-incubation">here</a>. Open it in the <code>~/dev/go/bin/</code> directory.</p>
+<p>Alternatively, you can choose to set up the environment on your computer, install the Go language, and build the newt tool from source as explained in the tutorials in the Newt Tool Manual. See <a href="../../../newt/newt_mac/">Install newt from source on Mac</a> if you have a Mac and <a href="../../../newt/newt_linux/">Install newt from source on Linux</a> if you have a Linux machine.</p>
<h3 id="try-building-test-code-on-simulator">Try building test code on simulator<a class="headerlink" href="#try-building-test-code-on-simulator" title="Permanent link">¶</a></h3>
<ol>
<li>Clone the larva repository from the Apache git repository into a local directory named <code>larva</code>.</li>
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Feb 27, 2016, at 3:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Sorry- miscommunication here. We cannot point to runtime binaries in asf documentation, that is a no-no.
>
> You can they just have to be clearly marked as such. Apache likes 3rd parties to use their code and having the documentation pointing to something useful for users is great. The PMC just has to be a little careful not to be seen as not endorsing any particular 3rd party but that’s not an issue here.
>
+1
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by aditi hilbert <ad...@runtime.io>.
Hi,
I have removed the reference to the binaries from docs for now. i will wait until the IPMC votes have passed before doing anything more about this.
I will do the steps Justin mentioned in the meantime:
* Rename files with something other than “Apache”
* Work on adding all the licenses including Apache license in the binary release
* Work on the language to use in the docs. It will talk about the source files first and then point to the binaries hosted on the 3rd party site. I won’t commit anything before the release is approved.
Thank you, Justin and Sterling, for the explanations.
aditi
> On Feb 27, 2016, at 12:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Sorry- miscommunication here. We cannot point to runtime binaries in asf documentation, that is a no-no.
>
> You can they just have to be clearly marked as such. Apache likes 3rd parties to use their code and having the documentation pointing to something useful for users is great. The PMC just has to be a little careful not to be seen as not endorsing any particular 3rd party but that’s not an issue here.
>
>> I believe runtime has full right to provide these binaries on github
>
> Yep they can.The Apache license is nice and permissive that way but it does ask for a few things in return.
>
> For example, and sorry if this is a bit of a repeat of my last email:
> - It’s not using an office release. Users are not supposed to be exposed to anything that’s not been released. It could put the ASF at risk. Just wait a couple of days until the vote is over.
> - The filename uses “apache” you’ll probabbly need to get permission from trademarks to do that. I doubt they give it and it’s far easier to rename. As a bonus there's less confusion that way as anyone can see that binary is not an Apache release.
> - Your using something the ASF produced. Great we love that but can you include a LICENSE file that tells the user which bits are Apache licensed.
>
>> LGPL license in dependency has an exception for static linking, in order to allow for just this case. It's incompatible for ASF - but we're not violating anyone's license.
>
> Well as I see it (and INAL etc ) currently you are not abiding by several license terms. In most licenses ask for a copy of their license to be distributed with a binary. The zip is missing an Apache license / notice file, GPL license notice and probably several other BSD, MIT licenses. Runtime can do what they want here, and I certainly have no say in that, but it would be nice to see an Apache license in that zip.
>
> Thanks,
> Justin
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Sorry- miscommunication here. We cannot point to runtime binaries in asf documentation, that is a no-no.
You can they just have to be clearly marked as such. Apache likes 3rd parties to use their code and having the documentation pointing to something useful for users is great. The PMC just has to be a little careful not to be seen as not endorsing any particular 3rd party but that’s not an issue here.
> I believe runtime has full right to provide these binaries on github
Yep they can.The Apache license is nice and permissive that way but it does ask for a few things in return.
For example, and sorry if this is a bit of a repeat of my last email:
- It’s not using an office release. Users are not supposed to be exposed to anything that’s not been released. It could put the ASF at risk. Just wait a couple of days until the vote is over.
- The filename uses “apache” you’ll probabbly need to get permission from trademarks to do that. I doubt they give it and it’s far easier to rename. As a bonus there's less confusion that way as anyone can see that binary is not an Apache release.
- Your using something the ASF produced. Great we love that but can you include a LICENSE file that tells the user which bits are Apache licensed.
> LGPL license in dependency has an exception for static linking, in order to allow for just this case. It's incompatible for ASF - but we're not violating anyone's license.
Well as I see it (and INAL etc ) currently you are not abiding by several license terms. In most licenses ask for a copy of their license to be distributed with a binary. The zip is missing an Apache license / notice file, GPL license notice and probably several other BSD, MIT licenses. Runtime can do what they want here, and I certainly have no say in that, but it would be nice to see an Apache license in that zip.
Thanks,
Justin
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by Sterling Hughes <st...@gmail.com>.
Sorry- miscommunication here. We cannot point to runtime binaries in asf documentation, that is a no-no.
I believe runtime has full right to provide these binaries on github: LGPL license in dependency has an exception for static linking, in order to allow for just this case. It's incompatible for ASF - but we're not violating anyone's license.
If it's an issue tho- we're replacing this code soon, so we're fine not hosting it as well. But I think the only thing necessary is to remove references to these binaries from the ASF site.
Sterling
> On Feb 26, 2016, at 10:16 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Hope that is fine?
>
> Sorry not really. [1]
>
> Think of it this way Runtime is taking an Apache release and compiling it and making that available as their own software. When the release is approved that’s fine as the Apache license allows that. However you need to abide by the terms of the Apache licence the code is under and respect Apache trademarks.
>
> I think it would be OK if you do the following and sorry it’s a long list. I can hunt down links for you or explain in more detail if you need.
> - Wait until the IPMC votes has passed.
> - Provide links to the official Apache source release first.
> - Change the name of the files so that they could not be confused with an Apache release. i.e. call then Runtime not Apache
> - Likely some changes will need to be made to make clear that this is a convince binary release by Runtime not Apache inside that zip i.e. changes to LICENSE, NOTICE etc
> - Provide links to the runtime compiled versions but make it 100% clear on that page that these files are not Apache releases and not hosted on Apache infrastructure.
> - You may not be able to license that bundle under an Apache license as it probably contains GPL software?
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/release.html#what
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Hope that is fine?
Sorry not really. [1]
Think of it this way Runtime is taking an Apache release and compiling it and making that available as their own software. When the release is approved that’s fine as the Apache license allows that. However you need to abide by the terms of the Apache licence the code is under and respect Apache trademarks.
I think it would be OK if you do the following and sorry it’s a long list. I can hunt down links for you or explain in more detail if you need.
- Wait until the IPMC votes has passed.
- Provide links to the official Apache source release first.
- Change the name of the files so that they could not be confused with an Apache release. i.e. call then Runtime not Apache
- Likely some changes will need to be made to make clear that this is a convince binary release by Runtime not Apache inside that zip i.e. changes to LICENSE, NOTICE etc
- Provide links to the runtime compiled versions but make it 100% clear on that page that these files are not Apache releases and not hosted on Apache infrastructure.
- You may not be able to license that bundle under an Apache license as it probably contains GPL software?
Thanks,
Justin
1. http://www.apache.org/dev/release.html#what
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by aditi hilbert <ad...@runtime.io>.
Hi Justin,
The executable is put up on runtime github site. Only source releases are on the apache repo.
The user has the choice of downloading the executable or following tutorials to set up the environment and installing newt from source.
Hope that is fine?
thanks,
aditi
> On Feb 26, 2016, at 9:25 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> Just double checking you're only putting up the source releases.
>
> There are a few policy issues around putting up the executables on the incubating site, i.e. before the incubating votes has passed and possible releasing unvoted on artefacts.
>
> Thanks,
> Justin
Re: incubator-mynewt-site git commit: information to download newt tool executable added
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Just double checking you're only putting up the source releases.
There are a few policy issues around putting up the executables on the incubating site, i.e. before the incubating votes has passed and possible releasing unvoted on artefacts.
Thanks,
Justin