[zthart]

OP, is there a reason you are using the 6.4 vs the RP2040 version?

No specific reason beyond that's the one I purchased. Frankly, I bought it before I appreciated any of the differences between the SCSI2SD project and the ZuluSCSI project, and differences between versions of the ZuluSCSI models themselves. It seems even the minutia is tough to sort out in the setting of a forum thread as well.

The longer version of how I got here is that in doing research I first came across the SCSI2SD device, and when looking it up found this page (https://www.scsi2sd.com/index.php?title=SCSI2SD) which directly links to the ZuluSCSI V6.4 as the "direct successor". I didn't come to realize that there were other models (the naming convention of the ZuluSCSI being a newer "version number" than the version of the RP2040 or "base" ZuluSCSI hardware certainly doesn't help the confusion) until after I had the device and was trying to use it, and came across a ton of documentation that didn't seem to match the product I was trying to use.

I have been using the utility linked on the product page for the ZuluSCSI V6. I am not convinced that, with the V6, _any_ images need to be created on the SD card as of yet, nor that writing any data to the SD card manually even affects how the ZuluSCSI works. I've emailed the folks at rabbit hole computing to see if they have some more comprehensive docs for the thing as well as with a few sanity test questions. Will post any interesting content from that response here.

I'm also not ruling out the possiblity here that my specific device was DoA or has some deeper issue. The fact that my machine sees the SCSI devices and reports the correct block size of each (even when the SD card is completely empty) as I've been testing tells me at the very least that setting the properties via the utility is doing _something_. Based on context clues I think it's writing that configuration into the last two blocks on the SD card, rather than some sort of EEPROM or other non-volatile storage on the device. My current hypothesis is that the V6 uses the SD card as arbitrary block storage and handles the SCSI translation and offsetting of the blocks to the configured regions on the card, and cares not at all what might be on that card in terms of a filesystem or other image files.

[legodude]

OP, is there a reason you are using the 6.4 vs the RP2040 version?

No specific reason beyond that's the one I purchased. Frankly, I bought it before I appreciated any of the differences between the SCSI2SD project and the ZuluSCSI project, and differences between versions of the ZuluSCSI models themselves. It seems even the minutia is tough to sort out in the setting of a forum thread as well.

The longer version of how I got here is that in doing research I first came across the SCSI2SD device, and when looking it up found this page (https://www.scsi2sd.com/index.php?title=SCSI2SD) which directly links to the ZuluSCSI V6.4 as the "direct successor". I didn't come to realize that there were other models (the naming convention of the ZuluSCSI being a newer "version number" than the version of the RP2040 or "base" ZuluSCSI hardware certainly doesn't help the confusion) until after I had the device and was trying to use it, and came across a ton of documentation that didn't seem to match the product I was trying to use.

I have been using the utility linked on the product page for the ZuluSCSI V6. I am not convinced that, with the V6, _any_ images need to be created on the SD card as of yet, nor that writing any data to the SD card manually even affects how the ZuluSCSI works. I've emailed the folks at rabbit hole computing to see if they have some more comprehensive docs for the thing as well as with a few sanity test questions. Will post any interesting content from that response here.

I'm also not ruling out the possiblity here that my specific device was DoA or has some deeper issue. The fact that my machine sees the SCSI devices and reports the correct block size of each (even when the SD card is completely empty) as I've been testing tells me at the very least that setting the properties via the utility is doing _something_. Based on context clues I think it's writing that configuration into the last two blocks on the SD card, rather than some sort of EEPROM or other non-volatile storage on the device. My current hypothesis is that the V6 uses the SD card as arbitrary block storage and handles the SCSI translation and offsetting of the blocks to the configured regions on the card, and cares not at all what might be on that card in terms of a filesystem or other image files.

That's why I made my original comment. I believe you are trying to do a mix of the two configuration strategies. Again, I've never used a SCSI2SD, but I believe it uses the SD card as a raw device. The ZuluSCSI 2040 (and 2040 BlueSCSI) work by using the SD card as a file system with disk images on it (and are much easier to configure as a result).

I would try following Sophie's guide.

[zthart]

I have only tried to do a mix of any configuration settings as last-resorts/debugging after getting details from folks in this thread. My original attempts to get things working started with a completely zeroed SD card and ZuluSCSI configuration set by the utility. From my original post I indicated I was pretty certain that setting images up was not the correct way to use the V6, only to be told it actually was, and then maybe actually no it isn't. I thought perhaps I had done something wrong, but I think at this point it's either an issue with my ZuluSCSI being faulty, or a firmware bug.

I am using the latest ZuluSCSI firmware, I am using the ZuluSCSI utility linked from the product page. I am not having issues starting `fx` or trying to netboot or anything like that. I just can't write any data and even if I _manually_ partition the SD card to get around `fx` being unable for some reason, IRIX installation fails and reports the filesystem is read-only.

I think at this point unless someone has experienced my specific issue I'll wait for a reply from the RHC folks, I can't imagine there's another permutation of settings/debugging I can do that I haven't tried already.

[zthart]

Quick update, I have resolved my issues here. The root cause was a hardware issue with the ZuluSCSI - I reached out to the creator and got it sorted with them. In my case it required a quick bodge on the PCB. I am not sure if this is a one off issue for me, if the hardware revision I received has a bug, or what the case is. For folks that stumble on this in the future, my suggestion is just to reach out to RHC - your issues may be different than mine, ymmv, etc.

If you are having issues where it appears your devices are read-only using the ZuluSCSI V6:

• Reach out to the project creators at Rabbit Hole Computing to get it sorted
  

To be clear:

• The ZuluSCSI V6 does not require any special formatting of your SD Card
  
• The ZuluSCSI V6 does not require you create appropriately-named image files on your SD card on another machine
  
• The ZuluSCSI V6 is entirely configured by the utility linked on it's product page at the RHC store
  
• The ZuluSCSI V6 does not work like the ZuluSCSI RP2040 or the ZuluSCSI V1.2 - the V6 means it's a successor to the SCSI2SD V6, not a new hardware revision of other ZuluSCSI models.
  

If you are struggling with the ZuluSCSI V6, make sure that you aren't following a guide for another model of the ZuluSCSI - guides for the SCSI2SD V6 will be more accurate.

[ChuckSharts]

For anyone having this same issue, here is how I fixed it. 
I desoldered the write protect pin from the SD card socket and jumped it to ground. You might can try just jumping it to ground though.



I have had to do this on multiple of these zuluscsi 6.4s but after that they work great. They have even worked with my older scsi2sd v6 SD cards innately.