- l4-hackers - example.com Site

User space filesystems for L4Linux
by Uwe Geuder 14 Jul '14

14 Jul '14

Hi! When looking at the examples and forum archives I get the impression that L4Linux users tend to work with ramdisks. However, in general I understand that in the Linux world ramdisks are considered mostly obsolete. Initramfs is the preferred solution https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/D… I replaced my disk image with a cpio archive suitable for initramfs and everything still works fine. Linux can dynamically recognize whether it is cpio or not. I understand my filesystem can grow dynamically until Linx runs out of memory. I dropped the ramdisk_size parameter from the kernel command line. Are there any drawbacks or pitfalls I am missing? The next step is compression. Both ramdisks and cpio archives can be compressed, again Linux can dynamically recognize that and uncompress before usage. (I have only tested cpio.gz so far, but I understand also disk images work and both faster lzo and more aggressive bzip2 and xz are supported.) However, when I tried to used my cpio.gz archive, the effect was zero. Someone had magically uncompressed my archive before making the U-Boot image. I tracked it down to the script src/l4/pkg/bootstrap/server/src/build.pl. > system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); > $file = "$modname.ugz" if !$?; It unpacks everything that is gzip compressed. Maybe that is necessary for object or executable files, I see some assembly manipulation a couple of lines further down, which I have not analyzed. However, for disk images or initramfs archives I cannot see the point. So I made the following hack diff --git a/src/l4/pkg/bootstrap/server/src/build.pl b/src/l4/pkg/bootstrap/server/src/build.pl index 22382d6..a31743e 100755 --- a/src/l4/pkg/bootstrap/server/src/build.pl +++ b/src/l4/pkg/bootstrap/server/src/build.pl @@ -75,8 +75,13 @@ sub build_obj($$$) printf STDERR "Merging image %s to %s [%dkB]\n", $file, $modname, ((-s $file) + 1023) / 1024; # make sure that the file isn't already compressed - system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); - $file = "$modname.ugz" if !$?; + if ($file =~ m/ramdisk-arm.rd$/) { + system("false"); + } else { + system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); + } + $file = "$modname.ugz" if !$? ; + print "using ", $file ; system("$prog_objcopy -S $file $modname.obj 2> /dev/null") if $strip && !$no_strip; system("$prog_cp $file $modname.obj") This worked as expected, my disk image remained compressed and Linux could uncompress it a boot time. Of course it is a hack, because the file name should not be hard-coded there. Same question as before, am I missing anything here? Also build.pl would fail to do the uncompression if a module is compressed with lzo, bzip2 or xz. Yes, I have found the variable BOOTSTRAP_UIMAGE_COMPRESSION. It worked fine during image creation, but during boot U-Boot failed with > Verifying Checksum ... OK > Uncompressing Kernel Image ... Error: inflate() returned -5 > GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover > resetting ... I assume this could be fixed by modiyfing the memory map. However, because my kernel is very small compared to the user space image and Linux has this nice dynamic support for various compression schemes I think I prefer an uncompressed U-Boot image containing a compressed user space image. Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder(a)nomovok.com (bot test: humans correct 1 obvious spelling error)

2 2

Pid 1 crashing under L4Linux
by Uwe Geuder 09 Jul '14

09 Jul '14

Hi! I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer. I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.) Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel. However, on L4Linux I always get > RAMDISK: ext2 filesystem found at block 0 > RAMDISK: Loading 262144KiB [1 disk] into ram disk... > EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities > EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities > EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) > VFS: Mounted root (ext4 filesystem) readonly on device 1:0. > Freeing unused kernel memory: 116K (022f9000 - 02316000) > Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 > > CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 > [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) > [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) > [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) > [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) > panic: going to sleep forever, bye > l4linux | panic: going to sleep forever, bye > The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon. The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on. What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float. > -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb Can any of these options be a problem under L4? (The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...) If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space. Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder(a)nomovok.com (bot test: humans correct 1 obvious spelling error)

2 2

MOE uses memory originally from IO device
by Martin Schröder 08 Jul '14

08 Jul '14

