Re: Socket fs

[Emery Hemingway]

Hello Boris,

In my opinion, once you start using TCP/IP, you cross a complexity
threshold where it makes sense to use high-level langauges or
networking libraries.

The alternative would be to use the lwIP raw API and avoid libc, but
this is not exposed right now. Another option would be the Rust way, I
expect there is atleast Rust TCP stack in the works, so in theory a
Rust component could be crafted to use Nic sessions directly.


Cheers,
Emery


On Mon, 27 Mar 2017 13:25:43 +0200
Christian Helmuth  wrote:

> Hello Boris,
> 
> On Mon, Mar 13, 2017 at 03:48:54PM +0100, Boris Mulder wrote:
> > 1. In the release notes you describe the support for async file I/O.
> > However, it seems that while asynchronous I/O works now,
> > synchronous I/O is no longer possible. When I remove the select()
> > call in the echo scenario, the call to recvfrom() will fail saying
> > the socket is not connected (even though it is an UDP socket and
> > should not have the notion of connections at all).
> > 
> > Of course this means it is not posix compatible; the intended
> > behaviour is to block until data becomes available.  
> 
> Thanks for your investigation. You're right the current state of
> socket support has some rough edges (esp. POSIX-correct error
> handling) that we plan to smoothen in near term. I'd like to invite
> you to open an issue at Github to aggregate your findings.
> 
> > 2. Currently there are two ways an application can use tcp/ip
> > sockets from the lxip stack: By using libc sockets, and by directly
> > opening a file system session and writing to the right socket
> > files. For any new Genode application that does not already depend
> > on libc, the first way means you unnecessarily add the entirety of
> > libc to your component. So the second way seems preferred. 
> > 
> > However, when programming an application using a file system
> > session directly adds a lot of code with many open()s, read()s and
> > write()s that could be abbreviated into single calls such as
> > connect() and recv(). Have you thought of providing a more
> > convenient API (such an object-oriented Socket class that hides the
> > vfs calls from the application programmer)? Or do you consider
> > using the fs session interface to be better? If so, why?  
> 
> We do not plan to implement an abstraction layer or object-oriented
> Socket interface currently. The mere reason for our recent
> developments was to enable more POSIX network applications to run on
> Genode and to support those components to share one network stack.
> Also, we imagine to mount the socket FS into Noux and use traditional
> tools in shell scripts to interoperate with the network.
> 
> I must admit that we (the Genode Labs team) do not assess ourselves as
> networking experts and, therefore, don't fancy to design and implement
> such a library. But as always nothing is set in stone and priorities
> may shift over time.
> 
> Regards


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Restoring child with checkpointed state

[Denis Huber]

Dear Genode community,

Preliminary: We implemented a Checkpoint/Restore mechanism on basis of 
Genode/Fiasco.OC (Thanks to the great help of you all). We store the 
state of the target component by monitoring its RPC function calls which 
go through the parent component (= our Checkpoint/Restore component). 
The capability space is indirectly checkpointed through the capability map.
The restoring of the state of the target is done by restoring the RPC 
objects used by the target component (e.g. PD session, dataspaces, 
region maps, etc.). The capabilities of the restored objects have to be 
also restored in the capability space (kernel) and in the capability map 
(userspace).

For restoring the target component Norman suggested the usage of the 
Genode::Child constructor with an invalid ROM dataspace capability which 
does not trigger the bootstrap mechanism. Thus, we have the full control 
of inserting the capabilities of the restored RPC objects into the 
capability space/map.

Our problem is the following: We restore the RPC objects and insert them 
into the capability map and then in the capability space. From the 
kernel point of view these capabilities are all "IPC Gates". 
Unfortunately, there was also an IRQ kernel object created by the 
bootstrap mechanism. The following table shows the kernel debugger 
output of the capability space of the freshly bootstraped target component:

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 address 000217 you can see the IRQ kernel object. What does this 
object do, how can we store/monitor it, and how can it be restored? 
Where can we find the source code which creates this object in Genode's 
bootstrap code?


Best regards,
Denis

On 11.12.2016 13:01, Denis Huber wrote:
> Hello Norman,
>
>> What you observe here is the ELF loading of the child's binary. As part
>> of the 'Child' object, the so-called '_process' member is constructed.
>> You can find the corresponding code at
>> 'base/src/lib/base/child_process.cc'. The code parses the ELF executable
>> and loads the program segments, specifically the read-only text segment
>> and the read-writable data/bss segment. For the latter, a RAM dataspace
>> is allocated and filled with the content of the ELF binary's data. In
>> your case, when resuming, this procedure is wrong. After all, you want
>> to supply the checkpointed data to the new child, not the initial data
>> provided by the ELF binary.
>>
>> Fortunately, I encountered the same problem when implementing fork for
>> noux. I solved it by letting the 'Child_process' constructor accept an
>> invalid dataspace capability as ELF argument. This has two effects:
>> First, the ELF loading is skipped (obviously - there is no ELF to load).
>> And second the creation of the initial thread is skipped as well.
>>
>> In short, by supplying an invalid dataspace capability as binary for the
>> new child, you avoid all those unwanted operations. The new child will
>> not start at 'Component::construct'. You will have to manually create
>> and start the threads of the new child via the PD and CPU session
>> interfaces.
>
> Thank you for the hint. I will try out your approach
>
>> The approach looks good. I presume that you encounter base-foc-specific
>> peculiarities of the thread-creation procedure. I would try to follow
>> the code in 'base-foc/src/core/platform_thread.cc' to see what the
>> interaction of core with the kernel looks like. The order of operations
>> might be important.
>>
>> One remaining problem may be that - even though you may by able the
>> restore most part of the thread state - the kernel-internal state cannot
>> be captured. E.g., think of a thread that was blocking in the kernel via
>> 'l4_ipc_reply_and_wait' when checkpointed. When resumed, the new thread
>> can naturally not be in this blocking state because the kernel's state
>> is not part of the checkpointed state. The new thread would possibly
>> start its execution at the instruction pointer of the syscall and issue
>> system call again, but I am not sure what really happens in practice.
>
> Is there a way to avoid this situation? Can I postpone the checkpoint by
> letting the entrypoint thread finish the intercepted RPC function call,
> then increment the ip of child's thread to the next command?
>
>> I think that you don't need the LOG-session quirk if you follow my
>> suggestion to skip the ELF loading for the restored component
>> altogether. Could you give it a try?
>
> You are right, the LOG-session quirk seems a bit clumsy. I like your
> idea of skipping the ELF loading and automated creation of CPU 

Re: GSOC 2017 - Project Enquiry

[Norman Feske]

Hello Arun,

thanks for your introduction and your interest in Genode!

The SAFEnet topic is quite challenging because none of the regular
Genode developers is acquainted with it. I added it to the challenges
page after a talk at this year's FOSDEM [1] caught my interest. In
contrast to most other topics of the list, there exists no tangible plan
of how to approach it. So we cannot provide concrete instructions of
what to do. We still figured that - for someone who already has profound
insights into SAFEnet, and who enjoys explorative work on both an
architectural and an implementation level - the topic would be an
intriguing playground.

[1] https://fosdem.org/2017/schedule/event/safe_internet/

If you decide to go forward, your proposal should present a concrete
plan towards a prototype scenario that showcases how Genode ought to
interact with SAFEnet. The interesting questions are:

* Which software components must be made available on Genode? What
  are their requirements and how difficult is the porting work?
  Are there any missing gaps in Genode? E.g., should the SAFEnet
  implementation be written in JAVA, it won't make sense to start
  working on the SAFEnet topic before porting OpenJDK to Genode first.

* Pick one feature of SAFEnet and draft a Genode scenario that
  showcases its use with Genode. The goal of the GSoC project will be
  to implement the scenario and thereby to lay the groundwork for the
  future exploration of further functionality. E.g., one idea would be
  a Genode ROM service that fetches ROM modules as files from SAFEnet.
  But there are certainly other and possibly more exciting ideas. ;-)

* The proposal should describe how the project could potentially
  contribute not only to Genode but also to the goals of SAFEnet.
  Ideally, bringing both projects together won't be a one-way street
  but would have a cross-pollinating effect.

Cheers
Norman


