Re: newtmgr OTA error: slice bounds out of range [:-62]

[Szymon Janc]

Hi,

We are able to reproduce this on newtmgr master (1.11-dev), will try to fix
this before next release

On Fri, 16 Sept 2022 at 03:22, Mo Chen  wrote:

> Hi there,
>
> I encountered errors when using mynewt to DFU OTA.
>
> Environment:
> Intel Macbook pro
> MacOS: Monterey 12.5.1
>
> newt version: 1.10.0
> newtmgr version: tried with v1.10.0 and v1.9.0. Neither works with the same
> error.
>
> Any clues or help are highly appreciated!
>
>
> error message:
>
> mndrive@Mos-MBP-MnDRIVE ~ % newtmgr image upload -c testbrd
>
> /Users/xxx/Documents/Mynewt/test/bin/targets/testbrd/app/apps/testbrd/testbrd.img
>
>  0 / 163232 [--]
>   0.00%panic:
> runtime error: slice bounds out of range [:-62]
>
>
> goroutine 1 [running]:
>
> mynewt.apache.org/newtmgr/nmxact/xact.encodeUploadReq({0x451a240
> 
> ?,
> 0xc000304320?}, {0xc2e140?, 0x42bd8c6?, 0x5ba48ab08a0c882f?}, 0x98?,
> {0xc00038?, 0x0?, 0x421300?}, 0x0, ...)
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:120
> +0x146
>
> mynewt.apache.org/newtmgr/nmxact/xact.findChunkLen({0x451a240
> ,
> 0xc000304320}, {0xc2e140, 0x20, 0x20}, 0x0?, {0xc00038, 0x27da0,
> 0x27da1}, 0x0, ...)
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:139
> +0x131
>
> mynewt.apache.org/newtmgr/nmxact/xact.nextImageUploadReq({0x451a240
> 
> ,
> 0xc000304320}, 0x0?, {0xc00038, 0x27da0, 0x27da1}, 0x0, 0x0?)
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:177
> +0x1eb
>
> mynewt.apache.org/newtmgr/nmxact/xact.(*ImageUploadCmd).Run(0xc32200,
> {0x451a240, 0xc000304320})
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:353
> +0x24e
>
>
> mynewt.apache.org/newtmgr/nmxact/xact.(*ImageUpgradeCmd).runUpload(0xc32100
> ,
> {0x451a240, 0xc000304320})
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:510
> +0x1cb
>
> mynewt.apache.org/newtmgr/nmxact/xact.(*ImageUpgradeCmd).Run(0x7ff7bfeffbe5
> ?,
> {0x451a240?, 0xc000304320?})
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/nmxact/xact/image.go:536
> +0x6a
>
> mynewt.apache.org/newtmgr/newtmgr/cli.imageUploadCmd(0xc0001f4c80?,
> {0xc0001ad920?, 0x3?, 0x3?})
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/newtmgr/cli/image.go:212
> +0x30b
>
> github.com/spf13/cobra.(*Command).execute(0xc0001f4c80, {0xc0001ad830,
> 0x3,
> 0x3})
>
> /Users/mndrive/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830
> +0x663 
>
> github.com/spf13/cobra.(*Command).ExecuteC(0xccaf00)
>
> /Users/mndrive/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914
> +0x2ee 
>
> github.com/spf13/cobra.(*Command).Execute(...)
>
> /Users/mndrive/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864
>
> main.main()
>
>
> /Users/mndrive/Downloads/apache-mynewt-newtmgr-1.10.0/newtmgr/newtmgr.go:111
> +0x16f
>
>
>
> --
> Mo Chen
>


-- 
pozdrawiam
Szymon K. Janc

Re: newtmgr

[Timo Kolthoff]

Thx,
Do you have any input on my next question in the previous mail?

/BR

Den 8 aug. 2018 19:37 skrev aditi hilbert :
Hi Timo,

That is correct - currently, newtmgr is only point to point capable. It is 
possible to extend it to work over mesh and that would be useful ... but such 
functionality is not planned for a release yet.

thanks,
aditi

> On Aug 7, 2018, at 4:55 AM, Timo Kolthoff  wrote:
>
> Hi,
>
> Is it correct that newtmgr is only ble point to point capable, so no
> ble mesh support? Is it something that has been concidered or possible
> to be implemented?
>
> This implies that there will not be support for log fetching,
> statistics or software upgrading in a ble mesh network? Is this
> something that will be solved in the mesh networking specifications?
>
> If so, does anybody know when one could expect a release of this
> functionality?
>
> /BR

Re: newtmgr

[aditi hilbert]

Hi Timo,

That is correct - currently, newtmgr is only point to point capable. It is 
possible to extend it to work over mesh and that would be useful ... but such 
functionality is not planned for a release yet.

thanks,
aditi

> On Aug 7, 2018, at 4:55 AM, Timo Kolthoff  wrote:
> 
> Hi,
> 
> Is it correct that newtmgr is only ble point to point capable, so no
> ble mesh support? Is it something that has been concidered or possible
> to be implemented?
> 
> This implies that there will not be support for log fetching,
> statistics or software upgrading in a ble mesh network? Is this
> something that will be solved in the mesh networking specifications?
> 
> If so, does anybody know when one could expect a release of this
> functionality?
> 
> /BR

Re: newtmgr fs command fails in sim

[Kevin Townsend]

Hi Jacob,

But Kevins code snippet brings up something im thinking about. In his
comments he has

CONFIG_NFFS: 1# Initialize and configure NFFS into the
 system


I dont agree with that comment, whats thats actually doing is turning on
the config subsystem and telling it to create its own nffs. Then hes
coattail riding on config's nffs partition.

Came back to this again today writing some internal documentation.

I do agree this leads to some potentially false conclusions, especially to
someone new to Mynewt since 'CONFIG_NFFS' sounds like it may well do
what the comment is saying, and it's part of the official FS documentation
here: https://mynewt.apache.org/latest/os/modules/fs/fs.html#description

I missed that myself, but appreciate you pointing it out since it may have
cause a problem in the future that might not have been obvious at first
glance.

K.

Re: newtmgr fs command fails in sim

[Kevin Townsend]

Hi Jacob,

Excellent point about the flash usage, and figuring out how to perhaps
make it easier for packages to play well together in a single filesystem
without hijacking the config system out of necessity.

I dont agree with that comment, whats thats actually doing is turning on
the config subsystem and telling it to create its own nffs. Then hes
coattail riding on config's nffs partition.

the 'way' to create your own nffs seems to be to disable config entirely,
because in the bsp config fcb and nffs both want to use FLASH_AREA_NFFS,
and then add
 - "@apache-mynewt-core/fs/nffs"

But obviously it seems like youd be well within you're rights to share a
disk resource between a bunch of packages.

However the way config and most packages work is to take a whole flash area
for themselves and pass it to nffs or fcb or whatever, so they actually
dont seem to share very well? Maybe config should be less opinionated and
take a premade fs, which the user (or bsp) preconfigured as an fcb or fat
or nffs or whatever. Then it wouldnt feel like im using configs disk (and
if I turn config off, the disk I was using wouldnt go away)

Kevin

Re: newtmgr fs command fails in sim

[Jacob Rosenthal]

Maybe Im misunderstanding, as Im personally digging into a bunch of fs
stuff right now myself..

But Kevins code snippet brings up something im thinking about. In his
comments he has
>
> CONFIG_NFFS: 1# Initialize and configure NFFS into the
> system
>
I dont agree with that comment, whats thats actually doing is turning on
the config subsystem and telling it to create its own nffs. Then hes
coattail riding on config's nffs partition.

the 'way' to create your own nffs seems to be to disable config entirely,
because in the bsp config fcb and nffs both want to use FLASH_AREA_NFFS,
and then add
- "@apache-mynewt-core/fs/nffs"

But obviously it seems like youd be well within you're rights to share a
disk resource between a bunch of packages.

