> On Sep 23, 2016, at 12:15 PM, Kevin Townsend <[email protected]> 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 <[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. >>>>>>> >
