users August 2012

users@lists.genode.org

15 participants
15 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users August 2012