On 27.03.2017 09:13, Arun Kumar wrote:
> Hi Mentors for GSOC,
> 
> My name is Arunkumar Ravichandran. I have been admitted to masters
> program in communications engineering at Univ of California, San
> Diego. I currently live in Chennai, India. I would love to work on a
> Genode project under the FOSDEM organization in GSOC 2017.
> 
> I would like to work on this project: integrating support for the SAFE
> network as a Genode component.
> 
> Already in Genode, all the components are provided access using the
> capabilities. Similarly SAFENET tries to achieve the same using the
> access tokens.
> 
> Could you please provide the scope/requirement for this implementation.
> Based on this, i can respond back with the design for implementing
> SAFEnet in Genode.
> 
> Thanks,
> Arun


-- 
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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Genode on i.MX6 (eMMC Flash)

[Kranthi Tej]

Hello,

We are using a i.MX6 based board. We have been able to run Android
successfully on the board. I've built the Genode demo image for the ARM
processor by using the Wandboard build configuration (hw_wand_quad). I have
successfully generated an image of Genode demo in the build directory named
"demo.img".

Can I load the generated Genode image onto the eMMC flash of the board
using MfgTool? If so, can you please guide me on how it can be done?

Thanks in advance,
Kranthi
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: [Genode] Suggestion about mailing list subject

[Christian Helmuth]

Hello all,

the resonance on this suggestion was mixed and mild with no decisive
majority. Therefore, I'll keep the configuration as is for now.

Greets
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

On Tue, Feb 07, 2017 at 11:08:25AM +0100, Christian Helmuth wrote:
> Hello Martín,
> 
> On Mon, Jan 30, 2017 at 07:57:33AM -0500, Martin Iturbide wrote:
> > I was wondering if it can be useful to configure the mailing list to
> > include on the subject (before the text) something like [Genode] or
> > [Genode-Main] . I know that it is easy to set a rule and folder for the
> > mailing list messages on the mail client, but in some other cases I like to
> > identify visually and fast the messages that are from this mailing list in
> > a group of mails.
> > 
> > This is just a thought, I don't know how hard or easy will be to configure
> > this on the sourceforge mailing lists.
> 
> Technically this is pretty simple by means of the Mailman
> subject_prefix feature. I personally do not like all subject lines
> written by users of the list cluttered with some prefix text. But, if
> other members of the list also express their demand for this feature
> and there's no overly resistance voiced I would enable it
> nevertheless.
> 
> Greets
> -- 
> Christian Helmuth
> Genode Labs
> 
> https://www.genode-labs.com/ · https://genode.org/
> https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
> 
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Socket fs

[Christian Helmuth]

Hello Boris,

On Mon, Mar 13, 2017 at 03:48:54PM +0100, Boris Mulder wrote:
> 1. In the release notes you describe the support for async file I/O.
> However, it seems that while asynchronous I/O works now, synchronous I/O
> is no longer possible. When I remove the select() call in the echo
> scenario, the call to recvfrom() will fail saying the socket is not
> connected (even though it is an UDP socket and should not have the
> notion of connections at all).
> 
> Of course this means it is not posix compatible; the intended behaviour
> is to block until data becomes available.

Thanks for your investigation. You're right the current state of
socket support has some rough edges (esp. POSIX-correct error
handling) that we plan to smoothen in near term. I'd like to invite
you to open an issue at Github to aggregate your findings.

> 2. Currently there are two ways an application can use tcp/ip sockets
> from the lxip stack: By using libc sockets, and by directly opening a
> file system session and writing to the right socket files. For any new
> Genode application that does not already depend on libc, the first way
> means you unnecessarily add the entirety of libc to your component. So
> the second way seems preferred. 
> 
> However, when programming an application using a file system session 
> directly adds a lot of code with many open()s, read()s and write()s that
> could be abbreviated into single calls such as connect() and recv(). 
> Have you thought of providing a more convenient API (such an 
> object-oriented Socket class that hides the vfs calls from the 
> application programmer)? Or do you consider using the fs session
> interface to be better? If so, why?

We do not plan to implement an abstraction layer or object-oriented
Socket interface currently. The mere reason for our recent
developments was to enable more POSIX network applications to run on
Genode and to support those components to share one network stack.
Also, we imagine to mount the socket FS into Noux and use traditional
tools in shell scripts to interoperate with the network.

