New MCUBoot mailing list

[Fabio Utzig]

Hi,

The MCUboot mailing list has been recently moved. We did not re-subscribe 
previously subscribed users, so for those interested it is now hosted here: 
https://groups.io/g/mcuboot

Cheers,
Fabio

Re: sensorhub bsp phase out proposal

[Fabio Utzig]

On Thu, Nov 14, 2019, at 4:58 AM, Jerzy Kasenberg wrote:
> 
> I propose to drop whatever support we have for this BSP so it will not be
> available in the next release.

+1

Re: FAT32 file system issue

[Fabio Utzig]

On Mon, Aug 26, 2019, at 1:39 PM, Fabien Lepoutre wrote:
> Hi all,
> I am running code with the FATFS driver to write a stream into an SD card.
> The SD card is FAT32 formatted.
> Everything goes well for some time but for some reason, after a while (I've
> seen the issue come in at file size = 1.5GB, 2GB, 3GB etc...),  the file

Do you really mean GB here, or was it a typo? I never tried using big files 
like this, but don't mind trying myself!

> memory location changes (looks like it wraps to the beginning of the SD
> card memory) and overwrites the boot block and FAT structure which corrupts
> the entire SD card.
> I haven't found any similar issues but not sure anybody has tested the file
> system to that extent.
> Anyone has an idea on where to start to debug that issue?
> I'm guessing this bug would be from the fatfs driver and not the mmc/sdcard
> driver... am I wrong to think this?

Possibly correct, the elm-chan FAT driver used is quite old now, and the 
maintainer has very good release notes describing fixes, etc; maybe something 
there can give a hint. Also those sizes are close to the limits that 
int32/uint32 can store, so it could be overflow, maybe even in the MMC driver...

> Thanks,
> Fabien
>

Re: newest BSP on OSX

[Fabio Utzig]

On Tue, Aug 6, 2019, at 2:45 PM, Dr. Juergen Kienhoefer wrote:

> The app/boot was removed after version 1.6.0
> Is there a replacement for that now? A change of the core version number in
> project.yml did not help.
> The error still is:
> Error: Could not resolve app package: @apache-mynewt-core/apps/boot

For "1.7.0" or "master" it should be: "@mcuboot/boot/mynewt"

Re: Deprecate "install" and "sync" commands?

[Fabio Utzig]

On Mon, Aug 5, 2019, at 3:30 PM, Szymon Janc wrote:
> Hi Chris,
> 
> Yes!  I'm also for option 3. Lets deprecate for next (1.8) release (make
> those print proper warning info when used) and just remove for 1.9.

+1

Re: [RESULT][VOTE] Release Apache Mynewt 1.7.0-rc2 and Apache NimBLE 1.2.0-rc2

[Fabio Utzig]

On Fri, Aug 2, 2019, at 5:53 AM, Justin Mclean wrote:

> Just a reminder that only PMC members votes are binding on releases.
> 
> From what I see Miguel, Martin and  Jerzy are listed as committers on 
> the project not PMC members. [1] (It’s either that or the roster is not 
> up to date.)
> 
> I also notice several PMC members are not subscribed to the private 
> list including some of those who voted on this release. All PMC members 
> must be subscribed to the private list, this has been brought up 
> before, so please if you are a PMC member please subscribe.

The PMC list is here: https://projects.apache.org/committee.html?mynewt

If you are a PMC you can subscribe to private@ using: 
private-subscr...@mynewt.apache.org

Fabio

Re: [VOTE] Release Apache Mynewt 1.7.0-rc2 and Apache NimBLE 1.2.0-rc2

[Fabio Utzig]

On Mon, Jul 29, 2019, at 8:39 AM, Szymon Janc wrote:

> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0.

> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

+1 (binding)

Re: [VOTE] Release Apache Mynewt 1.7.0-rc1 and Apache NimBLE 1.2.0-rc1

[Fabio Utzig]

On Fri, Jul 19, 2019, at 9:37 AM, Szymon Janc wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0.

> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because... 

+1 (binding)

Re: Feedback on board report

[Fabio Utzig]

On Fri, Jun 21, 2019, at 4:57 PM, Greg Stein wrote:
> On Fri, Jun 21, 2019, 14:05 Fabio Utzig  wrote:
> 
> > On Fri, Jun 21, 2019, at 12:39 PM, Sterling Hughes wrote:
> >
> >  > Most of the technical conversations happen on the pull requests
> > > themselves, I think this is fine.  It’s archived, and people have an
> > > opportunity to review & comment.
> > >
> > > Slack is largely for support, with the occasional “what do you
> > > think?”   So long as that comes back to a conversation on a pull
> > > request or dev list, I don’t see a huge issue.
> >
> > One way to make it more accessible for posterity is to run a daily task on
> > builds.apache.org that runs a bot subscribed to the slack channel, pulls
> > all conversations and deploys to some place like mynewt.apache.org/slack...
> > I double anyone would ever access that but at least it's in the open
> > instead of requiring people to join the channel, and it's logged forever...
> >
> 
> Please note that the-asf.slack.com is on a Standard Plan, so all history is
> retained. Dunno what workspace mynewt is using, but if you move there, then
> no need to attach an archive bot.

So the main (or only) issue is with chat history? Moving moves all users and 
history?

> 
> Cheers,
> -g
>

Re: Feedback on board report

[Fabio Utzig]

On Fri, Jun 21, 2019, at 12:39 PM, Sterling Hughes wrote:

 > Most of the technical conversations happen on the pull requests 
> themselves, I think this is fine.  It’s archived, and people have an 
> opportunity to review & comment.
> 
> Slack is largely for support, with the occasional “what do you 
> think?”   So long as that comes back to a conversation on a pull 
> request or dev list, I don’t see a huge issue.

One way to make it more accessible for posterity is to run a daily task on 
builds.apache.org that runs a bot subscribed to the slack channel, pulls all 
conversations and deploys to some place like mynewt.apache.org/slack... I 
double anyone would ever access that but at least it's in the open instead of 
requiring people to join the channel, and it's logged forever...

> 
> Sterling
> 
> On 20 Jun 2019, at 23:08, Justin Mclean wrote:
> 
> > Hi,
> >
> > There a couple of minor concerns that have been raised by the last 
> > board report:
> > 1. There seem to be a lot of conversion happen on slack (in particular 
> > private conversation) rather than on this email list
> > 2. The PMC seems to be not very active in following emails sent to the 
> > private list.
> >
> > Anyone on the PMC care to  comment on this?  What action (if any) do 
> > you think we need to take on this?
> >
> > Is there some way someone could summarise what happening on slack and 
> > bring it back to this list perhaps?
> >
> > I can see in whimsey, that a number of PMC members are not signed up 
> > to the private mailing list. [1] Is it just a matter of getting these 
> > missing people subscribed and perhaps reminding people what a PMC’s 
> > duties are?
> >
> > Thanks,
> > Justin
> >
> > 1. https://whimsy.apache.org/roster/committee/mynewt
>

Re: [VOTE] Release Apache Mynewt 1.6.0-rc2 and Apache NimBLE 1.1.0-rc2

[Fabio Utzig]

> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

+1 (binding)

Re: Minimal hardware requirements

[Fabio Utzig]

On Thu, Feb 21, 2019, at 10:11 AM, Tsvetan Ginin - Bulgaria wrote:
> Thanks Fabio for a quickly reply and for the info. Please, send me a 
> link to STM32L0x BSP.

https://github.com/apache/mynewt-core/tree/master/hw/bsp/b-l072z-lrwan1

Re: Minimal hardware requirements

[Fabio Utzig]

On Thu, Feb 21, 2019, at 9:30 AM, Tsvetan Ginin - Bulgaria wrote:
> Hello,
> 
> I would like to know what are the minimum hardware requirements 
> (program memory and others, if any) for installing “Mynewt” on a 
> development board (NUCLEO-L053R8; 64MB Flash and 8MB RAM).

