users

users@lists.genode.org

1 participants
2310 discussions

Announcement: Genode OS Framework version 12.08 released
by Norman Feske 23 Aug '12

23 Aug '12

Midsummer - there couldn't be a better time for releasing a new version of Genode. Among the highlights of version 12.08 are a new base platform that enables the framework to run on bare ARM hardware without a separate kernel, the largely reworked support for the NOVA hypervisor, and comprehensive device drivers for OMAP4-based hardware platforms. Quick overview of the changes that come with version 12.08: - Base platforms - New base-hw platform for running the framework on bare ARM hardware - NOVA support for x86_64, object integrity protection, core-only kernel-resource allocation - New OMAP4 SoC device drivers - HDMI output - SD-card - USB HID - Networking - New FFAT-based file-system service - New TAR file-system service - Improved Noux runtime - New port of the Lynx web browser - Shell scripting support - 3rd-party libraries - New ports of openssl, pcre, expat - MPC, libgmp for x86_64 and ARM - lwIP updated to version 1.4.1-rc1 - New port of the lighttpd web server Those and many more improvements are described in full detail in the release notes: http://genode.org/documentation/release-notes/12.08 Have fun with exploring the new version! Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Celebrate the 4th Anniversary of Genode with us
by Norman Feske 22 Aug '12

22 Aug '12

Hello, I just sent out an invitation with the Genode-Labs newsletter today. Just in case you are not receiving these mailings, please find the invitation text below: ---- when we released the first version of the Genode OS Framework four years ago, a few people recognized the potential of the technology but considered Genode largely as a research endeavor, which was probably right at that time. Now, four years of dedication and 16 releases later, Genode has evolved to a comprehensive and useful framework that increasingly captures the interest of the "real world". Over the course of the last year, we learned about several industrial research organizations who picked up our work to build upon, received inquiries about licensing our technology for the use in products, and observed increased public interest in the prospects Genode promises with regard to privacy and security. The most significant event for the project during the past year, however, was our move to liberate its development process and thereby expose our way of working and all technical discussions to the public. Although this was a radical move for a small company as ours, we got immediately rewarded by new developers and users entering the scene and an emerging community spirit. To celebrate these achievements together with us, we would like to welcome you to join us having a barbecue and campfire at the riverside: Google Maps: http://goo.gl/maps/C0luj 23th of August, 6 pm near Moritzburger Str. 1 in Dresden Everyone who feels attached to Genode in some way to another, please do not hesitate to drop by, hang out with the Genode crowd, and enjoy the barbecue and beverages. If you plan to attend, please send a brief notice until 20th of August to info@...1... Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 1

Status of 2012 Roadmap
by Robert Campbell 17 Aug '12

17 Aug '12

Hello guys, How is the progress on the 2012 road map? Are you on target to realize the goals set out in the 12.08 milestone? August - Release 12.08 Tiled window manager and user-interface concept Intel wireless driver Persistent file system Hosting genode.org website on Genode Multi-processor support on NOVA, Pistachio, and Fiasco.OC Regards

2 3

Illegal session request to service CPU
by Markus Partheymueller 17 Aug '12

17 Aug '12

Hi, with the latest code in staging I get the following error when starting the PCI driver through ACPI: [init -> acpi -> pci_drv] PCI driver started [init -> acpi] pci_drv: illegal session request of service "CPU" Later, the PCI driver fails because of this. The config portion looks as follows: <parent-provides> <service name="ROM"/> <service name="RAM"/> <service name="IRQ"/> <service name="IO_MEM"/> <service name="IO_PORT"/> <service name="CAP"/> <service name="PD"/> <service name="RM"/> <service name="CPU"/> <service name="LOG"/> <service name="SIGNAL"/> </parent-provides> ... <start name="acpi"> <resource name="RAM" quantum="32M"/> <binary name="acpi_drv"/> <provides> <service name="PCI"/> <service name="IRQ"/> <service name="CPU"/> </provides> <parent-provides> <service name="CPU"/> </parent-provides> <route> <service name="PCI"> <any-child/> </service> <any-service><parent/><any-child/></any-service> </route> </start> The parent-provides entry and the service name="CPU" in <provides> were not present in my last setup, but didn't change anything. Am I missing something or is there a problem with the most recent changes regarding the CPU session or NOVA-specific code? Cheers, Markus

2 1

Fwd: Re: openrisc
by Martin Stein 09 Aug '12

09 Aug '12

