l4-hackers

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

2 participants
2880 discussions

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

← Newer
1
...
6
7
8
9
10
11
12
...
288
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers