- 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
Comparto unas pruebas que hice con un Realme GT Neo 2 RMX3370, Snapdragon 870 y almacenamiento UFS.
Mi equipo principal es un Mac con Apple Silicon y pude trabajar directamente en modo Qualcomm EDL/9008 utilizando `edl` de bkerler.
El loader que me funcionó fue:
`prog_firehose_ddr4_fwupdate.elf`
Para comprobar la comunicación y leer la GPT utilicé:
`edl printgpt --memory=ufs --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
En mi RMX3370 el Firehose inició correctamente, devolvió ACK y pude leer la GPT de los LUN 0 al 5.
Particiones que confirmé:
* `ocdt` → LUN 3 → 128 KiB
* `abl` → LUN 4 → 1 MiB
* `recovery` → LUN 4 → 128 MiB
* `misc` → LUN 0 → 1 MiB
* `modemst1` → LUN 5 → 2 MiB
* `modemst2` → LUN 5 → 2 MiB
* `fsg` → LUN 5 → 2 MiB
* `fsc` → LUN 5 → 128 KiB
Por ejemplo, para hacer copia de OCDT y ABL:
`edl r ocdt ocdt.img --memory=ufs --lun=3 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
`edl r abl abl.img --memory=ufs --lun=4 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
También pude generar los `rawprogram0.xml` hasta `rawprogram5.xml` a partir de la GPT.
Un detalle importante: las lecturas de `misc`, `modemst1`, `modemst2`, `fsg` y `fsc` me salieron completamente en `0x00`, así que no las considero copias válidas sin más comprobaciones.
En cambio:
* `ocdt` contenía datos y empieza por `DDCO`
* `abl` contenía datos y tiene cabecera ELF
Todo esto fue comprobado primero en lectura.
Lo comparto porque muchas guías de Qualcomm EDL están centradas en Windows/QFIL, y en este caso el RMX3370 funcionó correctamente por Sahara/Firehose directamente desde macOS Apple Silicon.
Si alguien tiene otro RMX3370 y puede comprobar si coincide la distribución de LUNs, estaría bien comparar resultados.Comparto unas pruebas que hice con un Realme GT Neo 2 RMX3370, Snapdragon 870 y almacenamiento UFS.
Mi equipo principal es un Mac con Apple Silicon y pude trabajar directamente en modo Qualcomm EDL/9008 utilizando `edl` de bkerler.
El loader que me funcionó fue:
`prog_firehose_ddr4_fwupdate.elf`
Para comprobar la comunicación y leer la GPT utilicé:
`edl printgpt --memory=ufs --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
En mi RMX3370 el Firehose inició correctamente, devolvió ACK y pude leer la GPT de los LUN 0 al 5.
Particiones que confirmé:
* `ocdt` → LUN 3 → 128 KiB
* `abl` → LUN 4 → 1 MiB
* `recovery` → LUN 4 → 128 MiB
* `misc` → LUN 0 → 1 MiB
* `modemst1` → LUN 5 → 2 MiB
* `modemst2` → LUN 5 → 2 MiB
* `fsg` → LUN 5 → 2 MiB
* `fsc` → LUN 5 → 128 KiB
Por ejemplo, para hacer copia de OCDT y ABL:
`edl r ocdt ocdt.img --memory=ufs --lun=3 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
`edl r abl abl.img --memory=ufs --lun=4 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
También pude generar los `rawprogram0.xml` hasta `rawprogram5.xml` a partir de la GPT.
Un detalle importante: las lecturas de `misc`, `modemst1`, `modemst2`, `fsg` y `fsc` me salieron completamente en `0x00`, así que no las considero copias válidas sin más comprobaciones.
En cambio:
* `ocdt` contenía datos y empieza por `DDCO`
* `abl` contenía datos y tiene cabecera ELF
Todo esto fue comprobado primero en lectura.
Lo comparto porque muchas guías de Qualcomm EDL están centradas en Windows/QFIL, y en este caso el RMX3370 funcionó correctamente por Sahara/Firehose directamente desde macOS Apple Silicon.
Si alguien tiene otro RMX3370 y puede comprobar si coincide la distribución de LUNs, estaría bien comparar resultados.
Mi equipo principal es un Mac con Apple Silicon y pude trabajar directamente en modo Qualcomm EDL/9008 utilizando `edl` de bkerler.
El loader que me funcionó fue:
`prog_firehose_ddr4_fwupdate.elf`
Para comprobar la comunicación y leer la GPT utilicé:
`edl printgpt --memory=ufs --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
En mi RMX3370 el Firehose inició correctamente, devolvió ACK y pude leer la GPT de los LUN 0 al 5.
Particiones que confirmé:
* `ocdt` → LUN 3 → 128 KiB
* `abl` → LUN 4 → 1 MiB
* `recovery` → LUN 4 → 128 MiB
* `misc` → LUN 0 → 1 MiB
* `modemst1` → LUN 5 → 2 MiB
* `modemst2` → LUN 5 → 2 MiB
* `fsg` → LUN 5 → 2 MiB
* `fsc` → LUN 5 → 128 KiB
Por ejemplo, para hacer copia de OCDT y ABL:
`edl r ocdt ocdt.img --memory=ufs --lun=3 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
`edl r abl abl.img --memory=ufs --lun=4 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
También pude generar los `rawprogram0.xml` hasta `rawprogram5.xml` a partir de la GPT.
Un detalle importante: las lecturas de `misc`, `modemst1`, `modemst2`, `fsg` y `fsc` me salieron completamente en `0x00`, así que no las considero copias válidas sin más comprobaciones.
En cambio:
* `ocdt` contenía datos y empieza por `DDCO`
* `abl` contenía datos y tiene cabecera ELF
Todo esto fue comprobado primero en lectura.
Lo comparto porque muchas guías de Qualcomm EDL están centradas en Windows/QFIL, y en este caso el RMX3370 funcionó correctamente por Sahara/Firehose directamente desde macOS Apple Silicon.
Si alguien tiene otro RMX3370 y puede comprobar si coincide la distribución de LUNs, estaría bien comparar resultados.Comparto unas pruebas que hice con un Realme GT Neo 2 RMX3370, Snapdragon 870 y almacenamiento UFS.
Mi equipo principal es un Mac con Apple Silicon y pude trabajar directamente en modo Qualcomm EDL/9008 utilizando `edl` de bkerler.
El loader que me funcionó fue:
`prog_firehose_ddr4_fwupdate.elf`
Para comprobar la comunicación y leer la GPT utilicé:
`edl printgpt --memory=ufs --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
En mi RMX3370 el Firehose inició correctamente, devolvió ACK y pude leer la GPT de los LUN 0 al 5.
Particiones que confirmé:
* `ocdt` → LUN 3 → 128 KiB
* `abl` → LUN 4 → 1 MiB
* `recovery` → LUN 4 → 128 MiB
* `misc` → LUN 0 → 1 MiB
* `modemst1` → LUN 5 → 2 MiB
* `modemst2` → LUN 5 → 2 MiB
* `fsg` → LUN 5 → 2 MiB
* `fsc` → LUN 5 → 128 KiB
Por ejemplo, para hacer copia de OCDT y ABL:
`edl r ocdt ocdt.img --memory=ufs --lun=3 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
`edl r abl abl.img --memory=ufs --lun=4 --loader="$HOME/Downloads/prog_firehose_ddr4_fwupdate.elf"`
También pude generar los `rawprogram0.xml` hasta `rawprogram5.xml` a partir de la GPT.
Un detalle importante: las lecturas de `misc`, `modemst1`, `modemst2`, `fsg` y `fsc` me salieron completamente en `0x00`, así que no las considero copias válidas sin más comprobaciones.
En cambio:
* `ocdt` contenía datos y empieza por `DDCO`
* `abl` contenía datos y tiene cabecera ELF
Todo esto fue comprobado primero en lectura.
Lo comparto porque muchas guías de Qualcomm EDL están centradas en Windows/QFIL, y en este caso el RMX3370 funcionó correctamente por Sahara/Firehose directamente desde macOS Apple Silicon.
Si alguien tiene otro RMX3370 y puede comprobar si coincide la distribución de LUNs, estaría bien comparar resultados.
