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

Initial support for rp2350 chips #138

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

KevinOConnor
Copy link
Contributor

This PR resynchronizes the src/rp2040/ directory with the latest Klipper code. Notably, this adds support for rp2350 chips to Katapult.

This is a fairly large change mostly because of subtle differences between the previous Katapult rp2040 code and the Klipper rp2040 code. Notably:

  • rp2350 support.
  • The previous "execute from ram" Katapult implementation has been replaced with the Klipper "execute from ram" code.
  • The pico-sdk has been updated to v2.0.0 .
  • The can2040 code has been updated to the latest version (needed for pico-sdk v2.0.0).
  • The USB code will now implement double buffering (as that was recently added to the Klipper code).
  • If using UART, one can select several different UART pins during "make menuconfig".
  • Support for RP2040_ADD_BOOT_SIGNATURE was disabled. The scripts/uf2_append_boot_signature.py is still present, but it can't be enabled from "make menuconfig". I'm not sure what this code does, so I don't know how to test it (in particular on the rp2350 chips).

Note "enter bootloader on rapid double click of reset" support does not work on the rp2350 chips. It seems like these chips disable power to the SRAM0 and SRAM1 blocks when the RUN pin is pulled low, and thus codes written to the "bootup_code" address do not persist upon tapping the reset button. These memory based codes do persist across a normal armcm software reset, so entering the bootloader and starting the application do work. The rp2040 continues to support "entry via double click reset".

It may be possible to support "enter via reset double click" on the rp2350 by reconfiguring the chip power registers. It may also be possible to support it using the chip's own CHIP_RESET.DOUBLE_TAP mechanism. In either case, more investigation will be needed; it can be added in a follow up PR.

I've performed basic tests with this code on an rp2350 chip in USBSERIAL mode. I have also verified the code continues to run on an rp2040 chip (also tested in USBSERIAL mode).

@sh83 - FYI.

-Kevin

…hips

Synchronize with the latest Klipper code.  This pulls in the latest
lib/ files (needed to use the pico-sdk v2.0.0 version).  It updates to
latest can2040 code (needed for pico-sdk v2.0.0 support).  It
implements USB double buffering (as is now done in Klipper).  It adds
in support for additional UART pins (as is now done in Klipper).  It
adds support for rp2350 chips.

This replaces the execute in ram code previously implemented in
Katapult with the execute in ram code that is now standard in Klipper.

Signed-off-by: Kevin O'Connor <[email protected]>
It appears the rp2350 disables SRAM power when the RUN pin is pulled
low.  As a result, one can not store a code in regular memory to
detect if the RUN pin is pulled low multiple times.

Add a new CONFIG_HAVE_BOARD_CHECK_DOUBLE_RESET mechanism to allow the
board code to override the standard double reset checking code.
Implement an rp2350 specific check that uses the chip's POWMAN
chip_reset field to store/check a double reset condition.

Signed-off-by: Kevin O'Connor <[email protected]>
@KevinOConnor
Copy link
Contributor Author

I was able to implement "enter bootloader on reset double tap" on the rp2350 chips. I added a board specific mechanism for detecting rp2350 double taps. Instead of storing a code in SRAM, it stores a bit in the rp2350 POWMAN chip_reset register (which is not reset on RUN pin changes).

The second commit on this PR has this new code.

-Kevin

@sh83
Copy link
Contributor

sh83 commented Dec 13, 2024

The point of uf2_append_boot_signature.py is to prevent damaged application execution if it was partially overwritten by bootloader.
Consider the sequence:

  1. Mcu have klipper installed out of box
  2. The user flashes katapult on top of it. This way the klipper fw become damaged
  3. Katapult just check for 0xff and 0x00 empty flash signature, do not see any and just try to boot main fw.
  4. Bootloop or firmware hangs.

append_boot_signature just add one flash page of 0xFF at the application start. This way it force bootloader entry and application update by the user. It will force update application even if it was compatible with bootloader, but I think in most common cases application should be updated anyway.

Best wishes.

@Arksine
Copy link
Owner

Arksine commented Dec 14, 2024

This looks good to me, I'll merge when you are ready Kevin.

With regard to clearing the application area, one alternate solution would be to add an option to rp2040_flash that erases the first block of the application area. That said, it may be easier to continue to modify uf2 file.

@KevinOConnor
Copy link
Contributor Author

Perhaps we could always generate two uf2 files - one normal and one with clearing.

--- a/src/rp2040/Makefile
+++ b/src/rp2040/Makefile
@@ -57,6 +57,8 @@ $(OUT)lib/elf2uf2/elf2uf2: lib/elf2uf2/main.cpp
 $(OUT)katapult.uf2: $(OUT)katapult.elf $(OUT)lib/elf2uf2/elf2uf2
        @echo "  Creating uf2 file $@"
        $(Q)$(OUT)lib/elf2uf2/elf2uf2 $(OUT)katapult.elf $(OUT)katapult.uf2
+       @echo "  Creating uf2 file $(OUT)katapult.withclear.uf2"
+       $(Q)$(PYTHON) ./scripts/uf2_append_boot_signature.py --address $(CONFIG_LAUNCH_APP_ADDRESS) --input $(OUT)katapult.uf2 --output $(OUT)katapult.withclear.uf2
        @echo "  Creating legacy uf2 file $(OUT)canboot.uf2"
        $(Q)cp $@ $(OUT)canboot.uf2
 

I was able to test that the modified uf2 (eg, katapult.withclear.uf2) does works on the rp2350.

-Kevin

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

Successfully merging this pull request may close these issues.

3 participants