F4 BlueSCSI, a BlueSCSI Fork By Androda

[Androda]

F4 BlueSCSI, a BlueSCSI Fork by Androda (Tech by Androda)

GitHub - androda/F4_BlueSCSI: A small SCSI device based on STM32F4

A small SCSI device based on STM32F4. Contribute to androda/F4_BlueSCSI development by creating an account on GitHub.

github.com

F4 BlueSCSI devices have been available for some time now, in a wide variety of styles:
* PowerBook
* Standard 50 Pin Internal
* DB25 External
* Centronics 50 Pin External

The software is licensed GPL like upstream, and hardware versions are licensed Attribution-NonCommercial 4.0 International: https://creativecommons.org/licenses/by-nc/4.0/legalcode

If you are interested in making these hardware versions for sale, please contact me for alternate hardware licensing. I am looking for a distributor in the EU because international shipping and tax regulations are quite hard to follow.

There are two microcontrollers used by this fork, the STM32F401 (called F4Lite) and STM32F411 (called F4 or Full F4).
* F4Lite (green) modules cost about the same as the STM32F103 Blue Pill modules which are used by upstream BlueSCSI, but are faster
* F4 Black Pill modules cost a fair bit more, for even higher performance

A wiki page for performance numbers and known-compatible systems can be found here: https://github.com/androda/F4_BlueSCSI/wiki/System-Compatibility-and-Performance

FAQ:
Q: Is F4 BlueSCSI a competitor to upstream BlueSCSI?
A: Not really, Eric and I see it from the perspective of making SCSI solutions more available

Q: Wait, isn't this closed source?
A: Not any more. F4 BlueSCSI was closed source in the past for a variety of reasons, but has been open source for a few months now. For other reasons.

Q: Do you contribute to upstream BlueSCSI?
A: Yes! I created an XCVR hardware version for upstream BlueSCSI and contributed code changes to make it work.

Q: What's XCVR?
A: XCVR is short for Transceiver. Transceiver chips increase compatibility with picky SCSI-2 controllers, and act as a layer of protection for the BlueSCSI microcontroller.

The BlueSCSI name is used with permission from Eric.

 

[eric]

Thanks @Androda for all the hard work making BlueSCSI hardware, software, & community better!

I have one of the first (I think) F4 XCVR boards - using it in my external enclusre for my PowerMacs - works great.

 

[Androda]

A new Release Candidate build has just been posted. If you are able to flash the update and do some testing, it would be very much appreciated.

Release Candidate Link:

Release Release Candidate : 1.1-SNAPSHOT-2022-06-21 · androda/F4_BlueSCSI

This is a SNAPSHOT firmware, intended to be used by early adopters. Please back up your images before testing (note that none of my drive images were corrupted in testing this version). If you disc...

github.com

Firmware update steps:

Flashing Firmware Updates

A small SCSI device based on STM32F4. Contribute to androda/F4_BlueSCSI development by creating an account on GitHub.

github.com

 

[retr01]

What about increasing the transfer rate by overclocking? That is currently not available, right?

What do you think about increasing the transfer rate @Androda?

 

[Androda]

What about increasing the transfer rate by overclocking? That is currently not available, right?

What do you think about increasing the transfer rate @Androda?

I am unsure whether overclocking would increase transfer rates. BlueSCSI currently only speaks "Asynchronous SCSI", which is a slower protocol. "Synchronous SCSI" is faster, but much trickier to implement with current hardware.

Overclocking is something I've been meaning to look into, out of curiosity more than anything. Overclocking can cause hardware damage, because you're straining a part beyond the intended specs, and is something to be done 'at your own risk'.

 

[retr01]

I am unsure whether overclocking would increase transfer rates. BlueSCSI currently only speaks "Asynchronous SCSI", which is a slower protocol. "Synchronous SCSI" is faster, but much trickier to implement with current hardware.

Ah, gotcha. Yeah, I'd like synchronous.

Overclocking is something I've been meaning to look into, out of curiosity more than anything. Overclocking can cause hardware damage, because you're straining a part beyond the intended specs, and is something to be done 'at your own risk'.

That is correct. Yet, if overclocking is done on the BlueSCSI itself, it should not affect the host computer as long as the transfer rate is within the tolerance of the host's design? Besides, SCSI-1 allows asynchronous data transfer rates of 1.5 Mbps and synchronous transfer rates up to 5 Mbps. So, if overclock to have a sustained transfer rate of 3 Mbps, up to 4 Mbps, then should it be okay? Also, since the BlueSCSI F4 series can use 12v, that can be used for overclocking instead of termination power. Does that help?

 

[Androda]

I attempted some overclocking this morning.

The STM32F411 chip is rated at 100MHz. Overclocking to 125MHz resulted in a lockup on boot. Tweaking the F4 series' flash read accelerator didn't help. I had to change the AHB peripheral pre-divider to get the chip to start at this speed, and because the peripheral bus speed is divided everything goes slower talking to the outside world. Managed a pedestrian 1500k read and 1300k write after getting things working. The biggest learning from this experience is that the F4 series of chips does *not* like to be overclocked.

However, through this I've learned the way to set up the clock system to provide the F411's full 100MHz speed. The framework was set up to run at 96MHz, so that's 4 MHz for free. A small speed increase comes along with this, but nothing huge. Beige G3 benchmark shows an improvement of about 100k per second read speed.

 

[retr01]

Those chips can go up to 250 Mhz with overclocking, as indicated in this post on STM32F4 Discovery. However, you noted that the overall chipset of the F4 series is not designed for overclocking.

I wonder, what parts of the F4 series are resisting or overwhelmed with the higher frequencies?

 

[Androda]

