l4-hackers

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

2 participants
2880 discussions

23.10.1 amd64 l4linux doesn't build
by Richard Clark 12 Apr '24

12 Apr '24

Hi! I'm doing microkernel evaluations for a US gov't contract to find a nice shiny new replacement for the dismal little l4 microkernel they've been using and failing with... Fiasco/L4/L4linux seems to be a wonderfully full-featured software platform that easily fits the bill. Separation/Capability microkernel, fully developed user space, l4-native linux, and even a vmm that runs a sandboxed linux. Latest build with snapshot 23.10.1 and l4linux 23.10.1 seems the amd64 l4linux is broken with issues in libelf.h, gelf.h, and elf.h. 32bit build seems to build ok. Still trying to get something up and running. I'll try 32-bit with qemu for now. I do need 64-bit to compile and run, so I would appreciate any info on how to fix the build issues. Thanks! Richard H. Clark _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

3 6

uClibc and pthreads
by Pascal Scholz 25 Jan '24

25 Jan '24

Hello to all L4-Hackers out there, I'm currently investigating the pthread Implementation used in L4Re for an university project. To me it seems, that it's using Linuxthreads as pthread implementation of the uClibc. Regarding this I got two questions, of which I would be very happy, if someone could answer them: 1) Is there a technical reason for L4Re still using the Linuxthreads implementation and not some kind of NPTL port or other implementations? 2) What uClibc is used exactly? Do you manage your own fork of uClibc and back port relevant patches of uClibc-ng? Or do you use a uClibc-ng with additional L4 patches? Or some completely other version? It seems that the uClibc version used diverged in 2014 from the original. This seems relevant to me as I wanted to check, which changes were done to make the uClibc work with L4 (in an attempt to generate some kind of a diff), so I might port them to another libc implementation. In my project I would like to replace Linuxthreads with some other pthreads implementation and measure the performance impacts of these changes, so the aforementioned questions seem relevant to me. Thanks in advance for you time! Kind regards, Pascal _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

2 2

Which C++ version does Fiasco use
by teclis High Elf 29 Dec '23

29 Dec '23

Hi, There are a lot of C++ versions. Is Fiasco L4Re compliant with the current C++20 standard? regards, _______________________________________________ l4-hackers mailing list -- l4-hackers(a)os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave(a)os.inf.tu-dresden.de

3 2

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2024
by Martin Decky 15 Nov '23

15 Nov '23

Microkernel and Component-based OS Devroom at FOSDEM 2024 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based, unikernel-based and component-based operating systems will meet as part of FOSDEM 2024 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and other activities related to microkernel-based, unikernel-based, component-based operating systems and similar areas. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * languages, tools and toolchains used * enabling support for hardware (architectures, device drivers) and programming languages * development processes, debugging * maintenance, testing and release engineering * safety, security and robustness * trends and challenges * research and open questions * community and governance * use cases, experiences and status updates * best practices and lessons learned * demos The devroom has been scheduled to Saturday February 3rd 2024 in the afternoon (Central European Time). This is a call for your participation. We kindly ask you to submit your proposals no later than on December 10th 2023 (End of Day, Anywhere on Earth). Please use the pretalx [2] web site to submit your proposals. Note that this is a new submission system and the user accounts from the previous submission system (pentabarf) have not been transferred. Make sure to select the Microkernel and Component-based OS as the track when submitting your proposal and include at least the following information: * title of your proposal * short abstract (one or two paragraphs) * duration (at least 15 minutes and no longer than 40 minutes) * your full name * your short bio You can specify your preferred time slot of your proposal and any other relevant information. The communication language of the devroom is English. Please note that the devroom has been allocated only a half of a day this year. Therefore the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. The official devroom schedule (along with the accepted talks) will be announced on December 15th 2023 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will be published on the FOSDEM web site, too. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community, a kind of "extended family meeting" and it is one of the places where microkernel and unikernel enthusiasts meet regularly. To this date, over two dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. As every previous year, the devroom will offer the "stage" both to established community members and to newcomers. We like to select the talks in an inclusive manner, while staying true to the main technical topics (system-level software, broadly speaking) and creating a balanced and unbiased schedule. We would like to keep the quality bar of the devroom same as in the previous years. Presenting at FOSDEM implies that the recordings of the talks will be published under Creative Commons license by FOSDEM. By submitting a proposal, the speaker agrees to have the talk made available publicly indefinitely. For organizational purposes, we also need contact information of the speakers of accepted talks. Microkernel Dinner It has also become a habit that the devroom participants dine together somewhere in Brussels. The year 2024 will not be any different, so there is going to be a dinner on Saturday night. We will inform you about the exact arrangements later. About FOSDEM FOSDEM [5] is a two-day conference organized by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognized as one of the largest and best such events worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 8000 developers annually at the ULB Solbosch Campus in Brussels, Belgium. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary. Attendees are expected to follow the FOSDEM's code of conduct [6]. Important Dates Recap * 2023-12-10: Deadline for proposal submission * 2023-12-15: Schedule published and speakers notified of acceptance * 2024-02-03: Devroom taking place Contact For any comments, questions and suggestions, please do not hesitate to use the devroom's mailing list [3] to contact the devroom organizers. The primary organizers of the devroom in 2024 are: * Martin Decky * Razvan Deaconescu References [1] https://fosdem.org/2024/ [2] https://pretalx.fosdem.org/fosdem-2024/cfp [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] https://fosdem.org/ [6] https://fosdem.org/2024/practical/conduct/

