- l4-hackers - example.com Site

scanf is not working
by Raja Sekhar 10 Oct '13

10 Oct '13

Hello all, I'm trying to read input using scanf function. but it's not woring. what is the problem and how can i make it work. *Thanks & Regards* Raja Sekhar

2 1

issue while running l4re_fiasco on qemu-system-arm
by Raja Sekhar 10 Oct '13

10 Oct '13

Hello to all, I have cross compiled l4re-fiasco to panda_board and after running the image on Qemu. I'm getting blank screen and i'm not getting any console messages. and this is the command I used is as.. *$ *qemu-system-arm -M beagle -kernel /home/sets/l4re_work/Fiasco.OC-L4Re_arm/build_panda/L4Re/images/bootstrap.elf How to run l4re-fiasco on qemu-system-arm and what are the options i should provide to the command "qemu-system-arm". could please send me a immediate response..... * Thanks & Regards* Raja Sekhar

2 1

FOSDEM 2014 - CfP: Microkernels / Component-based OSes devroom
by Julian Stecklina 09 Oct '13

09 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FOSDEM 2014 - CfP: Microkernels / Component-based OSes devroom Fellow Operating System Hackers, built on the success of the microkernel devroom in the last years, FOSDEM 2014 [1] will host a devroom for developers of open-source microkernel- and component-based operating systems. The devroom is scheduled for Sunday, February 2nd, 2014. We are looking for talks in all areas related to microkernels and component-based operating systems. Possible subjects include, but are not limited to: - introduction of a specific OS or framework, - design of subsystems and general architecture of an OS, - hardware support, - success stories, experiences and lessons learned, - security and robustness, - improving the toolchain, - maintainance and testing, - higher-level languages for OS implementation, - community building. To submit a talk, please create an account at the conference's submission system [2] and select the devroom as the talk's track. Should there be any problems, please send a mail to the devroom mailing list [3]. In your submission, be sure to include: - Title and approximate length of the talk (in the General tab), - the correct track (also in the General tab), - a short abstract (in the Description tab). Talks should not exceed 45 minutes. To help us schedule, please indicate whether your talk is flexible in its length. Please submit your proposals before December 1st. We will announce acceptance and hopefully a rough schedule before Christmas. Of course, there are other ways to contribute and make this event a success, for example by doing a demo of your system. Small devices are no problem, but please check back with us, if you plan to bring larger equipment. Please forward this Call for Participation to anyone interested in participating! See you in Brussels, Julian Stecklina [1] http://fosdem.org/2014 [2] https://penta.fosdem.org/submission/ [3] https://lists.fosdem.org/listinfo/microkernel-devroom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlJVRToACgkQ2EtjUdW3H9k18wCg2Bk9GUuSoB/zoInMyj4Vtmgw 19UAoJQNcTh5funOqyg6ezRz7RY9sEeI =/Kfk -----END PGP SIGNATURE-----

1 0

L4Linux on AMD64 (again)
by Alexander Tarasikov 03 Oct '13

03 Oct '13

