PineTime bootloader improvements - Revision history

Caligari: Link to the proposal of external flash partitioning

2020-11-30T04:17:30Z

Link to the proposal of external flash partitioning

← Older revision		Revision as of 04:17, 30 November 2020
Line 139:		Line 139:
	A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.		A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.

	But it has the downside to add complexity and code that could fail.		But it has the downside to add complexity and code that could fail.

			See [[PineTime external flash partitioning]] proposal.

	[[Category:PineTime]]		[[Category:PineTime]]

JF: Add bootloader workflow diagram

2020-11-29T19:46:25Z

Add bootloader workflow diagram

← Older revision		Revision as of 19:46, 29 November 2020
Line 70:		Line 70:
	* Display status and progression (progress bar similar to wasp-reloader, color code,...)		* Display status and progression (progress bar similar to wasp-reloader, color code,...)
	* Test as much as possible		* Test as much as possible

			=== Bootloader workflow ===
			[[File:PineTimeBootloaderWorkflow.png]]

	=== Upgrade & Reloader ===		=== Upgrade & Reloader ===

JF: Add section "Why not add OTA functionality to the bootloader ?"

2020-11-29T16:46:53Z

Add section "Why not add OTA functionality to the bootloader ?"

← Older revision		Revision as of 16:46, 29 November 2020
Line 123:		Line 123:

	If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).		If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).

			=== Why not add OTA functionality to the bootloader ? ===
			This is exactly how the NRF bootloader/SoftDevice works: the bootloader is a standalone firmware that provides OTA functionality thanks to the SoftDevice. The downside is that the BLE stack needed to provide OTA is quite big and uses a lot of space in flash memory (~124kB according to the documentation). This is roughly 1/4 of the available space in the internal flash memory.

			Firmware based on the NRF SoftDevice share the BLE stack with the bootloader, it is mutualised between both entities.
			The downside of this design is that firmwares developers are somewhat forced to use the NRF BLE stack. If they want to integrate another BLE stacak (NimBLE for example), these 120kB used by the SoftDevice would be wasted.

			That's why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It's very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want.


	=== Fixed vs dynamic memory map ===		=== Fixed vs dynamic memory map ===

Caligari: /* Current memory map */

2020-11-28T13:43:38Z

Current memory map

← Older revision		Revision as of 13:43, 28 November 2020
Line 23:		Line 23:

	Internal flash (512Kb):		Internal flash (512Kb):
	* Page size is 4Kb		* Page size is 4Kb.
	* Bootloader contains the MCUBoot bootloader.		* Bootloader contains the MCUBoot bootloader.
	* Boot log is currently not used. Can be use to provide reboot logs to the application		* Boot log is currently not used. Can be use to provide reboot logs to the application
Line 30:		Line 30:

	External flash (4096Kb):		External flash (4096Kb):
			* Page size is 256 bytes.
	* Bootloader assets : boot logo		* Bootloader assets : boot logo
	* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.		* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.

Caligari: /* Current memory map */

2020-11-28T12:47:25Z

Current memory map

← Older revision		Revision as of 12:47, 28 November 2020
Line 17:		Line 17:

	== Current memory map ==		== Current memory map ==

			[[PineTime\| Pinetime Devkit0]] is using a nRF52832-QFAA MCU with 512kB flash and a [https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf XT25F32B SPI NOR external flash] with 4096kB.

	[[File:MemoryMap.png]]		[[File:MemoryMap.png]]

	Internal flash:		Internal flash (512Kb):
			* Page size is 4Kb
	* Bootloader contains the MCUBoot bootloader.		* Bootloader contains the MCUBoot bootloader.
	* Boot log is currently not used. Can be use to provide reboot logs to the application		* Boot log is currently not used. Can be use to provide reboot logs to the application
Line 25:		Line 29:
	* Scratch is used by MCUBoot as temporary storage for swap operation		* Scratch is used by MCUBoot as temporary storage for swap operation

	External flash:		External flash (4096Kb):
	* Bootloader assets : boot logo		* Bootloader assets : boot logo
	* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.		* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.

JF at 18:07, 18 November 2020

2020-11-18T18:07:15Z

← Older revision		Revision as of 18:07, 18 November 2020
Line 1:		Line 1:
			== Request for comments ==
			In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example).
			I try to explain why I made these choices too.

			Do not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else,...).

	== Introduction ==		== Introduction ==
	This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.		This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.

JF: /* Fixed vs dynamic memory map */

2020-11-18T18:03:47Z

Fixed vs dynamic memory map

← Older revision		Revision as of 18:03, 18 November 2020
Line 114:		Line 114:

	=== Fixed vs dynamic memory map ===		=== Fixed vs dynamic memory map ===
			A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.

			But it has the downside to add complexity and code that could fail.


	[[Category:PineTime]]		[[Category:PineTime]]

JF: /* Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash */

2020-11-18T18:01:25Z

Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash

@@ Line 81: / Line 81: @@
 == Discussions ==
 === Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
 === Fixed vs dynamic memory map ===

JF: Add bootloader/application boundaries

2020-11-18T17:42:14Z

Add bootloader/application boundaries

@@ Line 23: / Line 23: @@
 * OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.
 * FS : space available for the application firmware.
 == Changes ==
@@ Line 65: / Line 78: @@
 ** From InfiniTime to wasp-os : the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running
 ** From wasp-os to InfiniTime : the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running.
 [[Category:PineTime]]

JF: /* Bootloader assets */

2020-11-12T19:53:04Z

Bootloader assets

← Older revision		Revision as of 19:53, 12 November 2020
Line 38:		Line 38:
	In order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:		In order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:
	- Less code.		- Less code.
	~~- Easier to flash/install for the user AND the factory (we literally spend WEEKS to successfully flash infinitime and the bootloader).~~
	- Easier to document : 1 specific logo = bootloader mode		- Easier to document : 1 specific logo = bootloader mode
	- Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded).		- Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded).