Add BL parameter definitions as new document #408
Conversation
docs/tools/bootloader.md
Outdated
| * `target.restrict_size` | ||
|
|
||
| All of these parameters are valid in `targets.json`, `mbed_lib.json` and `mbed_app.json` and may be defined for individual targets and the wildcard target, `*`. A parameter in `mbed_lib.json` overrides a parameter in `targets.json`, and a parameter in `mbed_app.json` overrides one in `mbed_app.json`. | ||
|
|
There was a problem hiding this comment.
Is this intended? I assume one should be mbed_lib.json.
There was a problem hiding this comment.
Ha! Good catch. Yes, the second mbed_app.json should be mbed_lib.json in the last sentence.
There was a problem hiding this comment.
Fixed with a rebase.
theotherjimmy
force-pushed
the
split-bl
branch
from
77b133d to
f9873d0
Compare
docs/tools/bootloader.md
Outdated
|
|
||
| ### `target.restrict_size` | ||
|
|
||
| This parameter restricts the size of the application to be at most the specified size. When `target.bootloader_img` is present, the start of the current application's code segment is computed as above; Otherwise, the start address is the beginning of ROM. The size of the application computed by rounding the end address down to the nearest flash erase block boundary and subtracting the start address. The post-build merge process will pad the resulting boot loader binary to it's end address. |
There was a problem hiding this comment.
I'm not completely sure what is the difference between restrict_size and mbed_app_size? It seems like you can use them for the same thing: define the size of your application?
I also don't understand the rounding down part: "The size of the application computed by rounding the end address down to the nearest flash erase block boundary and subtracting the start address"
There was a problem hiding this comment.
I'll have to think about how to phrase that better. The difference is that restrict_size will generate the POST_APPLICATION_* stuff and pad your executable to the size mentioned and do the rounding down thingy.
docs/tools/bootloader.md
Outdated
|
|
||
| While the exporters can export a project using the configuration parameters above, there are some limitations. | ||
|
|
||
| The exporters do not interpret Mbed OS Configuration, and any changes to configuration parameters, especially boot loader parameter, require you to re-run the `mbed export` command. |
There was a problem hiding this comment.
This problem is common to all configuration changes, right? It sounds like the bootloader is a special case.
There was a problem hiding this comment.
That's true. You could, in theory, modify mbed_config.h for other configuration parameters. BL configs don't even allow that.
Copy edit for active voice, consistent spelling across docs and other minor grammar issues.
Copy edit new text, and combine two sections to avoid duplication.
Copy edit for active voice and spelling, and remove duplicate section because we link to its duplicate.
|
Much better! It was easy to understand and didn't leave any lingering questions behind! |
docs/tutorials/bootloader.md
Outdated
| Further, the exporters do not implement the postbuild merge that bootloader builds use. | ||
|
|
||
| For a managed bootloader: | ||
| After exporting a project with the `target.mbed_app_start` setting, you are responsible for ensuring that a boot loader is present, if needed. Without flashing this boot loader image, the device will not boot correctly. |
There was a problem hiding this comment.
This is an unmanaged BL parameter, and the unmanaged BL description. This should be swapped with the subsequent paragraph, without changing the title.
|
Much better. |
|
Good to go! |
@AnotherButler, where should we link this from?