Rp2040 add support for additional flash chips

[amken3d]

Why needed: We, Amken LLC (www.amken.us) are about to release a new series of Klipper compatible 3d printer control boards and extruder boards which use the rp2040 with winbond w25 flash in 4MB and 16MB flash chips. The current flash chips options on w25q080 caused issues in booting of our boards.
Implementation: Using pico-boot2-generator, checksummed .s files were generated for Winbond 1,2,4,8,and 16MB flash chips. Other vendor chips are also supported in this tool. Only the most commonly used Winbond and ISIS chips were selected. Can add more if required.

Single Compilation Step: direct compilation of the source file into an object file (stage2.o)
Dependencies: It relies on a single source file located at lib/rp2040/boot_stage2/boot2/$(STAGE2_FILE) as its dependency.
Includes: Precompiled checksumed files for popular Winbond w25 series of flash chips (including the one on pico)
Output: Generates a single output file, stage2.o, directly from the compilation process.
Tested: On custom boards with 1MB, 4Mb and 16MB chips from Winbond. Also tested on Pico.

[Sineos]

I assume there is no way to detect this automatically?
If manufacturers are adding "random" flash chips in their production, then this will create another challenge for the user to get the make settings right.

[hrken1]

@Sineos, yes and no. Yes, because most flash chips have a manufacturer and device id. No, because you'd have to query the chip somehow to get that info. Not impossible, but not exactly possible without loading a firmware into the controller. So a chicken and an egg situation.
In trying to design my new boards, I had to figure out what flash chips I wanted to use. I had to consider cost, availability and support. Availability being the biggest factor. The Arduino core has the best known list of the boards and flash chips for rp2040, there are out there. Searching through that list, Winbond stood out to me as being the most used. That is also the same company that supplies for Pico. Albeit, Pico only uses the W25Q080 (1MB) chip.
One idea is to mitigate your concern is to create a board definition list like they have in Arduino. Board makers submit their PR to add/update new boards. Example implemented here https://github.com/earlephilhower/arduino-pico/blob/master/docs/contrib.rst#adding-a-new-board. Board makers would have to keep their definitions up to date. As one myself, I don't see this as an extra effort. I see it as a value add and lessens my need to provide additional support. As a user, it would make the process much simpler. Just something to think of.

• H Keni (Amken LLC)

[hrken1]

Also, this issue of flash chips seem to have come up previously on discussion about other supported boards.
https://klipper.discourse.group/t/help-flashing-klipper-to-adafruit-feather-rp2040/3146/11

[KevinOConnor]

Thanks. I'm not sure this change is needed though. If one selects "low-level options" and selects a "Flash chip" of "GENERIC_03H with CLKDIV 4" then Klipper should work with just about any flash chip.

The first thing Klipper does on the rp2040 is copy flash to ram, and then it never accesses flash again. So, although "GENERIC_03H" is not particularly fast, it should have no noticeable impact on Klipper.

-Kevin

[amken3d]

@KevinOConnor , appreciate you for looking into this.
Here is my take on this.

1. Initialization Time and Boot Speed

While Klipper effectively minimizes flash access post-boot by copying necessary data into RAM, the initial boot process can be substantially slower under the 'GENERIC_03H with CLKDIV 4' setting. This impacts scenarios requiring quick reboots or updates, where a faster flash initialization could enhance the overall system responsiveness and reduce downtime. The "GENERIC_03H with CLKDIV 4" setting, while conservative and broadly compatible, may lead to slower boot times due to its lower data transfer rates. This can be significant in environments where quick restarts or updates are frequent. I have experienced this in my board bringups using W25Q128JVSIQ, W25Q32JVSSIQ and W25Q64JVSSIQ. When the generic driver is used, the behavior is erratic and not consistent. I tried to run diagnostics with a logic analyzer, but i wasn't able to get reproducible results. In some cases I had to set PICO_XOSC_STARTUP_DELAY_MULTIPLIER to 64 to get the board to even boot into Bootsel mode. Even then flashing of a u2f proved to be erratic.

2. Compatibility and Performance Trade-offs
   Some flash chips support faster protocols that can significantly improve data transfer rates without compromising reliability. Using a generic slow protocol ignores the potential performance benefits these chips offer.
   Although the 'GENERIC_03H' protocol ensures broad compatibility, it overlooks the performance capabilities of flash chips that support faster read protocols. This conservative approach limits Klipper's boot performance unnecessarily, especially when used with hardware capable of higher transfer speeds. A more nuanced approach could offer improved performance while maintaining compatibility. Furthermore, Generic_03h is still be fully supported as I have included the padded checksum file for it.

3. Impact on Firmware Updates and Flash Wear
   Even if Klipper primarily operates from RAM, firmware updates and potential logging or configuration changes may still involve flash writes. A slower flash protocol can extend the duration of these operations, impacting user experience and potentially increasing flash wear. This not only affects user experience during updates but may also increase wear on the flash chip due to prolonged write operations.

4. Future-Proofing and Feature Expansion
   As Klipper evolves, future features might require more frequent or faster access to flash memory. Designing with a more flexible or faster flash access protocol now could mitigate the need for significant restructuring later. Adopting a more flexible approach to flash access than 'GENERIC_03H' can provide a better foundation for features requiring faster or more frequent flash interactions. It's about future-proofing and ensuring Klipper remains responsive to both current and upcoming hardware capabilities.

With these, I hope I have been able to articulate why we need a better implementation than Generic_03h. I am sure that there are better ways to do what I am trying to do with this PR. We can iterate and make this better.

#4996

[amken3d]

Closing as I feel that my implementation is not the best. Will reopen when I have a better solution.