The sleep bug fix has nothing to do with mk. That's part of the 3.10 firmware that Asus put out. So I'm really not sure where you got that the mk patch has anything to do with that. The mk patch for the 3.10 firmware restores uhd friendly functionality and removes a new downgrade restriction that they added. That's it.
Ah sry I misundestood statement. Thx for explaining.
"
For BDXL compatible drives MK patch would re-enable ability to read UHD discs,
but it would not fix the "sleep" bug,
or any other firmware bugs. All MK patch does - it
makes the drive LibreDrive-compatible, nothing more."
(So the statements just says, that the Sleep Bug itself was not the fix by Mike, (ha
d been already fixed by the Asus 3.10 official update) whose such code Mike didn't change in his modified mk-firmware, just make the drive back
LibreDrive-compatible (possibly that kind of SPI-"block" they might introduce in new firmwares, s.th. you mentioned) to restore downgrade-option). (So the Sleep-Bug-fixes rests in mike's mk-firmware)
https://forum.redfox.bz/threads/dow...he-easy-and-safe-way.76551/reply?quote=498495
Yea, I think that's exactly what Mike is alluding to. Shutting off access to SPI in future firmware and/or drive revisions. For now, we're good and we should take advantage of this while we can. I flashed my ASUS drive natively to 3.02 (it came friendly and has always remained friendly) and my NS60 I downgraded with a DE enabled 1.00 cleaned firmware. I also dumped a full 1.01 bin using dosflash on the NS60 and a 3.02 bin on my ASUS just to have them. I'm not screwing around. My drives will stay as they are forever at this point. Once you have a friendly drive, you should leave it that way.
I fear my thing with the SPI-access might not correct. I don't really know what vendor-specific-commands are.
I'm just writing how I understood, if I misunderstood you'll clear it up.
Just remember s.th. with SCSI/ATAPI, SCSI-SAT-Layer or SCSI->ATA-passthrough, sg_utils Debian package how to access a SCSI/(+ATA?) and ATAPI devices.
sg_utils package to check what SCSI-commands (not sure if also ATA) an USB-UAS-SATA-bridge or SCSI/ATAPI devices support (eg for SCSI-unmap or ATA-TRIM or SCSI-unmap-ATA-TRIM conversion).
https://bbs.archlinux.org/viewtopic.php?id=236280
" sg_readcap -l /dev/sdX' and 'sg_vpd -a /dev/sdX' "
Read s.th. in combination if a USB-bridge supports vendor-commands.:
http://www.asmedia.com.tw/eng/e_show_products.php?item=133&cate_index=171
• Support ATA/ATAPI Packet Command Set
• Support ATA/ATAPI LBA48 addressing mode
• Integrated 8-bit micro-processor with embedded program RAM and ROM
• Support SPI NVRAM for Vender Specific Application of USB device Controller
---
I just mixed s.th. up. Got such thinking as you're accessing an ATAPI device, speaking SCSI-packet over ATA, and when accessing SPI-flash it goes over SATA-interface which speaks ATA (afaik) (like in IDE mode) and for ATAPI DVD/Blu-ray those SCSI commands over encapsulated SCSI-packets (over ATA-command set), also when accessing SPI flash.