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

[Oliver Mayer-Buschmann]

Hello all,

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.