You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Kevin Townsend <ke...@adafruit.com> on 2016/09/23 09:46:23 UTC
Re: newtmgr over Serial
Hi Will (and company),
Sorry to recycle an old thread, but I was just doing some testing with
the bootloader on the latest release, and wanted to come back to the
issue of having a purely serial option for flashing images in the
bootloader. From my perspective there are a number of valid use cases
around uploading an image on an empty device (other than the bootloader)
over UART or USB CDC, but others may disagree.
This would provide an inexpensive mechanism to debrick boards, for
example, as well as a useful tool for production environments where you
don�t have the financial or practical means to send a half dozen
commercially licensed JLink to your assembly house or somewhere in China
for testing then flashing.
Being able to run something like this with ONLY the bootloader present
would be a big plus I think:
$ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
As things stand today, you can only do this (I think, please correct me
if I�m wrong) if you already have a valid image flashed and shell
support enabled for newtmgr.
Is there an obstacle anyone can see about why this wouldn't be practical
to implement with only the bootloader present? We've been focused on
application level code and the peripheral side of nimble so I haven't
looked at the bootloader code at all, but will have a look to try to get
a better sense of the requirements here to use it with serial without
any sort of shell support on the application side.
K.
On 08/06/16 23:59, will sanfilippo wrote:
> +1
>
> Guess that is my one cent opinion :-) Wouldnt be hard to do and is definitely a handy option for a certain group of folks. BTW, and this is a minor detail, I am not so much for polling a pin; the bootloader can look at the serial port for a certain sequence of characters. If it sees them it enters download mode. If it doesnt see anything it likes after that (or doesnt see that sequence), it tries to boot an image. If it cant, it just cycles back. If it boots a valid image, all good. If it boots a bricked image, you just gotta power cycle it. Shouldnt increase boot time too much (which is something to keep in mind imo).
>
>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>
>> I\u2019m convinced that we should have an option for using standalone boot loader
>> with which you can upload images. These are valid use cases.
>>
>> We should make that happen.
>>
Re: newtmgr over Serial
Posted by Wayne Keenan <wa...@gmail.com>.
+1 for bootloader-only serial programming
All the best
Wayne
On 23 September 2016 at 10:46, Kevin Townsend <ke...@adafruit.com> wrote:
> Hi Will (and company),
>
> Sorry to recycle an old thread, but I was just doing some testing with the
> bootloader on the latest release, and wanted to come back to the issue of
> having a purely serial option for flashing images in the bootloader. From
> my perspective there are a number of valid use cases around uploading an
> image on an empty device (other than the bootloader) over UART or USB CDC,
> but others may disagree.
>
> This would provide an inexpensive mechanism to debrick boards, for
> example, as well as a useful tool for production environments where you
> don´t have the financial or practical means to send a half dozen
> commercially licensed JLink to your assembly house or somewhere in China
> for testing then flashing.
>
> Being able to run something like this with ONLY the bootloader present
> would be a big plus I think:
>
> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
>
> As things stand today, you can only do this (I think, please correct me if
> I´m wrong) if you already have a valid image flashed and shell support
> enabled for newtmgr.
>
> Is there an obstacle anyone can see about why this wouldn't be practical
> to implement with only the bootloader present? We've been focused on
> application level code and the peripheral side of nimble so I haven't
> looked at the bootloader code at all, but will have a look to try to get a
> better sense of the requirements here to use it with serial without any
> sort of shell support on the application side.
>
> K.
>
>
>
> On 08/06/16 23:59, will sanfilippo wrote:
>
>> +1
>>
>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is
>> definitely a handy option for a certain group of folks. BTW, and this is a
>> minor detail, I am not so much for polling a pin; the bootloader can look
>> at the serial port for a certain sequence of characters. If it sees them it
>> enters download mode. If it doesnt see anything it likes after that (or
>> doesnt see that sequence), it tries to boot an image. If it cant, it just
>> cycles back. If it boots a valid image, all good. If it boots a bricked
>> image, you just gotta power cycle it. Shouldnt increase boot time too much
>> (which is something to keep in mind imo).
>>
>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>
>>> I’m convinced that we should have an option for using standalone boot
>>> loader
>>> with which you can upload images. These are valid use cases.
>>>
>>> We should make that happen.
>>>
>>>
>
Re: newtmgr over Serial
Posted by Sterling Hughes <st...@apache.org>.
No worries: try setting the feature vs CFLAGS. (Note: all good efforts
learning about features will be unfortunately useless, as we\u2019ve
changed to sys config in develop :-( ).
# clear cflags
newt target set bootloader cflags=
# set feature
newt target set bootloader features=BOOT_SERIAL
That will enable extra dependencies and automatically set cflags. I
believe marko also had a comment in the pkg.yml about uncommenting
libs/console/stub \u2014 worth looking at that if you have conflicts with
console after enabling the BOOT_SERIAL feature.
On 23 Sep 2016, at 9:20, Kevin Townsend wrote:
> Hi Sterling,
>
> Thanks for the heads up. I added the cflag via '$ newt target set
> bootloader cflags=-DBOOT_SERIAL' and I can see that it exists in
> '/repos/apache-mynewt-core/libs/boot_serial', though when I try to
> build I'm getting:
>
> $ newt build bootloader
> Building target targets/bootloader
> Compiling boot.c
> Error: boot.c:33:37: fatal error: boot_serial/boot_serial.h: No
> such
> file or directory
> #include <boot_serial/boot_serial.h>
> ^
> compilation terminated.
>
> The target definition seems fine though (I'm on the 'master' branch
> just as a FYI):
>
> $ newt target show
> targets/bootloader
> app=@apache-mynewt-core/apps/boot
> bsp=hw/bsp/feather52
> build_profile=optimized
> cflags=-DBOOT_SERIAL
>
> I also tried 'newt install' and 'newt upgrade' to refresh the local
> setup but same results. Perhaps I need to update something in the
> local BSP, though ... I'll have a look at that.
>
> Thanks for the heads up about this library, though. Somehow it never
> ended up on my radar, but I'll try to get this building and test it
> out this weekend.
>
> BR,
>
> Kevin
>
Re: newtmgr over Serial
Posted by Kevin Townsend <ke...@adafruit.com>.
Hi Sterling,
Thanks for the heads up. I added the cflag via '$ newt target set
bootloader cflags=-DBOOT_SERIAL' and I can see that it exists in
'/repos/apache-mynewt-core/libs/boot_serial', though when I try to build
I'm getting:
$ newt build bootloader
Building target targets/bootloader
Compiling boot.c
Error: boot.c:33:37: fatal error: boot_serial/boot_serial.h: No such
file or directory
#include <boot_serial/boot_serial.h>
^
compilation terminated.
The target definition seems fine though (I'm on the 'master' branch just
as a FYI):
$ newt target show
targets/bootloader
app=@apache-mynewt-core/apps/boot
bsp=hw/bsp/feather52
build_profile=optimized
cflags=-DBOOT_SERIAL
I also tried 'newt install' and 'newt upgrade' to refresh the local
setup but same results. Perhaps I need to update something in the local
BSP, though ... I'll have a look at that.
Thanks for the heads up about this library, though. Somehow it never
ended up on my radar, but I'll try to get this building and test it out
this weekend.
BR,
Kevin
Re: newtmgr over Serial
Posted by marko kiiskila <ma...@runtime.io>.
Ok, there’s a bug there, caused by debug printfs. Probably my fault.
There is a call to console_printf() in bootloader. apps/boot/boot.c, lines 120-121.
Those should not be there. And they will crash nrf52 when building with
BOOT_SERIAL set. Remove them, and you should be ok.
> On Sep 23, 2016, at 3:12 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>
>> On Sep 23, 2016, at 12:15 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>>
>> Hi Marko,
>>
>> Thanks for the reply ... I wasn't sure what to do with the console/stub dependency though ... where should this be set?
>
> You should remove the console/stub from apps/boot/pkg.yml.
> libs/boot_serial needs console/full.
> I imagine this step can be made automatic once the new sysconfig stuff is brought in.
>
> As a side note; this warning seems to be harmless on my build, i.e. it does pick up the full console, but I might
> be just getting lucky.
>
>>
>> #
>> # Define BOOT_SERIAL in target features to include serial downloader.
>> # And uncomment 'libs/console/stub' from pkg.deps.
>> #
>>
>> This builds properly but when I flash the bootloader on an nRF52 with an app, the app doesn't start up, but disabling BOOT_SERIAL it runs fine, so I'm clearly defining the lib/console/stub dependency in the wrong place (clear because I'm getting conflict alerts to the console libs when I compile).
>>
>
> Did you try running the bootloader under debugger? Maybe it actually stops to wait for serial input?
> I have to admit I have not tried this code on nrf52, but it should be functional.
>
>> I had this in the target.yml file for the bootloader target, but that doesn't seem to be correct:
>>
>> target.deps: "@apache-mynewt-core/libs/console/stub”
>> K.
>>
>> On 23/09/16 20:56, marko kiiskila wrote:
>>> That all looks good.
>>> boot_serial package is supposed to be small.
>>>
>>> —8<—cut-start—
>>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newt target show boot_mkr1000
>>> targets/boot_mkr1000
>>> app=@apache-mynewt-core/apps/boot
>>> bsp=@mynewt-arduino-zero/hw/bsp/arduino_mkr1000
>>> build_profile=optimized
>>> features=BOOT_SERIAL
>>> —8<—cut end —
>>>
>>> Indeed, you need to add 3 defines to your BSP. For testing, I only added
>>> those to Arduino MKR1000 BSP. As you’ve probably figured out, these are for
>>> the pin to use, and whether you want that pin pulled up/down, and whether
>>> to compare pin value against 0 or 1.
>>>
>>> —8< — cut start —
>>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ grep BOOT_SERIAL repos/mynewt-arduino-zero/hw/bsp/arduino_mkr1000/include/bsp/bsp.h
>>> #ifdef BOOT_SERIAL
>>> #define BOOT_SERIAL_DETECT_PIN 43
>>> #define BOOT_SERIAL_DETECT_PIN_CFG GPIO_PULL_UP
>>> #define BOOT_SERIAL_DETECT_PIN_VAL 0
>>> —8< — cut end —
>>> I thought I sent an email about this, but maybe it was missing these details. Sorry
>>> about that.
>>>
>>> Now that we can take interrupts even without OS, the size of the bootloader with
>>> serial support could be made smaller. At the moment it still starts the OS, while the
>>> boot_serial stuff could just spin in a loop waiting for input.
>>> That would be attractive here, because then you could have the bootloader smaller
>>> than 16k (looks like it’s really close for your BSP).
>>>
>>>> On Sep 23, 2016, at 11:22 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>>>>
>>>> Hi Sterling,
>>>>
>>>> I saw the note on the dependency, but is the target the right place to be adding the dep entry as follows:
>>>>
>>>> $ newt target set bootloader
>>>> deps="@apache-mynewt-core/libs/console/stub"
>>>>
>>>> Adding the two missing defines at the BSP level for BOOT_SERIAL gets this building at least
>>>>
>>>> - BOOT_SERIAL_DETECT_PIN
>>>> - BOOT_SERIAL_DETECT_PIN_CFG
>>>>
>>>> The size still seems reasonable to me (<32KB), though I haven't tested this yet to see if it's being built correctly and the warning is setting an alarm bell off for me, but I'll test shortly:
>>>>
>>>> $ newt size bootloader
>>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>>>> FLASH RAM
>>>> 23 222 *fill*
>>>> 2136 32 baselibc.a
>>>> 330 2128 boot.a
>>>> 1141 12 boot_serial.a
>>>> 1717 1132 bootutil.a
>>>> 64 0 cmsis-core.a
>>>> 20 1 config.a
>>>> 124 0 crt0.o
>>>> 8 0 crti.o
>>>> 16 0 crtn.o
>>>> 640 512 feather52.a
>>>> 983 196 full.a
>>>> 634 8 hal.a
>>>> 80 0 libg.a
>>>> 1436 0 libgcc.a
>>>> 1200 0 mbedtls.a
>>>> 1837 40 nrf52xxx.a
>>>> 3322 809 os.a
>>>> 945 0 util.a
>>>>
>>>> objsize
>>>> text data bss dec hex filename
>>>> 16644 128 4532 21304 5338 bin/bootloader/apps/boot/boot.elf
>>>>
>>>> K.
>>>>
>>>>
>>>> On 23/09/16 17:57, Sterling Hughes wrote:
>>>>> Hi Kevin,
>>>>>
>>>>> I think (and I’ll let Marko chime in here), you can use the boot_serial package to achieve this (apache-mynewt-core/libs/boot_serial.)
>>>>>
>>>>> It speaks the newtmgr protocol, but doesn’t require the shell task or an image to be programmed. I think it will slightly explode the size of your boot loader, but that shouldn’t be a huge issue on the NRF52.
>>>>>
>>>>> apps/boot/ has the following options.
>>>>>
>>>>> #
>>>>> # Define BOOT_SERIAL in target features to include serial downloader.
>>>>> # And uncomment 'libs/console/stub' from pkg.deps.
>>>>> #
>>>>> pkg.deps.BOOT_SERIAL.OVERWRITE:
>>>>> - libs/console/full
>>>>> - libs/boot_serial
>>>>> pkg.cflags.BOOT_SERIAL:
>>>>> - -DBOOT_SERIAL
>>>>>
>>>>> It’s (unfortunately) been awhile since I’ve tested this, but we’ll take a look today and make sure it’s still functioning (it should be.)
>>>>>
>>>>> Sterling
>>>>>
>>>>> On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
>>>>>
>>>>>> Hi Will (and company),
>>>>>>
>>>>>> Sorry to recycle an old thread, but I was just doing some testing with the bootloader on the latest release, and wanted to come back to the issue of having a purely serial option for flashing images in the bootloader. From my perspective there are a number of valid use cases around uploading an image on an empty device (other than the bootloader) over UART or USB CDC, but others may disagree.
>>>>>>
>>>>>> This would provide an inexpensive mechanism to debrick boards, for example, as well as a useful tool for production environments where you don´t have the financial or practical means to send a half dozen commercially licensed JLink to your assembly house or somewhere in China for testing then flashing.
>>>>>>
>>>>>> Being able to run something like this with ONLY the bootloader present would be a big plus I think:
>>>>>>
>>>>>> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
>>>>>>
>>>>>> As things stand today, you can only do this (I think, please correct me if I´m wrong) if you already have a valid image flashed and shell support enabled for newtmgr.
>>>>>>
>>>>>> Is there an obstacle anyone can see about why this wouldn't be practical to implement with only the bootloader present? We've been focused on application level code and the peripheral side of nimble so I haven't looked at the bootloader code at all, but will have a look to try to get a better sense of the requirements here to use it with serial without any sort of shell support on the application side.
>>>>>>
>>>>>> K.
>>>>>>
>>>>>> On 08/06/16 23:59, will sanfilippo wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is definitely a handy option for a certain group of folks. BTW, and this is a minor detail, I am not so much for polling a pin; the bootloader can look at the serial port for a certain sequence of characters. If it sees them it enters download mode. If it doesnt see anything it likes after that (or doesnt see that sequence), it tries to boot an image. If it cant, it just cycles back. If it boots a valid image, all good. If it boots a bricked image, you just gotta power cycle it. Shouldnt increase boot time too much (which is something to keep in mind imo).
>>>>>>>
>>>>>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>>>>>
>>>>>>>> I’m convinced that we should have an option for using standalone boot loader
>>>>>>>> with which you can upload images. These are valid use cases.
>>>>>>>>
>>>>>>>> We should make that happen.
>>>>>>>>
>>
>
Re: newtmgr over Serial
Posted by marko kiiskila <ma...@runtime.io>.
> On Sep 23, 2016, at 12:15 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>
> Hi Marko,
>
> Thanks for the reply ... I wasn't sure what to do with the console/stub dependency though ... where should this be set?
You should remove the console/stub from apps/boot/pkg.yml.
libs/boot_serial needs console/full.
I imagine this step can be made automatic once the new sysconfig stuff is brought in.
As a side note; this warning seems to be harmless on my build, i.e. it does pick up the full console, but I might
be just getting lucky.
>
> #
> # Define BOOT_SERIAL in target features to include serial downloader.
> # And uncomment 'libs/console/stub' from pkg.deps.
> #
>
> This builds properly but when I flash the bootloader on an nRF52 with an app, the app doesn't start up, but disabling BOOT_SERIAL it runs fine, so I'm clearly defining the lib/console/stub dependency in the wrong place (clear because I'm getting conflict alerts to the console libs when I compile).
>
Did you try running the bootloader under debugger? Maybe it actually stops to wait for serial input?
I have to admit I have not tried this code on nrf52, but it should be functional.
> I had this in the target.yml file for the bootloader target, but that doesn't seem to be correct:
>
> target.deps: "@apache-mynewt-core/libs/console/stub”
> K.
>
> On 23/09/16 20:56, marko kiiskila wrote:
>> That all looks good.
>> boot_serial package is supposed to be small.
>>
>> —8<—cut-start—
>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newt target show boot_mkr1000
>> targets/boot_mkr1000
>> app=@apache-mynewt-core/apps/boot
>> bsp=@mynewt-arduino-zero/hw/bsp/arduino_mkr1000
>> build_profile=optimized
>> features=BOOT_SERIAL
>> —8<—cut end —
>>
>> Indeed, you need to add 3 defines to your BSP. For testing, I only added
>> those to Arduino MKR1000 BSP. As you’ve probably figured out, these are for
>> the pin to use, and whether you want that pin pulled up/down, and whether
>> to compare pin value against 0 or 1.
>>
>> —8< — cut start —
>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ grep BOOT_SERIAL repos/mynewt-arduino-zero/hw/bsp/arduino_mkr1000/include/bsp/bsp.h
>> #ifdef BOOT_SERIAL
>> #define BOOT_SERIAL_DETECT_PIN 43
>> #define BOOT_SERIAL_DETECT_PIN_CFG GPIO_PULL_UP
>> #define BOOT_SERIAL_DETECT_PIN_VAL 0
>> —8< — cut end —
>> I thought I sent an email about this, but maybe it was missing these details. Sorry
>> about that.
>>
>> Now that we can take interrupts even without OS, the size of the bootloader with
>> serial support could be made smaller. At the moment it still starts the OS, while the
>> boot_serial stuff could just spin in a loop waiting for input.
>> That would be attractive here, because then you could have the bootloader smaller
>> than 16k (looks like it’s really close for your BSP).
>>
>>> On Sep 23, 2016, at 11:22 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>>>
>>> Hi Sterling,
>>>
>>> I saw the note on the dependency, but is the target the right place to be adding the dep entry as follows:
>>>
>>> $ newt target set bootloader
>>> deps="@apache-mynewt-core/libs/console/stub"
>>>
>>> Adding the two missing defines at the BSP level for BOOT_SERIAL gets this building at least
>>>
>>> - BOOT_SERIAL_DETECT_PIN
>>> - BOOT_SERIAL_DETECT_PIN_CFG
>>>
>>> The size still seems reasonable to me (<32KB), though I haven't tested this yet to see if it's being built correctly and the warning is setting an alarm bell off for me, but I'll test shortly:
>>>
>>> $ newt size bootloader
>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>>> FLASH RAM
>>> 23 222 *fill*
>>> 2136 32 baselibc.a
>>> 330 2128 boot.a
>>> 1141 12 boot_serial.a
>>> 1717 1132 bootutil.a
>>> 64 0 cmsis-core.a
>>> 20 1 config.a
>>> 124 0 crt0.o
>>> 8 0 crti.o
>>> 16 0 crtn.o
>>> 640 512 feather52.a
>>> 983 196 full.a
>>> 634 8 hal.a
>>> 80 0 libg.a
>>> 1436 0 libgcc.a
>>> 1200 0 mbedtls.a
>>> 1837 40 nrf52xxx.a
>>> 3322 809 os.a
>>> 945 0 util.a
>>>
>>> objsize
>>> text data bss dec hex filename
>>> 16644 128 4532 21304 5338 bin/bootloader/apps/boot/boot.elf
>>>
>>> K.
>>>
>>>
>>> On 23/09/16 17:57, Sterling Hughes wrote:
>>>> Hi Kevin,
>>>>
>>>> I think (and I’ll let Marko chime in here), you can use the boot_serial package to achieve this (apache-mynewt-core/libs/boot_serial.)
>>>>
>>>> It speaks the newtmgr protocol, but doesn’t require the shell task or an image to be programmed. I think it will slightly explode the size of your boot loader, but that shouldn’t be a huge issue on the NRF52.
>>>>
>>>> apps/boot/ has the following options.
>>>>
>>>> #
>>>> # Define BOOT_SERIAL in target features to include serial downloader.
>>>> # And uncomment 'libs/console/stub' from pkg.deps.
>>>> #
>>>> pkg.deps.BOOT_SERIAL.OVERWRITE:
>>>> - libs/console/full
>>>> - libs/boot_serial
>>>> pkg.cflags.BOOT_SERIAL:
>>>> - -DBOOT_SERIAL
>>>>
>>>> It’s (unfortunately) been awhile since I’ve tested this, but we’ll take a look today and make sure it’s still functioning (it should be.)
>>>>
>>>> Sterling
>>>>
>>>> On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
>>>>
>>>>> Hi Will (and company),
>>>>>
>>>>> Sorry to recycle an old thread, but I was just doing some testing with the bootloader on the latest release, and wanted to come back to the issue of having a purely serial option for flashing images in the bootloader. From my perspective there are a number of valid use cases around uploading an image on an empty device (other than the bootloader) over UART or USB CDC, but others may disagree.
>>>>>
>>>>> This would provide an inexpensive mechanism to debrick boards, for example, as well as a useful tool for production environments where you don´t have the financial or practical means to send a half dozen commercially licensed JLink to your assembly house or somewhere in China for testing then flashing.
>>>>>
>>>>> Being able to run something like this with ONLY the bootloader present would be a big plus I think:
>>>>>
>>>>> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
>>>>>
>>>>> As things stand today, you can only do this (I think, please correct me if I´m wrong) if you already have a valid image flashed and shell support enabled for newtmgr.
>>>>>
>>>>> Is there an obstacle anyone can see about why this wouldn't be practical to implement with only the bootloader present? We've been focused on application level code and the peripheral side of nimble so I haven't looked at the bootloader code at all, but will have a look to try to get a better sense of the requirements here to use it with serial without any sort of shell support on the application side.
>>>>>
>>>>> K.
>>>>>
>>>>> On 08/06/16 23:59, will sanfilippo wrote:
>>>>>> +1
>>>>>>
>>>>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is definitely a handy option for a certain group of folks. BTW, and this is a minor detail, I am not so much for polling a pin; the bootloader can look at the serial port for a certain sequence of characters. If it sees them it enters download mode. If it doesnt see anything it likes after that (or doesnt see that sequence), it tries to boot an image. If it cant, it just cycles back. If it boots a valid image, all good. If it boots a bricked image, you just gotta power cycle it. Shouldnt increase boot time too much (which is something to keep in mind imo).
>>>>>>
>>>>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>>>>
>>>>>>> I’m convinced that we should have an option for using standalone boot loader
>>>>>>> with which you can upload images. These are valid use cases.
>>>>>>>
>>>>>>> We should make that happen.
>>>>>>>
>
Re: newtmgr over Serial
Posted by Kevin Townsend <ke...@adafruit.com>.
Hi Marko,
Thanks for the reply ... I wasn't sure what to do with the console/stub
dependency though ... where should this be set?
#
# Define BOOT_SERIAL in target features to include serial downloader.
# And uncomment 'libs/console/stub' from pkg.deps.
#
This builds properly but when I flash the bootloader on an nRF52 with an
app, the app doesn't start up, but disabling BOOT_SERIAL it runs fine,
so I'm clearly defining the lib/console/stub dependency in the wrong
place (clear because I'm getting conflict alerts to the console libs
when I compile).
I had this in the target.yml file for the bootloader target, but that
doesn't seem to be correct:
target.deps: "@apache-mynewt-core/libs/console/stub"
K.
On 23/09/16 20:56, marko kiiskila wrote:
> That all looks good.
> boot_serial package is supposed to be small.
>
> \u20148<\u2014cut-start\u2014
> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newt target show boot_mkr1000
> targets/boot_mkr1000
> app=@apache-mynewt-core/apps/boot
> bsp=@mynewt-arduino-zero/hw/bsp/arduino_mkr1000
> build_profile=optimized
> features=BOOT_SERIAL
> \u20148<\u2014cut end \u2014
>
> Indeed, you need to add 3 defines to your BSP. For testing, I only added
> those to Arduino MKR1000 BSP. As you\u2019ve probably figured out, these are for
> the pin to use, and whether you want that pin pulled up/down, and whether
> to compare pin value against 0 or 1.
>
> \u20148< \u2014 cut start \u2014
> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ grep BOOT_SERIAL repos/mynewt-arduino-zero/hw/bsp/arduino_mkr1000/include/bsp/bsp.h
> #ifdef BOOT_SERIAL
> #define BOOT_SERIAL_DETECT_PIN 43
> #define BOOT_SERIAL_DETECT_PIN_CFG GPIO_PULL_UP
> #define BOOT_SERIAL_DETECT_PIN_VAL 0
> \u20148< \u2014 cut end \u2014
> I thought I sent an email about this, but maybe it was missing these details. Sorry
> about that.
>
> Now that we can take interrupts even without OS, the size of the bootloader with
> serial support could be made smaller. At the moment it still starts the OS, while the
> boot_serial stuff could just spin in a loop waiting for input.
> That would be attractive here, because then you could have the bootloader smaller
> than 16k (looks like it\u2019s really close for your BSP).
>
>> On Sep 23, 2016, at 11:22 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>>
>> Hi Sterling,
>>
>> I saw the note on the dependency, but is the target the right place to be adding the dep entry as follows:
>>
>> $ newt target set bootloader
>> deps="@apache-mynewt-core/libs/console/stub"
>>
>> Adding the two missing defines at the BSP level for BOOT_SERIAL gets this building at least
>>
>> - BOOT_SERIAL_DETECT_PIN
>> - BOOT_SERIAL_DETECT_PIN_CFG
>>
>> The size still seems reasonable to me (<32KB), though I haven't tested this yet to see if it's being built correctly and the warning is setting an alarm bell off for me, but I'll test shortly:
>>
>> $ newt size bootloader
>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
>> FLASH RAM
>> 23 222 *fill*
>> 2136 32 baselibc.a
>> 330 2128 boot.a
>> 1141 12 boot_serial.a
>> 1717 1132 bootutil.a
>> 64 0 cmsis-core.a
>> 20 1 config.a
>> 124 0 crt0.o
>> 8 0 crti.o
>> 16 0 crtn.o
>> 640 512 feather52.a
>> 983 196 full.a
>> 634 8 hal.a
>> 80 0 libg.a
>> 1436 0 libgcc.a
>> 1200 0 mbedtls.a
>> 1837 40 nrf52xxx.a
>> 3322 809 os.a
>> 945 0 util.a
>>
>> objsize
>> text data bss dec hex filename
>> 16644 128 4532 21304 5338 bin/bootloader/apps/boot/boot.elf
>>
>> K.
>>
>>
>> On 23/09/16 17:57, Sterling Hughes wrote:
>>> Hi Kevin,
>>>
>>> I think (and I\u2019ll let Marko chime in here), you can use the boot_serial package to achieve this (apache-mynewt-core/libs/boot_serial.)
>>>
>>> It speaks the newtmgr protocol, but doesn\u2019t require the shell task or an image to be programmed. I think it will slightly explode the size of your boot loader, but that shouldn\u2019t be a huge issue on the NRF52.
>>>
>>> apps/boot/ has the following options.
>>>
>>> #
>>> # Define BOOT_SERIAL in target features to include serial downloader.
>>> # And uncomment 'libs/console/stub' from pkg.deps.
>>> #
>>> pkg.deps.BOOT_SERIAL.OVERWRITE:
>>> - libs/console/full
>>> - libs/boot_serial
>>> pkg.cflags.BOOT_SERIAL:
>>> - -DBOOT_SERIAL
>>>
>>> It\u2019s (unfortunately) been awhile since I\u2019ve tested this, but we\u2019ll take a look today and make sure it\u2019s still functioning (it should be.)
>>>
>>> Sterling
>>>
>>> On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
>>>
>>>> Hi Will (and company),
>>>>
>>>> Sorry to recycle an old thread, but I was just doing some testing with the bootloader on the latest release, and wanted to come back to the issue of having a purely serial option for flashing images in the bootloader. From my perspective there are a number of valid use cases around uploading an image on an empty device (other than the bootloader) over UART or USB CDC, but others may disagree.
>>>>
>>>> This would provide an inexpensive mechanism to debrick boards, for example, as well as a useful tool for production environments where you don�t have the financial or practical means to send a half dozen commercially licensed JLink to your assembly house or somewhere in China for testing then flashing.
>>>>
>>>> Being able to run something like this with ONLY the bootloader present would be a big plus I think:
>>>>
>>>> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
>>>>
>>>> As things stand today, you can only do this (I think, please correct me if I�m wrong) if you already have a valid image flashed and shell support enabled for newtmgr.
>>>>
>>>> Is there an obstacle anyone can see about why this wouldn't be practical to implement with only the bootloader present? We've been focused on application level code and the peripheral side of nimble so I haven't looked at the bootloader code at all, but will have a look to try to get a better sense of the requirements here to use it with serial without any sort of shell support on the application side.
>>>>
>>>> K.
>>>>
>>>> On 08/06/16 23:59, will sanfilippo wrote:
>>>>> +1
>>>>>
>>>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is definitely a handy option for a certain group of folks. BTW, and this is a minor detail, I am not so much for polling a pin; the bootloader can look at the serial port for a certain sequence of characters. If it sees them it enters download mode. If it doesnt see anything it likes after that (or doesnt see that sequence), it tries to boot an image. If it cant, it just cycles back. If it boots a valid image, all good. If it boots a bricked image, you just gotta power cycle it. Shouldnt increase boot time too much (which is something to keep in mind imo).
>>>>>
>>>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>>>
>>>>>> I\u2019m convinced that we should have an option for using standalone boot loader
>>>>>> with which you can upload images. These are valid use cases.
>>>>>>
>>>>>> We should make that happen.
>>>>>>
Re: newtmgr over Serial
Posted by marko kiiskila <ma...@runtime.io>.
That all looks good.
boot_serial package is supposed to be small.
—8<—cut-start—
[marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newt target show boot_mkr1000
targets/boot_mkr1000
app=@apache-mynewt-core/apps/boot
bsp=@mynewt-arduino-zero/hw/bsp/arduino_mkr1000
build_profile=optimized
features=BOOT_SERIAL
—8<—cut end —
Indeed, you need to add 3 defines to your BSP. For testing, I only added
those to Arduino MKR1000 BSP. As you’ve probably figured out, these are for
the pin to use, and whether you want that pin pulled up/down, and whether
to compare pin value against 0 or 1.
—8< — cut start —
[marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ grep BOOT_SERIAL repos/mynewt-arduino-zero/hw/bsp/arduino_mkr1000/include/bsp/bsp.h
#ifdef BOOT_SERIAL
#define BOOT_SERIAL_DETECT_PIN 43
#define BOOT_SERIAL_DETECT_PIN_CFG GPIO_PULL_UP
#define BOOT_SERIAL_DETECT_PIN_VAL 0
—8< — cut end —
I thought I sent an email about this, but maybe it was missing these details. Sorry
about that.
Now that we can take interrupts even without OS, the size of the bootloader with
serial support could be made smaller. At the moment it still starts the OS, while the
boot_serial stuff could just spin in a loop waiting for input.
That would be attractive here, because then you could have the bootloader smaller
than 16k (looks like it’s really close for your BSP).
> On Sep 23, 2016, at 11:22 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>
> Hi Sterling,
>
> I saw the note on the dependency, but is the target the right place to be adding the dep entry as follows:
>
> $ newt target set bootloader
> deps="@apache-mynewt-core/libs/console/stub"
>
> Adding the two missing defines at the BSP level for BOOT_SERIAL gets this building at least
>
> - BOOT_SERIAL_DETECT_PIN
> - BOOT_SERIAL_DETECT_PIN_CFG
>
> The size still seems reasonable to me (<32KB), though I haven't tested this yet to see if it's being built correctly and the warning is setting an alarm bell off for me, but I'll test shortly:
>
> $ newt size bootloader
> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
> Warning: API conflict: console (libs/console/stub <-> libs/console/full)
> FLASH RAM
> 23 222 *fill*
> 2136 32 baselibc.a
> 330 2128 boot.a
> 1141 12 boot_serial.a
> 1717 1132 bootutil.a
> 64 0 cmsis-core.a
> 20 1 config.a
> 124 0 crt0.o
> 8 0 crti.o
> 16 0 crtn.o
> 640 512 feather52.a
> 983 196 full.a
> 634 8 hal.a
> 80 0 libg.a
> 1436 0 libgcc.a
> 1200 0 mbedtls.a
> 1837 40 nrf52xxx.a
> 3322 809 os.a
> 945 0 util.a
>
> objsize
> text data bss dec hex filename
> 16644 128 4532 21304 5338 bin/bootloader/apps/boot/boot.elf
>
> K.
>
>
> On 23/09/16 17:57, Sterling Hughes wrote:
>> Hi Kevin,
>>
>> I think (and I’ll let Marko chime in here), you can use the boot_serial package to achieve this (apache-mynewt-core/libs/boot_serial.)
>>
>> It speaks the newtmgr protocol, but doesn’t require the shell task or an image to be programmed. I think it will slightly explode the size of your boot loader, but that shouldn’t be a huge issue on the NRF52.
>>
>> apps/boot/ has the following options.
>>
>> #
>> # Define BOOT_SERIAL in target features to include serial downloader.
>> # And uncomment 'libs/console/stub' from pkg.deps.
>> #
>> pkg.deps.BOOT_SERIAL.OVERWRITE:
>> - libs/console/full
>> - libs/boot_serial
>> pkg.cflags.BOOT_SERIAL:
>> - -DBOOT_SERIAL
>>
>> It’s (unfortunately) been awhile since I’ve tested this, but we’ll take a look today and make sure it’s still functioning (it should be.)
>>
>> Sterling
>>
>> On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
>>
>>> Hi Will (and company),
>>>
>>> Sorry to recycle an old thread, but I was just doing some testing with the bootloader on the latest release, and wanted to come back to the issue of having a purely serial option for flashing images in the bootloader. From my perspective there are a number of valid use cases around uploading an image on an empty device (other than the bootloader) over UART or USB CDC, but others may disagree.
>>>
>>> This would provide an inexpensive mechanism to debrick boards, for example, as well as a useful tool for production environments where you don´t have the financial or practical means to send a half dozen commercially licensed JLink to your assembly house or somewhere in China for testing then flashing.
>>>
>>> Being able to run something like this with ONLY the bootloader present would be a big plus I think:
>>>
>>> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin
>>>
>>> As things stand today, you can only do this (I think, please correct me if I´m wrong) if you already have a valid image flashed and shell support enabled for newtmgr.
>>>
>>> Is there an obstacle anyone can see about why this wouldn't be practical to implement with only the bootloader present? We've been focused on application level code and the peripheral side of nimble so I haven't looked at the bootloader code at all, but will have a look to try to get a better sense of the requirements here to use it with serial without any sort of shell support on the application side.
>>>
>>> K.
>>>
>>> On 08/06/16 23:59, will sanfilippo wrote:
>>>> +1
>>>>
>>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is definitely a handy option for a certain group of folks. BTW, and this is a minor detail, I am not so much for polling a pin; the bootloader can look at the serial port for a certain sequence of characters. If it sees them it enters download mode. If it doesnt see anything it likes after that (or doesnt see that sequence), it tries to boot an image. If it cant, it just cycles back. If it boots a valid image, all good. If it boots a bricked image, you just gotta power cycle it. Shouldnt increase boot time too much (which is something to keep in mind imo).
>>>>
>>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>>
>>>>> I’m convinced that we should have an option for using standalone boot loader
>>>>> with which you can upload images. These are valid use cases.
>>>>>
>>>>> We should make that happen.
>>>>>
>>>
>>
>
Re: newtmgr over Serial
Posted by Kevin Townsend <ke...@adafruit.com>.
Hi Sterling,
I saw the note on the dependency, but is the target the right place to
be adding the dep entry as follows:
$ newt target set bootloader
deps="@apache-mynewt-core/libs/console/stub"
Adding the two missing defines at the BSP level for BOOT_SERIAL gets
this building at least
- BOOT_SERIAL_DETECT_PIN
- BOOT_SERIAL_DETECT_PIN_CFG
The size still seems reasonable to me (<32KB), though I haven't tested
this yet to see if it's being built correctly and the warning is setting
an alarm bell off for me, but I'll test shortly:
$ newt size bootloader
Warning: API conflict: console (libs/console/stub <-> libs/console/full)
Warning: API conflict: console (libs/console/stub <-> libs/console/full)
FLASH RAM
23 222 *fill*
2136 32 baselibc.a
330 2128 boot.a
1141 12 boot_serial.a
1717 1132 bootutil.a
64 0 cmsis-core.a
20 1 config.a
124 0 crt0.o
8 0 crti.o
16 0 crtn.o
640 512 feather52.a
983 196 full.a
634 8 hal.a
80 0 libg.a
1436 0 libgcc.a
1200 0 mbedtls.a
1837 40 nrf52xxx.a
3322 809 os.a
945 0 util.a
objsize
text data bss dec hex filename
16644 128 4532 21304 5338
bin/bootloader/apps/boot/boot.elf
K.
On 23/09/16 17:57, Sterling Hughes wrote:
> Hi Kevin,
>
> I think (and I\u2019ll let Marko chime in here), you can use the
> boot_serial package to achieve this
> (apache-mynewt-core/libs/boot_serial.)
>
> It speaks the newtmgr protocol, but doesn\u2019t require the shell task or
> an image to be programmed. I think it will slightly explode the size
> of your boot loader, but that shouldn\u2019t be a huge issue on the NRF52.
>
> apps/boot/ has the following options.
>
> #
> # Define BOOT_SERIAL in target features to include serial downloader.
> # And uncomment 'libs/console/stub' from pkg.deps.
> #
> pkg.deps.BOOT_SERIAL.OVERWRITE:
> - libs/console/full
> - libs/boot_serial
> pkg.cflags.BOOT_SERIAL:
> - -DBOOT_SERIAL
>
> It\u2019s (unfortunately) been awhile since I\u2019ve tested this, but we\u2019ll
> take a look today and make sure it\u2019s still functioning (it should be.)
>
> Sterling
>
> On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
>
>> Hi Will (and company),
>>
>> Sorry to recycle an old thread, but I was just doing some testing
>> with the bootloader on the latest release, and wanted to come back to
>> the issue of having a purely serial option for flashing images in the
>> bootloader. From my perspective there are a number of valid use cases
>> around uploading an image on an empty device (other than the
>> bootloader) over UART or USB CDC, but others may disagree.
>>
>> This would provide an inexpensive mechanism to debrick boards, for
>> example, as well as a useful tool for production environments where
>> you don�t have the financial or practical means to send a half dozen
>> commercially licensed JLink to your assembly house or somewhere in
>> China for testing then flashing.
>>
>> Being able to run something like this with ONLY the bootloader
>> present would be a big plus I think:
>>
>> $ newtmgr -c serial image upload
>> bin/bleuart/apps/bleuart/bleuart.elf.bin
>>
>> As things stand today, you can only do this (I think, please correct
>> me if I�m wrong) if you already have a valid image flashed and shell
>> support enabled for newtmgr.
>>
>> Is there an obstacle anyone can see about why this wouldn't be
>> practical to implement with only the bootloader present? We've been
>> focused on application level code and the peripheral side of nimble
>> so I haven't looked at the bootloader code at all, but will have a
>> look to try to get a better sense of the requirements here to use it
>> with serial without any sort of shell support on the application side.
>>
>> K.
>>
>> On 08/06/16 23:59, will sanfilippo wrote:
>>> +1
>>>
>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is
>>> definitely a handy option for a certain group of folks. BTW, and
>>> this is a minor detail, I am not so much for polling a pin; the
>>> bootloader can look at the serial port for a certain sequence of
>>> characters. If it sees them it enters download mode. If it doesnt
>>> see anything it likes after that (or doesnt see that sequence), it
>>> tries to boot an image. If it cant, it just cycles back. If it boots
>>> a valid image, all good. If it boots a bricked image, you just gotta
>>> power cycle it. Shouldnt increase boot time too much (which is
>>> something to keep in mind imo).
>>>
>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>
>>>> I\u2019m convinced that we should have an option for using standalone
>>>> boot loader
>>>> with which you can upload images. These are valid use cases.
>>>>
>>>> We should make that happen.
>>>>
>>
>
Re: newtmgr over Serial
Posted by Sterling Hughes <st...@apache.org>.
Hi Kevin,
I think (and I\u2019ll let Marko chime in here), you can use the
boot_serial package to achieve this
(apache-mynewt-core/libs/boot_serial.)
It speaks the newtmgr protocol, but doesn\u2019t require the shell task or
an image to be programmed. I think it will slightly explode the size of
your boot loader, but that shouldn\u2019t be a huge issue on the NRF52.
apps/boot/ has the following options.
#
# Define BOOT_SERIAL in target features to include serial downloader.
# And uncomment 'libs/console/stub' from pkg.deps.
#
pkg.deps.BOOT_SERIAL.OVERWRITE:
- libs/console/full
- libs/boot_serial
pkg.cflags.BOOT_SERIAL:
- -DBOOT_SERIAL
It\u2019s (unfortunately) been awhile since I\u2019ve tested this, but we\u2019ll
take a look today and make sure it\u2019s still functioning (it should be.)
Sterling
On 23 Sep 2016, at 2:46, Kevin Townsend wrote:
> Hi Will (and company),
>
> Sorry to recycle an old thread, but I was just doing some testing with
> the bootloader on the latest release, and wanted to come back to the
> issue of having a purely serial option for flashing images in the
> bootloader. From my perspective there are a number of valid use cases
> around uploading an image on an empty device (other than the
> bootloader) over UART or USB CDC, but others may disagree.
>
> This would provide an inexpensive mechanism to debrick boards, for
> example, as well as a useful tool for production environments where
> you don�t have the financial or practical means to send a half dozen
> commercially licensed JLink to your assembly house or somewhere in
> China for testing then flashing.
>
> Being able to run something like this with ONLY the bootloader present
> would be a big plus I think:
>
> $ newtmgr -c serial image upload
> bin/bleuart/apps/bleuart/bleuart.elf.bin
>
> As things stand today, you can only do this (I think, please correct
> me if I�m wrong) if you already have a valid image flashed and shell
> support enabled for newtmgr.
>
> Is there an obstacle anyone can see about why this wouldn't be
> practical to implement with only the bootloader present? We've been
> focused on application level code and the peripheral side of nimble so
> I haven't looked at the bootloader code at all, but will have a look
> to try to get a better sense of the requirements here to use it with
> serial without any sort of shell support on the application side.
>
> K.
>
> On 08/06/16 23:59, will sanfilippo wrote:
>> +1
>>
>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is
>> definitely a handy option for a certain group of folks. BTW, and this
>> is a minor detail, I am not so much for polling a pin; the bootloader
>> can look at the serial port for a certain sequence of characters. If
>> it sees them it enters download mode. If it doesnt see anything it
>> likes after that (or doesnt see that sequence), it tries to boot an
>> image. If it cant, it just cycles back. If it boots a valid image,
>> all good. If it boots a bricked image, you just gotta power cycle it.
>> Shouldnt increase boot time too much (which is something to keep in
>> mind imo).
>>
>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <ma...@runtime.io>
>>> wrote:
>>>
>>> I\u2019m convinced that we should have an option for using standalone
>>> boot loader
>>> with which you can upload images. These are valid use cases.
>>>
>>> We should make that happen.
>>>
>