- l4-hackers - example.com Site

Porting Fiasco + L4Re to Raspberry Pi 2
by Antoine DEBUT 26 Nov '17

26 Nov '17

Hello l4-hackers, I am currently working on porting the Fiasco.OC micro kernel onto the Raspberry pi 2. Therefore, I am struggling with memory mapping, and I encounter the following error when launching the default 'hello' entry: L4 Bootstrapper Build: #2 Tue Feb 23 11:57:19 CET 2016, 4.8.3 20140303 (prerelease) Scanning up to 1024 MB RAM, starting at offset 32MB Memory size is 1024MB (00000000 - 3fffffff) RAM: 0000000000000000 - 000000003fffffff: 1048576kB Total RAM: 1024MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 1100000 moving module 02 { 10db000-110c4d7 } -> { 11cc000-11fd4d7 } [201944] moving module 01 { 10c9000-10da373 } -> { 11ba000-11cb373 } [70516] moving module 00 { 1043000-10c889f } -> { 1134000-11b989f } [546976] moving module 04 { 1029000-10425af } -> { 111a000-11335af } [103856] moving module 03 { 100f000-102849b } -> { 1100000-111949b } [103580] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x2000 Regions of list 'regions' [ 1000, 1aff] { b00} Kern fiasco [ 2000, 92fff] { 91000} Kern fiasco [ 93000, 930eb] { ec} Root mbi_rt [ c0000, c9c33] { 9c34} Sigma0 sigma0 [ d0000, d6177] { 6178} Sigma0 sigma0 [ 140000, 16905b] { 2905c} Root moe [ 170000, 17b58b] { b58c} Root moe [ 1000000, 100e4ff] { e500} Boot bootstrap [ 1100000, 1133fff] { 34000} Root Module API Version: (87) experimental Sigma0 config ip:000c0100 sp:00000000 Roottask config ip:00140250 sp:00000000 Starting kernel fiasco at 000012b8 Non-HYP kernel detected but running in HYP mode, switching back. Hello from Startup::stage2 Assertion failed at /home/adebut/Documents/snapshotTest/l4re-snapshot-2015123115/src/kernel/fiasco/src/kern/buddy_alloc.cpp:101: (unsigned long)block >= _base Press any key to reboot. I am currently working on the latest snapshot (2015123115), with U-Boot as a bootloader, and testing on a real board (Raspberry Pi 2 model B V1.1). The entry built is the standard 'hello', and I use the ramdisk-arm.rd given in the snapshot. I did add a custom Bsp for the board, mainly based on the first Raspberry Pi except for the Base Address, that is 0x3F000000 instead of the first Pi's 0x20000000. I highly think that it is an address configuration problem, because it first happened when I did expand the RAM size to 1024MB. With further investigation, I found out that it was the kernel memory allocation that causes this error, and suspect an incorrect MMU mapping. This suspicion comes from the fact that the assertion takes the address _base (0xf0400000) and the currently allocated block (0xee100000). I did not modify any parameter in the kern/arm/mem_layout-arm.cpp file on the Fiasco directory, which provides the default ARM addressing. Maybe that's where my error comes from ? How can I correctly configure my memory mapping, besides what I already configure in the Bsp (given in attachment) ? Also, it is the first time that I am assigned for porting a system, do you have some hints, like important steps to follow ? I am pretty sure it is a newbie error, but I cannot figure it out for now :( Thanks in advance for your time, -- Antoine Debut EPITA 2016 - GISTRE

3 7

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

20 Nov '17

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

2 1

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

01 Nov '17

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

3 4

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

01 Nov '17

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

3 13

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

27 Oct '17

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

5 7

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

09 Oct '17

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

1 0

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

23 Sep '17

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

2 2

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

19 Aug '17

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

5 19

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

26 Jul '17

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

2 2

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

23 Jul '17

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

3 3

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

22 Jul '17

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

2 3

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

21 Jul '17

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

3 12

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

08 Jul '17

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

2 2

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

08 Jul '17

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

2 1

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

07 Jul '17

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

2 3

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

05 Jul '17

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

2 1

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

27 Jun '17

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

3 8

IRQ objects
by David Werner 23 Jun '17

23 Jun '17

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

2 1

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

21 Jun '17

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

2 2

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

20 Jun '17

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

1 0

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

09 Jun '17

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

1 0

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

09 Jun '17

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

1 0

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

08 Jun '17

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

2 1

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

08 Jun '17

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

1 0

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

07 Jun '17

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

1 0