Conversation
|
For people like me who have no idea what "pinning XIP SRAM" is about, maybe it's worth adding a comment pointing to 5.9.3.2.1. in the RP2350 datasheet? 😉 |
|
"If, however, you have a non-flash binary with code or data in the XIP RAM address space, then you need to add a special |
Not necessarilly, because you could choose to pin manually only the region you want before loading your code/data into XIP SRAM, rather than having the bootrom pin the whole thing, in order to minimise the flash performance loss that comes from pinning XIP SRAM. |
Okay. So is the |
That section of the datasheet is currently incorrect (I have a PR open to fix it), but more generally picotool doesn't currently refer to the datasheet and instead assumes prior knowledge of the bootrom functionality (eg signing and hashing, what a load map is, etc), as that stuff is documented elsewhere |
Yes, it's adding a load map entry to ask the bootrom to do that |
|
Hmmm, very weird that the "Test Build Examples" jobs have suddenly decided to start failing 😕 It's complaining about a missing file but I don't think that any of the relevant repos have changed recently? |
|
BTStack has been bumped in the SDK but not yet in pico-examples, which is causing the failure |
Ahhhh! Thanks 😀 |
Also add --pin-xip-sram arg, add --clear arg to encrypt (rather than always clearing), and use model for correct pinning and clearing
Put default back to clearing, with --no-clear to disable clearing
Also fix seal documentation, as it doesn't sign the binary by default
| `seal` allows you to sign and/or hash a binary to run on RP2350. | ||
|
|
||
| By default, it will just sign the binary, but this can be configured with the `--hash` and `--no-sign` arguments. | ||
| By default, it will just add an embedded block to the end containing a relative load map, thus sealing the binary. The `--hash` and `--sign` arguments can be passed to include an hash and a signature; `--major`, `--minor` and `--rollback` can be passed to include a version; and `--clear` or `--pin-xip-sram` can be passed to add load map items. |
There was a problem hiding this comment.
that is confusing --clear or --pin-xip-sram can be passed to add load map items it might be technically correct, but maybe be explicit (e.g. add load map items indicating clear of RAM and pin of XRAM) but not sure if the user cares about the details
There was a problem hiding this comment.
i guess you did something more like the first suggestion further down
|
|
||
|
|
||
| std::vector<uint8_t> get_lm_hash_data(elf_file *elf, block *new_block, bool clear_sram = false) { | ||
| bool check_generic_load_map(std::shared_ptr<load_map_item> load_map, model_t model, bool &pin_xip_sram) { |
There was a problem hiding this comment.
this could be better named i think - also a bit weird to both modify and return a var
3 participants
Adds support for pinning XIP SRAM in a load map, and allows use of XIP SRAM in flash binaries