MCUBootloader won't build for custom board - zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH'

[Lucas Gabriel Coliado Bandeira]

Hello,

I'm using the nRF Connect SDK 1.9.1 and I have defined a custom board with nRF52840. This works for normal code (samples, etc).

The .dst has the following structure for the memory, based off the nrf52840dk_nrf52840 board (here some of the configuration has been omitted such as spi, etc):

&flash0 {

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,bt-c2h-uart = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
	};
	
	...
	
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00067000>;
		};
		slot1_partition: partition@73000 {
			label = "image-1";
			reg = <0x00073000 0x00067000>;
		};
		scratch_partition: partition@da000 {
			label = "image-scratch";
			reg = <0x000da000 0x0001e000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
};

If and only if I set CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf, I get the following error when building my solution:

Combining 'mcuboot/zephyr/zephyr.hex'
...
zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH'
region `FLASH' overflowed by 27608 bytes

Once I get this error, I get a plethora of include errors, such as "undefined reference to `z_impl_k_queue_get".

This happens regardless of the project (hello world sample does this) and it always overflows by the same amount (27608 bytes).

---

I've tried reading the documentation for the bootloader, but I'm also unable to build it for my custom board there. 

This makes me think the problem is with my board definition. So my questions are the following:

1. What steps do I need to take to configure the MCUBoot for a custom board?
2. Is defining the memory map in the .dst of the board not enough?
3. Must I write an overlay for the Bootloader? If yes, how should it look like?

Thanks

[Einar Thorsrud]

Hi,

How ar you building your board?

What steps do I need to take to configure the MCUBoot for a custom board?

You need to add CONFIG_BOOTLOADER_MCUBOOT=y like you have, and also need to add a child_image/mcuboot.conf. When this is done, the partition manager will partition the memory for you (and can be configured using pm.yml). (After building you can get a memory map printed by going to the build folder and typing "ninja partition_manager_report").

Is defining the memory map in the .dst of the board not enough?

The partitioning from the device tree is ignored when using the partition manager.

Must I write an overlay for the Bootloader? If yes, how should it look like?

Not normally when only using the internal flash, btu there are many example overlay files for the bootloader for different configurations (see bootloader/mcuboot/boot/zephyr/boards)

[Lucas Gabriel Coliado Bandeira]

Hello, Einar

I'm not sure what you mean by building the board so correct me if I'm wrong; I have a Zephyr project with the board definition as a subdirectory.

I use the nRF Connect VSCode extension to create a build configuration for the project by pointing it to my custom board definition. This is located in a subdirectory within the project. Sometimes I also use SEGGER Embedded to create the build configuration. This works normally for sample code, which I then Build and Flash using the IDE commands. 

If I set CONFIG_BOOTLOADER_MCUBOOT=y in the project's prj.conf, I receive the error message in the original post.

> You need to add CONFIG_BOOTLOADER_MCUBOOT=y like you have, and also need to add a child_image/mcuboot.conf. When this is done, the partition manager will partition the memory for you (and can be configured using pm.yml)

I think I'm missing some understanding of what scripts are involved during the build process, so please forgive me.

Is the partition manager script always ran on build to check for configurations? If not, how do I enable the partition manager? Is "child_image" the actual name that the builder identifies, or the name of the project?

After the partition manager is set, how should one configure mcuboot.conf? Where is this documented, are there examples in the DK boards?

Thank you for your patience

[Einar Thorsrud]

The build system will automatically run the partition manager when you build with a nRF Connect SDK project, and there is no need to do any extra steps in order to run it.

Can you upload your project complete with the custom board definition etc. and instructions on how you build it? Then I can both see if I spot anything and try to reproduce this on my end.

[Lucas Gabriel Coliado Bandeira]

I've attached a similar project file that reproduces the same error.

The easiest way to build this:

1. Extract the project folder
2. Open SEGGER Embedded Studio for Arm (configured for nRF Connect SDK)
3. Go to File -> Open nRF Connect SDK Project
4. In the Projects dropdown, click on the "..." on the far right to pick the mcubootProject project folder
5. In the Board Name dropdown, click on the "..." on the far right and pick the foobar board in the project folder (boards/arm/foobar)
6. Click OK
7. Go to Build -> Build Solution

This should result in the error during the size check.

The error will go away if you go to prj.conf and set CONFIG_BOOTLOADER_MCUBOOT=n and redo the steps, but then there won't be a bootloader. It will also go away if you remove pretty much every option regarding the networking drivers from the defconfig, but then the board is useless.

mcubootProject.zip

[Einar Thorsrud]

Hi,

Thanks for the project. I see the same on my end. To elaborate, I first get a lot of build errors building mcuboot which is caused by SPI being enabled in the default board configuration (boards/arm/foobar/foobar_defconfig), and this depends on multithreading which is not enabled in mcuboot by default. This can be solved by also adding CONFIG_MULTITHREADING=y (but there are better ways which I will come back to). Then I end up with the section `text' will not fit in region `FLASH' error. The quick and dirty way to fix this is to increase the mcuboot partition, which you can do by making a folder in your project called "child_image" (See Multi-image builds) and place mcuboot.conf there, where you put this line:

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x40000

This will make the mcuboot partition fit everything and the project builds.

This is probably not what you want to do, though. The man issue here is that you enable SPI etc in your board configuration file, and that is inherited by both the application and mcuboot (and any other project built for that board). So you either need to explicitly disable this in mcuboot.conf (the file described earlier in this post), or even better: make your board files minimal, and add configurations you only need in your application in your application overlay and configuration files. So, basically remove everything you added under "additional board options" in boards/arm/foobar/foobar_defconfig (perhaps except for CONFIG_GPIO_AS_PINRESET=y), and  add that to your application prj.conf instead. With that, the project builds as expected, and you do not get a bloated mcuboot.