You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+14-5
Original file line number
Diff line number
Diff line change
@@ -67,10 +67,17 @@ FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 32K /* 32K of flash is reserved f
67
67
/* --- BOOTLOADER CONFIGURATION SPECIFIC INFORMATION END --- */
68
68
```
69
69
70
+
NOTE: While configuring this part of the bootloader linker script you need to carefully consider the flash layout of your MCU.
71
+
A good practice would be to always start the primary and secondary applications from the beginning of the desired flash page. Also you need to be careful to not have any overlaps between the two.
72
+
Also, since the bootloader cannot update itself, once you flash the bootloader, you cannot modify the flash layout after that, on future application releases.
73
+
70
74
- Adapt your application:
71
-
Similarly to the bootloader, the application must also have that information inside its linker script.
75
+
Similarly to the bootloader, the application should also have that information inside its linker script. This is optional though, in case that you need that information inside your application for any reason.
76
+
72
77
It is important to not mess it up and be careful while copy-pasting that information to your linker script, as the tools that are provided under scripts/build_tools parse the application linker to find the relevant information. More information on how to use those tools can be found in the relevant README.md files.
73
78
79
+
- Utilize the script **scripts/build_tools/create_dfu_image.py** to make your app binary compatible to the built bootloader. More info on how to use it can be found in **scripts/build_tools/README.md**. The modified binary will be exported to the current working directory.
80
+
74
81
- You also need to modify the **private_key.pem** and **public_key.pem**, under **projects/**. They are being used to sign the application, and provide the bootloader with the relevant information on authenticating the signature.
75
82
76
83
# Porting bootloader to other boards
@@ -79,7 +86,7 @@ design the project in a way to be as easily portable as possible. Still there ar
79
86
in that area, but you could start by reading the **README.md**, under **projects/bootloader**. There, you can find some useful notes
80
87
that can help you port the project faster to your board.
81
88
82
-
**You can always reach out to me, to guide you through it.**
89
+
**You can always reach out to me, to guide you through it. Feel free to push a commit, adding support for your board.**
83
90
84
91
TODO: In the future, projects/bootloader/boards/<board_name> will contain all the **driver level** code for each specific board, and a simple define will utilize the correct board subfolder to build the bootloader.
85
92
@@ -88,10 +95,12 @@ TODO.
88
95
89
96
# How to use
90
97
1. Modify the bootloader (linker script/drivers) as you like based on the information provided before.
91
-
2. Use the build.sh script to build the bootloader.bin.
98
+
2. Use the build.sh script to build the bootloader.bin. (e.g. build.sh bootloader)
92
99
3. Flash the bootloader.bin on flash address 0x08000000.
93
-
4. You can develop your application following the example of projects/app. In that case, modify the linker script accordingly, update the private-public key pair and use the build.sh script to build the application.
94
-
5. You can always have a binary yourself and utilize the underlying tools (create_dfu_image.py).
100
+
4. You can develop your application following the example of projects/app. In that case, modify the linker script accordingly, update the private-public key pair and use the build.sh script to build the application. (e.g. build.sh all OR build.sh app)
101
+
5. You can always have a binary yourself and utilize the underlying tools (create_dfu_image.py). With this script you can convert your binary to a compatible application to be used by the bootloader.
102
+
103
+
IMPORTANT: More information about each script can be found inside the relevant folder that contains it.
After the execution of this script, a new binary will be created that will be ready to be flashed to the board, and be compatible with out bootloader.
76
76
Also, a yaml file will be produced that will contain information related to the final binary. (e.g. the crc, sha256 hash, version of the binary).
77
77
78
+
The reason that this script needs the linker script of the bootloader is to find the following information:
79
+
- Size of the application (both primary and secondary - which must be the same)
80
+
- Size of the footer, to add the relevant information to the end of the binary. (Also location of the footer in flash)
81
+
e.g. __flash_app_start__, __flash_app_end__, __header_app_crc_start__, __header_app_fw_version_start__, __header_app_hash_start__.
82
+
83
+
Also the private key is used to sign the application.
84
+
85
+
Note: This tool can be used on any application binary.
86
+
E.g. Let's say you have an application (binary) of size 120kB.
87
+
You configure the bootloader of this repository, to support an application binary of up to 230kB.
88
+
You can easily use this script to adapt your binary based on the bootloader standards and make it compatible with it.
89
+
Note: Don't forget to update the private-public key pair under **projects**. This is important to build your bootloader based on that pair and use the private key to sign your application. You need to create key pair based on ECDSA (chatgpt is your friend there :) )
90
+
78
91
# extract public key python script description
79
92
This script is being used pre-process a project firmware headerfile and rewrite it in order to add the public key information, in C-array format. The final result of that header file will be:
0 commit comments