XPost: alt.comp.os.windows-11   
   From: nospam@needed.invalid   
      
   On Fri, 4/4/2025 6:16 AM, Carlos E.R. wrote:   
   > On 2025-04-04 11:36, Carlos E.R. wrote:   
   >> On 2025-04-04 05:33, Paul wrote:   
   >>> On Thu, 4/3/2025 8:39 PM, Carlos E.R. wrote:   
   >>>> On 2025-04-03 23:47, Paul wrote:   
   >>>>> On Thu, 4/3/2025 4:01 PM, Carlos E.R. wrote:   
   >>   
   >> ...   
   >>   
   >>>> Sigh.   
   >>>>   
   >>>>   
   >>>> So you think this is a firmware issue, and nothing can be done on the   
   Linux side?   
   >>>>   
   >>>   
   >>> It would seem "the underground" is distributing various firmwares for   
   >>> this thing. Maybe the SPI bus really does have a firmware capability   
   >>> to "fix" the stupid thing ? The architecture document isn't exactly honest   
   >>> about this.   
   >>>   
   >>> jms578fwupdater.tgz   2,089,194 bytes   
   >>>   
   >>>       JMS578FwUpdate   4,130,828 bytes   
   >>>   
   >>> I guess that means some of the devices, have a 4MB SPI flash chip.   
   >>> and that's where the firmware is stored or something. THis could be   
   >>> a small 8 pin DIP near the JMB578 on the circuit board.   
   >>>   
   >>> I don't like to quote "sources" for things like this, unless   
   >>> there is some sort of traceability for them.   
   >>>   
   >>> The firmware may have been written by JMicron, but JMicron are   
   >>> not likely to be serving the file like a RealTek might.   
   >>>   
   >>> And since it's a flasher-firmware thing, the OS firmware support   
   >>> is not of the same delivery type (some devices accept dynamic   
   >>> firmware which is stored in device RAM). This would be a firmware   
   >>> that is stored in  an outboard chip from the JMS578. It fixes issue   
   >>> such as TRIM, UASP diaablement, proper support of power saving,   
   >>> and so on.   
   >>>   
   >>> The work you are doing, is similar to the work an enclosure   
   >>> engineer might do, before shipping this project. Each user   
   >>> apparently expected to "sweep the web", "look for bootleg firmware",   
   >>> "install" and "hope for the best". A science project.   
   >>   
   >> That's out of my league :-(   
   >   
   > I also asked on the openSUSE mail list, and a chap named Bengt said:   
   >   
   > +++·····················   
   > I have no experience with this device but it seems like others are having   
   problems as well with idVendor=152d, idProduct=0578 (JMicron Technology JMS578   
   SATA 6Gb/s)   
   >   
   > https://linux-hardware.org/?id=usb:152d-0578   
   > ·····················++-      
      
   It is not the "device" you have to worry about, it is   
   the firmware load that makes a difference.   
      
   As long as JMicron do not list the firmware(s) they   
   have as part of their production (RAID, non-RAID,   
   frame-based switching, enclosure-handling), it is hard to know precisely   
   how many firmware types there are to choose from, and   
   whether a different one would work better.   
      
   You would expect some enclosure management support. Some   
   units have a LED per drive, and maybe the controller chip   
   can communicate with the mux and light the lights it wants   
   to light.   
      
   Another form of input the controllers had in the past,   
   was mode switches, you could select JBOD, RAID0, RAID1, RAID10   
   with a couple DIP switches on the enclosure. And the firmware   
   would read those and operate the disks (with metadata written on them)   
   accordingly. Like if one drive is the odd drive, the other the even   
   drive, your clusters or inodes end up in the correct order,   
   each time the enclosure boots.   
      
   You can do a JBOD, and run a softRAID on top of them, which I gather   
   was your plan, until the drives did not behave themselves.   
      
      Paul   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)