users

users@lists.genode.org

2285 discussions

Re:Simple demo doesn´t work
by unknown＠example.com 18 May '14

18 May '14

Hello Christian, thank you for the patch. You are right, the video system could not be initialized. Applying your patch changed the output of the make command slightly in the following way: make[1]: Leaving directory `/opt/genode-14.02/build.lx' genode build completed spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 4095 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" No protocol specified No protocol specified [init -> launchpad] Could not open file "ld.lib.so" [init -> fb_sdl] SDL_SetVideoMode failed [init] virtual void Genode::Child_policy::exit(int): child exited with exit value 0 The following software components regarding libSDL are available on my system: libSDL-1_2-0 libSDL-devel libSDL_gfx13 DirectFB-libSDL Do you have any suggestions for tackling this issue ? Best regards, Markus

3 2

Simple demo doesn´t work
by unknown＠example.com 16 May '14

16 May '14

Hello everyone, although I was successful in installing Genode and the tool chain, I did not manage to get the simple demo running. I followed the instructions given in 'Quick start to build Genode for Linux'. When I tried to run the demo, I did not see anything but the following output: linux-tsju:/opt/genode-14.02/build.lx # make run/demo using run script /opt/genode-14.02/base-linux/run/env using run script /opt/genode-14.02/os/run/demo.run building targets: core init drivers/timer server/nitpicker server/liquid_framebuffer app/launchpad app/scout test/nitpicker server/nitlog drivers/framebuffer drivers/pci drivers/input spawn make core init drivers/timer server/nitpicker server/liquid_framebuffer app/launchpad app/scout test/nitpicker server/nitlog drivers/framebuffer drivers/pci drivers/input make[1]: Entering directory `/opt/genode-14.02/build.lx' checking library dependencies... Skip target drivers/framebuffer/exynos5 because it requires exynos5 Skip target drivers/framebuffer/imx53 because it requires imx53 Skip target drivers/framebuffer/omap4 because it requires omap4 Skip target drivers/framebuffer/pl11x/pbxa9 because it requires pl11x platform_pbxa9 Skip target drivers/framebuffer/pl11x/vea9x4 because it requires pl11x platform_vea9x4 Skip target drivers/framebuffer/pl11x/vpb926 because it requires pl11x platform_vpb926 Skip target drivers/framebuffer/rpi because it requires platform_rpi Skip target drivers/input/imx53 because it requires imx53 Skip target drivers/input/ps2/pl050 because it requires pl050 Skip target drivers/input/ps2/x86 because it requires ps2 Skip target drivers/pci/device_pd because it requires nova Library platform Library syscall Library startup Library cxx Library base-common Library base Library launchpad Library blit Library scout_gfx Library scout_widgets Library config Program app/launchpad/launchpad Library mini_c Library libz_static Library libpng_static Program app/scout/scout Program core/core Library lx_hybrid Program drivers/framebuffer/sdl/fb_sdl Program drivers/input/dummy/dummy_input_drv Program drivers/pci/x86/pci_drv Library alarm Library timer Program drivers/timer/timer Library init_pd_args Program init/init Program server/liquid_framebuffer/liquid_fb Program server/nitlog/nitlog Library server Program server/nitpicker/nitpicker Program test/nitpicker/testnit make[1]: Leaving directory `/opt/genode-14.02/build.lx' genode build completed spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 4095 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "ld.lib.so" No protocol specified No protocol specified [init -> fb_sdl] creating virtual framebuffer for mode 1024x768@...64... [init -> nitpicker] create session with args: label="launchpad", ram_quota=12288 By the way, to get into Genode I set up a virtual machine running openSUSE 13.1. The virtual machine is assigned a memory space of 4 GB. According to a posting in the Genode forum the error message 'Could not open file "ld.lib.so"' can be neglected in this case. Do you have any ideas for what I could do to get the simple demo running ? Best regards Markus

2 1

Docker app containers for Genode?
by Peter Lindener 13 May '14

13 May '14

RedHat<http://www.redhat.com/about/news/press-archive/2014/4/red-hat-docker-expand…>, and Ubuntu<http://www.infoworld.com/t/linux/ubuntu-chases-after-red-hat-openstack-and-…>bot seem to be incorporating Docker <https://www.docker.io/>'s application packaging into there plans...any thoughts on how Docker might come to influence Genode's longer term road-map? -Peter

4 7

ARM TrustZone TZASC Vs TZPC
by mohamed sabt 09 May '14

09 May '14

Hello, I'm reading the article "An Exploration of ARM TrustZone Technology" and a question was raised into my head when I reached the subsection "TZPC and TZASC". It is mentioned that by experimenting with the Versatile Express platform some insights were discovered. Namely, TZASC secures physical addresses via SMC (Static Memory Controller), while TZPC secures physical addresses via DMC (Dynamic MC). In summary, TZASC secures on-chip RAM, namely SRAM; and TZPC secures off-chip RAM, namely DRAM. I don't know if you're familiar with ARM TrustZone documentation, but in this white paper of ARM http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-G…, it is mentioned in the sections 4.1.4 and 4.1.7 the opposite of what was mentioned by your article. I look forward to your answer about this. I am studying the TrustZone architecture and reading this has just bugged me. I don't if I miss something here. Thank you in advance, Mohamed Sabt

2 1

Changed directory layout
by Norman Feske 07 May '14

07 May '14

Hello, as discussed in the issue "Source-code package management" [1], I changed the directory layout of Genode's source tree in the staging branch [2]. [1] https://github.com/genodelabs/genode/issues/1082 [2] https://github.com/genodelabs/genode/tree/staging All source-code repositories that formerly resided at the top level of the tree have been moved to the 'repos/' subdirectory. Changing the top-level directory layout raises the question of how to rebase existing topic branches on top of the new version. Fortunately, at least in a few cherry-picking experiments I did, git dealt very well with the situation. Still, we should pay special care with merging topic branches into mainline now. The new source-tree layout has the nice benefit that I could make the BUILD_DIR argument of the create_builddir tool optional. If no BUILD_DIR argument is supplied, the tool will create the build directory at '<genode-dir>/build/<platform>'. It would be worthwhile to revisit our documentation to simplify the steps to create build directories. I hope the transition to the new new directory layout will be free of major trouble. If you have strong concerns, now (as the patch is not yet in the master branch) is the time to raise them. ;-) 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

3 3

genome and i.mx53 quick start board
by Sileshi Demesie 30 Apr '14

30 Apr '14

Dear Sir/Madam, I am working on i.mx53 quick start board to manage the trust zone technology. I want to install genode on top of ubuntu or android so that I can run genode in the secure world and ubuntu/Android in the normal world. If can these two worlds , then I can to run trusted applications in the secure world(genode). Could you please give me brief explanation on how I can manage those things? thank you in advance. regards, Sileshi

2 1

AW: AW: Block Cache
by Wolfgang Schmidt 30 Apr '14

30 Apr '14