1 0

L4Re: stack allocation of moderately large arrays
by Paul Boddie 13 Nov '23

13 Nov '23

Hello, Having seen a problem recur in programs running in L4Re just now involving arrays of a relatively large size allocated statically in functions - about 100000 bytes or so - I was wondering if there are any implicit limitations with this form of allocation in L4Re. Is it possible that programs have a limited stack size and that the stack does not expand? Here is an example of the kind of code that causes an unhandled exception: uint32_t Spi_gpio::send_units(uint32_t bytes, const uint8_t data[], uint8_t unit_size, uint8_t char_size) { uint32_t chars = bytes / unit_size; int dc[chars]; And the exception looks like this: Unhandled exception: PC=0x1019ca8 PFA=0xfffd075a LdrFlgs=0x0 The actual cause of the exception is an access to an element in the dc array. When I eventually get back to my own experiments with initiating programs in L4Re - not involved with the problem reported here - I intend to look more closely at program stack allocation and expansion strategies, so I suppose this is an appropriate prelude to such work. Thanks for any guidance that might be offered, as always! Paul

2 1

L4Re: Input via UART fails with Ned involvement
by Paul Boddie 19 Sep '23

19 Sep '23

Hello, I have been trying to get some sensible behaviour from various programs running in L4Re that wish to read from standard input, hopefully using the UART, since standard output is successfully sent across the serial connection. However, it appears that Ned does something rather undesirable with the input stream. If I modify the hello example to use fgets and deploy it without Ned (the hello.cfg example in conf/examples), as long as some kind of serial initialisation has occurred, I can enter characters at the serial console and have the program read them. However, if I deploy the same code using Ned (the hello.cfg example in conf/examples), fgets repeatedly returns NULL. Strangely, if I follow the instructions in the L4Re documentation... https://l4re.org/doc/l4re_servers_ned.html#l4re_ned_interactive The ned-prompt program itself just prints "Cmd>" over and over again, failing to read anything. It is as if non-blocking I/O has been enabled, although ned- prompt appears to use readline, so I imagine that there is likely to be a somewhat different explanation. Attempting to enforce non-blocking input using fcntl in the hello example also does not help. Has anyone any suggestions as to why these things do not work? I have tried this on physical hardware as well as in QEMU. Thanks in advance, Paul

2 3

L4Re uvmm guest OS
by Radu Aron 22 Aug '23

22 Aug '23

Hi, Is it possible to have a Windows guest OS running on top of L4Re? If so, could you provide some insight into how that could work? It seems like uvmm doesn't allow booting from an ISO image, or am I missing something?

2 1

ARM TrustZone with UVMM
by Michael Willig 11 Jun '23

11 Jun '23

Hi all, I would like to try Fiasco/L4Re for a Mixed-Critical Xilinx UltraScale+ FPGA-MPSoC (the hardware accelerators on the FPGA should be virtualized/isolated for mixed-critical applications) Is there somewhere an example (or at least starting point) of an ARM Trustzone configuration of a Normal World VM and Secure World VM (with UVMM/Fiasco as hypervisor that also takes care of the ARM Trustzone configuration)? Best regards Micha

2 1

L4Re: Allocating pinned memory and obtaining its physical address
by Paul Boddie 24 May '23

24 May '23

Hello, Sorry to be lazy and not dig too deeply into the documentation and code, but once upon a time it was possible to use the l4re_ma functions to allocate pinned memory. Then, one would use the dataspace protocol to obtain the physical address of the memory via the capability involved in memory allocation. This exercise would be sufficient to get into a position to initialise peripherals in a system-on-a-chip, setting registers with the physical memory addresses they would need for things like DMA. The initialisation of things like framebuffers would rely on this procedure. I see that the "phys" operation in the dataspace protocol was discarded some time ago, and now there is a "DMA space" abstraction instead: https://l4re.org/doc/group__api__l4re__c__dma.html Are there any examples of how I might obtain a physical address associated with a block of memory using this new API? Thanks in advance for any guidance that might be offered! Paul

3 5

L4Re: Boot module copying and the MIPS Creator CI20
by Paul Boddie 21 May '23

21 May '23

Hello, As part of reviewing my earlier efforts getting L4Re running on various MIPS- based devices, I have been trying to get the bootstrap module to start the kernel on the MIPS Creator CI20, and here I encounter a strange problem. The bootstrap code appears to copy the different modules in the payload around in memory, and for the kernel, it finds the different sections at 0x2f4000 in physical memory (accessed via 0x802f4000), copying them into locations relative to the indicated module base address (for example, 0x1100000 or 0x2000000). From their new locations, each section of the kernel is then copied to its desired final address. So, the section of the kernel providing its entry point can be found at 0x2f4000 + 0xa411c, this being copied to base + 0xa411c, before finally being copied to 0x800d3000. However, the contents of memory at the final location (0x800d3000) are not correct, nor are they at the "staging" location of base + 0xa411c, even though they do correspond to the expected contents of the kernel binary at their original location. What I expect to see at the entry point is... 40806000 mtc0 zero,c0_status 000000c0 ehb What I see instead is... ffffffff bea3ffdf Apart from at the original location in the payload (0x2f4000 + 0xa411c). As far as I can tell, the second word is nonsense, and it is usually followed by more ffffffff words. So, it is as if copying failed for this particular section. Oddly, this only seems to affect the section of the kernel providing the entry point, and all other sections appear to be copied correctly from their original locations. One factor might be that this section is the last one that is copied. Does this seem like recognisable behaviour of some kind of misconfiguration? For the most part, I am just rebasing my old patches on the current L4Re and Fiasco versions, so I didn't expect a problem at this level. Regards, Paul

3 12

building x86-32
by Lieutenant_Beaver＠web.de 11 Mar '23

11 Mar '23

3 3

GI Operating-Systems + Fault Tolerance Meeting
by Horst Schirmeier 26 Jan '23

26 Jan '23

Hello microkernel hackers from Dresden and afar, the German Society of Informatics (GI) has a Special Interest Group on Operating Systems ("Fachgruppe Betriebssysteme" [1]), with members from both academia and industry. This group meets twice a year to network and to discuss their current work. The upcoming spring meeting, organized together with GI's fault-tolerance SIG ("Fachgruppe Fehlertolerierende Rechensysteme" [2]) will be hosted by TU Dresden on March 06+07 (noon to noon). Please consider attending and/or submitting a talk (details below and on the following website): https://www.betriebssysteme.org/aktivitaeten/treffen/2023-dresden/ Best regards, Horst Schirmeier [1] https://betriebssysteme.org [2] https://fg-fers.gi.de/ === Topic: "Operating Systems and Dependable Systems" === Dependability – the totality of safety, security, availability, reliability, and maintainability – is a fundamental attribute of safety-critical hardware and software systems. In the automotive industry, for example, current trends in autonomous driving present entirely new challenges in marrying fault tolerance and maximum performance while keeping costs low. The answers to these research questions ultimately call for a comprehensive investigation of the interactions between applications, system software, and hardware. In this spirit, the joint spring meeting of the GI's "Operating Systems" (FGBS) and "Fault-Tolerant Computing Systems" (FERS) special interest groups will be focusing on novel approaches to the analysis, design, and evaluation of dependable systems and on the exchange of ideas between the two communities. Areas of interest for submissions include, but are not limited to: - Fault tolerance mechanisms at all layers of the system - Dependability and real-time - Isolation and integration mechanisms in software - Test, analysis, evaluation, and verification - Robust system architectures and HW/SW co-design - Practical and field reports on safety-critical systems and their applications - Models, development processes, and standards Contributions outside the main focus of the event are most welcome as well. Please submit either a one-page abstract (presentation only) or a 2- to 4-page unpublished paper (ACM conference style) in German or English. A program committee consisting of members of the two steering boards will review the submissions and decide on their acceptance. In case of acceptance, papers (2-4 pages) will be published in the digital library of the Gesellschaft für Informatik. We explicitly welcome presentations in English. The talks' language will be indicated in the program to facilitate non-German members' participation in our workshops in the future. The event will also be organized in a hybrid format. -- Prof. Dr.-Ing. Horst Schirmeier Professur für Betriebssysteme Technische Universität Dresden Fakultät Informatik 01062 Dresden Tel.: +49 (351) 463-38321 office: Andreas-Pfitzmann-Bau, R.3102 Nöthnitzer Str. 46, 01187 Dresden (Campus-Navigator: https://tud.link/seh0) https://tud.de/inf/os

1 0

L4Re: uClibc and UTCB/TCR initialisation
by Paul Boddie 01 Oct '22

01 Oct '22

Hello, I have been working through reimplementing the mechanisms involved with launching programs in L4Re, managing to initiate programs apparently successfully under QEMU emulating amd64 and x86, but I have been less successful getting them to work under QEMU emulating a MIPS system (MIPS Malta). My arrangement of threads within tasks should be fairly similar to what L4Re normally employs to host and run programs, and I wrote it up here: "Gradual Explorations of Filesystems, Paging and L4Re" https://blogs.fsfe.org/pboddie/?p=2540 The pictures at the end summarise what has been done. I have a region mapper running in a thread in the same task as the program to be launched. The region mapper handles page faults and interacts with dataspaces on the program's behalf. Faults caused by the region mapper are handled by the initiating task. What I seem to have avoided previously but now experience is that after the region mapper has been started, it is able to service page faults, but after a certain point in the execution of the program of interest, the region mapper itself experiences an exception in the __pthread_cleanup_push_defer function within uClib's pthreads implementation, specifically at this line: buffer->__canceltype = THREAD_GETMEM(self, p_canceltype); Digging into this, I found that self is apparently zero. Since self is obtained from a call to thread_self which in turn obtains the user[0] member of the thread control register structure (providing the thread descriptor address), I can only conclude that either this member has not been initialised or that it has been overwritten by the other thread as it started up. Investigating uClibc startup, I notice that pthread initialisation does indeed involve a traversal of UTCB areas, zeroing user[0] in the supposedly free UTCB blocks. And with the region mapper having failed, the main program will also fail fairly quickly, with an exception typically occurring in the __pthread_initialize_minimal function, coincidentally just after this zeroing has occurred, just before a call to __libc_setup_tls. I have been looking for hints as to how this work is done in L4Re normally. Given that the region mapper and the program being run are normal programs that are executed via their conventional entry points, this resulting in the initialisation of the C library and threading for each payload, it seems that some measures must be in place to prevent this initialisation from causing conflicts in the UTCB area. For instance, I see that in the file... pkg/l4re-core/l4re_kernel/server/src/main.cc ... the __libc_alloc_initial_tls function is redefined to presumably override the weakly referenced version in uClibc, but if this were invoked it would probably cause uClibc to fail during initialisation, at least unless the zero page is going to be used (but it would need allocation somewhere else), so maybe it doesn't override anything after all. In any case, this function would only change some aspects of how __libc_setup_tls would work, so maybe it is a distraction. I did wonder if there was something specific about MIPS that would cause this failure, investigating the user-local register (ULR) used to hold UTCB-related information, but getting the UTCB address via the ULR would appear to work: otherwise, the region mapper would probably not start up. I also wondered about program initialisation issues, since I did experience problems on actual MIPS hardware related to various registers not being set up correctly, but the generated code seems fairly comprehensive in this regard these days (and maybe it was all along but I encountered a confounding phenomenon). Does anyone have any familiarity with how this actually works and might be able to indicate what I am doing wrong? As always, thanks for any help that can be offered! Paul

1 1

Creating tasks and the l4_task_map function
by Paul Boddie 01 Oct '22

01 Oct '22

Hello, I finally got round to experimenting with L4Re again, but in attempting to investigate task creation, I seem to have some difficulties understanding the mechanism by which tasks are typically created and how the l4_task_map function might be used in the process. After looking at lots of different files in the L4Re distribution, my understanding of the basic mechanism is as follows: 1. Some memory is reserved for the UTCB of a new task, perhaps using the l4re_ma_alloc_align function (or equivalent) to obtain a dataspace. 2. A task is created using l4_factory_create_task, indicating the UTCB flexpage, with this being defined as... l4_factory_create_task(l4re_env()->factory, new_task, l4_fpage(utcb_start, utcb_log2size, L4_FPAGE_RW)) 3. A thread is created using l4_factory_create_thread. l4_factory_create_thread(l4re_env()->factory, new_thread) 4. The thread attributes are set using the l4_thread_control API. 5. The l4_thread_ex_regs function is used to set the instruction pointer (program counter) and stack pointer of the thread. 6. The l4_scheduler_run_thread function is used to initiate the thread. The expectation is that the thread will immediately fault because there is no memory mapped at the instruction pointer location. However, it seems to me that it should be possible to use l4_task_map to make a memory region available within the task's address space, although I don't ever see this function used in L4Re for anything. (The C++ API makes it difficult to perform ad-hoc searches for such low-level primitives, in my view, so perhaps I am missing use of the equivalent methods.) Tentatively, I would imagine that something like this might work: l4_task_map(new_task, L4RE_THIS_TASK_CAP, l4_fpage(program_start, program_log2size, L4_FPAGE_RX), task_program_start) Here, the program payload would be loaded into the creating task at program_start, but the new task would be receiving the payload at task_program_start, with the configured instruction pointer location occurring within the receive window (after task_program_start, in other words). There are, of course, many other considerations around creating tasks, which I have noted from looking at the different packages (libloader, l4re_kernel, moe, ned), and I am aware that a few other things need to be done to start a task such as... * Defining capability selectors and mapping appropriate capabilities to the new task. * Creating a stack for the task and populating it with arguments and environment information. * Defining a suitable pager and exception handler, with this usually being provided by the l4re binary, as I understand it. Also, when actually dealing with program loading generally, I realise that the ELF binary needs to be interpreted and the appropriate regions associated with different parts of memory, this typically being handled by the region mapper/ manager in L4Re. And there is also the matter of dynamic library loading. But here, I am just attempting to establish the basic mechanism when a task starts up. Unfortunately, the only discussion I found was this (after some initial discussion about a related topic): http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/015366.html There are various examples in Subversion (maybe somewhere in the Git repositories, too) that create tasks or threads, but I don't find them particularly helpful, apparently being oriented towards very specific applications. A previous example was referenced in the above thread for the older L4Env system (or maybe an even earlier system): http://os.inf.tu-dresden.de/pipermail/l4-hackers/2000/000384.html As for why I would be wondering about such things - a question inevitably asked in the first thread referenced above - I firstly want to be able to understand the mechanism involved, but I also want to be able to integrate work I have been doing on file paging into task creation. Although I can probably do this by customising the "app model" normally used by the different loaders, it seems that I would need to construct an alternative l4re binary, which is rather cumbersome and perhaps a weakness of the abstractions that are provided, these being rather oriented towards obtaining dataspaces via the namespace API which I don't want to have to support in my filesystem. In any case, I wonder if there are any resources that describe the use of l4_task_map and the details of the program environment within tasks. Paul

4 26

Is there a benchmark for the IPC of L4Re?
by Mincheol Sung 23 Sep '22

23 Sep '22

Hi, I am trying to measure the performance of the IPC of L4Re. I am wondering whether there is a benchmark for the IPC performance. Mincheol

2 1

Build for x86_64 bare-metal machine
by Mincheol Sung 19 Sep '22

19 Sep '22

Hi guys, I am hanging out with L4, but couldn't find instructions/tutorials for building L4Re for an x86_64 bare-metal machine. Can you point me in the right direction? Thanks in advance. Mincheol

2 1

NXP LX2160 Uboot Fail
by rib0327 11 Sep '22

11 Sep '22

Hi, I am currently trying to get the L4Re running on the NXP LX2160 with U-Boot. When I try to load a .uimage I get the following error message: FDT and ATAGS support not compiled in Thank you in advance for your help.

2 3

Problem with newest Git-Version (RPi4)
by rib0327 28 Aug '22

28 Aug '22

Hello everyone, We have a question regarding the newest Kernel version available on Git (current date: 11.08.2022). We are working on an application and have come across a problem. In a previous Git version of the Kernel we had no problem building the .uimage file; however, with the newest update we found out that the .uimage file cannot be built. Here the working version (older one): Buildung local Project exampleApp [ExampleApp_Git] ... Compiling src/main.o [ExampleApp_Git] ==> Linking exampleApp [ExampleApp_Git] ==> exampleApp built [ExampleApp_Git] ==> Installing exampleApp to local build-tree Building L4Re uimage with Application exampleApp make[1]: Entering directory '/home/dev/L4Re_Git/l4' Building entry "exampleApp". Merging images: mod00: /home/dev/L4Re_Git/build-fiasco//fiasco [436kB] mod01: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/sigma0 [36kBBuildung local Project exampleApp [ExampleApp_Git] ... Compiling src/main.o [ExampleApp_Git] ==> Linking exampleApp [ExampleApp_Git] ==> exampleApp built [ExampleApp_Git] ==> Installing exampleApp to local build-tree Building L4Re uimage with Application exampleApp make[1]: Entering directory '/home/dev/L4Re_Git/l4' Building entry "exampleApp". Merging images: mod00: /home/dev/L4Re_Git/build-fiasco//fiasco [436kB] mod01: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/sigma0 [36kB] mod02: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/moe [226kB] mod03: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/l4re [117kB] mod04: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/exampleApp [174kB] [bootstrap] ... Generating bootstrap.ld [bootstrap] ... Compiling startup.o [bootstrap] ==> Linking bootstrap.elf [bootstrap] ==> Image post-processing bootstrap.elf [bootstrap] ==> bootstrap.elf built ==> Installing bootstrap.elf in image directory ==> Installing bootstrap_exampleApp in image directory ==> Installing bootstrap_exampleApp.elf in image directory [bootstrap] ... Generating bootstrap.raw ==> Installing bootstrap.raw in image directory ==> Installing bootstrap_exampleApp.raw in image directory [bootstrap] ... Generating bootstrap.uimage Image Name: L4 Image #3 Created: Thu Aug 11 09:11:24 2022 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1099688 Bytes = 1073.91 KiB = 1.05 MiB Load Address: 01000000 Entry Point: 01000000 ==> Installing bootstrap.uimage in image directory ==> Installing bootstrap_exampleApp.uimage in image directory Image size(s) in bytes: bootstrap_exampleApp.elf: 1534296 bootstrap.raw: 1099688 bootstrap.uimage: 1099752 Start address: 0x1000000 --> Build-Nr: 3 [bootstrap] ==> Installing bootstrap.elf to local build-tree [bootstrap] ==> Installing bootstrap_exampleApp to local build-tree [bootstrap] ==> Installing bootstrap_exampleApp.elf to local build-tree make[1]: Leaving directory '/home/dev/L4Re_Git/l4' DONE - bootstrap_exampleApp.uimage copied to /tftp/! ] mod02: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/moe [226kB] mod03: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/l4re [117kB] mod04: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/exampleApp [174kB] [bootstrap] ... Generating bootstrap.ld [bootstrap] ... Compiling startup.o [bootstrap] ==> Linking bootstrap.elf [bootstrap] ==> Image post-processing bootstrap.elf [bootstrap] ==> bootstrap.elf built ==> Installing bootstrap.elf in image directory ==> Installing bootstrap_exampleApp in image directory ==> Installing bootstrap_exampleApp.elf in image directory [bootstrap] ... Generating bootstrap.raw ==> Installing bootstrap.raw in image directory ==> Installing bootstrap_exampleApp.raw in image directory [bootstrap] ... Generating bootstrap.uimage Image Name: L4 Image #3 Created: Thu Aug 11 09:11:24 2022 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1099688 Bytes = 1073.91 KiB = 1.05 MiB Load Address: 01000000 Entry Point: 01000000 ==> Installing bootstrap.uimage in image directory ==> Installing bootstrap_exampleApp.uimage in image directory Image size(s) in bytes: bootstrap_exampleApp.elf: 1534296 bootstrap.raw: 1099688 bootstrap.uimage: 1099752 Start address: 0x1000000 --> Build-Nr: 3 [bootstrap] ==> Installing bootstrap.elf to local build-tree [bootstrap] ==> Installing bootstrap_exampleApp to local build-tree [bootstrap] ==> Installing bootstrap_exampleApp.elf to local build-tree make[1]: Leaving directory '/home/dev/L4Re_Git/l4' DONE - bootstrap_exampleApp.uimage copied to /tftp/! And now the faulty one (latest version): Buildung local Project exampleApp [ExampleApp_Git] ==> Linking exampleApp aarch64-linux-gnu-ld: cannot find ./src/main.o: No such file or directory make[1]: *** [/home/dev/L4Re_Git/l4/mk/prog.mk:125: exampleApp] Error 1 make: *** [/home/dev/L4Re_Git/l4//mk/binary.inc:159: /home/dev/L4Re_Git/build-l4re/ext-pkg/home/dev/L4Re_Dev/ExampleApp_Git/OBJ-arm64_armv8a-l4f] Error 2 Building L4Re uimage with Application exampleApp make[1]: Entering directory '/home/dev/L4Re_Git/l4' Could not find 'exampleApp' within paths /home/dev/L4Re_Git/build-fiasco/ /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f /home/dev/L4Re_Git/build-l4re/lib/arm64_armv8a /home/dev/L4Re_Git/build-l4re/lib/arm64_armv8a/l4f Processing of entry exampleApp in /home/dev/L4Re_Git/l4/conf/modules.list failed! make[3]: *** No rule to make target 'processing-of-module-list-failed', needed by 'mod.make.inc'. Stop. make[2]: *** [../../../../mk/binary.inc:159: /home/dev/L4Re_Git/build-l4re/pkg/bootstrap/server/src/OBJ-arm64_armv8a] Error 2 make[1]: *** [Makefile:544: uimage] Error 2 make[1]: Leaving directory '/home/dev/L4Re_Git/l4' make: *** [Makefile:6: do-all-make-goals] Error 2 cp: cannot stat '/home/dev/L4Re_Git/build-l4re/pkg/bootstrap/server/src/OBJ-arm64_armv8a/bootstrap_exampleApp.uimage': No such file or directory DONE - bootstrap_exampleApp.uimage copied to /tftp/! This does not happen if we create the image of ‘hello’. The problem is that the main.c file in the exampleApp does not get compiled before being linked à aarch64-linux-gnu-ld: cannot find ./src/main.o: No such file or directory. Everything was added correctly in modules.list. Does it depend on the newest update or did we make a mistake somewhere? In the attachment you will also find the build_all.sh file we used to build the image and also the Makefile for exampleApp. Thank you in advance for your help. Many regards, Mauro, Ricardo

2 1

Qemu cannot launch pre-built epi images using OVMF.fd
by 郭聪 12 Jul '22

12 Jul '22

Hi, I cannot launch those amd64 pre-built epi images with Qemu 4.2.1 on Ubuntu 20.04. All the pc images are fine. I have added the '-bios /usr/share/qemu/OVMF.fd' option. There is a warning "KERNEL: Warning: ACPI: Could not find RSDP, skip init" and then "no console will be available to OS". It seems that the first warning is from Fiasco, in fiasco/src/kern/acpi.cpp. I guess this is because the ACPI version. How can I solve this issue? Does anyone see the same problem? Thank you very much!

2 2

How to build a bootable l4linux image
by 郭聪 04 Jul '22

04 Jul '22

Hi, I am new to l4re. I am trying to boot a l4re image on an amd64 machine. I use dd to write pre-built-images (efi.iso) to a usb stick. I got the "no suitable video mode found" error. My BIOS has only the UEFI mode. How can I solve this error? BTW, I find how to build grub2iso of modules, but I do not know how to build a efi.iso like those pre-built ones. Could you please tell me the steps to build such an image? How can I modify the grub.conf file? Thank you!

1 0

Unresolved page faults when running l4linux-mag
by Haohui Mai 18 Apr '22

18 Apr '22

Hello, I'm trying to run the l4linux-mag example in the L4Re snapshot. It seems it will result in an unresolved page fault using the current snapshot (22.01.0): Loading: rom/ramdisk-amd64.rd INITRD: Size of RAMdisk is 4096KiB RAMdisk from 01816000 to 01c16000 [4096KiB] l4lx_thread_create: Created thread 429 (timer0) (u:b3001c00, v:00000000, sp:01557f28) WARNING: Unknown rdmsr: c0000100 at 0x212a20 WARNING: Unknown wrmsr: c0000100 at 0x212a33 WARNING: Unknown rdmsr: c0000100 at 0x212a4f WARNING: Unknown wrmsr: c0000100 at 0x212a70 Non-resolvable page fault at 3612f82, ip 302265. Page fault (non-resolved): pfa=3612f82 pc=302265 Non-resolvable page fault at 3612f82, ip 302265. Page fault (non-resolved): pfa=3612f82 pc=302265 qemu-system-x86_64: terminating on signal 2 Changing the console from ttyS0 to ttyLv0 will go a little bit further, but still result in a page fault: BUG: unable to handle page fault for address: 0000000003612f80 #PF: user write access in kernel mode #PF: error_code(0x0006) - not-present page PGD 0 P4D 0 Oops: 0006 [#1] SMP CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-l4-ge2ad9258b98e #2 RIP: 0028:cache_alloc_refill+0x365/0x610 Code: 54 24 24 31 db 85 d2 74 2e 49 8b 44 24 50 48 85 c0 74 11 89 df 41 0f af 7c 24 14 49 03 7d 28 ff d0 0f 1f 00 49 8b 55 20 89 d8 <88> 1c 02 83 c3 01 41 39 5c 24 24 77 d2 45 85 f6 0f 85 fd 01 00 00 RSP: 319f9f00:000000001006bca0 EFLAGS: 00000246 ORIG_RAX: 00000000000000f0 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 6db6db6db6db6db7 RDX: 0000000003612f80 RSI: 0000000000000001 RDI: 0000000000e57840 RBP: 000000000000003c R08: 00000000000194ff R09: 0000000000000002 R10: 00000000000194f8 R11: 0000000000000006 R12: 000000001001fc00 R13: 00000880000bd3f0 R14: 0000000000000400 R15: 0000000000000dc0 FS: ffffffffffffffff(0000) GS:ffffffffffffffff(0000) knlGS:ffffffffffffffff CS: 0028 DS: 0023 ES: 0023 CR0: ffffffffffffffff CR2: ffffffffffffffff CR3: ffffffffffffffff CR4: ffffffffffffffff Call Trace: ? idr_alloc_cyclic+0x52/0xb0 kmem_cache_alloc+0xc7/0xe0 __kernfs_new_node.constprop.0+0x59/0x1a0 ? vsnprintf+0x3e6/0x5b0 ? kernfs_link_sibling+0x8d/0xd0 ? kernfs_next_descendant_post+0x7d/0x90 ? kernfs_activate+0x5a/0x80 ? kernfs_add_one+0xdd/0x130 kernfs_new_node+0x1b/0x40 __kernfs_create_file+0x20/0xb0 sysfs_add_file_mode_ns+0x96/0x180 sysfs_create_file_ns+0x5d/0x90 bus_create_file+0x3f/0x60 bus_register+0x180/0x240 subsys_system_register+0x16/0x40 ? ntp_init+0x21/0x21 init_clocksource_sysfs+0xe/0x1f do_one_initcall+0x44/0x190 kernel_init_freeable+0x161/0x1ab ? rest_init+0xb0/0xb0 kernel_init+0x11/0x100 Any ideas to debug this? Your help is appreciated. Thanks, Haohui

2 3

Where is the latest L4Linux repo?
by Haohui Mai 04 Mar '22

04 Mar '22

Greetings! I've been playing around with L4Re + L4Linux recently. I'm interested in getting the source code of L4Linux 5.13. However, it seems that the latest commit of the subversion repository (https://svn.l4re.org/repos/oc/l4linux/trunk) listed on the L4Linux website is in 2018. Since the group has just released L4Linux 5.15 recently, I'm just wondering what is the URL of the latest repository? Your help is much appreciated. Thanks, Haohui

2 1

Unable to boot hello example.
by Ashwin Krishnakumar 05 Feb '22

05 Feb '22

Hello all, I have created this issue in the manifest repo. Issue : https://github.com/kernkonzept/manifest/issues/12 I am writing it again. I am trying to boot an AMD64 and ARM64 machine using fiasco. The Fiasco and L4 build works fine. We are able to generate the final elf also successfully. However the QEMU is unable to boot the machine. IT just freezes at startup with the comment "ROM booting". 1. Fiasco building successfully [image: image.png] 1. L4 runtime built successfully [image: Screen Shot 2022-02-04 at 4 18 24 AM] <https://user-images.githubusercontent.com/16016925/152503555-8c02af0d-1177-…> 1. Able to give a boot command. However the system requires a video card. So I moved to my Linux laptop and observed that the system boots beyond this error, but is not printing hello world. [image: Screen Shot 2022-02-04 at 4 25 57 AM] <https://user-images.githubusercontent.com/16016925/152504574-72b7b2c8-58a1-…> In my local laptop it just says booting from ROM and freezes. Is there an alternate instruction for booting examples for ARM64 and AMD64 ? Regards, -- Ashwin Krishnakumar, +15714980269 ECE Graduate Student, Virginia Tech.

2 1

CfP: Microkernel and Component-based OS Devroom at FOSDEM 2022
by Martin Decky 06 Dec '21

06 Dec '21

Microkernel and Component-based OS Devroom at FOSDEM 2022 CALL FOR PARTICIPATION On-line version of this CfP: http://fosdem.microkernel.info/ The developers and users of several free and open source microkernel-based and component-based operating systems will meet on-line as part of FOSDEM 2022 [1] and will share a developer room. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based, unikernel-based, component-based operating systems and similar topics. The devroom has been preliminarily scheduled to Saturday February 5th 2022. The devroom will take place during European day hours. Possible topics of the devroom include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * languages, tools and toolchains used * enabling support for hardware (architectures, device drivers) and programming languages * development processes, debugging * maintenance, testing and release engineering * safety, security and robustness * trends and challenges * research and open questions * community and governance * use cases, experiences and status updates * best practices and lessons learned * demos This is a call for your participation. We kindly ask you to submit your proposals no later than on December 28th 2021. Please use the Pentabarf web site [2] to submit your proposals. If you already have a user account in Pentabarf, please do not create a new one. Addtionally, make sure to select the Microkernel and Component-based OS Devroom as the track when submitting your talk and include at least the following information in your proposal: * title of your talk * your full name * short abstract of your talk (one or two paragraphs) * duration of your talk (at least 20 minutes and no longer than 50 minutes) * your short bio * your photo The talks will be pre-recorded in advance in January and streamed automatically during the event. This means that you will need to complete and submit your talk recording by January 15th 2022. However, each speaker should be also present on-line just after the streaming of their talk for a live Q&A. You can specify your prefered time slot of your talk. The communication language of the devroom is English. The official devroom schedule (along with the accepted talks) will be announced on December 31st 2021 on the devroom's mailing list [3] and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM web site. For any comments, questions and suggestions (e.g. suggestions for a different type of event during the devroom), please do not hesitate to use the devroom's mailing list [3]. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012 [4], this devroom has been a part of each following FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. By now, it has become a somewhat institutionalized tradition for the open source operating systems community and it is one of the few places where microkernel enthusiasts and people with different views on how operating systems should work meet regularly. To this date, over a dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Extraordinary Circumstances in 2022 (Again) Due to the extraordinary mode of organization of FOSDEM 2022 (being an on-line event again), the devroom talks will be required to be pre-recorded in January and streamed during the event (with a live Q&A). The talk videos will be published under Creative Commons license by FOSDEM. By submitting a recorded talk, the speaker agrees to have it made available publicly indefinitively. For organizational purposes, we also need contact information of the speakers of accepted talks. Please check the official CfP page [5] of the devroom regularly. We will keep updating it as technical guidelines will be set by the FOSDEM organizers. Microkernel Dinner Sadly, it will not be possible to arrange our traditional microkernel dinner and other in-person social gatherings in Brussels this time again. However, we plan a closing event of the devroom as a loose approximation of the microkernel dinner. The details will be announced later. We encourage the on-line participats to bring their own food and beverages. About FOSDEM FOSDEM [6] is a two-day event organized by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognized as one of the best such conferences worldwide. FOSDEM covers a wide spectrum of free and open source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers annually at the ULB Solbosch campus. Due to the circumstances, FOSDEM 2022 will be organized as an on-line event. The participation in FOSDEM is totally free, although the organizers gratefully accept donations and sponsorship. No registration is necessary, but attendees are expected to follow the FOSDEM's code of conduct [7]. Important Dates Recap * 2021-12-28: Deadline for talk proposal submission * 2021-12-31: Schedule published and speakers notified of acceptance * 2022-01-15: Deadline for talk pre-recoding submission * 2022-02-05: Devroom taking place on-line Contact In case of any comments, questions and suggestions, please do not hesitate to contact the devroom organizers via the devroom's mailing list [3]. The primary organizers of the devroom in 2022 are: * Sebastian Sumpf * Martin Decky Links [1] https://fosdem.org/2022/ [2] https://penta.fosdem.org/submission/FOSDEM22/ [3] https://lists.fosdem.org/listinfo/microkernel-devroom [4] https://archive.fosdem.org/2012/schedule/track/microkernel_os_devroom.html [5] http://fosdem.microkernel.info/ [6] https://fosdem.org/ [7] https://fosdem.org/2022/practical/conduct/

1 0

Basic support for HiKey960 & SMP question
by Martin Decky 05 Oct '21

05 Oct '21

Dear L4 hackers, I have implemented a basic support for the HiKey960 board (based on the Kirin 960 SoC) [1] in Fiasco.OC and L4Re. If you are interested, please feel free to examine the code at GitHub [2]. I would be more than happy for a code review and suggestions towards potential upstream merging. The code is based on the latest L4Re base 21.07.0 snapshot. I have wanted to rebase the implementation on the latest revisions of the respective GitHub repositories, but unfortunately the current upstream Fiasco does not work for me properly even in QEMU. The implementation is very basic (fixed physical memory layout, UART support only, etc.), but seems to be working fine on the default examples. Unfortunately, I am struggling for some time with making the additional CPU cores work. I would greatly appreciate your assistance in this matter. In a nutshell, the additional 3 little cores (A53) are woken up correctly using the PSCI call (I am not tackling the 4 big A73 cores yet), but the Fiasco code livelocks in the loop around the STXR instruction in src/kern/arm/64/tramp-mp.S [3]. The STXR instruction always reports that the exclusive access to the _tramp_mp_spinlock failed despite no other accesses to the spinlock happened (confirmed using a JTAG debugger). I have checked all the usual culprits like proper virtual memory mapping attributes. I don't see any significant difference between the initialization code of Fiasco and the initialization code of other kernels that support HiKey960. I am also aware of the recent Adam's fix to the _tramp_mp_spinlock code [4], but not even that fixes the livelock issue on HiKey 960. Does anyone have any idea what might be root cause of the livelock here? Thanks in advance for any input. [1] https://www.96boards.org/product/hikey960/ [2] https://github.com/martin-decky/L4Re-HiKey960 [3] https://github.com/martin-decky/L4Re-HiKey960/blob/master/src/fiasco/src/ker n/arm/64/tramp-mp.S#L247 [4] https://github.com/kernkonzept/fiasco/commit/6bc2f7132982bc1e159abb716eb9026 71d381e9e Best regards Martin Decky

4 7

Jump to page:

2025

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