I'll try their specific configuration to see what it does.

 

[Androda]

Another pre-release set of binaries has been generated, to fix formatting-utility-related errors:

Release Link:

Release Release Candidate: 1.1-SNAPSHOT-2022-06-27 · androda/F4_BlueSCSI

This is a SNAPSHOT firmware, intended to be used by early adopters. If you discover issues, please post them: In Discussions on this repo (discussion will be created automatically for this pre-rel...

github.com

Firmware Update Steps:

Flashing Firmware Updates

A small SCSI device based on STM32F4. Contribute to androda/F4_BlueSCSI development by creating an account on GitHub.

github.com

 

[retr01]

I'm wondering if you will implement the new feature that BlueSCSI F4 series can identify itself as any hard drive by use of the scsi-info.txt file?

https://github.com/erichelgeson/BlueSCSI/releases/tag/v1.1-20220626

 

[Androda]

This feature has been in the BlueSCSI codebase for a rather long time, actually. I think it was called out in this release because it had never been officially 'mentioned in a release notes' before.

F4 BlueSCSI uses the same configuration as upstream, as mentioned in the Usage section of the main repo:

Usage is intended to be the same as the parent project and will be kept in sync

Attached is from the 'device info' section in SCSI Director 4, showing that it works on F4 BlueSCSI. Personalized just for you.

 

[retr01]

Cool. Thank you, @Androda. So, I can go ahead and create the scsi-info.txt and place in the root directory of the SD:

From BlueSCSI's GitHub repo SCSI Vendor Config wiki page:

• The first line is the vendor and must be exactly 8 characters. (add spaces if not)
• The second line is the product and must be exactly 16 characters. (add spaces if not)
• The third line is the version and must be exactly 4 characters. (add spaces if not)

Hence the scsi-info.txt could be:

BLUESCSI
DESKTOP_F4LITE__
v1.1

 

[Androda]

Those chips can go up to 250 Mhz with overclocking, as indicated in this post on STM32F4 Discovery. However, you noted that the overall chipset of the F4 series is not designed for overclocking.

I wonder, what parts of the F4 series are resisting or overwhelmed with the higher frequencies?

I've tried this specific overclock configuration. It actually results in a decrease of read/write performance, for reasons I don't quite understand. Drops to 1700k read and 1500k write on beige G3.

This overclock is a little weird and doesn't seem to realize that although [(25 * (500/25)) / 4] works you can get the same results from [(25 * (250/25)) / 2] without pushing the PLL past the max multiplier suggested in the datasheet.

Standard config:
100MHz CPU Core
100MHz AHB (high speed bus connected to the GPIO pins and flash accelerator)
100MHz APB2 (we care about this one a lot, it's where the SPI peripheral lives)
50MHz APB1 (not using anything from here).

This specified overclock:
125MHz CPU Core
125MHZ AHB
62.5MHz APB2 <-- this looks like an issue
31.25MHz APB1

Looking at this, you'd think "oh, the APB2 speed is cut and that's why performance decreased". It's not this simple, unfortunately. I tried a modification of this overclock, to run the APB2 bus at full 125MHz speed. The most confusing part is, overclocking APB2 also results in performance loss compared to leaving everything alone.

The final test I ran this morning was to also overclock APB1. Why not, when everything else is overclocked too? Well, this didn't change anything. Big surprise, we aren't using any peripherals on that bus.

So the fact of the matter is: I'm not sure what's going on here. My configuration looks like it should be overclocking all the relevant busses, to apparently no useful effect.

And simply changing the multiplier from [(25 * (250/25)) / 2] (overclock) to [(25 * (200/25)) / 2] (the standard) restores full operating speed of 2036k read / 1800k write on beige G3.

 

[retr01]

They were probably throttled when overclocking because of the data paths, circuitry, and core designs. Besides, unless the SCSI is wide, older Macs will not see much difference anyway, no?

Cheers!

 

[Trash80toG4]

Got pics?

 

[Androda]

Got pics?

Pictures of what? The F4 BlueSCSI products? Those are on my website.

 

[Androda]

A new firmware release has just been posted. This one is not a pre-release, it's a full release. No issues were reported in the past month with the snapshot, and I haven't had any issues in testing.

Release 1.1-2022-07-27 · androda/F4_BlueSCSI

Most changes around Formatting Compatibility After testing around with the previous release candidate, it was noted that formatting in Drive Setup no longer worked. Changes were made in upstream to...

github.com

This version is the same as the pre-release 2022-06-27, with a few small changes. The log file was updated to write out F4 or F4Lite depending on the build, and a change was made to GPIO handling on F401 to deal with some issues I've been experiencing.

This release brings F4 up to date with the upstream release v1.1-20220626.

 

[Androda]

A new Optical Drive BETA Release has just been posted:

Release Optical Drive Support BETA · androda/F4_BlueSCSI

This is a BETA release of optical drive image support for BlueSCSI, based on Troy's Optical Branch. This branch has a PR open for merging into upstream BlueSCSI. Optical drive images are usually g...

github.com

This BETA release is based on the same branch from our friend @mynameistroy as the upstream Optical Beta.

CD images are specified with "CD" instead of "HD", e.g:
"CD10_2048_OS8.iso" sets up your disk image at SCSI ID 1, LUN 0, sector size 2048 (normal for CD images)

Instructions for flashing this new firmware are available here

 

[Androda]

I've tweaked the mounting bracket for the existing F4Lite V1.1 design, in the hopes that it will work with LC520 style edge connector machines (I don't own one of these systems unfortunately). Looking for a tester or two in the USA, DM me if interested. My eyeball and caliper say that things are really close to the right positions, but expect a small adjustment or two to be necessary.