-
Notifications
You must be signed in to change notification settings - Fork 20
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
Ultra SCSI (Fast20) support with reclocking the RP2040 and RP2350 line of boards and user editable reclocking timings #468
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bootloader works for Pico 2s. Putting a `zuluscsi.bin` file will now update the firmware. Also increased the SRAM size from the RP2040 to the RP2350 max size.
With the RP2350 at 150MHz, one clock cycle is 6.67 ns (150MHz) => delay 8.25 clocks or 9 clocks .define REQ_DLY 9. Thanks, @morio
Moved the RP2040 and RP2350 to the same customized arduino pico framework. That is compatible with both USB mass storage and the DaynaPORT Pico W SPI pio Wifi interface. Other changes include a base PlatformIO target that all RP builds inherit from. This gets rid of a lot of repeated settings. An unrelated change was the added the ability to set the timeout for USB enumeration as sometimes RP devices take longer than second to enumerate when on a USB hub. And adding both `EnableUSBMassStorage` and the new `USBMassStorageWaitPeriod` to the example `zuluscsi.ini` file.
Since the arduino pico library and the pico-sdk automatically build for either the RP2040 and RP23XX MCUs, both libraries have been merged into `lib/ZuluSCSI_platform_RP2MCU` with `#if` type C macros for some of the files and code snippets that are tied to the MCU. For example RP's PIO assembly files, timing delays and clock dividers.
Setup up SDIO delays in a struct that is rewritable and used that struct to initialize the SDIO interface. This should allow reclocking of the SDIO interface PIO statemachine.
There are two clock speed that can be reclocked to currently that seem to work 125MHz at 10MB/s sync and 250MHz at 20MB/s. Forcing slower sync speeds at 250MHz hasn't been tested. The Pico and Pico 2 haven't been setup either. The settings are to test it out are ``` [SCSI] ReclockInKHz = 250000 # set to 250MHz using KHz MaxSyncSpeed = 20 # to enable ultra Synchronous SCSI mode ```
In `lib/ZuluSCSI_platform_RP2MCU/timings.c` are the three clock settings for the product line. With a special setting for the SD clock rate of the Pico 2 as it could not do 50MHz SDIO clock at a 250MHz system clock. Was able to consolidate all the sdio pio and scsi_accel_target pio assembly files into one file for each function by setting the gpio waits dynamically via rewriting the the command in code. There are 3 things left to do. - Consolidate the scsi_accel_host pio files - Turn the Audio Build back on - See about DaynaPORT compatibility at high clock rates
Added back the Audio build and consolidated the initiator PIO assembly files into one by setting the wait GPIO in the C++ code. Also confirmed that the DaynaPORT works at 250MHz.
Added `zuluscsi_timings.ini` so users can modify their timing values by themselves. It limits their clock rate to 250MHz as higher clock rates than 266MHz require a recompile and 250MHz creates a nice 50MHz SDIO clock.
Pressing `m` or `r` then `y` will reboot the board. If `m` is pressed the board will reboot into mass storage. This will be useful to users playing with their timings or modifying their `zuluscsi.ini` settings. For users modifying their timings, they will need to reboot into mass storage, edit their `zulu_timings.ini` file, then do an 'r' reboot to reclock their board with their new settings. Most zuluscsi.ini file settings get reloaded after ejecting the mass storage device.
Removed the `zuluscsi.ini` setting for matching reclocking via KHz presets to using SpeedGrade = TurboMax etc.
Binaries from the CI for the initial pull request Run vcocalc.py here: https://www.online-python.com/LV1oJhiXe3 Here is the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This contains changes allowing the user to set
SpeedGrade
toTurboMax
in thezuluscsi.ini
file and get speeds up to 17MB/s reads with RP2040 based boards and over 10MB/s writes with a quality Class 10 SD card.Timings can be fined tuned with
zuluscsi_timings.ini
as the Turbo speeds grades have not been fully flushed out.Users can open the USB serial console and hit the 'm' key followed by the 'y' key to boot into mass storage mode, change either
zuluscsi.ini
orzuluscsi_timings.ini
, eject the mass storage device from the host computer and have their timing changes loaded into the ZuluSCSI without needed to eject the SD card or power off the ZuluSCSI.In
zuluscsi_timings.ini
file the sync period and sync offset can be set to the value negotiated by the SCSI host so when restarting via the USB serial console you don't loose the sync on the device side. Helpful for speed testing with command likedd
in Linux.Overclocking the RP2040 to our limit of 250MHz is beyond the factory specs and the long term side effect are unknown.
You can google https://www.google.com/search?q=overclocking+the+rp2040+to+250MHz for more information