[okl4-developer] Fast and Optimized System StartUp / OKL4 in an automotive environment

[Geoffrey Lee]

On Tue, Jun 03, 2008 at 11:55:16PM +0530, G S Madhusudan wrote:
> Are there any plans to allow dynamic loading of apps at run time ?
> I am contemplating allowing hosting of 3rd party apps and dynamic loading of
> apps would be an ideal way to do it (shutting down the system is
> not an option).
> 
> There does not appear to be any fundamental arch issue that prevents
> such a feature from being added but then I have not studied the code long
> enough to know the low level design issues.

While there is no dynamic loading functionality in the current OKL4
release, one of the factors that drives features is market demand
so it may become available in a future release.

Loading native OKL4 applications dynamically is more involved than 
simply decoding an ELF file as multiple instances may need to be
started while at the same time satisfying single address space
requirements.

	-gl

> 
> Geoffrey Lee wrote:
> > On Tue, Jun 03, 2008 at 10:25:31AM -0700, Oliver Mayer-Buschmann wrote:
> >   
> >> Hello all,
> >>
> >>     
> >
> >
> > Hi Oliver
> >
> > You can strip it of non-essential features by passing 
> > OKL4_FEATURE_PROFILE=NORMAL to the build system.
> >
> > In addition if you are building for a production environment
> > you can compile with ENABLE_DEBUG=False which will result
> > in further space savings.
> >
> > As for your question on whether it is possible to load OK Linux 
> > dynamically at runtime, there is no support for dynamically
> > loading arbitrary OKL4 applications at runtime.
> >
> > 	-gl
> >
> >
> >   
> >> I'm wondering what the minimum binary file size of OKL4 is for ARM.
> >> I've build 2.1 for gumstix and ended with a binary size of 5324800 Bytes!
> >> After stripping, the corresponding elf file was only 329060 Bytes in size.
> >> Ok, it's not illogical, that the binary image might be bigger due to flat
> >> linking
> >> (I'm using "arm-linux-objcopy -O binary image.elf image.bin" to create the
> >> image).
> >> After checking the content with readelf, I found out, that bootinfo is
> >> linked to 0xa0510000
> >> (all other sections are linked from 0xa0000000 to 0xa00cd77c+0x003fc),
> >> so I thougth it might be worth just to remove bootinfo for testing the
> >> resulting size.
> >> I did this with "arm-linux-strip -R bootinfo image.new" and yes, now
> >> everything seemed to be linked compactly.
> >> But the size of the image did NOT downsize !!
> >>
> >> So what's the minimum size for an image? Wombat was not included, but
> >> including it, seemed not to make a major difference!
> >>
> >> Did anybody already try to put wombat in a socond image and reload it on
> >> runtime?
> >>
> >> Thx and greetings,
> >>
> >> Oliver
> >>
> >>
> >> Josh Matthews-5 wrote:
> >>     
> >>> Hi Oliver,
> >>>
> >>> On Fri, May 23, 2008 at 6:41 PM, Oliver Mayer-Buschmann
> >>> <omb at opensynergy.com>
> >>> wrote:
> >>>
> >>>       
> >>>> I'm interested in any available information about the dynamic and modular
> >>>> reload from flash.What kind of concepts are already implemented?
> >>>>
> >>>>         
> >>> Demand loading of servers from a device is not functionality that is
> >>> supported out of the box in the current release of OKL4, though the
> >>> framework is there upon which such functionality could be constructed
> >>> (specifically, the recursive construction of address spaces and page
> >>> handlers is the primary enabling functionality). A general approach would
> >>> be
> >>> as follows:
> >>>
> >>> 1) Leverage the OKL4 driver framework to construct the underlying driver
> >>> for
> >>> your device. Extensive documentation is available on
> >>> wiki.ok-labs.com/DriverFramework which will walk you through this.
> >>>
> >>> 2) Develop a loader/componentization server which will act as the pager
> >>> for
> >>> your demand-loaded servers. The server interface would take the name of
> >>> the
> >>> server/component required to start, start up a new server with itself as
> >>> the
> >>> pager and load the first code page, and, as the new server faults, service
> >>> the fault by demand-loading the required pages from the device.
> >>>
> >>> So essentially it's the development of a device and a server - let me know
> >>> if you have any queries on how to go about that, or on the underlying
> >>> recursive construction of address spaces / pagers in OKL4 which enables
> >>> the
> >>> functionality you require.
> >>>
> >>> Best regards,
> >>> Josh Matthews
> >>>
> >>> _______________________________________________
> >>> Developer mailing list
> >>> Developer at okl4.org
> >>> https://lists.okl4.org/mailman/listinfo/developer
> >>>
> >>>
> >>>       
> >> -- 
> >> View this message in context: http://www.nabble.com/Fast-and-Optimized-System-StartUp---OKL4-in-an-automotive-environment-tp17402999p17628963.html
> >> Sent from the OKL4 Community mailing list archive at Nabble.com.
> >>
> >>
> >> _______________________________________________
> >> Developer mailing list
> >> Developer at okl4.org
> >> https://lists.okl4.org/mailman/listinfo/developer
> >>
> >>     
> >
> >   
> 
> 
> -- 
> G S Madhusudan
> 31 Cantonment Road
> Singapore 089747
> Phone: +65 3132 4797 
> 
> US:
> Phone: +1 510 868 9201 (landline/vmail)     
> Fax:   +1 240 266 1330
> SIP:   17470872558 at proxy01.sipphone.com
> 
> 
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer
> 

--