Hi, l4-hackers! This message is mainly directed to Adam because most of the work on the latest revisions of l4linux was done by him. I have noticed that AMD64 support is present in most of the arch-l4 code, so I have tried compiling the l4linux kernel in the amd64 mode. I have uncommented the “default y” switch in the KConfig to enable CONFIG_X86_64. Then, I fixed some minor compilation issues: * entry.S did not compile. I had to replace the bitwise or with summation, and replaced the X86_EFLAGS_BIT1 with the integer constant (well, I think I could’ve replaced it with X86_EFLAGS_FIXED) * replaced BIT1 with FIXED in some file, I think, head64.c * added the definition of the early page table count to head64.c (it *is* defined in pgtable-64.h, but I was lazy to figure out why it was not properly included) Then, I applied the amd64 patch to L4Re bootstrap (the one in the mailing list) and raised the modaddr to 0x4000000 to work around region conflicts. I have also launched qemu with 512M memory. First of all, the kernel crashed at the SLAB allocator because the cache pointer was uninitialized. Actually, it nanged in the “arch-l4/kernel/main.c” before calling start_kernel. The reason was that the “head_64.c” contained the code to clean the “early page tables” which wrote to the CR3 register. I have commented the writing to the CR3 and it allowed to move a bit further. Subsequently, I have commented out all the code in the file. SLAB allocator fails to allocate because the function “setup_cpu_cache” in the “mm/slab.c” file has the “init_refok” attribute which means it gets placed into the “ref” section. Selecting SLOB allocator makes it go further. Then, it crashed at the “console_init” call. Console_init calls con_init in “drivers/tty/vt.c”, which freezes at the “pr_info” statement (for some weird reason, it does not jump into the printk() from pr_info). It started working after I lowered the default printk level, so it’s a minor issue. Some more crashes were related to the debug/kmemleak init calls, vfs cache setup which I commented out. Eventually, I had the kernel output the debug via the ttyLv0, not via LOG_printf. It complained about some memory which was not within e820 range. The kernel did not fully boot, because the “init_rest” routine is also marked with “init_refok”. So, I think that only the code from the text section works and the pointers to other sections are invalid. Hope my findings will be useful. Now, I have some questions which could save a few hours of debugging. I would be very grateful if you could answer them: * Is amd64 support planned soon? * Could you explain which part of page table manipulation functions are needed, and which can be commented out? Should the page directory be written somewhere in vCPU instead of CR3? * What load_addr should be used? Zero or 0x100000 (I suspect the former). vG8tQK?z,P-UC`a -- Regards, Alexander

2 1

Re: error in bootstrap when building amd64
by Joel Nider 01 Oct '13

01 Oct '13

Hi, > > ? ==> Linking bootstrap32.elf > > /usr/bin/ld: skipping incompatible > > /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc.a when searching for -lgcc > > /usr/bin/ld: cannot find -lgcc > > collect2: ld returned 1 exit status > > make[4]: *** [bootstrap32.elf] Error 1 > > > Any ideas how to fix it? > > I guess a 32bit version of libgcc might be missing on your system. It is not clear to me why I need a 32-bit bootstrap image when I am trying to build a 64-bit kernel. Is it possible for me to disable/skip this particular file? Everything else seems to build fine. Thanks, Joel

2 1

L4Re::Util::Dataspace_svr
by Daniel Müller 30 Sep '13

30 Sep '13

Hello, L4Re::Util::Dataspace_svr's copy functionality is not very flexible. It only works for local dataspaces which I believe is insufficient. The problem is the "if (!src_cap.id_received())" construct in the L4Re::Dataspace_::Copy case in the dispatch method. Imo this should be something comparable to the validate_ds() method used in region_mapping_svr. Daniel

2 1

ARMV7 virtualization extensions support
by Karoline Haus 30 Sep '13

30 Sep '13

Good afternoon, I'd like to understand if the Fiasco kernel already supports ARM's virtualization extensions (like it supports VT-x and AMD-V), and if not, is that something you are working on? Many thanks for any pointers. Karoline

2 1

error in bootstrap when building amd64
by Joel Nider 30 Sep '13

30 Sep '13

Hi, I'm having trouble building the amd64 L4Re image. I'm building on Ubuntu 12.04 64-bit (kernel 3.2.0-29); make 3.81; gcc 4.6.3 (default) I'm using l4re-core-2013091917 (not the snapshot) that I got from here: http://os.inf.tu-dresden.de/download/snapshots-oc/l4re-core-2013091917.tar.… Everything builds fine until the 'bootstrap' package: === Building package "bootstrap" === make[1]: Entering directory `/home/joel/projects/l4re-core-2013091917/src/l4/pkg/bootstrap' make[2]: Entering directory `/home/joel/projects/l4re-core-2013091917/src/l4/pkg/bootstrap/server' make[3]: Entering directory `/home/joel/projects/l4re-core-2013091917/src/l4/pkg/bootstrap/server/src' make[4]: Entering directory `/home/joel/projects/l4re-core-2013091917/obj/l4/amd64/pkg/bootstrap/server/src/OBJ-amd64_K8' make[5]: Entering directory `/home/joel/projects/l4re-core-2013091917/src/l4/pkg/bootstrap/server/src/ARCH-amd64/libc32' make[6]: Entering directory `/home/joel/projects/l4re-core-2013091917/obj/l4/amd64/pkg/bootstrap/server/src/ARCH-amd64/libc32/OBJ-amd64_K8' make[6]: Leaving directory `/home/joel/projects/l4re-core-2013091917/obj/l4/amd64/pkg/bootstrap/server/src/ARCH-amd64/libc32/OBJ-amd64_K8' make[5]: Leaving directory `/home/joel/projects/l4re-core-2013091917/src/l4/pkg/bootstrap/server/src/ARCH-amd64/libc32' ==> Linking bootstrap32.elf /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status make[4]: *** [bootstrap32.elf] Error 1 Any ideas how to fix it? Thanks, Joel

