- Marca 📱
- Oppo / Vivo / Realme
- Modelo 🔖
- Realme GT Neo 2 RMX3370
- 📱 Android / Sistema operativo
- No indicado en esta prueba
- Tipo de falla / servicio 🛠️
- Software / Firmware (flasheo, sistema, errores)
- 🔧Herramienta utilizada
- otra | Otra herramienta
- Estado del equipo 📋
- Modo EDL / Qualcomm HS-USB 9008
- ¿Problema resuelto?
- si | ✅ Resuelto
Dejo otro detalle que puede servir a quien use Windows 11 ARM para trabajar con Qualcomm EDL.
En mi caso estoy usando Windows 11 ARM dentro de VMware Fusion en un Mac Apple Silicon y trabajando con un Realme GT Neo 2 RMX3370.
Cuando entré el teléfono en EDL, Windows inicialmente lo mostraba como:
`QUSB_BULK`
Al principio probé a asociarlo con WinUSB usando Zadig, pero en mi caso no era lo que necesitaba la herramienta de RMX3370 que estaba probando.
Quité la asociación WinUSB e instalé el driver USB ARM64 de Qualcomm.
Después de eso apareció correctamente en el Administrador de dispositivos como:
`Qualcomm HS-USB QDLoader 9008 (COM3)`
El número COM puede cambiar. Lo importante es que aparezca como `QDLoader 9008`.
Con eso la herramienta de Windows pudo detectar el teléfono por COM3.
Un detalle importante es que aparecer correctamente como `Qualcomm HS-USB QDLoader 9008` solo confirma que la parte USB/driver está funcionando.
En mi caso, la herramienta de Windows detectaba COM3 pero fallaba al intentar enviar:
`prog_firehose_ddr4_fwupdate.elf`
El teléfono seguía en EDL.
Más tarde probé ese mismo loader desde macOS con bkerler/edl y Firehose sí inició correctamente.
Así que en este caso el fallo de la herramienta Windows no significaba que el loader estuviera dañado.
Para diagnosticar este tipo de problemas separaría las dos cosas:
1. `QUSB_BULK` → revisar primero el driver.
2. `Qualcomm HS-USB QDLoader 9008 (COMx)` → la enumeración USB/EDL ya funciona.
3. Si después falla Sahara/Firehose → revisar la herramienta y la compatibilidad del loader por separado.
Puede ahorrar bastante tiempo porque un fallo de Firehose y un problema de driver USB no son lo mismo.
En mi caso estoy usando Windows 11 ARM dentro de VMware Fusion en un Mac Apple Silicon y trabajando con un Realme GT Neo 2 RMX3370.
Cuando entré el teléfono en EDL, Windows inicialmente lo mostraba como:
`QUSB_BULK`
Al principio probé a asociarlo con WinUSB usando Zadig, pero en mi caso no era lo que necesitaba la herramienta de RMX3370 que estaba probando.
Quité la asociación WinUSB e instalé el driver USB ARM64 de Qualcomm.
Después de eso apareció correctamente en el Administrador de dispositivos como:
`Qualcomm HS-USB QDLoader 9008 (COM3)`
El número COM puede cambiar. Lo importante es que aparezca como `QDLoader 9008`.
Con eso la herramienta de Windows pudo detectar el teléfono por COM3.
Un detalle importante es que aparecer correctamente como `Qualcomm HS-USB QDLoader 9008` solo confirma que la parte USB/driver está funcionando.
En mi caso, la herramienta de Windows detectaba COM3 pero fallaba al intentar enviar:
`prog_firehose_ddr4_fwupdate.elf`
El teléfono seguía en EDL.
Más tarde probé ese mismo loader desde macOS con bkerler/edl y Firehose sí inició correctamente.
Así que en este caso el fallo de la herramienta Windows no significaba que el loader estuviera dañado.
Para diagnosticar este tipo de problemas separaría las dos cosas:
1. `QUSB_BULK` → revisar primero el driver.
2. `Qualcomm HS-USB QDLoader 9008 (COMx)` → la enumeración USB/EDL ya funciona.
3. Si después falla Sahara/Firehose → revisar la herramienta y la compatibilidad del loader por separado.
Puede ahorrar bastante tiempo porque un fallo de Firehose y un problema de driver USB no son lo mismo.
