- l4-hackers - example.com Site

No configuration file found in build directory
by Wesley Miaw 26 Jul '11

26 Jul '11

I'm trying to add a new lib/server module to L4 but I'm having some trouble. I followed the snapshot top-level README suggestion to place the new code in an external directory, so I placed it into src/ mymodule/ next to src/l4re and src/l4linux. Then I created a Makefile under src/mymodule/src/ based on the example with include $(L4DIR)/mk/ lib.mk. However, this doesn't appear to be working. $(L4DIR)/mk/Makeconf is complaining that files existing inside the obj/l4/... directory are not to be found in the obj/mymodule/... directory. (I tried to copy the obj/... logic found in the top-level Makefile.) Is the README's suggestion accurate? Thanks, -- Wesley Miaw wesley(a)wesman.net

2 1

transfer_msg_items
by Chen Tian 21 Jul '11

21 Jul '11

Hello, Why was a sender's send item (e.g. mr[0] and mr[1] ) merged and stored into the receiver's mr[0]? Basically I have trouble understanding the following code. *rcv_words=(item->b.raw() & ~0x0ff7) | (sfp.raw())&0x0ff0); rcv_word +=2 ; Why didn't we use receiver's mr[1] as well? In the case of page fault handling IPC, the pf address stored in sender's mr[1] is not used ? Thanks. Chen

1 1

what is the difference between the 2 methods of booting hello demo
by cheng guanghui 19 Jul '11

19 Jul '11

Hello: In the modules.list there are 2 entires to boot hello demo as following: entry hello roottask moe --init=rom/hello module l4re module hello entry hello-cfg roottask moe rom/hello.cfg module l4re module ned module hello.cfg module hello The booting logs are following separately : hello MOE: Hello world MOE: found 117648 KByte free memory MOE: found RAM from 1000 to 75c7000 MOE: allocated 117 KByte for the page array @0x1000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:501000] BOOTFS: [136d000-1470e6d] [C:503000] l4re BOOTFS: [1471000-153030b] [C:504000] hello MOE: cmdline: /home/cheng/TUDOS/Src/l4re-snapshot-2011062216/obj/l4/x86/bin/x86_586/l4f/moe --init=rom/hello MOE: Starting: rom/hello MOE: loading 'rom/hello' Hello World! Hello World! Hello World! hello-cfg MOE: Hello world MOE: found 115604 KByte free memory MOE: found RAM from 1000 to 75c7000 MOE: allocated 117 KByte for the page array @0x1000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:501000] BOOTFS: [136d000-1470e6d] [C:503000] l4re BOOTFS: [1471000-166e572] [C:504000] ned BOOTFS: [166f000-166f066] [C:505000] hello.cfg BOOTFS: [1670000-172f30b] [C:506000] hello MOE: cmdline: /home/cheng/TUDOS/Src/l4re-snapshot-2011062216/obj/l4/x86/bin/x86_586/l4f/moe rom/hello.cfg MOE: Starting: rom/ned rom/hello.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/hello.cfg' hello | Hello World! hello | Hello World! hello | Hello World! hello | Hello World! hello | Hello World! hello | Hello World! hello | Hello World! So hello demo could be booted whatever from Ned or Moe directly. In the document Ned is described as this "The main thing to do here is to coordinate the startup of services and applications as well as to provide the communication channels for them". Does it mean "We use Ned just because we need to dynamically create IPC gate (channel) between different applications". If there is no need to use IPC gate we can use Moe directly to boot application. is it correct? Thanks. Warm regards. Cheng Guanghui

2 2

how can i understand this description in the l4re-source document?
by cheng guanghui 19 Jul '11

19 Jul '11

Hello: In the page 19 of the l4re-source document there is a description about caps as following: Caps The table with application-specific named capabilities (default is an empty table). If the table does not contain a capability with the name ’rom’, the ’rom’ capability from Ned’s initial caps is inserted into the table. How can i understand "If the table does not contain a capability with the name ’rom’, the ’rom’ capability from Ned’s initial caps is inserted into the table." Thanks. Warm regards. Cheng Guanghui

2 2

writing my own filesystem for L4
by Michal Schulz 19 Jul '11

19 Jul '11

Hello. I'm going to write a filesystem for L4, using the tmpfs (l4/pkg/tmpfs) as a starting point. However, I would like to know whether there are any tools I could use to test the filesystem. The tool I would love to have should display all registered filesystem and should allow me to walk through filesystem's directory trees. Is there such a tool or example application? Are there any packages in L4 which use VFS layer at all? regards, Michal. -- Michal Schulz

2 1

Re: l4-hackers Digest, Vol 99, Issue 11
by Chen Tian 18 Jul '11

18 Jul '11

