[okl4-developer] Fast and Optimized System StartUp / OKL4 in an automotive environment
Oliver Mayer-Buschmann
omb at opensynergy.com
Mon Oct 20 22:38:06 EST 2008
Hi Geoffrey,
Am Montag, den 20.10.2008, 22:11 +1100 schrieb Geoffrey Lee:
> On Wed, Oct 15, 2008 at 07:06:02PM +0200, Oliver Mayer-Buschmann wrote:
> > Hi Geoffrey,
> >
>
> Hi Oliver -
>
> > 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 would possibly agree that it might be a good idea, but without
> knowing the exact use cases I can't make a call. But to answer
> your specific question concerning elfweaver while I can't
> see infinitely into the future :-) elfweaver is actively
> developed and will be for quite some time, it is an important
> part of the OKL4 package.
>
I understand, that this is something that has to happen at OKL.
I think, that I've already explained my basic use case but I'm willed to
support you with further details.
> >
> > 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:
>
> My guess is the system thinks there is already something allocated
> at that virtual address range, and hence rejects the allocation.
That's my guess, too. But as you can see in my last post,
the target memory region seems not to be in use by the system.
That's exactly what I don't understand and I need more information about
finding out what's going on on system startup and how I can prevent the
system from allocating these regions.
>
> >
> > 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?
> >
>
> There is an Iguana reference manual on the OKL4 wiki. Is there
> something specific that you are after?
I'm after a sample Implementation how additional server's are registered
to iguana. Some explanation for which API calls have to be performed in
which order. That's what I mean when I talk about semantic.
>
> -gl
>
> > 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
> > > >
> > >
> >
>
More information about the Developer
mailing list