[okl4-developer] Fast and Optimized System StartUp / OKL4 in an automotive environment
Oliver Mayer-Buschmann
omb at opensynergy.com
Thu Oct 16 23:17:28 EST 2008
Hi,
I'm a little bit confused about OKL's memsection_create tests
in /libs/iguana/test/memsect_tests.c
All tests of memsection_create_fixed() create only memsections, that
have been created/deleted before as not fixed memsections, eg.:
START_TEST(MEMS0900)
{
uintptr_t base;
memsection_ref_t ordinary, fixed;
int *p;
int i;
ordinary = memsection_create(MEM_SIZE, &base);
fail_if(base == 0, "base pointer not-null");
fail_if(ordinary == 0, "reference not zero");
memsection_delete(ordinary);
fixed = memsection_create_fixed(MEM_SIZE, base);
fail_if(fixed == 0, "reference not zero");
if (base == 0 || fixed == 0 || ordinary == 0) {
return;
}
p = (int *)base;
for (i = 0; i < 10; i++) {
p[i] = i;
}
for (i = 0; i < 10; i++) {
fail_if(p[i] != i, "memory section corrupt writes");
}
memsection_delete(fixed);
}
END_TEST
Does this mean, that it's not possible to allocate predetermined RAM
locations.
If this is the case, how should it be possible to implement a dynamic
loader, hence the elf-files I want to load are linked to static
addresses.
I'm wondering why the system does not allocate the needed pages,
since the kernel debugger shows me that there do not exist any pages at
my target address:
...
80505000 [a0519ffe]: phys=a0519000 pg=f4112814 4KB rwx (RWX)
user WB domain = 15
8050e000 [a0512ffe]: phys=a0512000 pg=f4112838 4KB rwx (RWX)
user WB domain = 15
80600000 [a0108c01]: tree=f4108c00
80600000 [a0540ffd]: phys=a0540000 pg=f4108c00 64KB rwx (RWX)
user WB domain = 15
80610000 [a0550ffd]: phys=a0550000 pg=f4108c40 64KB rwx (RWX)
user WB domain = 15
80620000 [a0560ffd]: phys=a0560000 pg=f4108c80 64KB rwx (RWX)
user WB domain = 15
80630000 [a0570ffe]: tree=f4108cc0
80630000 [a0570ffe]: phys=a0570000 pg=f4108cc0 4KB rwx (RWX)
user WB domain = 15
80631000 [a0571ffe]: phys=a0571000 pg=f4108cc4 4KB rwx (RWX)
user WB domain = 15
80632000 [a0572ffe]: phys=a0572000 pg=f4108cc8 4KB rwx (RWX)
user WB domain = 15
80633000 [a0573ffe]: phys=a0573000 pg=f4108ccc 4KB rwx (RWX)
user WB domain = 15
80634000 [a0574ffe]: phys=a0574000 pg=f4108cd0 4KB rwx (RWX)
user WB domain = 15
80635000 [a0575ffe]: phys=a0575000 pg=f4108cd4 4KB rwx (RWX)
user WB domain = 15
80636000 [a0576ffe]: phys=a0576000 pg=f4108cd8 4KB rwx (RWX)
user WB domain = 15
80637000 [a0577ffe]: phys=a0577000 pg=f4108cdc 4KB rwx (RWX)
user WB domain = 15
80638000 [a0578ffe]: phys=a0578000 pg=f4108ce0 4KB rwx (RWX)
user WB domain = 15
80639000 [a0579ffe]: phys=a0579000 pg=f4108ce4 4KB rwx (RWX)
user WB domain = 15
8063a000 [a057affe]: phys=a057a000 pg=f4108ce8 4KB rwx (RWX)
user WB domain = 15
8063b000 [a057bffe]: phys=a057b000 pg=f4108cec 4KB rwx (RWX)
user WB domain = 15
8063c000 [a057cffe]: phys=a057c000 pg=f4108cf0 4KB rwx (RWX)
user WB domain = 15
8063d000 [a051effe]: phys=a051e000 pg=f4108cf4 4KB rwx (RWX)
user WB domain = 15
8063e000 [a051fffe]: phys=a051f000 pg=f4108cf8 4KB rwx (RWX)
user WB domain = 15
8063f000 [a057dffe]: phys=a057d000 pg=f4108cfc 4KB rwx (RWX)
user WB domain = 15
80640000 [a057effe]: tree=f4108d00
80640000 [a057effe]: phys=a057e000 pg=f4108d00 4KB rwx (RWX)
user WB domain = 15
80641000 [a057fffe]: phys=a057f000 pg=f4108d04 4KB rwx (RWX)
user WB domain = 15
80642000 [a0587ffe]: phys=a0587000 pg=f4108d08 4KB rwx (RWX)
user WB domain = 15
80643000 [a0588ffe]: phys=a0588000 pg=f4108d0c 4KB rwx (RWX)
user WB domain = 15
80644000 [a051cffe]: phys=a051c000 pg=f4108d10 4KB rwx (RWX)
user WB domain = 15
a4000000 [f0107d00]: tree=f0107d00
a4000000 [a0108801]: tree=f4108800
a4000000 [a0586ffe]: tree=f4108800
a4000000 [a0586ffe]: phys=a0586000 pg=f4108800 4KB rwx (RWX)
user WB domain = 15
Another interesting thing is the first memsection, that is created while
parsing bootinfo:
...
ADD VIRT MEM (pool: 0x1, base: 0x80645000, end: 0x9fffffff)
It starts where the last section of my basic elf-file ends,
but if I dump the corresponding memory it looks like this:
80644fc0 00000000 00000000 00000000 00000000 ........ ........
80644fd0 00000000 00000000 00000000 00000000 ........ ........
80644fe0 00000000 00000000 00000000 00000000 ........ ........
80644ff0 00000000 00000000 00000000 00000000 ........ .....###
Continue? (Continue/Quit) [continue]: continue
80645000 ######## ######## ######## ######## ######## ########
80645010 ######## ######## ######## ######## ######## ########
80645020 ######## ######## ######## ######## ######## ########
80645030 ######## ######## ######## ######## ######## ########
80645040 ######## ######## ######## ######## ######## ########
80645050 ######## ######## ######## ######## ######## ########
80645060 ######## ######## ######## ######## ######## ########
80645070 ######## ######## ######## ######## ######## ########
can you please explain a little bit of elfweaver magic? Thanx!
Oliver
Am Mittwoch, den 15.10.2008, 19:06 +0200 schrieb 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
> > >
> >
More information about the Developer
mailing list