However the way config and most packages work is to take a whole flash area
for themselves and pass it to nffs or fcb or whatever, so they actually
dont seem to share very well? Maybe config should be less opinionated and
take a premade fs, which the user (or bsp) preconfigured as an fcb or fat
or nffs or whatever. Then it wouldnt feel like im using configs disk (and
if I turn config off, the disk I was using wouldnt go away)

I also think this fits into something else Im trying to figure out which is
multiple nffs partitions and external flash. The flash area concept doesnt
work at all for that currently.






On Fri, Jul 6, 2018 at 12:12 PM Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:

> Hi,
>
> On Fri, Jul 6, 2018 at 6:24 PM marko kiiskila  wrote:
> >
> >
> >
> > > On Jul 6, 2018, at 5:49 PM, Kevin Townsend 
> wrote:
> > >
> > > Hi Chris,
> > >> The error codes that come back in newtmgr responses are always (or at
> > >> least should be) MGMT_ERR codes:
> > >>
> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
> > >>
> > >> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't
> recognized
> > >> (it is also used for other conditions; seems like we should have a
> > >> dedicated error code for "command not supported).
> > > Thanks for the point, and the quick reply!
> > >
> > > Command not supported would be more helpful, yes, but not a major
> problem.
> > >> Did you enable the `FS_NMGR` syscfg setting?
> > > That was indeed the problem. I did dig through the various packages
> looking at the CFG values, but didn't notice that one. Works great in the
> sim now with:
> > >
> > > # Enable newtmgr commands.
> > > STATS_NEWTMGR: 1  # Enable stats over newtmgr
> > > LOG_NEWTMGR: 1# Enable log over newtmgr
> > > CONFIG_NEWTMGR: 1 # Enable config over newtmgr
> > > FS_NMGR: 1# Enable 'fs' access from newtmgr
> > >
> > > It's a shame the naming is sort of inconsistent (inner OCD self
> speaking), but that's a minor detail. :P
> > >
> >
> > I know what you mean. There’s other examples of the same. But then
> renaming these would
> > break people’s build targets. Which is not nice :)
> >
> > Although I guess we could do this if we gave people enough warning.
>
> We can introduce new setting and set its default value to old setting,
> i.e.:
>
> syscfg.defs:
> FS_NEWTMGR:
> value: 'MYNEWT_VAL_FS_NMGR'
>
> This way people can continue using old settings for now and then
> transition to new settings. Would be good if old value can be marked
> as deprecated and newt would emit warning if deprecated setting is
> overriden in other package.
>
> I did similar change in RTT already:
>
> https://github.com/apache/mynewt-core/commit/67c430c5ecc8ac06af256e5d1bd487d3b6efdedc
>
> Best,
> Andrzej
>

Re: newtmgr fs command fails in sim

[Andrzej Kaczmarek]

Hi,

On Fri, Jul 6, 2018 at 6:24 PM marko kiiskila  wrote:
>
>
>
> > On Jul 6, 2018, at 5:49 PM, Kevin Townsend  
> > wrote:
> >
> > Hi Chris,
> >> The error codes that come back in newtmgr responses are always (or at
> >> least should be) MGMT_ERR codes:
> >> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
> >>
> >> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized
> >> (it is also used for other conditions; seems like we should have a
> >> dedicated error code for "command not supported).
> > Thanks for the point, and the quick reply!
> >
> > Command not supported would be more helpful, yes, but not a major problem.
> >> Did you enable the `FS_NMGR` syscfg setting?
> > That was indeed the problem. I did dig through the various packages looking 
> > at the CFG values, but didn't notice that one. Works great in the sim now 
> > with:
> >
> > # Enable newtmgr commands.
> > STATS_NEWTMGR: 1  # Enable stats over newtmgr
> > LOG_NEWTMGR: 1# Enable log over newtmgr
> > CONFIG_NEWTMGR: 1 # Enable config over newtmgr
> > FS_NMGR: 1# Enable 'fs' access from newtmgr
> >
> > It's a shame the naming is sort of inconsistent (inner OCD self speaking), 
> > but that's a minor detail. :P
> >
>
> I know what you mean. There’s other examples of the same. But then renaming 
> these would
> break people’s build targets. Which is not nice :)
>
> Although I guess we could do this if we gave people enough warning.

