On 20/10/2024 00:02, Stefan Monnier wrote:
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
ID 8564:1000 Transcend Information, Inc. JetFlash
[...]
|__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
ID 090c:3265 Silicon Motion, Inc. - Taiwan (formerly Feiya
Technology Corp.)
Hmm... I'm way out of my depth here, but the one thing that I notice
that the the Transcend state is using USB3 (hence xHCI) whereas the
Silicon Motion state uses USB2 speed (and presumably the EHCI).
Thank you for the hint. My laptops have 2 USB3 ports and 1 USB2 one. I
tried both options since USB2 port circuits have something special
related to provided power. I have not tried USB-C in the newer one though.
It seems, attempt of booting live system is a reliable way to put the device
into its "Silicon Motion" state.
My guess is that the boot code (BIOS? Grub?) doesn't support USB3 (it
doesn't have a driver for the xHCI controller, only for the EHCI
controller).
It seems grub uses UEFI driver:
grub> probe --driver (hd0,msdos1)
efidisk
I have no idea how to get more info from grub. Time required by md5sum
commands suggests that UEFI likely uses USB2 mode. Reading speed is 100
MB/s in the case of USB3 and just 30 MB/s when the stick is plugged into
a USB2 port.
UEFI has no problem to read grubx64.efi while the drive is in its
Transcend role, it does not matter if it is connected into a USB2 or a
USB3 port.
Browsing directories using "Boot From EFI File" UEFI menu is not enough
to switch drive mode to SMI (both USB2 and USB3).
Grub have no problem to read files from Transcend (again in USB2 or USB3
ports).
Booting grub from an *internal* drive when the USB is plugged into a
USB2 port causes SMI mode when kernel is booted. The state is preserved
after hot reboot.
Just booting grub from internal drive in the case of a USB3 port does
not cause switch from Transcend to SMI for Linux kernel. Reading a
*small* file located at the pen drive from grub prompt does not make any
harm as well
grub> md5sum (hd0,msdos1)/md5sum.README
However reading a larger file
grub> md5sum (hd0,msdos1)/EFI/boot/grubx64.efi
causes SMI mode when kernel is booted up.
Most curious case: a USB3 port for the stick and grub is loaded from it.
Linux kernel loaded from an internal drive sees it as Transcend ...
unless I run "md5sum (hd0,msdos1)/EFI/boot/grubx64.efi" (or some other
large enough file). Notice that UEFI reads this file earlier to boot
grub, so it sounds like some interference of Transcend firmware and grub
efidisk driver.
Finally
usb usb3-port1: unable to enumerate USB device
error reported only in the case of a USB3 port. As I wrote above, once
switched to SMI zero size disk, it remains the same after Linux hot
reboot when connected to a USB 2 port.
On 20/10/2024 14:32, Thomas Schmitt wrote:
Somewhat undisciplined usage of the Id 8564:1000 can be seen at:
https://flashboot.ru/iflash/page45/
Search gives dozens of records for this vid:pid pair. My device is
Transcend JetFlash 700 USB 3.1 128 GB (TS128GJF700). I suspect even the
same model may have variety of chips and firmware versions.
My feeble theory is that the booting software issues some kind of reset
which makes the USB stick's firmware forget its commercial vendor and lets
it fall back to its manufacturing vendor. Further it forgets how to deal
with Linux.
I am curious if it is possible to change device mode by some reset-like
command while Linux kernel is booted up. It would eliminate variant with
peculiar interaction of UEFI and grub efidisk driver bugs.
I have no hope that this USB stick may be used for a Linux live or
install images.