Hi Adam, I don't have a separate PHDR for ctors. I got this problem when I put ctors into the text section. Now I have moved ctors into the data section and the problem disappeared. Any ideas? Another questions is why ktext=0x90909090 in the ld file of fiasco.oc? Is this value randomly chosen? Thanks. On Sat, Jul 16, 2011 at 3:00 AM, <l4-hackers-request(a)os.inf.tu-dresden.de> wrote: > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > or, via email, send a message with subject or body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > > Today's Topics: > > 1. Re: write my own root task. (Adam Lackorzynski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Jul 2011 23:20:50 +0200 > From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> > To: l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: write my own root task. > Message-ID: <20110715212050.GB5040(a)os.inf.tu-dresden.de> > Content-Type: text/plain; charset=iso-8859-1 > > > On Thu Jul 14, 2011 at 15:15:25 -0700, Chen Tian wrote: >> I am trying to use C++ to write my own root task. I found that if I >> declare a static or global object, bootstrap complains that two >> regions belonging to my root task overlapped and thus cannot proceed. >> Why does my root task have two conflicting regions? According to the >> bootstrap report, they both have the correct starting address, but one >> ends just at the global object's ctor in .ctors section, while the >> other region covers the entire program. >> If the .ctors section is empty then everything is fine. Any ideas? > > I wonder why you have an own PHDR for ctors? How many do you have? > > > Adam > -- > Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > > > ------------------------------ > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > > End of l4-hackers Digest, Vol 99, Issue 11 > ****************************************** >

2 1

write my own root task.
by Chen Tian 15 Jul '11

15 Jul '11

Hello, I am trying to use C++ to write my own root task. I found that if I declare a static or global object, bootstrap complains that two regions belonging to my root task overlapped and thus cannot proceed. Why does my root task have two conflicting regions? According to the bootstrap report, they both have the correct starting address, but one ends just at the global object's ctor in .ctors section, while the other region covers the entire program. If the .ctors section is empty then everything is fine. Any ideas? Thanks. Chen

2 1

TLS on amd64
by Daniel Müller 14 Jul '11

14 Jul '11

Hello, I want to use the __thread keyword gcc provides. I was told this was recently adjusted to work (at least in the private repository which I am using). It appears to be working when building for IA32 but when I compile the same program for amd64 I get a page fault when running it (it is a simple program just incrementing a __thread declared int). It faults at 10010f4 (the first access of the variable). 00000000010010f0 <main>: 10010f0: 48 83 ec 08 sub rsp,0x8 10010f4: 64 c7 04 25 fc ff ff mov DWORD PTR fs:0xfffffffffffffffc,0x0 10010fb: ff 00 00 00 00 1001100: bf 60 48 01 01 mov edi,0x1014860 1001105: e8 36 88 00 00 call 1009940 <puts> 100110a: 64 83 04 25 fc ff ff add DWORD PTR fs:0xfffffffffffffffc,0x1 1001111: ff 01 1001113: bf 01 00 00 00 mov edi,0x1 1001118: e8 d3 71 00 00 call 10082f0 <sleep> 100111d: eb e1 jmp 1001100 <main+0x10> 100111f: 90 nop Is TLS for amd64 supposed to work? Any idea on the problem? Greetings, Daniel

2 3

Running the IO server
by Anna Fischer 12 Jul '11

12 Jul '11

I'm trying to run the ARM-based frame buffer configuration from conf/examples/arm-rv-lcd.cfg with pkg/io/config/arm-rv-eb-mc.devs and QEMU (-M realview-pbx-a9). I can boot the L4 Linux kernel on this (without GUI but just serial I/O) configuration, but I get an error when trying to set up the LCD (see below). Perhaps the LCD device configuration from the .devs file does not match what hardware QEMU emulates? How can I actually enumerate in the IO server what hardware it actually runs on? Is there a way to do that? Thanks, Anna L4 Bootstrapper Build: #34 Mon Jul 11 16:17:10 BST 2011, 4.5.2 Scanning up to 256 MB RAM Memory size is 256MB (00000000 - 10000000) RAM: 0000000000000000 - 000000000fffffff: 262144kB Total RAM: 256MB mod11: 012a9000-012cac7c: ex_fb_spectrum mod10: 0121b000-012a846c: mag mod09: 011f1000-0121a5b8: fb-drv mod08: 0119d000-011f01b8: ned mod07: 010c2000-0119cb58: io mod06: 010a8000-010c1510: l4re mod05: 010a7000-010a70e4: arm-rv-lcd.io mod04: 010a6000-010a659d: arm-rv-eb-mc.devs mod03: 010a5000-010a56bb: arm-rv-lcd.cfg mod02: 0106b000-010a45f0: moe mod01: 01061000-0106a33c: sigma0 mod00: 01015000-0106014c: fiasco Moving 12 modules to 1100000 with offset eb000 moving module 12 { 12a9000-12cac7c } -> { 1394000-13b5c7c } moving module 11 { 121b000-12a846c } -> { 1306000-139346c } moving module 10 { 11f1000-121a5b8 } -> { 12dc000-13055b8 } moving module 09 { 119d000-11f01b8 } -> { 1288000-12db1b8 } moving module 08 { 10c2000-119cb58 } -> { 11ad000-1287b58 } moving module 07 { 10a8000-10c1510 } -> { 1193000-11ac510 } moving module 06 { 10a7000-10a70e4 } -> { 1192000-11920e4 } moving module 05 { 10a6000-10a659d } -> { 1191000-119159d } moving module 04 { 10a5000-10a56bb } -> { 1190000-11906bb } moving module 03 { 106b000-10a45f0 } -> { 1156000-118f5f0 } moving module 02 { 1061000-106a33c } -> { 114c000-115533c } moving module 01 { 1015000-106014c } -> { 1100000-114b14c } Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/arm-rv-lcd.cfg Relocated mbi to [0x100f000-0x100f19e] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x2000 Regions of list regions [ 1000, 19ff] { a00} Kern fiasco [ 2000, 5cfff] { 5b000} Kern fiasco [ 90000, 9e17b] { e17c} Sigma0 sigma0 [ 140000, 17160b] { 3160c} Root moe [ 178000, 18eec7] { 16ec8} Root moe [ 1000000, 10143eb] { 143ec} Boot bootstrap [ 100f000, 100f29b] { 29c} Root Multiboot info [ 1190000, 13b5c7b] { 225c7c} Root Modules Memory API Version: (87) experimental Sigma0 config ip:000900e0 sp:01013044 Roottask config ip:00140178 sp:00000000 Starting kernel fiasco at 00001000 Realview System ID: Rev=0 HBI=178 Build=0 Arch=5 FPGA=00 L2: ID=00000000 Type=00000000 L2 cache enabled Hello from Startup::stage2 Initialize page table Number of IRQs available at this GIC: 96 Vmem_alloc::init() Cache config: ON ID_PFR0: 00001031 ID_PFR1: 00000011 ID_DFR0: 00000000 ID_AFR0: 00000000 ID_MMFR0: 00100103 ID_MMFR1: 20000000 ID_MMFR2: 01230000 ID_MMFR3: 00002111 SERIAL ESC: allocated IRQ 44 for serial uart Not using serial hack in slow timer handler. Welcome to Fiasco.OC (arm)! L4/Fiasco.OC arm microkernel (C) 1998-2011 TU Dresden Rev: r33 compiled with gcc 4.5.2 for Realview [] Build: #1 Tue Jun 21 12:57:15 BST 2011 Calibrating timer loop... done. SIGMA0: Hello! KIP @ 2000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:0;fff] [0:5d000;8ffff] [0:9f000;13ffff] [4:140000;171fff] [0:172000;177fff] [4:178000;18efff] [0:18f000;100efff] [4:100f000;100ffff] [0:1010000;118ffff] [4:1190000;13b5fff] [0:13b6000;effffff] IOMEM:---------------------- [0:10000000;ffffffff] MOE: Hello world MOE: found 242832 KByte free memory MOE: found RAM from 5d000 to f000000 MOE: allocated 239 KByte for the page array @0x9f000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:501000] BOOTFS: [1190000-11906bb] [C:503000] arm-rv-lcd.cfg BOOTFS: [1191000-119159d] [C:504000] arm-rv-eb-mc.devs BOOTFS: [1192000-11920e4] [C:505000] arm-rv-lcd.io BOOTFS: [1193000-11ac510] [C:506000] l4re BOOTFS: [11ad000-1287b58] [C:507000] io BOOTFS: [1288000-12db1b8] [C:508000] ned BOOTFS: [12dc000-13055b8] [C:509000] fb-drv BOOTFS: [1306000-139346c] [C:50a000] mag BOOTFS: [1394000-13b5c7c] [C:50b000] ex_fb_spectrum MOE: cmdline: moe rom/arm-rv-lcd.cfg MOE: Starting: rom/ned rom/arm-rv-lcd.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/arm-rv-lcd.cfg' IO | Io service mag | libio: Warning: Finding 'icu' in system bus failed with 'Void capability invoked' mag | Hello from MAG fbdrv | libio: Warning: Finding 'icu' in system bus failed with 'Void capability invoked' fbdrv | Could not find LCD. fbdrv | Failed to setup Framebuffer mag | Error: Exception: Void capability invoked: requesting goos info: backtrace ... mag | mag | MAG: destroy FB svc Ned[lua]: Hm, cpapbility 42d000 does not support the meta protocol: -2004 Ned: ERROR: rom/arm-rv-lcd.cfg:62: attempt to call method 'create' (a nil value)

2 2

Fix IO-APIC/IRQ-Routing Bug (affects GSIs 24, 48, 72, ...)
by Christian Ehrhardt 08 Jul '11

08 Jul '11

Hi, there seems to by an off-by-one error in Io_apic::find_apic() that kills IRQ-routing for GSIs that are a multiple of 24. Please consider the patch below (tested on real hardware with 3 IO-APICS). regards Christian diff --git a/src/kernel/fiasco/src/kern/io_apic.cpp b/src/kernel/fiasco/src/kern/io_apic.cpp index 88ffe68..897a1a0 100644 --- a/src/kernel/fiasco/src/kern/io_apic.cpp +++ b/src/kernel/fiasco/src/kern/io_apic.cpp @@ -331,7 +331,7 @@ Io_apic::find_apic(unsigned irqnum) { for (unsigned i = Max_ioapics; i > 0; --i) { - if (_apics[i-1]._apic && _apics[i-1]._offset < irqnum) + if (_apics[i-1]._apic && _apics[i-1]._offset <= irqnum) return i - 1; } return 0;

1 0