Hi,
On Mon Jan 04, 2016 at 17:03:49 +0100, Mahdi Aichouch wrote:
I combined the loader flags "L4.Ldr_flags.eager_map+L4.Ldr_flags.pinned_segs" in order to create fixed memory region for the text and data segments of an L4 task*. *And to be able to see their physical address using phys( ) method of Dataspace object. But, looking at the traces I didn't see any difference. After digging into the code where the Dataspace objects are created I saw that for instance in the following method from the file pkg/l4re_kernel/server/src/loader.cc :
L4Re_app_model::Dataspace L4Re_app_model::alloc_ds(unsigned long size) const { Dataspace mem = chkcap(Global::cap_alloc.allocL4Re::Dataspace(), "ELF loader: could not allocate capability"); chksys(Global::allocator->alloc(size, mem, (Global::l4re_aux->ldr_flags & L4RE_AUX_LDR_FLAG_PINNED_SEGS) ? L4Re::Mem_alloc::Pinned : 0 ), "loading writabel ELF segment"); return mem; }
The value of Global::l4re_aux->ldr_flags is equal to 0. And given the result of the test the created Dataspace is not pinned, because 0 is given as argument to alloc( ) method.
I was unable to find out why the attribute Global::l4re_aux->ldr_flags is not equal to L4.Ldr_flags.eager_map+L4.Ldr_flags.pinned_segs, as I was expecting. Could you please clarify this point.
Looking more closely at your last mail... the ldr_flags=... needs to go out one level of {}, i.e.: L4.default_loader:start({ ldr_flags = L4.Ldr_flags.eager_map + L4.Ldr_flags.pinned_segs, log = { "hello1", "green" } }, "rom/hello");
For my test, I modified the precedent code as follow :
chksys(Global::allocator->alloc(size, mem, /*(Global::l4re_aux->ldr_flags & L4RE_AUX_LDR_FLAG_PINNED_SEGS) ?*/ L4Re::Rm::Eager_map | L4Re::Mem_alloc::Pinned /*:0*/ ), "loading writabel ELF segment");
Then, in the traces I was I able to see the physical address of the created Dataspace objects.
Thats ok to do for your use case.
After that, I tested L4Linux and I saw that the physical addresses of the created Dataspace object of text and data segments when loading L4Linux binary have for example the following value :
l4linux | l4re_kernel: Loader::alloc_app_stack stack dataspace phys addr = 605b1000 size = 1000 l4linux | Global loader flags (Global::l4re_aux->ldr_flags) = 0 l4linux | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr = [605b2000] size = [3f9000] flags 0 l4linux | Phdr_load(): dataspace at physical address [0x605b2000], size [3f9000] l4linux | Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds [paddr = 0xa8000000 (0xa80segments00000), offs 0, size 4165632, all segs cow? 0] l4linux | Global loader flags (Global::l4re_aux->ldr_flags) = 0 l4linux | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr = [60aaf000] size = [2000] flags 0 l4linux | Phdr_load(): dataspace at physical address [0x60aaf000], size [2000] l4linux | Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xa8400000) paddr(0xa8400000), offs 4194304, size 8192, all segs cow? 0]
Looking in the trace from the main( ) function in L4Linux we can see that the physical address of the text and data areas of L4Linux are different from the precedents value printed using the phys( ) method of the corresponding Dataspace objects. As we can see below in the lines showing the physical value of stext - etext, sdata - edata areas :
... l4linux | L4LINUX: Ma DBG: Virtual Address 00000000 End 00000000 l4linux | Physical Address 00000000 End 00000000 l4linux | L4LINUX: Ma DBG: Starting binary at 0x2000360, argc=14 argv=0xafff4f6c *argv=0xb1007ff0 argv0=rom/vmlinuz.arm l4linux | External resolver is at 0xa800075c l4linux | ======> L4Linux starting... <======== l4linux | Linux version 3.16.0-l4 (aichouch@aichouch-ThinkCentre-M90) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #57 SMP Mon Jan 4 15:16:18 CET 2016 l4linux | Binary name: rom/vmlinuz.arm l4linux | This is an AEABI build. l4linux | Linux kernel command line (13 args): mem=128M l4memtype=pinned,continuous console=ttyLv0 l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=49152 rw init=/bin/sh earlyprintk=1 showpfexc=1 showghost=1 print-fatal-signals=1 l4shmnet.add=shmns,macparCPU mapping (l:p)[1]: 0:0 l4linux | Image: 020000a0 - 02600000 [6143 KiB]. l4linux | Areas: Text: 020000a0 - 023b2000 [3783kB] (a bit longer) l4linux | Data: 023b2000 - 023dd460 [173kB] l4linux | Initdata: 02387000 - 023b1a00 [170kB] l4linux | BSS: 023e239c - 024a6780 [784kB] l4linux | Device scan: l4linux | Device: L4ICU l4linux | Device: imx6q-fec.dev l4linux | MEM: 02188000 - 0218bfff l4linux | IRQ: 00000096 - 00000096 l4linux | IRQ: 00000097 - 00000097 l4linux | Device: dmamem l4linux | MEM: 60ab1000 - 60b30fff l4linux | Device scan done. l4linux | L4LINUX: Ma DBG: l4lx_thread_create: Created thread 416 (cpu0) (u:b3000e00, v:b3000c00, sp:023b3fa4) l4linux | main thread will be 416 l4linux | l4x_register_pointer_section: addr = 02000000 size = 4878336 l4linux | section-with-init: Virt: 0x2000000 to 0x24a677f [4761 KiB] l4linux | section-with-init: Phys: 0x60b33000 to 0x60fd977f, [4761 KiB] l4linux | Main thread running, waiting... l4linux | Main thread running, waiting... l4linux | stext virt 020000a0, phys 60b330a0 l4linux | etext virt 023b2000, phys 60ee5000 l4linux | sdata virt 023b2000, phys 60ee5000 l4linux | edata virt 023dd460, phys 60f10460 l4linux | L4x: Memory size: 128MB l4linux | L4x: Setting superpages for main memory l4linux | L4x: Adjusted memory start: 02000000 l4linux | Main memory: Virt: 0x2600000 to 0xa5fffff [131072 KiB] l4linux | Main memory: Phys: 0x64800000 to 0x6c7fffff, [131072 KiB] l4linux | l4x: vmalloc area: 0a600000 - 12600000 l4linux | l4x_register_pointer_section: addr = 02000000 size = 4878336 l4linux | text: Virt: 0x2000000 to 0x24a677f [4761 KiB] l4linux | text: Phys: 0x60b33000 to 0x60fd977f, [4761 KiB] l4linux | Booting Linux on physical CPU 0x0 l4linux | Linux version 3.16.0-l4 (aichouch@aichouch-ThinkCentre-M90) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #57 SMP Mon Jan 4 15:16:18 CET 2016 l4linux | CPU: Fiasco [410fc090] revision 0 (ARMv7), cr=00000000 l4linux | CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache l4linux | Machine: L4 l4linux | Ignoring unrecognised tag 0x00000000 l4linux | bootconsole [earlykdb0] enabled l4linux | Forcing write-allocate cache policy for SMP l4linux | Forcing shared mappings for SMP l4linux | Memory policy: Data cache writealloc l4linux | Page fault: addr = bffff003 pc = 0238aba0 (rw, T) l4linux | Forward PF to our pager l4linux | Loading: rom/ramdisk-arm.rd l4linux | INITRD: Size of RAMdisk is 49152KiB l4linux | INITRD: 12600000 - 15600000 ...
Could you please explain why there is a difference in the physical addresses of the Dataspaces representing the text and data sections when loading L4Linux binary, and the physical addresses of these sections when L4Linux is booting.
The L4Linux you are loading via ned is not the Linux kernel but a wrapper around that that contains the Linux kernel. L4Re will load the wrapper while the Linux output is the actual Linux kernel. The output before "=== L4Linux starting ===" is from the loader that is loading/unpacking the inner part, you probably want to look there as well (arch/l4/boot/ldr.c).
Adam