Add support for STMicroElectronics Nucleo-F439ZI

[man-gc]

This board is the same as the Nucleo-F429ZI but with a STM32F439ZI SOC. The only difference between this SoC and the STM32F429ZI is the presence of a hardware cryptographic accelerator.

[JarmouniA]

Some initial remarks.

[man-gc]

@JarmouniA I've read your initial remarks but, before I proceed to update these commits, I want to say that all files have been directly copied from the in-tree Nucleo-F429ZI.
Therefore, all remarks that apply here should also be applied to this board, shouldn't they ? Or maybe I should update the documentation to link to the other board, and simply mention that this board only provide a hardware cryptographic accelerator ?

[nordicjm]

convert all to webp, then put through https://tinypng.com/

[nordicjm]

Suggested change

	The Zephyr nucleo_f439zi board configuration supports the following hardware features:
	The Zephyr ``nucleo_f439zi`` board supports the following hardware features:

[JarmouniA]

I want to say that all files have been directly copied from the in-tree Nucleo-F429ZI. Therefore, all remarks that apply here should also be applied to this board, shouldn't they ?

@man-gc I think the images with the pin info shouldn't be in the other board either, the pins are assigned in the board's devicetree.

Or maybe I should update the documentation to link to the other board, and simply mention that this board only provide a hardware cryptographic accelerator ?

Yes, I think that would be best, instead of duplicating everything without obvious added value.

[man-gc]

@JarmouniA Due to the flash layout of the STM32F439ZI, would you be OK with the following partitioning for MCUBoot default Zephyr config ?

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		/* 32KB for bootloader */
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 DT_SIZE_K(32)>;
			read-only;
		};

		/*
		 * nvs subsystem requires 2 sectors with a max total of 32K
		 * On F4 series, the only option is to use the following
		 * partition, which is compatible with mcuboot usage.
		 * Keep it commented in order it is not used by CI.
		 *
		 * storage_partition: partition@8000 {
		 *	label = "storage";
		 *	reg = <0x0008000 DT_SIZE_K(32)>;
		 * };
		 */

		/* free sector: 64KB
		 *
		 * free0_partition: partition@10000 {
		 *	label = "free-0";
		 *	reg = <0x00010000 DT_SIZE_K(64)>;
		 * };
		 */

		/* application image slot: 384KB */
		slot0_partition: partition@20000 {
			label = "image-0";
			reg = <0x00020000 DT_SIZE_K(384)>;
		};

		/* free sectors: 4 * 16KB + 64KB
		 *
		 * free1_partition: partition@10000 {
		 *	label = "free-1";
		 *	reg = <0x00010000 DT_SIZE_K(128)>;
		 * };
		 */

		/* backup slot: 256KB */
		slot1_partition: partition@a0000 {
			label = "image-1";
			reg = <0x000a0000 DT_SIZE_K(256)>;
		};

		/* free sector: 128KB
		 *
		 * free2_partition: partition@e0000 {
		 *	label = "free-2";
		 *	reg = <0x000e0000 DT_SIZE_K(128)>;
		 * };
		 */
	};
};

It seems also it would be better to use MCUBOOT_BOOTLOADER_MODE_SWAP_USING_OFFSET with this board in order to have two image slots of 384KB. Maybe I should modify some Kconfig to set it and use the following partitioning to better use the available flash space

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		/* 64KB for bootloader */
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 DT_SIZE_K(64)>;
			read-only;
		};

		/* free sector: 64KB
		 *
		 * free0_partition: partition@10000 {
		 *	label = "free-0";
		 *	reg = <0x00010000 DT_SIZE_K(64)>;
		 * };
		 */

		/* application image slot: 384KB */
		slot0_partition: partition@20000 {
			label = "image-0";
			reg = <0x00020000 DT_SIZE_K(384)>;
		};

		/*
		 * Keep it commented in order it is not used by CI.
		 *
		 * storage_partition: partition@80000 {
		 *	label = "storage";
		 *	reg = <0x0080000 DT_SIZE_K(64)>;
		 * };
		 */

		/* free sector: 64KB
		 *
		 * free1_partition: partition@90000 {
		 *	label = "free-1";
		 *	reg = <0x00090000 DT_SIZE_K(64)>;
		 * };
		 */

		/* backup slot: 384KB */
		slot1_partition: partition@a0000 {
			label = "image-1";
			reg = <0x000a0000 DT_SIZE_K(384)>;
		};
	};
};

What do you think before I push another version for this PR ?

[man-gc]

@JarmouniA Due to the flash layout of the STM32F439ZI, would you be OK with the following partitioning for MCUBoot default Zephyr config ?

[...]

It seems also it would be better to use MCUBOOT_BOOTLOADER_MODE_SWAP_USING_OFFSET with this board in order to have two image slots of 384KB. Maybe I should modify some Kconfig to set it and use the following partitioning to better use the available flash space

[...]

What do you think before I push another version for this PR ?

Sorry, this is using the 1MB version and not the 2MB one, so the offsets must be recalculated accordingly

[man-gc]

Hi all,

I've seen that this PR now has 2 approvals but before merging, should I fix tests and force push ? Also, which partitioning should I use ? Or, should these modifications be done in another PR ?

I've also seen the recent PR #86485, should documentation of this board be modified accordingly ?

[erwango]

I've seen that this PR now has 2 approvals but before merging, should I fix tests and force push ?

Indeed, PR can't be merged w/o a clean CI sheet.

I've also seen the recent PR #86485, should documentation of this board be modified accordingly ?

Exactly, thanks.

[erwango]

Some comments on the doc, but otherwise this is a clean work, thanks!

[erwango]

Nitpick: Please remove. Each board should provide an independent documentation, adn in current case, it will be provided by the generated table.

[erwango]

Please add build instructions.