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.
—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.
