users

users@lists.genode.org

2285 discussions

Announcement: Genode OS Framework version 9.11 released
by Stefan Kalkowski 25 Nov '09

25 Nov '09

The new release 9.11 of the Genode OS Framework is available. The current release comprises a whole bunch of new functionality with respect to libraries, OS services and device drivers, like the Light-weight IP stack, Qt4 Webkit and USB storage, just to mention a few. Moreover, we incorporated new generic interfaces and made parts of Genode more efficient especially with respect to memory consumption. Apart from functional extensions and improvements, the new release contains initial support for the ARM architecture. As cherry on the cake, we release an adapted version of OKLinux running on top of the Genode/OKL4 platform. As a consequence, native Genode applications run side-by-side with unmodified Linux binaries. Release-notes summary for version 9.11 -------------------------------------- * Base framework * Signal-framework refinements * Binary-size optimizations * Paravirtualized Linux on top of Genode on OKL4 * Initial support for the ARM architecture * Operating-system services and libraries * Packet-streaming interface * Fully integrated shared-library support * Light-weight IP stack * Zero-footprint runtime for Spark/Ada programs * Port of popular libraries such as Freetype2 and Jpeg * Device drivers * Support for USB storage * PS/2 mouse scroll-wheel support * NIC driver service * Qt4 Webkit * Support for Jpeg and Freetype2 * Applications * Xvfb integration into Genode on Linux * Improved configurability of native applications You can find the complete release notes for the version 9.11 here: http://genode.org/documentation/release-notes/9.11/ The new release is available to the project's subversion repository and at the Genode download page: http://genode.org/download/latest-release Regards -- Stefan Kalkowski Genode Labs Developer http://genode-labs.com

1 0

Sharing locks between several address spaces
by Sven Fülster 20 Oct '09

20 Oct '09