2 1

About the use of C++11 features
by Johannes Schlatow 20 Sep '13

20 Sep '13

Hi, I just noticed that the current snapshot (2013-08-19) doesn't compile with gcc4.4 anymore, which is apparently due to some C++11 incompatibilities (see below). Based on the snapshot from April, I got the Fiasco.OC and L4Re port for the LEON3 (sparc) up and running and would like to merge this with the newest snapshot. Unfortunately, the LEON3 cross compiler (bcc) is based on gcc4.4. So...what's your policy about supporting oldish cross-compilers? And, by the way, how do you feel about including the LEON3 code in your repository? Cheers Johannes Here is the condensed output of a gcc4.4 compilation run: src/kernel/fiasco/src/lib/libk/cxx/function:34: error: ‘cxx::functor<Res(Args ...)>::functor(cxx::functor<Res(Args ...)>&&)’ cannot be defaulted src/kernel/fiasco/src/kern/map_util.cpp: In member function ‘void Mu::Auto_tlb_flush<Mem_space>::global_flush()’: src/kernel/fiasco/src/kern/map_util.cpp:78: error: expected primary-expression before ‘[’ token src/kernel/fiasco/src/kern/map_util.cpp:78: error: expected primary-expression before ‘)’ token src/kernel/fiasco/src/kern/map_util.cpp:741: error: expected primary-expression before ‘[’ token src/kernel/fiasco/src/kern/map_util.cpp:741: error: expected ‘(’ before ‘*’ token src/kernel/fiasco/src/kern/map_util.cpp:741: error: ‘m’ was not declared in this scope src/kernel/fiasco/src/kern/map_util.cpp:741: error: expected ‘(’ before ‘size’

2 1

Booting on Raspberry Pi
by Robert Kaiser 17 Sep '13

17 Sep '13

Hello, i'm currently trying to get Fiasco.OC + L4Re up and running on a Raspberry Pi, but no luck :-( I have gotten as far as building a bootstrap_hello.elf file. According to previous posts here, I should just copy this file to the first partition of a linux-bootable SD card, add an entry like "kernel=bootstrap_hello.elf" to config.txt, and I should see some messages at the serial port as the Pi boots L4. Alas, my Pi stays silent. If I then simply remove the added line from config.txt, leaving everything else the same, Linux boots from the card alright and I can see its messages on the serial port. Thus, I'm confident that my hardware set-up should be OK. I am not absolutely sure wether I got the building of the boot file right. What surprises me is that it is an ELF file: I have previously followed the "Baking Pi" tutorial at http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/. There I used to boot *raw* binaries which expected to be loaded at 0x8000. In contrast, this file here displays as an ELF file with .text starting at 0x01000000. Is that how it should be? The building process also creates a file named "bootstrap_hello", but that is simply a copy of bootstrap_hello.elf. What's the point of this? Thanks a lot for any help Robert Kaiser

2 10