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 <[email protected]> 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 <[email protected]> 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.
>>>>>
>>>
>>
>
