Remoteproc driver fails to launch firmware on first start - fix in description

[queenkjuul]

I don't know where else to provide this information.

I've been working on getting Linux 7.0 running on all 3 Duo boards. I've got all of the supported peripherals working, but I found (and fixed) a bug in the remoteproc driver.

The first time the system calls start(), it fails. Every time. If you call start then stop then start again, everything works normally on that second start.

The solution that worked for me was to add a reset_control_assert call to the probe function - this effectively is the same as calling stop, and it ensures the reset is in the right state for the initial start call.

From f08b82da7721cda7c39fdc3bdb4f322d8ba1775e Mon Sep 17 00:00:00 2001
From: queenkjuul <queenkjuul@pm.me>
Date: Sat, 25 Apr 2026 22:32:55 +0000
Subject: [PATCH] drivers: remoteproc: fix C906L probe function

---
 drivers/remoteproc/sophgo_cv1800b_c906l.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/remoteproc/sophgo_cv1800b_c906l.c b/drivers/remoteproc/sophgo_cv1800b_c906l.c
index 42258f072619..3b6023e6c0b1 100644
--- a/drivers/remoteproc/sophgo_cv1800b_c906l.c
+++ b/drivers/remoteproc/sophgo_cv1800b_c906l.c
@@ -201,6 +201,10 @@ static int cv1800b_c906l_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(priv->reset),
 				     "failed to get reset control handle\n");
 
+	// if reset isn't asserted during probe,
+	// the first call to start() will always fail
+	reset_control_assert(priv->reset);
+
 	platform_set_drvdata(pdev, rproc);
 
 	ret = devm_rproc_add(dev, rproc);
-- 
2.34.1

[unicornx]

An interesting question: on which version did you test it? I checked the latest master branch and didn't find the file "sophgo_cv1800b_c906l.c".

Also, if you've looked at https://github.com/sophgo/linux/wiki, you'll see that the remoteproc driver hasn't been accepted by upstream.

Perhaps you could contact the person (Junhui Liu junhui.liu@pigmoral.tech) who submitted the remoteproc driver patch for further discussion, or you could ask him if he'd be willing to continue. If he is unwilling, you could also take over.

Thanks,
Chen

[queenkjuul]

Ah, yes, this is one of the proposed drivers, not an accepted driver. I am not familiar with the etiquette around reaching out to someone directly like that, so I thought I would start with a github issue. I do not think I am familiar enough with C programming to take over, I just found a simple bug and wanted to share the solution.

I can reach out to Junhui directly, then.