[okl4-developer] Fast and Optimized System StartUp / OKL4 in an automotive environment
Geoffrey Lee
glee at ok-labs.com
Mon Oct 20 22:11:55 EST 2008
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'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.
>
> 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?
-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