-------- Original Message -------- Subject: Re: openrisc Date: Thu, 09 Aug 2012 11:08:04 +0200 From: Martin Stein <martin.stein@...1...> To: Nick Betteridge <nick.betteridge@...2...> Hi Nick, I'm pleased to hear that you've found the time to proceed. ... You're right concerning the directory 'src/platform'. Due to the fact that 'base-hw' solely targets ARM systems for now, the separation of generic and platform specific code is not proven very well. I've annotated this issue, thank you! Moreover i'm not sure if i've understood you right regarding 'mode_transition.s'. The file does not really handle or control any type of exception. It's purpose is on the one hand to only catch exceptions, wich occur in userland, save the interrupted user execution-state and exception information, and get back to the kernel enviroment to re-run 'kernel()'. On the other hand it offers also the opposite direction, that is resuming a given user execution-context in userland once 'kernel()' returns. This way the handling of the concrete exception, whether it is an interrupt, a page fault or a syscall, resides completely in 'kernel()'. If you were looking for the resolution of page faults, even 'kernel()' is not the final destination. When kernel detects the presence of a page fault, the function 'handle_pagefault()' only checks if the fault was caused by a translation miss. If this is the case a pager might resolve the problem by expanding the according page table. Thus kernel composes an appropriate IPC message to the pager that is identified by the thread object of the faulter. The pager normally is a thread in Genodes 'core' process, wich itself asks the so called "Region Manager" of the faulter for a region mapping that covers the fault. If a mapping is found the pager modifies the page table accordingly. The only process that doesn't need pagers is 'core'. Because 'core' is the first process in Genode, gets initialized by 'kernel()' and must be trusted anyway, its page table gets filled with static 1:1 translations initially by kernel. Once this is done, kernel itself joins this process, so userland threads in 'core' and the kernel "thread" share the same address space. Long story short, the configuration of virtual/effective addresses depends, except of 'core' on the region managers, wich themselves are instructed through the RM-sessions (base/include/rm-session/rm_session.h) they provide to their RPC-clients. I hope this gives you a rough picture of Genodes virtual-address management, even it is a somewhat far-reaching explanation. Cheers, Martin On 08/08/2012 06:24 PM, Nick Betteridge wrote: > Hi Martin, > > ... > > I have been slowly reading through your arm assembler, trying to > understand how genode works. > > Just one thing - you have partitioned both arm processors and platforms > into named directories, except for base_hw/src/platform, which contains > arm assembler. Do you intend to refactor this into something like > base_hw/src/platform/arm? > > Just one more thing, am I right in thinking > > 'base-hw/src/core/arm_v7a/mode_transition.s' > > is just for interrupt control? I can't find anything for configuring > virtual/effective addresses - perhaps this is done in 'c' (I haven't > read the c yet) - in openrisc this is handled in the supervisor mode. > > Cheers > Nick > > > >

2 1

[genode] [feature request] Lock and RW lock function for Genode Thread support.
by 김은석 07 Aug '12

07 Aug '12

3 2

Fwd: Re: openrisc
by Martin Stein 03 Aug '12

03 Aug '12

