- l4-hackers - example.com Site

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 07 Dec '20

07 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 31 Jul '20

31 Jul '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 13 Jul '20

13 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 28 Mar '20

28 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