Hi, The last time the build Problem was mit on Hardware, but on building it with the run/Demo for qemu. This now works after the comments. What haven't worked right now is using the live cd on real hardware. ( neither older L4 mir newer Linux live Demo) So I asked to know wether a specific Plattform is known to work as I habe no Nova knowledge so far ( to reduce the risk of asking to many stupid questions). Of I understand You correctly the was of using a filesystem with cache wozld be ahci as driver -> blockcache as server -> rump_fs as single client of the blockcache and as server for -> multiple programs accessing files. Is this correct? Best regards Wolfgang ----- Ursprüngliche Nachricht ----- Von: "Stefan Kalkowski" <stefan.kalkowski@...1...> Gesendet: ‎29.‎04.‎2014 09:37 An: "genode-main(a)lists.sourceforge.net" <genode-main(a)lists.sourceforge.net> Betreff: Re: AW: Block Cache Hi Wolfgang On 04/28/2014 10:25 PM, Wolfgang Schmidt wrote: > Hi Stefan, > Can You give a gibt for compatible x86 hw? I tried The democd on an FSC > Athlon64 which did mit start at all. Does for example a comp list for > nova exist? No, I've no compatibility list available. I know of quite different Intel PCs people are using doing experiments with Genode/NOVA. What do you mean with it didn't start at all on your specific hardware? The last time I've read an email from you regarding problems with NOVA on real hardware, it failed to compile the framebuffer driver, because your third-party-code "libports" repository probably wasn't prepare accordingly. Maybe it's better to smooth build problems out, instead of searching for new hardware? > > What so You mean with: it serves only one client- one client application? I meant, the block cache acts like a block driver. In general a block driver in Genode serves only one client, e.g.: a filesystem server. If you want to share the same device with multiple clients, you might use the "part_blk" server, which provides different partitions, found on the device, as separate block sessions to different clients. Does that clarifies your question? Regards Stefan > > Best regards > Wolfgang > ------------------------------------------------------------------------ > Von: Stefan Kalkowski <mailto:stefan.kalkowski@...1...> > Gesendet: ‎28.‎04.‎2014 21:13 > An: genode-main(a)lists.sourceforge.net > <mailto:genode-main@lists.sourceforge.net> > Betreff: Re: Block Cache > > Hi Wolfgang, > > On 04/28/2014 08:27 PM, w_schmidt@...181... wrote: >> Hello,, >> >> I have a few question regarding genodes block cache in 14.02. >> >> If understand it correctly on x86-based computers genode starts on top of >> linux. > > well, that's not true. Yes, Genode is able to run on top of Linux, > mostly for development purposes. But Genode runs also directly on x86 > hardware using the NOVA kernel, or Fiasco.OC kernel, or the OKL4 kernel, > or Pistachio kernel. > >> Therefore multiple caches will be used before something goes to genode >> a) the cache on a hdd >> b) cache on a drive controller >> c) the linux block cache > > If running on Linux yes, but normally it wouldn't make much sense to use > an additional block cache here. > >> d) qemu > > As already said: you don't need to use Qemu. Most run scripts are > starting Qemu by default, for convenience reasons only. > >> >> The first one is about the scenario in which the block cache is used. >> Is the block cache only thought for embedded devices where genode runs >> nativly? Are all embeded devices usable with the cache? > > The block cache uses the block session of Genode. It uses exactly one > block device, and serves exectly one client. As all block device drivers > of Genode are implementing the block session interface, the block cache > can be used on top of all block drivers, whether its a x86 AHCI driver, > or MMC card driver of an ARM SoC, or whatever. > >> >> Is there a way to mount a partition in genode with qemu without using > caches >> from c) and d) ? >> Or is there a x86 hardware where genode can directly operate on? > > Qemu allows to define the caching policy of a hard drive (cache=none). I > don't know whether it's possible to circumvent Linux block cache. I > assume that's hard. > But as mentioned above, you can use conventional x86 PC hardware. > > Regards > Stefan > >> >> As far as I have seen so far the disc cache of Linux does not seem to be >> disablable. I have only foudn ways to flush linux cache (like sync && > echo 3 >> > /proc/sys/vm/drop_caches). >> >> Best regards, >> Wolfgang >> >> >> > ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform > available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Genode-main mailing list >> Genode-main(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main >> > > -- > Stefan Kalkowski > Genode Labs > > http://www.genode-labs.com/ · http://genode.org/ > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > > > > _______________________________________________ > Genode-main mailing list > Genode-main(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Genode-main mailing list Genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

2 1

manually constructing the type list of RPC functions
by Mhamad Hmad 28 Apr '14

28 Apr '14

hi , the RPC function number in each interface is limited by 9 , I have more than 9 functions . Genode have away to do that by manually constructing the type list of RPC functions instead of using the convenience macro typedef Meta::Type_tuple<Rpc_myfunc1, Meta::Type_tuple<Rpc_myfunc2, Meta::Empty> > Rpc_functions; I add that to my intrface session but i get the next error *error: ‘Meta’ does not name a type* and another error * no type named ‘Rpc_functions’ in ‘struct myrpcsession::Session’* I looked to the "cpu_session.h" and tried to do same but i think i miss some thing . any clue? best , mohammad

2 4

make run/demo stop unexpectedly
by Sun Keqin 28 Apr '14

28 Apr '14

Hi, My colleague met a very strange problem today, so I ask for help. There is an error when he run "make run/demo” in build directory, however, when he run "qemu-system-i386 -no-kvm -m 256 -serial mon:stdio -cdrom var/run/demo.iso" directly, it works successfully. Do you know why it happened? What should I do to fix that? Here is the details. genode build completed using fiasco kernel /home/jimmy/work/os/genode/build/kernel/fiasco.oc/fiasco using sigma0/bootstrap at /home/jimmy/work/os/genode/build/l4 creating ISO image... spawn qemu-system-i386 -no-kvm -m 256 -serial mon:stdio -cdrom var/run/demo.iso L4 Bootstrapper Build: #1 2014: spawn id exp6 not open while executing "expect { -i $running_spawn_id -re $wait_for_re { } eof { puts stderr "Error: Spawned process died unexpectedly"; exit -3 } timeout { puts ..." (procedure "wait_for_output" line 11) invoked from within "wait_for_output $wait_for_re $timeout_value $qemu_spawn_id" (procedure "spawn_qemu" line 51) invoked from within "spawn_qemu $wait_for_re $timeout_value" (procedure "run_genode_until" line 18) invoked from within "run_genode_until forever" (file "/home/jimmy/work/os/genode/genode-13.05/os/run/demo.run" line 139) invoked from within "source $include_name" ("foreach" body line 3) invoked from within "foreach include_name [get_cmd_arg --include ""] { puts "using run script $include_name" source $include_name }" (file "/home/jimmy/work/os/genode/genode-13.05/tool/run" line 730) Cheers, keqin

4 4

Major revision of the C runtime (VFS)
by Norman Feske 28 Apr '14

28 Apr '14

Hello, I have just merged a significant change of the C runtime into our staging branch. Because this change will likely affect users of the framework (hopefully for the better ;-), I'd like to bring up this topic here. Since many years, our C runtime served us quite well, thanks to the plugin architecture that allows us to combine different backends such the lwIP socket API using libc_lwip_nic_dhcp, using LOG as stdout via libc_log, or using a ROM dataspace as a file via libc_rom. However, the original design of the plugin architecture is starting to show its limitations. Examples of the current limitations: * There is a libc_fs plugin that allows a program to access files from a file-system server. But there is no way to allow one program to access two different file-system servers. * There is a libc_block plugin that hands out a block session as a pseudo block device named '/dev/blkdev'. However, when combined with libc_fs, it is not defined which of both plugins will handle the file with this name. As a quick and dirty work-around, the libc_fs plugin explicitly black-lists '/dev/blkdev'. * In general, if multiple plugins are combined, there is no consistent virtual file system structure exposed via getdirentries. * There is no flexible concept for handling stdio. Most programs use libc_log to direct stdout to the LOG service. But what if we want to direct the output of such a program to a terminal? Granted, there exists the 'terminal_log' server to translate a LOG session to a terminal session but it would be much nicer to have this flexibility at the C runtime level. * Many libc plugins look similar. There are quite a few dusty corners where duplicated code has been accumulated over the years. That said, the semantic details (e.g., the quality of error handling) differ from plugin to plugin. Seeing the number of file systems (and thereby the number of added libc plugins) growing, it became apparent that our original design would not scale too well. On the other hand, we have gathered very positive experiences with the virtual file system implementation of Noux. It allows to us have a coherent VFS with support for stacked file systems (similar to union mounts) of various types. The VFS of Noux is stable and complete enough to accommodate our tool chain. Wouldn't it be a good idea to reuse the Noux VFS for the normal libc? This line of thoughts led to the following issue: https://github.com/genodelabs/genode/issues/999 The result of this line of work has been merged into the staging branch now. I adapted most of the run scripts and targets to the changed libc but certainly missed a few bits. I.e., the following run scripts remain untested and are expected to fail in one way of another: * http_srv_tracing_nonblocking_panda * qt_avplay (the qt4 version) * netperf * l4linux_dynamic * noux_gdb_dynamic * debug_nitpicker * noux_gdb * virtualbox * virtualbox_auto I would appreciate your help to rectify them, so that we can merge the staging branch to the master branch soon. How has the libc changed? Each libc-using program can be configured with a program-local virtual file system as illustrated by the following example: <config> ... <libc stdin="/dev/null" stdout="/dev/log" stderr="/dev/log"> <vfs> <dir name="dev"> <log/> <null/> </dir> <dir name="etc"> <dir name="lighttpd"> <inline name="lighttpd.conf"> ... </inline> </dir> </dir> <dir name="website"> <tar name="website.tar"/> </dir> </vfs> </libc> </config> Here you see a lighttpd server that serves a website coming from a TAR archive (which is obtained from a ROM module named "website.tar"). There are two pseudo devices "/dev/log" and "/dev/null", to which the "stdin", "stdout", and "stderr" attributes refer. The "log" file system consists of a single node that represents a LOG session. The web server configuration is supplied inline as part of the config. (Btw, you can try out a very similar scenario using the 'ports/genode_org.run' script) The VFS implementation resides at 'os/include/vfs/'. This is where you can see the file system types that are available (look for '*_file_system.h' files). Because the same code is used by Noux, we have one unified and coherent VFS implementation throughout the framework now. There are two things needed to adapt your work to the change. * Remove the use of the libc_{rom, block, log, fs} plugins from your target description files. Those plugins are no more. As of now, the VFS is still internally a plugin, but it is always included with the libc. * Configure the VFS of your libc-using program in your run script. For most former users of the sole libc_log plugin, this configuration looks like this: <config> <libc stdout="/dev/log" stderr="/dev/log"> <vfs> <dir name="dev"> <log/> </dir> </vfs> </libc> </config> For former users of the other plugins, there are the 'block', 'rom', and 'fs' file-system types available. I hope that you will like the new VFS infrastructure. If you have any questions, bug reports, or critique, feedback is always welcome. 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

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users