-------- Original Message -------- Subject: Re: openrisc Date: Fri, 03 Aug 2012 08:08:18 +0100 From: Nick Betteridge <nick.betteridge@...2...> To: Martin Stein <martin.stein@...1...> Hi Martin, Thanks for getting back to me - no problem on delayed reply as I'm looking after my two boys whilst trying to do some work. It's chaos. No problem also on using the genode lists. I may initially ask some very dumb questions as I haven't touched assembler work and processors since the early 80's. I have quickly scanned through your base_hw. Thank you so much for really documenting the code so well - at a first glance it looks as though a port should be straight forward. For the next two weeks I have to manage a 9 year old and a twelve year old and will attempt a port on my own if and when I get a chance. (I can't believe I was so badly behaved at those ages). After that we're on holiday in France until the beginning of September. From September onwards I hope to devote one day a week to this. Thanks again for being supportive and offering your help. Cheers, Nick On 03/08/12 00:14, Martin Stein wrote: > Hi Nick, > > First of all please excuse the delayed reply. > > For me its no problem that you've targeted me directly, > but i would propose to move this discussion to the > main list of Genode Labs for two reasons. > On the one hand it might be that other readers can > complete my comments in order that you can succeed > as soon as possible. On the other hand the results could > help other peoples as well. > > To bring it back to your questions, i'm very pleased to > hear about your intentions concerning OpenRISC, > not least because for now i don't know anybody who > addresses oneself to this task. > > Nevertheless i would recommend you to have a look > to my branch 'base_hw': > https://github.com/m-stein/genode/tree/base_hw > > It offers the direct port of Genode to several CortexA9 > systems through the 'base-hw' repository and thereby > pursues goals similar to 'base-mb'. Thus it can be seen > as the latest state of running Genode directly on RISC. > Furthermore 'base-mb' can't hide that it was my first > try to create a microkernel and it is an aspiration to > provide Microblaze support with the means of 'base_mb' > someday. > > Certainly this branch will be merged to the official 'master' > branch soon, we only just merged it into staging to let our > build bot give it a last check. > > So if you have further questions dont't hesitate to ask. > > Cheers, > Martin > > > On 08/01/2012 07:25 PM, Nick Betteridge wrote: >> Hi Martin, >> >> I hope you don't mind me writing directly to you. >> >> I am just about to do a port of your microblaze base of genode to >> openrisc. After spending sometime reading through the OR1K >> architecture manual and additional documentation I'm hoping that it >> should be quite straight forward. >> >> However, it suddenly struck me that somebody might have already done >> this. Do you know if anybody has done an Openrisc port? >> >> Just one more question - do you have any idea when you will be adding >> capability-based delegation of communication rights to the base-mb tree? >> >> Finally, I may have a few questions about the microblaze >> implementation whilst doing the port - would you mind if I contacted you? >> >> Cheers and best regards, >> >> Nick

1 1

Question about using heap
by 정복득 02 Aug '12

02 Aug '12

Hi, My program runs two kinds of RPC server in a single process. Do I need to get sliced heap for each RPC server or can I just share one sliced heap object between the rpc server? For example, Sliced_heap sliced_heap1(env()->ram_session(), env()->rm_session()); Sliced_heap sliced_heap2(env()->ram_session(), env()->rm_session()); ... Server1_root_component server1_root(&server1_ep, &sliced_heap1, ....); Server2_root_component server1_root(&server2_ep, &sliced_heap2, ....); OR Sliced_heap sliced_heap(env()->ram_session(), env()->rm_session()); ... Server1_root_component server1_root(&server1_ep, &sliced_heap, ....); Server2_root_component server1_root(&server2_ep, &sliced_heap, ....); My another question is : Do I need to use Synchronized_allocator to allocate a memory from heap (for object creation) when running multiple thread? Or is it ok to call (env()->heap()) for object creation in heap? Thank you. Bokdeuk Jeong

2 1

Trouble with QEMU when running run/demo on branch 12.05
by Сергей Грехов 01 Aug '12

01 Aug '12

Hello to all! I have switched on commit daf4300 and tried to run demo with command "make run/demo". The output gives no error, but for some reason qemu shows only black screen. I tried to use qemu provided by Ubuntu (0.15.1) and tried to compile version 0.14.1 with SDL support - the result is the same - black screen. The emulated system is foc_pbxa9. Command "make run/demo" works fine on tag 12.05. So I guess that the problem is in some commit between b54bdea and daf4300. -- Best regards, Sergey S. Grekhov

2 1

NOVA: Capability selectors cause call of invalid portal
by Markus Partheymueller 31 Jul '12

31 Jul '12

Hi, I am quite stuck with a problem I encountered when using a timer connection in Vancouver. As soon as the unique IDs of the capabilities for RPC reach numbers >= 0x100000, RPC calls fail because of calls to invalid portal numbers. In my particular case, there are 4 portals created: [ 0] EC:0xc0019f00 SYS_CREATE PT:0x1a06 EC:0xa7 EIP:0x139950 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x1a07 EC:0xa7 EIP:0x1398d0 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x1a08 EC:0xa7 EIP:0x139950 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x1a09 EC:0xa7 EIP:0x1398d0 In base/include/base/rpc_client.h, I inserted a debug statement showing that the "internal" portal being called is 0x82260. I think this is due to the translation between global capability selectors and NOVA portals, is that correct? When the internal IDs hit 0x100000, what happens is this: [ 0] EC:0xc0019f00 SYS_CREATE PT:0x30e6 EC:0xa7 EIP:0x139950 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x30e7 EC:0xa7 EIP:0x1398d0 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x30e8 EC:0xa7 EIP:0x139950 [ 0] EC:0xc0019f00 SYS_CREATE PT:0x30e9 EC:0xa7 EIP:0x1398d0 But the next event in NOVA is a call to portal number 0x100018, which doesn't exist because it was not created beforehand. It seems to me that from this point in time, the internal IDs are being used as NOVA portals somehow. But all I found was this unmarshalling method in base-nova/include/base/ipc.h: inline void Genode::Ipc_istream::_unmarshal_capability(Genode::Native_capability &cap) { long unique_id = 0; _read_from_buf(unique_id); int pt_sel = unique_id != ~0L ? _rcv_msg->rcv_pt_sel() : 0; cap = Native_capability(pt_sel, unique_id); } I put another debug instruction there and found out that rcv_pt_base was 0x100018, when the call failed. Right now I'm quite lost in all that RPC and Capability wrangling. Maybe someone can shed some light on this? How is that translation between internal IDs and NOVA portals done, anyway? Cheers Markus

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users