If it really was MB it would be great! ;-)

On this board Mynewt would be able to work, but it would be very limited. You 
would probably not want a bootloader and upgrade functionality.

This MCUs specs are the same as the nucleo-f030r8 which is already included in 
BSPs. Also STM32L0x support is already available so should not be too hard to 
add your BSP.

Fabio 

Re: Microchip CryptoAuthLib in mynewt

[Fabio Utzig]

Hello,

Those are very interesting chips, but unfortunately the library looks to be 
either LGPL 
(https://github.com/MicrochipTech/cryptoauthlib/blob/master/license.txt#L142) 
or GPL 
(https://github.com/MicrochipTech/cryptoauthlib/blob/master/license.txt#L662), 
both of which are incompatible with Apache, see: 
https://www.apache.org/legal/resolved.html#what-can-we-not-include-in-an-asf-project-category-x

Unless I am mistaken on my verification, this library cannot be integrate in 
our tree, and would need to remain in an external repo...

Fabio

On Fri, Jan 25, 2019, at 6:40 AM, Amr Bekhit wrote:
> Hello all,
> 
> I'm looking to integrate the Microchip CryptoAuthLib into mynewt
> (https://github.com/MicrochipTech/cryptoauthlib). I'm primarily
> focusing on getting the library incorporated as a standalone package
> and implement the I2C hal layer using the mynewt hal_i2c functions.
> 
> This is a "heads up" email in case anyone is also working on the same
> thing and would like to share what they're doing, or if anyone has any
> particular recommendations on how this library should be integrated.
> 
> Amr

Re: MYNEWT_VAL(...) invalid syntax ?

[Fabio Utzig]

Hi Markus,

You may need to update your BSP's `syscfg.yml`, check one included BSPs that 
has the same MCU that you're using for a complete list. Your particular failure 
is that your `syscfg.yml` is missing a "STM32_FLASH_SIZE_KB" entry.

Best,
Fabio

On Wed, Jan 9, 2019, at 4:30 AM, markus wrote:
> Hi Lukasz,
> 
> did manually build newt and run into some build failures:
> 
> .
> Compiling repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/
> hal_gpio.c
> Error: In file included from repos/apache-mynewt-core/kernel/os/include/
> os/mynewt.h:23:0,
>  from repos/apache-mynewt-core/hw/mcu/stm/stm32_common/
> src/hal_flash.c:21:
> bin/targets/spi/generated/include/syscfg/syscfg.h:15:49: error: 
> 'MYNEWT_VAL_STM32_FLASH_SIZE_KB' undeclared here (not in a function); 
> did you mean 'MYNEWT_VAL_STM32_FLASH_IS_LINEAR'?
>  #define MYNEWT_VAL(x)   MYNEWT_VAL_ ## x
>  ^
> repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:30:30: 
> note: in expansion of macro 'MYNEWT_VAL'
>  #define _FLASH_SIZE (MYNEWT_VAL(STM32_FLASH_SIZE_KB) * 1024)
>   ^~
> repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:64:16: 
> note: in expansion of macro '_FLASH_SIZE'
>  .hf_size = _FLASH_SIZE,
> ^~~
> 
> Anything else I should be doing?
> I also updated master again - just in case
> * master   cb9ece042 hw/drivers/lps33thw: Restore read 
> error stats
> 
> Thanks again,
> Markus
> 
> 
> 
> On Tue, 8 Jan 2019 07:05:11 +0100
> Łukasz Rymanowski  wrote:
> 
> > Hi Markus,
> > 
> > If master is used on mynewt-core then master branch of newt tool
> > should be used. Please try this and let us know of it works for you
> > 
> > Best
> > Lukasz
> > 
> > 
> > On Tue, Jan 8, 2019, 06:18 markus  > 
> > > 'been away for a few months and I can't build my projects anymore. I
> > > updated repos/apache-mynewt-core to the latest master branch
> > > (59912fc02) and it seems I'm running the latest newt tool, 1.5.0
> > >
> > > Executing `newt build ...` gives me an error for each package in
> > > apache-mynewt-core:
> > >
> > > * Warning: Parsing pkg @apache-mynewt-core/boot/boot_serial config:
> > >   strconv.ParseInt: parsing
> > >   "MYNEWT_VAL(BOOT_SERIAL_SYSINIT_STAGE_MAIN)": invalid syntax;
> > >   ignoring package.
> > >
> > >
> > > I couldn't find anything in the release notes - any clues as to what
> > > I'm doing wrong would be much appreciated.
> > >
> > > Thanks,
> > > Markus
> > >  
> 

Re: Blinky targets do not load

[Fabio Utzig]

Hi Duane,

I believe, but am not entirely sure, that OpenOCD 0.10.0 release was not able 
to flash nrf52x devices. I would suggest installing the latest from git. If 
using homebrew:

$ brew install --HEAD open-ocd

Or "reinstall" might work (sorry, not macOS user here!)

Best,
Fabio

On Thu, Jan 3, 2019, at 1:26 PM, Duane Hooton wrote:
> I am attempting to establish a newt environment on a MacBook running
> Mojave. This is a new computer and only supports usb-c ports. I have
> attached a newt nano2 through an adapter to one of these ports.
> 
> I have meticulously followed the steps to produce the Blinky app and
> associated boot loader. Here is the output from newt target show:
> 
> targets/my_blinky_sim
> 
> app=apps/blinky
> 
> bsp=@apache-mynewt-core/hw/bsp/native
> 
> build_profile=debug
> 
> targets/rbnano2_blinky
> 
> app=apps/blinky
> 
> bsp=@apache-mynewt-core/hw/bsp/rb-nano2
> 
> build_profile=debug
> 
> targets/rbnano2_boot
> 
> app=@apache-mynewt-core/apps/boot
> 
> bsp=@apache-mynewt-core/hw/bsp/rb-nano2
> 
> build_profile=optimized
> 
> The targets build successfully but when I attempt to load them I get the
> following output:
> 
> newt load rbnano2_blinky -v
> 
> Loading app image into slot 1
> 
> Load command:
> /Users/dhooton/Documents/projects/proxy/blinky/repos/apache-mynewt-core/
> hw/bsp/rb-nano2/rb-nano2_download.sh
> /Users/dhooton/Documents/projects/proxy/blinky/repos/apache-mynewt-core/
> hw/bsp/rb-nano2
> bin/targets/rbnano2_blinky/app/apps/blinky/blinky
> 
> Environment:
> 
> * FEATURES=BASELIBC_PRESENT BSP_NRF52 CONSOLE_UART_BAUD CONSOLE_UART_DEV
> CONSOLE_UART_FLOW_CONTROL FLASH_MAP_MAX_AREAS HAL_FLASH_VERIFY_BUF_SZ
> I2C_0_FREQ_KHZ I2C_0_PIN_SCL I2C_0_PIN_SDA I2C_1_FREQ_KHZ MCU_DCDC_ENABLED
> MCU_FLASH_MIN_WRITE_SIZE MCU_NRF52832 MSYS_1_BLOCK_COUNT MSYS_1_BLOCK_SIZE
> NFC_PINS_AS_GPIO OS_CPUTIME_FREQ OS_CTX_SW_STACK_GUARD
> OS_IDLE_TICKLESS_MS_MAX OS_IDLE_TICKLESS_MS_MIN OS_MAIN_STACK_SIZE
> OS_MAIN_TASK_PRIO OS_SCHEDULING OS_SYSVIEW_TRACE_CALLOUT
> OS_SYSVIEW_TRACE_EVENTQ OS_SYSVIEW_TRACE_MUTEX OS_SYSVIEW_TRACE_SEM
> QSPI_FLASH_SECTOR_COUNT QSPI_PIN_CS QSPI_PIN_DIO0 QSPI_PIN_DIO1
> QSPI_PIN_DIO2 QSPI_PIN_DIO3 QSPI_PIN_SCK SANITY_INTERVAL
> SPI_0_MASTER_PIN_MISO SPI_0_MASTER_PIN_MOSI SPI_0_MASTER_PIN_SCK
> SPI_0_SLAVE_PIN_MISO SPI_0_SLAVE_PIN_MOSI SPI_0_SLAVE_PIN_SCK
> SPI_0_SLAVE_PIN_SS SPI_1_MASTER_PIN_MISO SPI_1_MASTER_PIN_MOSI
> SPI_1_MASTER_PIN_SCK SPI_1_SLAVE_PIN_MISO SPI_1_SLAVE_PIN_MOSI
> SPI_1_SLAVE_PIN_SCK SPI_1_SLAVE_PIN_SS SYSINIT_CONSTRAIN_INIT TIMER_0
> UARTBB_0_PIN_RX UARTBB_0_PIN_TX UART_0 UART_0_PIN_CTS UART_0_PIN_RTS
> UART_0_PIN_RX UART_0_PIN_TX UART_1_PIN_CTS UART_1_PIN_RTS WATCHDOG_INTERVAL
> XTAL_32768
> 
> * FLASH_OFFSET=0x8000
> 
> * IMAGE_SLOT=0
> 
> *
> CORE_PATH=/Users/dhooton/Documents/projects/proxy/blinky/repos/apache-
> mynewt-core
> 
> *
> BSP_PATH=/Users/dhooton/Documents/projects/proxy/blinky/repos/apache-
> mynewt-core/hw/bsp/rb-nano2
> 
> * BIN_BASENAME=bin/targets/rbnano2_blinky/app/apps/blinky/blinky
> 
> Error:
> 
> Downloading bin/targets/rbnano2_blinky/app/apps/blinky/blinky.img to 0x8000
> 
> Open On-Chip Debugger 0.10.0
> 
> Licensed under GNU GPL v2
> 
> For bug reports, read
> 
> http://openocd.org/doc/doxygen/bugs.html
> 
> Info : auto-selecting first available session transport "swd". To override
> use 'transport select '.
> 
> adapter speed: 1 kHz
> 
> cortex_m reset_config sysresetreq
> 
> Info : CMSIS-DAP: SWD  Supported
> 
> Info : CMSIS-DAP: Interface Initialised (SWD)
> 
> Info : CMSIS-DAP: FW Version = 1.0
> 
> Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
> 
> Info : CMSIS-DAP: Interface ready
> 
> Info : reduce speed request: 1kHz to 5000kHz maximum
> 
> Info : clock speed 1 kHz
> 
> Info : SWD DPIDR 0x2ba01477
> 
> Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
> 
> target halted due to debug-request, current mode: Thread
> 
> xPSR: 0x0100 pc: 0xfffe msp: 0xfffc
> 
> .openocd_cmds:6: Error: invalid subcommand "write_image erase
> bin/targets/rbnano2_blinky/app/apps/blinky/blinky.img 0x8000"
> 
> in procedure 'script'
> 
> at file "embedded:startup.tcl", line 60
> 
> in procedure 'flash' called at file ".openocd_cmds", line 6
> 
> 
> 
> load - Load application image on to the board for 
> 
> 
> Usage:
> 
>   newt load  [flags]
> 
> 
> Flags:
> 
>   --extrajtagcmd string   Extra commands to send to JTAG software
> 
> 
> Global Flags:
> 
>   -h, --help  Help for newt commands
> 
>   -j, --jobs int  Number of concurrent build jobs (default 8)
> 
>   -l, --loglevel string   Log level (default "WARN")
> 
>   -o, --outfile stringFilename to tee output to
> 
>   -q, --quiet Be quiet; only display error output
> 
>   -s, --silentBe silent; don't output anything
> 
>   -v, --verbose   Enable verbose output when executing commands
> 
> I have also tried the steps to remove 

Re: Setting up RISC-V toolchain for Linux

[Fabio Utzig]

On Wed, Nov 7, 2018, at 8:04 PM, PEIJIE LI wrote:
> Hi Andrey:
> Thank you for your help.
> I switched to use the risvc64 package. Yet I am still seeing the
> missing sys/mman.h error.
> I tried installing gcc-multilib, build-essential, libc6-dev but none of
> them solves the problem.
> Any idea on what I should do to fix this?

To build for RISC-V you only need binutils + gcc (riscv64).

The errors you get when running `newt test ...` are because the tests run on a 
simulated environment. You need gcc-multilib and a 32-bit libc-dev. Not sure 
which distro you use, but installing `libc6-dev`on a 64-bit distr installs only 
the 64-bit libc. To get 32-bit, for Ubuntu you would need to install like this: 
`apt-get install linux-libc-dev:i386 `. Or just search with your package 
manager for something like "libc-dev-i386".

Re: Possible error in documentation

[Fabio Utzig]

On Sun, Sep 23, 2018, at 10:31 AM, Rohit Gujarathi wrote:
> Hello,
> 
> There might be a possible error in the "Enabling Newt Manager in Your
> Application" documentation or I might be doing something wrong.
> 
> Adding the listed packages in pkg.yml gives the following error,
> *Error: Unsatisfied APIs detected:*
> ** bootloader, required by: boot/split, mgmt/imgmgr*
> 
> So i added the boot/bootutil pkg to the list and only then it works.
> 
> Is this a error or am i doing something wrong?

You are doing nothing wrong. The documentation is still OK if using the latest 
release, 1.4.1, but on master this was changed after we did that release. The 
purpose of using an API dependency is to include either "boot/bootutil" from 
mynewt-core or mcuboot, both which supply the "bootloader" API.

Best,
Fabio

Re: Unit Tests with newt pkg new

[Fabio Utzig]

+1

On Sat, Sep 8, 2018, at 8:04 PM, Kevin Townsend wrote:
> The additions to the newt tool in recent releases makes things like package
> creation much easier, and pulling the code from Github is a good idea to
> keep things up to date.
> 
> In my own workflow, unit tests are a major part of package development
> since I can quickly and easily run functions natively, testing and updating
> the code accordingly. I simply force an intentional assert failure to see
> the printf debug output, edit code, run the unit test again, and on and on.
> 
> I'm also of the opinion that unit tests, aside from their obvious use
> improving code reliability, are an excellent source of 'documentation'
> since you can see the APIs in use for specific edge cases, and they are
> more likely be be kept up to date with breaking API changes.
> 
> I wanted to propose the idea of having the '/test' infrastructure are part
> of the default pkg when you run 'newt pkg new'. You currently need to
> manually create the files for this and it's a lot of repetitive copy,
> paste, rename type work that could be avoided, and might push more people
> to write unit tests?
> 
> My +1 would be to have /test as a standard feature of any package, and you
> can always delete it, but other people might find this delete burden
> inappropriate?
> 
> Kevin

Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

[Fabio Utzig]

+1 (binding)

On Fri, Jun 22, 2018, at 11:14 AM, Szymon Janc wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
> 
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
> 
> This is a bugfix only release fixing BLE connection creation in central role 
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on 
> Windows for newt and newtmgr tools.
> 
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> 
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
> 
>  Note that only features affected by bugfixes were tested for this 
> release. If you feel more testing is needed please provide your results here.
> 
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
> 
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> 
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
> 
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
> 
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
> 
> -- 
> pozdrawiam
> Szymon Janc
> 
> 

Re: Retrieving hardware IDs in Mynewt

[Fabio Utzig]

Hello,

You can simply call the HAL routine, given you already know the size of the 
HWID for your MCU (using LEN below):

#include 

uint8_t buf[LEN];

len_read = hal_bsp_hw_id(buf, LEN);

"buf" will have the HWID and the len will be returned. If you want to do it in 
a portable manner, you can use hal_bsp_hw_id_len() to check the size for the 
target MCU and allocate enough space (that was added recently, so not available 
on older releases).

Fabio

On Mon, Jun 25, 2018, at 9:48 AM, Amr Bekhit wrote:
> Hello,
> 
> Is there any driver for retrieving CPU hardware IDs in mynewt? I can see
> that there is a sys/id package, but I couldn't find any documentation for
> it, nor any use of this library in the sample code.
> 
> Amr

Re: nvic settings failing

[Fabio Utzig]

Hi Jan,

We set all but a few IRQ handlers to "os_default_irq_asm" on initialization. 
What you have to do is to set your handler with:

NVIC_SetVector(DMA2_Stream0_IRQn, (uint32_t)DMA2_Stream0_IRQHandler);
NVIC_EnableVector(DMA2_Stream0_IRQn);

PS: No need to use the "HAL_" macros from STM32Cube for this...

Best,
Fabio

On Mon, Jun 18, 2018, at 5:04 AM, Jan Clement wrote:
> Hello to you All,
> 
> I am new to mynewt and the ARM world as you would figure out by my 
> question.. I have a strong background in the 8-bit world where problems 
> tend to be easier..
> 
> I am working on a STM32f756 were I need to enable quite a lot of DMA 
> streams and also other peripheral functions (i.e. usb) I can't find yet 
> in mynewt code.
> 
> I really like the mynewt concept and would love to use it for my 
> application, a multimedia device with a touch tft, eth and wlan module.
> 
> So my question is, would it be able for me to use the mynewt kernel for 
> the running system (tasks, console, fs, update) but configure and access 
> the devices and the interrupts without using the API?
> 
> I did this when i tried to configure DMA for use with ADC1, but when I 
> write the NVIC register using HAL_NVIC_EnableIRQ(...) this crashes my 
> code, printing an "Unhandled interrupt (72)" to the console. When I 
> comment out the enable function, the system doesn't crash, but obviously 
> DMA is not working either.
> 
> I have the corresponding IRQ function in my code:
>   void DMA2_Stream0_IRQHandler(void)
> 
> but it never gets called, system crashes immediately after activating DMA.
> 
> 
> Any pointer in the right direction is highly appreciated!
> 
> Thank you very much
> 
> jan
> 
> 

Re: [VOTE] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1

[Fabio Utzig]

+1 (binding)

On Wed, Jun 6, 2018, at 4:45 PM, Szymon Janc wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0.
> 
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
> 
> NimBLE is having its first release as separate package. This is first and 
> last 
> release that is coordinated with Apache Mynewt release. After that NimBLE 
> will 
> follow with independent releases.
> 
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> 
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.0+Test+Results
> 
>  Note that this testing is not yet complete and more results will show 
> while voting is ongoing.
> 
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
> 
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/
> 
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit ceecdd3c98bba50859d744ce17b9e8f8b5206dd2
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit ddaf6d822f385b546fac683191ce776ccd53485a
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit bae15edb3b1b8f891f169fe9793131df91fb236b
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 5c759c31de25ec078f903a856d19c3ec1ecea28b
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit a85b65d97ecd062d8ea88c1a151f649e35e47420
> 
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/
> rc1/apache-mynewt-newt-bin-linux-1.4.0.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/
> apache-mynewt-newt-bin-osx-1.4.0.tgz
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
> 
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
> 
> -- 
> pozdrawiam
> Szymon Janc
> 
> 

Renaming BSP for Nucleo-F767zi board

[Fabio Utzig]

Hello,

Just a heads up, I have a PR (https://github.com/apache/mynewt-core/pull/1092) 
that renames the Nucleo-F767zi BSP which might break some existing targets that 
might be using it. This updates it follow a standard that was used for all 
other STM32 Nucleo boards (nucleo-f303k8, nucleo-f303re, nucleo-f401re, 
nucleo-f413re, nucleo-f413zh).

Best,
Fabio

Re: os data.core memory section

[Fabio Utzig]

On Mon, Apr 2, 2018, at 4:42 PM, markus wrote:
> On Mon, 02 Apr 2018 14:16:54 -0300
> Fabio Utzig <ut...@apache.org> wrote:
> 
> > Both
> > 
> > hw/mcu/stm/stm32f7xx/stm32f767.ld
> > hw/mcu/stm/stm32f4xx/stm32f407.ld
> > 
> > already define the stack on CCM (called DTCM on the F7xx). Am I
> > missing something here?
> 
> It might be me who's missing something (most likely scenario). The
> linker scripts do indeed define the DTCM and CCM memory regions and
> gives them names, ".stack" and ".data.core" depending on the linker
> script. What I'm missing is that those sections aren't used anywhere in
> the code.
> 
> The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in
> os_task.h, which sets the alignment but not the section. Looking at the
> generated memory map from an stm32f7 app all the sections are there but
> I cannot identify anything actually placed in there.
> 
> But then the linker has always been a bit of a dark art to me so I
> might just not be looking at the right things, or properly interpret
> what I'm seeing.

Ah, I see what you mean now, seems correct. Beyond main/idle it lso applies to 
any task for which the stack was allocated with malloc.

Re: os data.core memory section

[Fabio Utzig]

Both

hw/mcu/stm/stm32f7xx/stm32f767.ld
hw/mcu/stm/stm32f4xx/stm32f407.ld

already define the stack on CCM (called DTCM on the F7xx). Am I missing 
something here?

On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote:
> Hi Markus,
> 
> On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote:
> > I looked into moving the stack into the CCM memory of the stm32
> > mcu's - and although almost every linker script defines ".data.core"
> > sections and there are some defines in bsp.h's for section
> > attributes they don't seem to be used.
> > 
> > Is there some hidden magic going on or is the CCM reserved for
> > application code?
> 
> No hidden magic; CCM is mostly unused and is up for grabs.  I think
> there was some attempt to use this memory intelligently a while back,
> but as the number of supported BSPs increased, it became impractical.
> 
> When you say "the stack", do you mean the interrupt handler stack?  That
> sounds like a reasonable use of CCM (though you and others probably have
> a better sense of this than I do).  If this is something that users will
> want to do, it might be good to create a syscfg setting to control
> whether the stack gets put in CCM or normal RAM.
> 
> Chris

Re: STM32 backbone library

[Fabio Utzig]

On Tue, Mar 27, 2018, at 3:45 PM, markus wrote:
> Hey Miguel,
> 
> as you can tell - still causing trouble ;)
> 
> I should have mentioned that both APIs, LL (low level) and HAL (high
> level) are provided by ST Microelectronics and are part of their SDKs.
> 
> Although the LL API is called "low level" it is still portable between
> the different STM32 processor families. The big advantage is that it is
> stateless, doesn't require big data structures, and allows finer
> control.

Yes, feel free to use it! Btw, is there any explicit "contract" where it is 
mentioned that they will always be portable across different families?

Re: [DISCUSS] To track issues on Github for Apache Mynewt projects or not?

[Fabio Utzig]

So, when is a decision going to be made?

On Thu, Feb 8, 2018, at 11:15 AM, Miguel Azevedo wrote:
> +1
> 
> I strongly agree to track issues on github, the integration with
> github issues and PRs is very good and there's a lot of people already
> using it on other projects.
> Thanks,
> 
> Miguel
> 
> On Thu, Feb 8, 2018 at 5:34 AM, Fabio Utzig <ut...@apache.org> wrote:
> > +1
> >
> > I prefer as much information in a single place as possible, and GH as been 
> > adding more and more "project management" features making it better suited 
> > as a Jira alternative (and btw, we already made this move with MCUBoot!).
> >
> > Cheers,
> > Fabio Utzig
> >
> > On Tue, Feb 6, 2018, at 2:27 PM, Christopher Collins wrote:
> >> On Tue, Feb 06, 2018 at 12:26:17AM -0800, aditi hilbert wrote:
> >> > Hi,
> >> >
> >> > Multiple people have suggested that issues be tracked on Github close
> >> > to the code. The benefit is that contributors don’t have to switch
> >> > between two systems to raise and clear issues.  Please let your
> >> > thoughts known either way.
> >>
> >> I agree with switching to github issues.
> >>
> >> Jira seems more powerful and I do like it, but I find the extra
> >> flexibility is outweighed by the difficulty of using two different
> >> systems (github for PRs, Jira for issues).
> >>
> >> Chris
> 
> 
> 
> -- 
> --
> Miguel Azevedo

Re: [DISCUSS] To track issues on Github for Apache Mynewt projects or not?

[Fabio Utzig]

+1

I prefer as much information in a single place as possible, and GH as been 
adding more and more "project management" features making it better suited as a 
Jira alternative (and btw, we already made this move with MCUBoot!).

Cheers,
Fabio Utzig

On Tue, Feb 6, 2018, at 2:27 PM, Christopher Collins wrote:
> On Tue, Feb 06, 2018 at 12:26:17AM -0800, aditi hilbert wrote:
> > Hi,
> > 
> > Multiple people have suggested that issues be tracked on Github close
> > to the code. The benefit is that contributors don’t have to switch
> > between two systems to raise and clear issues.  Please let your
> > thoughts known either way.
> 
> I agree with switching to github issues.
> 
> Jira seems more powerful and I do like it, but I find the extra
> flexibility is outweighed by the difficulty of using two different
> systems (github for PRs, Jira for issues).
> 
> Chris

Re: stm32f7discovery apps on windows

[Fabio Utzig]

On Mon, Jan 8, 2018, at 5:34 PM, Abderrezak Mekkaoui wrote:
> FYI. Just in case where this could be helpful. On windows, I could not 
> build Apps for the stm32f7discovery board because of this simple problem:
> 
> Lines missing from the bsp.yml in 
> \repos\apache-mynewt-core\hw\bsp\stm32f7discovery:
> 
> bsp.downloadscript.WINDOWS.OVERWRITE: 
> "hw/bsp/stm32f7discovery/stm32f7discovery_download.cmd"
> bsp.debugscript.WINDOWS.OVERWRITE: 
> "hw/bsp/stm32f7discovery/stm32f7discovery_debug.cmd"
> 
> and the corresponding windows script files are missing from the same 
> directory:
> 
> stm32f7discovery_debug.cmd
> stm32f7discovery_download.cmd
> once these are added, the blinky example work out of the box
> Regards

Thanks for the report. We would be really glad if you can submit a PR with the 
fix!

Cheers,
Fabio Utzig

Re: stm32f3 support

[Fabio Utzig]

When last looking at that port I got the same impression. I think the in-tree 
F4 and F7 mcus/bsps are more similar between themselves than the f3 port is 
from any of them and making a new F3 port would be easier. But also I don't 
know about the history of the F3 port so someone can correct me. 

On Mon, Jan 8, 2018, at 3:45 AM, markus wrote:
> I've tried to use the mynewt_stm32f3 package with little success. It 
> seems to be so out of date that I'm wondering if it's even worth trying 
> to fix it or if I should rather start over following the porting guides 
> on web site?
> 
> Any guidance appreciated,
> Markus

[ANNOUNCE] Apache Mynewt 1.3.0 released

[Fabio Utzig]

Hello all,

The Apache Mynewt team is pleased to announce the release of 1.3.0.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:

http://www.apache.org/dyn/closer.lua/mynewt/apache-mynewt-1.3.0

Release notes are available here:

https://cwiki.apache.org/confluence/display/MYNEWT/RN-1.3.0

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at:

http://mynewt.apache.org/

Regards,
The Apache Mynewt team

[RESULT][VOTE] Release Apache Mynewt 1.3.0-rc3

[Fabio Utzig]

Hello all,

Voting for Apache Mynewt 1.3.0-rc3 is now closed.  The release has
passed this step of the process.  The vote breakdown is as follows:

+1 Justin Mclean (binding)
+1 Christopher Collins (binding)
+1 Sterling Hughes (binding)
+1 aditi runtime
+1 Vipul Rahane (binding)
+1 Łukasz Rymanowski (binding)
+1 Szymon Janc (binding)
+1 Jim Jagielski (binding)

Total: +8 binding

Thank you to all who voted.

[DISCUSS] Release Apache Mynewt 1.3.0-rc3

[Fabio Utzig]

Hi all,

This thread is for any and all discussion regarding the release of
Apache Mynewt 1.3.0-rc3.  All feedback is welcome.

Cheers,
Fabio Utzig

[VOTE] Release Apache Mynewt 1.3.0-rc3

[Fabio Utzig]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 1.3.0.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications. Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:

https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

This release candidate was tested as follows:

  1. Manual execution of the Mynewt test plan:

 https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan

 The test results can be found at:

 https://cwiki.apache.org/confluence/display/MYNEWT/1.3.0+Test+Results

  2. The full unit test suite for this release was executed via "newt
  test all" with no failures on Linux and OSX.

The release candidate to be voted on is available at:

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc3/

The commits under consideration are as follows:
blinky:
  repos: https://github.com/apache/mynewt-blinky
  commit d921fdd1877fc3bd6262e23d6be9f5c46c100576
core:
  repos: https://github.com/apache/mynewt-core
  commit 6fa22dae243e1e4a3fc5cf484652fe73aace09dd
newt:
  repos: https://github.com/apache/mynewt-newt
  commit f43e04d895c38433c090c74b1d6f32ed947eae80
newtmgr:
  repos: https://github.com/apache/mynewt-newtmgr
  commit c14a63d28b8cc6e14ecaa3d3d3aed278e1c0ee89

In addition, the following newt convenience binaries are available:
  linux:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc3/apache-mynewt-newt-bin-linux-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc3/apache-mynewt-newtmgr-bin-linux-1.3.0.tgz
  osx:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc3/apache-mynewt-newt-bin-osx-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc3/apache-mynewt-newtmgr-bin-osx-1.3.0.tgz

The release candidate is signed with a GPG key available at:

https://dist.apache.org/repos/dist/dev/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers,
please feel free to try out the release candidate and provide your
votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Fabio Utzig

[CANCEL][VOTE] Release Apache Mynewt 1.3.0-rc2

[Fabio Utzig]

Hello,

This vote for 1.3.0-rc2 is being cancelled due for the following
reasons:

* Incorrect newt version is displayed: "1.3.0-dev" instead of "1.3.0".

A new [VOTE] thread is coming soon...

Thanks,
Fabio Utzig

Re: [DISCUSS] Release Apache Mynewt 1.3.0-rc2

[Fabio Utzig]

On Thu, Dec 7, 2017, at 08:18 AM, Fabio Utzig wrote:
> Hi all,
> 
> This thread is for any and all discussion regarding the release of
> Apache Mynewt 1.3.0-rc2.  All feedback is welcome.

Just to make it clear, for this release we decided to remove pppoe.(c|h)
from the release due to license issues (category X). We are waiting for
legal-discuss' feedback to decide how to act on previous releases, and
also if it is OK to bundle those files, we'll add them back in the next
release.

Apart from that only LICENSE files were updated since rc1.

[DISCUSS] Release Apache Mynewt 1.3.0-rc2

[Fabio Utzig]

Hi all,

This thread is for any and all discussion regarding the release of
Apache Mynewt 1.3.0-rc2.  All feedback is welcome.

Cheers,
Fabio Utzig

[VOTE] Release Apache Mynewt 1.3.0-rc2

[Fabio Utzig]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 1.3.0.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications. Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:

https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

This release candidate was tested as follows:

  1. Manual execution of the Mynewt test plan:

 https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan

 The test results can be found at:

 https://cwiki.apache.org/confluence/display/MYNEWT/1.3.0+Test+Results

  2. The full unit test suite for this release was executed via "newt
  test all" with no failures on Linux and OSX.

The release candidate to be voted on is available at:

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc2/

The commits under consideration are as follows:
blinky:
  repos: https://github.com/apache/mynewt-blinky
  commit d921fdd1877fc3bd6262e23d6be9f5c46c100576
core:
  repos: https://github.com/apache/mynewt-core
  commit 6fa22dae243e1e4a3fc5cf484652fe73aace09dd
newt:
  repos: https://github.com/apache/mynewt-newt
  commit c325b9b05c7102e6f7f58bbb4f145732f9deae18
newtmgr:
  repos: https://github.com/apache/mynewt-newtmgr
  commit c14a63d28b8cc6e14ecaa3d3d3aed278e1c0ee89

In addition, the following newt convenience binaries are available:
  linux:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc2/apache-mynewt-newt-bin-linux-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc2/apache-mynewt-newtmgr-bin-linux-1.3.0.tgz
  osx:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc2/apache-mynewt-newt-bin-osx-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc2/apache-mynewt-newtmgr-bin-osx-1.3.0.tgz

The release candidate is signed with a GPG key available at:

https://dist.apache.org/repos/dist/dev/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers,
please feel free to try out the release candidate and provide your
votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Fabio Utzig

Re: Cannot build lora_app_shell

[Fabio Utzig]

On Fri, Dec 1, 2017, at 08:02 AM, K Dmitry wrote:
> 
> 
> 01.12.2017, 12:50, "Fabio Utzig" <ut...@apache.org>:
> > Do you mind attaching the output of "newt target config show
> > "? I want to try reproducing the bug here.
> 
> Guess there is no point in it any more. App finally runs on nrf52dk!
> I suppose it cannot run on nrf51, but was it incorrect pin definition
> that made it crash on nrf52?
> Should I investigate it?

Ah, sorry I might have missed something, but you wrote "I've bought
nrf52dk and build lora_app_shell for this target - still crashes." and
"lora app still crashes" at the end. Then it is working now and it was
just a matter of pin definitions?

Re: Cannot build lora_app_shell

[Fabio Utzig]

Do you mind attaching the output of "newt target config show
"? I want to try reproducing the bug here.

On Fri, Dec 1, 2017, at 07:39 AM, K Dmitry wrote:
> Just a  short update.
> 
> I've bought nrf52dk and build lora_app_shell for this target - still
> crashes. Tried loraping app - crashes on both nrf devkits. Slinky works
> fine on both, tried btshell app on nrf52dk - it works. Updated SX1276 SPI
> pins according to bsp.c and updated syscfg with SX1276_SPI_CS_PIN and
> other mentioned earlier defines - lora app still crashes.
> 
> Hope I'll have enough free time on weekend to debug deeper. I appreciate
> your help!

[VOTE] Release Apache Mynewt 1.3.0-rc1

[Fabio Utzig]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 1.3.0.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications. Mynewt provides a
real-time operating system, flash file system, network stacks, and
support utilities for real-world embedded systems.

For full release notes, please visit the Apache Mynewt Wiki:

https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes

This release candidate was tested as follows:

  1. Manual execution of the Mynewt test plan:
 https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
 The test results can be found at:
 https://cwiki.apache.org/confluence/display/MYNEWT/1.3.0+Test+Results

  2. The full unit test suite for this release was executed via "newt
  test all" with no failures on Linux and OSX.

The release candidate to be voted on is available at:

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc1/

The commits under consideration are as follows:
blinky:
  repos: https://github.com/apache/mynewt-blinky
  commit d921fdd1877fc3bd6262e23d6be9f5c46c100576
core:
  repos: https://github.com/apache/mynewt-core
  commit 5e48701c295469fbff7732f47ce3394c8d6eebf4
newt:
  repos: https://github.com/apache/mynewt-newt
  commit 1113413cbb259ebb4ded4a6dd706046435864ee9
newtmgr:
  repos: https://github.com/apache/mynewt-newtmgr
  commit 686f53209775133769cc57ab4873589b484c36ad

In addition, the following newt convenience binaries are available:
  linux:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc1/apache-mynewt-newt-bin-linux-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc1/apache-mynewt-newtmgr-bin-linux-1.3.0.tgz
  osx:
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc1/apache-mynewt-newt-bin-osx-1.3.0.tgz
-

https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.3.0/rc1/apache-mynewt-newtmgr-bin-osx-1.3.0.tgz

The release candidate is signed with a GPG key available at:

https://dist.apache.org/repos/dist/dev/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers,
please feel free to try out the release candidate and provide your
votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Fabio Utzig

Re: Cannot build lora_app_shell

[Fabio Utzig]

Hello,

The telee02 has a dependency on one of the LoRa drivers. If you look at
"hw/bsp/telee02/pkg.yml" you'll see:

pkg.deps.LORA_NODE:
- hw/drivers/lora/sx1276

the nrf51dk doesn't have this dependency. You would need to add it
yourself to satisfy the api requirements.

On Wed, Nov 29, 2017, at 10:20 AM, K Dmitry wrote:
> Hello!
> 
> I'm trying to build lora_app_shell using tutorial
> (https://mynewt.apache.org/latest/os/tutorials/lora/lorawanapp/) but
> build fails:
> 
> $ newt build  nrf51lora_app
> Building target targets/nrf51lora_app
> Error: Unsatisfied APIs detected:
> * lora_node_driver, required by: net/lora/node
> 
> Driver is presented in repos:
> $ rgrep  lora_node_driver ./
> ./repos/apache-mynewt-core/net/lora/node/pkg.yml:- lora_node_driver
> ./repos/apache-mynewt-core/hw/drivers/lora/sx1276/pkg.yml:-
> lora_node_driver
> 
> Here are my targets:
> $ newt target show
> targets/nrf51lora_app
> app=@apache-mynewt-core/apps/lora_app_shell
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk
> build_profile=optimized
> syscfg=LORA_MAC_TIMER_NUM=4:SHELL_CMD_ARGC_MAX=20:TIMER_4=1
> targets/nrf51lora_boot
> app=@apache-mynewt-core/apps/boot
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk
> build_profile=optimized
> 
> What am I doing wrong?
> 
> Thank you!

Re: Next release of Apache Mynewt

[Fabio Utzig]

Hello,

A heads up that I just created the 1.3 branches and we are now in frozen
state. The plan is to finish testing and send [VOTE] by Monday or
Tuesday.

Cheers,
Fabio Utzig

On Tue, Oct 31, 2017, at 06:52 PM, aditi hilbert wrote:
> Hi all,
> 
> There’s been quite a lot of activity on mynewt-core since the last
> release. The general plan was to do release 1.3 in December but I suggest
> we release the next point release (minor release) sooner than that to
> keep testing of features up to date and encourage adoption of recent
> features by the community of users.
> 
> Some of the features already implemented for the upcoming release 1.3 are
> listed here. It is by no means an exhaustive list, so feel free to add
> features that you are working on but don’t see included.
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Roadmap
> <https://cwiki.apache.org/confluence/display/MYNEWT/Release+Roadmap>
> 
> To target an end of Nov release date we would have to release the
> candidate on Nov 27th, if not earlier. Any red flags?
> 
> thanks,
> aditi

Re: Private keyfile format

[Fabio Utzig]

I don't think forcing users to change existing key formats would be a
good idea. I would suggest leaving compatibility in place for the
moment. When MCUboot changed the image format for 1.0 a new flag was
added to "new create-image" command, "-2", to write in the new format.
Maybe if a user provides "-2" you could also assume that PKCS#8 is to be
used. This would only break Mynewt users that have switched to MCUboot,
which is likely a smaller user base and more willing to engage in
"breaking" changes. What do you think?

On Wed, Nov 8, 2017, at 05:15 PM, Dr. Flywheel wrote:
> My vote is to affect the change ASAP. I don't know how painful it would
> be
> for other developers; however, carrying legacy implementations forward
> only
> increases the window of security vulnerability. Best to do this now,
> before
> the volume of applications exacerbates the situation.
> 
> Thanks.
> 
> --Dr. Flywheel
> 
> On Wed, Nov 8, 2017 at 10:14 AM, David Brown 
> wrote:
> 
> > In my work on https://runtimeco.atlassian.net/browse/MCUB-87 I will be
> > adding support for password protected private key files to MCUboot's
> > image signing tool.  I would also like to add this support to `newt`
> > as well.
> >
> > In order to support this protection, I will likely be moving from the
> > current algorithm-specific "legacy" file formats for private keys to
> > PKCS#8 (https://tools.ietf.org/html/rfc5958: Asymmetric Key Packages),
> > which defines a key storage format that supports multiple algorithms.
> > It also has a more modern and robust method of password protecting the
> > files.  As per the OpenSSL documentation: "newer applications should
> > use the more secure PKCS#8 format...".
> >
> > For MCUboot's tool, I will likely convert the format of the key files
> > to always be PKCS#8, effectively removing support for the legacy
> > formats.  There will be a documented `openssl` command that can be
> > used to convert any keys between the different formats.
> >
> > My question for the mynewt list is whether it would be acceptable to
> > change this key format within 'newt', or if we will continue needing
> > to support the legacy file formats for some period of time.
> >
> > Thanks,
> > David
> >

Re: 64-bit target

[Fabio Utzig]

Hi Simon,

Not AFAIK. Is there any MCU out there that is 64 bit?

Cheers,
Fabio Utzig

On Mon, Oct 30, 2017, at 10:17 PM, Simon Ratner wrote:
> Hi devs,
> 
> Has anyone looked at building core for a 64-bit target?
> 
> Obviously there is a lot of code right now that relies on the target
> platform being 32-bit, including the sim target (e.g. `os_mempool`). Any
> guesses at the amount of effort that would be involved, at least for the
> sim compiler / unittests?
> 
> Cheers,
> simon

Re: Using Nordic SDK 14.1.0

[Fabio Utzig]

Hi,

Since sdk 14 cannot be bundled in the main tree, I think it would be a
better idea to make an mcu specifically for the nrf52840 (or whatever
models have usb) adding the external sdk as a dependecy. This way it
would not "break" the other included nrf5x bsps.

Also "newt" could probably be improved to work better with external
repos in a way that does not need editing of repository.yml. One such
way could be to bundle a file with list of external repos that might be
used by an included package in a way that, if I create a new target
using bsp/mcu X is can automatically detect that this needs an external
repo, ask  permission to fetch it, etc.

Also curious about other's opinions!

Cheers,
Fabio Utzig

On Wed, Oct 18, 2017, at 08:35 PM, Miguel Azevedo wrote:
> Hi everyone,
> 
> We are currently using the Nordic SDK (v11.0.0) which doesn't have any
> USB support, therefore we need to move on to a newer version. I
> believe the best choice would be to use the latest version (v14.1.0).
> This version is quite recent, it was released today and supports all
> Nordic boards we run Mynewt on.
> 
> Regarding licensing, unlike SDK v11.0.0 (and since SDK v13.0.0), all
> the files are under the same license (which was discussed a few days
> ago on this mailing list).
> This means that, as far as I can see, we may either keep the BSPs and
> SDK (v11.0.0) files on the mynewt-core repository and have the updated
> SDK, as well as a copy of the BSPs on mynewt_nordic repository or move
> everything to the mynewt_nordic repository. None of this solutions
> sounds perfect.
> 
> How should we do this? What are your opinions on this matter?
> 
> Supported boards here:
> https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v14.1.0/sdk_for_custom_boards.html?cp=4_0_0_1_5_0#supported_board
> 
> Documentation, release notes and license text here:
> https://developer.nordicsemi.com/nRF5_SDK/doc/
> 
> Best regards,
> 
> Miguel Azevedo

Re: [VOTE] Release Apache Mynewt 1.2.0-rc1

[Fabio Utzig]

+1 (binding)

On Mon, Sep 11, 2017, at 06:33 AM, Michał Narajowski wrote:
> +1 (binding)
> 
> 2017-09-11 9:51 GMT+02:00 Łukasz Rymanowski
> :
> > +1 (binding)
> >
> > Łukasz
> >
> > On 10 September 2017 at 20:49, aditi hilbert  wrote:
> >> +1
> >>
> >> thanks,
> >> aditi
> >>
> >>> On Sep 8, 2017, at 11:54 AM, Szymon Janc  wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I am pleased to be calling this vote for the source release of
> >>> Apache Mynewt 1.2.0.
> >>>
> >>> Apache Mynewt is a community-driven, permissively licensed open source
> >>> initiative for constrained, embedded applications. Mynewt provides a
> >>> real-time operating system, flash file system, network stacks, and
> >>> support utilities for real-world embedded systems.
> >>>
> >>> For full release notes, please visit the Apache Mynewt Wiki:
> >>> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> >>>
> >>> This release candidate was tested as follows:
> >>>  1. Manual execution of the Mynewt test plan:
> >>> 
> >>> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
> >>> The test results can be found at:
> >>> https://cwiki.apache.org/confluence/display/MYNEWT/1.2.0+Test+Results
> >>>  2. The full unit test suite for this release was executed via "newt
> >>> test all" with no failures.  This testing was performed on the
> >>> following platforms:
> >>>   * OS X 10.11.5
> >>>   * Ubuntu Linux 17.04
> >>>
> >>> The release candidate to be voted on is available at:
> >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/
> >>>
> >>> The commits under consideration are as follows:
> >>> blinky:
> >>>  repos: https://github.com/apache/mynewt-blinky
> >>>  commit 5ade7990e81ebfb6b9801fd56b7ea32774747ced
> >>> core:
> >>>  repos: https://github.com/apache/mynewt-core
> >>>  commit e511aa733ee0d5740484738036618332ed45475b
> >>> newt:
> >>>  repos: https://github.com/apache/mynewt-newt
> >>>  commit 3a3e87d754e63cbcf2e49b49c20847dc3c19e655
> >>> newtmgr:
> >>>  repos: https://github.com/apache/mynewt-newtmgr
> >>>  commit 8bc55635bbac12c036b25b4968ee0f48c1f06e52
> >>>
> >>> In addition, the following newt convenience binaries are available:
> >>>  linux: 
> >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-linux-1.2.0.tgz
> >>>  osx: 
> >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-osx-1.2.0.tgz
> >>>
> >>> The release candidate is signed with a GPG key available at:
> >>> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> >>>
> >>> The vote is open for at least 72 hours and passes if a majority of at
> >>> least three +1 PMC votes are cast.
> >>>
> >>> [ ] +1 Release this package
> >>> [ ]  0 I don't feel strongly about it, but don't object
> >>> [ ] -1 Do not release this package because...
> >>>
> >>> Anyone can participate in testing and voting, not just committers,
> >>> please feel free to try out the release candidate and provide your
> >>> votes.
> >>>
> >>> A separate [DISCUSS] thread will be opened to talk about this release
> >>> candidate.
> >>>
> >>> Thanks,
> >>> Szymon Janc
> >>>
> >>

Re: Mynewt Logo

[Fabio Utzig]

I tried with the Logo with Apache's Logo at the left but it looks
distorted for the typical Logo res format on Wikipedia. I tried moving
the logo to the right where there's a lot of empty space. The result:

https://en.wikipedia.org/wiki/Apache_Mynewt#/media/File:Apache_Mynewt_Logo.png

On Mon, Aug 14, 2017, at 12:09 PM, aditi hilbert wrote:
> I have placed a vector image (with updated feather) for download as well
> as a .png on the project cwiki:
> 
> https://cwiki.apache.org/confluence/display/MYNEWT/Logo
> 
> 
> thanks,
> aditi
> 
> 
> > On Aug 14, 2017, at 7:55 AM, Todd Mitton  wrote:
> > 
> > There's also this svg version. It has the old feather though.
> > 
> > http://mynewt.apache.org/img/logo.svg
> > 
> > -Todd
> > 
> > On Mon, Aug 14, 2017 at 7:38 AM, Alfred Schilken  wrote:
> > 
> >> Hi Justin -  that sounds great!
> >> 
> >> Can you tell more ?
> >> 
> >> Where and when  - I know, it’s unofficial
> >> 
> >> I’m living in Germany - may be I can help somehow.
> >> 
> >> Regards
> >> Alfred
> >> 
> >> EDV-Beratung Schilken
> >> alf...@schilken.de
> >> www.schilken.de
> >> mobil: +49 178 1475677
> >> 
> >>> Am 14.08.2017 um 15:30 schrieb Justin Mclean :
> >>> 
> >>> Hi,
> >>> 
> >>> Do we have a hi res vector versions of the logo available anywhere?
> >>> 
> >>> I’m going to be speaking at a conference in Germany on Mynewt (not
> >> officially announced yet) and want to organise some stickers.
> >>> 
> >>> Thanks,
> >>> Justin
> >> 
> >> 
> 

Re: [VOTE] Release Apache Mynewt 1.1.0-rc2

[Fabio Utzig]

+1 (binding)

On Thu, Jul 27, 2017, at 07:47 PM, Szymon Janc wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.1.0.
> 
> This is the second release candidate for Mynewt 1.1.0 (rc2); voting for
> rc1 was cancelled due to issues described in [CANCEL][VOTE] email:
>   
> https://lists.apache.org/thread.html/ba768bba6e3b448489d12039bf526866f49732c2f63e1270aff70cd3@
> 
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
> 
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
> 
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.1.0+Test+Results
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.11.5
>* Ubuntu Linux 17.04
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.1.0/rc2/
> 
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 62dfe9154163b52ec2105ca329cc4547b7b11ae7
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit a9bd2b466feba698eb07c70a434f6424479cc368
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 0e174a618b473e89b5c0d681957830f0d4b7a665
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit e1c8a7f2294d3f2513eca16aebac12eede542596
> 
> In addition, the following newt convenience binaries are available:
>   linux:
>   
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.1.0/rc2/apache-mynewt-bin-linux-1.1.0.tgz
>   osx:
>   
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.1.0/rc2/apache-mynewt-bin-osx-1.1.0.tgz
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> 
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC votes are cast.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
> 
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
> 
> Thanks,
> Szymon Janc

Re: newt fails to recognize RSA private key

[Fabio Utzig]

On Tue, Jul 25, 2017, at 02:11 PM, Fabio Utzig wrote:
> On Tue, Jul 25, 2017, at 01:29 PM, Andrey Serdtsev wrote:
> > Hi all,
> > 
> > apache-mynewt-core/boot/bootutil/signed_images.md suggest to use 
> > 'openssl genrsa -out image_sign.pem 2048' for generating RSA keypair. 
> > When signing with this key, everything is fine:
> > $ newt create-image my-app 1.0.0.0 image_sign.pem
> > ...
> > App image succesfully generated: .../my-app.img
> > 
> > Now I look at 
> > 'https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL'
> >  
> > page and see another command for generating: 'openssl genpkey -algorithm 
> > RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048'. If I try to 
> > sign using such a key, everything is sad:
> > $ newt create-image my-app 1.0.0.0 image_sign.pem
> > ...
> > Error: Unknown private key format, EC/RSA private key in PEM format only.
> > 
> > As I can judge, methods for generating RSA pairs are identical and 
> > problem is somewhere in Go lib 'encoding/pem'. Not sure if this is 
> > really a bug, but clarification from Go guru is required.
> 
> They are not identical, the first command generates a key in PKCS#1
> format and the second in PKCS#8, which are slightly different formats. I
> never looked at the Go code for reading the PEMs but maybe it doesn't
> support PKCS#8.

Out of curiosity, the code to parse is here:

https://github.com/apache/mynewt-newt/blob/master/newt/image/image.go#L285

And the Go stdlib also supports PKCS#8:

https://golang.org/pkg/crypto/x509/#ParsePKCS8PrivateKey

Shouldn't be that hard to make a patch! (hopefully there are not a lot
of other places to change...)

Fabio Utzig

Re: newt fails to recognize RSA private key

[Fabio Utzig]

On Tue, Jul 25, 2017, at 01:29 PM, Andrey Serdtsev wrote:
> Hi all,
> 
> apache-mynewt-core/boot/bootutil/signed_images.md suggest to use 
> 'openssl genrsa -out image_sign.pem 2048' for generating RSA keypair. 
> When signing with this key, everything is fine:
> $ newt create-image my-app 1.0.0.0 image_sign.pem
> ...
> App image succesfully generated: .../my-app.img
> 
> Now I look at 
> 'https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL' 
> page and see another command for generating: 'openssl genpkey -algorithm 
> RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048'. If I try to 
> sign using such a key, everything is sad:
> $ newt create-image my-app 1.0.0.0 image_sign.pem
> ...
> Error: Unknown private key format, EC/RSA private key in PEM format only.
> 
> As I can judge, methods for generating RSA pairs are identical and 
> problem is somewhere in Go lib 'encoding/pem'. Not sure if this is 
> really a bug, but clarification from Go guru is required.

They are not identical, the first command generates a key in PKCS#1
format and the second in PKCS#8, which are slightly different formats. I
never looked at the Go code for reading the PEMs but maybe it doesn't
support PKCS#8.

Cheers,
Fabio Utzig

Re: Why not use -std=gnu99?

[Fabio Utzig]

On Thu, Jul 6, 2017, at 11:07 AM, Alfred Schilken wrote:
> Hi all,
> 
> I installed the arm-none-eabi-gcc via brew as proposed in the 1.0.0
> mynewt documentation for Mac.
> 
> So I have the version 4.9.3:
> 
> 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 227977]
> Copyright (C) 2014 Free Software Foundation, Inc.
> 
> 
> This old compiler uses the gnu89 "C-standard" as default. To check this I
> just included a nonsense for loop in  /apps/blinky/src/main.c:
> ...
> for(int i=0; i < 3; i++){
>   rc += i;
> }
> while (1) {
> ...
> 
> When running a "newt build" the compiler complains and proposes to use
> the option -std=gnu99 
> 
> newt build my_blinky_microbit
> Building target targets/my_blinky_microbit
> Compiling apps/blinky/src/main.c
> Error: apps/blinky/src/main.c: In function 'main':
> apps/blinky/src/main.c:58:5: error: 'for' loop initial declarations are
> only allowed in C99 or C11 mode
>  for(int i=0; i < 3; i++){
>  ^
> apps/blinky/src/main.c:58:5: note: use option -std=c99, -std=gnu99,
> -std=c11 or -std=gnu11 to compile your code
> 
> 
> My question:
> 
> Is the mynewt documentation outdated and I should use a newer version of
> arm-none-eabi-gcc, which maybe has gnu99 (or gnu11) as default?
> 
> Or are there any side effects which prevents us using the gnu99-Standard?
> 
> If gnu99 is not evil in any kind I would prefer it over gnu89, which is
> now 28 years old and not even can define a variable in the for-loop.
> After many years of java, python and Swift my C is a bit rusty.
> So I have read Ben Klemens’ book „21 st Century C“ and he describes a lot
> of advantages in c99, like:
> compound literals for arrays and structs, variable-length macros,
> designated initializers, definition of variables not only at the top of a
> function, ...
> 
> 
> I appended the option -std=gnu99 to compiler.flags.default: in
> repos/apache-mynewt-core/compiler/arm-none-eabi-m0/compiler.yml 
> and had no obvious negative side-effects with that.
> 
> Maybe this -std=gnu99 should be set in the apache-mynewt-core repo or at
> least put as a hint in the documentation about "Installing the Cross
> Tools for ARM“.

Hello Alfred,

Since you're using homebrew you can:

$ brew cask install gcc-arm-embedded

Which will get the latest version (6.3.1) already built.

If you want to add the option you suggested you can always add it to
"compiler.flags.base" key in your compiler.yml (there is one for each
ARCH in compiler/ARCH/compiler.yml). I've moved away from gcc 4.x a very
long time ago and only built Mynewt with 5.x and 6.x so I'll leave the
specific answer of using "std=gnu99" to someone else. My recommendation
would be to upgrade! :P

Cheers,
Fabio Utzig