I am currently working with a Quectel RM520N-GL module on a Raspberry Pi (ARM-based Linux) and I am experiencing an issue with eSIM provisioning.
My current firmware version is:
RM520NGLAAR03A03M4G_JP_01.202.01.202
When attempting to provision an AT&T eSIM via AT commands, I am able to successfully enable the LPA with AT+QESIM=“lpa_enable”,1, however AT+QESIM=“eid” returns ERROR, which is blocking me from retrieving the EID and proceeding with eSIM profile download.
I would like to request the latest firmware for the RM520N-GL that fully supports the AT+QESIM command set, specifically the “eid” and profile management commands. I understand that for ARM-based Linux, drivers may need to be cross-compiled.
Could you please provide:
The latest stable firmware for the RM520N-GL (R03 baseline)
The appropriate flashing tool for ARM-based Linux (QFirehose)
Dear @urielmendez911
I have sent to your email, please check.
Your current firmware supports eSIM, but you need a tool to download eSIM profile, we don’t have permission to release it, please contact with your supplier to get it.
Current firmware (AT+QGMR): RM520NGLAAR03A04M4G_01.202.01.202 (RM520N-GL, R03A04).
For additional context, in case it helps others:
on PCIe (SoC RK3566 / DesignWare controller, kernel 6.6), the link trains to L0 and the host enumerates the modem (17cb:0308); MHI powers on (“Power on setup success”), but the link then drops at the Data Link layer and the host reports MHI did not load image over BHI, ret: -5 - The modem never leaves EE:PBL.
USB mode works fully on the same board, and the same module is documented working over PCIe on other hosts (e.g. Raspberry Pi 5 / Broadcom, NVIDIA Tegra), which points to a host root-complex interaction rather than the module itself.
Given that, could you please share:
the latest RM520N firmware;
the latest ARM-Linux PCIe MHI driver, if available; and
any known host root-complex requirement for the SDX62 MHI boot (e.g. Data Link Feature / DLF handling)?
One correction on my DLF mention: I checked our root port, and RK3566 is a Gen2 (PCIe 2.1) controller with no Data Link Feature ext-cap at all, so DLF isn’t applicable on our side. Ruling it out; my mistake
So, the sharper failure signature: the link reaches L0 and the host reads BHI (“Power on setup success”), but L0 only holds for tens of ms (up to ~87 ms) before the link falls all the way to LTSSM Detect (dbi_link_up=0), which is a clean teardown, zero AER errors. The host arms the MHI MSI vectors (1 BHI + 6 event-ring) but not one ever fires before the link is gone, so the modem never leaves EE:PBL and BHI times out (ret -5).
So the real question, if you could please help and / or point me in the right direction: For this device, at PBL, what does the SDX62 expect the host to complete over PCIe in that first ~tens-of-ms window before it will hold the link - a specific MHI/BHI register write, an MSI/doorbell ack, an EE poll response? A pointer to the expected host-side PBL→BHI handshake sequence, or the ARM-Linux PCIe MHI driver that implements it, would be a huge help.
I am currently facing some interruptions when using PCIe and reading this thread, a firmware update seems hopeful. Could you please share the latest firmware with me? If needed, I can provide the serial number of the module.