- l4-hackers - OS Site

Multiple targets in one package
by Baruch Burstein 03 Dec '25

03 Dec '25

Hi. I am trying to build multiple apps in one package. I tried the following but am getting linker errors (of all things!) ``` PKGDIR ?= ../.. L4DIR ?= $(PKGDIR)/../.. TARGET = app1 SRC_CC = app1.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk TARGET = app2 SRC_CC = app2.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk ``` What is the right way to do this?

2 1

[FOSDEM'26] Call for Participation: Microkernel and Component-Based OS Devroom
by Sebastian Sumpf 04 Nov '25

04 Nov '25

Hi there, here the CfP for FOSDEM'26: We are happy to announce the CfP for the "Microkernel and Component-Based OS" devroom at the upcoming FOSDEM 2026. Developers and users of various free and open-source microkernel-based and component-based operating systems will meet again at FOSDEM during the weekend of January 31st and February 1st 2026 and will share a developer room. The Microkernel and Component-Based OS devroom is currently looking for your participation in the form of proposals for talks, demos and other related activities. Possible topics for 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, devices 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 * Live demos Important Dates The deadline for submitting proposals is December 1, 2025 (23:55 CET). Please use the FOSDEM website at https://fosdem.org/submit, select the track "Microkernel and Component-Based OS" and include at least the following information: * Title of your proposal * Short abstract (one or two paragraphs) * Duration (20 - 30 minutes, including demos and Q&A) * Your full name * Your short bio The devroom schedule (with accepted talks) will be announced on the devroom website at https://fosdem.org/2026/schedule/track/microkernel by December 15, 2025. The schedule will also be posted to the devroom mailing list and the speakers will be notified via email. Like previous years, the devroom will take place as an in-person event at the ULB Campus Solbosch in Brussels, Belgium during the second half of February 1, 2026 (Sunday). Due to the high number of submissions that FOSDEM received again this year, our devroom has only been allocated half a day. Therefore, the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. Given these restrictions, eight to nine half hour slots with a speaking time of 20 to 25 minutes and 5 to 10 minutes of Q&A form the upper limit. Requirements The communication language of the devroom is English. All content must relate to free and open-source software. By participating in the event, you agree to the publication of your talk recordings, slides and other content provided under the same CC-BY license as all other FOSDEM content. All participants are expected to adhere to the Code of Conduct: https://fosdem.org/2026/practical/conduct/ Contact For the 2026 edition, the organizers of the devroom are * Sebastian Sumpf (sebastian.sumpf [at] genode-labs.com) * Josef Söntgen (josef.soentgen [at] genode-labs.com) For any comments, questions and suggestions, please do not hesitate to contact us directly or via microkernel-devroom-manager at fosdem.org. Announcements and inquiries are additionally available through the devroom mailing list https://lists.fosdem.org/listinfo/microkernel-devroom About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012, this devroom has been a part of each subsequent FOSDEM (with slight variations of the name). The focus gradually widened to include component-based and other operating systems. It has now become somewhat of a tradition for the open-source operating systems community, a kind of "extended family meeting" and it is one of the very few places where microkernel and operating-system enthusiasts meet regularly. To 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 in the past, the devroom will offer the stage both to established community members and to newcomers. Our goal is to select talks in an inclusive manner and to create a balanced and unbiased schedule, while keeping the quality of the devroom as high as in previous years. About FOSDEM FOSDEM 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 new ideas, latest results, 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 in Brussels, Belgium. The participation in FOSDEM is totally free and requires no registration, although the organizers gratefully accept donations and sponsorship. Devroom Dinner Over the years, it has become a tradition that devroom speakers and enthusiasts meet for dinner somewhere in Brussels after the event to continue discussions, socialize and meet old and new friends. We plan to follow that tradition in some form as well in 2026 and will inform you about the exact arrangements later. Hope to see all of you in Brussels! Regards, Sebastian -- Sebastian Sumpf 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

Sculpt 25.10 with Fiasco.OC kernel
by Alexander Boettcher 03 Nov '25

03 Nov '25

Hello, last week Genode released a new version of its open source OS - Sculpt OS 25.10 [0]. I took the opportunity to craft a PC image that also contains an (unofficial and experimental) Sculpt variant based upon a Fiasco.OC kernel [1] version. The variant reflects to large degree the state I presented live during the Systems Meetup [2] gathering at the TU Dresden in January 2025. In case you are interested, feel free to check out [1]. Cheers, Alex. [0] https://genode.org/download/sculpt [1] https://genodians.org/alex-ab/2025-11-02-sculpt-multi-kernel [2] https://ukvly.org -- Alexander Boettcher Genode Labs https://www.genodians.org - https://www.genode.org

1 0

Assertion ‘state() & Thread_vcpu_user' in kernel vgic interrupt processing
by yy18513676366 14 Oct '25

14 Oct '25

Hi l4-hackers, When running a virtual machine, I encounter an assertion failure after the VM has been up for some time. The kernel crashes in src/kern/arm/thread-arm-hyp.cpp, specifically in the function vcpu_vgic_upcall(unsigned virq): vcpu_vgic_upcall(unsigned virq) { ...... assert(state() & Thread_vcpu_user); ...... } Based on source code inspection and preliminary debugging, the problem seems to be related to the management of the Thread_vcpu_user state. （1）Under normal circumstances, the vcpu_resume path (transitioning from the kernel back to the guest OS) updates the vCPU state to include Thread_vcpu_user. However, if an interrupt is delivered during this transition while the receiving side is not yet ready, the vCPU frequently return to the kernel (via vcpu_return_to_kernel) and subsequently process the interrupt through guest_irq in vcpu_entries. In this situation, the expected update of Thread_vcpu_user may not yet have taken place, which seems result in the assert being triggered when a VGIC interrupt is involved. （2）A similar condition seems to occur in the vcpu_async_ipc path. At the end of IPC handling, this function explicitly clears the Thread_vcpu_user flag. If a VGIC interrupt is delivered during this phase, the absence of the expected Thread_vcpu_user state seems to lead to the same assertion failure. I would like to confirm if the two points above are correct, and what steps I should take next to further debug this issue. In addition, I have some assumptions I would like to confirm: First, for IPC between non-vcpu threads, the L4 microkernel handles message delivery and scheduling (wake/schedule) directly, without requiring any forwarding through uvmm. Similarly, interrupts bound via the interrupt controller (ICU) to a non-vcpu thread or handler are also managed by the kernel and scheduler, and therefore do not necessarily involve uvmm. Second, passthrough interrupts, when not delivered in direct-injection mode, are routed to uvmm for handling if they are bound to a vCPU. Likewise, services provided by uvmm (such as virq) are also bound to a vCPU and therefore require forwarding through uvmm. There seems to have been a similar question in the past, but it does not seem to have been resolved. Re: Assertion failure error in kernel vgic interrupt processing - l4-hackers - OS Site I wonder if my questions are related to that post, and if any solutions exist. Thanks!

2 7

Questions regarding L4::Platform_Control
by David Q 13 Oct '25

13 Oct '25

Hello L4 hackers, I would like to thank the community for helping me learn; I am back with more questions. This time it is about L4::Platform_Control 1. It seems IO and UVMM both have this L4::Platform_Control capability, is it correct? 2. I can't seem to create a usable L4::Platform_Control capability in a userland application using the factory from env. Does this mean there is one such platform control capability only? 3. It seems there is a system_suspend() function, and X86 is particularly supported. Does it work right now for ARM? 4. Once system_suspend() is called in an ARM environment, does the kernel communicate with PSCI, which then gets intercepted by Arm trusted firmware? 5. Also, before suspending the entire system, it would seem a good idea to quiesce all threads (except the kernel I assume) and save the CPU/Thread states/contexts. Is there an API that could help with quiescing threads and saving relevant states? I only see the debugger being able to quiesce all threads, but I can't seem to find an API that can save and reload the saved states once we want to exit suspend. These are a lot of question, and I thank anyone who reads them.

1 0

L4 Thread, pthread, comprehension question
by xudino＠gmail.com 23 Sep '25

23 Sep '25

Hello L4 hackers, I hope you are all doing well today. I am hoping to discuss the topic of threads to better my understanding of it, as it seems to be a major building block in L4Re. I have the following questions (using the c++ based libraries.): 1. Is Pthread the official way to create threads in an L4Re application? 2. I have made a L4 thread (to understand how threads work in L4) without the help of pthreads by setting up the Attr, which involved in setting the exception handlers(using rm()), pager (using rm()), instruction pointers, stack pointers, binding, ex_reg() and finally running. All seems well until I try printing a message. It seems seems I am unable to use the printf() function in the instruction pointer function of said thread. The error I get is : ttest | l4re_itas[rm]: unhandled read page fault at 0x141 pc=0x100f8a0 ttest | l4re_itas: rom/thread_test: Unhandled exception: PC=0x100f8a0 PFA=0x140 LdrFlgs=0x0 However, if I use printf in a pthread, none of these errors pop up. 2a. Am I using the wrong exception handler and pager (I got both from rm)? 2b. Also, the "l4_vcon_send(L4_BASE_LOG_CAP,..,...) function seems to work fine in either case, shouldn't printf() eventually call this function as after a series of indirections? 2c. What exc_handler and pager do pthreads use? Why are they able to handle the pager faults and exceptions from printf? Can I appropriate them for the L4 threads I started? 3. It seems the Virtual Machines (VMs) that are on the hypervisor are also closely related with threads. I assume these are Vcpu threads and not pthreads. 3a. Am I correct in this assumption? 3b. How are the exception handlers and pagers set up for these Vcpus? Thank you so much for your time, David

3 3

Re: L4 Thread, pthread, comprehension question
by Marcus Haehnel 23 Sep '25

23 Sep '25

Hi David, On 2025-09-22 05:37, xudino(a)gmail.com wrote: > Hello L4 hackers, I hope you are all doing well today. > > I am hoping to discuss the topic of threads to better my understanding > of it, as it seems to be a major building block in L4Re. I have the > following questions (using the c++ based libraries.): > > 1. Is Pthread the official way to create threads in an L4Re > application? That is at least the high level primitive that you should use if you have no good reason to use the low level L4 primitives and want to use any of the POSIX / libc functionality inside your thread. > > 2. I have made a L4 thread (to understand how threads work in L4) > without the help of pthreads by setting up the Attr, which involved in > setting the exception handlers(using rm()), pager (using rm()), > instruction pointers, stack pointers, binding, ex_reg() and finally > running. All seems well until I try printing a message. > It seems seems I am unable to use the printf() function in the > instruction pointer function of said thread. The error I get is : > ttest | l4re_itas[rm]: unhandled read page fault at 0x141 > pc=0x100f8a0 > ttest | l4re_itas: rom/thread_test: Unhandled exception: > PC=0x100f8a0 PFA=0x140 LdrFlgs=0x0 > However, if I use printf in a pthread, none of these errors pop up. > 2a. Am I using the wrong exception handler and pager (I got both > from rm)? > 2b. Also, the "l4_vcon_send(L4_BASE_LOG_CAP,..,...) function seems > to work fine in either case, shouldn't printf() eventually call this > function as > after a series of indirections? > 2c. What exc_handler and pager do pthreads use? Why are they able > to handle the pager faults and exceptions from printf? Can I > appropriate > them for the L4 threads I started? What you are seeing is a side-effect of libpthread being quite tightly integrated with the libc. While it is true that printf will call l4_vcon_send somewhen down the line it will use some (potentially thread-local) internal buffers to print its output. While you can mix libpthread threads with native L4 threads you must take care to call no function from the libc that would make any use of TLS storage, unless you set this up yourself. If you want to write normal applications std::thread and pthread threads are the way to go. > > 3. It seems the Virtual Machines (VMs) that are on the hypervisor are > also closely related with threads. I assume these are Vcpu threads and > not pthreads. > 3a. Am I correct in this assumption? > 3b. How are the exception handlers and pagers set up for these > Vcpus? Yes, a vCPU is in the end only a thread with some extended state. A thread in vcpu mode provides an additional exception execution context. When a trap from avcpu occurs the kernel will switch the vCPU to the exception entry point. See entry_ip and entry_sp here https://l4re.org/doc/structl4__vcpu__state__t.html#a1f45174954aa47bb2f21b7b… These must be set as part of the vcpu state before starting the vcpu. The exception handler must take care of handling page-faults generated by threads user code. I hope this helps :) Best regards, - Marcus > > Thank you so much for your time, > David > _______________________________________________ > 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 1

Help: interactive REPL I/O for user program on L4Re/Fiasco.OC (amd64-plain) — Vcon/cons nearly working; canonical approach?
by Robert A. James 07 Sep '25

07 Sep '25

Hello l4-hackers, My name is Robert (Bob) A. James I'm VERY new to the L4Re world. This is also my first foray into systems programming having come from the Medical Device and Enterprise areas during my career. I am now retired and developing a full Operating System based on L4Re/Fiasco.OC. I’m looking for guidance on the /canonical/ way to wire an interactive text console (stdin/stdout) for a user program under L4Re/Fiasco.OC on amd64-plain. Context * I have a small, headless FORTH VM (“StarForth”) running under L4Re/Fiasco.OC; its self-tests pass. What’s missing is an *interactive REPL*. * Target outcomes: a) Run via |make qemu E=starforth O=build-x86_64| b) Build GRUB2 ISO via |make grub2iso E=starforth O=build-x86_64| c) ISO runs in QEMU and VirtualBox d) Same ISO boots on commodity x86_64 hardware What I’ve tried (and where I’m stuck) 1. *Vcon + cons* (almost there) * My mental model: Vcon as a frontend; |cons| providing the console service; StarForth as the “backend” client/subscriber. * Behavior I see: • The “terminal” prints what the *logger* prints rather than the process’s normal *stdout*. • Output sometimes *flushes only on newline*; interactive prompts without |\n| don’t appear reliably. * Aside from those two issues, this was close to a working REPL. * *Questions:* Is |cons| effectively write-only (log)? If so, what’s the supported input-capable console frontend to bind both stdin and stdout for a user process? Is there a minimal example showing correct capability wiring so user stdout/stderr don’t get mixed with the system log? 2. *GOOS/Framebuffer route* * I attempted a tiny terminal server that maps the GOOS framebuffer and renders an 8×16 CP437 font. I did not get this path working end-to-end, so I’m fine dropping it if there’s a simpler, recommended console approach. What would help * The *recommended minimal pattern* (modules/services + boot script) to give a user task a real interactive stdin/stdout: o works with |make qemu …| and |make grub2iso …| o also works on typical PCs without a full graphics stack. * A *small reference* that: (1) prints text, and (2) reads keystrokes from the user, with a snippet of |modules.list| and the Lua loader snippet. Environment / details * L4Re/Fiasco.OC on amd64-plain, built with the L4Re toolchain. * Intended entry points: |make qemu E=starforth O=build-x86_64|, |make grub2iso E=starforth O=build-x86_64|. One of my simple boot variants (for reference): |modules.list| (simplified) entry starforth kernel fiasco -serial_esc roottask moe rom/quark.cfg module l4re module ned module cons module quark.cfg module starforth |quark.cfg| --> I think this is about what I had. -- rom/quark.cfg local L4 =require("L4") local ld =L4.default_loader -- Start cons; feed it to the real serial logger (fe =L4.Env.log) local cons_ctl =ld:new_channel() ld:start({ caps = { cons = cons_ctl:svr(), -- server gate for cons' factory fe = L4.Env.log, -- cons frontend goes to serial/log }, }, "rom/cons -m l4re -f fe -a -t -c StarForth") -- ← added -c StarForth -- Ask cons to create a Vcon client for StarForth and pass it in as 'tty' -- (Capabilities are first-class in Ned; calling 'create' on caps is supported.) local tty =cons_ctl:create(L4.Proto.Log, "StarForth", "show", "key=1", "bufsz=65536") -- Start StarForth with that Vcon as its TTY ld:start({ caps = { tty = tty, -- the Vcon client for StarForth }, }, "rom/starforth") I can share a minimal reproducible case (sources, build logs, QEMU output) off-list if that helps. Thanks in advance for any pointers to the “right way,” or to a maintained example I can follow. Best regards, R. A. “Bob” James (rajames440(a)gmail.com) Kubuntu 25.04 • amd64-plain • QEMU/VirtualBox • GRUB2 boot targets

2 1

Question about SMC filtering in smc_user.cpp on ARM64
by Gravel Yuan 25 Jul '25

25 Jul '25

Hello all, I'm currently working on integrating OP-TEE support on the ARM64 architecture within the L4Re framework, specifically focusing on cryptographic operations such as encryption and decryption. While reviewing the implementation, I noticed that in fiasco/src/kern/arm/smc_user.cpp, non-fast SMC calls are explicitly filtered out with the following check: // only allow fast callsif (!(r0 & 0x80000000)) return commit_result(-L4_err::ENosys); I'm trying to understand the rationale behind this design decision. Was it primarily driven by real-time performance requirements, or are there other considerations？ Additionally, as OP-TEE often uses *yielding calls* for certain operations, do you think it would be appropriate for us to consider extending the kernel to support such calls? We would appreciate any insights or recommendations you can provide. Best regards,

2 1

L4Re: MIPS SMP cache initialisation may be broken for some CPUs
by Paul Boddie 20 Jul '25

20 Jul '25

Hello, Pushing on with my efforts to port L4Re to another MIPS-based SoC, I have been attempting to activate more than one CPU core. Although there is some support in Fiasco for the MIPS Coherence Manager (CM) and Cluster Power Controller (CPC), these technologies are not supported in this particular SoC, which is related to the JZ4780 used in the MIPS Creator CI20. However, the Platform_control abstraction (in src/kern/mips/platform_control- mips.cpp) does seem to provide some flexibility in the way secondary CPUs or cores may be started. It seems that even in situations where the CM is not available, the alloc_secondary_boot_code method will assemble a bootstrap routine from snippets including one, _tramp_mp_cache, that initialises the caches. Unfortunately, it appears that this cache initialisation code does not work on this particular SoC. The method used by_tramp_mp_cache is the familiar one where the cache tags are invalidated for all cache index entries using the Index_Store_Tag operation for each cache type. This is supposed to work on any MIPS CPU, but through some tedious troubleshooting, I discovered that it does not work for the data cache. If the data cache variant of the Index_Store_Tag operation is performed for a range of addresses starting from the base of KSEG0, I found that some kind of side-effect would occur, possibly affecting the rather critical addresses in that range. This would prevent Fiasco from continuing to start up, and things like timers and the UART would not function, although the processor was not halted and would still run code, illuminating LEDs as a last-resort debugging tool. There is some preliminary support for this SoC, as well as the JZ4780, in Linux and it seems that instead of using Index_Store_Tag, the tag records are explicitly invalidated and updated. However, it also seems to be the case that caches can be invalidated using Hit_Invalidate. Changing the cache operations in _tramp_mp_cache to use this invalidation operation in its two variants appears to work, avoiding the problems described above. Does anyone have any thoughts or recollections about this cache initialisation routine? On the topic of actually starting secondary cores, this SoC has its own set of registers for resetting cores, interrupt control, mailboxes, and so on. I have developed a fairly simple abstraction that performs similar core bootstrapping work to that of the Cm abstraction (in src/kern/mips/cm.cpp). I then extend the Platform_control abstraction so that it will call the alloc_secondary_boot_code method, followed by the appropriate method to start the secondary cores. Is there any documentation for the SMP architecture in Fiasco and L4Re? I note that interprocessor interrupts (IPI) are one element that I might need to support, probably using the mailboxes. Thanks in advance for any advice or feedback that may be given! Paul

2 2

Subject: Introduction – StarshipOS: A gForth/JVM Hybrid on L4Re
by Robert James 13 Jul '25

13 Jul '25

Hello everyone, My name is Rob James, and I wanted to introduce myself and an OS I’ve been developing called **StarshipOS**. StarshipOS is a unique hybrid operating system built on top of the L4Re microkernel framework. It combines: - A Forth-based core powered by **gForth** - A lightweight persistent **object memory model** that completely replaces the traditional filesystem - Embedded **OpenJDK 21** services for high-level logic and tooling The system is non-POSIX by design. Instead of files, everything lives in a dynamic memory graph of interactive objects. You interact with your system through a Forth-based REPL that evolves and mutates this object universe in real time. No shell scripts, no /etc, no /usr — just memory objects and messaging. The ultimate goal is to make the **REPL the new shell**, and the **memory graph the new filesystem**. Here’s what’s already in place: - A full Maven-driven build system that compiles Fiasco.OC, L4Re, OpenJDK, and gForth from source - A `starship-maven-plugin` that automates ROMFS image generation and ISO boot layout coming soon: - A sandboxed REPL environment that boots directly into gForth and supports mounting JVM modules as interactive bundles - Early support for memory graph ACLs, entropy-based object lifespan, and “bubbles” — user-defined isolated memory regions Right now, I’m focused on integration, getting the system to boot into the gForth REPL with full JVM runtime support, and beginning to layer in userland services via custom dictionary words. Source is available (in-progress) here: 👉 **https://github.com/rajames440/StarshipOS** I’ve been programming since the 1970s, mostly in userland, and I’m diving deep into kernel space and L4 internals for the first time. I’d love to hear from others doing low-level work on L4Re, especially anyone who's extended the build system or tackled non-POSIX boot flows. Thanks again to everyone who’s contributed to L4Re and Fiasco.OC — it’s a hell of a foundation to build a new kind of OS on. All the best, Rob James

2 1

L4Re: Why was EXTERN_C_BEGIN/END replaced?
by Paul Boddie 23 Jun '25

23 Jun '25

Hello, Taking the opportunity to use a newer snapshot of L4Re, I notice that EXTERN_C_BEGIN and EXTERN_C_END now cause errors like this: error: unknown type name ‘DO_NOT_USE_EXTERN_C_END_ANY_MORE__USE__END_DECLS’ The commit introducing this behaviour seems to be this one: https://github.com/kernkonzept/l4re-core/commit/ e04b50e0e4f7c7a3316a2d8b658db6d81bd3e88d It would appear that throughout L4Re, a mass renaming has occurred from these symbols to __BEGIN_DECLS and __END_DECLS. Was there a particular reason for what might seem like an arbitrary change? Paul

3 2

Upgrade issues. VM won't start.
by Richard Clark 23 Jun '25

23 Jun '25

Adam, So I have been using version 23.10.1, built as per the download page, and have gotten a couple VMs to ping eachother and give me a login prompt. I finally realized I was missing the virtio_switch package and grabbed it from github and put it where it is supposed to go. Of course, being a version mismatch now, it did not compile. I decide to bite the bullet and do an upgrade (always a mistake) and use the new build process given with the new website. That went smoothly! I install ham, run it, etc, everything builds, I update my local scripts and links to use the new environment variables instead of being hardcoded, and it all builds and looks good. Except that it doesn't run. The VMs get a memory exception and kick into jdb. I have not changed any of my .cfg or .list files. The VMs and ramdisks are untouched. My local (L4 native) processes start and appear to run. But the VMs crash for some reason. Even the device tree is unchanged. I also tried a newly built linux (as opposed to a prebuilt) and that failed as well. Is there some reason for this new crash between version 23.10.1 and the latest version from github? I've attached the VM startup output from both the old and new runs so you can take a look. I'm so close... I see the IP configuration parameter and how to set up lwip and virtio_switch.... Then my natives should be able to talk directly to my linuxes. Your help is greatly appreciated! Richard

6 17

Linux fails on startup looking for SMC
by Moshe Kravchik 22 Jun '25

22 Jun '25

Hi, I'm trying to set up a Linux running on uvmm with a HW passthrough. I added `zynqmp_firmware` to my DTS (it was required for the device I'm trying to pass). However, Linux fails to add the device and I see: vm-1 | [ 1.772078] ledtrig-cpu: registered to indicate activity on CPUs vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c200003f a1=3f ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c2000001 a1=0 ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | [ 1.805957] zynqmp_firmware firmware:zynqmp-firmware: probe with driver zynqmp_firmware failed with error -22 >From the traces I added, the failure is in `zynqmp_pm_get_api_version`. How do I add SMC handling? Best regards, Moshe _______________________________________________ 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 14

Re: Issue Rebooting Guest OS in UVMM: Invalid Capability Invoke
by Philipp Eppelt 12 Jun '25

12 Jun '25

Hi Stephen, I'm happy to hear that. In the future, please take care to reply to the list too, such that others can learn as well. :-) Cheers, Philipp Am 12.06.25 um 8:34 AM schrieb yy18513676366: > Hi Philipp, > > Thank you for your reply — it was truly helpful to me. > > > I believe I have identified the root cause of the issue. I had assigned full > permissions to all capabilities using :svr(), which included the L4_CAP_FPAGE_D > right. This permission caused kernel objects to be forcibly deleted. After I > adjusted the capability permissions to m("rwncs"), the problem was resolved. > > > I do not yet have a deep enough understanding of capabilities, their permission > flags, and the mapping process via l4_task_map. > > Regarding the restart procedure — it is actually quite straightforward. > According to the documentation, the L4Re::Parent::signal interface can be used > to terminate a running program. So I terminate uvmm first, and then restart it > using the ned script, just like at the beginning. In this way, the guest OS is > relaunched. > > > Through this process, I’ve come to appreciate the stability of L4Re. It is > reassuring to see that the crash of a single application does not affect other > programs. > > > Once again, thank you for your support and assistance. > > Best regards, > > Stephen.yang > > > > > > > At 2025-06-11 17:21:32, "Philipp Eppelt" <philipp.eppelt(a)kernkonzept.com> wrote: >>Hi Stephen, >> >>I don't quite follow your description, can you please show your ned script to >>help my understanding? >> >> >>Wrt 1.: To actively delete a kernel object, you need a capability possessing >>delete rights and call `l4_task_unmap()` featuring the delete flag or >>`l4_task_delete_obj()`. >>Otherwise, the kernel object gets deleted, when the reference count drops to >>zero, meaning there are no more capabilities holding a reference to this kernel >>object. >>An application can release its reference, but still possess the capability. Or a >>capability can be mapped to another application without increasing the reference >>count. >> >> >>To answer 2 and 3 I first need to understand your reboot workflow. >> >>Cheers, >>Philipp >> >> >>Am 10.06.25 um 10:27 AM schrieb yy18513676366: >>> Hello, >>> >>> I am currently conducting research using the L4Re system, and I am working on >>> implementing a mechanism to reboot a Guest OS managed by UVMM. >>> >>> In my setup, I run two Linux instances under UVMM. My goal is to reboot one of >>> them without affecting the other. >>> >>> To achieve this, I terminate the target instance by sending a signal using | >>> L4Re::Parent::signal|, and then I restart it using a Ned script to launch a new >>> instance of the same program. >>> When restarting, I reuse the capability that was created during the first launch >>> of the UVMM instance. >>> >>> However, during execution, the restarted program encounters an *"invalid >>> capability invoke"* error. >>> >>> >>> Upon investigation, I suspect this happens because |l4_task_unmap| was called >>> during the restart process, which likely removed kernel objects associated with >>> the original capability. As a result, the reused |cap_index| no longer refers to >>> a valid object. >>> >>> Based on this, I would appreciate your insights on the following questions: >>> >>> 1. >>> >>> Under what conditions are kernel objects deleted in L4Re? >>> >>> 2. >>> >>> In this rebooting workflow, how can we ensure that capabilities remain valid >>> or that their associated kernel objects are not prematurely unmapped or deleted? >>> >>> 3. >>> >>> If UVMM crashes during operation, how can we design a mechanism to ensure >>> system-wide stability and security? >>> >>> Thank you in advance for your valuable feedback! >>> >>> Best regards, >>> stephen.yang >>> >>> _______________________________________________ >>> 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 >> >>-- >>philipp.eppelt(a)kernkonzept.com - Tel. 0351-41 883 221 >>http://www.kernkonzept.com >> >>Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. >>Geschäftsführer: Dr.-Ing. Michael Hohmuth >> -- philipp.eppelt(a)kernkonzept.com - Tel. 0351-41 883 221 http://www.kernkonzept.com Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

1 0

Issue Rebooting Guest OS in UVMM: Invalid Capability Invoke
by yy18513676366 11 Jun '25

11 Jun '25

Hello, I am currently conducting research using the L4Re system, and I am working on implementing a mechanism to reboot a Guest OS managed by UVMM. In my setup, I run two Linux instances under UVMM. My goal is to reboot one of them without affecting the other. To achieve this, I terminate the target instance by sending a signal using L4Re::Parent::signal, and then I restart it using a Ned script to launch a new instance of the same program. When restarting, I reuse the capability that was created during the first launch of the UVMM instance. However, during execution, the restarted program encounters an "invalid capability invoke" error. Upon investigation, I suspect this happens because l4_task_unmap was called during the restart process, which likely removed kernel objects associated with the original capability. As a result, the reused cap_index no longer refers to a valid object. Based on this, I would appreciate your insights on the following questions: Under what conditions are kernel objects deleted in L4Re? In this rebooting workflow, how can we ensure that capabilities remain valid or that their associated kernel objects are not prematurely unmapped or deleted? If UVMM crashes during operation, how can we design a mechanism to ensure system-wide stability and security? Thank you in advance for your valuable feedback! Best regards, stephen.yang

2 1

L4Re: MIPS syncICache seems to be broken
by Paul Boddie 09 Jun '25

09 Jun '25

Hello, I have been trying to get L4Re working on another MIPS-based SoC and found myself struggling to get the kernel to boot. Initially, I wondered about various exotic concurrency issues, particularly since the SoC has two cores (each with two threads, apparently), but I started to suspect that our old nemesis, cache management, was to blame. Anyway, to save you the long story, I had a closer look at the syncICache routine that resides in the bootstrap package/module: pkg/bootstrap/server/src/ARCH-mips/crt0.S It turns out that syncICache is ineffective due to an erroneous loop continuation test. Here's the offending code: 10: synci 0($a0) addu $a0, $a0, $v0 sltu $v1, $a0, $a1 bne $v1, $0, 10b nop Here, $a0 is the region start and $a1 is the region size, with $v0 being the cache line size. The above code is equivalent to the following: address = start; do { synci 0(address) address += linesize; } while (address < size); The address should, of course, be compared to start + size. So, cache entries may not be flushed, particularly later in regions and at higher addresses, omitting coverage even of the early kernel regions, making kernel execution very unpredictable and unreliable. Perhaps the larger caches make this fault more obvious on this particular SoC. In the startup routine in the bootstrap package/module... pkg/bootstrap/server/src/startup.cc ...there is a declaration for syncICache, along with code to flush the caches, introduced purely for MIPS. To test my suspicions, I wrote a C++ version of the routine with inline assembly language for the machine instructions, fixing the loop continuation test. This seemed to allow the kernel to boot and the system to start up as I originally expected. Would you like me to contribute this fix? I think that unless inline assembly is problematic for some toolchain choices, it might be clearer to maintain this code in C++ rather than entirely in assembly language, thus avoiding such faults in the first place. This problem may have been around since the introduction of MIPS support into L4Re, appearing first in r70 of the public Subversion repository from back in May 2016. Paul

2 2

Can't tcp into VM?
by Richard Clark 05 Jun '25

05 Jun '25

Hey Adam! I’ve gotten the lwip stack working, and two vms running, and the ramdisks expanded a little, and some test processes statically built so I can run them… and the results suggest a firewall in the way, but I don’t see a way to enable the port I want… So lwip stack native to l4re, ipaddr 192.168.1.100, Vm1 at 192.168.1.2 Vm2 at 192.168.1.3 The vms can ping eachother. The vms can ping the lwip stack. Vm1 can establish a tcp connection TO the lwip stack. (and send packets!) Lwip cannot establish a tcp connection TO vm1. I would have tweaked the firewall, but I don’t see one, or any firewall utilities, in your default ramdisks. Suggestions? How would I enable port 5000 from 192.168.1.100 (lwip) to be allowed into vm1? Worst case, I guess I could just start all the connections from the vm, but still, it would be nice to know why it isn’t being allowed. I think this is the last little piece I am missing, and then I can run demos for our customer! 😊 Thanks! Richard

2 2

Real time application
by agaku03＠gmail.com 28 May '25

28 May '25

Hello I am trying to load real time applications on the L4re hypervisor. I would like to make sure that each application has a set ram space and a specific core. I have followed some examples that are proposed but I cannot segregate the various applications correctly. Is it possible to have an example of how I have to configure or what I have to do to achieve this?

2 8

fail to build package with l4re snapshot
by Tianhao Wang 22 May '25

22 May '25

hi, I'm trying to build a new package following the instructions from the snapshot page [1]. However it fails (error message below). steps: 1. download / extract the l4re-snapshot-25.03.0 snapshot 2. make setup (for the ia32 target) && make the hello world qemu example works correctly 3. add a new package, following instructions from "Adding your own code" [1] (of course the path placeholders are modified) /tmp/myfirstpkg/Makefile ``` PKGDIR ?= . L4DIR ?= PATH/TO/SNAPSHOT/src/l4 TARGET = myfirstprogram SRC_C = main.c include $(L4DIR)/mk/prog.mk ``` /tmp/myfirstpkg/main.c ``` #include <stdio.h> int main(void) { printf("Hello!\n"); return 0; } ``` 4. and try to build it $ cd myfirstpkg $ make O=/PATH/TO/SNAPSHOT/obj/l4/x86 error output: [myfirstpkg] ... Building Dependencies path/to/src/l4/mk/binary.inc:396: *** /tmp/myfirstpkg/Makefile: 'stdlibs compiler-rt' in REQUIRES_LIBS in Makefile but not in Control file requires. Stop. make: *** [path/to/src/l4/mk/binary.inc:195: path/to/obj/l4/x86/ext-pkg/tmp/myfirstpkg/OBJ-x86_gen-std-l4f] Error 2 I attempted to add file `Control` to the package root conataining the following but it doesn't work. requires: stdlibs compiler-rt Am I doing anything wrong in adding a new package? Sorry for the newbie question, I'm learning L4RE :) cheers, wth [1] https://os.inf.tu-dresden.de/download/snapshots/ -- wth 220F 6A50 7BEF 8C33 3B4A 4404 99DE B3B4 1583 4AEF

3 8

lwip/virtio-net examples?
by Richard Clark 20 May '25

20 May '25

Hi there! I've gotten two linux vms to come up and automatically set their IPv4 address and login for me. (l4vio_net_p2p) They can ping each other just fine. Now I would like to get them to talk to my l4Re-native server. I see an lwip library, and I see that it has a virtio backend that appears to connect lwip to the virtual network. What I can't seem to find is an example that uses it? I have one vm at 192.168.1.2, and the one at 192.168.1.3. I would like to assign my lwip virtio-net interface to 192.168.1.100, and of course have them all talk TCP and UDP to each other. I can handle lwip and sockets, I just have no clue how to get it configured and initialized under l4re. Any examples and/or helpful hints? .cfg files? modules.list? Code? Github link? Thank you for your time! Richard _______________________________________________ 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

Re: l4-hackers Digest, Vol 246, Issue 9
by Torsten Wierschin 19 May '25

19 May '25

Hi there! In my opinion, the problem discussed here can be solved quite well using yocto or buildroot or something else. If I ever find the time, I'd be happy to publish my yocto build environment for l4re. But maybe someone else will be faster? I'd like to thank you for the many very valuable tips posted here. Torsten Am Do., 15. Mai 2025 um 00:34 Uhr schrieb <l4-hackers-request(a)os.inf.tu-dresden.de>: > > Send l4-hackers mailing list submissions to > l4-hackers(a)os.inf.tu-dresden.de > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > l4-hackers-request(a)os.inf.tu-dresden.de > > You can reach the person managing the list at > l4-hackers-owner(a)os.inf.tu-dresden.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > Today's Topics: > > 1. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Marcus Hähnel) > 2. Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Paul Boddie) > 3. RE: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > (Richard Clark) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 May 2025 16:52:48 +0200 > From: Marcus Hähnel <support(a)kernkonzept.com> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Paul Boddie <paul(a)boddie.org.uk>, l4-hackers(a)os.inf.tu-dresden.de > Message-ID: > <c648158693b4e8f556b4d371f74e7751dce80e40.camel(a)kernkonzept.com> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, running > > > compile checks for all our supported architectures as well as an extensive > > > test suite on different platforms and configurations. So from that point of > > > view I would say you can consider all code pushed to Github as > > > “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people wanting to > > provide solutions for paying customers, but I have personally wondered how I > > might successfully and conveniently reproduce repository configurations when > > creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might want to > > replicate the L4Re configuration I have been using for another board. Starting > > from scratch, it was possible to use the ham tool, but despite it apparently > > maintaining version details for the different repositories, it wasn't > > particularly clear how one might preserve or export that metadata for further > > use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone serious-enough > > about using L4Re would get in touch with Kernkonzept and start talking > > business, but such a lack of clarity tends to suggest that either there aren't > > particularly adequate solutions for such fundamental needs or that any > > adequate solutions that may exist aren't for people merely investigating or > > evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved that > > everybody feels comfortable with, and if there's a steady stream of interested > > customers that seems to justify such a decision, but I could easily see > > potential users going elsewhere if the answer to simple questions is "talk to > > us". Even in reasonably large organisations, hitting an approval barrier that > > "talk to us" or "register your interest" represents can be a strong > > disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own activities are > > confined to my own interests and driven by a general belief that L4Re > > represents a reasonable foundation for certain kinds of systems. That there > > isn't exactly much of a public community around L4Re could also be regarded as > > a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, > helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it > as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response > focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, > which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more > fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of > use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — > so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of > L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against > our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a > workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of > reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham > checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a > complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your > current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually > reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an > issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re > together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 14 May 2025 22:01:08 +0200 > From: Paul Boddie <paul(a)boddie.org.uk> > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: l4-hackers(a)os.inf.tu-dresden.de, Marcus Hähnel > <support(a)kernkonzept.com> > Message-ID: <2728648.BddDVKsqQX@jason> > Content-Type: text/plain; charset="UTF-8" > > On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > > > thank you very much for your thoughtful message — it's really appreciated. > > Thank you for taking the time to respond! I didn't really expect such a > comprehensive reply, so it is much appreciated. > > > First of all: your opinion absolutely matters. The input from users like > > you, who engage deeply and share candid feedback, helps us make L4Re > > better. While we are aware that L4Re is still quite niche and the community > > small, we want to support it as best we can and would love to see it grow. > > It is reassuring to hear that you take feedback into consideration, even from > those of us who are not directly contributing to your work or, indeed, your > business. > > > I think you're raising a different, but equally important, point compared to > > what Richard was asking. My original response focused on the idea of > > providing a fully tested release for a specific combination of software > > configuration and hardware, which is understandably difficult for us to > > maintain as part of the open-source offering given our limited resources. > > I completely agree that if someone is in need of something that requires an > investment of time and resources, then they should either invest their own > time and resources, which is effectively what I have done over the last few > years, or they should be prepared to compensate others for that work. Nobody > should be required to do something for someone else for nothing - there is > already too much of that happening in the open source world - not that any > such request was made, I should add. > > Productive access to specific hardware configurations has always been a > challenge for software environment developers, and the collaboration required > to deliver robust support for a given hardware platform can be difficult to > coordinate. Even with today's hardware, mostly inexpensive from a historical > perspective, there is still a substantial cost in developing the corresponding > software support. > > > Your concern — about being able to reproduce a known working state of your > > development environment — is much more fundamental. You're right: this > > should be straightforward, and if it's not, then it's something we want to > > improve. Ease of use and accessibility are important to us, and sometimes > > we’re just too close to the system to see where friction arises — so thank > > you again for pointing this out. > > > > To clarify one key point: we don’t deliberately withhold features or > > usability improvements from the open-source version of L4Re to push people > > into commercial contact. That’s not our business philosophy. In fact, that > > would go directly against our goal of getting L4Re into more hands and > > making it easier to work with. > > I think it is fine to encourage people to make contact and to discuss > opportunities, and I don't seriously believe that people are being herded in > the direction of commercial support, but any kind of obstacle or hurdle in the > independent evaluation of a technology can be dissuasive. Some evaluators are > more likely to move on and look at other things than to cultivate some kind of > dialogue. > > This doesn't only happen in a commercial context. On plenty of occasions in > academia, I saw researchers encouraging others to get in touch, in order to > work around deficiencies in the way they had communicated or published their > work. I also saw the long-term effects of this, where people could not account > for what they had published after only a few years, with this emerging when I > was actually making contact with them to try and distribute their originally > published data. > > Empowering other people as much as possible or practicable may eventually > return such favours. When I return to my own work after a substantial period > of time, it is almost as if I am just another person taking a look at it, too. > > > Some of the convenience features — like release tagging — do exist in our > > customer repositories, but it’s more of a workflow habit than a conscious > > decision to exclude them from GitHub. No one had brought up the need for > > that kind of reproducibility in the open repo so far — and now that you > > have, let’s fix it. > > I can understand that it can be easy to overlook. How many times has one seen > missing tags in public repositories because Git makes it easy to forget to > push them? I also understand that publicly tagging releases can make mistakes > difficult to rectify, but I suppose this is just another hazard of release > management, and eventually we all get used to making "patch" releases. > > > Would something like weekly tags on GitHub help you? For example, a tag like > > `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that > > specific state? > > It might, but I think the challenge is then applying such tags to a large > number of repositories. Naturally, one can write scripts to synchronise all > those repositories, but isn't that what ham is supposed to achieve? > > Richard also mentioned various other packages that ham doesn't cover, and > having been working with the software for a long time now, there are still > various packages that I have needed to retrieve from the Subversion repository > for L4Re because they were never migrated to GitHub. I can understand that > those packages are no longer a focus, and I have even eliminated some of them > from my own environment, but they might still be used by the L4Re > demonstrations. > > > Also, ham already supports pinned revisions in the manifest (`revision` > > attribute in `project` tags), so you can share a complete and reproducible > > state that way as well. But I agree that this could be made more > > convenient. > > Unfortunately, I never discovered this, but I assumed that you must have a way > to capture the state of repositories in order to reproduce releases required > by customers. > > > One possible improvement could be a `ham create-pinned-manifest` sub-command > > that generates such a manifest from your current state. That’s not trivial > > — it would require resolving different remotes and checking that all > > commits are actually reachable in one of the remotes — but it’s definitely > > doable. If you're interested, feel free to open a proposal or even an issue > > on the ham GitHub repository — we’d love to hear your thoughts or > > collaborate on a solution. > > It is something I could consider working on, but it would be joining a long > list of other tasks. > > > Would any of these ideas help in your workflow? Do you have something else > > in mind? We're always happy to improve L4Re together with the people who > > use it. > > I think they would be helpful. Previously, with Subversion, one could request > a given release and get a versioned distribution of the software. The > disadvantages were the poor performance of Subversion and the awkwardness of > managing independent changes, as we all know. But that simplicity was also > very useful. > > Thanks once again for following up and giving my concerns your consideration! > > Paul > > > > ------------------------------ > > Message: 3 > Date: Wed, 14 May 2025 16:04:06 +0000 > From: Richard Clark <richard.clark(a)Coheretechnology.us> > Subject: RE: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Marcus Hähnel <support(a)kernkonzept.com>, Paul Boddie > <paul(a)boddie.org.uk>, "l4-hackers(a)os.inf.tu-dresden.de" > <l4-hackers(a)os.inf.tu-dresden.de> > Message-ID: <PH1P110MB17256A3F2418A9467AC57D79FC91A(a)PH1P110MB1725.NAM > P110.PROD.OUTLOOK.COM> > Content-Type: text/plain; charset="utf-8" > > Marcus, > > I, for one, rather than having to learn yet-another-tool that doesn't quite do what I want, would rather that > you have a fully-blessed-and-tested release all rolled up in a tar (or zip) file for download. You could even have > a git repo just for the tar files. One caveat, being that it must contain ALL the repos and possible little pieces > that could possibly go with it. One thing I hate about git is sub-repos that get lost or are not pulled down and > cause severe headaches trying to match versions. Like lwip, or virtio_switch, or any of the other couple dozen > packages that don't get pulled down with the new ham build process. I'd like to be able to go to one place, > use a command I already know, and get a fully functional, fully populated, "blessed" version. You do have your > old downloads site with a tgz file, but even that doesn't contain all the packages any more. This is the frustrating part. > I need a way to get a snapshot of everything that could possibly go together in a release whether I need it or not, because > some day I will need it and then the version I need will no longer be available. So, not a "demo" or "example" > version, but a full-source-everything-including-the-kitchen-sink version. > > > Thank you for considering our opinions! > > > Richard > > > -----Original Message----- > From: Marcus Hähnel <support(a)kernkonzept.com> > Sent: Wednesday, May 14, 2025 10:53 AM > To: Paul Boddie <paul(a)boddie.org.uk>; l4-hackers(a)os.inf.tu-dresden.de > Subject: Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, > > > running compile checks for all our supported architectures as well > > > as an extensive test suite on different platforms and > > > configurations. So from that point of view I would say you can > > > consider all code pushed to Github as “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people > > wanting to provide solutions for paying customers, but I have > > personally wondered how I might successfully and conveniently > > reproduce repository configurations when creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might > > want to replicate the L4Re configuration I have been using for another > > board. Starting from scratch, it was possible to use the ham tool, but > > despite it apparently maintaining version details for the different > > repositories, it wasn't particularly clear how one might preserve or > > export that metadata for further use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone > > serious-enough about using L4Re would get in touch with Kernkonzept > > and start talking business, but such a lack of clarity tends to > > suggest that either there aren't particularly adequate solutions for > > such fundamental needs or that any adequate solutions that may exist > > aren't for people merely investigating or evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved > > that everybody feels comfortable with, and if there's a steady stream > > of interested customers that seems to justify such a decision, but I > > could easily see potential users going elsewhere if the answer to > > simple questions is "talk to us". Even in reasonably large > > organisations, hitting an approval barrier that "talk to us" or > > "register your interest" represents can be a strong disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own > > activities are confined to my own interests and driven by a general > > belief that L4Re represents a reasonable foundation for certain kinds > > of systems. That there isn't exactly much of a public community around > > L4Re could also be regarded as a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it as best we can and would love to see it grow. > > I think you're raising a different, but equally important, point compared to what Richard was asking. My original response focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. > > Your concern — about being able to reproduce a known working state of your development environment — is much more fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — so thank you again for pointing this out. > > To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against our goal of getting L4Re into more hands and making it easier to work with. > > Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of reproducibility in the open repo so far — and now that you have, let’s fix it. > > Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that specific state? > > Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a complete and reproducible state that way as well. But I agree that this could be made more convenient. > > One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. > > Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re together with the people who use it. > > Best regards, > > - Marcus Hähnel > Principal Engineering Lead > > > -- > +++ Register now for our workshop “Get to know L4Re in 3 days” on > +++ October 28–30. Learn to design and deploy secure system > architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ > > --- > > Kernkonzept GmbH > Sitz: Dresden > HRB 31129 > Geschäftsführer: Dr.-Ing. Michael Hohmuth > > > > > _______________________________________________ > 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 > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > > > ------------------------------ > > End of l4-hackers Digest, Vol 246, Issue 9 > ******************************************

2 3

Re: Linux console?
by Adam Lackorzynski 16 Apr '25

16 Apr '25

Hi Richard, your dts has the 'l4vmm,vcon_cap = "uart";' enabled (not commented out), thus the 8250 UART emulation in uvmm looks for a "uart" capability which is not there and thus disables the virtual UART. Removing that line or commenting it out will make this work I believe as the standard capability will be used then. Adam On Mon Apr 14, 2025 at 11:57:32 +0000, Richard Clark wrote: > Adam, > > Yes the vm-basic.cfg is where I started. > > I am attaching a tgz file with two directories showing the two different outputs that I get when > trying to run hvc0 and ttyS0. Included are the config files, the ramdisk, and the dts as well. > > > Richard > > > -----Original Message----- > From: Adam Lackorzynski <adam(a)l4re.org> > Sent: Monday, April 14, 2025 12:49 AM > To: Richard Clark <richard.clark(a)Coheretechnology.us>; l4-hackers(a)os.inf.tu-dresden.de > Cc: Bud Wykoff <bud.wykoff(a)Coheretechnology.us> > Subject: Re: Linux console? > > Hi Richard, > > On Fri Apr 11, 2025 at 15:27:18 +0000, Richard Clark wrote: > > L4Re, > > > > I’ve been working with the examples and tweaking them for AMD64 > > (QEMU), and I’ve managed to get linux up and booting, reading the > > ramdisk, and even spawning a login process which kicks off /bin/sh and > > displays a # prompt. And that’s great, but that’s all it does. I can’t > > get any input to it. That’s using the device hvc0. Of course uvmm > > complains that there is no virtual console and warns that it might not > > work, so the software is at least not surprised! 😊 But when I try to > > use the device ttyS0, linux stops printing even before the login > > process tries to run. I don’t get any errors, but also no output. And > > I can’t seem to run the IO server because then linux won’t load at all (something about out-of-memory). > > > > I’m sure I’m missing some little piece of magic somewhere, but I can’t > > find any working examples. None of them have active logins (I had to > > add my own iniittab to the ramdisk). A little help connecting the cons > > service to my linux so I can get a real bash shell? Or running IO and > > connecting through that? > > Did you try to run for example the "VM-basic" entry that is there? That is supposed to be a minimal working example. > Please also provide the output from the system you're getting, that is helping understanding what's going on. > > > Thanks, Adam _______________________________________________ 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 6

L4Re running Chromium?
by Lonnie Cumberland via l4-hackers 14 Apr '25

14 Apr '25

Hi All, Hope that your day is going well. I am experimenting with ultra-lightweight object capabilities-based OS's and have only briefly in the past worked a little with L4Re as I had troubles getting it to run cleanly on my Intel NUC7 (x86_64) hardware due to some type of graphics problem. In any case, I am back to see if I can give it another go and would like to work toward building a type of ultra-lightweight Kiosk type system that might run Chromium web browser in full screen mode without any type of window manager straight from booting up. The project that I have in mind would only use and need a fullscreen web browser, and perhaps capabilities to run containers (docker or podman) perhaps so that I could run a local web server and some other things in the containers. Not sure if L4Re is able to handle all of this, but I wanted to ask, just in case. Thanks and have a great day, Lonnie _______________________________________________ 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

Using L4 to run multiple Linux VMs
by Hübner, Andreas 14 Apr '25

14 Apr '25

Hello L4 hackers, I'm currently evaluating whether we can use Fiasco/L4Re for some of our future projects and ran into some problems/questions that you might help me out with. The general idea is to isolate multiple Linux VMs running Debian/Ubuntu (unmodified kernel) on x86/amd64 hardware with L4Re. I already did most of the tutorials on the kernkonzept/manifest github wiki. (https://github.com/kernkonzept/manifest/wiki) There were some issues with the hardware I'm using, since it maps its BIOS to an address that L4 likes to use for page tables. (at least on amd64, x86 did work out of the box) I fixed it by adjusting the base address in the linker script. (Hopefully, this should not have any bad side effects on L4.) First question: In the VM tutorials, I always see the use of kernel image + cpio ramdisk in the startup code. Is this also applicable if I want to use a full-fledged Debian/Ubuntu installation? The guest system should also be able to modify the installation. (i. e. run apt-get upgrade etc.) Second question: The general architecture for the VM scenario seems to be Fiasco/L4 -> uvmm -> Linux VMs. Is it also possible to use L4Linux as Host for the Linux VMs? My assumption would be, that it might be easier to use the Linux VMs from Linux instead of uvmm. (maybe with kvm/libvirt support?) Especially when it comes to passing the hardware to the VMs. Third question: This is a direct follow up from the last point. Passing the HW is the hard part for me. I'm not that familiar with device tree files yet and as far as I know x86/amd64 usually does not use device tree because it can auto-detect via PCI/ACPI. But it looks like uvmm/io does require device tree to pass the HW to the VMs even though L4 itself is detecting it via PCI/ACPI. Maybe I can pass the whole PCI bus, but then I would like to isolate at least some parts. For example VM 1 should only get one port of the network adapter and VM 2 should get another one. (exclusively) And while both VMs should be able to read the RTC, they should not be able to modify it. (or maybe only one of them) I know, it's not really a question, but maybe you can give me some advice on how best to approach this on x86/amd64 hardware. Fourth question: Does Fiasco/L4 support SR-IOV? I checked the code + commits and there seems to be some development in the last year, but not sure how "mature" it is. That's all for now, thanks for reading and I hope the questions are not too embarrassing/annoying. :) Best regards, Andreas Hübner Software Developer Business Fullfillment | Research & Development aconnic group OFFICE: 01157 Dresden, Am Lehmberg 54, GERMANY Phone +49 3722 7351-1010 E-Mail andreas.huebner(a)aconnic.com Web www.aconnic.com Court Munich Registration HRB 292019 Chairman of the Supervisory Board: Dr. Stefan Hagemann Executive Board: Werner Neubauer, Markus Königshofer aconnic AG (Munich), aconnic system Germany GmbH (Hartmannsdorf), aconnic service GmbH (Kornwestheim), aconnic sistemas de telecomunicaciones S.A. de C.V. (Mexico City), aconnic system Switzerland AG (Zurich), aconnic engineering AG (Zurich), aconnic carbonzero GmbH (Starnberg) are direct affiliates of the aconnic group. We refer to our data protection rules at: https://www.aconnic.com/privacy/ _______________________________________________ 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 3

Linux console?
by Richard Clark 14 Apr '25

14 Apr '25

L4Re, I’ve been working with the examples and tweaking them for AMD64 (QEMU), and I’ve managed to get linux up and booting, reading the ramdisk, and even spawning a login process which kicks off /bin/sh and displays a # prompt. And that’s great, but that’s all it does. I can’t get any input to it. That’s using the device hvc0. Of course uvmm complains that there is no virtual console and warns that it might not work, so the software is at least not surprised! 😊 But when I try to use the device ttyS0, linux stops printing even before the login process tries to run. I don’t get any errors, but also no output. And I can’t seem to run the IO server because then linux won’t load at all (something about out-of-memory). I’m sure I’m missing some little piece of magic somewhere, but I can’t find any working examples. None of them have active logins (I had to add my own iniittab to the ramdisk). A little help connecting the cons service to my linux so I can get a real bash shell? Or running IO and connecting through that? Thank you in advance! Richard _______________________________________________ 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 1

Loading L4 after Uboot on ZynqMP
by mkravchik＠hotmail.com 10 Apr '25

10 Apr '25

Hello, I'm trying to run L4 on a Xilinx ZyncMP board. The board runs Uboot from ROM and then I tried to load L4 as described in https://l4re.org/bsp/zynqmp.html. However, loading a uimage fails, I'm getting an error: ZynqMP> fatload usb 0:1 0x0ffffc0 bootstrap_hello.uimage ZynqMP> bootm 0x0ffffc0 ## Booting kernel from Legacy Image at 00ffffc0 ... Image Name: L4 Image #8 Created: 2025-03-31 14:14:32 UTC Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1530680 Bytes = 1.5 MiB Load Address: 01000000 Entry Point: 01000000 Verifying Checksum ... OK XIP Kernel Image FDT and ATAGS support not compiled in ### ERROR ### Please RESET the board ### I tried to use rawimage, but there I get to the following problem: ZynqMP> fatload usb 0:1 0x1000000 bootstrap_hello-cfg.rawimage 2149176 bytes read in 151 ms (13.6 MiB/s) ZynqMP> go 0x1000000 ## S� L4 Bootstrapper Build: #15 Thu Apr 3 11:39:37 IDT 2025, 9.4.0 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (00000000 - 7fffffff) RAM: 0000000000000000 - 000000007fffffff: 2097152kB Total RAM: 2048MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/hello.cfg Compressed modules: cannot decompress at 0x10a8000, try 0x11bc000 Uncompressing modules (modaddr = 0x11bc000 (backwards)): mod06: 0x126c000-0x1296b38: hello mod05: 0x126b000-0x126b080: hello.cfg mod04: 0x11e1000-0x126a118: ned mod03: 0x11bc000-0x11e0c40: l4re Loading fiasco found node 0 kernel info page (via ELF) at 0x3000 L4Re is configured for EL2 mode (virtualization / hypervisor) but got started in EL1 by the boot-loader. Please change your boot-loader to start L4Re in EL2 mode. I'm not sure how to proceed from here. The Uboot is loaded from the board's ROM and is running at EL2. Any help is appreciated, Moshe _______________________________________________ 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 5

L4re RAM/Flash usage and scheduling timing Info
by Eric Miniere via l4-hackers 28 Mar '25

28 Mar '25

Hello Everyone, I am looking for an estimate of the memory footprint to run the hypervisor L4RE on a quad Core ARM Cortex R52. Does it run directly from flash or it needs to be copied to run in RAM ? same question for Guests OS (ie FreeRtos)? What could be the minimal needed L4RE footprint for code and data ? Also if someone could share a rough idea of scheduling time for an ARM R52 running at 400Mhz ? or nb of cycle it takes to schedule ? Thanks _______________________________________________ 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 3

Trouble booting L4Re on PC hardware?
by Richard Clark 14 Mar '25

14 Mar '25

Hi! I've had much success building and running my applications in QEMU. No issues there. But now I've got myself some real hardware. Windows boots on it. Debian Linux boots on it. Linux even boots from the USB I create with rufus. No problems there. What I would like to do, is to take the system.iso image that normally runs under QEMU (x86_64), burn that to my USB stick (same way I put linux boot on there), and then boot the USB stick. The hardware will boot from the USB, and the image copy to the USB appears to work, since I've done that and booted linux. But I cannot seem to get the system.iso file to boot. I've tried UEFI boot, Classic boot, copy as UEFI image, and copy as DD image. It seems to ignore the USB drive and (by default) boot windows from the NVME drive. The device has no serial port. Just an HDMI screen with USB mouse and keyboard. It does have ethernet ports and I could try that, but it doesn't appear that the UEFI bios supports TFTP. How do I take my QEMU work and boot it on a real PC? Thanks! Richard _______________________________________________ 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

How to L4Re on the S32G
by qiang xu 27 Feb '25

27 Feb '25

*Hello L4Re experts,* I would like to know how to run L4Re on the S32G. I couldn’t find any related documentation. I’m a beginner in this technical field, so could you provide friendly step-by-step instructions? Regards, Qiang _______________________________________________ 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

4 25

saving configuration to version control
by Baruch Burstein 09 Feb '25

09 Feb '25

Hello. After running `make config`, I am trying to save my configuration to git and later restore it. This is for both fiasco and l4. I found that the command `make savedefconfig` works (just like for linux kernel) to create a defconfig file for uploading to git, but the command `make defconfig` for restoring the configuration from this file doesn't work. What file should I be saving/restoring, or what is the process to save/restore my configuration? Either a defconfig or a full configuration would be ok. Thank you _______________________________________________ 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

Use HW random generator to kaslr-seed dtb on uvmm
by Flavio Erlich 04 Feb '25

04 Feb '25

Hi, According to Linux documentation, if I want to use kASLR I should add on my device tree, on the chosen node a kaslr-seed entry ( https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt). I'm running uvmm and I want to use the dt-modify argument to change the value on dtb to a value that comes from an HW random generator at runtime. I have written an application which reads a random sequence from the HW. How can I pass the random value from that application and pass the u64 value to the ned script which I can use as a seed? I can use the application exit code to read 32-bit and run it twice, but seems to be overkill to do that. I was thinking of sending a newer allocatted Dataspace to the application, it will fill it with random data, but I have no idea if it is possible to read this Dataspace and concatenate the result to the arguments to uvmm. Do you have any other suggestions? Thanks for your help, Flavio _______________________________________________ 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

USB on L4RE
by Flavio Erlich 25 Jan '25

25 Jan '25

I found this thesis defence post. https://tu-dresden.de/ing/informatik/sya/professur-fuer-betriebssysteme/die… Does anyone know if or where the code is available? Is the thesis paper available? Thanks, Flavio _______________________________________________ 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

emmc-driver imx8mp
by Alvaro Gallardo 08 Jan '25

08 Jan '25

Dear L4Re experts, I hope you are doing well and enjoying this time of the year. I would like to ask for your help or insights on how to use the emmc-driver in an imx8mp based board. In this platform, the usdhc nodes are located out of the pci bus, and they require an i2c device to work, as well as gpio and clocks. I am able to start the emmc server, which identifies one usdhc device and starts the server loop. I pass a virtual bus to the emmc driver with all required devices, as they usually work in the Virtual Machine to access the mmc. The driver scans all of them, finding the usdhc node. But, everything stops when I create a client, either using a dynamic way with: create(0, "device=...","ds-max=5); or declaring the client in the argument as: "emmc-drv -v --client cl1 --device=... --ds-max=5". For the second way, it stops when the Virtual Machine starts to configure the related virtio device (I am using a virtio_net node). I will be grateful if you can give me some information about the issue or some of the following questions: 1. how should the node in the device tree of the Virtual Machine be configured to work with the emmc client? 2. is it possible that the board's specific hardware configuration required for the mmc is stopping the emmc client to work? 3. Is there any way to test the driver before linking it to a virtual machine? I found an example with the "virtio-block-chksum-sync" module, but I could not find this module. I attach the configuration files, the output text and the base device tree structure. Thank you in advance for your attention. Kind regards, Alvaro Gallardo _______________________________________________ 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

Network failure when high traffic
by Mohamed Dawod 05 Dec '24

05 Dec '24

Hello, I created a new L4 setup with uvmm module and Linux kernel running on it. I added also virtio-net-device and created new tap devices to be able to communicate with the VM from outside of L4. The setup was done successfully and I could ping from my host machine to the Linux VM and vise versa. The problem appeared when I accelerated the ping using -i option : Ping 192.168.7.2 -i 0.01 It continue pings for a few minutes then it gives (Destination Host Unreachable)! I used the wrapper function vmm.start_virtio_switch() in me demo. Why did this issue happen ? And how can I fix it? Thanks, Mohamed _______________________________________________ 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 1

Video Error Reasons?
by Lonnie Cumberland via l4-hackers 27 Nov '24

27 Nov '24

Hello All, I have been experimenting with L4Re and was able to compile the latest snapshot that seems to work well for almost all of the examples in QEMU from the "make qemu" menu which is a very good start, I think. Lately, I have also used the "make grub2iso" which gives me the same menu of examples as the "make qemu" but for which it will generate an ISO of the example. I generated ISO's for all of the examples and tested them on 3 different x64 computer systems which are all Intel with 2 being NUC's and 1 being a Dell XPS 8950 but when I boot any of the generated L4Re ISO's, it seems to boot all of the core modules but then gets to an error message that seems to be related to the video mode. ------------------------------------------- error: no suitable video mode found ------------------------------------------- And then the screen shows a bunch of lines. I have been looking around though the L4Re code in the snapshot release, but I do not yet have a clue where how to change things so that these ISO's will boot completely on some hardware although things seem to boot up in QEMU. I am thinking that there might just be some setting somewhere that I need to adjust, or something. Any thoughts, suggestions, or ideas would be greatly appreciated. Have a great evening, Lonnie _______________________________________________ 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

4 4

CPU Virtualization in L4
by Mohamed Dawod 25 Nov '24

25 Nov '24

I know that Scheduling proxy in L4 is used to set cores and priority ranges for a dedicated task. For example, The below scheduling proxy makes the task runs on cores 1,2,3 with priority range [52,62]. scheduler = vmm.new_sched(0x50, 0xE) When I switch to debugging mode, I see that this task has priority = 52 in pr column! So why does scheduling proxy set priority range instead of a single value like Linux ? How does L4 use the priority range ? My second question is about the relationship between physical CPUs and virtual CPUs in L4. I know that CPU virtualization should give the ability to virtualize the available physical CPUs so that if we have single physical CPU core, CPU virtualization enables us to provide multiple virtual CPU cores for the VMs running ontop of the hypervisor. Actually I don't see this behaviour in the scheduling proxy in L4! instead, the cores parameter only takes a bitmap of the physical cores. Can I use the scheduling proxy or any other method/workarround to provide CPU Virtualization ? Thanks, Mohamed Dawod _______________________________________________ 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 1

Porting apps to L4Re?
by Lonnie via l4-hackers 18 Nov '24

18 Nov '24

Hello All, As part of the project effort that I am working on with L4Re, I am considering 2 possible pathways of which both need graphics capabilities to interact with the uvmm for a guest OS: Possible pathways: 1. Use the framebuffer "spectrum" example and port something like FreeRDP, rdesktop or other, so that this will allow for a loabable RDP service VM whose only job is to connect to other VM's. This would be for having a Docker/Podman Container engine running and to be able to connect to a container via a web browser VM that has a graphic console in fullscreen mode. 2. Find a way to have L4Re be able to access the graphic console (VGA) of each uvmm guest directly and then be able to HotKey switch between active VM's. This might be like having multiple guest OS's running (i.e. Ubuntu 24.04 and Windows 10 for example) and then be able to switch the console between them. This is also an idea to allow L4Re to boot all of the OS's that might reside on a dualboot or multiboot system. I actually need something this is really a cross between both of these since in one configuration case will be (1) and in another case will be (2). Wanted to get any thoughts or suggestions that you might have towards this. Thanks and have a great day, Lonnie _______________________________________________ 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

Generating EFI files
by Lonnie Cumberland 13 Nov '24

13 Nov '24

Hello All, While exploring and testing L4Re, I have also been testing some files from the AMD64 downloads: https://l4re.org/download/snapshots/pre-built-images/amd64/ While currently the only the elf32 file do run a bit and the efi files are now known to have some problems, I was wondering how the efi files were generated. I know that in the build for l4re that you can use "make -j24" to build the core as well as "make qemu" to show some available examples that I am trying to also get to work, but I was wondering how these above "pre-built-images" were generated? Also, I am very interested in the "l4re_vm-multi.efi" and "l4re_vm-multi-p2p.efi" in how they can be generated to run under QEMU as well as how to perhaps generate an x64 ISO that can be booted on real hardware. These interest me a great deal and I would really be interested if someone might be able to explain them more to me, especially the "p2p" one since have an interest in p2p networks as well. Thanks in advance and have a great day, Lonnie _______________________________________________ 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 4

vm-basic-pci demo testing
by Mohamed Dawod 13 Nov '24

13 Nov '24

Hi, I was trying the *vm-basic-pci* demo from l4Re version 24.08.0. The demo works and I could boot the Linux VM and login successfully, but I need to test the passed PCI bus to make sure that it works. I'm trying to test it using a *virtio-blk-pci* device from qemu which is expected to be mounted as a block device in */dev/vda*. but when I found no */dev/vda* file in the filesystem. Please find attached : * my ned scripts : vm-basic-pci.log * arm-virt64.io * the dts file : virt-basic_virt-64_pci.dts * and the full logs : vm-basic-pci.log Thanks in advance, Regards -- Mohamed Dawod *Software Engineer, *Avelabs Egypt *Cell Phone : (+20) 1117311726* -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

5 7

Debugging memory allocation in L4Re
by Paul Boddie 11 Nov '24

11 Nov '24

Hello, I thought I might as well ask this since the mailing list has been somewhat active recently. I have been testing some of my software, but after a certain period of time, I experience errors of the following form: l4re_kernel: ERROR: more-mem(1000): Cannot provide more memory. l4re_kernel: ERROR: mmap() called: unimplemented! size=100000 As far as I can tell, uclibc_morecore and mmap in... pkg/l4re-core/l4re_kernel/server/src/mem.cc ...are respectively responsible for these errors, the former being called by __malloc_trim, itself called by free in... pkg/l4re-core/uclibc/lib/contrib/uclibc/libc/stdlib/malloc-standard/free.c Looking at the uclibc_morecore implementation, it seems that the "program break" is defined only once, with a dataspace of 64 pages being allocated, and any subsequent sbrk call will not cause this allocated space to be extended further. Have I understood this situation correctly? As always, I assume that I am making some kind of mistake, in this case probably not deallocating memory when I should be and thus exhausting the available space. Are there any convenient ways of monitoring memory allocation in L4Re? Thanks for any advice offered! Paul _______________________________________________ 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

Qemu Demos
by Lonnie Cumberland 11 Nov '24

11 Nov '24

Hello All, I am on an Intel NUC 13 NHNE (x64) running Ubuntu 23.10 and am working my way through the basic Qemu Demos after following the build instructions https://github.com/kernkonzept/manifest/wiki/BUILDING From there I am in the "~/l4re/build-amd64$" and have added "/l4re/l4/conf/examples" to the "l4/conf/Makeconf.boot" Now I do a "make qemu" and get the list: =============================================== │ │ │ 0 hello │ │ 1 hello-cfg │ │ 2 hello-2 │ │ 3 hello-shared │ │ 4 framebuffer-example │ │ 5 L4Linux-basic │ │ 6 L4Linux-mag │ │ 7 VM-basic │ │ 8 VM-multi │ │ 9 VM-multi-p2p │ │ 10 VM-basic-pci =============================================== For which I have been able to run items 0 - 3, but when I run (4) "framebuffer-example", I get an error about a missing "x86-lagacy.devs" file and I cannot find it anywhere in the sources or builds. =============================================== Could not find 'x86-legacy.devs' within paths /home/lonnie/l4re/build-amd64/assets /home/lonnie/l4re/build-amd64/bin/amd64_gen/l4f /home/lonnie/l4re/build-amd64/bin/amd64_gen/plain /home/lonnie/l4re/build-amd64/lib/amd64_gen/std/l4f /home/lonnie/l4re/build-amd64/lib/amd64_gen/std/plain /home/lonnie/l4re/build-fiasco-amd64 /home/lonnie/l4re/l4/conf/examples make[1]: *** [Makefile:693: qemu] Error 1 make[1]: Leaving directory '/home/lonnie/l4re/l4' make: *** [Makefile:6: do-all-make-goals] Error 2 =============================================== I then restarted "make qemu" and tried (7) VM-basic, but it seems to abort with the messages: =============================================== MOE: Starting: rom/ned rom/vm-basic.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/vm-basic.cfg' VMM[]: Created VCPU 0 @ 18000 VMM[]: >>> CAUTION: Support for AMD SVM is experimental, use at your own risk! <<< terminate called after throwing an instance of 'N2L413Runtime_errorE' what: Invalid request: SVM does not support next_rip save. Aborting! =============================================== In trying to run the other VM-????? choices, I also get similar messages: =============================================== vm-1 | VMM[]: Created VCPU 0 @ 18000 vm-1 | VMM[]: >>> CAUTION: Support for AMD SVM is experimental, use at your own risk! <<< vm-1 | terminate called after throwing an instance of 'N2L413Runtime_errorE' vm-2 | VMM[]: Created VCPU 0 @ 18000 vm-2 | VMM[]: >>> CAUTION: Support for AMD SVM is experimental, use at your own risk! <<< vm-3 | VMM[]: Created VCPU 0 @ 18000 vm-3 | VMM[]: >>> CAUTION: Support for AMD SVM is experimental, use at your own risk! <<< vm-2 | terminate called after throwing an instance of 'N2L413Runtime_errorE' vm-1 | what: Invalid request: SVM does not support next_rip save. Aborting! vm-3 | terminate called after throwing an instance of 'N2L413Runtime_errorE' vm-1 | vm-2 | what: Invalid request: SVM does not support next_rip save. Aborting! vm-2 | vm-3 | what: Invalid request: SVM does not support next_rip save. Aborting! vm-3 | ========================================================= Has anyone been able to get all of these to run? I am still exploring but would like to get the be able to compile and run the VM-multi examples on the x64 hardware like in the video. https://l4re.org/cast-multi-vm-qemu.html Any thoughts on how to test out some of these? Best and have a great weekend, Lonnie _______________________________________________ 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

Building Screenshots and examples
by Lonnie Cumberland 10 Nov '24

10 Nov '24

Hello All, I hope that your day is going well. Recently, I have decided to explore L4Re as a microhypervisor and capabilities as a possible minimalist component-based microkernel OS. I have just set up Ubuntu 23.10 (x64) in an Intel NUC13 and would am reviewing as much documentation as I can find as well as am building the core L4Re according to the Github Wiki just to see how the process goes. https://github.com/kernkonzept/manifest/wiki/BUILDING As I am in the learning curve at the moment, I also would like to build some examples such as the "Screenshots" (https://l4re.org/screens.html) and demos from the Pre-Built section (https://l4re.org/download/snapshots/pre-built-images/amd64/). I did try to follow the direction on the pre-built sections and grabbed the "l4image" and all of the AMD64 EFI files to try and test, but when I launch them they just seem to hang and do nothing. I do have qemu (x64) installed as well, but still nothing seems to boot. What I would like to ask the mailinglist members is where can I get the source code to the "screenshots" examples as well as the AMD64 "pre-built" examples noted above so that I cam do a fresh compile to see them in action? Any help would be greatly appreciated. Thanks in advance and have a great day, Lonnie _______________________________________________ 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

4 8

Multiple CPU support for uvmm on virt-arm64 qemu machine
by Mohamed Dawod 06 Nov '24

06 Nov '24

Hello, I'm trying to provide multiple CPUs for a linux VM on top of L4. I'm using the qemu virt machine and building for aarch64. so I used *-smp* option to provide more CPUs. > $ qemu-system-aarch64 -M virt,virtualization=true -cpu cortex-a57 -smp 4 > -m 1024 -kernel ....etc.... Unfortunately, This didn't work. I tried to add more CPU device nodes to the dts file *virt-arm_virt-64.dts *but it also didn't work. I think that it's because of the provided interrupt-controller with *virt-arm_virt-64.dts* in *l4/pkg/uvmm/conf/dts* which mentioned that it supports only one CPU. > icsoc { > compatible = "simple-bus"; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > /* Uvmm will adapt the compatible string depending on the present > gic > * version. It expects reg entries that provide enough space for > the > * Cpu/Dist interface for gicv2 (at least 0x1000, 0x1000) or the > * Dist/Redist interface for gicv3 (0x10000, 0x20000 * number of > cpus). > * > *The entries provided here support any gicv2 setup or a gicv3 setup > * with one Cpu.* > */ > gic: interrupt-controller { > compatible = "arm,gic-400", "arm,cortex-a15-gic", > "arm,cortex-a9-gic"; > #interrupt-cells = <3>; > #address-cells = <0>; > interrupt-controller; > reg = <0 0x40000 0 0x10000>, > <0 0x50000 0 0x20000>; > }; > }; > My question now, is there any workaround to support multiple CPUs for virt machine on arm64 ? Thanks, Regards -- Mohamed Dawod *Software Engineer, *Cairo Egypt -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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 9

[FOSDEM 2025] Call for Participation: Microkernel and Component-Based OS Devroom
by Udo Steinberg 30 Oct '24

30 Oct '24

Hi all, below is the official CfP for the microkernel devroom at FOSDEM 2025. I am looking forward to a strong participation from all microkernel/unikernel research groups and companies, not only in the form of attendance, but also in the form of great talks :) Cheers, Udo We are happy to announce the CfP for the "Microkernel and Component-Based OS" devroom at the upcoming FOSDEM 2025. Developers and users of various free and open-source microkernel-based, unikernel-based and component-based operating systems will meet again at FOSDEM (https://fosdem.org) during the weekend of February 1/2, 2025 and will share a developer room. The microkernel and component-based OS devroom is currently looking for your participation in the form of proposals for talks, demos and other related activities. Possible topics for 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, devices 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 * live demos Important Dates The deadline for submitting proposals is December 1, 2024 (23:55 CET). Please use the FOSDEM website at https://fosdem.org/submit, select the track "Microkernel and Component-Based OS" and include at least the following information: * title of your proposal * short abstract (one or two paragraphs) * duration (20 - 40 minutes, including demos and Q&A) * your full name * your short bio The devroom schedule (with accepted talks) will be announced on the devroom website at https://fosdem.org/2025/schedule/track/microkernel by December 15, 2024. The schedule will also be posted to the devroom mailing list and the speakers will be notified via email. Like previous years, the devroom will take place as an in-person event at the ULB Campus Solbosch in Brussels, Belgium during the second half of February 1, 2025 (Saturday). Due to the high number of submissions that FOSDEM received this year, our devroom has only been allocated half a day. Therefore, the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. Requirements The communication language of the devroom is English. All content must relate to free and open-source software. By participating in the event, you agree to the publication of your talk recordings, slides and other content provided under the same CC-BY license as all other FOSDEM content. All participants are expected to adhere to the Code of Conduct: https://fosdem.org/2025/practical/conduct/ Contact For the 2025 edition, the organizers of the devroom are * Udo Steinberg (udo [at] hypervisor.org) * Alexander van der Grinten (alexander.vandergrinten [at] gmail.com) For any comments, questions and suggestions, please do not hesitate to contact us directly or via microkernel-devroom-manager(a)fosdem.org. About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012, this devroom has been a part of each subsequent FOSDEM (with slight variations of the name). The focus gradually widened to include component-based, unikernel-based and other operating systems. It has now 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 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 in the past, the devroom will offer the stage both to established community members and to newcomers. Our goal is to select talks in an inclusive manner and to create a balanced and unbiased schedule, while keeping the quality of the devroom as high as in previous years. About FOSDEM FOSDEM 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 new ideas, latest results, 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 and requires no registration, although the organizers gratefully accept donations and sponsorship. Devroom Dinner Over the years, it has become a tradition that devroom speakers and enthusiasts meet for dinner somewhere in Brussels on Saturday evening to continue discussions, socialize and meet old and new friends. We plan to follow that tradition in 2025 and will inform you about the exact arrangements later. Hope to see all of you in Brussels! _______________________________________________ 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

1 0

vm-basic-pci demo is not working for arm64
by Mohamed Dawod 29 Oct '24

29 Oct '24

Hi, I was trying to run the L4 demo *vm-basic-pci* for *arm64* using the command $ make qemu E=vm-basic-pci but It didn't work because of the missing 2 files : * virt-arm_virt-64_pci.dtb : which is requested by the *modules.list* file in the line : > module[arch=arm64,fname=virt-pci.dtb] dtb/virt-arm_virt-64_pci.dtb * virt-pci.dtbo : which is requested by the *vm-basic-pci.cfg* by the configuration > if (L4.Info.arch() == "arm64") then > dt = "-drom/.fdt" > overlay = "*-drom/virt-pci.dtbo*" > else > dt = "-drom/virt-pci.dtb" > overlay = "" > end I searched for both files in the whole *l4re-snapshot-23.10.1* directory but I couldn't find them Where can I find those necessary files to run *vm-basic-pc*i demo? Thanks in advance, Regards -- Mohamed Dawod *Software Engineer,* Cairo Egypt -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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 11

PCIe handling in virt arm64
by Mohamed Dawod 20 Oct '24

20 Oct '24

Hello, I need to pass through the PCIe bus to Linux VM via io and uvmm servers. First, I generated the corresponding dtb file from qemu for *virt* machine to get the exact pcie device node. $ qemu-system-aarch64 -nographic -machine > virt,virtualization=true,dumpdtb=conf/arm_virt-64-full.dtb > $ dtc -I dtb -O dts conf/arm_virt-64-full.dtb Secondly, I copied the following nodes to my dts file (*pcie@10000000*, *intc@8000000* and *v2m@8020000*) exactly as they are in the original dts file. Finally, I modified the ned scripts as mentioned in the comments of the *pcie_ecam.cc* file. The issue is that there is no IO driver for the device *v2m@8020000 *which is responsible for msi-controller. This device is needed for the PCIe. The error logs : > VMM[PCIe ctl]: PCIe host bridge pcie@10000000 refers to invalid MSI > controller: MSI parent is not an MSI controller > VMM[HW PCI dev]: No MSI-X controller available for MSI-X device pci_bus[1] > (devid=1) > VMM[HW PCI dev]: No MSI-X controller available for MSI-X device pci_bus[2] > (devid=2). > VMM[ioproxy]: No corresponding IO resource for 'v2m@8020000'.reg[0] > (0x8020000-0x8020fff). > VMM[vm]: Device creation for v2m@8020000 failed. Disabling device. How can I pass through the PCIe device if there is no IO driver for the needed msi-controller ? Thanks in advance, Regards -- Mohamed Dawod *Software Engineer, *Cairo Egypt -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

1 0

virtio disk handling
by Mohamed Dawod 09 Oct '24

09 Oct '24

Hello, I was reading this tutorial <https://github.com/kernkonzept/manifest/wiki/NVMeWithLinux> about using NVMe server with Linux guest and it works fine. Now I'm trying to apply the same tutorial but for arm64 instead of AMD64/X86_64. As expected, it didn't work because arm64 device tree blob/source doesn't contain the same *PCI* bus with the attached *virtio_disk* device node. Instead, virt-arm_virt-64.dts file contains only 2 VMM virtual devices for ARM guests : *virtio_uart* and *virtio_net*. I need a way to apply the same Tutorial (using NVMe server with Linux guests) for ARM64 instead of AMD64/X86_64. Any suggestions? Thank you, Regards -- -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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

sharing RTC device between 2 linux VMs
by Mohamed Dawod 03 Sep '24

03 Sep '24

Hi, I was trying to pass the RTC device from the host machine (qemu-arm46) to the guest machine linux VM on top of L4. and it was done successfully. Now I'm trying to share the same device between 2 linux VMs on top of L4. by duplicating the virtual device that describes the same physical device and also duplicating the virtual bus and passing one for each new vm. The issue if that one of the VMs is terminated because of the disability of binding the same IRQ as described in the screenshot below : [image: image.png] Please find attached all ned scripts I'm using for this experiment. Thank you, Regards -- Mohamed Dawod *Software Engineer, *Avelabs Egypt *Cell Phone : (+20) 1117311726* -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html> _______________________________________________ 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 3

Fwd: Systems Meetup ("Mikrokernstammtisch") 16.05 (Do.) @ Cyberus Office
by Jan Bierbaum 02 May '24

02 May '24

FYI -------- Forwarded Message -------- Subject: Systems Meetup ("Mikrokernstammtisch") 16.05 (Do.) @ Cyberus Office Date: Thu, 11 Apr 2024 09:05:22 +0000 From: Philipp Schuster <philipp.schuster(a)cyberus-technology.de> Hallo alle zusammen, Wir von Cyberus würden gerne den "Mikrokernstammtisch" in Dresden wieder neues Leben einhauchen und ein gemeinsames Treffen mit der Systems Community in Dresden organisieren. Dafür möchten wir gerne unser Büro am 16.05 (Do.) von 18:00 bis 22:00 zur Verfügung stellen. Leitet diese Einladung gerne auch an einige Freunde oder Kolleg:innen weiter, wenn sie daran Interesse hätten. Wir stellen für das Meetup diverse Getränke bereit sowie einen Meeting-Raum. Hier die Fakten: - Donnerstag, 16.05, 18:00 - 22:00 - Systems Meetup, nicht nur Mikrokerne 🙂 - If necessary, we are happy to switch to english - 10-30 Leute (grobe Schätzung) - 2-4 Lightning Talks für Gesprächsstoff Lightning Talks: - 5 bis 10 Minuten - Mögliche Themen - Entwickler-Produktivität im Alltag - Testing setups - Coole Produkte/Projekte - knifflige gelöste Probleme - Demos - ... TODOs: - Bitte meldet euch ob ihr dabei seid + wie viele weitere Gäste kommen - Bitte meldet euch ob ihr Interesse habt einen kurzen Lightningtalk zu halten Hoffentlich bis bald! PS: Ich möchte euch noch darüber informieren, dass die ukvly Mailingliste die früher von Julian Stecklina betrieben wurde leider endgültig tot ist. Bei regem Interesse und Teilnahme, können wir gerne einen neuen Kommunikationschannel beim Meetup etablieren. -------------------------------------------------------- Philipp Schuster Software Engineer E-Mail: philipp.schuster(a)cyberus-technology.de Cyberus Technology GmbH Zwickauer Str. 46 01069 Dresden Deutschland/Germany Telefon: +49 175 431 6677 (Tor Lund-Larsen) Web: https://www.cyberus-technology.de/ Geschäftsführer: Tor Lund-Larsen Sitz der Gesellschaft: Dresden Amtsgericht Dresden, HRB 36573 _______________________________________________ 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

1 0

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

l4re + rpi4 + mmc + vm + net
by Matthieu Fatrez 19 Sep '21

19 Sep '21

Hello l4-hackers, I try to run a vm with l4re on a RPI4b with this files bellow, but I don't know how to find the root device to finalize the boot process. I haven't played on the network part yet, but if you have any advice on the subject as well, I'm a taker. Help needed please. Thanks. vm_hw.vbus ------8<------------------------------------------------------------------------------------------------ Io.add_vbusses { vm_hw = Io.Vi.System_bus(function() MMC = wrap(Io.system_bus().mmc); end); } ------8<------------------------------------------------------------------------------------------------ io.cfg ------8<------------------------------------------------------------------------------------------------ local Res = Io.Res local Hw = Io.Hw local add_children = Io.Dt.add_children add_children(Io.system_bus(), function() mmc = Hw.Device(function() compatible = { "brcm,bcm2835-mmc" }; Resource.reg0 = Res.mmio(0xfe300000, 0xfe3000FF); Resource.irq0 = Res.irq(0x7e + 32); Property.flags = Io.Hw_device_DF_dma_supported; end) end) ------8<------------------------------------------------------------------------------------------------ mmc.dts ------8<------------------------------------------------------------------------------------------------ /dts-v1/; /include/ "virt-arm_virt-64.dts" / { mmc@fe300000 { compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci"; reg = <0xfe300000 0x100>; interrupts = <0x0 0x7e 0x4>; clocks = <0x3 0x1c>; dmas = <0xa 0xb>; dma-names = "rx-tx"; brcm,overclock-50 = <0x0>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <0x19>; bus-width = <0x4>; phandle = <0x2d>; }; }; ------8<------------------------------------------------------------------------------------------------ mfa.cfg ------8<------------------------------------------------------------------------------------------------ local L4 = require "L4"; local l = L4.default_loader; vbus_l4linux = l:new_channel(); -- Start io & flash memory l:start({ caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0), icu = L4.Env.icu, vm_hw = vbus_l4linux:svr() }, log = {"IO", "y"} }, "rom/io rom/io.cfg rom/vm_hw.vbus -vvvvvv"); l:startv({ caps = { ram = L4.Env.user_factory:create( L4.Proto.Dataspace, 256 * 1024 * 1024, L4.Mem_alloc_flags.Continuous | L4.Mem_alloc_flags.Pinned | L4.Mem_alloc_flags.Super_pages, 21):m("rws"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws") }, "rom/uvmm", "-v", "--kernel", "rom/Image.gz", "--ramdisk", "rom/ramdisk-armv8-64.rd", "--dtb", "rom/mmc.dtb", "--cmdline", "console=hvc0 ramdisk_size=10000 root=/dev/mmcblkp3 rw"); ------8<------------------------------------------------------------------------------------------------ in modules.list ------8<------------------------------------------------------------------------------------------------ entry mfa roottask moe rom/mfa.cfg module l4re module hello module uvmm module ned module mfa.cfg module uvmm module cons module dtb/virt-arm_virt-64.dtb module mmc.dtb module[shell] echo $SRC_BASE_ABS/pkg/uvmm/configs/vmm.lua module ramdisk-armv8-64.rd module[uncompress] Image.gz module io module io.cfg module vm_hw.vbus ------8<------------------------------------------------------------------------------------------------ Log from console ------8<------------------------------------------------------------------------------------------------ ## Starting application at 0x010000 L4 Bootstrapper Build: #29 Sat Sep 18 16:38:05 CEST 2021, 10.2.1 20210110 Raspberry Pi Model 4B, Rev 1.4, 8192MB, SoC BCM2711 [d03114] Warranty intact, OTP reading allowed, OTP programming allowed, Overvoltage allowed RAM: 0000000000000000 - 000000003b3fffff: 970752kB RAM: 0000000040000000 - 00000000fbffffff: 3080192kB RAM: 0000000100000000 - 00000001ffffffff: 4194304kB Total RAM: 8052MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 18 modules behind 1100000 moving module 17 { 39dc000-39dc066 } -> { 3ac1000-3ac1066 } [103] moving module 16 { 39db000-39db16e } -> { 3ac0000-3ac016e } [367] moving module 15 { 3796000-39da99f } -> { 387b000-3abf99f } [2378144] moving module 14 { 16d9000-37959ff } -> { 17be000-387a9ff } [34327040] moving module 13 { 1359000-16d8fff } -> { 143e000-17bdfff } [3670016] moving module 12 { 1358000-1358dbf } -> { 143d000-143ddbf } [3520] moving module 11 { 1357000-1357756 } -> { 143c000-143c756 } [1879] moving module 10 { 1356000-13565e9 } -> { 143b000-143b5e9 } [1514] moving module 09 { 130a000-1355ecf } -> { 13ef000-143aecf } [310992] moving module 08 { 1254000-130962f } -> { 1339000-13ee62f } [742960] moving module 07 { 1253000-1253386 } -> { 1338000-1338386 } [903] moving module 06 { 11d3000-1252a97 } -> { 12b8000-1337a97 } [522904] moving module 05 { 111d000-11d262f } -> { 1202000-12b762f } [742960] moving module 04 { 10f0000-111c9e7 } -> { 11d5000-12019e7 } [182760] moving module 03 { 10d2000-10ef957 } -> { 11b7000-11d4957 } [121176] moving module 02 { 109e000-10d13d7 } -> { 1183000-11b63d7 } [209880] moving module 01 { 1098000-109dd6f } -> { 117d000-1182d6f } [23920] moving module 00 { 101b000-1097387 } -> { 1100000-117c387 } [508808] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 3000 Regions of list 'regions' [ 0, fff] { 1000} Arch mpspin [ 1000, 8dfff] { 8d000} Kern fiasco [ 8e000, 8e347] { 348} Root mbi_rt [ 100000, 10a46f] { a470} Sigma0 sigma0 [ 140000, 170cab] { 30cac} Root moe [ 171cb0, 17eed7] { d228} Root moe [ 1000000, 101900b] { 1900c} Boot bootstrap [ 10000e8, 100011b] { 34} Root cpu_boot [ 101a1a4, 101ae49] { ca6} Boot modinfo [ 11b7000, 3ac1066] { 290a067} Root Module found kernel options (via ELF) at 4000 Sigma0 config ip:00100474 sp:00000000 Roottask config ip:00141584 sp:00000000 Starting kernel fiasco at 000016d0 Hello from Startup::stage2 Number of IRQs available at this GIC: 256 FPU: Initialize ARM generic timer: freq=54000000 interval=54000 cnt=1197663468 SERIAL ESC: allocated IRQ 125 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 10.2.1 20210110 for RPi4 (Broadcom 2711) [] Build: #1 Sat Sep 18 00:56:20 CEST 2021 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Cache config: ON Allocate ARM PPI 27 to virtual 1 ID_PFR[01]: 00002222 00000000Calibrating timer loop... Cache config: ON Allocate ARM PPI 25 to virtual 0 done. Allocate ARM PPI 27 to virtual 1 MDB: use page size: 30 Cache config: ON ID_PFR[01]: 00002222 00000000MDB: use page size: 21 ID_[DA]FR0: 10305106 00000000 ID_[DA]FR0: 10305106 00000000 ID_MMFR[04]: 00001124 00000000 00000000 00000000 ID_MMFR[04]: 00001124 00000000 00000000 00000000 MDB: use page size: 12 ID_PFR[01]: 00002222 00000000S ID_[DA]FR0: 10305106 00000000 IID_MMFR[04]: 00001124 00000000 00000000 00000000 GMA0: Hello! KIP @ 3000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:8e000;8efff] [0:RWX:8f000;fffff] [0:RWX:10b000;13ffff] [4:R-X:140000;170fff] [4:RW-:171000;17efff] [0:RWX:17f000;ffffff] [4:---:1000000;1000fff] [0:RWX:1001000;11b6fff] [4:RWX:11b7000;3ac1fff] [0:RWX:3ac2000;3b3fffff] [0:RWX:40000000;fbffffff] [0:RWX:100000000;1feffffff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:3b400000;3fffffff] [0:RW-:fc000000;ffffffff] [0:RW-:200000000;ffffffffffffffff] MOE: Hello world MOE: found 8185968 KByte free memory MOE: found RAM from 8e000 to 1ff000000 MOE: allocated 8175 KByte for the page array @0x17f000 MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11b7000-11d4958] [C:107000] l4re BOOTFS: [11d5000-12019e8] [C:109000] hello BOOTFS: [1202000-12b7630] [C:10b000] uvmm BOOTFS: [12b8000-1337a98] [C:10d000] ned BOOTFS: [1338000-1338387] [C:10f000] mfa.cfg BOOTFS: [1339000-13ee630] [C:111000] uvmm BOOTFS: [13ef000-143aed0] [C:112000] cons BOOTFS: [143b000-143b5ea] [C:114000] virt-arm_virt-64.dtb BOOTFS: [143c000-143c757] [C:116000] mmc.dtb BOOTFS: [143d000-143ddc0] [C:118000] vmm.lua BOOTFS: [143e000-17be000] [C:11a000] ramdisk-armv8-64.rd BOOTFS: [17be000-387aa00] [C:11c000] Image.gz BOOTFS: [387b000-3abf9a0] [C:11e000] io BOOTFS: [3ac0000-3ac016f] [C:120000] io.cfg BOOTFS: [3ac1000-3ac1067] [C:122000] vm_hw.vbus MOE: cmdline: moe rom/mfa.cfg MOE: Starting: rom/ned rom/mfa.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/mfa.cfg' IO | Io service IO | Verboseness level: 7 IO | unused physical memory space: IO | [0000003b400000-0000003fffffff] IO | [000000fc000000-000000ffffffff] IO | [00000200000000-ffffffffffffffff] IO | no 'iommu' capability found, using CPU-phys for DMA VMM[]: Created VCPU 0 @ 17000 VMM[GIC]: create ARM GICv2 IO | Loading: config 'rom/io.cfg' IO | Loading: config 'rom/vm_hw.vbus' IO | Add IRQ resources to vbus: IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | vm_hw: [N12_GLOBAL__N_112Virtual_sbusE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | L4ICU: [N2Vi6Sw_icuE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | MMC: [N2Vi9Proxy_devE] IO | Resources: ==== start ==== IO | IOMEM [000000fe300000-000000fe3000ff 100] 32-bit non-pref (align=ff flags=2) IO | IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | Real Hardware ----------------------------------- IO | System Bus: IO | Resources: ==== start ==== IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | mmc: IO | compatible= { "brcm,bcm2835-mmc" } IO | Clients: ===== start ==== IO | MMC: [N2Vi9Proxy_devE] IO | Clients: ===== end ==== IO | Resources: ==== start ==== IO | IOMEM [000000fe300000-000000fe3000ff 100] 32-bit non-pref (align=ff flags=2) IO | IRQ [0000000000009e-0000000000009e 1] none (align=0 flags=1) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | warning: could not register control interface at cap 'platform_ctl' IO | Ready. Waiting for request. VMM[main]: Hello out there. VMM[ram]: RAM: @ 0x3c00000 size=0x10000000 (ci) VMM[ram]: RAM: VMM mapping @ 0x2000000 size=0x10000000 VMM[ram]: RAM: VM offset=0xfffffffffe400000 VMM[main]: Loading kernel... VMM[file]: load: @ 0x3c00000 VMM[file]: copy in: to offset 0x0-0x20bc9ff VMM[main]: Loading ram disk... VMM[ram]: load: rom/ramdisk-armv8-64.rd -> 0x13800000 VMM[file]: load: @ 0x13800000 VMM[file]: copy in: to offset 0xfc00000-0xff7ffff VMM[main]: Loaded ramdisk image rom/ramdisk-armv8-64.rd to 13800000 (size: 00380000) VMM[]: Create virtual console VMM[guest]: New mmio mapping: @ f1040000 10000 VMM[GIC]: GICC virtualization only supports sizes up to 0x1000, adjusting device tree node VMM[GIC]: GIC interrupt-controller.reg update: Adjusting GICC size from 20000 to 1000 VMM[guest]: New mmio mapping: @ f1060000 1000 VMM[guest]: New mmio mapping: @ f1120000 100 VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM[Timer]: Guest timer frequency is 54000000 using (1/54), (9942053/29) to calculate timeouts VMM[psci]: Register PSCI device: hvc mode VMM[ioproxy]: Adding MMIO resource MMC.reg0 : [0xfe300000 - 0xfe3000ff] VMM[ioproxy]: Registering IRQ resource MMC.irq0 : 0x9e VMM[ram]: Cleaning caches for device tree [11fff000-11fff823] ([13bff000]) VMM[main]: Populating RAM of virtual machine VMM[mmio]: Mapping [2000000 - 11ffffff] -> [3c00000 - 13bfffff] VMM[mmio]: Mapping [GICC] -> [f1060000 - f1060fff] VMM[mmio]: Mapping [1e000 - 1e0ff] -> [f1120000 - f11200ff] IO | new iomem region: p=000000fe000000 v=00000000400000 s=400000 (bmb=0x36100) IO | map mem: p=000000fe300000 v=00000000700000 s=1000: done(0) VMM[mmio]: Mapping [200000 - 2000ff] -> [fe300000 - fe3000ff] VMM[]: reschedule(): Initiating cpu startup for 418000 VMM[guest]: Powered up cpu0 [0x1f010] VMM[]: Starting Cpu0 @ 0x3c00000 in 64Bit mode (handler @ 103ed60, stack: 8000fba0, task: 41e000, mpidr: 80000000 (orig: 80000000) VMM[]: 04bab7c8: msr PMUSERENR_EL0 = 00000000 (ignored) VMM[]: ffff800010013d68: msr OSDLR_EL1 = 00000000 (ignored) VMM[]: ffff800010013d6c: msr OSLAR_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee5c: msr DBGBCR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef1c: msr DBGBVR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee50: msr DBGBCR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef10: msr DBGBVR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee44: msr DBGBCR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ef04: msr DBGBVR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee38: msr DBGBCR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002eef8: msr DBGBVR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee2c: msr DBGBCR4_EL1 = 00000000 (ignored) VMM[]: ffff80001002eeec: msr DBGBVR4_EL1 = 00000000 (ignored) VMM[]: ffff80001002ee20: msr DBGBCR5_EL1 = 00000000 (ignored) VMM[]: ffff80001002eee0: msr DBGBVR5_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecdc: msr DBGWCR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed9c: msr DBGWVR0_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecd0: msr DBGWCR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed90: msr DBGWVR1_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecc4: msr DBGWCR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed84: msr DBGWVR2_EL1 = 00000000 (ignored) VMM[]: ffff80001002ecb8: msr DBGWCR3_EL1 = 00000000 (ignored) VMM[]: ffff80001002ed78: msr DBGWVR3_EL1 = 00000000 (ignored) VQ[0x1cb30]: num=256 d:0x4c14000 a:0x4c15000 u:0x4c16000 VQ[0x1cb78]: num=256 d:0x4c0c000 a:0x4c0d000 u:0x4c0e000 [ 1.400282] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 1.414509] loop: module loaded [ 1.418690] megasas: 07.714.04.00-rc1 [ 1.425640] libphy: Fixed MDIO Bus: probed [ 1.431368] tun: Universal TUN/TAP device driver, 1.6 [ 1.437279] thunder_xcv, ver 1.0 [ 1.440867] thunder_bgx, ver 1.0 [ 1.444438] nicpf, ver 1.0 [ 1.448109] hclge is initializing [ 1.451734] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version [ 1.459356] hns3: Copyright (c) 2017 Huawei Corporation. [ 1.465047] e1000: Intel(R) PRO/1000 Network Driver [ 1.470243] e1000: Copyright (c) 1999-2006 Intel Corporation. [ 1.476424] e1000e: Intel(R) PRO/1000 Network Driver [ 1.481710] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 1.488029] igb: Intel(R) Gigabit Ethernet Network Driver [ 1.493756] igb: Copyright (c) 2007-2014 Intel Corporation. [ 1.499697] igbvf: Intel(R) Gigabit Virtual Function Network Driver [ 1.506325] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [ 1.512801] sky2: driver version 1.30 [ 1.517367] VFIO - User Level meta-driver version: 0.3 [ 1.524155] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.531114] ehci-pci: EHCI PCI platform driver [ 1.535919] ehci-platform: EHCI generic platform driver [ 1.541542] ehci-orion: EHCI orion driver [ 1.545902] ehci-exynos: EHCI Exynos driver [ 1.550435] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.556998] ohci-pci: OHCI PCI platform driver [ 1.561801] ohci-platform: OHCI generic platform driver [ 1.567415] ohci-exynos: OHCI Exynos driver [ 1.572213] usbcore: registered new interface driver usb-storage [ 1.580207] i2c /dev entries driver [ 1.587651] sdhci: Secure Digital Host Controller Interface driver [ 1.594246] sdhci: Copyright(c) Pierre Ossman [ 1.599228] Synopsys Designware Multimedia Card Interface Driver [ 1.606125] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.612955] ledtrig-cpu: registered to indicate activity on CPUs [ 1.620526] usbcore: registered new interface driver usbhid [ 1.626435] usbhid: USB HID core driver [ 1.634165] NET: Registered protocol family 17 [ 1.639199] 9pnet: Installing 9P2000 support [ 1.643874] Key type dns_resolver registered [ 1.648725] registered taskstats version 1 [ 1.653117] Loading compiled-in X.509 certificates [ 1.659117] Btrfs loaded, crc32c=crc32c-generic, integrity-checker=on, zoned=no [ 1.667260] ALSA device list: [ 1.670540] No soundcards found. [ 1.674948] VFS: Cannot open root device "mmcblkp3" or unknown-block(0,0): error -6 [ 1.683078] Please append a correct "root=" boot option; here are the available partitions: [ 1.691888] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 1.700521] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0 #2 [ 1.706738] Hardware name: L4 VM (DT) [ 1.710614] Call trace: [ 1.713229] dump_backtrace+0x0/0x1b0 [ 1.717121] show_stack+0x1c/0x70 [ 1.720653] dump_stack+0xd0/0x12c [ 1.724272] panic+0x16c/0x334 [ 1.727531] mount_block_root+0x1bc/0x24c [ 1.731768] mount_root+0x104/0x138 [ 1.735469] prepare_namespace+0x134/0x174 [ 1.739793] kernel_init_freeable+0x260/0x2a4 [ 1.744398] kernel_init+0x18/0x124 [ 1.748108] ret_from_fork+0x10/0x30 [ 1.751908] Kernel Offset: disabled [ 1.755604] CPU features: 0x10000071,00000846 [ 1.760204] Memory Limit: none [ 1.763464] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- ------8<------------------------------------------------------------------------------------------------

2 2

l4re + l4linux on aarch64 - raspi4
by Matthieu Fatrez 12 Sep '21

12 Sep '21

Hello l4-hackers, I tried to use l4re hypervisor on raspberry pi 4. Prebuild image works but not for my needs. In fact, I want to use l4re running on raspberry pi 4 (aarch64) with 1 or more tasks (such hello, ...) and 1 linux 64 bits vm like debian, fedora or opensuse. When I try to compile : - x86_64 (native) : fiasco, l4re, l4linux no problem, - rpi3, 32bit (cross compile) : fiasco, l4re, l4linux no problem - rpi4 64bit (cross compile) : fiasco l4re OK but nothing for l4linux :-( In this last case, obj/l4linux directory is empty. Nothing created. Normal? Do you have some advices for me please? Thank you very much Matthieu.

2 3

Change in l4re_rm_attach behaviour?
by Paul Boddie 28 Aug '21

28 Aug '21

Hello, The long journey of developing components for L4Re continues - a story for another time, perhaps - and I have been testing code that works with the old Subversion-based L4Re distribution on the newer Git-based L4Re distribution. One thing that seems to be different between the old and the new is when a call like the following is performed: l4re_rm_attach(addr, size, L4RE_RM_SEARCH_ADDR, ds, offset, L4_PAGESHIFT); Apart from L4RE_RM_SEARCH_ADDR seemingly being replaced by a differently-named constant, L4RE_RM_F_SEARCH_ADDR, it appears that such a value for the flags is insufficient and that additional rights flags might be required. If I omit such rights flags, I get the L4_ENOENT error value, but this worked before. So, I think I may have misunderstood the behaviour of the function. Or are there now additional constraints imposed by the region manager that prevent any inappropriate accesses from bothering the dataspace? (My dataspace does test the flags on map requests against the rights supported by the dataspace itself.) Another difference that I see between the old and the new is in the flags used for map requests sent to dataspaces. In the old distribution, there were these definitions (in pkg/l4re-core/l4re_c/include/dataspace.h): L4RE_DS_MAP_FLAG_RO = 0, L4RE_DS_MAP_FLAG_RW = 1, It appears that map requests now use the following: L4RE_DS_F_R = L4_FPAGE_RO, L4RE_DS_F_W = L4_FPAGE_W, L4RE_DS_F_X = L4_FPAGE_X, L4RE_DS_F_RW = L4_FPAGE_RW, L4RE_DS_F_RX = L4_FPAGE_RX, L4RE_DS_F_RWX = L4_FPAGE_RWX, I think the actual values involved here are different, but I imagine that since everything should be manipulating values derived from these definitions (as opposed to maintaining separate definitions of the flags), no incompatibility would normally be observed. But the apparent lack of conservatism surprised me slightly. Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it! Paul

2 3

L4Re on Raspi 3
by Yanneck Geiger 21 Jun '21

21 Jun '21

Hello, unfortunately I can't get L4Re running on the Raspberry Pi 3 / 3+ using the provided Guider (https://l4re.org/rpi.html). I did the 64-Bit setup accordingly with the provided U-Boot and the ready-to-use images. U-Boot itself seems to work fine and I can set the IPs ... Unfortunately I don't know the address to load the .elf file so I'm using the following commands: "tftpboot bootstrap_hello_rpi3.elf" and "bootelf". After entering "bootelf" the output on serial spews garbage and after a few seconds the same garbage is "printed" in an interval of around 1 second. Am I doing anything wrong or am I missing something? Kind Regards Daniel

3 4

Resource sharing
by John Galt 04 Apr '21

04 Apr '21

Is it possible to share resources between two VMs running Linux? After defining the io_bus and the io configuration, just one VM is getting access to the resource while the other displays: ERROR: binding irq 34, result is -1 (operation not permitted) "VMM: FATAL: Device creation for virtual device failed". Terminate called after throwing an instance of 'N2L413Runtime_errorE' what: Operation not permitted: cannot bind to IRQ

2 1

Build tutorial for the Zynq Ultrascale+
by Jorge Miguel Perez Utrera 02 Apr '21

02 Apr '21

Hi, I am trying to build the first tutorial, but cross-compiling for the Zynq Ultrascale+. However, when I run "make E=hello qemu" I get the next output: Image size(s) in bytes: bootstrap_hello.elf: 1275456 Start address: 0x1000000 --> Build-Nr: 5 QEMU-cmd: qemu-system-aarch64 -kernel /home/jperezu/build-arm/images/bootstrap.elf -serial stdio -M xlnx-zcu102 -cpu cortex-a53 -m 1024 -display none L4 Bootstrapper Build: #5 Thu Apr 1 23:34:21 CEST 2021, 10.2.0 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (00000000 - 7fffffff) RAM: 0000000000000000 - 000000007fffffff: 2097152kB Total RAM: 2048MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 1100000 moving module 04 { 10ad000-10d99bf } -> { 1199000-11c59bf } [182720] moving module 03 { 108f000-10aca0f } -> { 117b000-1198a0f } [121360] moving module 02 { 105b000-108e54f } -> { 1147000-117a54f } [210256] moving module 01 { 1055000-105abef } -> { 1141000-1146bef } [23536] moving module 00 { 1014000-1054cef } -> { 1100000-1140cef } [265456] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 3000 Regions of list 'regions' [ 1000, 4afff] { 4a000} Kern fiasco [ 4b000, 4b0ef] { f0} Root mbi_rt [ 100000, 10a46f] { a470} Sigma0 sigma0 [ 140000, 170e43] { 30e44} Root moe [ 171e48, 17eed7] { d090} Root moe [ 1000000, 1012d63] { 12d64} Boot bootstrap [ 10131ef, 10135af] { 3c1} Boot modinfo [ 117b000, 11c59bf] { 4a9c0} Root Module found kernel options (via ELF) at 4000 Sigma0 config ip:00100474 sp:00000000 Roottask config ip:00141694 sp:00000000 Starting kernel fiasco at 000016b0 Hello from Startup::stage2 Number of IRQs available at this GIC: 192 Assertion failed at /home/jperezu/fiasco/src/kern/irq_mgr_multi_chip.cpp:67: mask Does anyone know what could be the problem? I am using CROSS_COMPILE:=aarch64-linux-gnu- to build and ARM64 architecture, ARMv8a CPU variant, Xilinx Zynq Ultrascale+, and CPU Arm Cortex-A53 in the configuration. Thank you for your help. Sincerely, Jorge

2 1

search CPP u-kernel, i knock in the good dors ?
by heitai 22 Mar '21

22 Mar '21

Hi, I search a CPP u-kernel, fiasco seems the best way but i see L4 not writting in CPP... dude, and the first code i was read isn't commented (kernel_console.cpp) may be i thinks my first stuff is comment fiasco... about kernel_console, why kconsole ? not native console writing ? may be i try to write on... i follow learn C++ programming by delanoy in french, may be take some time but kconsole seems thinks me to kde console, may be i missing. take care and best regard, heitai.

2 1

Invitation: Systems Software Innovations Summit 2021
by Martin Decky 17 Mar '21

17 Mar '21

Dear colleagues, I would like to cordially invite you to participate in Huawei Systems Software Innovations Summit 2021 on March 30th and 31st 2021. This is an on-line conference focused on research and practical aspects of operating systems, microkernel-based systems, formal verification and related topics. Notable speakers are Greg Kroah-Hartman (Linux Foundation), Timothy Roscoe (ETH Zurich), Hermann Härtig (TU Dresden), June Andronick (UNSW) and others. There is no fee for participation. Accessing the live on-line stream requires just a simple registration. More information at https://huawei-events.de/ We are looking forward to your participation! Best regards Martin Decky Principal Research Engineer Dresden Research Center Huawei Technologies

1 0

L4Re: region mapper/manager concurrency considerations and resource limits
by Paul Boddie 02 Mar '21

02 Mar '21

Hello, Apologies for introducing two potentially separate topics, but they both seem to present themselves in my most recent endeavour. In short, I am wondering about the following... What considerations need to be given to concurrency with regard to the use of the l4re_rm_attach function and similar functionality? Is access to the region mapper/manager from different threads in the same task advisable, are there thread safety issues, and if so, can these be sensibly worked around? (I have observed what seems to be the same address being provided for two different dataspaces at the same time, which does not appear to happen when I introduce locking around calls to l4re_rm_attach. Are such problems expected or could this be some other problem manifesting itself?) What kind of resource limits apply to L4Re tasks? In my work, I am allocating capabilities for objects acting as dataspaces. Things seem to work fairly well up to a certain point, and then capability allocation seems to fail, and program failure is then not particularly graceful. (I currently observe that creating 160 threads, each with its own IPC gate capability seems to be unproblematic, but more than this will produce errors that manifest themselves either in pthread library code or in my own code where a critical section is supposed to be enforced.) I suppose some contextual remarks might be useful. My previous work involved providing some simple filesystem-related functionality through filesystem servers, where a new server object (exposed via an IPC gate and having its own thread) is created for each open file. Some stress testing in a multiprocessor environment indicated that various concurrency issues were highly likely to be present. (I also probably didn't provide general enough support for flexpages, but since all my "send" flexpages were single machine pages, I don't think this would have caused additional problems or confusion.) Consequently, I migrated the principal mechanisms to my Linux environment and wrote a simulation to explore the concurrency situation, identifying and hopefully remedying various deficiencies (including more general flexpage support). This new endeavour involves bringing this tested functionality back into L4Re, wiring it up with the IPC system, and testing using multithreaded clients. I might also ask about support in L4Re for C++ threading constructs. When developing my simulation, I decided to use the standard C++ support for threading, mutexes, condition variables, and so on, as opposed to using pthread functionality. I imagine that C++ library support for these things just wraps the pthread functionality, but I wonder if there are not other considerations that I might need to be aware of. Sorry if this is in any way vague, but since there isn't really any discussion about system architecture or implementation on this list with respect to these technologies (or really any technologies), I find myself experimenting with the available software to determine techniques and approaches that I hope will be viable. Nevertheless, any constructive remarks or advice would be greatly appreciated. Thanks in advance, Paul

3 11

Boot problems with Fiasco.OC on the NanoPC-T3 Plus
by Andreas Resch 25 Jan '21

25 Jan '21

Hello everyone, as part of a practical course at my university my group has to bring Fiasco.OC and L4re to the NanoPC-T3 Plus which is powered by the S5P6818 from Samsung/Nexell. We’re currently stuck on multiple fronts, and as a sort of last resort I’m asking here for help, I hope you don’t mind. 1. Problem - The RAM We implemented a working uart driver for our board and when using all (seemingly) correct values for the RAM region (as stated in the TRM is located from 0x40000000 to 0xc0000000) our SBC only boots up to the message “Hello from Startup::stage2” and then hangs in the function Kmem_alloc::Kmem_alloc() , we believe because the value of Map_base is with 0xffff000040000000 far too big but haven’t found a way to fix this issue whilst keeping the correct RAM region. Does someone have an idea why setting the incorrect RAM region results in more progress in the boot process (as stated in the following paragraph)? 2. The Timer - or the lack thereof When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 we achieve slightly more output. Right up to ARM generic timer, which seems to not work on this particular board, we decided to implement our own timer driver, now we are stuck at Panic: Trace buffer size unaligned which, upon investigation, was an output from the JDB; by disabling the debugger we could again get more output, seen below. The clock doesn’t seem to start counting and I currently have no idea how to implement my own clock driver, I was hoping the generic clock would suffice. Bytes transferred = 1223880 (12acc8 hex) ## Booting kernel from Legacy Image at 40080000 ... Image Name: L4 Image #428 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1223816 Bytes = 1.2 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #428 Thu Jan 14 22:44:58 CET 2021, 7.5.0 RAM: 0000000040000000 - 00000000ffff0000: 3145664kB Total RAM: 3071MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 410dd000-4112ac87 } -> { 411cb000-41218c87 } [318600] moving module 01 { 410c4000-410dcea7 } -> { 411b2000-411caea7 } [102056] moving module 00 { 41077000-410c34cf } -> { 41165000-411b14cf } [312528] moving module 04 { 4103f000-41076bbf } -> { 4112d000-41164bbf } [228288] moving module 03 { 41012000-4103ee4f } -> { 41100000-4112ce4f } [183888] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40003000 Regions of list 'regions' [ 40000000, 400000ef] { f0} Root mbi_rt [ 40001000, 40058fff] { 58000} Kern fiasco [ 400f0000, 40108a5b] { 18a5c} Sigma0 sigma0 [ 40118a60, 4011c2ef] { 3890} Sigma0 sigma0 [ 40130000, 4017d4cf] { 4d4d0} Root moe [ 4018d4d0, 40198d67] { b898} Root moe [ 41000000, 41011193] { 11194} Boot bootstrap [ 41100000, 41164fff] { 65000} Root Module found kernel options (via ELF) at 40004000 Sigma0 config ip:401002bc sp:00000000 Roottask config ip:401413ec sp:00000000 Starting kernel fiasco at 40001818 Hello from Startup::stage2 Number of IRQs available at this GIC: 160 Detecting PSCI ... Detected PSCI v1.1 PSCI: CPU_SUSPEND format extended, supports OS-initiated mode PSCI: TOS: Not present or not required. SERIAL ESC: allocated IRQ 7 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: cffbd484-dirty compiled with gcc 7.5.0 for Samsung S5P6818 [] Build: #212 Thu Jan 14 22:44:36 CET 2021 Calibrating timer loop… If anyone could maybe guide me into the right direction I’d be more than happy! Thank you very much! Best regards Andreas

4 6

Fiasco.OC won't boot on Aaeon FWS2360 ...
by Andreas Steinmetzler 19 Dec '20

19 Dec '20

Hi, in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360 (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to start the different cores of the processor (I'm using the latest published l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build with this command make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64" The ISO image boots fine on another amd64 system. After adding some printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get stuck with this call: // Send IPI-Sequency to startup the APs Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page); as it does not return anymore ... any hint how to debug this or drill down to get more information and the AtomC3558 system to boot? Thanks Andreas L4 Bootstrapper Build: #2 Mon Dec 14 12:09:54 PST 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 00000000000997ff: 614kB RAM: 0000000000100000 - 000000003e2dffff: 1017728kB RAM: 000000003e300000 - 0000000078762fff: 954764kB RAM: 0000000078773000 - 000000007de44fff: 88904kB RAM: 000000007f34b000 - 000000007f7fffff: 4820kB RAM: 0000000100000000 - 000000087fffffff: 31457280kB Total RAM: 32738MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe --init=rom/hello need 272 bytes to copy MBI reserved 272 bytes at 0x2000 Moving up to 5 modules behind 1100000 moving module 00 { 1021000-1246617 } -> { 119b000-13c0617 } [2250264] moving module 04 { 170000-19b95f } -> { 116f000-119a95f } [178528] moving module 03 { 152000-16f72f } -> { 1151000-116e72f } [120624] moving module 02 { 10e000-15175f } -> { 110d000-115075f } [276320] moving module 01 { 101000-10d48f } -> { 1100000-110c48f } [50320] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 210f] { 110} Root mbi_rt [ 99800, 9ffff] { 6800} Arch BIOS [ e0000, fffff] { 20000} Arch BIOS [ 100000, 11247f] { 12480} Sigma0 sigma0 [ 140000, 18007f] { 40080} Root moe [ 182038, 1940e7] { 120b0} Root moe [ 2d0400, 2e1257] { 10e58} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 62efff] { 22f000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 1151000, 119afff] { 4a000} Root Module [ 3e2e0000, 3e2fffff] { 20000} Arch BIOS [ 78763000, 78772fff] { 10000} Arch BIOS [ 7de45000, 7df1cfff] { d8000} Arch BIOS [ 7df1d000, 7df99fff] { 7d000} Arch BIOS [ 7df9a000, 7e3aafff] { 411000} Arch BIOS [ 7e3ab000, 7f34afff] { fa0000} Arch BIOS [ 7f800000, 7fffffff] { 800000} Arch BIOS [ e0000000, efffffff] { 10000000} Arch BIOS [ fd000000, fe7fffff] { 1800000} Arch BIOS [ ff000000, ffffffff] { 1000000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001419ed sp:0000000000000000 Starting kernel fiasco at 0000000000300910 Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: unknown compiled with gcc 7.5.0 for x86-64 [] Build: #7 Mon Dec 14 11:40:53 PST 2020 Performance-critical config option(s) detected: CONFIG_NDEBUG is off Superpages: yes Kmem:: TSS mem at 8053f9000 (4096Bytes) VMX: enabled VMX: EPT supported VMX: initialized ACPI: RSDP[0xf05b0] r02 OEM:ALASKA FPU0: SSE ACPI: FACS phys=7e3a9080 virt=0x203a9080 ACPI: HW sig=cd SERIAL ESC: allocated IRQ 4 for serial uart VMX: init page sizes SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: GenuineIntel (6:5F:1:0)[000506f1] Model: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz at 2199MHz Freeing init code/data: 20480 bytes (5 pages) MP: detecting APs... After tramp_page

2 2

CfP: FOSDEM 2021 - Microkernel Devroom
by Martin Decky 08 Dec '20

08 Dec '20

Microkernel Devroom at FOSDEM 2021 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 operating systems will meet on-line as part of FOSDEM 2021 [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 6th 2021. 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 * used languages, tools and toolchains * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * development processes, debugging * maintenance, testing and release engineering * security and robustness * trends and challenges * community and governance * use cases, experiences and status updates * best practices, lessons learned and demos This is a call for your participation. We kindly ask you to submit your proposals no later than on December 26th 2020. Please use the Pentabarf website [2] to submit your proposals. If you already have a user account in Pentabarf, please do not create a new one. Please make sure to select the Microkernel 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), excluding a Q&A part * your short bio * your photo The talks will be pre-recorded in advance in January and streamed during the event. This means that you will need to complete and submit your talk by around mid January. However, each speaker should be also present on-line just after the streaming of the 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 2020 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 website. You are also invited to send any other suggestions for what you want to see or do at the devroom to the mailing list. About the Devroom Since the first Microkernel devroom at FOSDEM 2012 [4], this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based and unikernel-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there. To this date, over a dozen projects have participated in one way or another. Each 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 2021 Due to the extraordinary mode of organization of FOSDEM 2021 (being an on-line event for the first time), many practical aspects of the devroom are still in the process of determination. For example, the devroom talks will be required to be pre-recorded in January and streamed during the event (with a live Q&A), but the technical details are still sketchy at this moment. 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 our devroom regularly. We will keep updating it as new guidelines will be determined by the FOSDEM organizers. Sadly, it will not be possible to arrange our traditional microkernel dinner and other in-person social gatherings in Brussels this time. However, we plan to organize an on-line replacement. The details will be announced later in January. On the other hand, the on-line nature of the devroom allows us to "overflow" to a second day in case we receive a substatial number of quality proposals. About FOSDEM FOSDEM [6] is a two-day event organised by volunteers to promote the widespread use of free and open source software. FOSDEM is widely recognised 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, and in the past instances certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers at the ULB Solbosch campus. Due to the circumstances, FOSDEM 2021 will be organized as an on-line event. Despite this, the participation in FOSDEM is still totally free, although the organisers 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 * 2020-12-26: Deadline for talk proposal submission * 2020-12-31: Schedule published and speakers notified of acceptance * mid January 2021: Time frame for talk pre-recoding * 2021-02-06: Devroom taking place on-line Contact In case of any questions, comments 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 2021 are: * Martin Decky * Jakub Jermar Links [1] https://fosdem.org/2021/ [2] https://penta.fosdem.org/submission/FOSDEM21/ [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/2021/practical/conduct/

1 0

Raspberry Pi SD access
by Mohamed Nasr 07 Oct '20

07 Oct '20

Hi L4 Team, I am trying to access SD card of Raspberry Pi 4 But the IO fail with IO | new iomem region: p=0000007e000000 v=00000000400000 s=400000 (bmb=0x24370) IO | map mem: p=0000007e300000 v=00000000700000 s=1000: failed(-12) VMM: FATAL: Insufficient memory Can you help me on what I am missing? My configurations are: ----------- io.cfg ---------------------------------- local Res = Io.Res local Hw = Io.Hw local add_children = Io.Dt.add_children add_children(Io.system_bus(), function() mmc = Hw.Device(function() compatible = { "brcm,bcm2835-mmc" }; Resource.reg0 = Res.mmio(0x7e300000, 0x7e3000FF); Resource.irq0 = Res.irq(0x7e); Property.flags = Io.Hw_device_DF_dma_supported; end) end) -------- vm_hw.vbus --------------------------- Io.add_vbusses { vm_hw = Io.Vi.System_bus(function() MMC = wrap(Io.system_bus().mmc); end); } -------- rpi_mmc.ned ------------------------- local L4 = require("L4"); local l = L4.default_loader; vbus_l4linux = l:new_channel(); -- Start io & flash memory l:start({ caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0), icu = L4.Env.icu, vm_hw = vbus_l4linux:svr() }, log = {"IO", "y"} }, "rom/io rom/io.cfg rom/vm_hw.vbus -vvvvvv"); l:startv({ caps = { ram = L4.Env.user_factory:create(L4.Proto.Dataspace, 256 * 1024 * 1024, 7, 21):m("rws"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws") }, "rom/uvmm", "-v", "-krom/image.bin", "-rrom/ramdisk-arm64.rd", "-drom/virt-arm_virt-64-2.dtb", "-cconsole=hvc0 ramdisk_size=10000 root=/dev/ram0 rw"); --------------- modules.list --------------------- entry rpi-mmc kernel fiasco -serial_esc roottask moe rom/rpi-mmc.ned module uvmm module l4re module ned module virt-arm_virt-64-mod.dtb module ramdisk-arm64.rd module rpi-mmc.ned module image.bin module io module io.cfg module vm_hw.vbus ------------- I added mmc to device tree --------- mmc@7e300000 { compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci"; reg = <0x7e300000 0x100>; interrupts = <0x0 0x7e 0x4>; clocks = <0x3 0x1c>; dmas = <0xa 0xb>; dma-names = "rx-tx"; brcm,overclock-50 = <0x0>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <0x19>; bus-width = <0x4>; phandle = <0x2d>; }; -------------------------------------------------------------------- I tested Linux kernel with uvmm module and without IO module and it was working perfectly. I compiled it with the following options on: CONFIG_VIRTIO=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_BLK=y CONFIG_BLK_MQ_VIRTIO=y CONFIG_VIRTIO_CONSOLE=y CONFIG_VIRTIO_INPUT=y CONFIG_VIRTIO_NET=y --------------------------------------------------------------------- boot log messages are: L4 Bootstrapper Build: #104 Wed Oct 7 20:14:57 EET 2020, 7.5.0 Raspberry Pi Model 4B, Rev 1.1, 4096MB, SoC BCM2711 [c03111] Warranty intact, OTP reading allowed, OTP programming allowed, Overvoltage allowed RAM: 0000000000000000 - 000000003b3fffff: 970752kB RAM: 0000000040000000 - 00000000fbffffff: 3080192kB Total RAM: 3956MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 14 modules behind 1100000 moving module 13 { 2540000-25400bb } -> { 262c000-262c0bb } [188] moving module 12 { 253f000-253f555 } -> { 262b000-262b555 } [1366] moving module 11 { 230c000-253e187 } -> { 23f8000-262a187 } [2302344] moving module 10 { 15b3000-230b9ff } -> { 169f000-23f79ff } [13994496] moving module 09 { 15b2000-15b22ea } -> { 169e000-169e2ea } [747] moving module 08 { 1232000-15b1fff } -> { 131e000-169dfff } [3670016] moving module 07 { 1231000-123176c } -> { 131d000-131d76c } [1901] moving module 06 { 11be000-123041f } -> { 12aa000-131c41f } [468000] moving module 05 { 11a0000-11bd14f } -> { 128c000-12a914f } [119120] moving module 04 { 119f000-119fdbf } -> { 128b000-128bdbf } [3520] moving module 03 { 10eb000-119e957 } -> { 11d7000-128a957 } [735576] moving module 02 { 10ad000-10eaf0f } -> { 1199000-11d6f0f } [253712] moving module 01 { 10a3000-10ac947 } -> { 118f000-1198947 } [39240] moving module 00 { 1014000-10a24c7 } -> { 1100000-118e4c7 } [582856] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 3000 Regions of list 'regions' [ 0, fff] { 1000} Arch mpspin [ 1000, 9ffff] { 9f000} Kern fiasco [ a0000, a01ff] { 200} Root mbi_rt [ 100000, 10e46f] { e470} Sigma0 sigma0 [ 140000, 17d70f] { 3d710} Root moe [ 17e710, 189edf] { b7d0} Root moe [ 1000000, 10122b3] { 122b4} Boot bootstrap [ 1013210, 1013c1c] { a0d} Boot modinfo [ 11d7000, 262c0bb] { 14550bc} Root Module found kernel options (via ELF) at 4000 Sigma0 config ip:0010042c sp:00000000 Roottask config ip:00141594 sp:00000000 Starting kernel fiasco at 00001760 Hello from Startup::stage2 Number of IRQs available at this GIC: 256 FPU: Initialize ARM generic timer: freq=54000000 interval=54000 cnt=2085101974 SERIAL ESC: allocated IRQ 125 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 7.5.0 for RPi4 (Broadcom 2711) [] Build: #1 Mon Oct 5 13:54:22 EET 2020 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Cache config: ON Allocate ARM PPI 27 to virtual 1 Calibrating timer loop... Cache config: ON Allocate ARM PPI 25 to virtual 0 done. Allocate ARM PPI 27 to virtual 1 MDB: use page size: 30 Cache config: ON MDB: use page size: 21 ID_PFR[01]: 00002222 00000000MDB: use page size: 12 ID_[DA]FR0: 10305106 00000000 SIGMA0: Hello! ID_MMFR[04]: 00001124 00000000 00000000 00000000 KIP @ ID_PFR[01]: 00002222 000000003000 ID_[DA]FR0: 10305106 00000000 ID_MMFR[04]: 00001124 00000000 00000000 00000000 allocated ID_PFR[01]: 00002222 000000004 ID_[DA]FR0: 10305106 00000000 KBID_MMFR[04]: 00001124 00000000 00000000 00000000 for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:a0000;a0fff] [0:RWX:a1000;fffff] [0:RWX:10f000;13ffff] [4:R-X:140000;17dfff] [4:RW-:17e000;189fff] [0:RWX:18a000;11d6fff] [4:RWX:11d7000;262cfff] [0:RWX:262d000;3b3fffff] [0:RWX:40000000;faffffff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:3b400000;3fffffff] [0:RWX:fc000000;ffffffffffffffff] MOE: Hello world MOE: found 4012740 KByte free memory MOE: found RAM from a0000 to fb000000 MOE: allocated 4015 KByte for the page array @0x18a000 MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11d7000-128a958] [C:107000] uvmm BOOTFS: [128b000-128bdc0] [C:109000] vmm.lua BOOTFS: [128c000-12a9150] [C:10b000] l4re BOOTFS: [12aa000-131c420] [C:10d000] ned BOOTFS: [131d000-131d76d] [C:10f000] virt-arm_virt-64-2.dtb BOOTFS: [131e000-169e000] [C:111000] ramdisk-arm64.rd BOOTFS: [169e000-169e2eb] [C:113000] rpi-mmc3.ned BOOTFS: [169f000-23f7a00] [C:115000] image.bin BOOTFS: [23f8000-262a188] [C:117000] io BOOTFS: [262b000-262b556] [C:119000] io.cfg BOOTFS: [262c000-262c0bc] [C:11b000] vm_hw.vbus MOE: cmdline: moe rom/rpi-mmc3.ned MOE: Starting: rom/ned rom/rpi-mmc3.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/rpi-mmc3.ned' IO | Io service IO | Verboseness level: 7 IO | unused physical memory space: IO | [0000003b400000-0000003fffffff] IO | [000000fc000000-ffffffffffffffff] IO | no 'iommu' capability found, using CPU-phys for DMA VMM[]: Created VCPU 0 @ 16000 IO | Loading: config 'rom/io.cfg' IO | Loading: config 'rom/vm_hw.vbus' IO | Add IRQ resources to vbus: IRQ [0000000000007e-0000000000007e 1] none (align=0 flags=1) IO | vm_hw: [N12_GLOBAL__N_112Virtual_sbusE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | L4ICU: [N2Vi6Sw_icuE] IO | Resources: ==== start ==== IO | Resources: ===== end ===== IO | MMC: [N2Vi9Proxy_devE] IO | Resources: ==== start ==== IO | IRQ [0000000000007e-0000000000007e 1] none (align=0 flags=1) IO | IOMEM [0000007e300000-0000007e3000ff 100] 32-bit non-pref (align=ff flags=2) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | Real Hardware ----------------------------------- IO | System Bus: IO | Resources: ==== start ==== IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | mmc: IO | compatible= { "brcm,bcm2835-mmc" } IO | Clients: ===== start ==== IO | MMC: [N2Vi9Proxy_devE] IO | Clients: ===== end ==== IO | Resources: ==== start ==== IO | IRQ [0000000000007e-0000000000007e 1] none (align=0 flags=1) IO | IOMEM [0000007e300000-0000007e3000ff 100] 32-bit non-pref (align=ff flags=2) IO | DMADOM [00000000000000-00000000000000 1] (align=0 flags=6) IO | Resources: ===== end ===== IO | warning: could not register control interface at cap 'platform_ctl' IO | Ready. Waiting for request. VMM[GIC]: create ARM GICv2 VMM[main]: Hello out there. VMM[ram]: RAM: @ 0x2800000 size=0x10000000 (ci) VMM[ram]: RAM: VMM mapping @ 0x1200000 size=0x10000000 VMM[ram]: RAM: VM offset=0xfffffffffea00000 VMM[main]: Loading kernel... VMM[file]: load: @ 0x2880000 VMM[file]: copy in: to offset 0x80000-0xdd8a00 VMM[]: Create virtual console VMM[guest]: New mmio mapping: @ f1040000 10000 VMM[GIC]: GICC virtualization only supports sizes up to 0x1000, adjusting device tree node VMM[GIC]: GIC interrupt-controller.reg update: Adjusting GICC size from 20000 to 1000 VMM[guest]: New mmio mapping: @ f1060000 1000 VMM[guest]: New mmio mapping: @ f1120000 100 VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM[Timer]: Guest timer frequency is 54000000 using (1/54), (9942053/29) to calculate timeouts VMM[psci]: Register PSCI device: hvc mode VMM[ioproxy]: Registering IRQ resource MMC.irq0 : 0x7e VMM[ioproxy]: Adding MMIO resource MMC.reg0 : [0x7e300000 - 0x7e3000ff] IO | new iomem region: p=0000007e000000 v=00000000400000 s=400000 (bmb=0x24370) IO | map mem: p=0000007e300000 v=00000000700000 s=1000: failed(-12) VMM: FATAL: Insufficient memory Best Regards, Nasr -- *Driving Innovation! Visit our website www.avelabs.com <http://www.avelabs.com/>*, to read Avelabs Confidentiality Notice, follow this link: http://www.avelabs.com/email/disclaimer.html <http://www.avelabs.com/email/disclaimer.html>

2 1

L4Linux with hardware access on amd64 PC ...
by Andreas Steinmetzler 31 Aug '20

31 Aug '20

Hi, I'm experimenting with the TuD Snapshot release 2020.07.1 and can compile and run Fiasco, L4re and L4Linux in their basic configurations (amd64 architecture) using the default l4lx.cfg file of the distribution. As this is not all that useful, I was looking in getting the system use the available hardware. Based on snippets I found on the internet and the example config files, I created the following cfg and devs files, but now L4Linux immediately runs into an unhandled exception (full boot log at the end of this eMail). Was wondering if someone from the mailing list can share a set of config files which would allow to get L4Linux up and using at least some of the basic hardware like network and disks on a typical PC board. In my current experiments I'm using the following config files (see below). Any help or pointers are appreciated! Andreas File x86-legacy.devs is unchanged from ~l4/pkg/io/io/config. =============l4lx.cfg================== local L4 = require("L4"); loader = L4.default_loader; vbus_l4linux = loader:new_channel(); vbus_input = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; l4linux = vbus_l4linux:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/x86-legacy.devs rom/l4lx-x86.io"); loader:start( { caps = { vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), }, "rom/vmlinuz mem=1024M console=ttyLv0 earlyprintk=1 l4x_rd=rom/ramdisk-amd64.rd root=1:0 ramdisk_size=4000"); ==================================== =============l4lx-x86.io================== local hw = Io.system_bus() Io.add_vbusses { input = Io.Vi.System_bus { ps2dev = wrap(hw:match("PNP0[3F]??")); }; fbdrv = Io.Vi.System_bus { PCI0 = Io.Vi.PCI_bus_ident { dummy = Io.Vi.PCI_dummy_device(); pci_gfx = wrap(hw:match("PCI/display")); }; x1 = wrap(hw:match("BIOS")); x2 = wrap(hw:match("PNP0900")); x3 = wrap(hw:match("PNP0100")); }; l4linux = Io.Vi.System_bus { -- Add a new virtual PCI root bridge PCI0 = Io.Vi.PCI_bus { pci_l4x = wrap(hw:match("PCI/network", "PCI/storage", "PCI/media")); }; }; } ========================================== GRUB Loading /bootstrap /bootstrap -modaddr 0x01100000 Loading /fiasco fiasco -serial_esc Loading /sigma0 sigma0 Loading /moe moe rom/l4lx.cfg goading /l4lx.cfg l4lx.cfg Loading /l4re l4re Loading /io io Loading /ned ned Loading /x86-legacy.devs x86-legacy.devs Loading /l4lx-x86.io l4lx-x86.io Loading /vmlinuz vmlinuz Loading /ramdisk-amd64.rd ramdisk-amd64.rd Done, booting... error: Can't get controller info. L4 Bootstrapper Build: #1 Mon Aug 17 10:28:54 PDT 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 000000000009fbff: 639kB RAM: 0000000000100000 - 00000000cfe87fff: 3405344kB RAM: 0000000100000000 - 000000012effffff: 770048kB Total RAM: 4078MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/l4lx.cfg need 456 bytes to copy MBI reserved 456 bytes at 0x2000 Moving up to 11 modules behind 1100000 moving module 10 { 2443000-2742fff } -> { 260c000-290bfff } [3145728] moving module 09 { 1521000-2442faf } -> { 16ea000-260bfaf } [15867824] moving module 05 { 124a000-1520ea7 } -> { 1413000-16e9ea7 } [2977448] moving module 00 { 1021000-124954f } -> { 11ea000-141254f } [2262352] moving module 08 { 1ea000-1ea25e } -> { 11e9000-11e925e } [607] moving module 07 { 1e9000-1e9337 } -> { 11e8000-11e8337 } [824] moving module 06 { 170000-1e89ef } -> { 116f000-11e79ef } [494064] moving module 04 { 152000-16f72f } -> { 1151000-116e72f } [120624] moving module 03 { 151000-15133d } -> { 1150000-115033d } [830] moving module 02 { 10e000-15075f } -> { 110d000-114f75f } [272224] moving module 01 { 101000-10d48f } -> { 1100000-110c48f } [50320] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 21c7] { 1c8} Root mbi_rt [ 9fc00, 9ffff] { 400} Arch BIOS [ f0000, fffff] { 10000} Arch BIOS [ 100000, 1122ff] { 12300} Sigma0 sigma0 [ 140000, 17fb0b] { 3fb0c} Root moe [ 181030, 192f67] { 11f38} Root moe [ 2d0400, 2e10d7] { 10cd8} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 4010ab] { 10ac} Kern fiasco [ 600000, 83bfff] { 23c000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 1150000, 11e9fff] { 9a000} Root Module [ 1413000, 290bfff] { 14f9000} Root Module [ cfe88000, cfffffff] { 178000} Arch BIOS [ f8000000, fbffffff] { 4000000} Arch BIOS [ fed40000, fed44fff] { 5000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001418dd sp:0000000000000000 Starting kernel fiasco at 0000000000300910 Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: unknown compiled with gcc 7.5.0 for x86-64 [] Build: #2 Mon Aug 17 16:30:24 PDT 2020 Performance-critical config option(s) detected: CONFIG_NDEBUG is off Superpages: yes ACPI: RSDP[0xf3af0] r02 OEM:COREv4 FPU0: SSE AVX ACPI: FACS phys=cfe9d240 virt=0x2009d240 ACPI: HW sig=0 SERIAL ESC: allocated IRQ 4 for serial uart Enable MSI support: chained IRQ mgr @ 0xffffffff10156d20 SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: AuthenticAMD (16:30:1:0)[00730f01] Model: AMD GX-412TC SOC at 998MHz 32/512 Entry I TLB (4K pages) 8 Entry I TLB (4M pages) 40/512 Entry D TLB (4K pages) 8/256 Entry D TLB (4M pages) 32 KB L1 I Cache (2-way associative, 64 bytes per line) 32 KB L1 D Cache (8-way associative, 64 bytes per line) 2048 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 4096 bytes (1 pages) SVM: enabled SVM: nested paging supported SVM: NASID: 8. MP: detecting APs... Calibrating timer loop... SVM: enabled SVM: enabled SVM: enabled done. SVM: nested paging supported SVM: nested paging supported MDB: use page size: 30 SVM: NASID: 8. SVM: nested paging supported SVM: NASID: 8. SVM: NASID: 8. MDB: use page size: 21 MDB: use page size: 12 SIGMA0: Hello! KIP @ 400000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:2000;2fff] [0:RWX:3000;9efff] [0:RWX:113000;13ffff] [4:R-X:140000;17ffff] [0:RWX:180000;180fff] [4:RW-:181000;192fff] [0:RWX:193000;3fffff] [0:RWX:402000;5fffff] [0:RWX:83c000;114ffff] [4:RWX:1150000;11e9fff] [0:RWX:11ea000;1412fff] [4:RWX:1413000;290bfff] [0:RWX:290c000;cfe87fff] [0:RWX:100000000;11fb4efff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:9f000;fffff] [0:RW-:cfe88000;febfffff] [0:RW-:fec01000;fec1ffff] [0:RWX:fec21000;fedfffff] [0:RWX:fee01000;ffffffff] [0:RWX:12f000000;ffffffffffffffff] IO PORTS-------------------------- [0:RW-:0;fffffff] MOE: Hello world MOE: found 3900664 KByte free memory MOE: found RAM from 2000 to 11fb4f000 MOE: allocated 4603 KByte for the page array @0x83c000 MOE: virtual user address space [0-7fffffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [1150000-115033e] [C:107000] l4lx.cfg BOOTFS: [1151000-116e730] [C:109000] l4re BOOTFS: [1413000-16e9ea8] [C:10b000] io BOOTFS: [116f000-11e79f0] [C:10d000] ned BOOTFS: [11e8000-11e8338] [C:10f000] x86-legacy.devs BOOTFS: [11e9000-11e925f] [C:111000] l4lx-x86.io BOOTFS: [16ea000-260bfb0] [C:113000] vmlinuz BOOTFS: [260c000-290c000] [C:115000] ramdisk-amd64.rd MOE: cmdline: moe rom/l4lx.cfg MOE: Starting: rom/ned rom/l4lx.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx.cfg' IO | Io service IO | Find root Pointer IO | Found root Pointer: f3af0 IO | ACPI: RSDP 0x00000000000F3AF0 000024 (v02 COREv4) IO | ACPI: XSDT 0x00000000CFE9D0E0 00007C (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: FACP 0x00000000CFE9EE40 000114 (v06 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: DSDT 0x00000000CFE9D280 001BB3 (v02 COREv4 COREBOOT 00010001 INTL 20180531) IO | ACPI: FACS 0x00000000CFE9D240 000040 IO | ACPI: SSDT 0x00000000CFE9EF60 0001F8 (v02 COREv4 COREBOOT 0000002A CORE 20180531) IO | ACPI: MCFG 0x00000000CFE9F160 00003C (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: TPM2 0x00000000CFE9F1A0 00004C (v04 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: APIC 0x00000000CFE9F1F0 00007E (v03 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: HEST 0x00000000CFE9F270 0001D0 (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: IVRS 0x00000000CFE9F440 0000E0 (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: SSDT 0x00000000CFE9F520 0048A6 (v02 AMD AGESA 00000002 MSFT 04000000) IO | ACPI: SSDT 0x00000000CFEA3DD0 0007C8 (v01 AMD AGESA 00000001 AMD 00000001) IO | ACPI: DRTM 0x00000000CFEA45A0 00007C (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | ACPI: HPET 0x00000000CFEA4620 000038 (v01 COREv4 COREBOOT 00000000 CORE 20180531) IO | IO | ACPI table initialization: IO | Table [DSDT: COREBOOT] (id 01) - 379 Objects with 45 Devices, 15 Regions, 80 Methods (20/60/19 Serial/Non/Cvt) IO | Table [SSDT: COREBOOT] (id 02) - 14 Objects with 2 Devices, 0 Regions, 3 Methods (1/2/0 Serial/Non/Cvt) IO | Table [SSDT: AGESA ] (id 03) - 411 Objects with 6 Devices, 18 Regions, 143 Methods (25/118/14 Serial/Non/Cvt) IO | Table [SSDT: AGESA ] (id 04) - 28 Objects with 0 Devices, 0 Regions, 4 Methods (0/4/0 Serial/Non/Cvt) IO | ACPI: 4 ACPI AML tables successfully acquired and loaded IO | Final data object initialization: Namespace contains 841 (0x349) objects IO | evxfevnt-0204 Enable : System is already in ACPI mode IO | Initializing General Purpose Events (GPEs): IO | Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI) IO | Initializing Device/Processor/Thermal objects and executing _INI/_STA methods: IO | Executed 7 _INI methods requiring 1 _STA executions (examined 64 objects) IO | ACPICA-Version:20190816, System in ACPI MODE, 24bit timer IO | ACPI: Enabled 7 GPEs in block 00 to 1F IO | Ready. Waiting for request. PH 0 offs=0000000000200000 flags=r-x PH-type=0x1 virt=0000000000200000 evirt=0000000000b08f78 phys=0000000000200000 ephys=0000000000b08f78 f_sz=0000000000908f78 memsz=0000000000908f78 PH 1 offs=0000000000c00000 flags=rw- PH-type=0x1 virt=0000000000c00000 evirt=0000000000e15000 phys=0000000000c00000 ephys=0000000000e15000 f_sz=0000000000215000 memsz=0000000000215000 PH 2 offs=0000000000e15000 flags=rwx PH-type=0x1 virt=0000000000e15000 evirt=0000000001016000 phys=0000000000e15000 ephys=0000000001016000 f_sz=0000000000081000 memsz=0000000000201000 PH 3 offs=0000000000b08f3c flags=--- PH-type=0x4 virt=0000000000b08f3c evirt=0000000000b08f78 phys=0000000000b08f3c ephys=0000000000b08f78 f_sz=000000000000003c memsz=000000000000003c Starting binary at 0x200000, argc=7 argv=0xafff5f18 *argv=0x7100fff4 argv0=rom/vmlinuz External resolver is at 0x68000d30 ======> L4Linux starting... <======== Linux version 5.7.0-l4 (andreas@deepl) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04), GNU ld (GNU Binutils for Ubuntu) 2.30) #3 Mon Aug0 Binary name: rom/vmlinuz Linux kernel command line (6 args): mem=1024M console=ttyLv0 earlyprintk=1 l4x_rd=rom/ramdisk-amd64.rd root=1:0 ramdisk_size=4000 CPU mapping (l:p)[1]: 0:0 Image: 00200000 - 01016000 [14424 KiB]. Areas: Text: 00200000 - 008006f1 [6145kB] --------------------------------------------------------------------- CPU 0 [fffffffff021e0ba]: IRQ ENTRY CPU(s) 0-3 entered JDB jdb: z RO-Data: 00a00000 - 00b09000 [1060kB] Data: 00c00000 - 00c95b80 [598kB] Init: 00e15000 - 00e95000 [512kB] BSS: 00e98000 - 01000000 [1440kB] Device scan: Device: L4ICU Device: PCI0 Device: pci_l4x[1] L4Re: rom/vmlinuz: Unhandled exception: PC=0x68008698 PFA=0x0 LdrFlgs=0x0

3 5

L4Re: Identifying the source location of a program exception
by Paul Boddie 01 Aug '20

01 Aug '20

Hello, Returning to L4Re investigations with newer hardware (hosting qemu on the amd64 architecture), I have been trying to debug some of my hastily written code that undoubtedly has a race condition lurking in it. Unfortunately, I cannot remember the way of discovering how to identify the source instruction responsible (if I ever really knew it to begin with). I get an error like this: L4Re[rm]: unhandled read page fault at 0x38 pc=0x3a8bd9 Previous experiences suggested that I might not get much sense out of the program counter value, and it was also suggested to me that I might try and use the kernel debugger to show the thread execution state. I dug up instructions to achieve this... 1. Modify pkg/l4re-core/l4re/util/include/region_mapping_svr_2 and pkg/l4re-core/l4re_kernel/server/src/region.cc to employ enter_kdebug invocations. 2. Add jdb = L4.Env.jdb in the capabilities section of the start or startv invocation that invokes the task in the appropriate .cfg file. 3. Run the system and wait for an exception to trigger the debugger. 4. Use the t<enter> command sequence to see the thread state. 5. Use <space> to enter the disassembly and see the supposedly problematic instruction. Unfortunately, this seems to add confusion. Firstly, I end up with a different location: ffffffff10455e98. Even if I assume that the actual location is 455e98, being somewhat near to the usual payload base address of 400000, it doesn't help me identify what the code is that resides there. Normally, I would attempt to use addr2line, nm or objdump to provide some kind of map, but I cannot see any correspondence between their output and these values. I also considered, since my code is dynamically linked, that I might need to get the linker to tell me a bit more about where it is positioning library code in memory. This was suggested in another context a couple of years ago: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008274.html However, the only vaguely pertinent output I can find is this: _dl_protect_relro:124: RELRO protecting rom/libuc_c.so: start:0x3a6000, end:0x3a7000 _dl_protect_relro:124: RELRO protecting rom/libdl.so: start:0x3bf000, end:0x3c0000 If the 3a8bd9 value is meaningful, it evidently refers to something between these two regions, if these regions are valid. I thought that there was a more coherent summary of loaded objects, but I cannot find any details of that now. I imagine that there must be a simpler way of getting back to the source from exception addresses and would greatly appreciate being told (or reminded) what that is! Thanks in advance, Paul

3 4

uvmm support for AMD-V
by Andreas Steinmetzler 16 Jul '20

16 Jul '20

Hi, I followed the tutorials on github to get a basic L4re environment compiled and running (Hello World) on a embedded x86 board (more specifically APU2 https://www.pcengines.ch/apu2.htm). Everything worked fine - really nice tutorial. Next, I was using the single Linux VM guide to move on getting to more interesting stuff and uvmm stopped with the following error message "VMM: FATAL: Unsupported HW virtualization type.: Invalid request" While reading more of the documentation I looks to me that uvmm is not supporting AMD-V (last sentence in https://github.com/kernkonzept/uvmm/blob/master/doc/uvmm.dox). Wondering if there is a fundamental shortcoming of the AMD-V extensions or is it just missing because nobody worked on it? Thanks Andreas SeaBIOS (version rel-1.12.1.3-0-g300e8b7) Press F10 key now for boot menu Booting from Hard Disk... GRUB Loading /bootstrap /bootstrap -modaddr 0x01100000 Loading /fiasco fiasco -serial_esc Loading /sigma0 sigma0 Loading /moe moe rom/uvmm-basic.ned Loading /uvmm uvmm Loading /l4re l4re Loading /ned ned Loading /virt-pc.dtb virt-pc.dtb Loading /ramdisk-amd64.cpio.gz ramdisk-amd64.cpio.gz Loading /uvmm-basic.ned uvmm-basic.ned Loading /bzImage bzImage Done, booting... error: Can't get controller info. L4 Bootstrapper Build: #1 Tue Jul 14 23:45:16 CEST 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 000000000009fbff: 639kB RAM: 0000000000100000 - 00000000dfe88fff: 3667492kB RAM: 0000000100000000 - 000000011effffff: 507904kB Total RAM: 4078MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe rom/uvmm-basic.ned need 424 bytes to copy MBI reserved 424 bytes at 0x2000 Moving up to 10 modules behind 1100000 moving module 09 { 1319000-1b4f02f } -> { 15c7000-1dfd02f } [8609840] moving module 07 { 109a000-13181ff } -> { 1348000-15c61ff } [2613760] moving module 05 { 1021000-10999ef } -> { 12cf000-13479ef } [494064] moving module 08 { 2cf000-2cf23a } -> { 12ce000-12ce23a } [571] moving module 06 { 2ce000-2ce732 } -> { 12cd000-12cd732 } [1843] moving module 04 { 2b0000-2cd72f } -> { 12af000-12cc72f } [120624] moving module 03 { 1d7000-2afb1f } -> { 11d6000-12aeb1f } [887584] moving module 02 { 194000-1d675f } -> { 1193000-11d575f } [272224] moving module 01 { 187000-19348f } -> { 1186000-119248f } [50320] moving module 00 { 101000-186b97 } -> { 1100000-1185b97 } [547736] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 21a7] { 1a8} Root mbi_rt [ 9fc00, 9ffff] { 400} Arch BIOS [ f0000, fffff] { 10000} Arch BIOS [ 100000, 11247f] { 12480} Sigma0 sigma0 [ 140000, 17f9eb] { 3f9ec} Root moe [ 181030, 1930e7] { 120b8} Root moe [ 2d0400, 2e1257] { 10e58} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 488fff] { 89000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 11d6000, 1dfd02f] { c27030} Root Module [ dfe89000, dfffffff] { 177000} Arch BIOS [ f8000000, fbffffff] { 4000000} Arch BIOS [ fed40000, fed44fff] { 5000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001418dd sp:0000000000000000 Starting kernel fiasco at 0000000000300910 Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: 69396db compiled with gcc 7.5.0 for x86-64 [] Build: #1 Wed Jul 15 00:09:32 CEST 2020 Performance-critical config option(s) detected: CONFIG_NDEBUG is off CONFIG_FINE_GRAINED_CPUTIME is on Superpages: yes Kmem:: TSS mem at 10fb5e000 (4096Bytes) ACPI: RSDP[0xf3af0] r02 OEM:COREv4 FPU0: SSE AVX ACPI: FACS phys=dfe9d240 virt=0x2009d240 ACPI: HW sig=0 Enable MSI support: chained IRQ mgr @ 0xffffffff10156d10 SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: AuthenticAMD (16:30:1:0)[00730f01] Model: AMD GX-412TC SOC at 998MHz 32/512 Entry I TLB (4K pages) 8 Entry I TLB (4M pages) 40/512 Entry D TLB (4K pages) 8/256 Entry D TLB (4M pages) 32 KB L1 I Cache (2-way associative, 64 bytes per line) 32 KB L1 D Cache (8-way associative, 64 bytes per line) 2048 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 16384 bytes (4 pages) SVM: enabled SVM: nested paging supported SVM: NASID: 8. MP: detecting APs... Calibrating timer loop... SVM: enabled SVM: enabled SVM: nested paging supported done. SVM: NASID: 8. SVM: enabled SVM: nested paging supported SVM: nested paging supported SVM: NASID: 8. SVM: NASID: 8. MDB: use page size: 30 MDB: use page size: 21 MDB: use page size: 12 SIGMA0: Hello! KIP @ 400000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:RWX:2000;2fff] [0:RWX:3000;9efff] [0:RWX:113000;13ffff] [4:R-X:140000;17ffff] [0:RWX:180000;180fff] [4:RW-:181000;193fff] [0:RWX:194000;3fffff] [0:RWX:485000;11d5fff] [4:RWX:11d6000;1dfdfff] [0:RWX:1dfe000;dfe88fff] [0:RWX:100000000;10fb4efff] IOMEM:---------------------- [0:RW-:0;fff] [0:RW-:9f000;fffff] [0:RW-:dfe89000;febfffff] [0:RW-:fec01000;fec1ffff] [0:RWX:fec21000;fedfffff] [0:RWX:fee01000;ffffffff] [0:RWX:11f000000;ffffffffffffffff] IO PORTS-------------------------- [0:RW-:0;fffffff] MOE: Hello world MOE: found 3912072 KByte free memory MOE: found RAM from 2000 to 10fb4f000 MOE: allocated 4347 KByte for the page array @0x485000 MOE: virtual user address space [0-7fffffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11d6000-12aeb20] [C:107000] uvmm BOOTFS: [12af000-12cc730] [C:109000] l4re BOOTFS: [12cf000-13479f0] [C:10b000] ned BOOTFS: [12cd000-12cd733] [C:10d000] virt-pc.dtb BOOTFS: [1348000-15c6200] [C:10f000] ramdisk-amd64.cpio.gz BOOTFS: [12ce000-12ce23b] [C:111000] uvmm-basic.ned BOOTFS: [15c7000-1dfd030] [C:113000] bzImage MOE: cmdline: moe rom/uvmm-basic.ned MOE: Starting: rom/ned rom/uvmm-basic.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm-basic.ned' VMM: FATAL: Unsupported HW virtualization type.: Invalid request

2 1

Access to Arm Trusted Firmware
by Stefan Kalkowski 14 Jul '20

14 Jul '20

Dear l4-hackers, I've seen that Fiasco.OC provides support for the i.MX8 SoC universe. I'm curious about whether the kernel provides any means to access the ARM Trusted Firmware (ATF) in general? (especially regarding the vendor-specific calls for powering different peripheral domains). I've seen some kind of platform control privilege for cpu powering if I understood it correctly. Is there something more generic available? I'm asking, because right now I write a platform driver for Genode running on the i.MX 8M with focus on the base-hw kernel. But if there is a way I would like to support Fiasco.OC as well. Thank you in advance for any clearing up & best regards Stefan -- Stefan Kalkowski Genode labs https://github.com/skalk | https://genode.org

2 3

Question on availability of 'Live Hacking - HW Enforced Virtualization Of Linux Home Gateway'
by Andreas Steinmetzler 14 Jul '20

14 Jul '20

Hi, not sure if this is the right forum to ask, but I came across the following presentation given @embedded World 2018 https://bringyourownit.com/2018/03/20/hardware-enforced-virtualization-of-l… and was wondering if the full presentation and the "live hacking" steps are available somewhere as I'm interested in doing more experiments in this direction? Or maybe there is some other similar write-up available which is describing something similar? Any pointers are highly appreciated. Thanks Andreas BTW: I tried to search the mailing list archive, but unfortunately I'm getting a 403 permission error :(.

1 0

Problems Compiling L4RE with L4Linux
by Or Becker 29 Mar '20

29 Mar '20

Hi, I'm trying to compile L4RE with L4Linux and execute it with qemu. I followed the Github tutorial but the default Ned script didn't work (since I'm using the L4Linux I guess), so I used a different Ned script I found online (In the future I will have multiple VMs so I thought to do it in advanced). My Ned script is simple: package.path = "rom/?.lua"; local L4 = require "L4"; local vmm = require "vmm"; vmm.start_vm({ id = 1, mem = 128, mon = false, rd = "rom/ramdisk-armv8.cpio.gz", fdt = "rom/virt-arm_virt.dtb", bootargs = "console=hvc0 earlyprintk=1 rdinit=/bin/sh", kernel = "rom/Image.gz", log = L4.Env.log }); But when I try to execute "make E=uvmm1 qemu", an error occurred: Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Allocate ARM PPI 25 to virtual 0 Allocate ARM PPI 27 to virtual 1 Calibrating timer loop... done. MDB: use page size: 30 MDB: use page size: 21 MDB: use page size: 12 SIGMA0: Hello! KIP @ 40003000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:40000000;40000fff] [0:40054000;400effff] [0:40109000;40117fff] [0:4011d000;4012ffff] [4:40130000;4017afff] [0:4017b000;40189fff] [4:4018a000;40197fff] [0:40198000;410fffff] [4:41100000;4264bfff] [0:4264c000;7effffff] IOMEM:---------------------- [0:0;3fffffff] [0:80000000;ffffffffffffffff] MOE: Hello world MOE: found 1009576 KByte free memory MOE: found RAM from 40000000 to 7f000000 MOE: allocated 1008 KByte for the page array @0x40198000 MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [41100000-41197700] [C:107000] uvmm BOOTFS: [41198000-411c4e70] [C:109000] l4re BOOTFS: [411c5000-41246690] [C:10b000] ned BOOTFS: [41247000-412475ae] [C:10d000] virt-arm_virt.dtb BOOTFS: [41248000-41453600] [C:10f000] ramdisk-armv8.cpio.gz BOOTFS: [41454000-41454138] [C:111000] uvmm1.ned BOOTFS: [41455000-4264ba00] [C:113000] Image.gz MOE: cmdline: moe rom/uvmm1.ned MOE: Starting: rom/ned rom/uvmm1.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm1.ned' lua error: rom/uvmm1.ned:4: module 'vmm' not found: no field package.preload['vmm'] no file 'rom/vmm.lua' no file '/usr/local/lib/lua/5.3/vmm.so' no file '/usr/local/lib/lua/5.3/loadall.so' no file './vmm.so'. qemu-system-aarch64: terminating on signal 2 Makefile:6: recipe for target 'do-all-make-goals' failed make: *** [do-all-make-goals] Interrupt I tried to add more paths to the package.path but the error stays the same (even if uvmm.lua exists in the path) Can you please help me? Thank you, Or

3 3

L4Re with GCC 9; Repositories and Roadmaps
by Paul Boddie 06 Feb '20

06 Feb '20

Hello and Happy New Year! Having been otherwise occupied so far this year, I decided to take the opportunity to revisit my L4 development environment that happens to use Debian unstable. It turns out that GCC 9 is now the supported toolchain version, and unfortunately, L4Re doesn't yet understand this new version. So, first of all, I wondered whether support for that is imminent. I did take a look at persuading the build system to work, but this seems to involve hunting down version-specific resources and defining new ones for the new version. I stopped when encountering some libstdc++ headers and wondering whether this isn't documented somewhere. = Repositories = It did occur to me that I might also be expecting updates for such things from the wrong channel. Since I have been using L4Re for a while, I still use the Subversion repositories made available from svn.l4re.org, referenced by the documentation on l4re.org. It seems that these repositories are not updated as frequently as the GitHub repositories, but maybe they serve as a kind of staging area for more stable releases. After giving up on using GCC 9, I decided to re-clone repositories in a Debian stable environment. This didn't go very well with the Subversion repositories: after a while of saturating my aging machine's I/O bandwidth, cloning (or checking out) tended to fail. The repomgr script, if re-run, seems to just delete everything and start again, so after a few tries I gave up. Meanwhile, using the GitHub repositories failed for different reasons. Previously, I have tended to get "index pack" and "missing object" errors with Git when cloning. There don't seem to be any decent remedies for this, with people suggesting tweaking compression, network, memory and other settings, manually fiddling with the "object database" and other such nonsense. The consensus might be that I do not have a powerful enough machine (only 1GB RAM) to clone even modestly-sized Git repositories. Nevertheless, it would be nice to be able to download some kind of release distribution. I somehow doubt that the world really needs to accommodate all the multi-gigabyte Linux kernel clones out there that differ by a few files, either. If I really want to version my modifications against the released code, I can always version control them myself (even using a more coherent version control system if I want). = Roadmaps = Such considerations led me to also consider what I have been wanting to use L4Re for and the notion of a roadmap, both my own and that of L4Re itself. It seems to me that L4Re, or parts of it, can form the basis of a usable system in its own right (as opposed to just hosting L4Linux). However, I don't see much development directed towards such a goal. (Actually, I don't really see much L4Re development at all.) It seems to me, as I may have mentioned before, that one crucial area of development that would be needed for my purposes is that of providing general- purpose filesystem support. To do that, it seems that a few separate issues need attention, amongst them the component architecture required to export file entries and contents to programs, and support in the C library so that programs can access files transparently. Since L4Re's filesystem support seems to require linking filesystem-specific libraries against programs and having those programs access filesystem data directly, as far as I can tell, a new component architecture is required. Meanwhile, it seems to me that uClibc, at least in the version offered by L4Re, does not offer a particularly coherent or convenient basis for integrating with such a component architecture. Consequently, I spent a fair amount of time last year investigating filesystem component architectures and alternative C library implementations. But I wouldn't mind knowing whether there are plans to remedy these deficiencies in L4Re or whether I should just plug away at such things by myself. (I can live with people saying that they don't care about the things that I happen to care about. No-one needs to make excuses here: even the Hurd people seem pretty unmotivated about getting people on board, although it can be said that within certain parameters, they at least have a system that meets their objectives to some degree.) = Some Thoughts = It rather looks like the amount of time I have to spend on L4Re-related development will be significantly reduced for the foreseeable future. In some respects, I feel that I have learned quite a bit, but in other respects, I feel that it has been a frustrating exercise to try and get up to speed with L4Re development. (And I hardly want to get started on my Fiasco development experience.) Although literature obviously exists about various L4 implementations, I don't feel that the documentation experience is coherent at all. Many of the pertinent details are also obscured by the focus on code-originating reference documentation. And where microkernel-based systems should be emphasising the nature of the interfaces between components, there instead seems to be a policy of hiding such details in the implementation details of various abstractions (implemented multiple times in an almost archaelogical fashion). Indeed, this latter policy is quite infuriating because it binds the developer to existing functionality and frameworks unnecessarily. So, when developing my components for low-end devices, I went along with L4Re framework classes due to an incomplete understanding of the IPC mechanisms (which also brought other irritations because those classes assume a more complete understanding), but also because interfacing with other components is not obvious when the protocols are squirreled away across multiple header and implementation files. I have even gone as far as to write my own interface description language tool to permit the generation of IPC code and to help emphasise component interfaces and protocols. It seems to me that a lot of the point in having systems that facilitate component-oriented architectures is to make such details explicit, as was indeed emphasised by projects like Spring. Otherwise, everyone might as well be writing stuff for frameworks in the Linux kernel. Anyway, I am sure that there are plenty of people developing for and enhancing L4Re who are content with their situation and what they are able to achieve. But I personally feel that opportunities are being missed to apply these technologies to areas where they would make a real (and, crucially, positive) difference. If anyone else (still reading by this point) is even vaguely interested in general-purpose operating system development on L4Re, it would be nice to hear from you. Paul

4 11

Compatibility of microkernel systems with legacy OSes; was L4Re with GCC 9; Repositories and Roadmaps
by Andrew Warkentin 30 Jan '20

30 Jan '20

On 1/28/20, Martin Decky <martin.decky(a)huawei.com> wrote: > > FYI: The microkernel-based OS Huawei is working on internally has Linux > compatibility (both from the syscall API and from the drivers point of view) > as one of its goals. > Is it natively Unix-like, or is the Linux compatibility layer some kind of containerized "penalty box" that doesn't really integrate into the system? Also, since you're not developing it publicly , that may limit its ability to compete with Linux, which of course has a completely open development model without copyright assignment. In addition, from one article I read, it sounded like even though it is going to be open source eventually, it was designed with the assumption that it would be running on tivoized devices with locked bootloaders, with no way for the user to get full control. > > GNU Hurd obviously also tries to be GNU/Linux compatible (not on the syscall > level, but on the glibc level). Many other microkernel-based systems (e.g. > Genode, just to name one) maintain their own adaptation layers for hosting > Linux device drivers. > >From what I understand, Hurd doesn't implement a lot of Linux-kernel-specific APIs. On 1/28/20, Paul Boddie <paul(a)boddie.org.uk> wrote: > > I actually think that most people agree with you on this, at least when > confronted with the notion for the first time. But I don't think such > considerations should overrule every other consideration: it reminds me of > people in the English-speaking world (particularly in my country of origin) > > who say that if they could be bothered to learn a foreign language, it would > > be "something like Spanish that a lot of people speak", justifying the > choice > in terms of all the millions of individual speakers with whom they could be > > having hypothetical conversations that, naturally, they wouldn't end up > having > anyway. > For my purposes, I would much rather have an OS that runs Linux programs natively rather than having to port every single application I want to run. > > Your project being this one: > > https://gitlab.com/uxrt > > Is there a summary of it anywhere? > This is the closest thing to a summary that I have at the moment: https://gitlab.com/uxrt/uxrt-toplevel/blob/master/architecture_notes > > I wonder whether people don't already rely on things like L4Linux for such > functionality. However, I don't personally think that having boxed-up driver > > frameworks is particularly elegant or plays to the strengths of > microkernel- > based paradigms. In L4Re, I found myself staring down bits of imported Linux > > kernel code and wondering whether things might not have been easier - and > most > certainly clearer - had something been developed independently. > Yes, it's true that it's maybe not the most elegant way to run drivers, but I think it's a worthwhile trade-off for broad hardware support. As far as UX/RT is concerned it's not really that big a sacrifice because it will have relatively little vertical modularization anyway (e.g. instead of separate disk filesystem, partition driver, and disk device driver processes, all three will be incorporated into a single "disk server" process, much as on QNX; this should improve performance over most other microkernel OSes while not really sacrificing much as far as security or error recovery). > > Of course, the real solution is to have a library of functionality that a > variety of systems could use. Then, we wouldn't need to pick over the > remains > of some other project. Being familiar with this industry over a couple of > decades, however, I am fully aware that people exhibit rather strong > tendencies to insist that such cooperation is not possible, usually because > of > something super-special that they insist that only they are doing. > I'd be willing to cooperate on such libraries as long as they don't place unnecessary burdens on client code.

3 9

Hardware-aided Trusted Computing devroom at FOSDEM
by Vasily A. Sartakov 12 Dec '19

12 Dec '19

Hello I would like to invite your to participate in a new devroom: Hardware-aided Trusted Computing. The devroom is devoted to open source projects on top of modern TEEs like Intel SGX, AMD SEV/SVE, Arm TrustZone. You can find the schedule here: https://fosdem.org/2020/schedule/track/hardware_aided_trusted_computing/ I hope this will be interesting for the community. See you at FOSDEM. -- Dr.-Eng. V. A. Sartakov

1 0

Filesystem Architectures with L4Re and L4-Based Systems
by Paul Boddie 02 Dec '19

02 Dec '19

Hello, As this list can attest, I previously spent a bit of time diving into the way dynamic linking is supported by L4Re to get shared mode programs working. This turned out to have a relatively simple fix related to symbols employed by GCC- generated code. But during this exercise, I gained some familiarity with the way libraries are loaded, and this appears to involve the virtual filesystem support, with the loader perusing the filesystem to access libraries, and with these being provided as modules by the "rom" filesystem. Since then, I've spent some time looking at how files are provided by filesystems and accessed by code that uses the conventional C or POSIX library interfaces. It raises a few questions about why things are done in a particular way in L4Re, and which approaches are in use for other L4-based systems, especially those that seek to provide general-purpose, multi-user solutions. What I think I now understand about the virtual filesystem support in L4Re is as follows. The virtual filesystem itself is a "client-side" construct, meaning that it resides within any given program. That programs have their own view of a filesystem is not too different from what the documentation about systems like the Hurd describes and advocates, and I suppose it is a tempting approach because it gives each program the flexibility to be customised in this regard. However, it seems that beyond the internal "mount tree" representation, configuration of the namespace hierarchy is largely done using the L4Re namespace concept, with namespaces acting as directories, and non-namespace objects within the hierarchy interpreted as particular file types. Apart from the interpretation of namespaces as directories, it seems that for the most part, dataspaces are employed to be interpreted as file objects. I will admit that I didn't really look very hard at how different systems provide file access before now, but what surprised me slightly was the apparent lack of delegation in L4Re. As far as I can tell, on systems based on kernels like Linux, the open library function will employ a system call to delegate the matter of finding the file and obtaining a way of accessing it to the familiar monolithic-kernel-plus-filesystems arrangement. On more "exotic" systems (than Linux) like Minix 3 or the Hurd, it appears that delegation to a virtual filesystem server [1] or servers [2] occurs to mediate access to specific files. Some systems like Inferno and Plan 9 employ protocols [3] to formalise the client-server relationship. I had almost expected to find similar things in L4Re, but I could only confirm their absence after reviewing the various VFS abstractions. One thing I wonder about is whether the current L4Re approach is able to satisfactorily deal with filesystem content that needs to serve different user entities, with content having different permission and ownership rights. It seems that the filesystem logic has to be available as a library within a program, which is not necessarily a problem. But to avoid filesystem content being completely exposed to the discretion of user programs (reminiscent of the problems with early Network File System implementations), the library would need to call out to other entities, which doesn't appear to be done with the current L4Re abstractions. One could implement support for, say, the ext3 filesystem in a library, operating on a dataspace provided at some kind of mountpoint in a directory (with the directory being provided by a namespace, of course) but it would be like giving a user program access to a block device in a traditional Unix-like system. Are there any articles about the design of L4Re that might explain the motivations here? And are there any accessible-but-detailed articles about other microkernel-based systems and the way in which they structure their filesystem architectures? I looked around on the TU-Dresden site for materials, but I didn't immediately find anything obviously relevant. Paul [1] https://wiki.minix3.org/doku.php?id=developersguide:vfsinternals [2] https://www.gnu.org/software/hurd/hurd-talk.html#pat [3] http://doc.cat-v.org/inferno/4th_edition/styx

1 1

Alignment checking on ARM
by Al Grant 26 Nov '19

26 Nov '19

I'm building L4 on ARM using GCC 7.4.0 on Cortex-A15. ARCH-arm/head.cc enables alignment checking (sets SCTLR.A=1), but we then see an alignment check fault in init_kip_f.cc. With the default compiler options, the GCC cross tools will assume alignment checking is _not_ enabled and will generate code that may use unaligned access. We can override this by compiling with -mno-unaligned-access. But it would be good to know what is intended. If the intention is to be able to run "mainstream" open-source code in userspace, i.e. build code using the standard Linux ABI, we ought to allow that, and not enable alignment checks in SCTLR. Some code will not be fixed by compiling -mno-unaligned-access (because it casts arbitrary unaligned pointers to word-sized types etc.) So my question is, what is the intention? (1) fault unaligned access in kernel and userspace (2) fault unaligned access in kernel but allow in userspace (3) allow unaligned access in kernel and userspace I'm assuming it can't be (3) as the bootstrap code explicitly enables alignment checking. (2) would be a good compromise, it would enable alignment checks which would pick up some possible faults in the kernel, but it would improve portability of ordinary open-source packages in userspace. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 1

Kernel Helpers segmentation fault
by Sateesh K 14 Nov '19

14 Nov '19

Hi, My setup is as follows: l4linux 4.19.0-l4 Fiasco.OC Raspberry Pi 3 Model B I am running a helloworld.go program which is causing the following stack trace. (gdb) bt full #0 0xffff0f60 in ?? () No symbol table info available. #1 0x0001143c in kernelCAS64 () at /usr/local/go/src/sync/atomic/asm_linux_arm.s:112 No locals. #2 0x0001103c in sync/atomic.loadUint64 (addr=0x10442080, val=48) at /usr/local/go/src/sync/atomic/64bit_arm.go:10 No locals. #3 0x00071f44 in internal/poll.(*fdMutex).rwlock (mu=0x10442080, read=false, ~r1=160) at /usr/local/go/src/internal/poll/fd_mutex.go:130 mutexBit.lo = 4 mutexMask.hi = 2147481600 mutexMask.lo = 0 mutexSema = 0x1044208c mutexWait.hi = 2048 mutexWait.lo = 0 #4 0x00072314 in internal/poll.(*FD).writeLock (fd=0x10442080, ~r0=...) at /usr/local/go/src/internal/poll/fd_mutex.go:237 No locals. #5 0x00072a94 in internal/poll.(*FD).Write (fd=0x10442080, p=..., ~r1=0, ~r2=...) at /usr/local/go/src/internal/poll/fd_unix.go:243 n = -1212420096 nn = 118 --Type <RET> for more, q to quit, c to continue without paging--c #6 0x00073958 in os.(*File).write (b=..., err=..., f=0x1040c0f0, n=2729821 44) at /usr/local/go/src/os/file_unix.go:243 No locals. #7 0x00072ffc in os.(*File).Write (b=..., err=..., f=0x1040c0f0, n=0) at /usr/local/go/src/os/file.go:144 err.data = 0x12c0e8 <fmt.ppFree> "" err.itab = 0x8b7a8 <fmt.Fprintln+20> "\004" ~r2.data = 0x10456014 "" ~r2.itab = 0x0 #8 0x0008b7fc in fmt.Fprintln (a=..., err=..., n=233960, w=...) at /usr/local/go/src/fmt/print.go:255 p = 0x10456080 #9 0x0008b888 in fmt.Println (a=..., err=..., n=0) at /usr/local/go/src/fmt/print.go:264 No locals. #10 0x000916c0 in main.main () at /home/pi/hello.go:6 No locals. On further analysis, I find that segmentation fault is at __kuser_cmpxchg64. I have enabled CONFIG_KUSER_HELPERS=y when building the linux kernel. Any hint please on how to proceed. Best Regards, Sateesh Kalidas

3 3

http://os.inf.tu-dresden.de/pipermail/l4-hackers/2019/008421.html
by Sateesh K 04 Nov '19

04 Nov '19

Hi, I am trying to bring up Raspberry Pi 3 B peripherals (specifically SD card) onto the linux which is onto of Fiasco.OC. I have read the following thread which is close to what I am doing. http://os.inf.tu-dresden.de/pipermail/l4-hackers/2019/008421.html. I have a question, how to get a .dtb file. Please help. Best Regards, Sateesh Kalidas LinkedIn : http://linkedin.com/in/sateeshkalidas <https://www.linkedin.com/in/sateeshkalidas> Twitter: https://twitter.com/sats34

2 1

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

[Resent due to wrong Reply-To: header] FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium 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-, unikernel-, and component-based operating systems. Possible topics include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * used languages and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 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 website. You are invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there; to this date over a dozen projects have participated in one way or another. Each 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. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

CfP: FOSDEM 2020 - Microkernels and Component-based OS devroom
by Julian Stecklina 04 Oct '19

04 Oct '19

FOSDEM 2020 - Microkernels and Component-based OS devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2020 [1] in Brussels, Belgium 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-, unikernel-, and component-based operating systems. Possible topics include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * used languages and tools * enabling support for hardware (architectures, device drivers) * enabling support for programming languages * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos The deadline for your proposal is on December 1, 2019. Please use the Pentabarf [2] system to submit your proposals. You do not need to create a new account if you already have one. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December 15 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 website. You are invited to send any other suggestions for what you want to see or do at the devroom to the list. We will also use this list to organize the traditional devroom dinner that will happen on the first day of FOSDEM. About the devroom Since the first Microkernel devroom at FOSDEM 2012, this devroom has been part of each following FOSDEM. The focus gradually widened to include component-based operating systems. By now it has become a somewhat institutionalized tradition for the community to meet there; to this date over a dozen projects have participated in one way or another. Each 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. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2020 will not be any different, so there is going to be a dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. Important dates recap * 2019-12-01: Deadline for submissions * 2019-12-15: Schedule published and speakers notified of acceptance * 2020-02-01: Devroom Dinner (details to be announced) * 2020-02-01/2020-02-02: The devroom takes places (check the schedule) Links [1] https://fosdem.org/ [2] https://penta.fosdem.org/submission/FOSDEM20 [3] https://lists.fosdem.org/listinfo/microkernel-devroom

1 0

Fiasco.OC-UX on MIPS?
by Paul Boddie 30 Sep '19

30 Sep '19

Hello again, Having been using the MIPS-based CI20 single-board computer a bit more recently, I wondered if it might be possible to get the user mode Fiasco kernel working on MIPS. As I understand it, the UX variant of Fiasco only works on IA32 (x86, 32-bit), and although MIPS isn't particularly popular, it would at least be useful to me. However, having looked at the code, it seems like quite a bit of work to unpick the IA32-related aspects from the UX-specific code. There appears to be a fair amount of descriptor table usage, for instance, and despite reading the thesis about it [1], I don't feel I have a decent-enough overview of what would really need doing to port the UX variant to another architecture. So far, I've reviewed the MIPS code which employs a Proc abstraction and has a number of functions in the Mips namespace which could be replaced to maintain a "virtual" processor in the user mode kernel. It seems that the existing UX variant employs an Emulation abstraction for things like the processor status, and perhaps the Proc abstraction could take over these responsibilities. Quite how many privileged CPU registers would need maintaining probably depends on how much other code would still be using them. This brings me to an awkward difference between IA32 and MIPS: that of the page fault handling and memory management. MIPS has no inherent notion of page table structures that are held by the CPU and consulted by it when addressing errors occur. Instead, an exception handler is invoked to populate various privileged registers and to perform privileged instructions. However, it seems to me that Fiasco needs to maintain a page directory, anyway, and that the user mode kernel is not likely to be attempting the actual memory management operations, either. Consequently, it is tempting to think that the existing UX code might also be usable on MIPS. This would actually involve replacing a dedicated page directory implementation that appears to be present for MIPS with the one that other architectures appear to use. One detail that might need preserving is the code path dealing with TLB lookups (as a consequence of addressing errors), but it may be the case that page faults are dealt with more directly when signals arrive - perhaps what the UX code does now - and that the TLB exception vectors will remain unused. When considering some of these issues, I did wonder about the role of certain architecture-specific aspects of the MIPS implementation. The existing UX code seems to deal with "vectors" and seems rather connected to interrupt descriptor tables (or their emulation). On MIPS, exception vectors are typically resident in kernel memory and have specific addresses. It seems to me that the handling of exceptions (caused by signals) would direct execution via these vectors and thus preserve the existing exception.S implementation, albeit relocated to user memory. I guess the alternative would involve rewriting such things and using emulated processor features directly instead of trapping and handling privileged instructions. (I did also wonder to what extent the assembly language could also be migrated to C++ even for the native MIPS implementation.) That brings me to a discussion about the purpose of the user mode kernel variant. As I understand it, one of the aims is to preserve architecture- specific code so as to give that code some possible testing and general exercise: it might actually help in the development of the kernel more generally. Is this a reasonable understanding? Initially, I thought that UX would actually be architecture-neutral (in terms of mechanisms; obviously the code would be native), but it appears that a stated aim is to be able to run existing binaries unchanged. Would an architecture-neutral UX variant make any sense? I suppose I could go on and on, here, but as far as I can tell there are quite a few things that would need deciding in order to have a realistic chance of ever getting this working, amongst others that I will have forgotten or not considered... * Redefining the memory layout for kernel and task processes (so as to work within the host system constraints) * Separating generic and native functionality for various central abstractions * Replacing the memory management with a mechanism similar to that employed by the existing UX code * Defining a usable interrupt and exception paradigm (here, I am tempted to introduce a second-level controller for user mode interrupts) * Determining which modules are required and how the code should be built (largely using the existing UX configurations) * Testing and integrating the host system functionality required for the user mode kernel to function (process tracing, signal handling, system call invocations using the trampoline, thread management) On this last point, I investigated the trampoline mechanism on a MIPS Linux system, and it does seem viable. There are a few tricks to getting system calls working (that can be learned from glibc and the kernel itself), although the trick employed to cancel them may not work. Also, the paper [1] describes the need to acquire signal context information by deploying a signal handler and having processes capture context data on the kernel's behalf. This may not be necessary on MIPS since the interesting details - those that seem to be posted on the stack when IA32 exceptions occur - are available via the registers exposed by ptrace on MIPS. Indeed, I learned that ptrace is something of a fickle friend, not necessarily providing the same level of support on all systems. And thus, I wondered if there is still much sustained interest in the user mode approach or if people regard other technologies to be more practical and/or interesting. If you have read this far, maybe you might be able to share your thoughts on the topic. It has been frustrating trying to get a good overview of the code - I'm not sure the preprocessor really helps, to be honest - and while I would like to be able to get the user mode kernel working on another architecture, I would rather like to know if it is really worth my while. Getting a better understanding is therefore the first step in finding out. Paul [1] http://os.inf.tu-dresden.de/papers_ps/steinberg-beleg.pdf

4 11

Unable to create Goos FB in UEFI mode
by Adi Lima 09 Sep '19

09 Sep '19

Hi, I've been trying to make this one work, but in vain, so far... Either using qemu or in real hardware, all failed when booting from UEFI. >From qemu's stdio I know that the boot has been completed successfuly, but it seems like fb-drv was unable to support current default mode from EFI Framebuffer boot (or it is trying to switch to some other mode, and failed?). I was using standard ex_fb_spectrum_cc, with x86-fb.io, x86-fb.cfg and x86-legacy.devs, all loaded by grub2 as Multiboot2 and Module2 Everything was fine if booted using BIOS, but I haven't try on UEFI mode with CSM. Can you give me a hint of what to try next, please? Thanks in advance :-) -- FX. J. Adi Lima Trivision Studio

2 1

Full virtualization on Raspberry PI 4
by clim atisefr 29 Aug '19

29 Aug '19

Hi, I know the Raspberry PI 3 does not support the full virtualization and only para-virtualization is supported. It seems that the Raspberry PI 4 with the Broadcom 2711 (Quad-core Cortex-A72 ARM v8 64-bit SoC @ 1.5 GHz) may support it. Is there any development to support this platform with L4RE ? or any hint to start it ? Thanks, Chris

2 1

Porting Pistachio to Cell
by Tyson Key 22 Aug '19

22 Aug '19

Hi, In a wave of projects, over the years, I've been working on trying to rescue the Pistachio GitHub repository from bitrot, and build it with modern tools (I have one project that builds, and runs on x86, with an ancient version of GRUB, and another, that's a complete basket case, since KickStart is broken, but that's another matter), and saw, with some interest, ports to various Open Firmware-enabled platforms, and wondered if anyone had any guides to building, and running a PowerPC 64-bit userland, and boot infrastructure? There was an old guide to building with PSIM, and PPC32, on the KIT Website, but it seems incomplete, and it doesn't seem obvious, as to how one would build a bootable disk image, or how to prepare the compiled userland to run on hardware. Since the site is pretty dated, and the code has changed, since then, is that information even relevant? I've got access to a FreeBSD 12 PPC64 build environment, under QEMU's PSeries Xenial machine emulator, and I'm in the process of trying to set up a direct development environment, on a PlayStation 3 system, so access to PowerPC toolchains isn't a problem. Eventually, I'm planning on seeing if I can use the existing code, and parts of FreeBSD's PlayStation 3 port, to implement a basic, first-draft port to run on Sony's CellOS/BEAT ABI-based hypervisor, or in GameOS mode, with PetitBoot. Thanks in advance, for any assistance, Tyson Key.

1 0

New L4Re component released: virtio-net
by Jakub Jermar 29 Jul '19

29 Jul '19

Dear L4 hackers, last week we released virtio-net on GitHub[0]. Together with the previously released L4Re components, virtio-net can be used to interconnect two VMs with a virtual network. We also wrote a little tutorial which illustrates that[1]. Happy hacking, Jakub [0] https://github.com/kernkonzept/virtio-net [1] https://github.com/kernkonzept/manifest/wiki/MultipleVMs -- Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth

1 0

kernel error
by ssrmurthy saka 04 Jul '19

04 Jul '19

Hi team, I am using "4.13.0-36-generic" kernel and i exported cross compiler of version "gcc-linaro-7.4.1-2019.02-i686_arm-linux-gnueabihf". when i try to compile new odule i am facing below error. can you please help on this. make -C /lib/modules/4.13.0-36-generic/build/ M=/home/tessolve/c modules make[1]: Entering directory '/usr/src/linux-headers-4.13.0-36-generic' CC [M] /home/tessolve/c/vm.o In file included from ./include/asm-generic/int-ll64.h:10:0, from ./arch/arm/include/uapi/asm/types.h:4, from ./include/uapi/linux/types.h:4, from ./include/linux/compiler.h:231, from ./include/linux/init.h:4, from /home/tessolve/c/vm.c:1: ./include/uapi/asm-generic/int-ll64.h:11:10: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h> ^~~~~~~~~~~~~~~~~~~ compilation terminated. scripts/Makefile.build:315: recipe for target '/home/tessolve/c/vm.o' failed make[2]: *** [/home/tessolve/c/vm.o] Error 1 Makefile:1550: recipe for target '_module_/home/tessolve/c' failed make[1]: *** [_module_/home/tessolve/c] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-36-generic' Makefile:4: recipe for target 'all' failed make: *** [all] Error 2 Thanks, murthy

1 0

Want to run L4Re on Raspberry PI.
by Lei Zhou 28 Jun '19

28 Jun '19

HI, I'm looking for the information and procedure how to compile and deploy L4Re on Raspberry PI. Any feedbacks would be greatly appreciated! Thanks, Lei

5 26

Enable L4Linux network access on Raspberry Pi-b.
by Lei Zhou 24 Jun '19

24 Jun '19

Hi Adam & Hackers, Has anybody enabled network access for L4linux Raspberry pi3? I read through all the history on related topics and understand the process to get it working. I summarized the steps as below and major problem for me is how to convert device tree for L4linux and compose corresponding rpi_deices.io configuration. Please see my specific question inlined in those steps. Thanks in advance for your feedback. 1. configure and Compile l4linux to support flattened device tree support. Also enables CONFIG_USB_LAN78XX=y && CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_L4_SERVER = y CONFIG_USE_OF = y 2. Adapt https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2… into ./l4linux/arch/l4/boot/dts/simple.dts [Lei's question]: I understand why bcm2710-rpi-3-b.dts cannot be used directly because some of the reg_address physical address doesn't apply and might fail to be mapped. How can I pick network access specific device nodes and its dependancies(power or clock etc) and how to change those illegal reg_address? 3. Create an rpi3_devices.io for L4Re with the devices and their resources and assign the desired devices to a vbus. [Lei's question]: Should I define all device nodes one-2-one mapping from step 2's device tree? 4. Update your ned script and modules.list -- vim:set ft=lua: local L4 = require("L4"); loader = L4.default_loader; -- Start io vbus_l4linux = loader:new_channel(); --vbus_input = loader:new_channel(); --vbus_fbdrv = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; -- input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); -- fbdrv = vbus_fbdrv:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io -vvv rom/rpi_devices.io"); -- Start L4linux loader:start( { caps = { -- fb = mag_svc:create(L4.Proto.Goos, "g=640x480"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), l4re_dbg = L4.Dbg.Warn, }, "rom/vmlinuz mem=64M console=ttyLv0 l4x_rd=rom/ramdisk- l4x_dtb=rom/rpi3b-simple.dtb" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=4000 init=/bin/sh earlyprintk=1 "); 5. Build final bootstrap_l4linux.uimage for Raspberry. Thanks very much! Lei Zhou

2 2

How to enable Guest Linux VM on Raspberry PI3?
by Lei Zhou 17 Jun '19

17 Jun '19

After I brought up L4Re and Fiasco on Raspberry PI3, would like to enable guest Linux VM on top of it. I'm looking at the link https://github.com/kernkonzept/manifest/wiki/LinuxVM and hoping I can do the same thing on Raspberry PI3. The link seems using hardware-assisted virtualization option uvmm based for guest VM. There seems also L4Linux Paravirtualization option. Which option should I use for me to enable guest LInux VM on Raspberry PI3? In addition, when I followed the link to try on QEMU first, encounter some "vbus" capability issue. I followed the guidance exactly as the link says. However, when I started the command to spawning the Linux VM as: $make E=uvmm-basic qemu It failed with following log: ============================================ MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [41100000-411974b8] [C:107000] uvmm BOOTFS: [41198000-411c4e58] [C:109000] l4re BOOTFS: [411c5000-41246770] [C:10b000] ned BOOTFS: [41247000-412475c4] [C:10d000] virt-arm_virt.dtb BOOTFS: [41248000-41430200] [C:10f000] ramdisk-armv8.cpio.gz BOOTFS: [41431000-41431242] [C:111000] uvmm-basic.ned BOOTFS: [41432000-42618a00] [C:113000] Image.gz MOE: cmdline: moe rom/uvmm-basic.ned MOE: Starting: rom/ned rom/uvmm-basic.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm-basic.ned' VMM[vmbus]: 'vbus' capability not found. Hardware access not possible for VM. VMM[main]: Hello out there. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device virtio_uart@20000 failed. Disabling device. VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device interrupt-controller failed. Disabling device. VMM: FATAL: Parsing timer interrupt: Argument out of range qemu-system-aarch64: terminating on signal 2 Makefile:6: recipe for target 'do-all-make-goals' failed make: *** [do-all-make-goals] Interrupt ========================================================================= Any feedbacks are greatly appreciated! Lei Zhou

3 9

L4Re, BUILD_ARCH, cross-building for ARM on MIPS
by Paul Boddie 11 Jun '19

11 Jun '19

Hello, In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi Zero, I encountered an unusual problem: unusual because, I suppose, most people do not try and cross-build on architectures other than x86(-64). When performing the initial L4Re build directory initialisation step... make B=mybuild ...BUILD_ARCH seems to be set to x86 even on other architectures. This then causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, and the gcc host compilers for MIPS raise errors upon encountering these unrecognised arguments. Here is the offending command in the top-level Makefile (line 376 in my version, r83 in Subversion): GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o Although it seemed like the config step could be performed after ignoring these errors, I did wonder if there might be some undesirable consequences. In the end, I found that the following invocation was needed: make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32 After that, things seem to work as expected. I imagine that there is a "chicken and egg" situation here: the appropriate settings would be obtained from the configuration, but the command being run sets up the configuration. Has anyone else seen this problem before? Paul

2 1

Fwd: l4linux running lmbench
by yangzeng 29 May '19

29 May '19

Dear Developers: I am a newcomer to l4linux, I use the default configuration to run l4linux-mag, now I want to run lmbench on l4linux, how should I put lmbench into l4linux Best Regards

2 1

L4linux startup problem
by yangzeng 20 May '19

20 May '19

Hi L4 hackers, I encountered some problems when running l4linux. I used the default configuration to run l4linux. It is good to use make qemu, but when I use make grub2iso to generate iso, use qemu-system-x86_64 -cdrom l4linux-mag.iso to run. The following error occurred mag | Hello from MAG mag | mapped frame buffer at 0x1200000 mag | ERROR: could not start screen driver for given video mode. mag | Maybe unsupported pixel format... exiting mag | MAG: destroy FB svc Ned[lua]: Warning: Capability 433000 does not support the meta protocol: -2004 lua error: rom/l4lx-gfx.cfg:52: attempt to call a nil value (method 'create'). qemu-system-x86_64: terminating on signal 2 what should i do? thanks

1 0

L4Linux with L4Re and Fiasco.OC-UX
by Paul Boddie 04 Apr '19

04 Apr '19

Hello, I have been looking at trying out L4Linux in UX mode as a first step towards its use on "native" Fiasco, and I seem to be experiencing a problem with launching the Linux kernel itself. I have followed the instructions from these pages: https://l4linux.org/download.shtml https://l4linux.org/build.shtml https://l4linux.org/use.shtml Specifically, I have an existing build of UX that has been used for some time to develop software. I have updated it to revision 83 and have checked out the l4linux_requirements, which appear to be some packages (rtc and shmc) I already have. I then performed a build once again: make O=mybuild The L4Linux repository has also been checked out and updated to revision 83. The code has been configured and built using the following invocations: make O=mybuild x86_32-ux_defconfig make O=mybuild menuconfig # to set the L4Re build directory make O=mybuild Here, the mybuild directory is distinct from the L4Re mybuild directory. For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I run the system as follows: make O=mybuild ux E=L4Linux-basic After the usual familiar start-up messages, I see this output specific to the configuration being launched: ---- Ned: loading file: 'rom/l4lx.cfg' libio: Warning: Query of 'vbus' failed! PH 0 offs=00001000 flags=r-x PH-type=0x1 virt=00100000 evirt=0053f000 phys=00100000 ephys=0053f000 f_sz=0043f000 memsz=0043f000 PH 1 offs=00440000 flags=rw- PH-type=0x1 virt=0053f000 evirt=00a58000 phys=0053f000 ephys=00a58000 f_sz=0006ce9f memsz=00519000 PH 2 offs=00371ee0 flags=--- PH-type=0x4 virt=00470ee0 evirt=00470f1c phys=00470ee0 ephys=00470f1c f_sz=0000003c memsz=0000003c Starting binary at 0x100000, argc=6 argv=0xafff4f84 *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa8000bd0 L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0 ---- In order to try and identify the problem, I used the following command: addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b This seems to indicate that the point of failure is at line 2727 in arch/l4/kernel/main.c which is the start of this function: int __ref L4_CV main(int argc, char **argv) So, I wonder what the problem might be that leads to a crash as the main function is being invoked. Have I missed anything obvious? All of this is being done in a Debian unstable chroot on x86. Paul

2 2

Raspberry Pi 3B and L4Linux
by Dejan Cotra 27 Mar '19

27 Mar '19

Hi all, Im trying to run L4Linux on Raspberry Pi 3B. So far I was able to build Fiasco kernel and L4Re for Raspberry Pi 3B. I used aarch64-linux-gnu-gcc toolchain. Also I was able to create Uboot image for hello config, which I successfully run on both qemu and Raspberry Pi 3B. So now Im trying to build L4Linux. First question would be does L4Linux supparm64 architecture? If yes, any hints for configuration? If it does not support arm64 architecture does this also mean that I have to build Fiasco kernel and L4Re for 32bit arm architecture. Thanks in advance, Dejan

2 1

Invalidating mapped flexpages in pagers
by Paul Boddie 19 Mar '19

19 Mar '19

Hello, I have been trying to implement a pager in L4Re where the pager employs a memory region of limited size to satisfy map requests for a dataspace occupying a larger virtual memory region. Upon receiving a map request, the pager identifies the dimensions of the flexpage to be sent to the task experiencing the page fault, and it populates the flexpage's memory with the appropriate data. What this accomplishes so far is that when page faults occur in a task accessing the dataspace, mappings from virtual memory addresses are established in the task referring to the memory region populated by the pager. The task can read from page to page and keep getting new data. However, as each new map request comes in, I want to be able to invalidate the mappings previously made by the pager. Otherwise, I get many pages in the task's address space referring to the same memory, which is obviously not what I intend. Is it possible to send a flexpage from the pager in such a way that the mappings previously established by Fiasco.OC for the memory region are invalidated? Or have I missed some other mechanism for achieving what I am attempting? The L4Re documentation isn't helping me so much here, and I can't seem to find examples of this kind of thing in the source distribution. Thanks for any help anyone can give! Paul

2 5

Huawei R&D lab in Dresden
by Martin Decky 07 Mar '19

07 Mar '19

[Apology for this job ad. Please ignore if you are not interested in job offers.] Dear all, Huawei is starting a new R&D lab in Dresden. The lab shall focus on microkernel OS design and development, with a well-balanced mix between innovative research (including, but not limited to, topics such as HW/SW co-design, heterogeneous computing, data-centric computing, etc.) and prototype development (including, but not limited to, design and implementation of key operating system services for Huawei's microkernel OS, safety and security certification, formal verification, etc.). We offer prospective job candidates the possibility to impact billions of Huawei devices, collaborate on real-world scenarios for the microkernel multiserver OS design (in the automotive, IoT, telco, industrial and other domains) and even influence future HW design (HiSilicon, one of the major semiconductor companies, is a fully owned subsidiary of Huawei). We are also supporting mutually beneficial collaboration with academia (e.g. ETH Zurich, TU Dresden) and microkernel-related companies. If you are interested in discussing the details of the senior engineer, software architect and researcher roles we offer, please do not hesitate to contact me. We will be also more than happy to talk to you at the upcoming Fachgruppe Betriebssysteme Frühjahrstreffen 2019 in Erlangen next week [1] and at EuroSys 2019 in Dresden in about three weeks [2]. [1] https://www.betriebssysteme.org/aktivitaeten/treffen/2019-erlangen/ [2] https://www.eurosys2019.org/ Best regards Martin Decky Senior Research Engineer Huawei Technologies German Research Center

1 0

Setting up ssd and hard disk in l4linux
by Xinyue Wu 26 Feb '19

26 Feb '19

Dear Developers, I have been trying to mount ssd and hard disk in l4linux. There are some similiar questions in previous archives, and I have done the following things according to them: - configure 'devs' file and 'io' file, add sata to vbus - enable PCI support - enable vPCI driver - enable AHCI driver But when I ran l4linux in hardware, I still couldn't find sata in pci bus, nor could I found my devices under /dev. Does anyone have some suggestions? Or maybe there are something wrong in my device configuration, please let me know if so. Thanks a lot. x86-legacy.devs ================= local Res = Io.Res local Hw = Io.Hw Io.hw_add_devices(function() SATA = Hw.Device(function() Property.hid = "SATA"; Resource.iop1 = Res.io(0x1f0, 0x1f7); Resource.iop2 = Res.io(0x3f6, 0x3f7); Resource.irq = Res.irq(14); end); end) l4lx-x86.io ==================== local hw = Io.system_bus() Io.add_vbusses { l4linux = Io.Vi.System_bus { -- Add a new virtual PCI root bridge PCI0 = Io.Vi.PCI_bus { pci_sata = wrap(hw:match("SATA")); }; }; } l4lx.cfg ====================== local L4 = require("L4"); loader = L4.default_loader; vbus_l4linux = loader:new_channel(); vbus_input = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; l4linux = vbus_l4linux:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/x86-legacy.devs rom/l4lx-x86.io"); loader:start( { caps = { vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), }, "rom/vmlinuz mem=1024M console=ttyLv0 earlyprintk=1 l4x_rd=rom/ramdisk-256m.rd root=1:0 ramdisk_size=268435456");

2 1

some questions about l4bd.c in l4linux
by yadong.li 20 Feb '19

20 Feb '19

Hi Adam， I am studying how to support emmc storage in L4Re. I have read the file l4linux/drivers/block/l4bd.c. I have some questions 1、 In “l4linux/drivers/block/l4bd.c”, I can’t find the function implementation of “l4fdxc_request_write” and some with prefix l4fdxc in l4linx or l4， is there some demos? 2、 If it is implemented by ourselves, where is more reasonable to place “l4fdxc_request_write” , in l4 or l4linux ? 3、 If in l4, Which implementation is more reasonable , lib or server? Thank you very much

2 1

Communication between L4Linux tasks and L4re tasks
by Canberk Demirsoy 17 Feb '19

17 Feb '19

Dear Developers, I have a simple question regarding the communication of L4Linux and L4re. I have already read previous entries but could not solve my problem. I am able to establish a communication between the tasks in L4re, but what I need is communication between a task that is running on L4Linux and a task that is running on L4re. How can I do this in simplest way? Any suggestions? Best Regards *Canberk*

2 1

Poll for Separation Kernel (microkernel) CC Protection Profile
by Holger Blasum 20 Jan '19

20 Jan '19

Hello l4-hackers, microkernel-based systems can be used as separation kernels[*] for security. At the moment there is a poll on input for a Common Criteria for Information Technology Security (CC) separation kernel protection profile draft, organized by a certMILS.eu colleague from Rostock Univ, at https://evasys.uni-rostock.de/evasys/online.php?p=ccuf-sk-wg The idea is to have a base protection profile (PP) that all players can agree with and to specify additional functionality as add-ons to the PP (e.g., in the form of PP modules). The questionnaire is an opportunity to provide early feedback. Note that there are no mandatory questions, i.e. you can freely move around / you can leave any question unanswered - the only condition for your feedback be submitted to the collection system is that you go to the last page and use the submit button there. We invite feedback via that poll by end of this week. If, beyond the questionnaire, you want to join the Common Criteria User's Forum separation kernel working group, or anyone would like to have more time, just let me know by answering to this email. [*] https://en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security Best, -- Holger Blasum, SYSGO

1 1

QEMU advent calendar
by Matthias Lange 21 Dec '18

21 Dec '18

Hi, today we have another small treat for those interested in L4Re. You should check door 21 [1] of the QEMU advent calendar for a peek on what you can build with our newly released #L4Re projects. Happy holidays! Matthias. [1] https://www.qemu-advent-calendar.org/2018/#day-21 -- 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

1 0

New L4Re projects released
by Matthias Lange 20 Dec '18

20 Dec '18

Dear L4 folks, as the year is slowly coming to an end we want to take the opportunity to announce the release of new L4Re projects to our github [1]. This release includes the development version of our small virtual machine monitor uvmm [2]. It is capable of running Linux on all three of L4Re's supported architectures. Another noteworthy project is io [3] which is our IO device multiplexing and virtualizing component. To get you started we added a new tutorial [4] on how to setup and run a Linux VM on L4Re. We hope you enjoy the new release and we love to hear what you think. Happy holidays! Matthias. [1] https://github.com/kernkonzept [2] https://github.com/kernkonzept/uvmm [3] https://github.com/kernkonzept/io [4] https://github.com/kernkonzept/manifest/wiki/LinuxVM -- 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

1 0

UEFI L4 image?
by Peter Wiehe 26 Nov '18

26 Nov '18

Hello, can you give me a link to an UEFI flat PE image of L4Re? If that's not available, then perhaps a link to instructions how to produce one myself? Kind regards Peter

2 4

UEFI
by Peter Wiehe 23 Nov '18

23 Nov '18

Hi everybody! Is it possible to run L4 on UEFI? Kind regards Peter Wiehe

2 1

FOSDEM 2019 - Microkernels developer room - CfP
by Sebastian Sumpf 12 Oct '18

12 Oct '18

FOSDEM 2019 - Microkernels and Component-based OSes devroom CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2019 [1] in Brussels, Belgium and will share a developer room on Sunday February 03, 2019 [2]. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-, unikernel-, and componenent-based operating systems. Possible topics include, but are not limited to: * introduction of a specific OS or framework * design of subsystems and the general architecture of an OS * enabling support for hardware (architectures, device drivers) * used languages and tools * maintenance and testing * security and robustness * trends and challenges * use cases, experiences, lessons learned and demos Please use the Pentabarf [3] system to submit your proposals. You do not need to create a new account if you already have one. When in doubt, please use the devroom mailing list [4]. If you do not want to give a talk yourself, you may still send suggestions for what else you would like to see, or do in the devroom. Please send your suggestions to the mailing list. The deadline for your proposal is on December the 1st 2018. Make sure to include the following in your proposal: * title of your talk (will be printed in the FOSDEM booklet) * your full name (will be printed in the FOSDEM booklet) * a short abstract (one or two paragraphs) * duration of your talk (please, at least 25 and no longer than 55 min) The official devroom schedule (along with the accepted talks) will be announced on December the 15th on the devroom's mailing list and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. About the devroom Since the first Microkernel devroom in 2012 this devroom has been part of each following FOSDEM. By now it has become a somewhat institutionalized tradition for the micro kernel community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the Microkernel devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in Brussels. The year 2019 will not be any different, so there is going to be a microkernel family dinner on Saturday night. We try place a reservation, so we will inform you about the exact location and time later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. Important dates recap * 01.12.2018: Deadline for submissions * 15.12.2018: Schedule published and speakers notified of acceptance * 03.02.2019: The devroom takes places Links [1] http://fosdem.org [2] https://fosdem.org/2019/practical/transportation [3] https://penta.fosdem.org/submission/FOSDEM19 [4] https://lists.fosdem.org/listinfo/microkernel-devroom See you all at FOSDEM!

2 1

Information on implementing L4
by John 05 Oct '18

05 Oct '18

Hi all. I've been looking at Google and Wikipedia for information about L4, and it's fairly thin. I've come up with that L4 has read and write registers and performs IPC by fixed-length registers, with all actions synchronous (I guess that means you send a message and block until the target thread reads the message). Is there a more concrete document anywhere about implementing an L4 microkernel and what makes it L4? I'm surveying the field at the moment and looking at all the advances made in computer software—security, managed language runtimes, hypervisors, real-time OS—and trying to project the possibilities for a next-generation operating system. There's enough divergence that a rewrite from scratch might make sense; and besides, I've drawn up a method for getting a self-hosting CLR running with only anonymous memory allocation and VFS file page mapping, along with a method of getting the CLR to self-host and getting it up and running before an actual OS kernel. In other words: it's readily-achievable to write a CLR in C#, get it running on itself before the kernel comes up, then load a kernel, VMM, VFS, ABI, scheduler, and so forth—all written in C#, compiled to CIL, and totally independent of the hardware architecture underneath—and then throw away the loader and bring up init. The kernel would need to use an abstract factory model to do common tasks which require hardware-specific code, and the CLR would need to load an assembly with a concrete factory for the particular hardware and a few built-in native assembly calls; but it's doable. This is all theoretical at the moment, and I want to explore the particular edges a little to see what I find out.

7 32

OS/Microkernel Engineers Wanted!
by Osman Ismael 02 Oct '18

02 Oct '18

[Apology for the shameless ad, but might be of interest to some] BedRock Systems is a stealth startup with a global team. Our platform is based upon cutting-edge technology, including the latest generation of L4 microkernel, and leverages the next level of development methodologies and tools. We were founded by industry veterans who built large successful companies from scratch. Our top-notch team is a mixture of the best from industry and academia. Come transform the computing landscape. Join us at www.bedrocksystems.com <http://www.bedrocksystems.com/>. BedRock Systems Engineering team.

1 0

Call from 8-bytes aligned stack to functions that require 16-bytes stack alignment
by Yuxuan Shui 25 Sep '18

25 Sep '18

Hi, L4Linux is compiled with -mpreferred-stack-boundary=3, but the "external functions" it calls are usually compiled without this option, so defaults to 16 bytes alignment. This causes potential unaligned memory access if the compiler choose to generate instructions like movdqa. QEMU without kvm seems to just let this pass, but with kvm enabled, this could generate a GP. -- Regards Yuxuan Shui

1 0

RE: Issues about server multi-threading on L4Re
by 李鼎基 21 Sep '18

21 Sep '18

Oh yes! Actually I used the version without arguments. Now I think I can try to fix this problem with the constructor with arguments. Thank you very much! From: Jakub Jermar<mailto:jakub.jermar@kernkonzept.com> Sent: Friday, September 21, 2018 23:12 To: 李鼎基<mailto:lidingji1997@hotmail.com> Subject: Re: Issues about server multi-threading on L4Re On 09/21/2018 05:02 PM, 李鼎基 wrote: > Actually, I’ve tried to run the server loop in only one thread (a new > thread created by “pthread_create”, NOT the main thread) on server. > > Theoretically, it should perform the same as running the server loop in > the main thread, but the server still gets stuck. How did you create your Object_registry / Registry_server - there is a version for the main thread which has constructor without arguments [0] and uses the main thread - and then there is a version with a constructor that takes arguments [1], among which is a server thread. You need to use the second version to tell it about your new thread. Can it be that you are using the version without arguments? [0] https://l4re.org/doc/classL4Re_1_1Util_1_1Registry__server.html#a694a009623… [1] https://l4re.org/doc/classL4Re_1_1Util_1_1Registry__server.html#ad88c4355e6… HTH, Jakub > > ------------------------------------------------------------------------ > *发件人:* l4-hackers <l4-hackers-bounces(a)os.inf.tu-dresden.de> 代表 > Jakub Jermar <jakub.jermar(a)kernkonzept.com> > *发送时间:* Friday, September 21, 2018 10:26:12 PM > *收件人:* l4-hackers(a)os.inf.tu-dresden.de > *主题:* Re: Issues about server multi-threading on L4Re > > Hi there! > > On 09/21/2018 02:10 PM, 李鼎基 wrote: >> I’m trying to implement some multi-threading IPC benchmarks on L4Re. >> Following the /“shared_ds”**/demo, firstly, I create 8 threads to send >> IPC on client and receive them all on server’s main thread. >> >> The server loops, waits for the requests and handles them in the >> “dispatch” function. This single-thread server works well. >> >> >> >> Then I want to create 8 threads in server (so that it can serve the >> client thread-to-thread). >> >> I wrap the “server.loop();” in a “thread_fn” and use “pthread_create” to >> create more threads, however, the server will get stuck. >> >> There are some printings after entering thread_fn so that I can make >> sure new threads are created and executed except the server.loop part. > > I guess the problem is in that you are trying to use the same server > loop for all your threads. The server loop is associated with a single > server thread that executes the server objects. In other words, all but > the thread which is associated with your server loop just block there > and don't receive any IPC calls. > >> In order to serve different requests concurrently, is there any way to >> create a multi-threading server? > > In theory (never tried that myself), you can try giving a separate > server loop to each of your threads. You will then need to register your > server object at each of them. The end result should be that your client > threads are each connected to a different IPC gate which has its own > bound server thread. All of these gates carry the label of the same > server object which will be invoked when an IPC call arrives at any of them. > > HTH, > Jakub > > -- > Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael > Hohmuth > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers -- Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth

1 0

Issues about server multi-threading on L4Re
by 李鼎基 21 Sep '18

21 Sep '18

Hi, I’m trying to implement some multi-threading IPC benchmarks on L4Re. Following the “shared_ds” demo, firstly, I create 8 threads to send IPC on client and receive them all on server’s main thread. The server loops, waits for the requests and handles them in the “dispatch” function. This single-thread server works well. Then I want to create 8 threads in server (so that it can serve the client thread-to-thread). I wrap the “server.loop();” in a “thread_fn” and use “pthread_create” to create more threads, however, the server will get stuck. There are some printings after entering thread_fn so that I can make sure new threads are created and executed except the server.loop part. In order to serve different requests concurrently, is there any way to create a multi-threading server? -- Thanks

2 1

High 32 bits of SFMASK is reserved
by Yuxuan Shui 20 Sep '18

20 Sep '18

Hi, In cpu-64.cpp, in function Cpu::setup_sysenter, Fiasco try to set IA32_FMASK (called MSR_SFMASK in the code) to ~0ULL. However, only the lower 32bit of FMASK should be written to. This cause problems on some platforms. -- Regards Yuxuan Shui

3 2

cost (cycles + cache) of setup and use of IPC mechanisms
by Zenaan Harkness 17 Sep '18

17 Sep '18

Establishing any IPC communication channel has setup costs and per message or per "message batch" usage costs: (CPU cycles + context switches) / channel setup (CPU cycles + context switches) / msg[-batch] Further, as recent Linux kernel network stack work has discovered, cache effects strongly proscribe batch processing rather than per-msg (or per packet) processing (seems obvious, I guess "in hindsight") to make 10G and above network links work well: Batch processing of network packets https://lwn.net/Articles/763056/ and see also: User-space networking with Snabb https://lwn.net/Articles/713918/ Is there a paper quantifying and comparing various IPC mechanism costs? Specifically and separately, is there a paper quantifying the setup and use costs of shared memory IPC (possibly in comparison with any other IPC mechanism)? TIA,

1 1

L4linux booting problem on IMX.6 based board
by diming.zhang＠gmail.com 04 Sep '18

04 Sep '18

Hi, I'm working on building L4linux for my imx.6 arm-board. But the booting stopped before the l4linux console coming out. The logs is as follows: U-Boot 2015.04-imx_v2015.04_3.14.52_1.1.0_ga+g6cf684a (Sep 01 2018 - 05:09:24) CPU: Freescale i.MX6Q rev1.5 at 792 MHz CPU: Temperature 33 C Reset cause: POR Board: MX6-SabreSD I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial switch to partitions #0, OK mmc2(part 0) is current device Net: FEC [PRIME] Error: FEC address not set. Normal Boot Hit any key to stop autoboot: 1 0 reading l4linux.uimage 10982764 bytes read in 291 ms (36 MiB/s) ## Booting kernel from Legacy Image at 11000000 ... Image Name: L4 Image #51 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 10982700 Bytes = 10.5 MiB Load Address: 11000000 Entry Point: 11000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #51 Mon Sep 3 02:20:50 CST 2018, 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] Scanning up to 1024 MB RAM, starting at offset 32MB Memory size is 1024MB (10000000 - 4fffffff) RAM: 0000000010000000 - 000000004fffffff: 1048576kB Total RAM: 1024MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 12 modules behind 11100000 moving module 02 { 11a45000-11a7952b } -> { 11b36000-11b6a52b } [214316] moving module 01 { 11a3a000-11a443b7 } -> { 11b2b000-11b353b7 } [41912] moving module 00 { 1197f000-11a399d7 } -> { 11a70000-11b2a9d7 } [764376] moving module 11 { 1167f000-1197efff } -> { 11770000-11a6ffff } [3145728] moving module 10 { 11673000-1167e766 } -> { 11764000-1176f766 } [46951] moving module 09 { 1124b000-116724cf } -> { 1133c000-117634cf } [4355280] moving module 08 { 1124a000-1124a0ee } -> { 1133b000-1133b0ee } [239] moving module 07 { 11248000-1124992f } -> { 11339000-1133a92f } [6448] moving module 06 { 11247000-112473b3 } -> { 11338000-113383b3 } [948] moving module 05 { 11087000-11246a87 } -> { 11178000-11337a87 } [1833608] moving module 04 { 11025000-1108676b } -> { 11116000-1117776b } [399212] moving module 03 { 1100f000-110244ef } -> { 11100000-111154ef } [87280] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 10002000 Regions of list 'regions' [ 10000000, 100001bf] { 1c0} Root mbi_rt [ 10001000, 10001a3f] { a40} Kern fiasco [ 10002000, 100cbfff] { ca000} Kern fiasco [ 10100000, 10109c5f] { 9c60} Sigma0 sigma0 [ 10119fcc, 1011e177] { 41ac} Sigma0 sigma0 [ 10140000, 10173d0b] { 33d0c} Root moe [ 10183f70, 1018f4b3] { b544} Root moe [ 11000000, 1100e5bb] { e5bc} Boot bootstrap [ 11100000, 11a6ffff] { 970000} Root Module found kernel options (via ELF) at 10003000 Sigma0 config ip:101003f4 sp:00000000 Roottask config ip:10141590 sp:00000000 Starting kernel fiasco at 10001230 Hello from Startup::stage2 Number of IRQs available at this GIC: 160 FPU: Initialize FPU0: Subarch: 3, Part: 30, Rev: 4, Var: 9, Impl: 41 L2: ID=410000c7 Type=9e340340 Aux=32070000 WMask=ffff S=0 L2: Type L2C-310 Size = 1024kB Ways=16 Waysize=64 SERIAL ESC: allocated IRQ 61 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] for i.MX6 [] Build: #1 Sat Sep 1 02:19:56 CST 2018 Calibrating timer loop... done. MDB: use page size: 20 MDB: use page size: 12 SIGMA0: Hello! KIP @ 10002000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:10000000;10000fff] [0:100cc000;100fffff] [0:1010a000;10118fff] [0:1011f000;1013ffff] [4:10140000;10173fff] [0:10174000;10182fff] [4:10183000;1018ffff] [0:10190000;110fffff] [4:11100000;11a6ffff] [0:11a70000;4effffff] IOMEM:---------------------- [0FPU1: Subarch: 3, Part: 30, Rev: 4, Var: 9, Impl: 41 :Cache config: ON 0ID_PFR[01]: 00001231 00000011; ID_[DA]FR0: 00010444 00000000 fID_MMFR[04]: 00100103 20000000 01230000 00102111 ffffff] [0:50000000;ffffffff] MOE: Hello world MOE: found 1021396 KByte free memory MOE: found RAM from 10000000 to 4f000000 MOE: allocated 1008 KByte for the page array @0x10190000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [11100000-111154fFPU2: Subarch: 3, Part: 30, Rev: 4, Var: 9, Impl: 41 0Cache config: ON ]ID_PFR[01]: 00001231 00000011 ID_[DA]FR0: 00010444 00000000 [ID_MMFR[04]: 00100103 20000000 01230000 00102111 C:107000] l4re BOOTFS: [11116000-1117776c] [C:109000] ned BOOTFS: [11178000-11337a88] [C:10b000] io BOOTFS: [11338000-113383b4] [C:10d000] l4lx_imx6.cfg BOOTFS: [11339000-1133a930] [C:10f000] imx6_hw_devices.devs BOOTFS: [1133b000-1133b0ef] [C:111000] l4lx-imx6.io BOOTFS: [1133c000-117634d0] [C:113000] vmlinuz BOOTFS: [11764000-1176f767] [C:115000] imx6FPU3: Subarch: 3, Part: 30, Rev: 4, Var: 9, Impl: 41 qCache config: ON _ID_PFR[01]: 00001231 00000011s ID_[DA]FR0: 00010444 00000000 aID_MMFR[04]: 00100103 20000000 01230000 00102111 bresd.dtb BOOTFS: [11770000-11a70000] [C:117000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx_imx6.cfg MOE: Starting: rom/ned rom/l4lx_imx6.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx_imx6.cfg' l4linux-IO| Io service l4linux-IO| Verboseness level: 4 l4linux-IO| unused physical memory space: l4linux-IO| [00000000000000-0000000fffffff] l4linux-IO| [00000050000000-000000ffffffff] l4linux-IO| no 'iommu' capability found, using CPU-phys for DMA l4linux-IO| Loading: config 'rom/imx6_hw_devices.devs' l4linux-IO| warning: inconsistent fixed resource @ device: /System Bus/ l4linux-IO| : hid= l4linux-IO| compatible= { "fsl,imx6q-fec" } l4linux-IO| DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) l4linux-IO| Loading: config 'rom/l4lx-imx6.io' l4linux-IO| Real Hardware ----------------------------------- l4linux-IO| System Bus: hid= l4linux-IO| Resources: ==== start ==== l4linux-IO| DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) l4linux-IO| Resources: ===== end ===== l4linux-IO| ethernet: hid= l4linux-IO| compatible= { "fsl,imx6q-fec" } l4linux-IO| Clients: ===== start ==== l4linux-IO| ethernet: [N2Vi9Proxy_devE] l4linux-IO| Clients: ===== end ==== l4linux-IO| Resources: ==== start ==== l4linux-IO| IOMEM [00000002188000-0000000218bfff 4000] non-pref (32bit) (align=3fff flags=2) l4linux-IO| IRQ [00000000000096-00000000000096 1] level high (32bit) (align=0 flags=300001) l4linux-IO| IRQ [00000000000097-00000000000097 1] level high (32bit) (align=0 flags=300001) l4linux-IO| DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) l4linux-IO| Resources: ===== end ===== l4linux-IO| warning: could not register control interface at cap 'platform_ctl' l4linux-IO| Ready. Waiting for request. l4linux | PH 0 offs=00010000 flags=rwx PH-type=0x1 l4linux | virt=03000000 evirt=0348e000 l4linux | phys=03000000 ephys=0348e000 l4linux | f_sz=004071fc memsz=0048e000 l4linux | PH 1 offs=003c099c flags=r-- PH-type=0x4 l4linux | virt=033b099c evirt=033b09c0 l4linux | phys=033b099c ephys=033b09c0 l4linux | f_sz=00000024 memsz=00000024 l4linux | PH 2 offs=00000000 flags=rwx PH-type=0x6474e551 l4linux | virt=00000000 evirt=00000000 l4linux | phys=00000000 ephys=00000000 l4linux | f_sz=00000000 memsz=00000000 l4linux | Starting binary at 0x3000260, argc=5 argv=0xafff4f94 *argv=0xb1007ff4 argv0=rom/vmlinuz l4linux | External resolver is at 0xa8000b48 l4linux | ======> L4Linux starting... <======== l4linux | Linux version 4.17.0-l4 (zhangdiming@ubuntu) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)) #7 Mon Sep 3 02:20:06 CST 2018 l4linux | Binary name: rom/vmlinuz l4linux | This is an AEABI build. l4linux | Linux kernel command line (4 args): mem=64M console=ttyLv0l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=4000 l4linux | CPU mapping (l:p)[1]: 0:0 l4linux | Image: 03000000 - 03600000 [6144 KiB]. l4linux | Areas: Text: 03000000 - 032f5000 [3028kB] l4linux | RO-Data: 032f5000 - 0339b000 [664kB] l4linux | Data: 033d6000 - 034071fc [196kB] l4linux | Init: 033b1000 - 033d6000 [148kB] l4linux | BSS: 034071fc - 0348e000 [539kB] l4linux | Device scan: l4linux | Device: L4ICU l4linux | Device: ethernet l4linux | MEM: 02188000 - 0218bfff l4linux | IRQ: 00000096 - 00000096 l4linux | IRQ: 00000097 - 00000097 l4linux | DMAD: 00000000 - 00000000 l4linux | Device scan done. l4linux | l4lx_thread_create: Created thread 41d (cpu0) (u:b3000e00, v:b3000c00, sp:033d7fa4) l4linux | main thread will be 41d l4linux | L4x: section-with-init(-data): Virt: 0x3000000 to 0x348dfff [4664 KiB] l4linux | section-with-init(-data): Phys: 0x10719fff00000000 to 0x123800000000, [8 KiB] l4linux | L4x: section-with-init-text: Virt: 0x3000000 to 0x348dfff [4664 KiB] l4linux | error: failed to get physical address for 3000000. l4linux | L4x: data: Virt: 0x3000000 to 0x348dfff [4664 KiB] l4linux | error: failed to get physical address for 3000000. l4linux | L4x: Main thread running, waiting... l4linux | L4x: Memory size: 64MB l4linux | L4x: Setting superpages for main memory l4linux | L4x: Adjusted memory start: 03000000 l4linux | L4x: Main memory: Virt: 0x3600000 to 0x75fffff [65536 KiB] l4linux | Main memory: Phys: 0x11c00000 to 0x15bfffff, [65536 KiB] l4linux | L4x: vmalloc area: 07600000 - 0f600000 l4linux | L4x: text: Virt: 0x3000000 to 0x348dfff [4664 KiB] l4linux | error: failed to get physical address for 3000000. l4linux | Loading: rom/ramdisk-arm.rd l4linux | INITRD: Size of RAMdisk is 3072KiB l4linux | RAMdisk from 00002000 to 00302000 [3072KiB] l4linux | l4lx_thread_create: Created thread 422 (timer0) (u:b3000a00, v:00000000, sp:0342ffa0) l4linux | Booting Linux on physical CPU 0x0 l4linux | Linux version 4.17.0-l4 (zhangdiming@ubuntu) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)) #7 Mon Sep 3 02:20:06 CST 2018 l4linux | CPU: Fiasco [412fc09a] revision 10 (ARMv7), cr=00400000 l4linux | CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache l4linux | Machine: L4 l4linux | Ignoring unrecognised tag 0x00000000 l4linux | Memory policy: Data cache writealloc l4linux | CPU: All CPU(s) started in SVC mode. l4linux | INITRD: 00002000 - 00302000 l4linux | random: get_random_bytes called from start_kernel+0x9c/0x3c0 with crng_init=0 l4linux | Built 1 zonelists, mobility grouping on. Total pages: 17685 l4linux | Kernel command line: mem=64M console=ttyLv0l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=4000 l4linux | Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) l4linux | Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) l4linux | Memory: 64776K/71684K available (3028K kernel code, 196K rwdata, 664K rodata, 148K init, 539K bss, 6908K reserved, 0K cma-reserved) l4linux | Virtual kernel memory layout: l4linux | vector : 0xffff0000 - 0xffff1000 ( 4 kB) l4linux | fixmap : 0xffc00000 - 0xfff00000 (3072 kB) l4linux | vmalloc : 0x07600000 - 0x0f600000 ( 128 MB) l4linux | lowmem : 0x00000000 - 0x07600000 ( 118 MB) l4linux | modules : 0x02010000 - 0x03000000 ( 15 MB) l4linux | .text : 0x(ptrval) - 0x(ptrval) (3028 kB) l4linux | .init : 0x(ptrval) - 0x(ptrval) ( 148 kB) l4linux | .data : 0x(ptrval) - 0x(ptrval) ( 197 kB) l4linux | .bss : 0x(ptrval) - 0x(ptrval) ( 540 kB) l4linux | NR_IRQS: 282 l4linux | clocksource: l4kipclk: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns l4linux | l4timer: Using IRQ210 l4linux | sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns l4linux | Console: colour dummy device 80x30 l4linux | console [ttyLv0] enabled l4linux | Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280) l4linux | pid_max: default: 32768 minimum: 301 l4linux | Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) l4linux | Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) l4linux | CPU: Testing write buffer coherency: ok l4linux | Setting up static identity map for 0x3000000 - 0x3000000 l4linux | VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 l4linux | clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns l4linux | futex hash table entries: 256 (order: -1, 3072 bytes) l4linux | NET: Registered protocol family 16 l4linux | DMA: preallocated 256 KiB pool for atomic coherent allocations l4linux | Failed to create "l4x" debugfs directory: -19 l4linux | clocksource: Switched to clocksource l4kipclk l4linux | NET: Registered protocol family 2 l4linux | tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes) l4linux | TCP established hash table entries: 1024 (order: 0, 4096 bytes) l4linux | TCP bind hash table entries: 1024 (order: 0, 4096 bytes) l4linux | TCP: Hash tables configured (established 1024 bind 1024) l4linux | UDP hash table entries: 256 (order: 0, 4096 bytes) l4linux | UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) l4linux | NET: Registered protocol family 1 l4linux | Trying to unpack rootfs image as initramfs... l4linux | rootfs image is not initramfs (junk in compressed archive); looks like an initrd l4linux | INITRD: Freeing memory. l4linux | l4x: Checks passed. l4linux | NetWinder Floating Point Emulator V0.97 (double precision) l4linux | workingset: timestamp_bits=30 max_order=14 bucket_order=0 l4linux | io scheduler noop registered l4linux | io scheduler deadline registered l4linux | io scheduler cfq registered (default) l4linux | io scheduler mq-deadline registered l4linux | io scheduler kyber registered l4linux | L4 serial driver l4linux | serial-ttyLv.0: ttyLv0 at MMIO 0x1 (irq = 0, base_baud = 230400) is a L4-vcon l4linux | l4ser_shm: L4 shared mem serial driver l4linux | l4cdds: No name given, not starting. l4linux | brd: module loaded l4linux | l4bdds: No name given, not starting. l4linux | NET: Registered protocol family 17 l4linux | RAMDISK: ext2 filesystem found at block 0 l4linux | RAMDISK: Loading 3072KiB [1 disk] into ram disk... | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ done. l4linux | EXT4-fs (ram0): mounting ext2 file system using the ext4 subsystem l4linux | EXT4-fs (ram0): mounted filesystem without journal. Opts: (null) l4linux | VFS: Mounted root (ext2 filesystem) readonly on device 1:0. l4linux | Freeing unused kernel memory: 148K l4linux | This architecture does not have kernel memory protection. l4linux | The booting stopped at here, and there is no sentance as "Please press Enter to activate this console." displayed. ============================== module.list ------------------------------------- modaddr 0x01100000 default-kernel fiasco -serial_esc default-bootstrap bootstrap entry imx6-arm roottask moe rom/l4lx_imx6.cfg module l4re module ned module io module l4lx_imx6.cfg module imx6_hw_devices.devs module l4lx-imx6.io module vmlinuz module[perl] "ramdisk-$ENV{ARCH}.rd" ============================== At this point I have no idea what to do any help will be much appreciated! Thank you very much! Regards Jason

2 1

Genode 18.08 brings modern hardware support
by Stefan Kalkowski 30 Aug '18

30 Aug '18

Dear l4-hackers, the community and team around the Genode OS framework proudly presents release 18.08, which is at the same time the 10th anniversary of our project. With this release we follow our ambition to sculpt a general-purpose OS using the Genode framework. It adds support for a lot of different recent hardware, the ability to apply Intel microcode updates in a kernel agnostic fashion, and extends the interactive usability of the system. Readers of this mailing list might be especially interested in the update of the NOVA and Fiasco.OC kernels used by the framework to recent versions. The highlights of Genode 18.08 are: - Sculpt OS with live runtime view - Device drivers - Linux device-driver environment based on kernel 4.16.3 - Updated and enhanced Intel framebuffer and wireless drivers - De-componentized USB stack, support for isochronous devices - Improved device compatibility of NIC and PS/2 drivers - Experimental runtime for Zircon-based drivers - Base framework and OS-level infrastructure - NIC-router support for multiple uplinks - New VFS plugin for using LwIP as TCP/IP stack - Cached file-system-based ROM service - VFS plugin for importing initial content - Enhanced Ada language support - Libraries and applications - Python 3 - VirtualBox 5.1.38 - Platforms - New Intel Microcode update mechanism - Multiprocessor support for our custom kernel on x86 - Updated NOVA and Fiasco.OC kernels All of these and more improvements can be read in detail in the release documentation: https://genode.org/documentation/release-notes/18.08 We are looking forward for your feedback. Happy hacking! -- Stefan Kalkowski Genode labs https://github.com.skalk | https://genode.org

1 0

L4Re Build Failure on i386 (Revision 80)
by Paul Boddie 12 Aug '18

12 Aug '18

Hello, I thought I'd try and get L4Re and the UX variant of Fiasco.OC working again. Various errors with the actual compiler - not typical compilation errors - have previously occurred, but system updates come along every so often and I saw that new revisions of L4Re/Fiasco.OC have also arrived fairly recently. Unfortunately, the L4Re build fails with complaints about the linking process. Here is the verbose build output at the point of failure: [fb-drv] ==> Linking fb-drv LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep/32:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep GENDEP_TARGET=fb-drv GENDEP_BINARY=ld GENDEP_BINARY_ALT1=ld /home/paulb/L4/UX/src/l4/tool/bin/l4-bender -t ld - Dl4obj=/home/paulb/L4/UX/src/l4/mybuild -Dl4dir=/home/paulb/L4/UX/src/l4 - Dgcclibdir="/usr/lib/gcc/i686-linux-gnu/7/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/i686-linux-gnu/7/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/i386-linux-gnu/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../i686-linux-gnu/7/ /usr/lib/gcc/i686-linux-gnu/7/../../../i386- linux-gnu/ /usr/lib/gcc/i686-linux-gnu/7/../../../../lib/ /lib/i686-linux- gnu/7/ /lib/i386-linux-gnu/ /lib/../lib/ /usr/lib/i686-linux-gnu/7/ /usr/lib/i386-linux-gnu/ /usr/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/ /usr/lib/gcc/i686-linux-gnu/7/../../../ /lib/ /usr/lib/" -Dl4system=x86_gen -Dl4api=l4f -Dlinker="ld -m elf_i386" -- spec=/home/paulb/L4/UX/src/l4/mk/bid-bender.spec -- -o fb-drv -MD -MF ./.fb- drv.pcs.d -PClibc_support_misc -PClibio-vbus -PCx86emu_int10 -PCx86emu_int10 - PCstdlibs -static -gc-sections -Ttext-segment=0x01000000 --defsym __L4_KIP_ADDR__=0xaffff000 --defsym __L4_STACK_ADDR__=0xb0000000 -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen/l4f -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen -L /home/paulb/L4/UX/src/l4/mybuild/lib --warn-common -Ttext-segment=0x01000000 main.o dummy.o splash.o vesa.o ld: section `.note.gnu.property' assigned to non-existent phdr `interp' ld: section `.rel.dyn' assigned to non-existent phdr `interp' I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes? Paul

2 7

L4Re development version available on GitHub
by Jakub Jermar 04 Jul '18

04 Jul '18

Dear L4 hackers, we in Kernkonzept are happy to announce the release of our L4Re operating system framework on GitHub. Today we release 6 new repositories: https://github.com/kernkonzept/mk https://github.com/kernkonzept/manifest https://github.com/kernkonzept/l4re-core https://github.com/kernkonzept/hello https://github.com/kernkonzept/drivers-frst https://github.com/kernkonzept/bootstrap Together with the Fiasco.OC repository released earlier this year[1], these repositories represent a frequently updated foundation for building operating systems with real-time, security, safety and virtualization requirements. The manifest repository contains a Wiki with detailed instructions on building[2] L4Re and contributing[3] to it. Happy hacking! Jakub [1] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008224.html [2] https://github.com/kernkonzept/manifest/wiki/BUILDING [3] https://github.com/kernkonzept/manifest/wiki/CONTRIBUTING

1 0

Building programs with MODE=shared in L4Re
by Paul Boddie 04 Jul '18

04 Jul '18

Hello, I have been busy writing libraries and programs for L4Re and recently had to think about the size of the payloads I have been deploying. It appears that in the build system, one can use MODE=shared to build dynamically-linked programs, and there is a shared version of the hello example in the examples package. However, I don't see any recipe for doing this for other programs. My impression is that the dynamic linker must have all the required libraries deployed as modules, and so I wrote a script to generate a list of such modules using readelf. In addition, it appears that libl4sys-direct.so is required (which readelf does not detect). Adding these modules to my conf/modules.list should yield success, but within my constrained debugging environment, I only see that "shared" programs fail to start. I really need to see if they start but then experience some initialisation problem, or whether they actually crash but Mag keeps their viewports around. Are there any other things that I need to consider when building and deploying such programs? I searched for guidance on this topic and only found the following: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/007094.html http://os.inf.tu-dresden.de/pipermail/l4-hackers/2016/007830.html Both of these discussion threads only provide some details and are obviously not tutorials. Thanks for any clues you might be able to provide! Paul P.S. I guess I could also see if the CI20 produces useful console-level details, perhaps indicating an architecture-related problem. Usually, however, the problem is caused by some simple mistake I have made, so I suspect that there is merely some detail I have forgotten.

2 9

Release of Sculpt TC
by Alexander Boettcher 15 Jun '18

15 Jun '18

Hi l4-hackers, we are happy to announce the release of Sculpt TC [0], a Genode based incarnation of a microkernel based operating system. It is the second out of four Sculpt OS releases planned in 2018 [1]. Under https://genode.org/download/sculpt you find the downloadable image, which is a live system and installer all in one. Once booted you can download further packages to play around with, e.g several native Genode applications and VMs on several VMMs. Have fun. Cheers, Alex B. [0] https://lists.genode.org/pipermail/users/2018-June/006115.html [1] https://genode.org/about/road-map#2018_-_The_year_of_Sculpt -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 3

Issues about webserver on L4Re
by 李鼎基 08 Jun '18

08 Jun '18

Hi, I’ve been trying to find or write a webserver directly on L4Re (*NO* L4Linux involved) based on snapshot “l4re-snapshot-17.12”. At first, I noticed that there was already a web server in “l4re-snapshot-17.12/src/l4/pkg/ankh”. But it was broken, even if I removed the “broken” file to make, nothing was generated under “/path/to/build/pkg/ankh” except “Makefile”. Then I intend to write a simple webserver (1st step a socket demo). Although there are socket APIs, I don’t know how to solve the NIC driver issues. The same code works well on Linux but failed on L4Re. Therefore: 1. Is there any way to revive the “ankh”? 2. If not, is there any way/demo to write a simple webserver directly on L4Re? Or how to solve the NIC driver issues? -- Thanks

2 1

Porting L4Re and Fiasco.OC to the Ben NanoNote and Letux 400
by Paul Boddie 30 May '18

30 May '18

As promised, I wrote up my experiences porting L4Re and Fiasco.OC to the Ben NanoNote: https://blogs.fsfe.org/pboddie/?p=2147 There are, in fact, nine articles describing the process, which I accept might be a bit too much reading for the casual inquirer, especially as the narrative wanders from one problem to be solved to the next. But the summary should cover the main tasks that need to be done in this kind of work. Since getting things working on the Ben, I have also persuaded the software to work on the Letux 400 notebook computer, which is a variant of the Skytone Alpha-400 product that did the rounds almost ten years ago (although I was probably completely unaware of it at that time): http://blogs.fsfe.org/pboddie/?p=2175 I hope that some of the information I have shared is useful to others and perhaps encourages someone else to port the software to a device of their choosing. Good luck to that person! Paul P.S. As noted before, the patches are here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html

2 5

Input driver configuration and use in L4Re
by Paul Boddie 25 May '18

25 May '18

Hello again, I have been implementing input drivers for the keypad/keyboard provided by the Ben NanoNote and Letux 400 notebook computer, and although I appear to have implemented something that works (tested using specialised example code), using the existing OMAP3 keypad code as a guide (in pkg/drivers/input), I wondered whether it is possible to connect such drivers to other components in a convenient way. I see that the input package is the thing that provides the device registry that I use when employing the arm_input_register macro, and in that package is a framework that supposedly exports input drivers as serial I/O devices using the "l4drv" driver. But I can't find anything obvious that uses the connect operation which would need to occur to probe, enable, and attach my driver to this framework. Is it possible to integrate my input drivers to things like Mag, which seems to use input events, or to fbterminal or other things? I haven't seen any documentation or code that demonstrates this, but I suppose that I may have missed something somewhere. Thanks for any help that is offered! Paul

2 4

Re: Assertion failure error in kernel vgic interrupt processing
by nico.hacker 14 May '18

14 May '18

Hi, The previous test is not enough to cause error, this error is not related to peripherals, I have removed almost all peripheral drivers In the previous test, I added a delay operation before the vm2 start, so that vm1 completely up and then start vm2, this will greatly reduce the probability of the error. Now I removed this delay, vm1 and vm2 started simultaneously, then the error will occur frequently (about 1/10 probability). The error is generated when kernel processes vtimer interrupts. Under normal circumstances, after processing a vtimer interrupt, the vcpu thread will return to uvmm and then execute prepare_guest_entry(). This operation will eventually enter the kernel through the system call to set the state of vcpu thread, but when the error occurs, I find that the vcpu thread does not execute vcpu_resume, it processes two consecutive vtimer interrupts. As a result, the assertion fails.  Is the kernel able to guarantee that the complete process of handling vgic and vtimer interrupts (including the process in uvmm) is not interrupted by a new interrupt?  Here's my configuration: ------------------------------------------------------------------------- uvmm.ned vmm.start_vm{   id=1,   mem=256,   vbus=io_busses.vm_hw,   bootargs=common_bootargs .. " ramdisk_size=9100 root=/dev/ram",   kernel="rom/Image.gz",   rd="rom/ramdisk-arm.rd",   fdt="rom/virt-board.dtb",   prio=nil, cpus=0x1 }; vmm.start_vm{   id=2,   mem=256,   vbus=io_busses.vm_nohw,   bootargs=common_bootargs .. " ramdisk_size=9100 root=/dev/ram",   kernel="rom/Image.gz",   rd="rom/ramdisk-arm.rd",   fdt="rom/virt-board.dtb",   prio=nil, cpus=0x1 }; -------------------------------------------------------------------------- io.cfg -- vi:ft=lua local Res = Io.Res local Hw = Io.Hw local add_children = Io.Dt.add_children add_children(Io.system_bus(), function()   VGIC = Hw.Device(function()     Property.hid = "arm-gicc";     Resource.reg0 = Res.mmio(0x12006000, 0x12007fff);     Property.flags = Io.Hw_device_DF_multi_vbus;   end)   VM1_DEV = Hw.Device(function()     Property.hid = "vm1_dev";     Resource.reg0 = Res.mmio(0x70100000, 0x70100FFF); --UART   end)   VM2_DEV = Hw.Device(function()     Property.hid = "vm2_dev";     Resource.reg0 = Res.mmio(0x70100000, 0x70100FFF); --UART   end) end) ---------------------------------------------------------------------------- vm_hw.vbus Io.add_vbusses {   vm_hw = Io.Vi.System_bus(function()     VGIC = wrap(Io.system_bus():match("arm-gicc"));     VM1_DEV = wrap(Io.system_bus():match("vm1_dev"));   end); } ---------------------------------------------------------------------------- vm_nohw.vbus Io.add_vbusses {   vm_nohw = Io.Vi.System_bus(function()     VGIC = wrap(Io.system_bus():match("arm-gicc"));     VM2_DEV = wrap(Io.system_bus():match("vm2_dev"));   end); }---------------------------------------------------------------------------- Nico 于 2018-04-11 05:59:58,Adam Lackorzynski<adam os="" inf="" tu-dresden="" de="">写道:</adam><blockquote style="padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#ccc 1px solid"><pre>On Mon Apr 09, 2018 at 22:26:38 +0800, nico wrote: > Sorry, the last email did not specify this information. > I gave VM1 all the hardware resources, and it used eight cores. VM2 only has > uart resources (also timer, gic resources), using a single core. I tried to > give both VM1 and VM2 only the necessary hardware resources( uart, timer, gic), > and that error won't happen. Ok, that's interesting. So that means that some of the passed through hardware is causing this. Would you be able to find out which device is causing this, by selectively enabling/disabling devices? Adam > On 4/9/2018 06:28ï¼ Adam Lackorzynski<adam os="" inf="" tu-dresden="" de=""> wroteï¼ > > Hi Nico, > > On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote: > > Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is > running 64bit Linux. It is recommended to start two or three vms, that > will be easier to reproduce this problem. > > > So, I tried several things but cannot reproduce this issue. I assume > this are single-core VMs only? Any hardware passed through? > Just trying to narrow it down... _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers </adam></pre></blockquote><div style="height:30px;"></div><div style="height:2px;width:298px;border-bottom:solid 2px #e5e5e5"></div><div style="height:20px;"></div><a target="_blank" style="background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 25px;display:block;color:#333333;text-decoration: none;" href="http://mail.tom.com/webmail-static/welcomesxy.html" onmouseover="this.style.cssText='background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 27px;display:block;color:#4c4c4c; text-decoration:underline;'" onmouseout="this.style.cssText='background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 27px;display:block;color:#4c4c4c;text-decoration:none'">随心邮-在微信里收发邮件，及时省电又安心</a>

2 1

Assertion failure error in kernel vgic interrupt processing
by nico 10 Apr '18

10 Apr '18

2 5

Entrypoint for user-space syscall instruction
by Zihan Yang 26 Mar '18

26 Mar '18

Hi, I'm trying to figure out the entry for 'syscall' in Fiasco, I already know that Fiasco will set MSR_STAR, MSR_LSTAR and MSR_CSTAR in Cpu::setup_sysenter. However, things don't seem right when I run a simple program of my own, which is compiled statically outside in Ubuntu with gcc 5.4.0. This program directly issues a single 'syscall' instruction (instead of the syscall() function), which is equivalent to getpid(). Here is the program, which is compiled with gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c -------------------- BEGIN --------------------- //syscall_single.c //gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c #include <stdio.h> void printres(unsigned long res) { printf("Done, id = %d\n", res); } int main() { asm volatile( "mov $39, %%rax\n" "syscall\n" "mov %%rax, %%rdi\n" "call printres" : : : "cc" ); return 0; } --------------------- END ------------------------ Since Fiasco has specified MSR_LSTAR, I expect every normal system call to goto the 'entry_sys_fast_ipc_c' in src/kern/ia32/64/entry-native.S, therefore I add such line at the beginning of entry_sys_fast_ipc_c -------------------- BEGIN --------------------- .extern unsigned long test_rax; entry_sys_fast_ipc_c: movq %rax, test_rax //mov rax to the global variable test_rax --------------------- END ------------------------ And I print this variable in 'sys_ipc_wrapper'. Now strange things happen, when I type './syscall_single' in the shell, test_rax is never 39 at any time! But yet it can get the right result, and there is output in 'dispatch_system_call' in l4linux side(manually added by me). My questions are (1) What is the entrypoint and actual path if a user program directly issues a syscall instruction? (2) I find dispatch_system_call judges whether there is a system call based on the 'trap_nr' field of thread_struct, does this mean it is implemented through exception? Thanks.

1 1

Ben NanoNote patches (MIPS/Ingenic JZ4720) and memory mapping issues
by Paul Boddie 17 Mar '18

17 Mar '18

Hello, Accompanying my patches for the MIPS Creator CI20 (Ingenic JZ4780), I have some patches that get Fiasco.OC booting on the Ben NanoNote (Ingenic JZ4720). Currently, I can get a task running that shows some data on the screen. More details about the Ben NanoNote can be found here: http://en.qi-hardware.com/wiki/Ben_NanoNote (It is a "palmtop" device from around 2010 that was made in fairly limited quantities but unfortunately didn't get the attention it deserved that might have seen follow-on models, and many more units, being made.) Unfortunately, the data I display on the screen isn't aligned properly. This isn't a fundamental problem since I was happily using the screen to emit bit patterns in order to debug the kernel while working to bring it up on the hardware. However, now, in my example task, I see what would appear to be a 9-pixel misalignment with the screen. Something like this, each digit being a pixel of a certain colour, with groups of ten sharing the same colour: 122222222223333333333...111111111 Although I suspect that this is some kind of peripheral initialisation issue, none of the device registers are any different from before, and I can even neglect to initialise most of them, keeping the configuration from the bootloader, and still see the problem. The registers I do have to change are the ones that tell the LCD peripheral where the framebuffer is, but I can check that the values I use are consistent with where I am storing screen data. So it makes sense to me to check whether there might be something related to L4Re or Fiasco.OC (and my modifications, of course) that could be causing this. In my task, I do the following: l4re_ma_alloc_align(fb_size, fbmem, L4RE_MA_CONTINUOUS | L4RE_MA_PINNED, 6) Here, the documentation indicates that the alignment will be 2**6 or 64 bytes, although it will in practice be page-aligned and thus 4096 bytes in my case. This, upon success, is then followed by this: l4re_rm_attach(&fb_vaddr, fb_size,L4RE_RM_SEARCH_ADDR | L4RE_RM_EAGER_MAP, fbmem, 0, L4_PAGESHIFT) And upon success, I obtain the physical address for the region: l4re_ds_phys(fbmem, 0, &fb_paddr, &fb_size_out) Both the virtual and physical addresses seem to be page-aligned. From my limited knowledge of the hardware, I cannot envisage a situation where writes to the physical memory would be offset, let alone wrapped in the way described above. But I suppose I could easily be unaware of other things that might be happening, and so it seems worthwhile to ask around. By the way, my patches are here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html I would certainly appreciate hearing any ideas about things I might have overlooked. Thanks, Paul

1 2

I got an issue, when testing command like this :qemu–system–aarch64 -kernel uimage -smp 2...
by Jiang qihong 14 Mar '18

14 Mar '18

The whole command , qemu–system–aarch64 -kernel uimage -M vexpress -a15 -cpu cortex-a57 -smp 2 -m256 --nographic The issue is that when running into shell, i didn't find two cpus. The parameter "-smp 2",didn't work. Does qemu support arch arm -v8 when using the parameter(-smp)? From jqh mobile phone.

3 2

How to show call path in backtrace with jdb?
by Zihan Yang 14 Mar '18

14 Mar '18

Hi all, I'm trying to debug L4Linux using jdb in Fiasco. I have added a breakpoint in a function(e.g, syscall_exit), and it did hit into jdb when I run. However, when I type 'bt' in jdb, it only prints the values in the stack, or worse, it sometimes couldn't print the stack. I have tried enabling L4_DEBUG_REGISTER_NAMES and CONFIG_FRAME_POINTER in L4Linux, and uncheck 'config without frame pointer' and 'generate inline code' options in Fiasco, but still it doesn't work. QEMU could be an option, but qemu debugs the whole system while I just want to focus on the L4Linux itself because I just want to figure out the call path of ret_from_fork and how does L4Linux stop the user dispatch loop, etc. Is there any way to show the the call path in jdb to assist the debugging work? By way, is there any doc describing the call path from fiasco to L4Linux, I know it is implemented with sysretq or iretq, but where is the entrypoint in L4Linux? For example, when I type 'ls /bin' in shell, it would finally go into L4Linux's function 'syscall_exit()', but how can I find the call path between them? If I can figure it out, maybe I just don't need to debug anymore. Thanks

2 1

Is the L4Linux running as a Fiasco.OC server?
by Zeyu Mi 09 Mar '18

09 Mar '18

Hi all, I am studying the implementation of the Fiasco.OC and the L4Linux. I have searched on the Internet and many papers and documents record that L4Linux runs as an L4 server and any L4Linux user process is a new task, which has a new page table different from that of an L4Linux server. However, the experiment result seems to conflict with those documents. When I started a new program in the L4Linux shell and used "lp" command (show present list) in JDB, I noticed that there was one thread having "vcpu" state. But the resulted list did not contain any new thread or task which is related to the new program. I am very confused and wondering whether or not the implementation recorded in those papers or documents are wrong or obsolete? The experiment is based on "l4re-snapshot-2016082114". Thanks in advance for any explanation. -- Best Regards Zeyu Mi

3 12

Activating the sigma0 thread in the Fiasco kernel
by Paul Boddie 08 Mar '18

08 Mar '18

Hello, I've been trying to coerce L4Re and Fiasco.OC to work with the Ben NanoNote, which is related to the MIPS Creator CI20 that is (mostly - see earlier discussions) supported by this software. There are a few challenges involved, such as avoiding MIPS32r2 instructions that the NanoNote's SoC doesn't support (JZ4740 in the NanoNote versus JZ4780 in the CI20), and positioning things appropriately to avoid upsetting the installed bootloader. Since I last posted anything about this, I've managed to get Fiasco to go about its bootstrapping business, proceeding from the bootstrap package, entering the kernel, running kernel_main, doing various initialisation tasks, enabling interrupts, and ending up in the init_workload method where a sigma0 thread and a boot thread are created and activated. It is at this point that I seem to have encountered a particularly stubborn problem: how to get the sigma0 thread to activate and return control to init_workload for the boot thread to be activated, then going on to finish what little remains of the bootstrapping process. Strangely, the boot thread has no difficulty in being activated and returning control if I put it first in the sequence, but sigma0 seems to cause something different to happen. Now, for this activation, it seems that the real action begins in Context::switch_cpu, where an exchange of stack pointers occurs and a branch is made to the Context::switchin_context method, with the old context presumably being made to resume after the branchpoint. As far as I can tell, both threads manage to set this up correctly. I see that the new context then causes Thread::user_invoke to be called, with execution proceeding via the ret_from_user_invoke routine and ultimately into the user task. Looking at the address to which the CPU will "return" to in user mode, all seems reasonable and consistent with the configuration of sigma0. However, one thing that baffles me somewhat is the way that interrupts are disabled in Thread::user_invoke. Given that the CPU ends up in the task in user mode, it would surely need some kind of exception or interrupt for the kernel to be re-entered, yet I don't see any operation that re-enables interrupts anywhere. Maybe this is the cause of my problem, but I don't understand how sigma0 would be different from anything else. I have needed to change some CPU-level operations to adapt the code to the earlier microarchitecture revision, but I don't think I've made any obvious mistakes, and I have seemingly figured out how to describe the interrupt system because for a while I couldn't get past the Delay::init invocation in the bootstrap process which relies on interrupts working. (Some comments in the code would have helped me guess what numbers to use in certain invocations.) Does anyone have any thoughts or guidance about what I should be looking at? Thanks in advance and sorry for the wall of text! Paul

2 6

Fiasco.OC development version available on github
by Matthias Lange 22 Feb '18

22 Feb '18

Hi, Kernkonzept proudly announces the availability of a development version of the Fiasco.OC microkernel on github [1]. It features a detailed history and will be updated regularly. Those interested in exploring the latest changes can amend the latest L4Re snapshot release (see [2]) with this development version. We plan to release development versions of the build system and selected userspace components in the weeks ahead. So, let us know what you think. Cheers, Matthias. [1] https://github.com/kernkonzept/fiasco [2] https://l4re.org/download.html -- 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

4 4

L4Linux performance vs hardware virtualization
by Bob Liu 12 Feb '18

12 Feb '18

Hi Folks, L4Linux.org mentioned: "Compared to monolithic Linux, there is a small performance tradeoff because of the µ-kernel architecture. However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. " Any place can find more detail about the test? And I'm very curious the L4Linux performance vs "using hardware virtualization on top of L4", have you made any comparison before? -- Thank you! Bob

3 2

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

Get instruction opcode + operands for page fault
by Josef Stark 04 Feb '18

04 Feb '18

Hi all, when a page fault occurs, does the Instruction Register contain the actual instruction that caused the fault or the previous instruction? In the former case, how can I access it? I need the opcode + the operands (like source/target registers). I already have the memory address that the instruction tried to access. I'm on ARM A9, so only load/store instructions can cause a page fault. I know that I could also look at the address where my IP is pointing to and get the instruction from there, but I'm wondering which way would be easier/better. Cheers, Josef

2 1

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

L4Re and Meltdown / Spectre attacks
by Matthias Lange 08 Jan '18

08 Jan '18

Hi, after the dust around the Meltdown and Spectre attacks has settled a bit, you may wonder how Fiasco.OC / L4Re fares with regard to these attacks. Fiasco.OC / L4Re is vulnerable to Meltdown-like attacks because the kernel is mapped into each task. However, the kernel does not map all physical memory but only memory it requires for its own data structures + kernel-user memory required for e.g. UTCBs and vCPU state save areas. Depending on the amount of physical memory and the available page sizes, Fiasco.OC may map it little bit more than that to save TLB entries. That means there can be a slight overlap of user memory that is visible to the kernel. But it is not possible for a thread to read _all_ memory. Because we think that no thread should read information from other threads (pagetables, capability arrays, UTCBs etc.), we plan to change Fiasco.OC to execute in its own address space on Intel CPUs. Against Spectre we do not plan to implement anything right now. We think the attack surface of the kernel is very little (if any) and may be even further reduced with Intel's microcode updates and future compiler/tool mitigations. However, we will observe future discussions and developments and may reassess this in the future. Thank you and regards, Matthias. -- Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

1 0

Fiasco.OC port on Jailhouse
by Muneeswaran Rajendran 19 Dec '17

19 Dec '17

Hi, I trying to understand the porting of fiasco.OC kernel into jailhouse but not able locate the source code of jailhouse porting code for fiasco.OC kernel. Please share the same. I refer this below document to get 'jailhouse/configs/fiasco-demo.c' this file. But i do not find it. https://rtime.felk.cvut.cz/~sojka/students/F3-BP-2016-Baryshnikov-Maxim-bar… Please help me out to find out. Regards, Munees

1 0

exception while running L4linux on raspberry pi 2
by vmc doe 18 Dec '17

18 Dec '17

Hi Adam/l4-hackers, I tried to build l4+l4Re+l4linux for raspberry pi 2. The build was successful, but when I tried to run this in qemu I am getting the following error. Could you pls help me to fix this error? I am new to L4 and L4Re and would like to try out some virtualization options with L4 Microkernel. Could you pls suggest some initial modules or portions where I can start with. Regards vmc L4 Bootstrapper Build: #3 Mon Dec 11 15:24:01 IST 2017, 4.8.3 20140303 (prerelease) Scanning up to 512 MB RAM, starting at offset 32MB Memory size is 512MB (00000000 - 1fffffff) RAM: 0000000000000000 - 000000001fffffff: 524288kB Total RAM: 512MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 8 modules behind 1100000 moving module 02 { 1823000-18544df } -> { 1914000-19454df } [201952] moving module 01 { 1811000-1822373 } -> { 1902000-1913373 } [70516] moving module 00 { 1786000-1810e23 } -> { 1877000-1901e23 } [568868] moving module 07 { 1486000-1785fff } -> { 1577000-1876fff } [3145728] moving module 06 { 108c000-148547f } -> { 117d000-157647f } [4166784] moving module 05 { 102a000-108b717 } -> { 111b000-117c717 } [399128] moving module 04 { 1010000-10294a3 } -> { 1101000-111a4a3 } [103588] moving module 03 { 100f000-100f12d } -> { 1100000-110012d } [302] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 2000 Regions of list 'regions' [ 1000, 1a3f] { a40} Kern fiasco [ 2000, 9afff] { 99000} Kern fiasco [ 9b000, 9b137] { 138} Root mbi_rt [ e0000, e9ec3] { 9ec4} Sigma0 sigma0 [ f0000, f6177] { 6178} Sigma0 sigma0 [ 140000, 169e37] { 29e38} Root moe [ 170000, 18242b] { 1242c} Root moe [ 1000000, 100e573] { e574} Boot bootstrap [ 1100000, 1876fff] { 777000} Root Module found kernel options (via ELF) at 3000 Sigma0 config ip:000e0100 sp:00000000 Roottask config ip:00140250 sp:00000000 Starting kernel fiasco at 0000120c Hello from Startup::stage2 ARM generic timer: freq=62500000 interval=62500 cnt=5558234 SERIAL ESC: allocated IRQ 57 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 4.8.3 20140303 (prerelease) for Broadcom 2836 [] Build: #2 Mon Dec 11 14:06:49 IST 2017 Calibrating timer loop... done. MDB: use page size: 20 MDB: use page size: 12 SIGMA0: Hello! KIP @ 2000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:0;fff] [4:9b000;9bfff] [0:9c000;dffff] [0:ea000;effff] [0:f7000;13ffff] [4:140000;169fff] [0:16a000;16ffff] [4:170000;182fff] [0:183000;10fffff] [4:1100000;1876fff] [0:1877000;1effffff] IOMEM:---------------------- [0:20000000;ffffffff] MOE: Hello world MOE: found 499336 KByte free memory MOE: found RAM from 9b000 to 1f000000 MOE: allocated 495 KByte for the page array @0x183000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [1100000-110012e] [C:107000] l4lx.cfg BOOTFS: [1101000-111a4a4] [C:109000] l4re BOOTFS: [111b000-117c718] [C:10b000] ned BOOTFS: [117d000-1576480] [C:10d000] vmlinuz BOOTFS: [1577000-1877000] [C:10f000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx.cfg MOE: Starting: rom/ned rom/l4lx.cfg MOE: loading 'rom/ned' Ned says: Hi World! L4Re: unhandled exception: pc=0x1029198 (pfa=205a48) L4Re: Global::l4re_aux->ldr_flags=0

2 1

Trying l4re-snapshot-17.10 on a Wanboard(iMX6Q) hangs at Starting kernel ...
by Sathish Kumar Balasubramaniam -ERS, HCL Tech 18 Dec '17

18 Dec '17

Build machine is Debian 8.10 (jessie) 64-Bit GCC toolchain is gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf I tried to build the l4re-snapshot-17.10 for Freescale iMX6 and the build completed. When i loaded the bootstrap.uimage (both hello and L4Linux-basic) boots till the following U-Boot 2016.11+fslc+gc44711d (Nov 15 2017 - 16:14:11 +0530) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard rev C1 I2C: ready DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment auto-detected panel HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 => ext4load mmc 0 ${loadaddr} /boot/bootstrap.uimage 8790080 bytes read in 628 ms (13.3 MiB/s) => bootm ${loadaddr} ## Booting kernel from Legacy Image at 12000000 ... Image Name: L4 Image #2 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 8790016 Bytes = 8.4 MiB Load Address: 11000000 Entry Point: 11000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... I have a JTAG BDI-3000 with Cortex-A9 license. Any ideas how to debug the issue ??? ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

2 1

Re: Add network device to L4Linux
by Yiyang Su 28 Nov '17

28 Nov '17

Hi, Thanks so much for your explanation. Now the L4Linux has access to the network and SD card. The problem was that in order to access these two device in Cubietruck, additional hardware devices must also be provided for L4Linux such as clock source, pin control (pinctrl), power management unit and direct memory access (dma) . To add the required drivers for all hardware devices i have modified some Kconfig and Makefile of L4Linux. Furthermore at the moment Two L4Linux are running and can communicate each other via shmn. I would like to configure as that one L4Linux (call it L1 here) is only allowed to access network device and another one (L2) is only allowed to access SD card device. Now i am struggling how can i provide the right ".io" file for the vbus. First, L1 and L2 require their own devices such as """ Io.add_vbus("l4linux_1", Io.Vi.System_bus { gmacclk = wrap(Hw.GMACTX); miiclk = wrap(Hw.MII); gmacint = wrap(Hw.GMACINT); ethernet = wrap(Hw.NIC); }) Io.add_vbus("l4linux_2", Io.Vi.System_bus { mmc0clk = wrap(Hw.MMC0CLK); regachi5v = wrap(Hw.ACHI5V); regv3v3 = wrap(Hw.V3V3); mmc0 = wrap(Hw.MMC0); }) """ But L1 and L2 still require other common devices such as pinctrl, dma, clk, etc. Here comes the problem, i cannot write the ".io" file like this """ Io.add_vbus("l4linux_1", Io.Vi.System_bus { osc24mclk = wrap(Hw.OSC24M); ahbclk = wrap(Hw.AHB); apb0clk = wrap(Hw.APB0); pinctrl = wrap(Hw.PIO); dmac = wrap(Hw.DMA); gmacclk = wrap(Hw.GMACTX); miiclk = wrap(Hw.MII); gmacint = wrap(Hw.GMACINT); ethernet = wrap(Hw.NIC); }) Io.add_vbus("l4linux_2", Io.Vi.System_bus { osc24mclk = wrap(Hw.OSC24M); ahbclk = wrap(Hw.AHB); apb0clk = wrap(Hw.APB0); pinctrl = wrap(Hw.PIO); dmac = wrap(Hw.DMA); mmc0clk = wrap(Hw.MMC0CLK); regachi5v = wrap(Hw.ACHI5V); regv3v3 = wrap(Hw.V3V3); mmc0 = wrap(Hw.MMC0); }) """ and to boot two L4Linux as: """ loader:start( { caps = { icu = L4.Env.icu, sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0), input = vbus_input:svr(), general = vbus_general:svr(), l4linux_1 = vbus_l4linux_1:svr(), l4linux_2 = vbus_l4linux_2:svr(), }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io -vvv rom/l4lx-net-cubi-two.devs rom/l4lx-net-cubi-two.io" ); -- start L4Linux 1 loader:start( { caps = { vbus = vbus_l4linux_1, shmns = shmns:mode("rw"), }, .... } ); -- start L4Linux 2 loader:start( { caps = { vbus = vbus_l4linux_2, shmns = shmns:mode("rw"), }, .... } ); """ There will be conflicting virtual clients because of the two times assignments of the same device to the vbus and the two L4Linux won't be booted. I am stuck here and thinking about to implement a driver server, but don't know if it is the right direction. Any suggestions would be greatly appreciated. Yang

2 1

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

Does the latest version of L4Re support 64bit VMM?
by nico 20 Nov '17

20 Nov '17

Hi, The latest kernel supports armv8 and 64bit Hyp mode. Does that mean we can run a guest OS in VM, such as 64bit Linux? Does L4Re provide the corresponding interfaces for that? Regards, Nico

2 1

Booting L4Re with qemu-system-arm: Panic in sigma0
by Leslie Zhai 01 Nov '17

01 Nov '17

Hi L4 hackers, $ svn info Path: . Working Copy Root Path: /data/project/l4re URL: https://svn.l4re.org/repos/oc/l4re/trunk Relative URL: ^/trunk Repository Root: https://svn.l4re.org/repos/oc/l4re Repository UUID: d050ee49-bd90-4346-b210-929a50b99cfc Revision: 75 Node Kind: directory Schedule: normal Last Changed Author: l4check Last Changed Rev: 75 Last Changed Date: 2017-10-15 19:49:39 +0800 (Sun, 15 Oct 2017) My Fiasco build config: # # Automatically generated file; DO NOT EDIT. # Fiasco configuration # CONFIG_HAS_FPU_OPTION=y CONFIG_HAS_SERIAL_OPTION=y CONFIG_HAS_JDB_GZIP_OPTION=y # # Target configuration # # CONFIG_IA32 is not set # CONFIG_AMD64 is not set CONFIG_ARM=y # CONFIG_MIPS is not set CONFIG_PF_INTEGRATOR=y # CONFIG_PF_REALVIEW is not set # CONFIG_PF_SUNXI is not set # CONFIG_PF_BCM283X is not set # CONFIG_PF_SA1100 is not set # CONFIG_PF_XSCALE is not set # CONFIG_PF_ARMADA38X is not set # CONFIG_PF_KIRKWOOD is not set # CONFIG_PF_TEGRA is not set # CONFIG_PF_LAYERSCAPE is not set # CONFIG_PF_IMX is not set # CONFIG_PF_RCAR3 is not set # CONFIG_PF_EXYNOS is not set # CONFIG_PF_S3C2410 is not set # CONFIG_PF_OMAP is not set # CONFIG_PF_ZYNQ is not set CONFIG_BSP_NAME="integrator" CONFIG_CAN_ARM_CPU_926=y CONFIG_CAN_ARM_CPU_1176=y CONFIG_ABI_VF=y CONFIG_ARM_926=y # CONFIG_ARM_1176 is not set CONFIG_FPU=y CONFIG_ARM_ALIGNMENT_CHECK=y CONFIG_ARM_EM_STD=y CONFIG_ARM_CPU_ERRATA=y # # Kernel options # # CONFIG_CONTEXT_8K is not set CONFIG_CONTEXT_4K=y CONFIG_FINE_GRAINED_CPUTIME=y CONFIG_SCHED_FIXED_PRIO=y # CONFIG_SCHED_WFQ is not set # CONFIG_SCHED_FP_WFQ is not set # # Debugging # CONFIG_INLINE=y # CONFIG_NDEBUG is not set # CONFIG_NO_FRAME_PTR is not set CONFIG_STACK_DEPTH=y CONFIG_LIST_ALLOC_SANITY=y CONFIG_SERIAL=y CONFIG_JDB=y CONFIG_JDB_LOGGING=y CONFIG_JDB_GZIP=y # CONFIG_JDB_ACCOUNTING is not set # CONFIG_WARN_NONE is not set # CONFIG_WARN_WARNING is not set CONFIG_WARN_ANY=y # # ARM debugging options # CONFIG_VMEM_ALLOC_TEST=y CONFIG_DEBUG_KERNEL_PAGE_FAULTS=y # # Compiling # CONFIG_CC="gcc" CONFIG_CXX="g++" CONFIG_HOST_CC="gcc" CONFIG_HOST_CXX="g++" CONFIG_MAINTAINER_MODE=y CONFIG_LABEL="" CONFIG_EXPERIMENTAL=y CONFIG_PERF_CNT=y CONFIG_BIT32=y CONFIG_WARN_LEVEL=2 CONFIG_XARCH="arm" CONFIG_ABI="vf" My L4Re build config: # Automatically generated. Don't edit BID_COMPILER_TYPE=gcc BUILD_SYSTEMS=arm_armv5te arm_armv5te-l4f CONFIG_ARCH_ENABLE_STACK_PROTECTOR=y CONFIG_BID_GCC_ENABLE_STACK_PROTECTOR=y CONFIG_BID_GCC_STACK_PROTECTOR=y CONFIG_BUILD_ABI="l4f" CONFIG_BUILD_ABI_l4f=y CONFIG_BUILD_ARCH="arm" CONFIG_BUILD_ARCH_arm=y CONFIG_CPU_ARM_ARMV5TE=y CONFIG_CPU="armv5te" CONFIG_CTAGS="ctags" CONFIG_DROPS_INSTDIR="/path/to/l4re" CONFIG_DROPS_STDDIR="/path/to/l4re" CONFIG_ETAGS="etags" CONFIG_LEX="flex" CONFIG_MAKECONFS_ADD="" CONFIG_YACC="yacc" GCCDIR=/usr/lib/gcc/arm-linux-gnueabi/6.1.1 GCCFORTRANAVAIL= GCC_HAS_ATOMICS= GCCINCFIXEDPATH=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/include-fixed GCCLIB_EH=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/libgcc_eh.a GCCLIB_FILE_crtbegin.o=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/crtbegin.o GCCLIB_FILE_crtbeginS.o=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/crtbeginS.o GCCLIB_FILE_crtbeginT.o=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/crtbeginT.o GCCLIB_FILE_crtend.o=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/crtend.o GCCLIB_FILE_crtendS.o=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/crtendS.o GCCLIB_HOST=/usr/lib/gcc/arm-linux-gnueabi/6.1.1/libgcc.a GCCLIB_S_SO= GCCMAJORVERSION=6 GCCMINORVERSION=1 GCCNOSTACKPROTOPT=-fno-stack-protector GCCPATCHLEVEL=1 GCCSTACKPROTALLOPT=-fstack-protector-all GCCSTACKPROTOPT=-fstack-protector GCCSYSLIBDIRS=-L/usr/lib/gcc/arm-linux-gnueabi/6.1.1/ -L/usr/lib/gcc/arm-linux-gnueabi/6.1.1/../../../../arm-linux-gnueabi/lib/arm-linux-gnueabi/6.1.1/ -L/usr/lib/gcc/arm-linux-gnueabi/6.1.1/../../../../arm-linux-gnueabi/lib/ -L/usr/arm-linux-gnu/sys-root/lib/arm-linux-gnueabi/6.1.1/ -L/usr/arm-linux-gnu/sys-root/lib/ -L/usr/arm-linux-gnu/sys-root/usr/lib/arm-linux-gnueabi/6.1.1/ -L/usr/arm-linux-gnu/sys-root/usr/lib/ GCCVERSION=6 HOST_SYSTEM=linux INT_CPP_NAME=cc1 INT_CXX_NAME=cc1plus INT_LD_NAME=arm-linux-gnu-ld LD_EMULATION=armelf_linux_eabi LD_GENDEP_PREFIX=LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=/data/project/xiangzhai/l4re/l4/build-arm/tool/gendep/64:/data/project/xiangzhai/l4re/l4/build-arm/tool/gendep/32 LD_HAS_HASH_STYLE_OPTION=n LDVERSION=227-3 include /data/project/xiangzhai/l4re/l4/build-arm/.config.indep include /data/project/xiangzhai/l4re/l4/build-arm/.config.platform Booting L4Re with qemu-system-arm: $ make qemu CROSS_COMPILE=arm-linux-gnu- E=hello MODULE_SEARCH_PATH=/data/project/xiangzhai/l4re/kernel/fiasco/build-arm make[1]: Entering directory '/data/project/xiangzhai/l4re/l4' Image size(s) in bytes: bootstrap_hello.elf: 1279488 Start address: 0x1000000 --> Build-Nr: 6 QEMU-cmd: qemu-system-arm -kernel /data/project/xiangzhai/l4re/l4/build-arm/images/bootstrap.elf -serial stdio -M integratorcp -m 256 L4 Bootstrapper Build: #6 Tue Oct 31 15:50:55 CST 2017, 6.1.1 20160621 (Red Hat Cross 6.1.1-2) Scanning up to 256 MB RAM, starting at offset 32MB Memory size is 256MB (00000000 - 0fffffff) RAM: 0000000000000000 - 000000000fffffff: 262144kB Total RAM: 256MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 1100000 moving module 02 { 10e7000-11284af } -> { 11d8000-12194af } [267440] moving module 01 { 10d5000-10e6343 } -> { 11c6000-11d7343 } [70468] moving module 00 { 1053000-10d4edb } -> { 1144000-11c5edb } [532188] moving module 04 { 1031000-1052697 } -> { 1122000-1143697 } [136856] moving module 03 { 100f000-1030473 } -> { 1100000-1121473 } [136308] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 2000 Regions of list 'regions' [ 1000, 193f] { 940} Kern fiasco [ 2000, 8efff] { 8d000} Kern fiasco [ 8f000, 8f0eb] { ec} Root mbi_rt [ e0000, eb16b] { b16c} Sigma0 sigma0 [ f0000, f517b] { 517c} Sigma0 sigma0 [ 140000, 1711df] { 311e0} Root moe [ 180000, 18c4eb] { c4ec} Root moe [ 1000000, 100e4f7] { e4f8} Boot bootstrap [ 1100000, 1143fff] { 44000} Root Module found kernel options (via ELF) at 3000 Sigma0 config ip:000e0100 sp:00000000 Roottask config ip:00140254 sp:00000000 Starting kernel fiasco at 00001118 Hello from Startup::stage2 FPU: Initialize FPU0: Subarch: 1, Part: 10, Rev: 0, Var: 9, Impl: 41 KERNEL: Warning: Buddy::alloc: Size mismatch: 1c000 v 20000 SERIAL ESC: allocated IRQ 1 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: 362fdae-dirty compiled with gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) for Integrator [] Build: #2 Tue Oct 31 15:39:15 CST 2017 Calibrating timer loop... done. MDB: use page size: 20 MDB: use page size: 12 EXCEPTION: (00) Why undef insn? pfa=00002000, error=00000000 psr=20000110 R[0]: 00002000 00000000 00000000 000e01d0 000f0004 00002000 000f0030 00000000 R[8]: 00000000 00000000 00000000 000f281c 000f2808 00000000 00000000 000e01d4 KERNEL: Warning: Sigma0 raised an exception --> HALT Panic: ... --------------------------------------------------------------------- CPU 0 [f001519c]: abort jdb: Then how to use addr2line to find the root cause? please give me some hint, thanks a lot! $ arm-linux-gnu-addr2line -p -i -e bin/arm_armv5te/bootstrap.elf -a 00002000 Because 0001-Fix-invalid-initialization-in-new.patch has been already merged into svn trunk, so this http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008111.html might not fix my issue, but as Sarah mentioned "looks like a compiler issue"? $ arm-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-linux-gnueabi/6.1.1/lto-wrapper Target: arm-linux-gnueabi Configured with: ../gcc-6.1.1-20160621/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/arm-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=arm-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=arm-linux-gnueabi --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-newlib --with-plugin-ld=/usr/bin/arm-linux-gnu-ld --with-sysroot=/usr/arm-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-tune=cortex-a8 --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-gnu-indirect-function --with-linker-hash-style=gnu Thread model: single gcc version 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

3 4

Problem with L4Linux accessing ethernet clocks
by Manolis Ragkousis 01 Nov '17

01 Nov '17

Hello everyone, I am having trouble getting the network to work on L4Linux running on the zedboard. I have enabled the macb driver which my net card needs, I have created a device tree telling l4linux where to find the device and I have written the io configuration. The problem is that L4linux doesn't have access to the 3 clocks it needs for the network device to work. Those are "pclk", "hclk", "tx_clk". I understand that I have to assign those clocks to l4linux. But how can I do that? I cannot find any examples of assigning clocks. Won't this create an issue to the Fiasco kernel? Should the driver use "l4kipclk" instead of "pclk"? Below you will find the dmesg output, my io files, my cfg file and the device tree. Thank you for your time and help! Manolis ----dmesg output part begin---- __l4x_ioremap: Mapping physaddr e000b000 [0x1000 Bytes, e000b000+001000] to 00002000+000000 /amba/ethernet@e000b000: could not find phandle ERROR: could not get clock /amba/ethernet@e000b000:pclk(0) macb e000b000.ethernet: failed to get macb_clk (4294967294) macb: probe of e000b000.ethernet failed with error -2 ----dmesg output part end---- ---- zynq.dts begin ---- { model = "L4Linux (DT)"; compatible = "L4Linux"; #address-cells = <1>; #size-cells = <1>; chosen { }; aliases { }; amba { compatible = "simple-bus"; #address-cells = <0x1>; #size-cells = <0x1>; interrupt-parent = <0x3>; ranges; ethernet@e000b000 { compatible = "cdns,zynq-gem", "cdns,gem", "cdns,macb"; reg = <0xe000b000 0x1000>; status = "okay"; interrupts = <0x0 0x16 0x4>; clocks = <0x1 0x1e 0x1 0x1e 0x1 0xd>; clock-names = "pclk", "hclk", "tx_clk"; #address-cells = <0x1>; #size-cells = <0x0>; phy-mode = "rgmii-id"; phy-handle = <0x4>; ethernet-phy@0 { reg = <0x0>; linux,phandle = <0x4>; phandle = <0x4>; }; }; }; }; ---- zynq.dts end ---- ---- zedboard.devs begin ---- local Res = Io.Res local Hw = Io.Hw Io.hw_add_devices(function() NIC = Hw.Device(function() compatible = {"cdns,zynq-gem", "cdns,gem", "cdns,macb"}; Property.hid = "cdns,zynq-gem"; Property.flags = Io.Hw_device_DF_dma_supported; Resource.irq = Io.Res.irq(54); Resource.mem = Res.mmio(0xe000b000, 0xe000bfff); end); end); ---- zedboard.devs end ---- ---- hw_devices.io begin ---- local Hw = Io.system_bus() Io.add_vbus("l4linux", Io.Vi.System_bus { ethernet = wrap(Hw.NIC); }) ---- hw_devices.io end ---- ---- l4lx.cfg begin ---- local L4 = require("L4"); local loader = L4.default_loader; local lxname = "vmlinuz"; -- Start io vbus_l4linux = loader:new_channel(); local vbus_input = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); }, log = { "IO", "y" }, l4re_dbg = L4.Dbg.Warn, }, "rom/io rom/zedboard.devs rom/hw_devices.io"); L4.default_loader:start( { caps = { vbus = vbus_l4linux; }, l4re_dbg = L4.Dbg.Warn, log = L4.Env.log:m("rws"), }, "rom/vmlinuz mem=312M console=ttyLv0 " .. "l4x_dtb=rom/zynq-zed.dtb " .. "l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=5000"); ---- l4lx.cfg end ----

3 13

Add network device to L4Linux
by Yiyang Su 27 Oct '17

27 Oct '17

Hi, Starting from a previous work [1], I have succeeded in booting L4Linux on Cubietruck with the snapshot (l4re-snapshot-2016082114). Then I have been trying to configure L4Linux to access Ethernet device. With current configuration I cannot boot L4Llinux anymore. Following is my configuration and boot log: l4lx-net-cubi.devs =========================================== local Res = Io.Res local Hw = Io.Hw Io.hw_add_devices(function() NIC = Hw.Device(function() Property.hid = "sun7ia20gmac"; compatible = {"allwinner,sun7i-a20-gmac"}; Resource.regs = Res.mmio(0x01c50000, 0x01c5ffff); --Resource.irq = Res.irq(0); Resource.irq = Res.irq(85); --Resource.irq = Res.irq(4); Property.flags = Io.Hw_device_DF_dma_supported; end); end) l4lx-net-cubi.io =========================================== local hw = Io.system_bus() Io.add_vbus("l4linux", Io.Vi.System_bus { NIC = wrap(hw:match("allwinner,sun7i-a20-gmac")); }) l4lx-net-cubi.cfg =========================================== local L4 = require("L4"); local loader = L4.default_loader; vbus_l4linux = loader:new_channel(); loader:start( { caps = { icu = L4.Env.icu, sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0), l4linux = vbus_l4linux:svr(), }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io -vvv rom/l4lx-net-cubi.devs rom/l4lx-net-cubi.io" ); -- start L4Linux loader:start( { caps = { vbus = vbus_l4linux, }, --log = {"l4linux", "cyan"}, log = L4.Env.log:m("rws"), l4re_dbg = L4.Dbg.Warn, }, "rom/vmlinuz mem=64M console=ttyLv0 earlyprintk=1 l4x_dtb=rom/sun7i-a20-cubietruck.dtb " .. "l4x_rd=rom/ramdisk-" .. L4.Info.arch() .. ".rd " .. "root=1:0 rw ramdisk_size=4000" ); modules.list ============================================ entry L4Linux-net-cubi roottask moe rom/l4lx-net-cubi.cfg module l4re module ned module io module sun7i-a20-cubietruck.dtb module l4lx-net-cubi.cfg module l4lx-net-cubi.devs module l4lx-net-cubi.io module vmlinuz module[perl] "ramdisk-$ENV{ARCH}.rd" boot log =================================== U-Boot SPL 2017.03-rc3 (Aug 14 2017 - 13:26:17) DRAM: 2048 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2017.03-rc3 (Aug 14 2017 - 13:26:17 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 1024x768 vga console (overscan 0x0) In: serial Out: vga Err: vga SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr reading /boot/boot.scr 1165 bytes read in 24 ms (46.9 KiB/s) ## Executing script at 43100000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** reading boot/uImage 10481728 bytes read in 652 ms (15.3 MiB/s) ## Booting kernel from Legacy Image at 48000000 ... Image Name: L4 Image #32 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 10481664 Bytes = 10 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #32 Mi 13. Sep 11:47:18 CEST 2017, 4.9.4 Scanning up to 1024 MB RAM, starting at offset 32MB Memory size is 1024MB (40000000 - 7fffffff) RAM: 0000000040000000 - 000000007fffffff: 1048576kB Total RAM: 1024MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 12 modules behind 41100000 moving module 02 { 419cd000-419fe49b } -> { 41abd000-41aee49b } [201884] moving module 01 { 419bb000-419cc337 } -> { 41aab000-41abc337 } [70456] moving module 00 { 4192d000-419ba98b } -> { 41a1d000-41aaa98b } [579980] moving module 11 { 4162d000-4192cfff } -> { 4171d000-41a1cfff } [3145728] moving module 10 { 4122b000-4162c473 } -> { 4131b000-4171c473 } [4199540] moving module 09 { 4122a000-4122a0c2 } -> { 4131a000-4131a0c2 } [195] moving module 08 { 41229000-412291ef } -> { 41319000-413191ef } [496] moving module 07 { 41228000-4122835d } -> { 41318000-4131835d } [862] moving module 06 { 4121f000-41227d73 } -> { 4130f000-41317d73 } [36212] moving module 05 { 41094000-4121e8d3 } -> { 41184000-4130e8d3 } [1616084] moving module 04 { 41032000-410936a7 } -> { 41122000-411836a7 } [399016] moving module 03 { 41010000-4103145f } -> { 41100000-4112145f } [136288] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40002000 Regions of list 'regions' [ 40000000, 400001cf] { 1d0} Root mbi_rt [ 40001000, 40001a7f] { a80} Kern fiasco [ 40002000, 4009afff] { 99000} Kern fiasco [ 400c0000, 400ca287] { a288} Sigma0 sigma0 [ 400d0000, 400d6177] { 6178} Sigma0 sigma0 [ 40140000, 40168fcb] { 28fcc} Root moe [ 40170000, 40176ff3] { 6ff4} Root moe [ 41000000, 4100f5cb] { f5cc} Boot bootstrap [ 41100000, 41a1cfff] { 91d000} Root Module found kernel options (via ELF) at 40003000 API Version: (87) experimental Sigma0 config ip:400c0100 sp:00000000 Roottask config ip:40140210 sp:00000000 Starting kernel fiasco at 4000124c Non-HYP kernel detected but running in HYP mode, switching back. Hello from Startup::stage2 Number of IRQs available at this GIC: 160 FPU: Initialize FPU0: Subarch: 2, Part: 30, Rev: 4, Var: 7, Impl: 41 ARM generic timer: freq=24000000 interval=24000 cnt=212673046 SERIAL ESC: allocated IRQ 33 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 4.9.4 for Allwinner A20 [] Build: #4 Mon Sep 11 10:25:38 CEST 2017 Calibrating timer loop... done. MDB: use page size: 20 MDB: use page size: 12 SIGMA0: Hello! KIP @ 40002000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:40000000;40000fff] [0:4009b000;400bffff] [0:400cb000;400cffff] [0:400d7000;4013ffff] [4:40140000;40168fff] [0:40169000;4016ffff] [4:40170000;40176fff] [0:40177000;410fffff] [4:41100000;41a1cfff] [0:41a1d000;7effffff] IOMEM:---------------------- [0:0;3fffffff] [0:80000000;ffffffff] MOE: Hello world MOE: found 1021976 KByte free memory MOE: found RAM from 40000000 to 7f000000 MOE: allocated 1008 KByte for the page array @0x40177000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:103000] BOOTFS: [41100000-41121460] [C:105000] l4re BOOTFS: [41122000-411836a8] [C:107000] ned BOOTFS: [41184000-4130e8d4] [C:109000] io BOOTFS: [4130f000-41317d74] [C:10b000] sun7i-a20-cubietruck.dtb BOOTFS: [41318000-4131835e] [C:10d000] l4lx-net-cubi.cfg BOOTFS: [41319000-413191f0] [C:10f000] l4lx-net-cubi.devs BOOTFS: [4131a000-4131a0c3] [C:111000] l4lx-net-cubi.io BOOTFS: [4131b000-4171c474] [C:113000] vmlinuz BOOTFS: [4171d000-41a1d000] [C:115000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx-net-cubi.cfg MOE: Starting: rom/ned rom/l4lx-net-cubi.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx-net-cubi.cfg' IO | Io service IO | Verboseness level: 4 IO | unused physical memory space: IO | [00000000000000-0000003fffffff] IO | [00000080000000-000000ffffffff] IO | no 'iommu' capability found use CPU-phys for DMA IO | Loading: config 'rom/l4lx-net-cubi.devs' IO | warning: inconsistent fixed resource @ device: /System Bus/ IO | : hid=sun7ia20gmac IO | DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) IO | Loading: config 'rom/l4lx-net-cubi.io' IO | Real Hardware ----------------------------------- IO | System Bus: hid= IO | Resources: ==== start ==== IO | DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) IO | Resources: ===== end ===== IO | NIC: hid=sun7ia20gmac IO | Clients: ===== start ==== IO | NIC: [N2Vi9Proxy_devE] IO | Clients: ===== end ==== IO | Resources: ==== start ==== IO | IRQ [00000000000055-00000000000055 1] none (32bit) (align=0 flags=1) IO | IOMEM [00000001c50000-00000001c5ffff 10000] non-pref (32bit) (align=ffff flags=2) IO | DMADOM [00000000000000-00000000000000 1] non-pref (32bit) (align=0 flags=6) IO | Resources: ===== end ===== IO | warning: could not register control interface at cap 'platform_ctl' IO | Ready. Waiting for request. PH 0 offs=00010000 flags=rwx PH-type=0x1 virt=02000000 evirt=0245b5dc phys=02000000 ephys=0245b5dc f_sz=003d3653 memsz=0045b5dc PH 1 offs=00394898 flags=r-x PH-type=0x4 virt=02384898 evirt=023848bc phys=02384898 ephys=023848bc f_sz=00000024 memsz=00000024 PH 2 offs=00000000 flags=rwx PH-type=0x6474e551 virt=00000000 evirt=00000000 phys=00000000 ephys=00000000 f_sz=00000000 memsz=00000000 Starting binary at 0x2000330, argc=9 argv=0xafff4f84 *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa80007cc ======> L4Linux starting... <======== Linux version 4.7.0-l4 (yiyang@i85217) (gcc version 4.9.4 (Linaro GCC 4.9-2017.01) ) #4 Wed Sep 13 11:18:30 CEST 2017 Binary name: rom/vmlinuz This is an AEABI build. Linux kernel command line (8 args): mem=64M console=ttyLv0 earlyprintk=1 l4x_dtb=rom/sun7i-a20-cubietruck.dtb l4x_rd=rom/ramdisk-arm.rd root=1:0 rw ramdisk_size=4000 CPU mapping (l:p)[1]: 0:0 Image: 02000000 - 02600000 [6144 KiB]. Areas: Text: 02000000 - 023848bc [3602kB] RO-Data: 022ad000 - 02370000 [780kB] Data: 023ac000 - 023cefe0 [139kB] Init: 02385000 - 023ac000 [156kB] BSS: 023d3653 - 0245b5dc [543kB] Device scan: Device: L4ICU Device: NIC IRQ: 00000055 - 00000055 MEM: 01c50000 - 01c5ffff DMAD: 00000000 - 00000000 Device scan done. l4lx_thread_create: Created thread 41e (cpu0) (u:b3000e00, v:b3000c00, sp:023adfa4) main thread will be 41e L4x: section-with-init(-data): Virt: 0x2000000 to 0x245bfff [4464 KiB] section-with-init(-data): Phys: 0x40273000 to 0x406cefff, [4464 KiB] L4x: section-with-init-text: Virt: 0x2000000 to 0x245bfff [4464 KiB] error: failed to get physical address for 2000000. L4x: Main thread running, waiting... L4x: Memory size: 64MB L4x: Setting superpages for main memory L4x: Adjusted memory start: 02000000 L4x: Main memory: Virt: 0x2600000 to 0x65fffff [65536 KiB] Main memory: Phys: 0x41c00000 to 0x45bfffff, [65536 KiB] l4x: vmalloc area: 06600000 - 0e600000 L4x: text: Virt: 0x2000000 to 0x245bfff [4464 KiB] error: failed to get physical address for 2000000. The boot process stops at this point. Compare with other boot logs in archives the following step could be the loading ramdisk and device tree blob. Then I delete the "l4x_dtb=rom/sun7i-a20-cubietruck.dtb" from the cmdline, it can boot the L4Linux again. Does it mean there is a problem with loading the device tree blob? Any suggestion is very appreciated. Thanks. Best regards, Yang [1] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008120.html

5 7

FOSDEM 2018 - Microkernels developer room - CfP
by Jakub Jermar 09 Oct '17

09 Oct '17

FOSDEM 2018 - Microkernels developer room CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2018 [1] in Brussels, Belgium and will share a developer room on Saturday of February 3, 2018 [2]. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based operating systems. Possible topics include, but are not limited to: * Introduction of a specific OS or framework * Design of subsystems and the general architecture of an OS * Enabling support for hardware (architectures, device drivers) * Used languages and tools * Maintenance and testing * Security and robustness * Trends and challenges * Use cases, experiences, lessons learned and demos Please use the Pentabarf [3] system to submit your proposals and file it under the track “Microkernels devroom”. You do not need to create a new account if you already have one. When in doubt, please use the devroom mailing list [4]. If you do not want to give a talk yourself, you may still send suggestions for what else you would like to see, or do in the devroom. Please send your suggestions to the mailing list. The deadline for your proposal is on December 8. Make sure to include the following in your proposal: * Title of your talk (will be printed in the FOSDEM booklet) * Your full name (will be printed in the FOSDEM booklet) * A short abstract (one or two paragraphs) * Duration of your talk (please, at least 25 and no longer than 45 min) The official devroom schedule (along with the accepted talks) will be announced on December the 15th on the devroom's mailing list and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors 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 discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. About the devroom Since the first Microkernel devroom in 2012 this devroom has been part of each following FOSDEM. By now it has become a somewhat institutionalized tradition for the microkernel community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the Microkernel devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in downtown Brussels after the devroom closes. The year 2018 will not be any different, so there is going to be a microkernel family dinner on Saturday night. The exact location and time will be specified later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. Important dates recap * 08.12.2017: Deadline for submissions * 15.12.2017: Schedule published and speakers notified of acceptance * 03.02.2018: The devroom takes places Links [1] http://fosdem.org/ [2] https://fosdem.org/2018/practical/transportation/ [3] https://penta.fosdem.org/submission/FOSDEM18 [4] https://lists.fosdem.org/listinfo/microkernel-devroom See you all at FOSDEM!

1 0

Trying to run L4Linux on Cubietruck
by Yiyang Su 23 Sep '17

23 Sep '17

Dear L4-hackers, I have already run "Hello World!" on Cubietruck. At the moment i am trying to run L4Linux. I have built the files on Ubuntu with cross compiler gcc-linaro-4.9.4-arm-linux-gnueabihf. During booting there are two errors, assertion failure and kernel panic. The logs are stated below: Assertion failure ==================================================== U-Boot SPL 2017.03-rc3 (Jul 28 2017 - 11:53:12) DRAM: 2048 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2017.03-rc3 (Jul 28 2017 - 11:53:12 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 1024x768 vga console (overscan 0x0) In: serial Out: vga Err: vga SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr reading /boot/boot.scr 883 bytes read in 24 ms (35.2 KiB/s) ## Executing script at 43100000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** reading boot/script.bin 46404 bytes read in 32 ms (1.4 MiB/s) reading boot/uImage 8745024 bytes read in 518 ms (16.1 MiB/s) ## Booting kernel from Legacy Image at 48000000 ... Image Name: L4 Image #11 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 8744960 Bytes = 8.3 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #11 Fr 28. Jul 15:38:45 CEST 2017, 4.9.4 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (40000000 - bfffffff) Limiting 'RAM' region [ 40000000, bfffffff] { 80000000} to [ 40000000, bcffffff] { 7d000000} due to 3024 MB address limit RAM: 0000000040000000 - 00000000bcffffff: 2048000kB Total RAM: 2000MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 8 modules behind 41100000 moving module 02 { 41825000-4185649f } -> { 41916000-4194749f } [201888] moving module 01 { 41813000-4182433b } -> { 41904000-4191533b } [70460] moving module 00 { 41776000-4181296f } -> { 41867000-4190396f } [641392] moving module 07 { 41476000-41775fff } -> { 41567000-41866fff } [3145728] moving module 06 { 41094000-41475477 } -> { 41185000-41566477 } [4068472] moving module 05 { 41032000-410936ab } -> { 41123000-411846ab } [399020] moving module 04 { 41010000-41031463 } -> { 41101000-41122463 } [136292] moving module 03 { 4100f000-4100f12d } -> { 41100000-4110012d } [302] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40002000 Regions of list 'regions' [ 40000000, 40000137] { 138} Root mbi_rt [ 40001000, 40001a7f] { a80} Kern fiasco [ 40002000, 400aafff] { a9000} Kern fiasco [ 400c0000, 400ca287] { a288} Sigma0 sigma0 [ 400d0000, 400d6177] { 6178} Sigma0 sigma0 [ 40140000, 4016851b] { 2851c} Root moe [ 40170000, 40176ff3] { 6ff4} Root moe [ 41000000, 4100e55b] { e55c} Boot bootstrap [ 41100000, 41866fff] { 767000} Root Module found kernel options (via ELF) at 40003000 API Version: (87) experimental Sigma0 config ip:400c0100 sp:00000000 Roottask config ip:40140210 sp:00000000 Starting kernel fiasco at 4000124c Non-HYP kernel detected but running in HYP mode, switching back. Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) Number of IRQs available at this GIC: 160 FPU: Initialize FPU0: Subarch: 2, Part: 30, Rev: 4, Var: 7, Impl: 41 ARM generic timer: freq=24000000 interval=24000 cnt=211255640 SERIAL ESC: allocated IRQ 33 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 4.9.4 for Allwinner A20 [] Build: #4 Fri Jul 28 15:09:33 CEST 2017 Per_cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) Allocate 1480 bytes (1KB) for CPU[2] local storage (offset=134ad10, 0xf13e4800-0xf13e4dc8) Number of CPUs: 1 Calibrating timer loopP..e.r_ cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) Allocate 1480 bytdeons e(.1 B) for CPU[1] MlDocB:a l usseto praaggee (siozffe:s et=115200d10, 0xf11ea800-MDB: use page size: 01x2f11eadc8) DiffSerent frequency on AP CPUsIFPUG1M: Subarch: A20, Part: :30 , Rev: H4e, Var: 7ll, Impl: o41! ache config: ON KIID_PFR[01]: P00001 131@ 0001104110 ID_[DA]FR0: 00200105552 00000000000 eD_MMFR[04]: 101 01105 a40000000l l0o1240000c a0t2102211 B CPU[14]: Kgoes to idle loop for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:40000000;40000fff] [0:400ab000;400bffff] [0:400cb000;400cffff] [0:400d7000;4013ffff] [4:40140000;40168fff] [0:40169000;4016ffff] [4:40170000;40176fff] [0:40177000;410fffff] [4:41100000;41866fff] [0:41867000;bbffffff] IOMEM:---------------------- [0:0;3fffffff] [0:bd000000;ffffffff] MOE: Hello world MOE: found 2023088 KByte free memory MOE: found RAM from 40000000 to bc000000 MOE: allocated 1984 KByte for the page array @0x40177000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:103000] BOOTFS: [41100000-4110012e] [C:105000] l4lx.cfg BOOTFS: [41101000-41122464] [C:107000] l4re BOOTFS: [41123000-411846ac] [C:109000] ned BOOTFS: [41185000-41566478] [C:10b000] vmlinuz BOOTFS: [41567000-41867000] [C:10d000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx.cfg MOE: Starting: rom/ned rom/l4lx.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx.cfg' Assertion failed at /home/yiyang/Microkernel_ARM/l4re/src/kernel/fiasco/src/lib/libk/slab_cache.cpp:261: ret --------------------------------------------------------------------- CPU 0 [f001d9e0]: abort Kernel panic ========================================================= U-Boot SPL 2017.03-rc3 (Jul 28 2017 - 11:53:12) DRAM: 2048 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2017.03-rc3 (Jul 28 2017 - 11:53:12 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 1024x768 vga console (overscan 0x0) In: serial Out: vga Err: vga SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr reading /boot/boot.scr 883 bytes read in 24 ms (35.2 KiB/s) ## Executing script at 43100000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** reading boot/script.bin 46404 bytes read in 32 ms (1.4 MiB/s) reading boot/uImage 8745024 bytes read in 518 ms (16.1 MiB/s) ## Booting kernel from Legacy Image at 48000000 ... Image Name: L4 Image #11 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 8744960 Bytes = 8.3 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... L4 Bootstrapper Build: #11 Fr 28. Jul 15:38:45 CEST 2017, 4.9.4 Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (40000000 - bfffffff) Limiting 'RAM' region [ 40000000, bfffffff] { 80000000} to [ 40000000, bcffffff] { 7d000000} due to 3024 MB address limit RAM: 0000000040000000 - 00000000bcffffff: 2048000kB Total RAM: 2000MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 8 modules behind 41100000 moving module 02 { 41825000-4185649f } -> { 41916000-4194749f } [201888] moving module 01 { 41813000-4182433b } -> { 41904000-4191533b } [70460] moving module 00 { 41776000-4181296f } -> { 41867000-4190396f } [641392] moving module 07 { 41476000-41775fff } -> { 41567000-41866fff } [3145728] moving module 06 { 41094000-41475477 } -> { 41185000-41566477 } [4068472] moving module 05 { 41032000-410936ab } -> { 41123000-411846ab } [399020] moving module 04 { 41010000-41031463 } -> { 41101000-41122463 } [136292] moving module 03 { 4100f000-4100f12d } -> { 41100000-4110012d } [302] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40002000 Regions of list 'regions' [ 40000000, 40000137] { 138} Root mbi_rt [ 40001000, 40001a7f] { a80} Kern fiasco [ 40002000, 400aafff] { a9000} Kern fiasco [ 400c0000, 400ca287] { a288} Sigma0 sigma0 [ 400d0000, 400d6177] { 6178} Sigma0 sigma0 [ 40140000, 4016851b] { 2851c} Root moe [ 40170000, 40176ff3] { 6ff4} Root moe [ 41000000, 4100e55b] { e55c} Boot bootstrap [ 41100000, 41866fff] { 767000} Root Module found kernel options (via ELF) at 40003000 API Version: (87) experimental Sigma0 config ip:400c0100 sp:00000000 Roottask config ip:40140210 sp:00000000 Starting kernel fiasco at 4000124c Non-HYP kernel detected but running in HYP mode, switching back. Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) Number of IRQs available at this GIC: 160 FPU: Initialize FPU0: Subarch: 2, Part: 30, Rev: 4, Var: 7, Impl: 41 ARM generic timer: freq=24000000 interval=24000 cnt=211256036 SERIAL ESC: allocated IRQ 33 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: unknown compiled with gcc 4.9.4 for Allwinner A20 [] Build: #4 Fri Jul 28 15:09:33 CEST 2017 Per_cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) Allocate 1480 bytes (1KB) for CPU[2] local storage (offset=134ad10, 0xf13e4800-0xf13e4dc8) Number of CPUs: 1 Calibrating timer loopP.e..r_ cpu_data_alloc: (orig: 0xf0099af0-0xf009a0b8) 1llocate 1480 bydteosne (. B) for CPU[1] MlDocB:a l usseto praaggee (siozffe:s et=115200d10, 0xf11ea800-MDB: use page size: 0x1f211eadc8) !iffSerent frequency on AP CPUsIFPUG1M: Subarch: A20, Part: :30 , Rev: H4e, Var: l7l, Impl: o41 Cache config: ON KIID_PFR[01]: P0000 1131 @ 0001104110 ID_[DA]FR0: 0002010555 200000000000 eD_MMFR[04]: 101 01105 a40000000l l0o1240000c a0t2102211 B CPU[14]:K goes to idle loop for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [4:40000000;40000fff] [0:400ab000;400bffff] [0:400cb000;400cffff] [0:400d7000;4013ffff] [4:40140000;40168fff] [0:40169000;4016ffff] [4:40170000;40176fff] [0:40177000;410fffff] [4:41100000;41866fff] [0:41867000;bbffffff] IOMEM:---------------------- [0:0;3fffffff] [0:bd000000;ffffffff] MOE: Hello world MOE: found 2023088 KByte free memory MOE: found RAM from 40000000 to bc000000 MOE: allocated 1984 KByte for the page array @0x40177000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:103000] BOOTFS: [41100000-4110012e] [C:105000] l4lx.cfg BOOTFS: [41101000-41122464] [C:107000] l4re BOOTFS: [41123000-411846ac] [C:109000] ned BOOTFS: [41185000-41566478] [C:10b000] vmlinuz BOOTFS: [41567000-41867000] [C:10d000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx.cfg MOE: Starting: rom/ned rom/l4lx.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx.cfg' libio: Warning: Query of 'vbus' failed! PH 0 offs=00010000 flags=rwx PH-type=0x1 virt=02000000 evirt=0244333c phys=02000000 ephys=0244333c f_sz=003bb3d5 memsz=0044333c PH 1 offs=0037ef74 flags=r-x PH-type=0x4 virt=0236ef74 evirt=0236ef98 phys=0236ef74 ephys=0236ef98 f_sz=00000024 memsz=00000024 PH 2 offs=00000000 flags=rwx PH-type=0x6474e551 virt=00000000 evirt=00000000 phys=00000000 ephys=00000000 f_sz=00000000 memsz=00000000 Starting binary at 0x2000330, argc=6 argv=0xafff4f8c *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa80007cc ======> L4Linux starting... <======== Linux version 4.7.0-l4 (yiyang@Dell-E4XY) (gcc version 4.9.4 (Linaro GCC 4.9-2017.01) ) #2 Fri Jul 28 14:00:04 CEST 2017 Binary name: rom/vmlinuz This is an AEABI build. Linux kernel command line (5 args): mem=128M console=ttyLv0 l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=4000 CPU mapping (l:p)[1]: 0:0 Image: 02000000 - 02600000 [6144 KiB]. Areas: Text: 02000000 - 0236ef98 [3515kB] RO-Data: 0229e000 - 0235b000 [756kB] Data: 02394000 - 023b6d20 [139kB] Init: 0236f000 - 02394000 [148kB] BSS: 023bb3d5 - 0244333c [543kB] Device scan: Device scan done. l4lx_thread_create: Created thread 41a (cpu0) (u:b3000e00, v:b3000c00, sp:02395fa4) main thread will be 41a L4x: section-with-init(-data): Virt: 0x2000000 to 0x2443fff [4368 KiB] L4x: section-with-init-text: Virt: 0x2000000 to 0x2443fff [4368 KiB] L4x: Main thread running, waiting... L4x: Memory size: 128MB L4x: Setting superpages for main memory L4x: Adjusted memory start: 02000000 L4x: Main memory: Virt: 0x2600000 to 0xa5fffff [131072 KiB] l4x: vmalloc area: 0a600000 - 12600000 L4x: text: Virt: 0x2000000 to 0x2443fff [4368 KiB] panic: going to sleep forever, bye Any help would be appreciated. Thanks, Yiyang

2 2

L4Linux network and SD Access
by Daniel (Xiaolong) Wang 19 Aug '17

19 Aug '17

Hi all, I want to give L4Linux access to SD card, and ethernet driver. Initially I thought by run L4Linux kernel on top of L4re, drivers built with L4Linux kernel can just work. After trying and reading the email archive, seems like I need to configure the corresponding capability in cfg. I’m very new to L4re environment is there any tutorials or references that can help me understand it better? (I’m currently reading the manual, my development board is a beagle bone black) Also I’m trying to build a L4Linux with MMC driver. My configuration is based on default arm_defconfig. I enabled * Make Linux be a Server * Bus driver for L4vbus * L4shm based network driver * MMC/SD/SDIO card support -> HW reset support for eMMC, MMC block device driver, Use bounce buffer for simple hosts, SDIO UART/GPS class support, Secure Digital Host Controller Interface Support, SDHCI platform and OF driver helper, MediaTek SD/MMC Card Interface support * DOS/FAT/NT Filesystem -> MSDOS fs support, VFAT fs support however, when it build the following errors show did I do something wrong? LD drivers/i2c/busses/built-in.o LD drivers/i2c/muxes/built-in.o LD drivers/i2c/built-in.o LD drivers/idle/built-in.o CC drivers/input/input.o CC drivers/input/input-compat.o CC drivers/input/input-mt.o CC drivers/input/ff-core.o LD drivers/input/input-core.o CC drivers/input/mousedev.o CC drivers/input/evdev.o LD drivers/input/built-in.o LD drivers/iommu/built-in.o CC drivers/irqchip/irqchip.o LD drivers/irqchip/built-in.o LD drivers/leds/built-in.o LD drivers/lguest/built-in.o LD drivers/macintosh/built-in.o LD drivers/media/common/b2c2/built-in.o LD drivers/media/common/saa7146/built-in.o LD drivers/media/common/siano/built-in.o LD drivers/media/common/v4l2-tpg/built-in.o LD drivers/media/common/built-in.o LD drivers/media/firewire/built-in.o LD drivers/media/i2c/soc_camera/built-in.o LD drivers/media/i2c/built-in.o LD drivers/media/mmc/siano/built-in.o LD drivers/media/mmc/built-in.o LD drivers/media/pci/b2c2/built-in.o LD drivers/media/pci/ddbridge/built-in.o LD drivers/media/pci/dm1105/built-in.o LD drivers/media/pci/mantis/built-in.o LD drivers/media/pci/netup_unidvb/built-in.o LD drivers/media/pci/ngene/built-in.o LD drivers/media/pci/pluto2/built-in.o LD drivers/media/pci/pt1/built-in.o LD drivers/media/pci/pt3/built-in.o LD drivers/media/pci/saa7146/built-in.o LD drivers/media/pci/smipcie/built-in.o LD drivers/media/pci/ttpci/built-in.o LD drivers/media/pci/built-in.o LD drivers/media/platform/omap/built-in.o LD drivers/media/platform/built-in.o LD drivers/media/rc/keymaps/built-in.o LD drivers/media/rc/built-in.o LD drivers/media/tuners/built-in.o LD drivers/media/usb/b2c2/built-in.o LD drivers/media/usb/dvb-usb/built-in.o LD drivers/media/usb/dvb-usb-v2/built-in.o LD drivers/media/usb/s2255/built-in.o LD drivers/media/usb/siano/built-in.o LD drivers/media/usb/stkwebcam/built-in.o LD drivers/media/usb/ttusb-budget/built-in.o LD drivers/media/usb/ttusb-dec/built-in.o LD drivers/media/usb/zr364xx/built-in.o LD drivers/media/usb/built-in.o LD drivers/media/built-in.o LD drivers/mfd/built-in.o LD drivers/misc/cb710/built-in.o LD drivers/misc/eeprom/built-in.o LD drivers/misc/lis3lv02d/built-in.o LD drivers/misc/mic/bus/built-in.o LD drivers/misc/mic/built-in.o LD drivers/misc/ti-st/built-in.o LD drivers/misc/built-in.o CC drivers/mmc/card/block.o CC drivers/mmc/card/queue.o LD drivers/mmc/card/mmc_block.o CC drivers/mmc/card/sdio_uart.o LD drivers/mmc/card/built-in.o CC drivers/mmc/core/core.o CC drivers/mmc/core/bus.o CC drivers/mmc/core/host.o CC drivers/mmc/core/mmc.o CC drivers/mmc/core/mmc_ops.o CC drivers/mmc/core/sd.o CC drivers/mmc/core/sd_ops.o CC drivers/mmc/core/sdio.o CC drivers/mmc/core/sdio_ops.o CC drivers/mmc/core/sdio_bus.o CC drivers/mmc/core/sdio_cis.o CC drivers/mmc/core/sdio_io.o CC drivers/mmc/core/sdio_irq.o CC drivers/mmc/core/quirks.o CC drivers/mmc/core/slot-gpio.o CC drivers/mmc/core/pwrseq.o CC drivers/mmc/core/debugfs.o LD drivers/mmc/core/mmc_core.o CC drivers/mmc/core/pwrseq_simple.o CC drivers/mmc/core/pwrseq_emmc.o LD drivers/mmc/core/built-in.o CC drivers/mmc/host/sdhci.o CC drivers/mmc/host/mtk-sd.o CC drivers/mmc/host/sdhci-pltfm.o CC drivers/mmc/host/sdhci-of-arasan.o CC drivers/mmc/host/sdhci-of-at91.o LD drivers/mmc/host/built-in.o LD drivers/mmc/built-in.o CC drivers/net/Space.o CC drivers/net/loopback.o CC drivers/net/l4shmnet.o LD drivers/net/built-in.o LD drivers/nfc/built-in.o LD drivers/nvme/host/built-in.o LD drivers/nvme/built-in.o CC drivers/of/base.o CC drivers/of/device.o CC drivers/of/platform.o CC drivers/of/fdt.o CC drivers/of/fdt_address.o CC drivers/of/address.o CC drivers/of/irq.o CC drivers/of/of_reserved_mem.o LD drivers/of/built-in.o LD drivers/platform/built-in.o LD drivers/power/built-in.o LD drivers/pwm/built-in.o CC drivers/rtc/rtc-lib.o LD drivers/rtc/built-in.o LD drivers/soc/bcm/built-in.o LD drivers/soc/fsl/built-in.o LD drivers/soc/built-in.o CC drivers/tty/tty_io.o CC drivers/tty/n_tty.o CC drivers/tty/tty_ioctl.o CC drivers/tty/tty_ldisc.o CC drivers/tty/tty_buffer.o CC drivers/tty/tty_port.o CC drivers/tty/tty_mutex.o CC drivers/tty/tty_ldsem.o CC drivers/tty/pty.o CC drivers/tty/sysrq.o LD drivers/tty/ipwireless/built-in.o CC drivers/tty/serial/serial_core.o CC drivers/tty/serial/l4ser.o CC drivers/tty/serial/l4ser_shm.o LD drivers/tty/serial/built-in.o CC drivers/tty/vt/vt_ioctl.o CC drivers/tty/vt/vc_screen.o CC drivers/tty/vt/selection.o CC drivers/tty/vt/keyboard.o CC drivers/tty/vt/consolemap.o CC drivers/tty/vt/consolemap_deftbl.o CC drivers/tty/vt/vt.o CC drivers/tty/vt/defkeymap.o LD drivers/tty/vt/built-in.o LD drivers/tty/built-in.o LD drivers/video/backlight/built-in.o CC drivers/video/console/dummycon.o CC drivers/video/console/fbcon.o CC drivers/video/console/bitblit.o CC drivers/video/console/softcursor.o LD drivers/video/console/built-in.o CC drivers/video/fbdev/core/fb_cmdline.o CC drivers/video/fbdev/core/fb_notify.o CC drivers/video/fbdev/core/fbmem.o CC drivers/video/fbdev/core/fbmon.o CC drivers/video/fbdev/core/fbcmap.o CC drivers/video/fbdev/core/fbsysfs.o CC drivers/video/fbdev/core/modedb.o CC drivers/video/fbdev/core/fbcvt.o LD drivers/video/fbdev/core/fb.o LD drivers/video/fbdev/core/built-in.o LD drivers/video/fbdev/omap2/omapfb/displays/built-in.o LD drivers/video/fbdev/omap2/omapfb/dss/built-in.o LD drivers/video/fbdev/omap2/omapfb/built-in.o LD drivers/video/fbdev/omap2/built-in.o LD drivers/video/fbdev/built-in.o CC drivers/video/logo/logo.o LOGO drivers/video/logo/logo_linux_mono.c CC drivers/video/logo/logo_linux_mono.o LOGO drivers/video/logo/logo_linux_vga16.c CC drivers/video/logo/logo_linux_vga16.o LOGO drivers/video/logo/logo_linux_clut224.c CC drivers/video/logo/logo_linux_clut224.o LD drivers/video/logo/built-in.o LOGO drivers/video/logo/logo_superh_mono.c LOGO drivers/video/logo/clut_vga16.c LOGO drivers/video/logo/logo_blackfin_vga16.c LOGO drivers/video/logo/logo_superh_vga16.c LOGO drivers/video/logo/logo_blackfin_clut224.c LOGO drivers/video/logo/logo_dec_clut224.c LOGO drivers/video/logo/logo_m32r_clut224.c LOGO drivers/video/logo/logo_mac_clut224.c LOGO drivers/video/logo/logo_parisc_clut224.c LOGO drivers/video/logo/logo_sgi_clut224.c LOGO drivers/video/logo/logo_spe_clut224.c LOGO drivers/video/logo/logo_sun_clut224.c LOGO drivers/video/logo/logo_superh_clut224.c LD drivers/video/built-in.o LD drivers/built-in.o LD sound/built-in.o LD firmware/built-in.o CC arch/l4/drivers/vbus/l4vbus.o LD arch/l4/drivers/vbus/built-in.o CC arch/l4/drivers/events.o LD arch/l4/drivers/built-in.o CC net/socket.o LD net/802/built-in.o CC net/core/sock.o CC net/core/request_sock.o CC net/core/skbuff.o CC net/core/datagram.o CC net/core/stream.o CC net/core/scm.o CC net/core/gen_stats.o CC net/core/gen_estimator.o CC net/core/net_namespace.o CC net/core/secure_seq.o CC net/core/flow_dissector.o CC net/core/sysctl_net_core.o CC net/core/dev.o CC net/core/ethtool.o CC net/core/dev_addr_lists.o CC net/core/dst.o CC net/core/netevent.o CC net/core/neighbour.o CC net/core/rtnetlink.o CC net/core/utils.o CC net/core/link_watch.o CC net/core/filter.o CC net/core/sock_diag.o CC net/core/dev_ioctl.o CC net/core/tso.o CC net/core/sock_reuseport.o CC net/core/flow.o CC net/core/net-sysfs.o CC net/core/net-procfs.o LD net/core/built-in.o CC net/ethernet/eth.o LD net/ethernet/built-in.o CC net/ipv4/route.o CC net/ipv4/inetpeer.o CC net/ipv4/protocol.o CC net/ipv4/ip_input.o CC net/ipv4/ip_fragment.o CC net/ipv4/ip_forward.o CC net/ipv4/ip_options.o CC net/ipv4/ip_output.o CC net/ipv4/ip_sockglue.o CC net/ipv4/inet_hashtables.o CC net/ipv4/inet_timewait_sock.o CC net/ipv4/inet_connection_sock.o CC net/ipv4/tcp.o CC net/ipv4/tcp_input.o CC net/ipv4/tcp_output.o CC net/ipv4/tcp_timer.o CC net/ipv4/tcp_ipv4.o CC net/ipv4/tcp_minisocks.o CC net/ipv4/tcp_cong.o CC net/ipv4/tcp_metrics.o CC net/ipv4/tcp_fastopen.o CC net/ipv4/tcp_recovery.o CC net/ipv4/tcp_offload.o CC net/ipv4/datagram.o CC net/ipv4/raw.o CC net/ipv4/udp.o CC net/ipv4/udplite.o CC net/ipv4/udp_offload.o CC net/ipv4/arp.o CC net/ipv4/icmp.o CC net/ipv4/devinet.o CC net/ipv4/af_inet.o CC net/ipv4/igmp.o CC net/ipv4/fib_frontend.o CC net/ipv4/fib_semantics.o CC net/ipv4/fib_trie.o CC net/ipv4/inet_fragment.o CC net/ipv4/ping.o CC net/ipv4/ip_tunnel_core.o CC net/ipv4/gre_offload.o CC net/ipv4/sysctl_net_ipv4.o CC net/ipv4/proc.o CC net/ipv4/xfrm4_mode_beet.o CC net/ipv4/xfrm4_mode_transport.o CC net/ipv4/xfrm4_mode_tunnel.o CC net/ipv4/ipconfig.o CC net/ipv4/inet_diag.o CC net/ipv4/tcp_diag.o CC net/ipv4/tcp_cubic.o CC net/ipv4/xfrm4_policy.o CC net/ipv4/xfrm4_state.o CC net/ipv4/xfrm4_input.o CC net/ipv4/xfrm4_output.o CC net/ipv4/xfrm4_protocol.o LD net/ipv4/built-in.o CC net/ipv6/addrconf_core.o CC net/ipv6/exthdrs_core.o CC net/ipv6/ip6_checksum.o CC net/ipv6/ip6_icmp.o CC net/ipv6/output_core.o CC net/ipv6/protocol.o CC net/ipv6/ip6_offload.o CC net/ipv6/tcpv6_offload.o CC net/ipv6/exthdrs_offload.o LD net/ipv6/built-in.o CC net/netlink/af_netlink.o CC net/netlink/genetlink.o LD net/netlink/built-in.o CC net/packet/af_packet.o LD net/packet/built-in.o CC net/sched/sch_generic.o CC net/sched/sch_mq.o LD net/sched/built-in.o CC net/unix/af_unix.o CC net/unix/garbage.o CC net/unix/sysctl_net_unix.o LD net/unix/unix.o LD net/unix/built-in.o CC net/xfrm/xfrm_policy.o CC net/xfrm/xfrm_state.o CC net/xfrm/xfrm_hash.o CC net/xfrm/xfrm_input.o CC net/xfrm/xfrm_output.o CC net/xfrm/xfrm_sysctl.o CC net/xfrm/xfrm_replay.o LD net/xfrm/built-in.o CC net/sysctl_net.o LD net/built-in.o CC lib/lockref.o CC lib/bcd.o CC lib/div64.o CC lib/sort.o CC lib/parser.o CC lib/halfmd4.o CC lib/debug_locks.o CC lib/random32.o CC lib/bust_spinlocks.o CC lib/kasprintf.o CC lib/bitmap.o CC lib/scatterlist.o CC lib/gcd.o CC lib/lcm.o CC lib/list_sort.o CC lib/uuid.o CC lib/flex_array.o CC lib/iov_iter.o CC lib/clz_ctz.o CC lib/bsearch.o CC lib/find_bit.o CC lib/llist.o CC lib/memweight.o CC lib/kfifo.o CC lib/percpu-refcount.o CC lib/percpu_ida.o CC lib/rhashtable.o CC lib/reciprocal_div.o CC lib/once.o CC lib/string_helpers.o CC lib/hexdump.o CC lib/kstrtox.o CC lib/pci_iomap.o CC lib/iomap_copy.o CC lib/devres.o CC lib/hweight.o CC lib/bitrev.o CC lib/crc16.o HOSTCC lib/gen_crc32table GEN lib/crc32table.h CC lib/crc32.o CC lib/genalloc.o CC lib/fonts/fonts.o CC lib/fonts/font_8x8.o CC lib/fonts/font_8x16.o LD lib/fonts/font.o LD lib/fonts/built-in.o CC lib/lz4/lz4_decompress.o LD lib/lz4/built-in.o CC lib/lzo/lzo1x_decompress_safe.o LD lib/lzo/lzo_decompress.o LD lib/lzo/built-in.o CC lib/xz/xz_dec_syms.o CC lib/xz/xz_dec_stream.o CC lib/xz/xz_dec_lzma2.o CC lib/xz/xz_dec_bcj.o LD lib/xz/xz_dec.o LD lib/xz/built-in.o CC lib/zlib_inflate/inffast.o CC lib/zlib_inflate/inflate.o CC lib/zlib_inflate/infutil.o CC lib/zlib_inflate/inftrees.o CC lib/zlib_inflate/inflate_syms.o LD lib/zlib_inflate/zlib_inflate.o LD lib/zlib_inflate/built-in.o CC lib/swiotlb.o CC lib/iommu-helper.o CC lib/iommu-common.o CC lib/syscall.o CC lib/nlattr.o CC lib/dynamic_queue_limits.o CC lib/net_utils.o LD lib/built-in.o CC lib/argv_split.o CC lib/bug.o CC lib/cmdline.o CC lib/ctype.o CC lib/dec_and_lock.o CC lib/decompress.o CC lib/decompress_bunzip2.o CC lib/decompress_inflate.o CC lib/decompress_unlz4.o CC lib/decompress_unlzma.o CC lib/decompress_unlzo.o CC lib/decompress_unxz.o CC lib/dma-noop.o CC lib/dump_stack.o CC lib/earlycpio.o CC lib/extable.o CC lib/fdt.o CC lib/fdt_empty_tree.o CC lib/fdt_ro.o CC lib/fdt_rw.o CC lib/fdt_strerror.o CC lib/fdt_sw.o CC lib/fdt_wip.o CC lib/flex_proportions.o CC lib/idr.o CC lib/int_sqrt.o CC lib/ioremap.o CC lib/irq_regs.o CC lib/is_single_threaded.o CC lib/klist.o CC lib/kobject.o CC lib/kobject_uevent.o CC lib/md5.o CC lib/nmi_backtrace.o CC lib/nodemask.o CC lib/plist.o CC lib/radix-tree.o CC lib/ratelimit.o CC lib/rbtree.o CC lib/seq_buf.o CC lib/sha1.o CC lib/show_mem.o CC lib/string.o CC lib/timerqueue.o CC lib/vsprintf.o AR lib/lib.a CC arch/l4/lib/arch-arm/../proc.o CC arch/l4/lib/arch-arm/../debugfs.o LD arch/l4/lib/arch-arm/built-in.o AS arch/l4/lib/arch-arm/../../../arm/lib/ashldi3.o AS arch/l4/lib/arch-arm/../../../arm/lib/ashrdi3.o AS arch/l4/lib/arch-arm/../../../arm/lib/backtrace.o AS arch/l4/lib/arch-arm/../../../arm/lib/bswapsdi2.o AS arch/l4/lib/arch-arm/../../../arm/lib/call_with_stack.o AS arch/l4/lib/arch-arm/../../../arm/lib/changebit.o AS arch/l4/lib/arch-arm/../../../arm/lib/clearbit.o AS arch/l4/lib/arch-arm/../../../arm/lib/copy_page.o AS arch/l4/lib/arch-arm/../../../arm/lib/csumipv6.o AS arch/l4/lib/arch-arm/../../../arm/lib/csumpartial.o AS arch/l4/lib/arch-arm/../../../arm/lib/csumpartialcopy.o AS arch/l4/lib/arch-arm/../../../arm/lib/delay-loop.o CC arch/l4/lib/arch-arm/../../../arm/lib/delay.o AS arch/l4/lib/arch-arm/../../../arm/lib/div64.o AS arch/l4/lib/arch-arm/../../../arm/lib/findbit.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-readsb.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-readsl.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-readsw-armv4.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-writesb.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-writesl.o AS arch/l4/lib/arch-arm/../../../arm/lib/io-writesw-armv4.o AS arch/l4/lib/arch-arm/../../../arm/lib/lib1funcs.o AS arch/l4/lib/arch-arm/../../../arm/lib/lshrdi3.o AS arch/l4/lib/arch-arm/../../../arm/lib/memchr.o AS arch/l4/lib/arch-arm/../../../arm/lib/memcpy.o AS arch/l4/lib/arch-arm/../../../arm/lib/memmove.o AS arch/l4/lib/arch-arm/../../../arm/lib/memset.o AS arch/l4/lib/arch-arm/../../../arm/lib/memzero.o AS arch/l4/lib/arch-arm/../../../arm/lib/muldi3.o AS arch/l4/lib/arch-arm/../../../arm/lib/setbit.o AS arch/l4/lib/arch-arm/../../../arm/lib/strchr.o AS arch/l4/lib/arch-arm/../../../arm/lib/strrchr.o AS arch/l4/lib/arch-arm/../../../arm/lib/testchangebit.o AS arch/l4/lib/arch-arm/../../../arm/lib/testclearbit.o AS arch/l4/lib/arch-arm/../../../arm/lib/testsetbit.o AS arch/l4/lib/arch-arm/../../../arm/lib/ucmpdi2.o CC arch/l4/lib/arch-arm/../csumpartialcopyuser.o CC arch/l4/lib/arch-arm/../memcpy_user.o CC arch/l4/lib/arch-arm/../pte.o CC arch/l4/lib/arch-arm/../uaccess.o AR arch/l4/lib/arch-arm/lib.a LD arch/l4/l4lxlib/generic/built-in.o CC arch/l4/l4lxlib/generic/irq_gen.o CC arch/l4/l4lxlib/generic/legacy.o CC arch/l4/l4lxlib/generic/thread_gen.o AR arch/l4/l4lxlib/generic/lib.a LD arch/l4/l4lxlib/l4env/built-in.o CC arch/l4/l4lxlib/l4env/irq_vcpu.o CC arch/l4/l4lxlib/l4env/memory.o CC arch/l4/l4lxlib/l4env/misc.o CC arch/l4/l4lxlib/l4env/task.o CC arch/l4/l4lxlib/l4env/thread.o AR arch/l4/l4lxlib/l4env/lib.a LD virt/lib/built-in.o LD virt/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o drivers/built-in.o: In function `sdhci_at91_probe': /home/daniel/Desktop/l4re-snapshot/src/l4linux/build-arm/../drivers/mmc/host/sdhci-of-at91.c:212: undefined reference to `clk_set_rate' make[1]: *** [vmlinux] Error 1 make[1]: Leaving directory `/home/daniel/Desktop/l4re-snapshot/src/l4linux/build-arm' make: *** [sub-make] Error 2

5 19

I/O memory access and hardware page mappings
by Paul Boddie 26 Jul '17

26 Jul '17

Hello again, Having looked at the l4vbus_gpio functions and struggled with providing suitable devices, I decided to take the simpler approach and just ask for the I/O memory of the devices and access that directly. However, this didn't prove as straightforward as anticipated, either. The aim was to take the previously-mentioned device resources of the following form and to perform l4io_request_iomem (or l4io_request_resource_iomem) to get addresses of virtual regions corresponding to the different physical memory regions. PORTA = Hw.Device(function() Property.hid = "jz4780-gpio-PORTA"; Resource.regs = Res.mmio(0x10010000, 0x100100ff); ... end); PORTB = Hw.Device(function() Property.hid = "jz4780-gpio-PORTB"; Resource.regs = Res.mmio(0x10010100, 0x100101ff); ... end); ... PORTF = Hw.Device(function() Property.hid = "jz4780-gpio-PORTF"; Resource.regs = Res.mmio(0x10010500, 0x100105ff); ... end); It was indeed possible to obtain the resources involved with individual ports and also to obtain an address for each port region. However, accesses relative to these base addresses did not produce the expected results (LED output changes, switch input changes). (Looking at the virtual and physical regions in jdb suggested that the accesses were not being propagated, although I was also not successful in putting values into physical memory addresses and obtaining any of the expected results, either.) Now, I did wonder how such a small, 256-byte region mapping would actually work with my hardware. The JZ4780 does not support pages smaller than 4K when mapping memory, but I did notice that I do get an exception if trying to access beyond the end of the virtual region. (I found this out when considering that perhaps the virtual address might actually point to the base of the hardware page containing the region. So, I added a region offset to the base and tried to perform a memory access. Obviously, returning the hardware page address would be an unfortunate choice because it would oblige the API user to know about such things. Clearly, the API should return the address of the actual region, and maybe it does.) So, if this smaller-than-hardware page size is enforced, there must be a mechanism above the plain TLB mechanism that performs such enforcement. One interesting thing I noticed was that when requesting two different regions, the virtual addresses for the base of the regions were 4K apart, not 256 bytes apart. In any case, I was left wondering if any such mechanism might be preventing accesses from being correctly propagated. To simplify things a bit more, I then decided to just define the entire GPIO region in the device tree: GPIO = Hw.Device(function() Property.hid = "JZ4780 GPIO"; Resource.regs = Res.mmio(0x10010000, 0x100105ff); end); Requesting the memory for this device succeeds as before, but then performing accesses relative to the returned virtual address (with port F at vaddr + 0x500, for instance) also succeeds and produces the desired result, unlike before. So, what is this mechanism that handles accesses to regions that do not correspond to hardware pages (either in size or alignment)? Is there some kind of address-based trapping that redirects accesses to some kind of privately- allocated page that is then mapped to the hardware page concerned? Is it possible that this mechanism does not work on MIPS or on my specific device? I apologise if I should be answering my own questions by looking at the code or particular documentation resources. Paul

2 2

uImage Load Address Issue
by Daniel (Xiaolong) Wang 23 Jul '17

23 Jul '17

Hi All, I’m testing L4re on a customized I.MX6 Solo-X-4 board. I found that the fiasco kernel (the simple hello world example built into an uimage) cannot be load by the U-boot. It shows “data abort". The reason I guess it is due to different loading address. The U-boot’s default $loadaddr is 0x80800000, but the uimage I build using the L4re buildsystem has: Load Address: 11000000 Entry Point: 11000000 ==> Installing bootstrap.uimage in image directory Image size(s) in bytes: bootstrap_hello-cfg.elf: 1470844 bootstrap.raw: 1437696 bootstrap.uimage: 1437760 Start address: 0x11000000 I used the RAM_BASE=0x8080000 option to change the starting address when I made the image (as shown below), the boot did not crash but the kernel hangs at “Starting kernel..." Load Address: 01000000 Entry Point: 01000000 ==> Installing bootstrap.uimage in image directory Image size(s) in bytes: bootstrap_hello-cfg.elf: 1470844 bootstrap.raw: 1437696 bootstrap.uimage: 1437760 Start address: 0x801000000 I think it is still related to the different load address. But I do not know how to fix it. I would really appreciate if someone can point me to a right direction. Thanks -Dan

3 3

Obtaining and accessing device abstractions in L4Re
by Paul Boddie 22 Jul '17

22 Jul '17

Hello, I've been trying to write some drivers in L4Re, starting out with a GPIO driver for a currently-unsupported board, and I think I have mostly understood the concepts involved. Fortunately, there are already a couple of drivers to borrow ideas from... pkg/io/io/server/src/drivers/gpio/bcm2835.cc pkg/io/io/server/src/drivers/gpio/omap.cc And if I am not mistaken, such drivers can be accessed from other components by just doing something like this (testing for validity as we go): vbus = l4re_env_get_cap("vbus"); l4vbus_get_device_by_hid(vbus, 0, &gpio_handle, gpio_hid, 0, 0); l4vbus_gpio_set(vbus, gpio_handle, gpio_reg, value); It appears that if I just declare the device appropriately in my board's hw_devices.io file, I should be able to get a handle for it using code like the above. And all access can apparently be done via the l4vbus_gpio functions with this handle. (I was also wondering if it was possible to actually instantiate or obtain a device directly instead of obtaining a handle, for code written in C++, but the above is easily good enough at the moment.) But now I want to make another, non-GPIO, driver abstraction, instead of directly accessing the mapped memory regions concerned (which I see that some of the drivers do). It seems like I should be able to... * define a class for the abstraction inheriting from Hw::Device * declare the device in hw_devices.io using this class * provide various properties in the hw_devices.io declaration (for configuration purposes) * read the properties in the actual class implementation * access registers in memory just as the GPIO drivers do I think I can muddle through all this. But how should another component access methods provided by this driver? Do I have to implement functionality like that provided by the following files...? pkg/io/libvbus/lib/src/vbus_gpio.cc pkg/io/libvbus/include/vbus_gpio-ops.h pkg/io/io/server/src/virt/gpio/vgpio.cc Does any of this make any sense? :-) I'm just getting started here, but thanks are due in advance for any advice anyone may have! Paul

2 3

Booting L4Re on the CI20: Panic in sigma0
by Paul Boddie 21 Jul '17

21 Jul '17

Hello, I've been trying to get Fiasco.OC and L4Re booting on the MIPS Creator CI20, starting out by building the "hello" example. The first obstacle was actually seeing the serial output, where the board appears to be configured to output to UART4 in the bootstrap package, but booting from an SD card produced no output. Although I thought I had messed up the preparation of the image, or that U-Boot was being fussy about the image addresses and failing to execute the payload, switching to UART0 and rewiring my connection got me some output. For reference, changing the UART involves a couple of modifications to pkg/bootstrap/server/src/platform/ci20.cc as follows: - kuart.base_address = 0x10034000; // UART4 + kuart.base_address = 0x10030000; // UART0 - kuart.irqno = 34; + kuart.irqno = 51; // UART0: 32 + 19 But now I appear to experience a panic in sigma0 as it starts up, with the message... Warning: Sigma0 raised an exception --> HALT Here are the regions: Regions of list 'regions' [ 0, 1db] { 1dc} Kern fiasco [ 1000, 10eb] { ec} Root mbi_rt [ 10000, 9d09f] { 8d0a0} Kern fiasco [ 140000, 184773] { 44774} Root moe [ 190000, 197f3f] { 7f40} Root moe [ 200000, 20be17] { be18} Sigma0 sigma0 [ 210000, 2161bf] { 61c0} Sigma0 sigma0 [ 2d0000, 2e33df] { 133e0} Boot bootstrap [ 1100000, 1164fff] { 65000} Root Module And the registers look like this: 00[ 0]: 00000000 at[ 1]: 80022e50 v0[ 2]: 00000001 v1[ 3]: 80000000 a0[ 4]: 00010000 a1[ 5]: 002000e0 a2[ 6]: ffffffe7 a3[ 7]: 00000401 t0[ 8]: 00000000 t1[ 9]: 00000401 t2[10]: 00000413 t3[11]: 82152f38 t4[12]: 82152000 t5[13]: 801873bc t6[14]: fffffffe t7[15]: 801873bc s0[16]: 82152f60 s1[17]: 00000400 s2[18]: 00000001 s3[19]: 00000000 s4[20]: 80090000 s5[21]: 00000000 s6[22]: 00000fa0 s7[23]: 00000000 t8[24]: 8008519c t9[25]: 800a0000 k0[26]: ffffffff k1[27]: ffffffff gp[28]: 800b7f80 sp[29]: 00000000 fp[30]: 80185000 ra[31]: 80010000 HI: 00000000 LO: 000003a8 Status 00000413 Cause 00000010 EPC 002000ec The EPC indeed appears to reference sigma0, with the Cause indicating an erroneous data or instruction fetch operation. Looking at the disassembly of sigma0... 002000e0 <__start>: 2000e0: 3c1c0001 lui gp,0x1 2000e4: 279c7f80 addiu gp,gp,32640 2000e8: 0399e021 addu gp,gp,t9 2000ec: 8f9d8018 lw sp,-32744(gp) 2000f0: 8f99801c lw t9,-32740(gp) 2000f4: 27bdfff0 addiu sp,sp,-16 2000f8: 0320f809 jalr t9 2000fc: 00000000 nop ...it appears that the problem occurs when the global offset table is accessed. The global pointer gets computed as... 0x10000 + 32640 + 0x800a0000 = 0x800b7f80 ...with the load-relative operation accessing... 0x800b7f80 - 32744 = 0x800aff98 It is presumably this address that is illegal within the failing thread of execution. I've been looking at the debugger documentation... http://l4re.org/fiasco/doc/jdb.pdf ...but I'm not sure I'm doing the right things to see the state of the machine. Attempting to dump the memory at that address appears to indicate inaccessible memory, but I imagine that this region might not be mapped within whichever "task" is active. Does anyone have any suggestions about how I can troubleshoot this problem? Thanks in advance, Paul

3 12

Open a shell for a an individual task
by Hennebold, Christoph 08 Jul '17

08 Jul '17

Hello, I'am trying to write an interactive client/server system which consists of a client component that runs its own shell, and the corresponding server which provides various interfaces. I was wondering if it is possible to spawn a shell for the client during the initialization with Ned or if it is possible at all? (Besides running Ned in interactive mode) Best regards!

2 2

Re: Define Addr. Space of Task
by ba_f 08 Jul '17

08 Jul '17

Hello again, this topic is still open. So, how can I link a Task to a specific address space? > Hi Adam, > > >> Linking a program to a specific location is well possible. >> However, the extra memory region is not part of the normal RAM but an >> extra piece of memory? How is it accessed? And how big is it? >> >> Adam > > > Yes, the secure ram is separate from the ordinary DRAM. > But, access to it is address based via ARM AXI. > > My design has a trusted L4re-App. > And i want to link the trusted app alone to the secure ram. > I argue that ordinary DRAM is easy to read out for an attacker that has > local access to the platform. > The secure ram is less easy to read-out, so the trusted app would be > more secure. > > > > > Greets, > > ba_f Thank you, ba_f

2 1

L4Re IPC share memory that share file in one Linux filesystem and be visible to other Linuxes
by Joyce Peng(彭美僑) 07 Jul '17

07 Jul '17

Hi L4, I want to share a file in one Linux filesystem and be visible to other Linuxes that all run on top Fiasco.OC. It seems an IPC communication between L4re vm tasks. And access a file in Linux filesystem is a mechanism of kernel block device driver. But I only notice two char device drivers that use L4re library l4shmc in L4linux. It is l4ser_shm and l4shmnet. May you give some information about this work how to work. Thanks. Joyce.peng(彭美僑)

2 3

Unit testing guidelines or resource
by jrodriguez＠uns.edu.ar 05 Jul '17

05 Jul '17

Hi L4 team, I'm looking forward for information about existent or recommended methodology to perform systematic test on single fiasco component or L4Re service. From what I see, there is not other option than running on qemu or target host. What I would really like is to get sort of fiasco&L4Re mock to be able to run systematic unit test on user level app but on my PC (avoiding the emulator). Any recommendation on this regard? Thought about fiasco UX, but not sure if that feature is still maintained. And if I jump into the complex task of designing this mock, any recommendation about l4re service which is more "isolated" from microkernel to take it as initial use case for such development? Well that's all by now. Thanks in advance for any feedback Best Agustin

2 1

Problem with L4re and L4Linux on Qemu/VMware
by Daniel (Xiaolong) Wang 27 Jun '17

27 Jun '17

Hi all, I’m sorry to bother, again… But I keep getting problems hope you can give me some advice. I’m trying to test out L4re +L4Linux on X86 and ARM i.MX6. I downloaded the newest l4re-snapshot-2006082114. I built Fiasco with Intel Pentium Pro and Virtualization (did not change anything else). I built L4re with Pentium Pro type CPU (everything else are default settings). Then I built L4Linux with the L4re builddir. I turned off 64-bit kernel, CPU selected Pentium-Pro, turned off most of the settings as the warning instructed. These are the settings of L4Linux that I enabled: Processor type and features: * DMA memory allocation support * Processor feature human-readable name * Fast CPU feature tests * Support for extended X86 platform * Single-depth WCHAN output * High memory support is OFF * Enable bounce buffers * X86 architectural random number generator * Enable seccomp to safety compute untrusted bytecode * Enable the LDT Power Management and ACPI options: * Suspend to RAM and standby * device power management core functionality * CPU Frequency scaling is OFF Bus Options: * PCI support * PCI access mode is Direct I was able to compile all three parts and build both iso image (for vmware fusion on macOS) and qemu simulator. I first tested hello, hello-cfg, hello-shared, frame buffer-example-x86, all of those works as expected. However when I tried to build L4Linux-basic and L4Linux-mag-x86. Not of them works. for L4Linux-mag-x86 the system shows a diagram “system is booting” then hang forever. for L4Linux-basic the image boot but freeze soon. The screen shows: l4cdds: No name given, not starting brd: module loaded l4cdds: no name given, not starting moused: ps/2 mouse device common for all mice l4x: Faking dummy RTC rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos rtc_cmos: only 24-hr supported rtc_l4x: l4x-rtc: Could not find ‘rtc’ cap rtc_l4x: probe of rtc-l4x failed with error -2 NET: Registered protocol family 17 L4IRQ: set irq type of 64 to 1 RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 3072KiB [1 disk] into ram disk… done. VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing unused kernel memory 188K (00494000 - 004c3000) Write protecting the kernel text: 2684K Write protecting the kernel read-only data 768k rodata_test: test data was not read only Please press Enter to activate this console. clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2845e81c5f6, max-idle_ns: 440795276432 ns clocksource: Switched to clocksource tsc Initially I thought it might related RTC so I checked out all Real time clock in L4Linux, but it still the same. Any help would be appreciated. Thanks -Dan

3 8

IRQ objects
by David Werner 23 Jun '17

23 Jun '17

Hi L4-hackers, i am currently working on a checkpoint/restore component (for the Genode framework) which aims at the migration of processes/components. When I first start the target component of the checkpointer, its object looks like this: 000204 :0016e* Gate 0015f* Gate 00158* Gate 00152* Gate 000208 :00154* Gate 0017e* Gate 0017f* Gate 00179* Gate 00020c :00180* Gate 00188* Gate -- -- 000210 : -- -- 0018a* Gate 0018c* Gate 000214 :0018e* Gate 00196* Gate 00145* Gate 00144* IRQ 000218 :00198* Gate -- -- -- 00021c : -- 0019c* Gate -- -- At position 000217 is an IRQ object which is used for signaling. I would like to know if this IRQ object carries any information which I need to store in order to recreate a new IRQ object for the restarted component. If you are interested in more context you can take a look at: https://sourceforge.net/p/genode/mailman/message/35904942/ Kind Regards, David Werner

2 1

L4re and L4Linux Compatible issue
by Daniel (Xiaolong) Wang 21 Jun '17

21 Jun '17

Hi all, I’m trying to use L4re to run L4linux. I successfully built the fiasco kernel and l4re with the default setting from the newest l4re-snapshot. However when I try to build L4linux it shows it shows: “ld: skipping incompatible /home/daniel/Desktop/l4re-snapshot/src/l4/builddir/lib/x86_pentium4/l4f/libl4sys-direct.a when searching for -ll4sys-direct” "ld: skipping incompatible /home/daniel/Desktop/l4re-snapshot/src/l4/builddir/lib/x86_pentium4/l4f/libl4sys.a when searching for -ll4sys" "ld: cannot find -ll4sys” I assume it is the platform of L4re I built is not compatible with the L4Linux settings. I built L4re for x86_586 and x86_pentium4. My question is that is there a compatible X86 CPU platform the works for both L4re and L4Linux? Should I built AMD64 instead? Thanks -Dan

2 2

L4re with L4Linux
by Daniel (Xiaolong) Wang 20 Jun '17

20 Jun '17

Hi all, I’m new to L4re. I would like to use L4re as a microvisor and run L4linux VM. Is there any tutorial shows how to build the system like that? Thanks -Dan

1 0

Re: l4linux: l4x_setup_memory:Cant get main memory
by Leslie Zhai 09 Jun '17

09 Jun '17

Hi Adam, Thanks for your hint! > Hm, tried adding more memory to the VM? Perhaps other users might experienced the same issue: L4x: Main thread running, waiting... L4x: Memory size: 64MB L4x: Setting superpages for main memory l4x_setup_memory: Can't get main memory of 65536kiB! Please try to add more memory to the VM. MOE[mem_alloc]: quota: limit=-1 Byte, used=9646080 Byte MOE[mem_alloc]: global: avail=52121376 Byte MOE[mem_alloc]: free list (start address/size): MOE[mem_alloc]: 0x210e0 - 0x213ff (800 Byte) MOE[mem_alloc]: 0x273400 - 0x273fff (3 kB) MOE[mem_alloc]: 0x370000 - 0x3fffff (576 kB) MOE[mem_alloc]: 0xba6000 - 0x18aafff (13 MB) MOE[mem_alloc]: 0x541a000 - 0x7838fff (36 MB) Terminating L4Linux. so I simply added "Please try to add more memory to the VM." Index: arch/l4/kernel/main.c =================================================================== --- arch/l4/kernel/main.c (revision 54) +++ arch/l4/kernel/main.c (working copy) @@ -1384,7 +1384,8 @@ if (l4re_ma_alloc_align(mem_chunk_sz[i], l4x_ds_mainmem[i], f, virt_phys_alignment)) { - LOG_printf("%s: Can't get main memory of %ldkiB!\n", + LOG_printf("%s: Can't get main memory of %ldkiB! Please try to " + "add more memory to the VM.\n", __func__, mem_chunk_sz[i] >> 10); l4re_debug_obj_debug(l4re_env()->mem_alloc, 0); l4x_exit_l4linux(); then users might realized that using qemu-system-x86_64 -m 1024M to launch L4Linux-mag-x86, and L4Linux is able to run happily :) https://pbs.twimg.com/media/DB3YY0zVwAA9CM9.png sorry for posting screenshots on Twitter but I am so happy! so excited! and my sincere thank goes to you and Jean! you are teaching me patiently and carefully :) -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: Fiasco.OC: null-pointer dereference?
by Leslie Zhai 09 Jun '17

09 Jun '17

Hi Jean, Thanks for your help! 在 2017年06月09日 00:53, Jean Wolter 写道: > On 08/06/17 04:18, Leslie Zhai wrote: >> Hi Matthias, >> >> Jean taught me about how to debug L4Re using jdb in qemu >> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008038.html it >> used a on purpose bug (null ptr deref) to crash Ned, then L4Re >> thrown: unhandled write page fault at 0x0 pc=0x100398d, and addr2line >> ... -e ned -a 100398d to indicate the root cause line. >> >> But how to find out the root cause if unclear that which components >> bring in the issue? > > I think there might be a misunderstanding. I only introduced the null > pointer dereference to demonstrate how to do it using a known problem. > You can apply exactly the same steps in a different situation. I just want to express the ('on purpose' is misuse, sorry for my poor English) debug patch is a demo to guide me how to debug with jdb in the qemu :) you are my mentor teaching me patiently and carefully! > > But I would like to add something. You actually had all the > information you needed: > > MOE: loading 'rom/ned' > Ned says: Hi World! > [1] 0 pf: 0022 pfa=0000000000000018 ip=fffffffff0031ea9 (R-) > spc=0xffffffff807c3dd > [2] L4Re[rm]: unhandled read page fault at 0x18 pc=0x102e893 > [3] L4Re: unhandled exception: pc=0xfffffffff0031ea9 (pfa=18) > L4Re: Global::l4re_aux->ldr_flags=0 > > > In [2] you see the message from the local pager, that is unable to > find a valid region for the pagefault address and complains. It shows > the 0x18 as pagefault address and an instruction pointer 0x102e893. > The instruction pointer did not make any sense at that time. The local > pager triggers an exception. > > In [3] you see the exception message. It shows the instruction pointer > where the pagefault was actually raised: 0xfffffffff0031ea9. This is > an address inside the kernel: That is the key point! it is magic to me that 0xfffffffff0031ea9 is an address inside the kernel, I need to deepinto Fiasco about address space, correct? > ~/build/tmp/l4re$ addr2line -p -i -e > ../leslie/fiasco/build/fiasco.image -a fffffffff0031ea9 > 0xfffffffff0031ea9: > /home/zhaixiang/project/l4re/kernel/fiasco/src/drivers/amd64/processor-amd64.cpp:67 > ... > (inlined by) > /home/zhaixiang/project/l4re/kernel/fiasco/src/kern/ram_quota.cpp:53 > > /home/zhaixiang/project/l4re/kernel/fiasco/src/drivers/amd64/processor-amd64.cpp:67 > fffffffff0031ea8: fa cli > fffffffff0031ea9: 48 8b 47 18 mov 0x18(%rdi),%rax > fffffffff0031ead: 48 03 77 10 add 0x10(%rdi),%rsi > _ZN9Ram_quota5allocEl(): > /home/zhaixiang/project/l4re/kernel/fiasco/src/kern/ram_quota.cpp:54 > > If it is not a kernel fault and you need to find out, which component > is responsible (or need more information about the current state) you > can press 'i' when line [0] appears. You enter the kernel debugger and > can look at the current thread using t<enter>. The thread has an id, > which you can lookup in the list of present threads (using 'lp'). Here > it is thread 22: > > id cpu name pr sp wait to stack state > 2e 0 ----- 2 1e - ( 920) rcv_wait > 2b 0 ----- 10 1e - (1072) rcv_wait > 22 0 ----- 2 1e (1776) ready > 1f 0 #ned ff 1e - (1072) > ready,rcv_wait > > All threads shown here have the same address space and therefore the > problem happened in the context of ned. > >> >> The same story is how to debug L4Linux? >> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008047.html >> please give me some advice, thanks a lot! >> > Maybe you can add "-serial stdio" to your qemu options and provide the > complete backtrace for the problem? It looks like a framebuffer issue, > but there should be more information in the lines above ... I will try instead of posting screenshots on Twitter, sorry for my posting! > > regards, > Jean > -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: About l4linux debug method
by Leslie Zhai 08 Jun '17

08 Jun '17

Hi L4 hackers, > fiasco r72 applied 0001-Fix-invalid-initialization-in-new.patchhttp://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html l4re r72 and l4linux r54 is not able to workhttps://pbs.twimg.com/media/DBtVv8zXoAAelwt.png <https://pbs.twimg.com/media/DBtVv8zXoAAelwt.png> l4linux-build can be downloaded here https://drive.google.com/open?id=0ByE8c-y74l_uTmtYVnVIbHdRZ0k -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

2 1

Re: Fiasco.OC: null-pointer dereference?
by Leslie Zhai 08 Jun '17

08 Jun '17

Hi Matthias, Thank you so much for your pretty cool 0001-Fix-invalid-initialization-in-new.patch http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html Jean taught me about how to debug L4Re using jdb in qemu http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008038.html it used a on purpose bug (null ptr deref) to crash Ned, then L4Re thrown: unhandled write page fault at 0x0 pc=0x100398d, and addr2line ... -e ned -a 100398d to indicate the root cause line. But how to find out the root cause if unclear that which components bring in the issue? just like Jean investigated why framebuffer-example-x86 failed to work, actually it is not init process issue, but Fiasco `_quota` member of a thread is not correctly initialized. 0001-Fix-invalid-initialization-in-new.patch is awesome! how to debug deepinto it? it might be easy to a maintainer of Fiasco kernel, but it is really magic to me :) The same story is how to debug L4Linux? http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008047.html please give me some advice, thanks a lot! -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: About l4linux debug method
by Leslie Zhai 07 Jun '17

07 Jun '17

Hi L4 hackers, But how to debug L4Linux in qemu by jdb? please give me some hints, thanks a lot! fiasco r72 applied 0001-Fix-invalid-initialization-in-new.patch http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html l4re r72 and l4linux r54 is not able to work https://pbs.twimg.com/media/DBtVv8zXoAAelwt.png -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: Graphical desktop, l4con, mag
by Leslie Zhai 07 Jun '17

07 Jun '17

Hi Jean, Happy holiday :) 在 2017年06月05日 23:43, Jean Wolter 写道: > Hello Leslie, > > today are public holidays in Germany, so I will try to follow up on > the issue tomorrow. I downloaded your binaries and am able to > reproduce the problem. It appears to be a problem with the fiasco > build. When I use my fiasco image build with gcc 4.9 l4/build/.config GCCDIR=/usr/lib/gcc/x86_64-redhat-linux/6.3.1 ... > the systems boots. When I use your fiasco image it triggers the > pagefault shown in your screen shots. > > There are some warnings in the boot sequence with your kernel: > "Warning: Buddy::alloc: Size mismatch: e58 v 1000" ... fiasco/build/globalconfig.out # CONFIG_AMD64_K8 is not set # CONFIG_AMD64_CORE2 is not set CONFIG_AMD64_CORE_I=y l4/build/.config CONFIG_BUILD_ARCH="amd64" CONFIG_BUILD_ARCH_amd64=y CONFIG_CPU="K8" CONFIG_CPU_X86_K8=y does it mean this mismatch? but when I rebuilt fiasco with CONFIG_AMD64_K8=y # CONFIG_AMD64_CORE2 is not set # CONFIG_AMD64_CORE_I is not set the same story so I need to go deeper into fiasco/kern/buddy_alloc.cpp > > > regards, > > Jean > > -- Regards, Leslie Zhai - a LLVM hackerhttps://reviews.llvm.org/p/xiangzhai/

2 2

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

06 Jun '17

Dear Rui, ご回答有難うございます！ > I believe the LLD's linker script is now fairly decent that you can expect it should work in most cases. -- Regards, Leslie Zhai https://reviews.llvm.org/p/xiangzhai/

1 0

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

Re: Graphical desktop, l4con, mag
by Leslie Zhai 05 Jun '17

05 Jun '17

在 2017年06月03日 04:56, Jean Wolter 写道: > Hello Leslie, > > On 02/06/17 11:33, Jean Wolter wrote: >> I replaced my "ned" binary with yours and the system boots up fine. >> >> Now I wonder how I could reproduce your problem. It looks like I >> >> * either need all binaries or >> * need to build them the same way you are building them. I used a >> fresh checkout from the svn repositories and use gcc version >> 4.9.2 (Debian 4.9.2-10) to build the components. >> > > Since I neither have your binaries nor know how you build them https://drive.google.com/open?id=0ByE8c-y74l_uLUdKWG9NWndnSUk and https://drive.google.com/open?id=0ByE8c-y74l_udUtJOTZvc3BycG8 > I thought about how you could diagnose the problem further. To > demonstrate how to do this I intentionally added a null pointer > dereference to ned and would like to discuss how I would diagnose this. > > --- ned/server/src/main.cc (revision 72) > +++ ned/server/src/main.cc (working copy) > @@ -35,6 +35,8 @@ > Dbg::set_level(Dbg::Warn); > info.printf("Hello from Ned\n"); > > + *(int *)0 = 0; > + > boot_info.printf("cmdline: "); > for (int i = 0; i < argc; ++i) > boot_info.cprintf("%s ", argv[i]); > > 1. Add -serial_esc -wait to kernel options in conf/modules.list > > --- modules.list (revision 72) > +++ modules.list (working copy) > @@ -80,6 +80,7 @@ > module libuc_c.so > > entry framebuffer-example-x86 > +kernel fiasco -serial_esc -wait > roottask moe rom/x86-fb.cfg > module x86-fb.cfg > module l4re > > If you boot this the kernel will enter the kernel debugger before > doing anything else. Enter the following commands: > > * P+ /* show every pagefault before forwarding it to the pager */ > * Prx0<space>100<space> /* restrict pagefault logging to pagefaults > between [0-100] */. > * g /* go */ > > The kernel should stop when the access to 0x18 happens, then you can > enter the kernel debugger using 'i' and can check who is responsible > and maybe get a correct instruction pointer. If I do this here it > looks like follows (I added -serial stdio to the qemu options): > > qemu-system-x86_64 -kernel > /home/jw5/build/tmp/l4re/bin/amd64_K8/bootstrap -append "bootstrap > -modaddr 0x01100000" -serial stdio -initrd > "/home/jw5/build/tmp/fiasco//fiasco -serial_esc > -wait,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/sigma0 > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/moe > rom/x86-fb.cfg,/home/jw5/src/l4resvn/src/l4/conf/examples//x86-fb.cfg > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/l4re > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/ned > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/io > ,/home/jw5/src/l4resvn/src/l4/pkg/io/io/config//x86-legacy.devs > ,/home/jw5/src/l4resvn/src/l4/conf/examples//x86-fb.io > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/fb-drv > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/mag > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/ex_fb_spectrum_cc " > ... > Freeing init code/data: 49152 bytes (12 pages) > > Calibrating timer loop... done. > > --------------------------------------------------------------------- > CPU 0 [fffffffff003df99]: Wait > jdb: P+ > PF logging enabled > jdb: Pr restrict to addr in [0-100] /* pressed > Prx0<space>100<space> */ > PF logging enabled, restricted to 0000000000000000 <= pfa <= > 0000000000000100 > jdb: g /* g does no show up in output */ > ... > MOE: cmdline: /home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/moe rom/x86-fb.cfg > MOE: Starting: rom/ned rom/x86-fb.cfg > MOE: loading 'rom/ned' > pf: 0022 pfa=0000000000000000 ip=00000000010038a2 (w-) > spc=0xffffffff807c3dd8 > /* press i */ > --------------------------------------------------------------------- > CPU 0 [fffffffff0062116]: LOG > jdb: > > Now you can use the kernel debugger to inspect the current state of > the system. Here I simply use addr2line to find the error: > > addr2line -p -i -e bin/amd64_K8/l4f/ned -a 10038a2 > 0x00000000010038a2: > /home/jw5/src/l4resvn/src/l4/pkg/l4re-core/ned/server/src/main.cc:38 > (inlined by) > /home/jw5/src/l4resvn/src/l4/pkg/l4re-core/ned/server/src/main.cc:77 > > > Line 38 is the line with the null pointer dereference. > > I hope this helps, > Jean > > > -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: Graphical desktop, l4con, mag
by Leslie Zhai 05 Jun '17

05 Jun '17

在 2017年06月03日 04:56, Jean Wolter 写道: > Hello Leslie, > > On 02/06/17 11:33, Jean Wolter wrote: >> I replaced my "ned" binary with yours and the system boots up fine. >> >> Now I wonder how I could reproduce your problem. It looks like I >> >> * either need all binaries or >> * need to build them the same way you are building them. I used a >> fresh checkout from the svn repositories and use gcc version >> 4.9.2 (Debian 4.9.2-10) to build the components. >> > > Since I neither have your binaries nor know how you build them I > thought about how you could diagnose the problem further. To > demonstrate how to do this I intentionally added a null pointer > dereference to ned and would like to discuss how I would diagnose this. > > --- ned/server/src/main.cc (revision 72) > +++ ned/server/src/main.cc (working copy) > @@ -35,6 +35,8 @@ > Dbg::set_level(Dbg::Warn); > info.printf("Hello from Ned\n"); > > + *(int *)0 = 0; > + > boot_info.printf("cmdline: "); > for (int i = 0; i < argc; ++i) > boot_info.cprintf("%s ", argv[i]); > > 1. Add -serial_esc -wait to kernel options in conf/modules.list > > --- modules.list (revision 72) > +++ modules.list (working copy) > @@ -80,6 +80,7 @@ > module libuc_c.so > > entry framebuffer-example-x86 > +kernel fiasco -serial_esc -wait > roottask moe rom/x86-fb.cfg > module x86-fb.cfg > module l4re > > If you boot this the kernel will enter the kernel debugger before > doing anything else. Enter the following commands: > > * P+ /* show every pagefault before forwarding it to the pager */ > * Prx0<space>100<space> /* restrict pagefault logging to pagefaults > between [0-100] */. > * g /* go */ > > The kernel should stop when the access to 0x18 happens, then you can > enter the kernel debugger using 'i' and can check who is responsible > and maybe get a correct instruction pointer. If I do this here it > looks like follows (I added -serial stdio to the qemu options): > > qemu-system-x86_64 -kernel > /home/jw5/build/tmp/l4re/bin/amd64_K8/bootstrap -append "bootstrap > -modaddr 0x01100000" -serial stdio -initrd > "/home/jw5/build/tmp/fiasco//fiasco -serial_esc > -wait,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/sigma0 > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/moe > rom/x86-fb.cfg,/home/jw5/src/l4resvn/src/l4/conf/examples//x86-fb.cfg > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/l4re > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/ned > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/io > ,/home/jw5/src/l4resvn/src/l4/pkg/io/io/config//x86-legacy.devs > ,/home/jw5/src/l4resvn/src/l4/conf/examples//x86-fb.io > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/fb-drv > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/mag > ,/home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/ex_fb_spectrum_cc " > ... > Freeing init code/data: 49152 bytes (12 pages) > > Calibrating timer loop... done. > > --------------------------------------------------------------------- > CPU 0 [fffffffff003df99]: Wait > jdb: P+ > PF logging enabled > jdb: Pr restrict to addr in [0-100] /* pressed > Prx0<space>100<space> */ > PF logging enabled, restricted to 0000000000000000 <= pfa <= > 0000000000000100 > jdb: g /* g does no show up in output */ > ... > MOE: cmdline: /home/jw5/build/tmp/l4re/bin/amd64_K8/l4f/moe rom/x86-fb.cfg > MOE: Starting: rom/ned rom/x86-fb.cfg > MOE: loading 'rom/ned' > pf: 0022 pfa=0000000000000000 ip=00000000010038a2 (w-) > spc=0xffffffff807c3dd8 > /* press i */ > --------------------------------------------------------------------- > CPU 0 [fffffffff0062116]: LOG > jdb: > > Now you can use the kernel debugger to inspect the current state of > the system. Here I simply use addr2line to find the error: > > addr2line -p -i -e bin/amd64_K8/l4f/ned -a 10038a2 > 0x00000000010038a2: > /home/jw5/src/l4resvn/src/l4/pkg/l4re-core/ned/server/src/main.cc:38 > (inlined by) > /home/jw5/src/l4resvn/src/l4/pkg/l4re-core/ned/server/src/main.cc:77 > > > Line 38 is the line with the null pointer dereference. Thanks for your help! worked :) addr2line -p -i -e bin/amd64_K8/l4f/ned -a 100398d 0x000000000100398d: /home/zhaixiang/project/l4re/l4/pkg/l4re-core/ned/server/src/main.cc:38 (inlined by) /home/zhaixiang/project/l4re/l4/pkg/l4re-core/ned/server/src/main.cc:77 and I need to carefully read JDB manual. > > I hope this helps, > Jean > > > -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 1

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