On 5/21/20 2:41 PM, Bjorn Andersson wrote:
On Thu 21 May 12:29 PDT 2020, Suman Anna wrote:
On 5/21/20 2:21 PM, Bjorn Andersson wrote:
On Thu 21 May 12:06 PDT 2020, Suman Anna wrote:
Hi Bjorn,
On 5/21/20 12:54 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:46 PDT 2020, Suman Anna wrote:
The current remoteproc core has supported only 32-bit remote
processors and as such some of the current resource structures
may not scale well for 64-bit remote processors, and would
require new versions of resource types. Each resource is currently
identified by a 32-bit type field. Introduce the concept of version
for these resource types by overloading this 32-bit type field
into two 16-bit version and type fields with the existing resources
behaving as version 0 thereby providing backward compatibility.
The version field is passed as an additional argument to each of
the handler functions, and all the existing handlers are updated
accordingly. Each specific handler will be updated on a need basis
when a new version of the resource type is added.
I really would prefer that we add additional types for the new
structures, neither side will be compatible with new versions without
enhancements to their respective implementations anyways.
OK.
An alternate way would be to introduce the new types as completely
new resource types which would require additional customization of
the resource handlers based on the 32-bit or 64-bit mode of a remote
processor, and introduction of an additional mode flag to the rproc
structure.
What would this "mode" indicate? If it's version 0 or 1?
No, for indicating if the remoteproc is 32-bit or 64-bit and adjust the
loading handlers if the resource types need to be segregated accordingly.
Sorry, I think I'm misunderstanding something. Wouldn't your 64-bit
remote processor need different firmware from your 32-bit processor
anyways, if you want to support the wider resource? And you would pack
your firmware with the appropriate resource types?
Yes, that's correct.
Afaict the bit width of your remote processor, busses or memory is
unrelated to the choice of number of bits used to express things in the
resource table.
I would have to add the new resource type to the loading_handlers right, so
it is a question of whether we want to impose any restrictions in remoteproc
core or not from supporting a certain resource type (eg: I don't expect
RSC_TRACE entries on 64-bit processors).
Right, but either you add support for new resource types to the
loading_handlers, or you add the version checks within each handler,
either way you will have to do some work to be compatible with new
versions.
Regarding what resources would be fit for a 64-bit processor probably
relates to many things, in particular the question of what we actually
mean when we say that a coprocessor is 64-bit. So I don't really see a
need for the remoteproc core to prevent someone to design their
system/firmware to have a 64-bit CPU being passed 32-bit addresses.
OK. In general, I have seen firmware developers get confused w.r.t the
resource types, that's why I was inclined to go with the restrictive
checking. Anyway, will rework the support as per the comments.
regards
Suman
