-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring linker scripts in sync with pico-sdk original. #16
base: main
Are you sure you want to change the base?
Conversation
…eneration The objcopy step that updates sections with binary data failed because of an error with sections now marked NOLOAD instead of COPY. The error disappeared with moving section .uninitialized_data to near .ram_vector_table, which somehow triggered adding a section that reserved a piece of RAM (which is fine) with reference to a flash area (which is strange). Note that these uninitialized sections are explicitly requested by __uninitialized_ram() directives: pico-sdk/src/rp2_common/pico_platform/include/pico/platform.h: #define __uninitialized_ram(group) __attribute__((section(".uninitialized_data." #group))) group Their use is to keep ram uninitialized on purpose, to collect entropy (for RNG) or data left over from before reset.
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.
I'm uneasy about merging this without understanding what's going on - especially as it immediately diverges the linker script again from the pico-sdk one
@@ -142,10 +142,15 @@ SECTIONS | |||
__binary_info_end = .; | |||
. = ALIGN(4); | |||
|
|||
.ram_vector_table (NOLOAD): { | |||
.ram_vector_table (NOLOAD): { |
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.
nit: you added a space to the start of this line in both linker scripts
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.
That's right, I aligned it with the other entries while I was at it.
You're referring only to ab7cef8 here, I guess. Let me elaborate a bit. The change itself is trivial and doesn't impact our standalone or picowota builds in a negative way. It is a rearrangement of sections placed in RAM with no (known) negative impact. AFAIK the only hard requirement could be that The order of sections was:
Which we had to rearrange to:
Without this rearrangement, we see something strange popping up when using
The unexpected value here is LMA of Re-arranging gives:
Where we see the expected LMA The actual issue may be that
And comparing
Memsz seems to indicate some internal For this I used |
@usedbytes I think this is actually a bug in the original linker script. The |
FYI: the equivalent fix was recently merged in |
The linker script apparently evolved in pico-sdk. This patch updates the linker script in picowota to match the original script (
memmap_default.ld
) as closely as possible.This will make it easier to spot issues as either project evolves.
A related goal is to have some way of using the pico-sdk linker scripts as a template for the linker scripts in e.g. picowota (see templated linker scripts, issue #398 of pico-sdk).