Failure on JMS583

[jaredmauch]

while writing out JMS567_SSI_v20.06.00.01.bin to a USB device I received the following bug/traceback

python3 jms567ctl.py -d /dev/sda write_flash JMS567_SSI_v20.06.00.01.bin 
Opening block device /dev/sda...
Reading firmware version...
Traceback (most recent call last):
  File "/home/jared/jms567ctl/jms567ctl.py", line 388, in <module>
    main()
  File "/home/jared/jms567ctl/jms567ctl.py", line 344, in main
    print("Firmware version: " + ".".join(str(f) for f in intf.firmware_version()))
                                                          ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jared/jms567ctl/jms567ctl.py", line 197, in firmware_version
    info = self.chip_info()
           ^^^^^^^^^^^^^^^^
  File "/home/jared/jms567ctl/jms567ctl.py", line 192, in chip_info
    return self._c.read(cmd, 16)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/jared/jms567ctl/jms567ctl.py", line 65, in read
    return py3_sg.read_as_bin_str(self.f, scsi_cmd, read_len, 1000)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
py3_sg.SCSIError: (0, 1, 0, '')

the existing firmware/device identifies as:

./jms567ctl.py -d /dev/sda chip_info
Opening block device /dev/sda...
Reading firmware version...
Firmware version: 0.2.0.4
Chip info: f4e7152d058310013538333100020004
Done

with the following kernel messages as the device is inserted:

[  484.125999] usb 4-1: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd
[  484.151887] usb 4-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.04
[  484.152730] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  484.153558] usb 4-1: Product: External
[  484.154452] usb 4-1: Manufacturer: JMicron
[  484.155423] usb 4-1: SerialNumber: DD56419883893
[  484.163227] scsi host2: uas
[  484.164748] scsi 2:0:0:0: Direct-Access     JMicron  Tech             0204 PQ: 0 ANSI: 6
[  484.168313] sd 2:0:0:0: Attached scsi generic sg0 type 0
[  486.044539] sd 2:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[  486.045370] sd 2:0:0:0: [sda] 4096-byte physical blocks
[  486.046399] sd 2:0:0:0: [sda] Write Protect is off
[  486.047222] sd 2:0:0:0: [sda] Mode Sense: 5f 00 00 08
[  486.047562] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  486.048571] sd 2:0:0:0: [sda] Preferred minimum I/O size 4096 bytes

the existing firmware from a read_firmware md5sum is as follows with the md5sum as well of the image I was attempting to write out - it doesn't seem to erase/write at all.

# md5sum saved_firmware.bin JMS567_SSI_v20.06.00.01.bin
1d0f14ad2c245fb2da5dabe40b826974  saved_firmware.bin
5040755ab414982cc76a79bbbca728fe  JMS567_SSI_v20.06.00.01.bin

[projectgus]

Hi @jaredmauch,

Thanks for sending this in.

A weird thing, the failure stack trace happens while reading the firmware version before the tool has tried any flash operations. The same request is sent for every command, but in the case of chip_info and read_flash they seem to have succeeded.

If you power cycle the enclosure and try writing again, does it behave any differently?

[jaredmauch]

This isn't actually an enclosure but a USB <-> M2 adapter i can find it in my purchase history or post a photo, but it's basically a bare exposed PCB w/ NVME on it

[projectgus]

Oh, interesting! I guess same question, though - if you try power cycling it and writing flash immediately, does it get any further than the stack trace you sent?

[jaredmauch]

yeah, i beat on it pretty hard with a lot of different tools, I'm wondering if it actually has a user updatable flash area or if it's fixed, i tried it in both arm(pi5) and x86 hardware to see if there was some endian related issues as well. The Nvme is a WD SN 530 2240 and the adapter is https://www.amazon.com/gp/product/B07JKWHFRC/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

[jaredmauch]

Ok the plot thickens, while it presents as: Bus 001 Device 003: ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

A photo of it shows JMS583 on the chip

[projectgus]

Ah OK, if this is a different USB/NVMe chip then it might use a different protocol - it's clearly very similar, but hardware companies often tweak details as they move forward. You might need to do some reversing/development work to use this tool with it.

There is almost certainly a flash chip visible in one of the photos on Amazon, it's the 8-pin SOIC package next to the bigger JMS chip.

[projectgus]

There is almost certainly a flash chip visible in one of the photos on Amazon, it's the 8-pin SOIC package next to the bigger JMS chip.

Hmm, actually it's hard to tell as they've photoshopped an arrow on top of it but it might be the power supply chip instead.

If you have a high res photo of the real board then I'd be curious to take a look at it for you, but would also understand if this is the end of the line for now. :)

[jaredmauch]

Ok, I'm doing a bit more digging into things as I have another device that also looks to be a 583 - What I'm seeing is that when the firmware is more than 65536 in size that might get written out there's some underlying issues. I'm willing to pop the chips off and read them in another device as I have flash and ability to rework the PCBs (but time is somewhat limited so this went on the back burner for a bit)

Here's a slightly different board that also has slightly different layout: (https://amzn.to/3OPEahN)

This one seems to have the FM25Q0 SOIC-8

FM25Q08.PDF

I'm also going to look at the pin header to see if it's actually a TTL console port for the 563 which may provide a path to debug further what is going on

[projectgus]

Good luck, interested to see where you get to!

I think most likely there will be some small difference(s) in the USB protocol for JMS583 compared to 567. The most direct way to update this tool is probably to get a USB packet capture from an official updater and reverse engineer from there, but it's a bit of a pain.