Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756473Ab2HFOQk (ORCPT ); Mon, 6 Aug 2012 10:16:40 -0400 Received: from mail-vc0-f174.google.com ([209.85.220.174]:39754 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756375Ab2HFOQj (ORCPT ); Mon, 6 Aug 2012 10:16:39 -0400 MIME-Version: 1.0 X-Originating-IP: [46.116.151.238] In-Reply-To: <1344237865-32491-1-git-send-email-roylee17@gmail.com> References: <1344237865-32491-1-git-send-email-roylee17@gmail.com> From: Ohad Ben-Cohen Date: Mon, 6 Aug 2012 17:16:18 +0300 Message-ID: Subject: Re: [PATCH 1/1] remoteproc: extend customized fw loader to cover request and release To: Tzu-Jung Lee Cc: "linux-kernel@vger.kernel.org" , =?ISO-8859-1?Q?Sjur_Br=E6ndeland?= , Stephen Boyd , Fernando Guzman Lugo , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2554 Lines: 62 Hi Tzu-Jung Lee, On Mon, Aug 6, 2012 at 10:24 AM, Tzu-Jung Lee wrote: > Previously, the remoteproc mandates an actual ELF firmware in order to > parse the resource table and boot the remoteproc. > > An fw loader abstraction was added in v3.61-rc1 to make the ELF as a > "default" handler, and allows firmwares in other formats to be loaded. > > However, in our use cases, we don't actually have a firmware for linux > to load. The remote processor always boots first, and then boots the > rest of processors that running linux. Can you describe your use case some more ? What parts in remoteproc are actually helpful for you (not much I guess if Linux doesn't control the life cycle of the remote processor in your case) ? Do you use rpmsg ? > In this case, forging an binary firmware just for the resource table > creates a burden for maintenence. > Allowing the firmware request/release function to be customized gives > developers to construct the reqource table in memory, instead of loading > one from filesystem. I'm not sure this is an ideal abstraction though. The problem you describe is architectural and not necessarily related with a specific binary format, which this patch ties it up with (by abstracting it away in rproc_fw_ops). It seems that a binary-format-agnostic solution is preferable, because it could then be utilized by any platform, regardless of the binary format it uses. In general we prefer not to adopt a solution that puts the resource table in the kernel, because that means redundant churn and compatibility issues, as the resource table is inherently coupled with the software running on the remote processor, and not with the Linux kernel. An easy solution is to allow loading an external stand-alone resource table from the filesystem. We've discussed this in the past and several parties showed interest. Will it help you ? Another possible solution is to allow the low level rproc driver to provide the remoteproc framework a pointer to an in-memory resource table. This may prove useful in case the remote processor is already up when Linux boots, and the resource table is already loaded to memory. > Change-Id: I0aa071dc1bd775eed6ea0822cff0fe2fc1b12b45 PS - no need to provide these tags when sending patches upstream. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/