My board is equipped with 128MB external DRAM: > L4 Bootstrapper > Build: #1234 Do 3. Jul 17:34:17 CEST 2014, 4.6.2 > Scanning up to 128 MB RAM > Memory size is 128MB (40000000 - 47ffffff) > RAM: 0000000040000000 - 0000000047ffffff: 131072kB > Total RAM: 128MB In addition the CPU has 128kb internal RAM (so called On-Chip-RAM) which is located at address 0 - 0001ffff. I want to expose this OCRAM as a virtual device to a (already existing) kernel driver within l4linux, so I added these few lines to my config: > OCRAM => new Device() { > .hid= "ocram"; > new-res Mmio(0x00000000 .. 0x0001FFFF); > } > > client0 => new System_bus() { > ... > "ocram" = wrap(hw-root.OCRAM); > } Unfortunately IO cannot map this device, but maps instead something else which is of no use for me: > io | <0x1bff0>IOMEM [00000000000000-0000000001ffff 20000] non-pref (32bit) (align=1ffff flags=4002) > io | WARNING: phys mmio resource allocation failed > io | <0x1bff0>IOMEM [00000000000000-0000000001ffff 20000] non-pref (32bit) (align=1ffff flags=4002) > io | allocated resource: <0x1bff0>IOMEM [00000001000000-0000000101ffff 20000] non-pref (align=1ffff flags=4002) But a few lines up I see: > MOE: Hello world! > MOE: found 109032 KByte free memory > MOE: found RAM from 40000000 to 47000000 > ... Probably MOE assumes this as normal ram and adds it to its pool. But how can I inhibit MOE grabbing this piece of RAM and instead assign it to the OCRAM device in IO? Best regards, Martin

2 4

Fwd: Problems using qemu devices from l4re
by Maria Soler 07 Jul '14

07 Jul '14

