- l4-hackers - example.com Site

Booting L4/Fiasco + L4Re on PC
by 석현철 16 May '12

16 May '12

Hello. I’ve tried to boot L4/Fiasco on PC. I followed the directions for building from both “http://os.inf.tu-dresden. de/fiasco/build.html” and “http://os.inf.tu-dresden.de/L4Re/build.html” And I could run L4/Fiasco on QEMU. Now I hope I want to boot L4 on PC environment. As I searched, it can be done through GRUB. (But, I am not convinced that it is right way.) Anyway, I’ve tried to boot L4 by using GRUB. I use Ubuntu Linux for compiling L4/Fiasco and L4Re. In this, there is GRUBv2. I made the bootable ISO image. (It is done by “make grub2iso E=hello MODULE_SEARCH_PATH={mypath}”) And then, what should I do in order to boot L4 on PC? How should I configure the GRUB configuration? I really want to know how to boot L4 on PC. Please, help me! Kind Regards, Hyunchul Seok.

2 1

Re: understanding l4re
by Björn Döbel 14 May '12

14 May '12

Hi, On 14.05.2012 18:13, Ryan Brown wrote: > Thank you for your answers, they were very helpful. Now I have some more > questions: > > Are any of these documents relevant to, or helpful in working with > Fiasco.OC? http://l4hq.org/docs/manuals/ No. These docs don't describe the Fiasco.OC API (although many of the concepts are shared). The relevant documentation for Fiasco and the L4 Runtime Environment is at https://os.inf.tu-dresden.de/L4Re/doc/ (yes, that's all for now - if you have any questions, please ask and we're glad to help). There's also a Wiki: http://wiki.tudos.org/Main_Page > Is there a limit on how many threads you can create with pthreads? As in any other system, pthread_create() returns -EAGAIN if there are insufficient system resources to create another thread. This may happen, if the lib is not able to allocate a stack or TLS area for the thread or in the Fiasco.OC case if there are insufficient kernel resources. > How does thread scheduling work? As a policy this should be implemented > in user space, right? Actually, scheduling is the only policy that is implemented in the kernel and as far as I know most L4 variants do this, although there have been experiments to do it in user space. [1] > Does pthreads take care of this? I see that it > handles resuming the highest priority waiting thread for example when > unlocking a mutex. But what if more threads are runnable than the number > of cores? Fiasco.OC schedules threads based on their priorities. (Same priority leads to round-robbin scheduling.) There are separate run queues for every physical CPU and you have to explicitly bind a thread to a physical core. > Are shared libraries supported? Yes. There is a port of ldso in l4/pkg, most libs are built as shared variants as well. There's even an example for starting a version of the hello example with shared libraries: * First check out L4Re as documented on the web page. * Then go to l4/pkg and do $> svn up examples/ * Then build examples/misc/shared-hello * In l4/conf/modules.list there is an example entry "hello-shared" that should get you set up. > Actually, I think I saw that fork/exec, etc were stubs. These may be stubs in the C library, but there are no implementations of fork/exec for L4Re. (Although, this would be possible.) > I believe I've seen L4 apis for creating new address > spaces, but what about loading an executable into the address space? This is done by an ELF loader. The default loaders are moe (for the first binary) and ned (the Lua-based init program). You can also write your own and use the functionality provided by l4/pkg/libloader. > I suppose I should take more of a look at moe and ned to understand this. Indeed. ;) > How does the L4re logger get initialized and connected to the serial > console? When being started, an L4Re application gets an initial set of capabilities (== communication channels). These are the initially available services and one of them is the Log channel which by default provides stdout and stderr for your application. The default log implementation is provided by the kernel who has a serial console driver built in (debugging...). > I see some code inside bootstrap for initializing the uart, is > this where it happens? This is the first place where this happens. Bootstrap is a bit weirdly placed in l4/pkg. Actually, it is the "kernel" that is initially booted for every L4 setup. It sets up a multiboot environment and then hands over control to Fiasco, which then is the real kernel to run. As the Fiasco codebase is separate from the L4Re code base, you'll find another UART driver in Fiasco as well. Yep, that's redundant. > Thanks for the help, and sorry for so many questions. No worries. May I ask if you have any special project in mind? Cheers, Bjoern [1] J. Stoess: Towards Effective User-Controlled Scheduling for Microkernel-Based Systems, SIGOPS OSR, July 2007

1 0

Source of KVM-L4 ?
by Rolf Sommerhalder 13 May '12

13 May '12

Hello list, Is there any source code available of "KVM-L4", e.g. KVM which has been ported to L4Linux? There are some publications from TU Dresden which report about this successful port as KVM-L4. Is its source code available at all, or is it just hiding from search engines in some public repository or archive? Thanks, Rolf

4 12

Fiasco.OC on Cortex-A9
by Johan Dams 12 May '12

12 May '12

Hi all, I'm wondering if anyone has come across an issue with Fiasco.OC on Cortex-A9 based systems. The problem is that I do not get past this instruction (and with that I mean that the system just locks up): "mcr p15, 0, %[control], c1, c0 \n" // control in src/kern/arm/bootstrap.cpp. The exact same code works fine on a Cortex-A8 based processor. Changing cache on or off (in the control variable) does not change anything. Also, just reading the current content of the register and writing it back locks the system. I have been going over compiler flags, tried different compilers altogether (using 4.5.3-r1 right now), and looked if something odd was going on with the generated assembly code, etc. with no results. This code is a standard ARM instruction, and comes well before any paging or even the actual kernel starts. The SOC in question is a Freescale i.MX6 Quad core Cortex A9, which I realize not many have actually used yet. However, if similar issues presented itself on other platforms, these might give some clues. Any ideas? Best regards, Johan

1 2

understanding l4re
by Ryan Brown 11 May '12

11 May '12

Hi. I'm exploring developing software that runs on Fiasco.OC/L4re, so I'm trying to understand how the various pieces fit together. If I'm following the makefiles correctly it looks like some uclibc files (like libc/inet) are getting compiled, but they seem to be making linux system calls. I also see the libc_backends code, and I'm not sure how this fits in. It looks like these are mostly stubs, is it expected that you'll link the final binary with the real implementation you want? I also took a look at libpthreads, and I don't see much l4 specific code. It looks like mutexes are implemented as spinlocks? Isn't there a better way to do synchronization in fiasco?

2 1

[ankh+l4linux] Doesn't work
by Timur 03 May '12

03 May '12

Hi, after ifconfig eth0 up l4linux crashes with errors: -------------------------- l4lx_irq_dev_startup: creating IRQ thread for 66 (IRQ-cap 42d000) l4lx_irq_dev_startup: creating IRQ thread for 66 (IRQ-cap 42d000) l4linux | l4lx_thread_create: Created thread 433 (IRQ66) (u:b3000e00, sp:006c9ff4) l4linux | irq_thread: Started IRQ thread for IRQ 66 l4linux | wait_for_irq_message: IRQ 66 (42d) receive failed, error = 0x4 ------------------------ l4_is_invalid_cap(p->irq_cap) return false in wait_for_irq_message, but l4_irq_wait_u(p->irq_cap, &src_id, L4_IPC_NEVER, utcb) return L4_IPC_ENOT_EXISTENT. How can this be? -- Galiullin Timur

2 1

Re: Running Fiasco.OC in Bochs
by Norman Feske 01 May '12

01 May '12

Hello Julius, > I am successfully running Fiasco.OC on Bochs (2.4.6) with PCI emulation > enabled (although all my slots are empty). I had encountered the same > double fault issue and discovered that I could work around it by > configuring Fiasco to use RTC scheduling (instead of PIT). APIC seems to > work fine, too. thank you for this excellent suggestion! By using RTC as scheduling timer and re-enabling PCI, I was able to bring the whole scenario (including the GUI) to life. Cheers Norman

1 0

Re: Fwd: Running Fiasco.OC in Bochs
by Martin Unzner 29 Apr '12

29 Apr '12