Hi there, I'm working on two applications which require communication over shared memory. Therefore, I've adapted some of your datastructures (such as the slab allocator, semaphores and locks) so that they are safe to be shared between different address spaces, by adding smart pointers and taking care of having all shared components (like the Applicant list of the locks, the applicants and the locks themselves) within the shared memory. I have now a little problem with the locks. I have a thread in address space 1 which performs a lock operation on a lock in shared memory. The lock operation is (by default) mapped to the L4_Stop syscall (I work with the Okl4-Kernel). Another thread in address space 2 performs a wake-operation on the same lock (where the thread id is deposited in the applicant), which is mapped to L4_ThreadSwitch which is again mapped to the L4_ExchangeRegisters syscall. This operation does not wake the first thread. In detail, the L4_ThreadWasHalted call which is performed upon L4_ThreadSwitch returns false, hence the thread which tried the wake operation remains spinning in the forever-loop (this is a nice opportunity for a denial-of-service-attac of a malicious client by the way...). However, I've started to investigate by replacing the L4_ThreadSwitch syscall by L4_WaitNotify and the wake-operation by L4_Notify. The result was the same. Checking the error code of the L4_Notify syscall with L4_ErrorCode showed that the call had been aborted due to L4_ErrInvalidThread, respectively L4_ErrNonExist (2). Now I wonder if a thread is generally allowed to invoke syscalls on threads which don't belong to its address space (maybe I need some capability? What exactly is env()->pd_session()->bind_thread() for?). I've also noticed that the thread ids I get from env()->cpu_session()->state() or from thread_get_my_native_id() differ from those the kernel debugger shows (what exactly do you do when you ask Okl4::__L4_TCR_ThreadWord(Genode::UTCB_TCR_THREAD_WORD_MYSELF) for a thread id? Is that the global thread id?) Perhaps you have an idea what's going wrong here (meanwhile I'd add L4_MutexControl to core :o) ). With kind regards Sven -- Sven FÃ¼lster

2 1

Re: Split console with two keyboards
by Christian Helmuth 16 Oct '09

16 Oct '09

Hello Shakthi, On Fri, Oct 16, 2009 at 12:16:21AM +0530, Shakthi Kannan wrote: > Hi, > > I would like to know if it is possible in any of the L4* systems to > have a setup like the following: > > * The console (framebuffer) to be split into two frames/windows, say > top and bottom halves, but, each one should be used/accessed > independently of each other. > > * With two keyboards connected to this single system, one should be > able to use (shell) one of the keyboards with the top window, while > the other should use the bottom one. > > Appreciate any thoughts/inputs in this regard. Thanks! I don't know of any L4-based system, which supports this setup out-of-the-box. IMO Genode [1] and L4Env [2] have all you need to build such a system on your own: PS/2 drivers, USB HID drivers, and frame buffer console/GUI. Both options implicate some hacking on your part as multi-head scenarios were not addressed so far. BTW, Genode seemlessly supports several L4 kernels, namely OKL4, Fiasco, and Pistachio. That's a nice feature if you're not certain which kernel fits your needs best and want to postpone the final decision :-) [1] http://www.genode.org [2] http://www.inf.tu-dresden.de/index.php?node_id=1431 Regards -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://genode.org/

1 0

Small TODO tasks at Genode project
by Shakthi Kannan 06 Oct '09

06 Oct '09

Hi, I am looking at small tasks that can be worked for the Genode project. Is it possible for anyone to break down larger goals into smaller project outcomes that people can explore or delve into? Also, this FPGA graphics is quite interesting. What is the content in the FPGA here, and what is the relation with Genode here? Sorry, if this is off-topic in this list, else I shall contact the Genode-FX list. http://www.genode-labs.com/news/genode-fx-on-trenz-electronic-industrial-fp… Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com

2 4

rom service in user space / how to add Rom_module
by Oliver Mayer-Buschmann 07 Sep '09

07 Sep '09

Hi, I've implemented my own rom service based on Genode::Rom_root and Genode::Rom_fs inside a server. Basically the service seems to work. If I open a Rom_connection on a file that I've added to my Rom_fs before, I get a valid Dataspace_capability. By using a Genode::Dataspace_client, I can see that the size and the base address of the Dataspace correspond to the values that I've passed to the Rom_module I've inserted into my Rom_fs before. The problem is, that the data inside the Dataspace is 0. Here the code: Dataspace_capability file_cap; Rom_connection rom(filename, unique_name); try { file_cap = rom.dataspace(); } catch (Rom_file_missing) { printf("Error: Could not access file \"%s\" from ROM service.\n", filename); return 0; } if(!file_cap.valid()) PWRN("file cap not valid!!"); void* addr = env()->rm_session()->attach(file_cap); Genode::Dataspace_client dsc(file_cap); PDBG("rom module filename: %s", filename); PDBG("rom module base address: 0x%lx", dsc.phys_addr()); PDBG("rom module size: 0x%zx", dsc.size()); PDBG("some data: 0x%x", *(int*)addr); .. and the corresponding output: rom module filename: pci_drv rom module base address: 0x3333000 rom module size: 0x26000 some data: 0x0 My understanding is, that the constructor of Rom_module needs a physical base address. How can I copy data to a memory location, that is still available in another context? I've tried out the following but this does not work: // for now we copy data from core's to our local rom service Genode::Dataspace_capability file_cap; Rom_connection rom(filename); try { file_cap = rom.dataspace(); } catch (Rom_file_missing) { printf("Error: Could not access file \"%s\" from ROM service.\n", filename); } void* addr = env()->rm_session()->attach(file_cap); Genode::Dataspace_client dsc_source(file_cap); /* create new Rom_module */ Genode::Ram_dataspace *ram_dsc = new (env()->heap()) Genode::Ram_dataspace(env()->ram_session(), dsc_source.size()); Genode::Dataspace_client dsc(ram_dsc->cap()); Genode::memcpy(ram_dsc->local_addr<void>(), addr, dsc_source.size()); Rom_module *r = new (&_sliced_heap) Rom_module(dsc.phys_addr(), dsc_source.size(), filename); PDBG("rom module filename: %s", filename); PDBG("rom module base address: 0x%lx", dsc_source.phys_addr()); PDBG("rom module size: 0x%zx", dsc_source.size()); PDBG("dataspace base address: 0x%lx", dsc.phys_addr()); PDBG("some data: 0x%x", *(int*)ram_dsc->local_addr<void>()); _rom_fs.insert(r); _rom_fs.print_fs(); The output in this context is ok: rom module filename: pci_drv rom module base address: 0x3140000 rom module size: 0x26000 dataspace base address: 0x3333000 some data: 0x464c457f Is there an Allocator that I can use? Thx, Oliver

2 2

Session mapping 1:1 vs. 1:n
by Sven Fülster 28 Aug '09

28 Aug '09

Hi all, during my work, I've written a vesa driver which is capable of serving multiple clients (using 'virtual' framebuffers, derived from your vesa_drv). I always thought, that my 'Session_component' is created once when the first client opens a connection to my service, so that init calls 'create_session' in my 'Root_component' just once and never again. That was obviously wrong. I've found out, that 'create_session' is called once for each client - not on creation of the connection but on the first ipc call the client invokes. For my setting, this behaviour is not useful, so I've manually taken care of being a singleton by allocating my 'Root_component' only once in 'create-session' and handing out that single object subsequently on each following session creation. I've noticed some strange behaviour with that setting. (1) I saw that something complained about my singleton -- [init -> vesa_drv] void Genode::Avl_node<NT>::insert(Genode::Avl_node<NT>*) [wit h NT = Genode::Object_pool<Genode::Server_object>::Entry]: Inserting element 26f c twice into avl tree! -- But that did not seem to matter, so I ignored it... (2) I had to identify my clients somehow to maintain state information. So I hand over a 'shared secret' in each ipc call. That's simply the dataspace cap the client got from me. I noticed that something else than my clients called one of my methods during startup with an invalid secret. -- [init -> vesa_drv] virtual void Framebuffer::Session_component::toggle(Genode::D ataspace_capability): Framebuffer::Session_component::toggle 4b383d61h [init -> vesa_drv] virtual void Framebuffer::Session_component::toggle(Genode::D ataspace_capability): Framebuffer::Session_component::toggle: _fb_cap not accept ed. -- I wonder who might that be. Maybe a relict of mine or does the framework some kind of 'reflection'? (3) However, all that did not really bother, and for a start, everything seemed to work nice, but when my setting grew bigger, some ipcs didn't work properly. One of my two clients (the 2nd) caught an 'Ipc_error' when performing its second request. The first request performed fine. I thought that maybe the ipc could not be performed because the Session_component was serving another ipc at that moment. So I've ignored the exception and i kept retrying the ipc call. Without any success, and from here on I can't imagine what happens. Does anyone have an idea what I've missed? Kind regards Sven -- Sven FÃ¼lster

2 2

Announcement: Genode OS Framework version 9.08 released
by Norman Feske 19 Aug '09

19 Aug '09

The new release 9.08 of the Genode OS Framework is available. With this release, we focused on replacing several interim solutions with much improved new implementations. In particular, we want to highlight the new synchronization mechanisms, the new timer service, and our effort to unify former platform-specific code among all kernel platforms supported by the framework. The major functional additions of this release are the port of the dynamic linker from FreeBSD, new core extensions for running Linux (Wombat) on top of the OKL4 version of Genode, and the support for super pages on the L4/Fiasco and L4ka::Pistachio kernels. Release-notes summary for version 9.08 -------------------------------------- * Base framework * New lock implementation * New generic signalling mechanism * Added support for thread-local storage * Core extension to run Linux on top of Genode on OKL4 * Operating-system services and libraries * Added shared-library support * Improved XML config handling * Optimized Nitpicker GUI server * New timer server * Added support for super pages on L4/Fiasco and L4ka::Pistachio * Added support for write-combined I/O access * Unified startup code and linker scripts among all platforms * Removed glibc dependency from the Linux version You can find the complete release notes for the version 9.08 here: http://genode.org/documentation/release-notes/9.08/ The new release is available to the project's subversion repository and at the Genode download page: http://genode.org/download/latest-release Regards -- Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org

1 0

PCI memory configuration
by Frank Kaiser 10 Aug '09

10 Aug '09

Hello It looks as if we have a serious problem with the PCI device driver. The driver just takes over the PCI memory configuration from the BIOS, and it turns out that the current BIOS of the IVI platform assigns memory block with a minimum address increment of 1 kB. The outcome is that the register addresses of the 3 SDHCI controllers and the EHCI controller reside in one 4 kB page. Since Genode seems to always assign one page to each device, it only can handle the first controller found. Trying to allocate resources to the next controllers results in errors: Genode::Io_mem_session_component::Dataspace_attr Genode::Io_mem_session_component::_prepare_io_mem(const char*, Genode::Range_allocator*): I/O memory [bfe57000,bfe58000) not available Genode::Io_mem_session_component::Io_mem_session_component(Genode::Range _allocator*, Genode::Range_allocator*, Genode::Server_entrypoint*, const char*): Local MMIO mapping failed! [init -> test-dde_os_linux26_mmc] request_mem_region() failed (start bfe57400, size 100)<4>PCI: Unable to reserve mem region #1:100@...26... for device 0000:00:0a.0 The PCI memoty map is as follows: [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8100 (base class 0x6) [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8108 (base class 0x3) [init -> test-pci] Resource 0 (MEM): base=0xbfe80000 size=0x00080000 [init -> test-pci] Resource 1 (I/O): base=0x0000e880 size=0x00000008 [init -> test-pci] Resource 2 (MEM): base=0xb0000000 size=0x08000000 [init -> test-pci] Resource 3 (MEM): base=0xbfe60000 size=0x00020000 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 811b (base class 0x4) [init -> test-pci] Resource 0 (MEM): base=0xbfe58000 size=0x00004000 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8110 (base class 0x6) [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8112 (base class 0x6) [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8114 (base class 0xc) [init -> test-pci] Resource 4 (I/O): base=0x0000e480 size=0x00000020 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8115 (base class 0xc) [init -> test-pci] Resource 4 (I/O): base=0x0000e080 size=0x00000020 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8116 (base class 0xc) [init -> test-pci] Resource 4 (I/O): base=0x0000d880 size=0x00000020 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8117 (base class 0xc) [init -> test-pci] Resource 0 (MEM): base=0xbfe57c00 size=0x00000400 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 811c (base class 0x8) [init -> test-pci] Resource 0 (MEM): base=0xbfe57800 size=0x00000100 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 811d (base class 0x8) [init -> test-pci] Resource 0 (MEM): base=0xbfe57400 size=0x00000100 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 811e (base class 0x8) [init -> test-pci] Resource 0 (MEM): base=0xbfe57000 size=0x00000100 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 8119 (base class 0x6) [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 811a (base class 0x1) [init -> test-pci] Resource 4 (I/O): base=0x0000ffa0 size=0x00000010 [init -> test-pci] Vendor ID: 8086 (Intel) Device ID: 4232 (base class 0x2) [init -> test-pci] Resource 0 (MEM): base=0xbfffe000 size=0x00002000 [init -> test-pci] Vendor ID: 10ee (unknown) Device ID: a123 (base class 0x8) [init -> test-pci] Resource 0 (MEM): base=0xdc000000 size=0x04000000 [init -> test-pci] Resource 1 (MEM): base=0xdbfffc00 size=0x00000100 [init -> test-pci] Resource 2 (MEM): base=0xdbfff800 size=0x00000100 [init -> test-pci] Resource 3 (MEM): base=0xc0000000 size=0x10000000 For the time being we require only one SDHCI controller so that we could omit the initialisation over the other two, but this still leaves the problem with the conflicting address assignment of the EHCI controller. I see only two solutions: 1. Make Genode dealing with PCI memory resources smaller than 4 kB. 2. If #1 is not affordable, let the PCI driver reassign the memory resources with a minimum increment of 4 kB. I'd like to get some hints how to proceed. Regards Frank

2 1

base-linux/src/base/env/rm_session_mmap.cc/Platform_env::Rm_session_mmap::attach
by Sven Fülster 04 Aug '09

04 Aug '09

Hi all, is there a special reason why you don't have implemented the 'attach_at'-support to a local address in the base-linux code? I need this feature (and my fix seems to work well here). I'll also need this feature in the base-okl4 code (and I would try to add it also there if necessary...) Is there any risk/ nasty surprise when using it? Thank you and kind regards Sven -- Sven FÃ¼lster

2 2

Problem with 'test-pci'
by Frank Kaiser 04 Aug '09

04 Aug '09

Hello As a preparation of a certain task I want to check the PCI resources of my platform (IVI platform with Intel ATOM). For this purpose I built Genode-on-OKL4, only consisting of a minimum driver set and the test-pci application. Running this image in qemu looks good, but on the IVI platform the init process fails with a page fault before or when starting the PCI driver which is the first entry in the config file. The error message is: no RM attachment (READ pf_addr=6000 pf_ip=2001286 from 01) I have no clue what this message is trying to tell me. The given IP points to the function Genode::strncpy(). I also wonder why the system wants to read from virtual address 0x6000, because all modules are allocated beginning at virtual address 0x02000000. Checking init's pagetable with OKL4's KDB on qemu shows a number of allocations below: 00000000 [00140027]: tree=f0140000 00001000 [001f5067]: phys=001f5000 pg=f0140004 4KB rwx (RWX) user WB 00003000 [001f7067]: phys=001f7000 pg=f014000c 4KB rwx (RWX) user WB 00004000 [001f8067]: phys=001f8000 pg=f0140010 4KB rwx (RWX) user WB 00005000 [001df025]: phys=001df000 pg=f0140014 4KB r~x (R~X) user WB 00006000 [00275067]: phys=00275000 pg=f0140018 4KB rwx (RWX) user WB 00007000 [00276067]: phys=00276000 pg=f014001c 4KB rwx (RWX) user WB 00008000 [00277067]: phys=00277000 pg=f0140020 4KB rwx (RWX) user WB 00009000 [00278067]: phys=00278000 pg=f0140024 4KB rwx (RWX) user WB 0000a000 [00368067]: phys=00368000 pg=f0140028 4KB rwx (RWX) user WB 0000b000 [00369067]: phys=00369000 pg=f014002c 4KB rwx (RWX) user WB 0000c000 [0036a067]: phys=0036a000 pg=f0140030 4KB rwx (RWX) user WB 0000d000 [0036b067]: phys=0036b000 pg=f0140034 4KB rwx (RWX) user WB 0000e000 [0037b067]: phys=0037b000 pg=f0140038 4KB rwx (RWX) user WB 00012000 [003fa067]: phys=003fa000 pg=f0140048 4KB rwx (RWX) user WB 00016000 [00852067]: phys=00852000 pg=f0140058 4KB rwx (RWX) user WB 0004a000 [00336067]: phys=00336000 pg=f0140128 4KB rwx (RWX) user WB 00066000 [00370067]: phys=00370000 pg=f0140198 4KB rwx (RWX) user WB On the IVI platform this area at the time of the page fault looks: 00000000 [00141027]: tree=f0141000 00001000 [001f5067]: phys=001f5000 pg=f0141004 4KB rwx (RWX) user WB 00005000 [001df025]: phys=001df000 pg=f0141014 4KB r~x (R~X) user WB I'd like to get some hints where to look into the code for finding the cause of the problem. Since I cannot debug the platform, I probably have to add more trace messages to get additonal information about what is going on. Regards Frank

3 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users