I must admit that we (the Genode Labs team) do not assess ourselves as
networking experts and, therefore, don't fancy to design and implement
such a library. But as always nothing is set in stone and priorities
may shift over time.

Regards
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode on i.MX6Q Sabre Lite

[Stefan Kalkowski]

Hi,

On 03/27/2017 09:14 AM, Yevgeny Lavrov wrote:
> Excellent :) Thank you for guiding me through it. Is there anything else
> in Genode, other than log that I can try on Sabre Lite to make sure that
> it works?

The following run-scripts run successfully each night on the Wandboard,
and therefore should succeed on your board too:

affinity
blk_cache
bomb
clipboard
cpu_quota
cpu_sampler
ds_ownership
fault_detection
fpu
fs_log
init
ldso
libc_getenv
libc_pipe
libc_vfs
libc_vfs_block
libc_vfs_ext2
libc_vfs_fs
libc_vfs_ram
moon
new_delete
nic_loopback
noux
part_blk
pthread
ram_fs_chunk
reconstructible
report_rom
resource_request
resource_yield
rm_fault
rom_blk
rom_filter
rump_ext2
rust
sd_card_bench
signal
sub_rm
synced_interface
trace
util_mmio
xml_generator
xml_node

However, the only test here that deals with hardware beside the CPU or
timer is the sd_card_bench test. There is almost no peripheral device
driver support available for Genode on i.MX6 except the SD-card driver.
So if you want to run more sophisticated setups including graphics,
network, or input you could concentrate on writing or porting related
drivers first.

Best regards
Stefan

> My current goal is to get Genode running on top of seL4 micro kernel on
> ARM platform. I'm aware that Genode/seL4 support for ARM is scheduled
> for August 2017, but maybe there's anything that I can start
> experimenting with now?
> 
> Thank you
> 
> On Thu, Mar 23, 2017 at 4:15 AM, Stefan Kalkowski
>  > wrote:
> 
> Hi,
> 
> On 03/23/2017 04:10 AM, Yevgeny Lavrov wrote:
> > I've made the necessary changes to UART variables, and lowered the
> > amount of RAM by making RAM0_SIZE = 0x2000. After executing the
> > image.elf on Sabre Lite, I got the following output:
> >
> > ## Starting application at 0x10001000
> > ...
> >
> > :virt_alloc: Allocator 0x200f40b4
> > dump:
> >
> >  Block: [0x1000,0x10001000] size=0x1000 avail=0x1000
> > max_avail=0x1000
> >
> >  Block: [0x105ad000,0x20001000] size=0xfa54000 avail=0xfa54000
> > max_avail=0xbfe5b000
> >
> >  Block: [0x201a4000,0x201a5000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x201a5000,0xe000] size=0xbfe5b000 avail=0xbfe5b000
> > max_avail=0xbfe5b000
> >
> >  Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0
> > max_avail=0xbfe5b000
> >
> >  Block: [0xf0007000,0xf0008000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0xf0009000,0xf000a000] size=0x1000 avail=0x0
> > max_avail=0xffe5000
> >
> >  Block: [0xf000a000,0xfffef000] size=0xffe5000 avail=0xffe5000
> > max_avail=0xffe5000
> >
> >  => mem_size=4018765824 (3832 MB) / mem_avail=4018749440 (3832
> > MB)
> >
> >
> >
> > :phys_alloc: Allocator 0x200f3048
> > dump:
> >
> >  Block: [0x1061f000,0x1062] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x1062,0x10621000] size=0x1000 avail=0x0
> > max_avail=0x1f9dd000
> >
> >  Block: [0x10621000,0x10622000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x10622000,0x10623000] size=0x1000 avail=0x0
> > max_avail=0x1f9dd000
> >
> >  Block: [0x10623000,0x3000] size=0x1f9dd000 avail=0x1f9dd000
> > max_avail=0x1f9dd000
> >
> >  => mem_size=530452480 (505 MB) / mem_avail=530436096 (505
> > MB)
> >
> >
> >
> > :io_mem_alloc: Allocator 0x200f512c
> > dump:
> >
> >  Block: [0x0,0x1061f000] size=0x1061f000 avail=0x1061f000
> > max_avail=0xcfff
> >
> >  Block: [0x3000,0x] size=0xcfff avail=0xcfff
> > max_avail=0xcfff
> >
> >  => mem_size=3764514815 (3590 MB) / mem_avail=3764514815 (3590
> > MB)
> >
> >
> >
> > :io_port_alloc: Allocator 0x200f6198
> > dump:
> >
> >  => mem_size=0 (0 MB) / mem_avail=0 (0
> > MB)
> >
> >
> >
> > :irq_alloc: Allocator 0x200f7204
> > dump:
> >
> >  Block: [0x0,0x1] size=0x1 avail=0x1
> > max_avail=0x1
> >
> >  Block: [0x2,0x1d] size=0x1b avail=0x1b
> > max_avail=0x3e2
> >
> >  Block: [0x1e,0x400] size=0x3e2 avail=0x3e2
> > max_avail=0x3e2
> >
> >  => mem_size=1022 (0 MB) / mem_avail=1022 (0
> > MB)
> >
> >
> >
> > :rom_fs: ROM
> > modules:
> >
> >  ROM: [101a6000,101a6158)
> > config
> >
> >  ROM: [10182000,101a2178)
> > init
> >
> >  ROM: [10105000,101819a4) ld.lib.so 
> > 
> >
> >  ROM: [101a3000,101a5598)
> > test-log
> >
> >
> >
> >
> > kernel
> > initialized
> >
> > Genode
> > 17.02
> >
> > 504 MiB RAM assigned to
> > init
> >
> > [init -> test-log] hex range:
> > 

