-
Notifications
You must be signed in to change notification settings - Fork 175
Conversation
Moves the segments together so they are contiguous, with XIP SRAM at end This allows packaging no_flash binaries which use XIP_SRAM, and also makes ones using scratch_x/y take up less space in flash
Propogates the need for xip_sram pinning load map through
lurch
commented
Jun 17, 2026
Squashed Elf 😂
image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is just move_seg rather than squash_seg ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s move_seg_to_end_of_last_seg, which is what I’m calling "squashing" in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, fair enough 😀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this "magic number" 2 relate to? (Similarly, what does the 0 in get_model(0) on line 5885 relate to?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s the file_idx, so file number 2, matching the filenames[2] above - the other one is file number 0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh! I was worried that e.g. get_model(0) was hardcoded to return (the model for) RP2040 and get_model(2) was hardcoded to return RP2350B 😉
Probably outside the scope of this PR, but maybe get_model_for_file_index(2) would be less confusing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a stupid question, but why is it only the seal command that has a --no-squash option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You only need to squash it once, before sealing it with a load map, hence doing the squashing in seal - none of the other commands squash the ELF, so don’t need the no-squash argument
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so only a "sealed ELF" needs to be squashed? There wouldn't be any benefit to "squashing" a non-sealed ELF to e.g. make a smaller UF2 file? (apologies for my probably-horrendous use of terminology)
Co-authored-by: will-v-pi <108662275+will-v-pi@users.noreply.github.com>
Adds squashing of segments in the ELF file together, for them to be copied to the correct place at runtime
This is necessary for signing/hashing of sparse no_flash binaries (eg using XIP_SRAM or SCRATCH_X/Y)
This behaviour is enabled by default, but a
--no-squashargument is added which disables this squashing if necessary (eg if the pico-sdk binary is compiled withPICO_CRT0_DEBUG_ENTRY_RESETS_VIA_BOOTROM=0andPICO_CRT0_NO_DATA_COPY=1, as then the copy at runtime will not occur)