Hi,

indeed, bootloader does get bigger. I didn’t try this out on Nordic to see
if something gets out of whack. I’ll check it to see if there are pieces
that came in with unintentionally. ‘newt size <target>’  will show what
components get bigger.

To make the bootloader fit, there’s 2 options:
- make bootloader flash area larger, or
- don’t use NFFS, instead switch over to using FCB

To increase area for bootloader, you need to adjust the linker scripts for
bootloader and the image, as well as the BSP’s flash map. And that should
be it. Nordic has 1k sectors, so the adjustments can be pretty fine-grained.
This are in the files Wayne pointed out.

Or don’t use NFFS, instead use FCB for config. This will drop the size
of the bootloader quite a bit, close to 8k. We’ll want to make the bootloader
vs app comm to take place via some other method than NFFS. NFFS
support brings in a lot of text.

I briefly talked about this with Peter Snyder, and thought we should see
if we can steal some bytes from the end of the 2nd image slot for this.

However, in the short term, I suggest increasing the bootloader area.

> On Jun 18, 2016, at 3:29 AM, Kevin Townsend <[email protected]> wrote:
> 
> I was able to build manually pulling via git, and adding the following macros 
> in my custom BSP:
> 
>   /* BOOT_SERIAL pins */
>   /* DFU pin is set to 0.07 on the BLEFRIEND32 */
>   #define BOOT_SERIAL_DETECT_PIN      (7)
>   /* 0 = No pullup, 1 = Pull Up, 2 = Pull Down */
>   #define BOOT_SERIAL_DETECT_PIN_CFG  (0)
>   /* Board has external pullup and the tact switch sets the pin to GND */
>   #define BOOT_SERIAL_DETECT_PIN_VAL  (0)
> 
> This corresponds to the HW bootloader pin on this board: 
> https://cdn-learn.adafruit.com/assets/assets/000/024/297/original/adafruit_products_schem.png?1428267509
> 
> Even with the new nrf51_bootser target set to optimized, though, it's running 
> over the .text region limit for the nRF51:
> 
>   Error:
>   
> /Users/ktown/prog/gcc-arm-none-eabi-4_9-2015q1/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:
>   
> /Users/ktown/Dropbox/microBuilder/code/nRF52/Mynewt/bletest/bin/nrf51_bootser/apps/boot/boot.elf
>   section `.text' will not fit in region `FLASH'
>   
> /Users/ktown/prog/gcc-arm-none-eabi-4_9-2015q1/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:
>   region `FLASH' overflowed by 1288 bytes
>   
> /Users/ktown/Dropbox/microBuilder/code/nRF52/Mynewt/bletest/bin/nrf51_bootser/libs/os/os.a(os_arch_arm.o):
>   In function `os_arch_os_init':
>   
> /Users/ktown/Dropbox/microBuilder/Code/nRF52/Mynewt/bletest/repos/apache-mynewt-core/libs/os/src/arch/cortex_m0/os_arch_arm.c:218:
>   undefined reference to `bsp_init'
> 
> There do tend to be meaningful gains in optimisation between releases, so I 
> switched to 2016q1 (5.3.1) and it's closer, but still not quite small enough:
> 
>   Linking boot.elf
>   Error:
>   
> /Users/ktown/prog/gcc-arm-none-eabi-5_3-2016q1/bin/../lib/gcc/arm-none-eabi/5.3.1/../../../../arm-none-eabi/bin/ld:
>   
> /Users/ktown/Dropbox/microBuilder/code/nRF52/Mynewt/bletest/bin/nrf51_bootser/apps/boot/boot.elf
>   section `.text' will not fit in region `FLASH'
>   
> /Users/ktown/prog/gcc-arm-none-eabi-5_3-2016q1/bin/../lib/gcc/arm-none-eabi/5.3.1/../../../../arm-none-eabi/bin/ld:
>   region `FLASH' overflowed by 700 bytes
>   
> /Users/ktown/Dropbox/microBuilder/code/nRF52/Mynewt/bletest/bin/nrf51_bootser/libs/os/os.a(os_arch_arm.o):
>   In function `os_arch_os_init':
>   
> /Users/ktown/Dropbox/microBuilder/Code/nRF52/Mynewt/bletest/repos/apache-mynewt-core/libs/os/src/arch/cortex_m0/os_arch_arm.c:218:
>   undefined reference to `bsp_init'
>   collect2: error: ld returned 1 exit status
> 
> Looking at what 'optimized' gets converted to, it seems like it's '-Os' which 
> is the best we'll get for size (compiler.yml states: 
> "compiler.flags.optimized: [compiler.flags.default, -Os -ggdb]")
> 
> Which version of GCC were you using yourself?
> 
> Best regards,
> Kevin
> 
> On 18/06/16 01:44, marko kiiskila wrote:
>> Hi,
>> 
>> I checked in a package that can be included in bootloader, and
>> it will accept image upgrades over serial port.
>> 
>> It expects that the image upgrade is done using the newtmgr
>> protocol. Command set that it supports is limited; it can list images,
>> accept an image upload command (stores it to slot 0), and also reset.
>> 
>> For testing, I added a snippet of code to apps/boot which can
>> be conditionally compiled in by defining target features for boot loader
>> to include BOOT_SERIAL.
>> The code monitors a GPIO pin, and if it’s set to specific state during
>> bootup, it’ll enter the serial downloader, awaiting these commands.
>> Again for testing, I added the pin config to use for Arduino MKR1000
>> BSP.
>> 
>> Here’s my target definition for using this, in case you want to try this
>> out:
>> [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
>> 
>> Feedback appreciated,
>> M
>> 
>>> On Jun 17, 2016, at 4:26 PM, [email protected] wrote:
>>> 
>>> boot; conditionally check whether to expect image download commands
>>> over serial. Whether code gets built in depends on target features.
>>> 
>>> 
> 

Reply via email to