- l4-hackers - example.com Site

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