Hello, I am running l4re on qemu (qemu-system-arm) and I have been trying to use a qemu device from l4re, but I have been unsuccessful so far. This device creates a file in the host and that is how I have been testing if I was actually writing/reading on the device: I was trying to write from the guest and read from the host (didn't work) and trying to write from the host and read from the guest, but didn't work either. What I have tried so far: - I have tried to use sigma0_map_iomem like this: --------------------------------------------- string = malloc(SIZE); l4sigma0_map_iomem(L4_BASE_PAGER_CAP, 0xXXXXXXXX, string, SIZE, 1); //I have tried both cached and uncached. printf("Received: %s\n",string); //prints nothing, regardless of the content of the file in the host memset(p,'a',SIZE); //the file in the host remains unchanged --------------------------------------------- The qemu device is mapped in address 0xXXXXXXXX and its size is bigger than SIZE. SIZE is a multiple of 4KB and so is 0xXXXXXXXX. I have tried to use this option by itself and combined with an io server (I actually tried this first, but now that I have seen that there is no difference in the behavior if I add it or remove it, I think they are maybe unrelated or most probably I am not using them the right way). To create the io server I have included an app.io file as follows: --------------------------------------------- -- Example configuration for io local hw = Io.system_bus() -- Configure two platform devices to be known to io Io.hw_add_devices { comm = Io.Hw.Device { hid = "COMM"; Io.Res.irq(63); Io.Res.mmio(BASE_ADDR, TOP_COMM); }, data = Io.Hw.Device { hid = "DATA"; Io.Res.irq(63); Io.Res.mmio(TOP_COMM+0x1000, TOP_DATA); } } Io.add_vbusses { -- Create a virtual bus for a client and give access to the device prodb = Io.Vi.System_bus { comm_bus = wrap(hw:match("comm")); data_bus = wrap(hw:match("data")); } } --------------------------------------------- and added to my .cfg file: --------------------------------------------- vbus = l:new_channel(); -- Start io l:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; input = vbus_prodb:svr(); }, }, "rom/io rom/app.io"); l:start( { prodb = vbus:svr(); log = { "app", "green" } }, "rom/app" , { FSTAB_FILE = "rom/fstab" } ); --------------------------------------------- Both with and without the io server, the application compiles and runs, but there is no communication with the file in the host, so I guess I am not mapping the device in the right way. I have also tried to use libio instead of sigma0 as follows: --------------------------------------------- string = malloc(SIZE); l4io_request_iomem(0xXXXXXXXX, SIZE, 1, string); //I have tried both cached and uncached. printf("Received: %s\n",string); //prints nothing, regardless of the content of the file in the host memset(p,'a',SIZE); //the file in the host remains unchanged --------------------------------------------- And this warning appears: app | libio: Warning: Query of 'vbus' failed! but it runs, so I don't really know what I am doing wrong. There is no complete example that I have found with either libio or sigma0, so I need some hints on this, please. Thank you! María.

4 6

Question abut DRQ handler
by Yuxin Ren 07 Jul '14

07 Jul '14

Hi, When I go through the IPC code, I have some questions about dqr handler. In the remote_ipc_send function within the thread-ipc.cpp file, I find a comment " // trigger remote_ipc_receiver_ready path, because we may need to grab locks // and this is forbidden in a DRQ handler. So transfer the IPC in usual // thread code. However, this induces a overhead of two extra IPIs." I have some questions about this comment. 1. Why cannot we grab locks in a DRQ handler? 2. Where do we need to grab lock? 3. Why can extra IPI solve this problem? Thank you very much. Best, Yuxin

2 5

Delay::measure function
by Xavier LEBARS 04 Jul '14

04 Jul '14

Hi everyone, I’m currently trying to port Fiasco + L4re with the « Hello World » application on a Zedboard which has a Xilinx Zynq z7020 processor (ARM Cortex A9 MPCore). We already configure UART and Timer for the microkernel but boot crash after the step : Calibrating Timer loop… Our problem seems to occur during the execution of Delay::measure() function. Does anyone know what it exactly does and especially update_timer which seems to have no effect in our case. Here is the boot execution trace : # Booting kernel from Legacy Image at 03000000 ... Image Name: L4 Image #42 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 868352 Bytes = 848 KiB Load Address: 01100000 Entry Point: 01100000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 02000000 ... Image Name: Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5619903 Bytes = 5.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02a00000 Booting using the fdt blob at 0x2a00000 Loading Kernel Image ... OK Loading Ramdisk to 1f5d2000, end 1fb2e0bf ... OK Loading Device Tre L4 Bootstrapper Build: #42 Tue Jul 1 15:59:58 CEST 2014, 4.7.3 Scanning up to 512 MB RAM Memory size is 512MB (00100000 - 200fffff) RAM: 0000000000100000 - 00000000200fffff: 524288kB Total RAM: 512MB mod04: 011ba000-011d3578: hello mod03: 011a0000-011b9458: l4re mod02: 0116e000-0119f624: moe mod01: 01164000-0116d33c: sigma0 mod00: 01115000-011638e8: fiasco Moving up to 5 modules behind 1200000 moving module 00 { 1115000-11638e7 } -> { 12bf000-130d8e7 } [321768] moving module 01 { 1164000-116d33b } -> { 130e000-131733b } [37692] moving module 02 { 116e000-119f623 } -> { 1318000-1349623 } [202276] moving module 03 { 11a0000-11b9457 } -> { 1200000-1219457 } [103512] moving module 04 { 11ba000-11d3577 } -> { 121a000-1233577 } [103800] Scanning fiasco -serial_esc Scanning sigma0 Scanning moe --init=rom/hello Relocated mbi to [0x110e000-0x110e0e2] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x102000 Regions of list 'regions' [ 101000, 101b3f] { b40} Kern fiasco [ 102000, 15efff] { 5d000} Kern fiasco [ 190000, 1965fb] { 65fc} Sigma0 sigma0 [ 198000, 19e17b] { 617c} Sigma0 sigma0 [ 240000, 26cacb] { 2cacc} Root moe [ 270000, 286f0f] { 16f10} Root moe [ 1100000, 11143f3] { 143f4} Boot bootstrap [ 110a000, 110a0a6] { a7} Boot mbi [ 110e000, 110e1df] { 1e0} Root Multiboot info [ 1114048, 111409f] { 58} Boot mbi [ 1200000, 1233577] { 33578} Root Module API Version: (87) experimental Sigma0 config ip:00190100 sp:01113de4 Roottask config i�Hello from Startup::stage2 Number of IRQs available at this GIC: 96 Cache config: ON ID_PFR[01]: 00001231 00000011 ID_[DA]FR0: 00010444 00000000 ID_MMFR[04]: 00100103 20000000 01230000 00102111 L2: ID=410000c8 Type=9e300300 Aux=72360000 WMask=ff S=0 L2: Type L2C-310 Size = 512kB SERIAL ESC: allocated IRQ 59 for serial uart Not using serial hack in slow timer handler. Welcome to Fiasco.OC (arm)! L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden Rev: f5bb6d4 compiled with gcc 4.7.3 for zynq [] Build: #69 Tue Jul 1 15:59:21 CEST 2014 Calibrating timer loop... Thanks in advance Best Regards Xavier

2 3

Doubts about File Systems on FIASCO on ARM (Cortex-A15)
by Maria Soler 03 Jul '14

03 Jul '14

Hello, I would need to use file system facilities, but I am not sure how this is done. I can already use rom/ and also tmpfs, but neither is exactly what I need. I need to create persistent files that are written in disk from applications running on FIASCO (directly, not using L4Linux as an intermediary). I would also need to load (these or other) files from disk in run time (loading all files as modules in rom may not be the best solution, specially since we need to create new files "on the go" and be able to load them from other applications. Is there any module/library/whatever in FIASCO that offers this? If there is one, how can we use it/where can we find information about it? In case this is relevant, our applications are in C and we are to run FIASCO in TrustZone Crotex-A15 (in secure mode). Best regards, María.

4 7

Re: Thanks Martin !! I got Ethernet on L4 Linux !!
by Taeung 02 Jul '14

02 Jul '14

Hi, Martin Sorry for late answer. I was very busy because of my company. On 06/26/2014 05:58 PM, Martin Schröder wrote: > Am 26.06.2014 09:05, schrieb Taeung: >> Hi, Martin >> >> Great to see again :-) >> > > Yeah :-) > >> The reason of that I disabled 'L4_CLK_NOOP' is as below. >> When I added SD/MMC device driver and etc options in menuconfig, I met >> error message as below. > > >> So, in order to solve this problem, I modified source code at first and >> amended Kconfig file thereafter. >> > > Ok, that makes sense. > > What about your progress with fiasco? I've succeeded in loading two L4Linux and running MPI program in each. And I've succeeded in getting Ethernet which can connect external network. > Did you manage to get everything running you need? Interesting to hear > that SD/MMC is running on your system. But I've failed in getting SD/MMC despite loading MMC driver and registering MMC device in IO server. I guess that there is problems in mach-setup.c (about PHY?) like previous a problem of Ethernet. Somehow I guess that some modification in mach-setup.c is needed. > I use it only temporary for booting U-Boot and will be removed later. Me,too I can't use SD card in L4 Linux yet. > > What I am missing is support for NAND and NOR (via SPI), but next week > I will start this task. > > Currently I am stumbling with IPC. I have about 12 different Linux > processes communicating via Unix Sockets in each direction. Now I want > to have 6 on one l4linux an 6 on another l4linux. I got it working by > using the l4shmnet driver and TCP-Sockets, but IP is not allowed and > the Linux IP-Stack must be removed, so I have to use something else. > Unfortunately I don't know of any ready-to-use alternative, so I have > to do it on my own. > I haven't try to do IPC in two L4 Linux. Did you make sure you enable it as below? =============================== L4Linux configuration ---> Features ---> Make Linux be a server Stub drivers ---> l4shm based network driver =============================== > Best regards from Berlin, > Martin. > > >

1 0

Question about handshake_receiver in IPC
by Yuxin Ren 01 Jul '14

01 Jul '14

Hi, I find before handle IPC, we always call handshake_receiver function. A basic question is why do we need to handshake receiver? What do we do when we handshake_receiver? Another thing I note is we have separate handshake_receiver (remote_handshake_receiver) if the receiver is on the other core. What is the difference between those two handshake_receiver functions? Thank you very much. Best, Yuixn

2 1

real time application example in l4re
by cem akpolat 01 Jul '14

01 Jul '14

Dear all, is there any example for a real-time applications running on l4re? I see in the slides prepared by TU Dresden that there is always a separation between realtime and non-realtime, but I couldn't find any example for that. If there is an example, could you refer it? Cheers, Cem Akpolat

2 1