On Thu, Oct 01, 2026 at 10:42:39AM +0200, Konrad Dybcio wrote: > On 9/30/26 4:07 AM, Shawn Guo wrote: > > Qualcomm NHLOS team changes XBL for Nord IOT/Embedded variant, leaving > > ADSP to be powered up by Linux remoteproc, so that Nord IQ10 Qualcomm > > Linux (QLI) behavior gets aligned with IQ8/9. Drop early_boot flag from > > Nord ADSP for that purpose. > > > > Signed-off-by: Shawn Guo <[email protected]> > > --- > > What happens if this patch is absent?
ADSP never comes up: remoteproc remoteproc0: attaching to adsp remoteproc remoteproc0: can't attach to rproc adsp: -19 Since XBL no longer boots ADSP, the remote never publishes its SMP2P inbound item. The smp2p entry stays unmapped, and irq_get_irqchip_state() on fatal_irq returns -ENODEV. qcom_pas_attach() treats that as a hard error rather than falling back to a firmware boot. Even the existing fallback (ready bit clear -> RPROC_OFFLINE) doesn't work: rproc_boot() takes the attach branch, sees the error and returns without loading firmware. > > When the early_boot path was first introduced I was really hoping > that this behavior could be made unconditional and Linux would > figure out if the rproc may be active by virtue of it sending > back signals or not, unfortunately that hasn't made it into the > tree.. The difficulty is with the positive signal. As Stephan pointed out [1], the ready bit is not cleared when the remote is stopped or force-shutdown, so a stop followed by rmmod/modprobe of qcom_q6v5_pas makes the driver attach to a remote that is not running. Without ping-pong or a PAS query for the remote state, I don't think we can reliably say that a remote *is* running. The negative signal is reliable though. The -ENODEV from irq_get_irqchip_state() means the remote has never populated its SMP2P entry since cold boot, so it cannot be running. We can fall back to a firmware boot in that case. early_boot then becomes a hint that the bootloader *may* have started the remote, which matches Nord ADSP: it is started by XBL on the Auto variant and by Linux remoteproc on the IoT variant. I'll drop this patch and send two patches instead: - remoteproc: core: continue to the firmware boot path when .attach() leaves the rproc in RPROC_OFFLINE - remoteproc: qcom: pas: treat -ENODEV from the SMP2P state read as "not running" and fall back to start With those, Nord ADSP keeps early_boot and I've tested it with both XBL variants. With the old XBL it attaches as before; with the new one it falls back to loading firmware. Shawn [1] https://lore.kernel.org/all/[email protected]/