Hi Norman, Björn told me about your problem because I write my Belegarbeit using a Framework which includes Bochs. I was not able to reproduce your exact error, but since I have experienced faults at the same stage of booting when I started with Bochs, my workaround might at least be worth a try. Using your setup, my Bochs instance hung up instead of reporting a double fault, but then again, everything worked when I disabled the PCI bridge. So maybe pci: enabled=0 in bochsrc or even omitting the --enable-pci parameter while configuring might help in your case. In general, I experienced that compiling Bochs with less configuration parameters usually produces a better emulator. Regards, Martin Am 29.04.2012 08:36, schrieb Björn Döbel: > Hi, > > Kannst Du dem Norman helfen? > > Björn > > -------- Original-Nachricht -------- > Betreff: Running Fiasco.OC in Bochs > Datum: Sat, 28 Apr 2012 21:14:37 +0200 > Von: Norman Feske<norman.feske(a)genode-labs.com> > An: l4-hackers(a)os.inf.tu-dresden.de > > Hello, > > for tracing/profiling purposes, I'd like to run Genode on Fiasco.OC in > Bochs. My prior attempts with the OKL4 and Pistachio kernels went fine. > However, when booting the setup with Fiasco.OC, I get the following > kernel message right at the start: > > Freeing init code/data: 28672 bytes (7 pages) > > DOUBLE FAULT! > EAX=ec7ff000 ESI=00000000 DS=0023 > EBX=fcdcf000 EDI=fcdcf170 ES=0023 > ECX=ec7ff000 EBP=f0060100 GS=0043 > EDX=ec7ff000 ESP=fcdcffbc SS=0010 ESP0=00000000 > EFL=00200246 EIP=f006592c CS=0008 > Return reboots, "k" tries to enter the L4 kernel debugger... > > Has anyone successfully used Fiasco.OC with Bochs before? If yes, I > would very much appreciate a known-good starting point for experimentation. > > For reference, I am using the following kernel configuration: > > > https://raw.github.com/genodelabs/genode/master/base-foc/config/x86_32.kern… > > My 'bochsrc' file looks as follows: > > display_library: x > romimage: file=/usr/local/share/bochs/BIOS-bochs-latest > megs: 128 > com1: enabled=1, mode=file, dev=serial.out > boot: cdrom > ata0-master: type=cdrom, path=var/run/demo.iso, status=inserted > mouse: enabled=1, type=imps2 > log: ./bochs.out > panic: action=fatal > vgaromimage: file=/usr/local/share/bochs/VGABIOS-lgpl-latest > vga: extension=vbe > pci: enabled=1, chipset=i440fx, slot1=pcivga > > The Bochs version is the official release 2.5.1 configured with the > following arguments: > > --with-x11 --enable-plugins --enable-pci --enable-clgd54xx > > Regards > Norman >

2 1

Running Fiasco.OC in Bochs
by Norman Feske 28 Apr '12

28 Apr '12

Hello, for tracing/profiling purposes, I'd like to run Genode on Fiasco.OC in Bochs. My prior attempts with the OKL4 and Pistachio kernels went fine. However, when booting the setup with Fiasco.OC, I get the following kernel message right at the start: Freeing init code/data: 28672 bytes (7 pages) DOUBLE FAULT! EAX=ec7ff000 ESI=00000000 DS=0023 EBX=fcdcf000 EDI=fcdcf170 ES=0023 ECX=ec7ff000 EBP=f0060100 GS=0043 EDX=ec7ff000 ESP=fcdcffbc SS=0010 ESP0=00000000 EFL=00200246 EIP=f006592c CS=0008 Return reboots, "k" tries to enter the L4 kernel debugger... Has anyone successfully used Fiasco.OC with Bochs before? If yes, I would very much appreciate a known-good starting point for experimentation. For reference, I am using the following kernel configuration: https://raw.github.com/genodelabs/genode/master/base-foc/config/x86_32.kern… My 'bochsrc' file looks as follows: display_library: x romimage: file=/usr/local/share/bochs/BIOS-bochs-latest megs: 128 com1: enabled=1, mode=file, dev=serial.out boot: cdrom ata0-master: type=cdrom, path=var/run/demo.iso, status=inserted mouse: enabled=1, type=imps2 log: ./bochs.out panic: action=fatal vgaromimage: file=/usr/local/share/bochs/VGABIOS-lgpl-latest vga: extension=vbe pci: enabled=1, chipset=i440fx, slot1=pcivga The Bochs version is the official release 2.5.1 configured with the following arguments: --with-x11 --enable-plugins --enable-pci --enable-clgd54xx Regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Performance of l4_task_unmap call
by Chen Tian 26 Apr '12

26 Apr '12

Hi, I did a small test: a parent task first maps and then unmaps a page to its child. Both parent and child task are running on the same core. I found the execution is very slow and 99% time are spent on l4_task_unmap( L4_FP_OTHER_SPACES flag is used). After some investigation, I found the flag "need_xcpu_tlb_flush" in map_util.cpp:766 is set to true. My guess is that this flag controls the tlb of the cpu at which the child task is running. However, in my case, both tasks are running on the same core, setting this flag can have huge negative impact on performance. I am thinking to put a check before this statement: if (current_cpu() != space's CPU) set the flag to true. Is this correct? If so, how to get space's cpu? space->cpu() ? Thanks for the help. Chen

2 1