l4-hackers January 2018

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

9 participants
11 discussions

Microkernel and alumni meetup
by Matthias Lange 11 Feb '18

11 Feb '18

Dear friends of the microkernel, it's about time for another microkernel and alumni meetup to catch up on all the developments of the last 6 months. Let's meet for a beer or two. To find a date that fits the most people please visit https://dudle.inf.tu-dresden.de/Microkernel_Meetup/ and add your preferred day. Regards, Matthias. -- Matthias Lange, matthias.lange(a)kernkonzept.com, +49-351-41 888 614 Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 2

MIPS Creator CI20 patches (again)
by Paul Boddie 06 Feb '18

06 Feb '18

Hello, I recently looked at the collection of patches accumulated when trying to get the CI20 support to a functioning state, and I think I've brought them up to date with the latest upstream repository version (r75). In doing so, I've also tried to break them up into distinct parcels of functionality so that the less interesting or less relevant patches can be ignored. A page describing the patches can be found here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html None of these patches have changed since previous discussions on this topic. The rdhwr instruction support I needed to add, for instance, is still done in MIPS assembly language, fitting in with existing support for another variant of that instruction. Anyway, I thought it might be useful to put them somewhere with a description for future reference. I've yet to get round to looking seriously at L4Re on the CI20 again and it isn't likely to happen now before the end of the year. Paul

2 13

Build problems on i386 (Fiasco-OC.UX)
by Paul Boddie 30 Jan '18

30 Jan '18

Hello, More awkward news from Debian on i386! I was looking to build the "Linux Usermode Platform" variant of Fiasco-OC on i386 (well, Pentium 4) and encountered a couple of issues. Firstly, "struct ucontext" is mentioned in src/kern/ux/usermode.cpp but has been deprecated in favour of "ucontext_t". There are some User Mode Linux reports about this: https://lkml.org/lkml/2017/11/15/159 https://lkml.org/lkml/2018/1/25/522 A search-and-replace involving the two terms fixes the compilation error that otherwise occurs. Secondly, linking of the kernel fails due to symbol conflicts between the minilibc functionality and glibc: /usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/libc.a(memcmp.o): In function `memcmp': (.text+0x0): multiple definition of `memcmp' libc.a(memcmp.o):/home/paulb/L4/UX-75/src/kernel/fiasco/src/lib/minilibc/memcmp.c:7: first defined here collect2: error: ld returned 1 exit status /home/paulb/L4/UX-75/src/kernel/fiasco/src/kern/ux/Makerules.KERNEL:35: recipe for target 'fiasco.debug' failed So, not knowing how best to deal with this, I relied on the --allow-multiple- definition linker option: https://gcc.gnu.org/ml/gcc-help/2009-09/msg00108.html I doubt that this is the right way to deal with it. Maybe GCC 6.4 (Debian 6.4.0-12) introduced some behaviour that is not compatible with the way this linking is being done. Both of the above issues are present in repository versions 74, 75 and 76 at the very least. Certainly, the first issue is not likely to be absent in earlier versions. Paul P.S. I have also been experiencing a build problem with L4Re on i386, but this will be described in another message.

2 2

Build problems on i386 (L4Re)
by Paul Boddie 30 Jan '18

30 Jan '18

As promised, my other error report... With Fiasco-OC built, I concentrated on building L4Re for i386, but this led to me encountering this rather frustrating error: [l4util] ==> Linking to shared libl4util.so /home/paulb/L4/UX-75/src/l4/mk/lib.mk:139: recipe for target 'libl4util.so' failed make[4]: *** [libl4util.so] Segmentation fault make[4]: *** Deleting file 'libl4util.so' ../../../../../mk/binary.inc:164: recipe for target '/home/paulb/L4/UX-75/src/l4/mybuild/pkg/l4re-core/l4util/lib/src/OBJ-x86_gen- l4f' failed This issue is present in repository versions 72 through 76. Again, I'm testing this with GCC 6.4 (Debian 6.4.0-12). I've not seen this at all when cross- compiling, either with the Debian or with Buildroot compilers. Paul

