Hi Jan,

I checked some more.
BSP you mentioned has SLOT0 located at 0x08020000, you mentioned 0x08010000
as your starting point so you may check this.

I also checked that if you specify in your target syscfg.yml (or in
application or bsp)
INCLUDE_IMAGE_HEADER: 0
it should have same effect as _imghdr_size = 0x0;
basically it means that image header (32 bytes for MCUBOOT) is not to be
reserved. It can be verified in .map file look for something like that:

.image_header
 *(.image_header)

.interrupts     0x08040000      0x1f8
                0x08040000                        . = ALIGN (0x4)
                0x08040000                        __isr_vector = .
                0x08040000                        __isr_vector_start = .

This was taken from STM32F767 which has slot0 located at 0x8040000
Following fragment is from build that has INCLUDE_IMAGE_HEADER: 1

.image_header   0x08040000       0x20
 *(.image_header)
 .image_header  0x08040000       0x20
H:\msys64\home\Jerzy\work\blinky\bin\targets\nucleo-f767zi-iptest\app\@apache-mynewt-core\mgmt\image_header\@apache-mynewt-core_mgmt_image_header.a(image_header.o)
                0x08040000                image_header

.interrupts     0x08040020      0x1f8
                0x08040020                        . = ALIGN (0x4)
                0x08040020                        __isr_vector = .
                0x08040020                        __isr_vector_start = .

So you can see that interrupt vectors are moved 32 bytes allowing for newt
to insert image header.

In any case if your custom bootloader jumps to 0x8010000 it should not work
before as well
_imghdr_size = 0 means that there is not space for image header but
interrupt vectors starting from initial SP are at the very beginning of you
build.
Unless you have something special at 0x8010000 your code should jump to
address store in 0x08010004

If your share some fragment of map file I can help you some more.

br
Jerzy

śr., 22 sty 2025 o 16:36 Jerzy Kasenberg <jerzy.kasenb...@codecoup.pl>
napisał(a):

> Hi Jan,
>
> Easiest way for you to proceed is to get old linker scripts that worked
> for you before
> Then instead of having bsp.yml file with line
>
>  bsp.linkerscript: autogenerated
>
> set bsp.linkerscript to what it was before
>
> I'll check your case to see how to manage it using autogenerated scripts
> and let you know later
>
> br
> Jerzy
>
> śr., 22 sty 2025 o 13:44 Jan Clement <jan.clem...@cm-electronics.de>
> napisał(a):
>
>> Hello Devlist,
>>
>> during my process of upgrading apache mynewt from 1.9.0 to 1.13.0 I now
>> face the problem, that the binaries I generate are not running on my
>> system.
>>
>> As a starting point I used the iptest application and the
>> stm32f7discovery bsp package. This worked with the old mynewt version. I
>> run my own bootloader implementation, after booting, it jumps to
>> 0x08010000 and starts executing from there. For this to work in the old
>> implementation I had to set
>>
>>  > _imghdr_size = 0x0;    /* size = 0 for direct flashing */
>> in the linker script.
>>
>> I can't find any corresponding setting in the new version. The only
>> thing I found is:
>>
>>  > INCLUDE_IMAGE_HEADER
>> which I set to 0.
>>
>> For testing purposes I also tried to flash the image directly and use it
>> without the bootloader, this also didn't work.
>>
>> When I debug my application I get following output:
>>
>>  > xPSR: 00000000 pc: 00000000 msp: 0x96f3b83c
>>
>> It seems that my program counter is not set correctly.
>>
>> Any help is greatly appreciated, thanks!
>>
>> Jan
>>
>

Reply via email to