We can introduce new setting and set its default value to old setting, i.e.:

syscfg.defs:
FS_NEWTMGR:
value: 'MYNEWT_VAL_FS_NMGR'

This way people can continue using old settings for now and then
transition to new settings. Would be good if old value can be marked
as deprecated and newt would emit warning if deprecated setting is
overriden in other package.

I did similar change in RTT already:
https://github.com/apache/mynewt-core/commit/67c430c5ecc8ac06af256e5d1bd487d3b6efdedc

Best,
Andrzej

Re: newtmgr fs command fails in sim

[marko kiiskila]

> On Jul 6, 2018, at 5:49 PM, Kevin Townsend  wrote:
> 
> Hi Chris,
>> The error codes that come back in newtmgr responses are always (or at
>> least should be) MGMT_ERR codes:
>> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
>> 
>> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized
>> (it is also used for other conditions; seems like we should have a
>> dedicated error code for "command not supported).
> Thanks for the point, and the quick reply!
> 
> Command not supported would be more helpful, yes, but not a major problem.
>> Did you enable the `FS_NMGR` syscfg setting?
> That was indeed the problem. I did dig through the various packages looking 
> at the CFG values, but didn't notice that one. Works great in the sim now 
> with:
> 
> # Enable newtmgr commands.
> STATS_NEWTMGR: 1  # Enable stats over newtmgr
> LOG_NEWTMGR: 1# Enable log over newtmgr
> CONFIG_NEWTMGR: 1 # Enable config over newtmgr
> FS_NMGR: 1# Enable 'fs' access from newtmgr
> 
> It's a shame the naming is sort of inconsistent (inner OCD self speaking), 
> but that's a minor detail. :P
> 

I know what you mean. There’s other examples of the same. But then renaming 
these would
break people’s build targets. Which is not nice :)

Although I guess we could do this if we gave people enough warning.

Re: newtmgr fs command fails in sim

[Kevin Townsend]

Hi Chris,

The error codes that come back in newtmgr responses are always (or at
least should be) MGMT_ERR codes:
https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65

`MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized
(it is also used for other conditions; seems like we should have a
dedicated error code for "command not supported).

Thanks for the point, and the quick reply!

Command not supported would be more helpful, yes, but not a major problem.

Did you enable the `FS_NMGR` syscfg setting?
That was indeed the problem. I did dig through the various packages 
looking at the CFG values, but didn't notice that one. Works great in 
the sim now with:


    # Enable newtmgr commands.
    STATS_NEWTMGR: 1  # Enable stats over newtmgr
    LOG_NEWTMGR: 1    # Enable log over newtmgr
    CONFIG_NEWTMGR: 1 # Enable config over newtmgr
    FS_NMGR: 1    # Enable 'fs' access from newtmgr

It's a shame the naming is sort of inconsistent (inner OCD self 
speaking), but that's a minor detail. :P


Kevin

Re: newtmgr fs command fails in sim

[Christopher Collins]

Hi Kevin,

On Fri, Jul 06, 2018 at 02:41:17PM +0200, Kevin Townsend wrote:
> I'm doing some initial development using only the simulator (for 
> convenience sake), and was testing out 'newtmgr fs' support to quickly 
> get data to and from the simulator.
> 
> My sim target is setup to use NFFS using mostly default values:
> 
>      # NFFS filesystem
>      FS_CLI: 1 # Include shell FS commands
>      CONFIG_NFFS: 1    # Initialize and configure NFFS into the
> system
>      NFFS_DETECT_FAIL: 2   # Format a new NFFS file system on
> failure to detect
> 
> Everything works fine from shell when I start the .elf file and create 
> an NFFS file in code, and I can see the file and contents via cat:
> 
> ls /cfg
> 604693   5 /cfg/id.txt
> 604693 1 files
> 604900 compat> cat /cfg/id.txt
> 5678
> 
> But when I try to do anything with 'newtmgr fs' (up or down) I always 
> get *error 5*, which I assume corresponds to 
> https://github.com/apache/mynewt-core/blob/master/fs/fs/include/fs/fs.h#L72: 

The error codes that come back in newtmgr responses are always (or at
least should be) MGMT_ERR codes:
https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65

`MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized
(it is also used for other conditions; seems like we should have a
dedicated error code for "command not supported).

Did you enable the `FS_NMGR` syscfg setting?

Chris

Re: newtmgr on Android

[Brian Giori]

Hi Andrey,

I have built Android and iOS NewtMgr implementations which are
currently in a "private beta" (if you will) and are still under active
development. The plan is to release these libraries (Apache 2.0) when
they have stabilized, which for Android should be soon.

If you'd like access to the Android repo, I can get you a maven artifact
which you can use in your app to perform firmware upgrades (among
other things). I am using jitpack to host the artifact since the code is
hosted in a private repository on github. In order to get you access to the
jitpack artifacts, I will need the github username for anyone that wants
access.

Brian



On Wed, Jun 27, 2018 at 9:19 AM, Jacob Rosenthal 
wrote:

> I dont know if that runtime sensors app has firmware update, but it has oic
> which would get you close
> https://github.com/runtimeco/android_sensor
>
> Also I have a web bluetooth solution that would work on a lot of android
> phones
> https://github.com/jacobrosenthal/web-newtmgr
>
>
>
> On Wed, Jun 27, 2018 at 8:37 AM andrey.serdt...@yotadevices.com <
> andrey.serdt...@yotadevices.com> wrote:
>
> > Hi all,
> >
> > Does anybody knows if newtmgr is available under Android?
> > The task is to update mynewt device firmware from Android phone.
> >
> > Thank you.
> >
> > BR,
> > Andrey
> >
> >
>

Re: newtmgr on Android

[Jacob Rosenthal]

I dont know if that runtime sensors app has firmware update, but it has oic
which would get you close
https://github.com/runtimeco/android_sensor

Also I have a web bluetooth solution that would work on a lot of android
phones
https://github.com/jacobrosenthal/web-newtmgr



On Wed, Jun 27, 2018 at 8:37 AM andrey.serdt...@yotadevices.com <
andrey.serdt...@yotadevices.com> wrote:

> Hi all,
>
> Does anybody knows if newtmgr is available under Android?
> The task is to update mynewt device firmware from Android phone.
>
> Thank you.
>
> BR,
> Andrey
>
>

Re: newtmgr 'image confirm' returns 'Error: 1'

[Kevin Townsend]

Hi Christopher,

Thanks for the explanation between the test/basic-confirm and 
confirm-hash differences. I didn't realize the distinction, but it 
clarifies a number of things for me for the mobile app (visible in the 
store now: 
https://itunes.apple.com/app/adafruit-mynewt-manager/id1272085812?mt=8)


I'll try with the newtmgr commands again on a clean machine. It may well 
be that the error message is an artifact of some previous system or tool 
configuration.


Kevin


On 22/08/17 20:00, Christopher Collins wrote:

Hi Kevin,

On Wed, Aug 16, 2017 at 11:45:52PM +0200, Kevin Townsend wrote:

I'm doing some tests with newtmgr over serial since this is the lowest
cost mechanism for many users (no J-Link required), and the update
process as I understand it is as follows:

- $ newtmgr -c serial1 image upload mysignedimage.img
^ This will write the new image in slot=1 with no flags set
- $ newtmgr -c serial1 image test
4d0ff81e083f8cc9d428e8bb70ed86ae98f237ce8dd59bfd33f7493874addd1d
^ This will set the flags to 'pending' and when you reset, the image
will be moved into slot 0 and the old image will be switched to slot 1
- $ newtmgr -c serial1 reset
^ Wait for the flash switch to finish ...
  The new image is now marked as 'active' but the old image has the
'confirmed' flag set so resetting again will cause the device to revert
to the old image if no action is taken,

All correct.


so first we need to ...
- $ newtmgr -c serial1 image confirm
4d0ff81e083f8cc9d428e8bb70ed86ae98f237ce8dd59bfd33f7493874addd1d
^ This will 'confirm' the new image (I don't think the hash is
necessary though), and then the old image will no longer be marked as
'confirmed' and resetting will maintain the new image. Notice no more
'confirmed' flag on slot 1 here, and slot 0 is now 'confirmed'
  $ newtmgr -c serial1 image list
  Images:
   slot=0
  version: 0.7.0
  bootable: true
  flags: active confirmed
  hash:
4d0ff81e083f8cc9d428e8bb70ed86ae98f237ce8dd59bfd33f7493874addd1d
   slot=1
  version: 0.6.0
  bootable: true
  flags:
  hash:
9a8fce478019c5e806253c307d32ddeab559ff6dc2577670ff6e0b1cb72f929b
  Split status: N/A (0)

What confused me is that no matter if I use the has or not with 'image
confirm' I always get 'Error: 1' in the output, which is confusing.

$ newtmgr -c serial1 image confirm
4d0ff81e083f8cc9d428e8bb70ed86ae98f237ce8dd59bfd33f7493874addd1d
Error: 1

$ newtmgr -c serial1 image confirm
Error: 1

Is there a logical explanation for this? I'm running the 1.1 binaries
installed via brew on OS X 10.11.6.

The "image confirm" command behaves differently if you specify the hash
argument:

* Confirm-without-hash: This is the "safe" version of the command.  It
confirms the currently-running image.  This can only be used when you
are "testing out" an image (i.e., slot 0 is active but not confirmed,
slot 1 is confirmed but not active).

* Confirm : This is the unsafe version.  It allows you to bypass
the "image test" step.  Say you have the following image state:

 slot 0: active confirmed, hash=xxx
 slot 1: , hash=yyy

If you issue an "image confirm " command and reset the device,
the image state will look like this:

 slot 0: active confirmed, hash=yyy
 slot 1: , hash=xxx

In other words, this version of "image confirm" permanently swaps to an
untested image.  This might be useful for upgrading lots of devices
to a known-good image.

Regarding the "Error: 1" message - I'm afraid I don't have an
explanation.  Are you sending the confirms immediately after the "image
list" commands?  That is, is the board in the (slot0: active confirmed,
slot1: ) state when you get the error?  If so, I am not able
to reproduce that behavior:

 [ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c bhd-oic --name c5 
image list
 Images:
  slot=0
 version: 5.5.5.5
 bootable: true
 flags: active confirmed
 hash: ec4044b698f06f9d3128b2b900c4da0d15a500b77f0378a2bad5f87b43c1bd42
  slot=1
 version: 0.0.0
 bootable: true
 flags:
 hash: 59477eca25d3deb4edc0b1ef80f1f517f37b90d127ef33597d21ba171446d693
 Split status: N/A (0)

 [ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c bhd-oic --name c5 
image confirm
 Images:
  slot=0
 version: 5.5.5.5
 bootable: true
 flags: active confirmed
 hash: ec4044b698f06f9d3128b2b900c4da0d15a500b77f0378a2bad5f87b43c1bd42
  slot=1
 version: 0.0.0
 bootable: true
 flags:
 hash: 59477eca25d3deb4edc0b1ef80f1f517f37b90d127ef33597d21ba171446d693
 Split status: N/A (0)

 [ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c bhd-oic --name c5 
image confirm ec4044b698f06f9d3128b2b900c4da0d15a500b77f0378a2bad5f87b43c1bd42
 Images:
  slot=0
 version: 5.5.5.5
 bootable: true
 flags: active confirmed
 

Re: Newtmgr moved to new repo

[Paul LaCrosse]

Tried option #2, which worked.  Thanks Chris!

On Mon, Jul 10, 2017 at 4:23 PM, Christopher Collins 
wrote:

> Hi Paul,
>
> On Mon, Jul 10, 2017 at 04:13:30PM -0400, Paul LaCrosse wrote:
> > Pauls-MacBook-Pro-2:testgoget paul$  go get mynewt.apache.org/newtmgr/.
> ..
> >
> > # cd /Users/paul/dev/go/src/mynewt.apache.org/newt; git pull --ff-only
> >
> > fatal: repository '
> > https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/' not
> > found
> >
> > package mynewt.apache.org/newtmgr/nmxact/example/ble_loop
> >
> > imports mynewt.apache.org/newt/util/unixchild: exit status 1
> >
> > Download of latest newtmgr, produces error.
>
> It appears your version of the newt repo was cloned from the old apache
> git server (before Mynewt moved to github).  Using "go get" with the
> mynewt.apache.org vanity domain helps to avoid problems like this.  To
> solve this, I would either:
>
> 1. Change the newt repo remote to the github URL:
>
> cd $GOPATH/src/mynewt.apache.org/newt &&
> git remote set-url origin https://github.com/apache/
> incubator-mynewt-newt.git
>
> Or,
>
> 2. Completely remove $GOPATH/src/mynewt.apache.org and reinstall it with
> `go get mynewt.apache.org/newt/...`
>
> Thanks,
> Chris
>

Re: Newtmgr moved to new repo

[Christopher Collins]

Hi Paul,

On Mon, Jul 10, 2017 at 04:13:30PM -0400, Paul LaCrosse wrote:
> Pauls-MacBook-Pro-2:testgoget paul$  go get mynewt.apache.org/newtmgr/...
> 
> # cd /Users/paul/dev/go/src/mynewt.apache.org/newt; git pull --ff-only
> 
> fatal: repository '
> https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/' not
> found
> 
> package mynewt.apache.org/newtmgr/nmxact/example/ble_loop
> 
> imports mynewt.apache.org/newt/util/unixchild: exit status 1
> 
> Download of latest newtmgr, produces error.

It appears your version of the newt repo was cloned from the old apache
git server (before Mynewt moved to github).  Using "go get" with the
mynewt.apache.org vanity domain helps to avoid problems like this.  To
solve this, I would either:

1. Change the newt repo remote to the github URL:

cd $GOPATH/src/mynewt.apache.org/newt &&
git remote set-url origin 
https://github.com/apache/incubator-mynewt-newt.git

Or,

2. Completely remove $GOPATH/src/mynewt.apache.org and reinstall it with
`go get mynewt.apache.org/newt/...`

Thanks,
Chris

Re: Newtmgr moved to new repo

[Paul LaCrosse]

Pauls-MacBook-Pro-2:testgoget paul$  go get mynewt.apache.org/newtmgr/...

# cd /Users/paul/dev/go/src/mynewt.apache.org/newt; git pull --ff-only

fatal: repository '
https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/' not
found

package mynewt.apache.org/newtmgr/nmxact/example/ble_loop

imports mynewt.apache.org/newt/util/unixchild: exit status 1

Download of latest newtmgr, produces error.


On Mon, Jul 10, 2017 at 1:44 PM, Christopher Collins 
wrote:

> Hello all,
>
> The newtmgr tool location has changed:
>
> From: https://github.com/apache/mynewt-newt/tree/master/newtmgr
>   To: https://github.com/apache/mynewt-newtmgr/tree/master/newtmgr
>
> To download the latest newtmgr, use the following command:
>
> go get mynewt.apache.org/newtmgr/...
>
> The plan is to remove the "old" newtmgr from the newt repo when Mynewt
> 1.1 is released.
>
> The "new" newtmgr has improved BLE support.  BLE should now work more
> reliably on Linux and macOS.  The particulars are documented here:
> http://mynewt.apache.org/latest/newtmgr/command_list/newtmgr_conn/
>
> My preferred way to use BLE is to create a "ble" connection profile with
> an empty connstring:
>
> newtmgr conn add ble type=ble connstring=' '
>
> Then, specify the target device name on the command line each time you
> send a command:
>
> newtmgr -c ble --name nimble-bleprph echo hello
>
> Rationale:
> The reason for the move is to simplify downloading and
> building of newt and newtmgr.  The "go get" command works better with
> the "mynewt.apache.org" vanity domain when there is one application per
> repo.  Since the vanity domain requires the use of the "..." syntax in
> the `go get` command, the entire repo gets downloaded, including
> applications that weren't requested.
>
> Thanks,
> Chris
>