2 2

OS Engineers Wanted!
by Gernot Heiser 30 Jan '18

30 Jan '18

[Apology for the shameless ad, but might be of interest to some] Would you like to get paid for making the world more secure with seL4? I'm in charge of directing OS development for the newly-founded company Hensoldt Cyber. We will develop an integrated, highly-secure hardware-software solution, combined with secure production, aimed at changing the game in securing real-world embedded/cyber-physical systems. Needless to say, there will be close collaboration with the Data61 Trustworthy Systems team. We're now hiring engineers who will help us getting there. Specifically, we're looking for strongly-motivated people with practical experience in OS development, although there is flexibility with the degree of experience. Actual experience with L4 microkernels would be awesome. Place of work will be Munich (no remote work possible, sorry). You'll have to be prepared to obtain a German government security clearance (German citizenship is not a requirement for this). Interested? Please send me your CV. Gernot

1 0

Access ARM Data Fault Address Register (System Control Register) in Fiasco.OC
by Stark, Josef 26 Jan '18

26 Jan '18

Hey, in Fiasco.OC we have a function inside src/kernel/foc/l4/pkg/l4sys/include/thread.h > L4_INLINE l4_msgtag_t > l4_thread_ex_regs_ret(l4_cap_idx_t thread, l4_addr_t *ip, l4_addr_t *sp, > l4_umword_t *flags) L4_NOTHROW; which allows us for a given thread (capability ID) to read its general purpose registers, SP and IP. Is there a similar function (if not, how could I achieve it) to access the ARM A9 System control registers or, to be more precise, the Data Fault Address Register (DFAR) [1] of a thread? I tried creating a function similar to the above mentioned, but modified the body to do this: > unsigned int v; > asm volatile ("mrc p15, 0, %[v], c6, c0, 0" : [v]"=r"(v) :: ); and then write v back to the caller. But this just made the whole system hang. Any ideas? Thanks in advance! Best regards, Josef [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100511_0401_10_…

3 3

L4/Fiasco kernel debugger (jdb) and step over command
by Valery V. Sedletski 22 Jan '18

22 Jan '18

Hi. I'm trying to debug my program with jdb. (I'm using the old L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I enabled the permanent single step mode (with the S+ command) and a permanent show the Thread Control Block (with the t+ command) option. So, I was able to single-step with "g" command. Also, I found "jr" (go until return (ret or iret) is encountered) and "jb" (go until the next branch instruction, like jmp/call/int) commands, but they don't seem to work. When I enter them, I see only a single step to the next instruction. Are these two commands broken? How do I step over a "call"/"int" instruction? Thanks in advance, valery

3 11

Re: Question about vm memory initialization
by nico 11 Jan '18

11 Jan '18

2 2

Workaround to build l4linux for ARM Target
by Leslie Zhai 10 Jan '18

10 Jan '18

Hi l4 hackers, ../arch/l4/arm-mach-l4/l4.c:33:10: fatal error: l4/io/io.h: No such file or directory #include <l4/io/io.h> ^~~~~~~~~~~~ compilation terminated. so I just workaround to `ln -s` manually: build-freescale-imx6/include/l4/io/ ├── io.h -> /data/project/xiangzhai/l4re/l4/pkg/io/libio-io/include/io.h ├── pciids.h -> /data/project/xiangzhai/l4re/l4/pkg/io/io/server/libpciids/include/pciids.h └── types.h -> /data/project/xiangzhai/l4re/l4/pkg/io/libio-io/include/types.h l4re version: svn76 l4linux version: svn57 GNU toolchain: gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11) I think it might be `Makefile` simple issue :) -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

2 3

Question about vm memory initialization
by nico 10 Jan '18

10 Jan '18

Hi Adam, I started uvmm and found that all ram space allocated to vm are cleared. But I do not need to do that, because uboot has loaded image file to ram, and vm linux would use that image file. Could you tell me where the uvmm did the cleanup? Regards, Nico

4 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 January 2018