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

[Oliver Mayer-Buschmann]

Hi Geoffrey,

having from elfweaver merged packages, with each containing an own
bootinfo,
and let them be parsed from OKL-code, seemed to be an easy and
consistent way. Might OKL support this in the future?
Doesn't it make sense to modify elfweaver to support this?
Or will this not fit to your future plannings, maybe your next release
will not contain elfweaver any more?

Of course you are right, I've started to implement my own server.
But I'm running into problems.

I'm not able to get memsections with predetermined RAM locations.
I'm using the method memsection_create_fixed(). I can't see any usage of
my RAM destinations by the system, but the memsection has not been
created. 
Here is my code:

    memsection_ref_t ms;

    elf_fprintf(stdout, (void*)elffile, elffile_size, "omb_testapp",
ELF_PRINT_PROGRAM_HEADERS | ELF_PRINT_SECTIONS);

    ms = memsection_create_fixed(elffile_size, base);

and here the resulting output (from skyeye, containing some ELF-output):

Found an elf32 file called "omb_testapp" located at address 0x0x80605a78
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
  LOAD           0x008000 0x80800000 0x80800000 0x05191 0x05191 R E
0x8000
  LOAD           0x00d194 0x8080d194 0x8080d194 0x00118 0x0020c RW
0x8000
Section Headers:
  [Nr] Name              Type            Addr     Off
[ 0]  0 0
[ 1] .text 2155872256 32768
[ 2] .rodata 2155891128 51640
[ 3] .data 2155925908 53652
[ 4] .got 2155926172 53916
[ 5] .bss 2155926188 53932
[ 6] .comment 0 53932
[ 7] .debug_aranges 0 55048
[ 8] .debug_pubnames 0 56968
[ 9] .debug_info 0 60349
[10] .debug_abbrev 0 142016
[11] .debug_line 0 164143
[12] .debug_frame 0 188580
[13] .debug_str 0 192264
[14] .debug_ranges 0 199419
[15] .shstrtab 0 200963
[16] .segment_names 0 201151
[17] .strtab 0 201158
[18] .symtab 0 209996
iguana/server/src/pd.c:551 pd_create_memsection: pd_create_memsection
(0x8002c4d0, 35a54, 80800000, 2)
iguana/server/src/memsection.c:92 memsection_new: memsection_new_called
iguana/server/src/pd.c:581 pd_create_memsection: MEM_FIXED:
virtpool_alloc_fixed
iguana/server/src/pd.c:602 pd_create_memsection: failed to alloc from
virtpool

Any idea what I'm missing.
Could you please explain the usage of iguana-API more detailet?

Thank you!

Oliver

Am Donnerstag, den 16.10.2008, 02:18 +1100 schrieb Geoffrey Lee:
> On Thu, Oct 09, 2008 at 11:41:02PM +0200, Oliver Mayer-Buschmann wrote:
> > Hi,
> > 
> 
> Hi Oliver - I am guessing you intend for these packages to be 
> loaded dynamically at run-time on demand, and hence these modules
> should live outside of the main bootable image.  In this case
> rather than putting it into the bootinfo, maybe you can
> create a package manager that "knows" about all the packages
> available on a given system and let it load these packages
> directly on demand?  Off the top of my head I don't recall
> anything special that you might have to do if you were 
> to run a program dynamically, other than go through the 
> standardized Iguana application pd creation and thread creation.
> In the case of dynamically loaded programs you'd probably create
> a memory section(s) and load your ELF load your program into those 
> memory section (s).
> 
> 	-gl
> 
> > I'd appreciate to receive some feedback and information from you.
> > 
> > As explained in this tread:
> > http://wiki.ok-labs.com/forum?query=startup%20automotive
> > I'm working on an modularized startup concept for Iguana.
> > 
> > At this point I've finished all basic work to start with my package  
> > loader implementation.
> > 
> > A package is a set of iguana applications (e.g. a package contains 1  
> > or more iguana servers or a wombat).
> > Let's say, a package is an ELF-File (e.g. one of the ELF-Files from / 
> > build/iguana/bin)
> > 
> > I have acces to NAND and I've integrated YAFFS2 to L4, so I'm able to  
> > load ELF-files to RAM,
> > using the NICTA ELF-loader.
> > 
> > The last missing step to prove the concept, is to register the  
> > additional loaded programs to iguana.
> > 
> > I've had a first deeper look into the bootinfo parsing of the iguana  
> > server.
> > Hmm, ... I'm able to use gdb in skyeye ... one of how many @TODOs in  
> > OKL ^^
> > anyway ...
> > 
> > I can imagine some different possibilities to implement the  
> > registration to iguana, e.g.:
> > 
> > 1. I could define my own iguana registration meta data (e.g. in XML),  
> > implement a separate iguana server
> > and use the ig_server idl4 API to create memsections, pds, etc and  
> > register the package to L4.
> > Any hint's in using the iguana API is appreciated-I'm talking about  
> > semantic! ;-)
> > 
> > 2. I could modify elfweaver to be able to create (merge) packages for  
> > me that contain the needed bootinfo section
> > to be parsed inside the iguana root server . The elfweaver manual  
> > tells me, that I can bring additional code to ig_server,
> > using elfweaver's extension feature. Has anybody tested or used this?
> > Can somebody help me with elfweaver modifications?
> > Where is the best starting point in creating ELF-files with bootinfos,  
> > that do not contain a root server nor a kernel but references to
> > programs, that only exist in other packages? Any useful information is  
> > definitely appreciated!
> > 
> > Thanks!
> > 
> > Oliver
> > 
> > _______________________________________________
> > Developer mailing list
> > Developer at okl4.org
> > https://lists.okl4.org/mailman/listinfo/developer
> > 
>