l4-hackers May 2017

l4-hackers@os.inf.tu-dresden.de

9 participants
10 discussions

Porting Fiasco + L4Re to Raspberry Pi 2
by Antoine DEBUT 26 Nov '17

26 Nov '17

Hello l4-hackers, I am currently working on porting the Fiasco.OC micro kernel onto the Raspberry pi 2. Therefore, I am struggling with memory mapping, and I encounter the following error when launching the default 'hello' entry: L4 Bootstrapper Build: #2 Tue Feb 23 11:57:19 CET 2016, 4.8.3 20140303 (prerelease) Scanning up to 1024 MB RAM, starting at offset 32MB Memory size is 1024MB (00000000 - 3fffffff) RAM: 0000000000000000 - 000000003fffffff: 1048576kB Total RAM: 1024MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 1100000 moving module 02 { 10db000-110c4d7 } -> { 11cc000-11fd4d7 } [201944] moving module 01 { 10c9000-10da373 } -> { 11ba000-11cb373 } [70516] moving module 00 { 1043000-10c889f } -> { 1134000-11b989f } [546976] moving module 04 { 1029000-10425af } -> { 111a000-11335af } [103856] moving module 03 { 100f000-102849b } -> { 1100000-111949b } [103580] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x2000 Regions of list 'regions' [ 1000, 1aff] { b00} Kern fiasco [ 2000, 92fff] { 91000} Kern fiasco [ 93000, 930eb] { ec} Root mbi_rt [ c0000, c9c33] { 9c34} Sigma0 sigma0 [ d0000, d6177] { 6178} Sigma0 sigma0 [ 140000, 16905b] { 2905c} Root moe [ 170000, 17b58b] { b58c} Root moe [ 1000000, 100e4ff] { e500} Boot bootstrap [ 1100000, 1133fff] { 34000} Root Module API Version: (87) experimental Sigma0 config ip:000c0100 sp:00000000 Roottask config ip:00140250 sp:00000000 Starting kernel fiasco at 000012b8 Non-HYP kernel detected but running in HYP mode, switching back. Hello from Startup::stage2 Assertion failed at /home/adebut/Documents/snapshotTest/l4re-snapshot-2015123115/src/kernel/fiasco/src/kern/buddy_alloc.cpp:101: (unsigned long)block >= _base Press any key to reboot. I am currently working on the latest snapshot (2015123115), with U-Boot as a bootloader, and testing on a real board (Raspberry Pi 2 model B V1.1). The entry built is the standard 'hello', and I use the ramdisk-arm.rd given in the snapshot. I did add a custom Bsp for the board, mainly based on the first Raspberry Pi except for the Base Address, that is 0x3F000000 instead of the first Pi's 0x20000000. I highly think that it is an address configuration problem, because it first happened when I did expand the RAM size to 1024MB. With further investigation, I found out that it was the kernel memory allocation that causes this error, and suspect an incorrect MMU mapping. This suspicion comes from the fact that the assertion takes the address _base (0xf0400000) and the currently allocated block (0xee100000). I did not modify any parameter in the kern/arm/mem_layout-arm.cpp file on the Fiasco directory, which provides the default ARM addressing. Maybe that's where my error comes from ? How can I correctly configure my memory mapping, besides what I already configure in the Bsp (given in attachment) ? Also, it is the first time that I am assigned for porting a system, do you have some hints, like important steps to follow ? I am pretty sure it is a newbie error, but I cannot figure it out for now :( Thanks in advance for your time, -- Antoine Debut EPITA 2016 - GISTRE

3 7

Re: clang-5.0 is not supported. Please use one of the following versions
by Leslie Zhai 05 Jun '17

05 Jun '17

Hi Adam, Thanks for your reply! > we tend to defer to enable versions until they're actually released. Please remove 5.0 :) And what about LLVM's lld? I found it is only for ld https://svn.l4re.org/repos/oc/l4re/trunk/kernel/fiasco/src/kernel.amd64.ld correct? -- Regards, Leslie Zhai https://reviews.llvm.org/p/xiangzhai/

4 4

xorriso : FAILURE : Not a known command
by Leslie Zhai 02 Jun '17

02 Jun '17

Hi L4 hackers, When I Running hello.iso http://os.inf.tu-dresden.de/fiasco/build.html via *make grub2iso E=hello MODULE_SEARCH_PATH=/path/to/fiasco-build-dir *it failed to generate ISO, xorriso thrown such error: xorriso : FAILURE : Not a known command: '-f' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' Failed to create ISO at tool/lib/L4/Grub.pm line 123. Makefile:598: recipe for target 'grub2iso' failed so I simply changed the option: Index: tool/lib/L4/Grub.pm =================================================================== --- tool/lib/L4/Grub.pm (revision 72) +++ tool/lib/L4/Grub.pm (working copy) @@ -116,7 +116,7 @@ close A; }; my $cmd = "$mkr --output=\"$isofilename\" $dir ". - join(' ', @morefiles)." --$opt -f"; + join(' ', @morefiles)." --$opt -follow default"; system("$cmd"); die "Failed to create ISO" if $?; # grub-mkrescue does not propagate internal tool errors please review my patch, thanks a lot! -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

4 10

Graphical desktop, l4con, mag
by teclis High Elf 02 Jun '17

02 Jun '17

Guten Tag, I've got the Hello app runing with fiasco and l4re in qemu, how do I get the graphical UI and console running that I see on the screen shots page? Do I need to use l4con and mag? I don't see an entry with l4con in modules.list. danke * <http://german.about.com/library/media/Audio/gutentag.wav>*

6 15

Benchmarks in l4
by Maxim Baryshnikov 01 Jun '17

01 Jun '17

