squishy-scsi / squishy Goto Github PK

Any unconfigured FPGA I/O will end up floating, and may possibly cause problems, such as driving the transceivers or enabling TERMPWR.

As such we need to ensure that all I/O be explicitly set to a known and safe level.

A guide on how to use the Squishy CLI needs to be written and verified.

The Squishy software install instructions need some vetting and cleanup.

Only Linux is officially supported but try to ensure the macOS and Windows install guides also work well.

The getting started guide needs to be written.

It should include how to initially setup the software and hardware, as well as an example use case to get started with.

This is blocked by:

• #14
• #15
• #16
• #17

The hardware usage and setup guide documentation needs to be written.

This is blocked by the following issues:

• squishy-scsi/hardware#13
• squishy-scsi/hardware#12
• squishy-scsi/hardware#11
• squishy-scsi/hardware#10
• squishy-scsi/hardware#9
• squishy-scsi/hardware#8
• squishy-scsi/hardware#7
• squishy-scsi/hardware#6
• squishy-scsi/hardware#5
• squishy-scsi/hardware#4

To make development easier and more clear, add type annotations to as much as possible

A guide on how to use the Squishy GUI needs to be written and verified.

Setup / Automate packaging for Debian / apt/dpkg based distributions

The squishy applet interface needs to be properly formalized.

Currently it allows for command line arguments, but not much between the hardware and applet code itself. Also REPL/GUI support for applets would be nice.

• GUI Support
• REPL Support

Finish implementing the rest of the standardized SCSI commands as well as any related structures and enumerations needed to properly handle them.

Write a document to help people wanting to delve into the code.

Explain terminology usage where it may be ambiguous, confusing, and/or archaic/arcane, as well as any potential gotchas that may be encountered when doing development.

Various tutorials on how to use the Squishy software and hardware need to be written.

This is blocked by #29

• Custom Applets
• Hardware Usage (blocked by #14)
• Software Usage
• Applets
  • Analyzer Applet
  • Taperipper Applet
• Gateware Library
• Python Library

The Squishy device wrapper needs to be fleshed out to allow for applet code running on the host system to communicate with the hardware over the sideband interface.

Blocked on pypi/support#1937.

Create the PyPi package for distribution via pip.

Ensure the Python library and Gateware library componentes are properly documented.

This is blocked by:

• #23
• squishy-scsi/hardware#3
• #26
• #28
• #27

Implement the structures and enumerations related to the SCSI protocol messages.

When using the Yowasp builds of Yosys and nextpnr there is an issue with detecting them and using them when trying to build gateware. We need to add detection for this and warn if we don't find any of them.

NOTE: Also need to investigate to see how the ULPI timings go for the yowasp flow, they seem to fail by at least 7MHz even with ABC9

The tests.gateware.core.test_flash.SPIFlashTests test is non-deterministic and randomly fails/passes.

The gateware itself works enough for DFU and applet updates, but the tests being unstable is non-ideal.

This is likely due to how the Torii pysim engine works. So there is no real fix right away, ideally I'd like to be able to formally verify it, but that is much later on the docket.

This issue will likely be around until the new sim engine is in Torii, so just skipping that test might be the best for now

Implementation of the gateware for the SCSI Target and Initiator state machines for all 3 versions of SCSI need to be properly implemented.

• SCSI-1
• SCSI-2
• SCSI-3

In addition to this target extensibility to be able to register custom SCSI commands needs to be implemented to allow proper flexibility as a library component.

Setup / Automate packaging for RHEL / RPM based distributions

Setup / Automate packaging for Arch Linux / pacman based distributions

The introduction page of the documentation needs some cleanup and re-wording to make it a little friendlier to read as well as a better jumping off point to get into the rest of the project.

The multiboot gateware for rev1 and rev2 needs to be written and finalized. It is based off the work @dragonmux did with dragonBoot

It will expose a DFU endpoint over USB to allow the gateware and in the case of the rev2 hardware the supervisor firmware to be updated.