Code/uf2 is up here now https://github.com/BlueSCSI/BlueSCSI-v2/pull/198 - if you give it a try let me know!
Here's a screenshot from that Github page...
So just to clarify...
Even though it says "BlueSCSI-Pico2-58226df.uf2" firmware can be tested "on any version of BlueSCSI hardware," the performance improvements for Write Speed only occur when you have a Pico 2 board installed, correct?
In other words, most people with a BlueSCSI v2 will have either a Pico or PicoW. But to get the new Write speed improvements, you would need to remove the Pico or PicoW and solder in a Pico 2, correct?
If so, based on what I am reading here, there won't be a Pico2W until the end of 2024.
So just to clarify...
Even though it says "BlueSCSI-Pico2-58226df.uf2" firmware can be tested "on any version of BlueSCSI hardware," the performance improvements for Write Speed only occur when you have a Pico 2 board installed, correct?
In other words, most people with a BlueSCSI v2 will have either a Pico or PicoW. But to get the new Write speed improvements, you would need to remove the Pico or PicoW and solder in a Pico 2, correct?
If so, based on what I am reading here, there won't be a Pico2W until the end of 2024.
I know, but you know me. I love it when things are plainly stated on a grammar school level. That's really what my entire YouTube channel is about. Saying things in a more detailed yet plain way so even a true nincompoop like me can understand it!Any version of BlueSCSI hardware (with a Pico2 (which I thought was implied as it's a firmware for the Pico 2))
Don't do that, everyone who I see try to remove a Pico destroys the board. Get a kit or build some of your own boards, put a socket on it.
Being the cheapest man alive, I did manage to remove my Pico boards and replace them with Pico W boards on the two BlueSCSI v2 hardware units that I have. They appear to be working fine. But I will admit that it took a lot of time and great care with Hakko FR-301 desoldering gun to achieve it. So advising others to just buy a new kit is probably best. I agree that you avoid both trouble and hassle that way.
If you do plan to replace the Pico with a Pico 2, my two cents is that you should not be desoldering from the bottom of the BlueSCSI PCB.
If your board has pin headers holding the Pico in place, then desolder the Pico from the top only. As Eric mentions, it's very easy to damage the BlueSCSI PCB when desoldering. The Pico's pad holes seem to be more robust and hold up better against a desoldering tool.
If your board has pin headers holding the Pico in place, then desolder the Pico from the top only. As Eric mentions, it's very easy to damage the BlueSCSI PCB when desoldering. The Pico's pad holes seem to be more robust and hold up better against a desoldering tool.
Another big new release this month - https://github.com/BlueSCSI/BlueSCSI-v2/releases/tag/v2024.10.26
Release v2024.12.08 · BlueSCSI/BlueSCSI-v2
This update is recommended for all users and should be the end of any odd SDIO timeouts or errors that were experienced by a small number of users. With the SDIO rewrite by @androda last release an...
github.com
This update is recommended for all users and should be the end of any odd SDIO timeouts or errors that were experienced by a small number of users. With the SDIO rewrite by @androda last release and the framework updates this release we have not seen any reports of issues.
Note even though we now support 4(+) Pico boards (Pico1/1w/2/2w/etc) - there is only 1 .uf2 file to flash - no need to wade through 18+ files to figure out the right one to flash, there's only one choice and it'll do the right thing(tm).
You would see SDIO timeouts while using the BlueSCSI in the log file. Users would see extremely slow speed due to the timeouts. I think we had a total of 12 users report this (so very small) and took us a while to even narrow down as none of our (same model) computers would exhibit this behavior. Not a huge common factor but 8x00's and some Sun workstations were the main ones. Nothing to do with a specific task or wifi.
On the up side since @Androda completely re-wrote the SDIO communications layer it is a huge improvement over the previous one in terms of reliability.
With help from Greiman of course. He provided a generic RP2040 SDIO implementation which made a lot more sense than what was already in use. My main contribution was cutting down the number of PIO instructions it required and hooking it into the existing framework.
There was some discussion in the BlueSCSI Web thread about SD card fragmentation, and I wanted to add to it without polluting the thread, so I am moving it here if that's okay.
I currently use an M4 Mac to setup my BlueSCSI cards, and while I have had a few stumbling blocks on the way, I have managed to reliably create SD cards that have no fragmentation of the disk images. Unfortunately, with modern filesystem tools basically accepting file fragmentation as a way of life, I haven't been able to do much inspection of the SD cards themselves to really dig in, but here's what I've run across.
EDIT: rsync will strip out extended attributes, so should not need to use 'xattr -c' with it.
I currently use an M4 Mac to setup my BlueSCSI cards, and while I have had a few stumbling blocks on the way, I have managed to reliably create SD cards that have no fragmentation of the disk images. Unfortunately, with modern filesystem tools basically accepting file fragmentation as a way of life, I haven't been able to do much inspection of the SD cards themselves to really dig in, but here's what I've run across.
- There's the usual .DS_Store and Spotlight index updates during a copy that can be a problem.
- Apple's increasingly aggressive Gatekeeper setup is adding extended attributes to files that previously did not include them, including those created by Disk Jockey. Copying a file with extended attributes will cause it to be fragmented as the extended attributes are written to a separate file in parallel.
- Formatting with Disk Utility triggers macOS to create the .Spotlight-V100 folder before you can even disable indexing on the drive. Disabling Spotlight will not remove the multitude of files that wind up in this folder, and these files seem to do a good job of fragmenting the free space on the drive. The result is the first image for me usually winds up fragmented despite dealing with the above.
- Add the images I want into a single folder.
- Open a terminal window and navigate to the folder.
- First, create a "filler" file to fill in the fragmented free space: dd if=/dev/zero of=00Filler bs=1M count=128
Second, strip extended attributes:xattr -c *- Third, ensure Spotlight is disabled on the SD card if I just formatted it, and then delete any files on the card.
- Finally, run rsync to mirror the folder to the SD Card: rsync --progress -av * /Volumes/<SDCARDNAME>
EDIT: rsync will strip out extended attributes, so should not need to use 'xattr -c' with it.
Last edited:
Thanks for some details on what you do - I have an M3 Max MacBook Pro and what I do is updated in the wiki - https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Image-File-Fragmentation#mac-os
You can simply `cp -X file.hda /Volumes/sdcard` which will avoid copying any extended attributes
Note that not all extended attributes are cleared via xattr -c - you have to do com.apple.provenance separately
ALSO note you MUST use Terminal.app (not a 3rd party terminal like iTerm (which i use)) as it can not remove com.apple.provenance!
I honestly don't know why Apple makes this so hard. If file is being copied to a FS that doesn't support xattr's - ignore em! (eg cp -X)
You can simply `cp -X file.hda /Volumes/sdcard` which will avoid copying any extended attributes
Note that not all extended attributes are cleared via xattr -c - you have to do com.apple.provenance separately
ALSO note you MUST use Terminal.app (not a 3rd party terminal like iTerm (which i use)) as it can not remove com.apple.provenance!
I honestly don't know why Apple makes this so hard. If file is being copied to a FS that doesn't support xattr's - ignore em! (eg cp -X)
Funny enough, rsync strips extended attributes (including quarantine) without any additional parameters in Terminal.app, which I just confirmed. This is what happens when I don't have a lot of time to truly grok what's going on.
Apple does things for the sake of macOS behavior, and compatibility with other systems is secondary. Sadly, the lack of the quarantine attribute has special meaning, which is one reason Apple works to preserve these attributes and is getting more aggressive about setting them (provenance is related, which is why it's hard to remove). And the case of it creating fragmented files is mostly only an issue for specific use cases like these which aren't exactly common. It sucks, but I see little chance of change. Especially when the things that bite us the most are part of macOS' defenses against bad actors.
I would have been tempted to go with an SD card layout that enables the BlueSCSI to effectively have a contiguous block of addresses to put HDD images outside of the FAT partition and use the FAT partition for config/CDs/shared. But that means specialized tools to get those drive images on/off the card.
@eric I was looking to order a batch of these from JLCPCB and I think I have it pretty well set up, but the LED and the JST connector at J6 are both out of stock. I found a replacement LED, but I could not find a replacement for the 6 connector. The question I have is what is it used for? I haven't seen anything in the documentation about its use and I'm wondering if I could get these ordered without it on the board. Worst case I could always add it later if needed (although it may be tight with a few of the components around it. Any advice would be greatly appreciated!
There should be a bunch of common LED's (i'd hope) in the common parts at JLC - some discussion here https://github.com/BlueSCSI/BlueSCSI-v2/discussions/113
Also remember to order them in Blue
(it really doesn't add 2 days as the UI says)
Ah, so it a used to interface between the control Pico and the BlueSCSI. I may wait until they can have the part, then, as I think I’ll be trying to use that setup (I prefer opening my machines as little as possible due to the plastics).
There should be a bunch of common LED's (i'd hope) in the common parts at JLC - some discussion here https://github.com/BlueSCSI/BlueSCSI-v2/discussions/113
Also remember to order them in Blue
Yeah, I could find a replacement for the LED (although only in green), but I found you can pre-order parts, so I now have many more JST connectors and LEDs than I will use ordered. Hopefully in 10 days I'll have a complete BOM and can order my assembled PCBs. I didn't realize you could also order from other people's idle parts inventory. Unfortunately, no one had any idle inventory for the JST connectors.
To get rid of any .DS_Store on my SD Card I always use this.
Code:
# Navigate to the relevant Volume (replace the volume name)
cd /Volumes/SD
# Find any .DS_Store files (optional) within the folder
find ./ -name .DS_Store -print
# Delete any .DS_Store files within the folder
find ./ -name .DS_Store -delete