Thanks Jerin. This is something we can perhaps discuss in more detail during next week's ODP call and/or at LCU. The ODP design point is multicore SoCs where at least one processor can run Linux. It's quite reasonable to expect that many SoCs will have a "main" core that has Linux capabilities that serves to "launch" threads on other bare-metal cores. We may wish to examine the naming of some of the existing APIs to make them more odp-centric but I'd view bare-metal as essentially another runtime variant.
You're also correct that a number of the existing examples assume Linux simply because that enabled easier development. Over time I'd expect a richer set of examples to be incorporated into the examples directory that would illustrate other environments. Do you have a suggested one for illustrating your environment? Bill On Wed, Sep 3, 2014 at 5:14 AM, Maxim Uvarov <[email protected]> wrote: > Hello Jacob, > > that is interesting. Sound linke not huge work is needed. But in your case > you need to implement > separate "odp platform" which will use Cavium specific things instead of > linux-generic. > > I also have some notes bellow. > > > On 09/03/2014 11:49 AM, Jacob, Jerin wrote: > >> All, >> >> We have tried to add ODP bare-metal support for Cavium SoC to find the gap >> in ODP mainline API definition for bare-metal run-time environment >> support. >> >> I would like to share the findings so that we can discuss and going >> forward we can >> incorporate those gaps in ODP API definition and have bare metal support >> in ODP. >> >> Following are the details: >> >> 1) Generic ODP API to launch the work on selected cores. >> Currently applications are using odp_linux_pthread_create/odp_ >> linux_pthread_join >> API's to do the same. Which needs to changed to generic ODP API. >> >> Expectation: >> Function "main" in the app shall be invoked by the root core and >> other core shall be launched by the root core using ODP API. >> > > That might be good catch. We do cpu isolation for odp process in linux. > But still did not define > proper set up for this. Or script will isolate core and then we need odp > app moved to that specific > core or we do everything in odp app. In you particular case I think it's > reasonable to send patch > for this and we can discuss how is that suitable for other SoC. > > > 2) ODP API's support command line parsing. >> If an ODP application demands for more sophisticated command line parsing >> (can not be achieved through getopt*) then I think >> we should have dedicated ODP API's for command line parsing like dpdk. >> > > Does patch "[v5] Add-global_init-paramiters" solve your problem? > https://patches.linaro.org/36509/ > > > 3) Changes in configure.ac >> Need an additional configure option to skip checking the linux specific >> libraries in configure.ac >> > > That is fine. Do not see any problem with changing configure.ac or moving > it's parts > to platform specific folder. > > > 4) Avoid using global variables in odp application for sharing >> the data between cores. >> > > Not sure that I understand that. Are you saying about reserving memory > blocks > with different names for all application instances? > > Best regards, > Maxim. > > > Any thoughts ? >> >> - Jerin. >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
