spi_flash: add support for fast SPI speeds

[Arksine]

In PR #5450 we reduced the SPI clock to the 400KHz speed stated in the official SD Card specification. At the time I did this because I discovered some cards failed to initialize at 4MHz. That said, I thought the change could potentially affect other SD Cards, and based on feedback on Discourse it sounds like it has. This PR adds an -s (fast_spi) option that will set the clock to 4MHz when enabled.

As of right now this is untested, I need to restore the original bootloader on some of my boards currently running Katapult. I decided to create this now as a draft to get visibility for additional testers. It would be appreciated if some users with working configurations can checkout this PR and verify that it doesn't introduce a regression. When I am able to test and confirm that it works myself I will change the status of the PR.

In addition it would be good to have a tester experiencing the issue at 400KHz verify that running flash-sdcard.sh -s resolves the issue.

[Arksine]

I have successfully tested both with and without the new -s option on an SKR 1.3 and Flyboard Mini. Everything is working as expected, so I have changed this PR's status.

I do think that we need someone who can consistently reproduce issues at 400KHz to test and confirm that -s resolves the problem. Thus far I haven't been able to reproduce with any of my cards.

[CodeMonkeyX]

Here is the output I got from running with and without the -s option after applying the patch. It seems to work as expect and fixes the issue I was personally having.

nick@saitama:~/klipper $ ./scripts/flash-sdcard.sh /dev/ttyAMA0 fysetc-spider
Flashing /home/nick/klipper/out/klipper.bin to /dev/ttyAMA0
Checking FatFS CFFI Build...
Connecting to MCU...Connected
Checking Current MCU Configuration...Done
MCU needs restart: is_config=1, is_shutdown=0
Attempting MCU Reset...Done
Waiting for device to reconnect...Done
Connecting to MCU...Connected
Requested SPI Clock Frequency: 400000
Initializing SD Card and Mounting file system...

SD Card Flash Error: Failed to Initialize SD Card. Is it inserted?
Traceback (most recent call last):
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1327, in _configure_mcu_spibus
    self.fatfs.mount(printfunc)
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 327, in mount
    raise OSError("flash_sdcard: failed to mount SD Card, returned %s"
OSError: flash_sdcard: failed to mount SD Card, returned FR_NOT_READY

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1655, in main
    spiflash.run()
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1590, in run
    self.run_reactor_task(self.run_sdcard_upload)
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1573, in run_reactor_task
    k_reactor.run()
  File "/home/nick/klipper/klippy/reactor.py", line 292, in run
    g_next.switch()
  File "/home/nick/klipper/klippy/reactor.py", line 340, in _dispatch_loop
    timeout = self._check_timers(eventtime, busy)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nick/klipper/klippy/reactor.py", line 158, in _check_timers
    t.waketime = waketime = t.callback(eventtime)
                            ^^^^^^^^^^^^^^^^^^^^^
  File "/home/nick/klipper/klippy/reactor.py", line 48, in invoke
    res = self.callback(eventtime)
          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1545, in run_sdcard_upload
    self.mcu_conn.configure_mcu(printfunc=output_line)
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1362, in configure_mcu
    self._configure_mcu_spibus(printfunc=printfunc)
  File "/home/nick/klipper/scripts/spi_flash/spi_flash.py", line 1330, in _configure_mcu_spibus
    raise SPIFlashError(
SPIFlashError: Failed to Initialize SD Card. Is it inserted?
nick@saitama:~/klipper $ ./scripts/flash-sdcard.sh -s /dev/ttyAMA0 fysetc-spider
Flashing /home/nick/klipper/out/klipper.bin to /dev/ttyAMA0
Checking FatFS CFFI Build...
Connecting to MCU...Connected
Checking Current MCU Configuration...Done
MCU needs restart: is_config=1, is_shutdown=0
Attempting MCU Reset...Done
Waiting for device to reconnect...Done
Connecting to MCU...Connected
Requested SPI Clock Frequency: 4000000
Initializing SD Card and Mounting file system...

SD Card Information:
Version: 2.0
SDHC/SDXC: True
Write Protected: False
Sectors: 31116288
manufacturer_id: 3
oem_id: SD
product_name: SU16G
product_revision: 8.128
serial_number: E02E4721
manufacturing_date: 10/2012
capacity: 14.8 GiB
fs_type: FAT32
volume_label: b'SPIDER'
volume_serial: 2057008142
Uploading Klipper Firmware to SD Card...Done
Validating Upload...Done
Firmware Upload Complete: firmware.bin, Size: 32428, Checksum (SHA1): 00FAC96489A9EBBCB8FF4427B74F6F0928C6DB85
Attempting MCU Reset...Done
Waiting for device to reconnect...Done
Connecting to MCU...Connected
Requested SPI Clock Frequency: 4000000
Verifying Flash...Version matched...Done
Firmware Flash Successful
Current Firmware: v0.12.0-58-g25bc649c-dirty-20240101_151304-saitama
Attempting MCU Reset...Done
SD Card Flash Complete
nick@saitama:~/klipper $

[github-actions[bot]]

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.