Re: Genode on i.MX6Q Sabre Lite

[Yevgeny Lavrov]

Excellent :) Thank you for guiding me through it. Is there anything else in
Genode, other than log that I can try on Sabre Lite to make sure that it
works?
My current goal is to get Genode running on top of seL4 micro kernel on ARM
platform. I'm aware that Genode/seL4 support for ARM is scheduled for
August 2017, but maybe there's anything that I can start experimenting with
now?

Thank you

On Thu, Mar 23, 2017 at 4:15 AM, Stefan Kalkowski <
stefan.kalkow...@genode-labs.com> wrote:

> Hi,
>
> On 03/23/2017 04:10 AM, Yevgeny Lavrov wrote:
> > I've made the necessary changes to UART variables, and lowered the
> > amount of RAM by making RAM0_SIZE = 0x2000. After executing the
> > image.elf on Sabre Lite, I got the following output:
> >
> > ## Starting application at 0x10001000
> > ...
> >
> > :virt_alloc: Allocator 0x200f40b4
> > dump:
> >
> >  Block: [0x1000,0x10001000] size=0x1000 avail=0x1000
> > max_avail=0x1000
> >
> >  Block: [0x105ad000,0x20001000] size=0xfa54000 avail=0xfa54000
> > max_avail=0xbfe5b000
> >
> >  Block: [0x201a4000,0x201a5000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x201a5000,0xe000] size=0xbfe5b000 avail=0xbfe5b000
> > max_avail=0xbfe5b000
> >
> >  Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0
> > max_avail=0xbfe5b000
> >
> >  Block: [0xf0007000,0xf0008000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0xf0009000,0xf000a000] size=0x1000 avail=0x0
> > max_avail=0xffe5000
> >
> >  Block: [0xf000a000,0xfffef000] size=0xffe5000 avail=0xffe5000
> > max_avail=0xffe5000
> >
> >  => mem_size=4018765824 (3832 MB) / mem_avail=4018749440 (3832
> > MB)
> >
> >
> >
> > :phys_alloc: Allocator 0x200f3048
> > dump:
> >
> >  Block: [0x1061f000,0x1062] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x1062,0x10621000] size=0x1000 avail=0x0
> > max_avail=0x1f9dd000
> >
> >  Block: [0x10621000,0x10622000] size=0x1000 avail=0x0
> > max_avail=0x0
> >
> >  Block: [0x10622000,0x10623000] size=0x1000 avail=0x0
> > max_avail=0x1f9dd000
> >
> >  Block: [0x10623000,0x3000] size=0x1f9dd000 avail=0x1f9dd000
> > max_avail=0x1f9dd000
> >
> >  => mem_size=530452480 (505 MB) / mem_avail=530436096 (505
> > MB)
> >
> >
> >
> > :io_mem_alloc: Allocator 0x200f512c
> > dump:
> >
> >  Block: [0x0,0x1061f000] size=0x1061f000 avail=0x1061f000
> > max_avail=0xcfff
> >
> >  Block: [0x3000,0x] size=0xcfff avail=0xcfff
> > max_avail=0xcfff
> >
> >  => mem_size=3764514815 (3590 MB) / mem_avail=3764514815 (3590
> > MB)
> >
> >
> >
> > :io_port_alloc: Allocator 0x200f6198
> > dump:
> >
> >  => mem_size=0 (0 MB) / mem_avail=0 (0
> > MB)
> >
> >
> >
> > :irq_alloc: Allocator 0x200f7204
> > dump:
> >
> >  Block: [0x0,0x1] size=0x1 avail=0x1
> > max_avail=0x1
> >
> >  Block: [0x2,0x1d] size=0x1b avail=0x1b
> > max_avail=0x3e2
> >
> >  Block: [0x1e,0x400] size=0x3e2 avail=0x3e2
> > max_avail=0x3e2
> >
> >  => mem_size=1022 (0 MB) / mem_avail=1022 (0
> > MB)
> >
> >
> >
> > :rom_fs: ROM
> > modules:
> >
> >  ROM: [101a6000,101a6158)
> > config
> >
> >  ROM: [10182000,101a2178)
> > init
> >
> >  ROM: [10105000,101819a4) ld.lib.so
> > 
> >
> >  ROM: [101a3000,101a5598)
> > test-log
> >
> >
> >
> >
> > kernel
> > initialized
> >
> > Genode
> > 17.02
> >
> > 504 MiB RAM assigned to
> > init
> >
> > [init -> test-log] hex range:
> > [0e00,1680)
> >
> > [init -> test-log] empty hex range:[0abc,0abc)
> > (empty!)
> >
> > [init -> test-log] hex range to limit:
> > [f8,ff]
> >
> > [init -> test-log] invalid hex range:  [f8,08)
> > (overflow!)
> >
> > [init -> test-log] negative hex char:
> > 0xfe
> >
> > [init -> test-log] positive hex char:
> > 0x02
> >
> > [init -> test-log] multiarg string:"parent ->
> > child.7"
> >
> > [init -> test-log] String(Hex(3)):
> > 0x3
> >
> > [init -> test-log] Test done.
> >
> > Is this the desired output from "log"?
> >
> > Thanks
>
> Exactly!
>
> Regards Stefan
>
> >
> > On Wed, Mar 22, 2017 at 6:56 AM, Stefan Kalkowski
> >  > > wrote:
> >
> > Hi,
> >
> > On 03/22/2017 08:14 AM, Yevgeny Lavrov wrote:
> > > Hi
> > >
> > > Thanks for the hint. You're correct about the UART, they are
> different.
> > > Wand uses UART1 = 0x0202 while Sabre Lite uses UART2 which is
> 0x021e800.
> > > I tried Genode 15.02 from the institute of
> > > Madras:|https://github.com/iitmadras/genode/tree/hw_
> sabrelite_tz_support
> > 
> > >  >  >>|,
> > > simple run/printf for now, and it works. I currently use it as a
> > > reference. After comparing board_base.h files for i.MX6 platform, I
> > > noticed that specifically for Sabre Lite the values in the
> board_base.h
> > 

GSOC 2017 - Project Enquiry

[Arun Kumar]

Hi Mentors for GSOC,

My name is Arunkumar Ravichandran. I have been admitted to masters
program in communications engineering at Univ of California, San
Diego. I currently live in Chennai, India. I would love to work on a
Genode project under the FOSDEM organization in GSOC 2017.

I would like to work on this project: integrating support for the SAFE
network as a Genode component.

Already in Genode, all the components are provided access using the
capabilities. Similarly SAFENET tries to achieve the same using the
access tokens.

Could you please provide the scope/requirement for this implementation.
Based on this, i can respond back with the design for implementing
SAFEnet in Genode.

Thanks,
Arun

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main