Hello everybody, Does the L4re contain some kind of simple performance benchmarks which are already prepared to use? I've tried to launch some demos from the ferret package but not succeed... Thank you in advance for any suggestions. Sincerely, Maxim Baryshnikov.

4 11

libfs/ FUSE on L4Re
by Stark, Josef 31 May '17

31 May '17

Hello, yesterday I came across a very interesting paper titled "Porting FUSE to L4Re", accessible here: http://os.inf.tu-dresden.de/papers_ps/pester-beleg.pdf For porting FUSE, the author uses a library called "libfs" which provides filesystem request forwarding and processing, if I understood correctly. It reads as if libfs is already included in L4Re. However, I couldn't find neither FUSE nor libfs in the current L4Re snapshot. Are they by any chance publicly available somewhere else, or are both not to be published? Cheers, Josef

4 7

Microkernel + Alumni Meetup
by Bjoern Doebel 30 May '17

30 May '17

Hi all, it has been a while since we last met for a beer. Water went down the Elbe river, companies were closed, companies were started, research papers got accepted, technical advancements were made. Let's catch up on all of that! To find a suitable time, please visit https://dudle.inf.tu-dresden.de/ukm-01-2017/ Bjoern

2 3

clang-5.0 is not supported. Please use one of the following versions
by Leslie Zhai 29 May '17

29 May '17

Hi L4 hackers, I am using clang (svn trunk 303321) to build fiasco, it thrown such error: kernel/fiasco/src/Makeconf:264: *** clang-5.0 is not supported. Please use one of the following versions: 3.5 3.6 3.7 3.8 so I simply add other versions for clang, please review my patch, thanks a lot! Index: kernel/fiasco/src/Makeconf =================================================================== --- kernel/fiasco/src/Makeconf (revision 72) +++ kernel/fiasco/src/Makeconf (working copy) @@ -245,7 +245,7 @@ CC_WHITELIST-gcc := 4.5 4.6 4.7 4.8 4.9 5 6 -CC_WHITELIST-clang := 3.5 3.6 3.7 3.8 +CC_WHITELIST-clang := 3.5 3.6 3.7 3.8 3.9 4.0 5.0 CC_WHITELIST := $(CC_WHITELIST-$(CC_TYPE)) CC_BLACKLIST-arm-gcc := 4.8.0 4.8.1 4.8.2 -- Regards, Leslie Zhai https://reviews.llvm.org/p/xiangzhai/

2 1

Share exist memory over IPC with L4Re
by Alexander Fratzer 16 May '17

16 May '17

Dear L4-Hackers, I have a very simple problem but I can't find the solution in the L4Re-Doc and examples so far. I wrote a very simple Unix-Like Shell with a Filesystem-Server and a Loader-Server and I implemented some Posix-Call as an abstraction for the communication with the Filesystem-Server (virtual). Now I have a problem of double copies for a read-Operation. I want a complete abstraction from the L4Re mechanisms and the underlying Client-Server architecture for the usage of this interface. The (bad) mechanism is as follow: Function (client side): ssize_t read(int fd, void *buf, size_t count) Algorithm: 1. Allocate Dataspace with size of count. 2. Send Cap of Dataspace to the Filesystem-Server. 3. Copy content of Dataspace to buf. 4. Cleanups. Function (server side): long VFSSrv::op_file_read(VFS::Rights, TaskRegistry::TaskId task, TaskRegistry::FileDescriptor fd, size_t size, L4::Ipc::Snd_fpage& flexp, size_t& rsize) Algorithm: 1. Get Dataspace-Cap from Ipc-fpage. 2. Reserve area with Region-Manager. 3. Attach Dataspace to the area. 4. Copy content of the file to the attached area. 5. Cleanups. This was my first working solution without focus on runtime but the creation of a new task from an ELF-File of 1.4 MB size takes 20 seconds on Cortex A8. This suxx so I have to optimize. Therefor I need a way to share the content of my file (virtual, heap allocated memory) without copying to the client but i don't find a way to share exist memory over IPC. I think I'm using the Dataspace-mechanism in a wrong way but maybe a Dataspace isn't the right choice in my case. A simple solution would be a new Filesystem which is based on Dataspaces but I don't want to do this. Have anybody a better idea? Thanks for help. Best regards Alex.

2 1

Fiasco.OC: null-pointer dereference?
by Stefan Kalkowski 09 May '17

09 May '17

Dear L4-Hackers, recently, I started to upgrade the Fiasco.OC kernel version that is used by the Genode OS framework to the lastly released version (r72). I took the opportunity to upgrade, because the upcoming Genode release uses a fresh compiler toolchain that refused to build the very old Fiasco.OC kernel version that was used until now (r56). Everything went quite smoothly, and I'm glad to see how the kernel develops further. Thanks to all developers at this point! Unfortunately, I stumbled across an issue when it comes to thread destruction. In our system all threads are constructed and destructed by the roottask that is called 'core'. In some cases, not always but quite often, the Ram_quota pointer of the thread object is zero during the call of the Thread_oject's delete operator, which leads to a page-fault within the kernel-code. A simple check[1] before dereferencing the pointer solves the problem, but I wonder whether we will leak quota or memory then, or in general cover some more serious problem. Obviously, we have different usage patterns of syscalls, e.g.: the order of destructing IPC-gates, threads, IRQs, and tasks. Moreover, we still have some very few patches[2] so that the kernel meets our requirements. But none of them explains the thread's Ram_quota pointer getting zero. The page-fault triggers across all x86 and arm platforms that we use. Any hint would be very much appreciated, all the best! Stefan [1] https://github.com/skalk/foc/commit/2b01c9d16fd8e29e6af18fe750be2c8a312b4762 [2] https://github.com/skalk/foc/commits/r72 -- Stefan Kalkowski Genode Labs https://github.com/skalk · http://genode.org/

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers May 2017