Skip to content
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

lpc176x: don't write to 0x2FC. #6506

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jernejp21
Copy link

Leave 0x2FC - 0x2FF alone, since it stores values for code read protection. We don't want to lock flash permanently.

According to user manual, 0x2FC is reserved for CRP mechanism. It might happen that generated code is exactly the same as CRP1, CRP2 or CRP3. For that reason we should avoid writing to that area.

slika

Leave 0x2FC - 0x2FF alone, since it stores values for code read protection. We don't want to lock flash permanently.

Signed-off-by: Jernej Pangerc <[email protected]>
@Arksine
Copy link
Collaborator

Arksine commented Feb 24, 2024

Interesting. I think the chances that we would unintentionally write CRP3 are extremely low, but I see the utility in making it impossible. If its decided that we need to avoid 0x2FC, I think a simpler solution would be something like this:

diff --git a/src/generic/armcm_link.lds.S b/src/generic/armcm_link.lds.S
index 2f789f13..46126584 100644
--- a/src/generic/armcm_link.lds.S
+++ b/src/generic/armcm_link.lds.S
@@ -22,6 +22,9 @@ SECTIONS
         _text_vectortable_start = .;
         KEEP(*(.vector_table))
         _text_vectortable_end = .;
+#if CONFIG_LPC_FLASH_START_0000
+        . = 0x300;
+#endif
         *(.text .text.*)
         *(.rodata .rodata*)
     } > rom

I'm curious to see Kevin's feedback. If we make this change to Klipper I will also make it to Katapult.

Copy link

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

  1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
    If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
  2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
  3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@KevinOConnor
Copy link
Collaborator

Interesting, thanks. I agree it is worthwhile to change the code to avoid this problem.

I agree with Arksine in that I'm unsure about changing FLASH_APPLICATION_ADDRESS and about introducing a new "vector" segment in the linker script. I do think we should introduce a new lpc176x_link.lds.S file though (as I think we should try to avoid adding board specific code to the src/generic/ directory). How about copying src/generic/armcm_link.lds.S to a new src/lpc176x/lpc176x_link.lds.S and adding Arksine's suggestion there (along with a comment about needed to avoid CRP1).

Thanks again,
-Kevin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants