users

users@lists.genode.org

1 participants
2322 discussions

make run/printf in the 14.05 version
by Bob Stewart 31 May '14

31 May '14

I just cloned the 14.05 version and did a create_builddir. From the created build directory I did a basic "make run/printf". That immediately gave me the following error: *using run script --include** **couldn't read file "--include": no such file or directory** ** while executing** **"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 "/Work/Genode/genode-14.05/tool/run" line 850)** **make: *** [run/printf] Error 1* I had no command line parameters other than the make run... What have I missed? Thanks, Bob.

3 7

Announcement: Genode OS Framework version 14.05 released
by Christian Helmuth 30 May '14

30 May '14

Genode 14.05 comes with a strong focus on framework scalability. We extend our C runtime with per-process virtual file system support. Now, programs seamlessly integrate with separate file-system services to distinct concerns like web-server configuration and data. Also, we introduce a new concept for integrating third-party software in form of one unified port tool. The highlights of the fresh release are - New tools for managing ported 3rd-party source code - New block-level encryption using CDG - New process-local virtual file systems - NOVA microhypervisor - VirtualBox with guest additions - Support for static priorities - Execution on bare hardware (base-hw) - Multi-processor support - Sparsely populated core address space - USB 3.0 on x86-based platforms More detailed information can be found in the release documentation http://genode.org/documentation/release-notes/14.05 Happy hacking with Genode -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://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

2 2

VMM for base-hw on ARM
by S Madhu 29 May '14

29 May '14

Is there any virtualization support for ARM on the base-HW platform ? We need a trustzone enabled kernel, so the base-HW platform on the Freescale i.Mx6 is the ideal platform for us. We plan to run a virtualized version of Android on top of this. So we need support for a paravirtulaized Linux. later we plan to port the Android VM directly on to the base-hw kernel so we will not need VMM support but that is not a trivial task so plan to first run a virtualized Linux first since that involved no major changes to the Android run-time. Was wondering if we had to add the VMM support ourselves or if there was something that was added in today's 14.05 release ? Madhu

2 3

Trustzone on i.MX6 sabrelite
by S Madhu 25 May '14

25 May '14

Copying an email exchange between me and Norman to teh mailing list. I have a few master's students who are starting to work on Trustzone, so I am trying to find out the best way to get them up and running. Target platform is the i.MX6 Sabrelite board from Freescale. later we will move to our own open source i.MX6 board. ----------------------------------------------------------------------------------- Hello, > My student started work today. I have asked him to post on the group. > I am defining the scope of work for him for the next 1 year. Basically I > want > him to complete the trustzone integration on the i.MX6 board. Do you > think there is 6-8 months of work left for 1 person in this effort ? the answer very much depends on the experience of the developer and degree of trustzone support you want to achieve. Given that base-hw support trustzone on the Cortex-A9 already (for the Versatile Express platform) and also the i.MX53 SoC, I don't expect any difficulties to get the TZ world switch running in principle. If you really care about thoroughly protecting the secure world from the normal world, however, there is much more work to do. E.g., in our current demo scenario, we cut some corners, which might not be good idea in a real product. E.g. we grant the normal world access to the system-and-clock management unit. Revoking access to this unit from the normal world is easy. But to get Linux running w/o access to it is quite difficult. We'd need to either provide a virtualized version of the device (using a trap-and-emulate scheme) or change the Linux kernel to use custom smc "hypercalls" to the TZ VMM instead of accessing the device directly. Also, as an additional challenge, it would be worthwhile to investigate a solution for the problem described in the last paragraphs of the Section "Additional device drivers" of our article: http://genode.org/documentation/articles/trustzone#Additional_device_drivers The DMA problem (GPU and IPU are using the same DMA channel) is quite serious. It would be interesting to investigate if i.MX6 has fixed that. To sum it up, the task can be scaled from a few months (just experimenting with the world switch and granting most devices to the normal world) to more than a year (when revoking devices from the normal world while still making Linux happy to run in the normal world). --------------------------------------------------------------------------------- Madhu

1 1

Re: Hi~ I am ajblane. I have a question. Please, help me.
by Christian Helmuth 23 May '14

23 May '14

Hello ajblane, I hope you don't mind that I take this to our mailing list https://lists.sourceforge.net/lists/listinfo/genode-main The list is the primary discussion forum for Genode related questions. For further questions, other developers have the chance to offer a helping hand. So, please subscribe using the link above. Regarding your current issue: Do you use a 64-bit Linux installation? Currently, our GDB port is limited to 32-bit and supported platforms are me@...246...:genode.git> (cd ports/lib/mk; find -name "gdbserver_platform.mk") ./foc_arm/gdbserver_platform.mk ./pistachio_x86/gdbserver_platform.mk ./foc_x86_32/gdbserver_platform.mk ./linux_x86_32/gdbserver_platform.mk ./fiasco_x86/gdbserver_platform.mk ./okl4_x86/gdbserver_platform.mk ./nova_x86_32/gdbserver_platform.mk Regards -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://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 Fri, May 23, 2014 at 11:09:43AM +0800, ch ajblane wrote: > Dear sir: > I want to use Qemu's GDB stub to debug, so I read these articles which > are "How to start exploring Genode" and "User- level debugging on Genode > via GDB". > > > I do six steps as follow, but the six step can't work. > > step 1: > cd <genode-dir> > > ./tool/create_builddir linux_x86 BUILD_DIR=build.lx > > step 2: > > cd build.lx > make run/demo > > step 3: > Change to the ports repository and issue the following command > make prepare PKG=gdb > > step 4: > Change to the libports repository and issue the following command > make prepare > > step 5: > Change to the qt4 repository and issue the following command > make prepare > > step 6: > Change to the build directory and issue the following command > make app/gdb_monitor > > But step 6 can't work. it's error message is > > checking library dependencies... > Library-description file gdbserver_platform.mk is missing > > My question is how to let step 6 can work. > Please help me. Thanks. > > Best regard. > > About me: > My name: ajblane > I am a P.H.D student. > My school: http://www.cs.ccu.edu.tw/english/ > My Hackpad: https://genode_for_fun.hackpad.com/ > My github: https://github.com/ajblane

3 4

Management of ported 3rd-party software
by Norman Feske 22 May '14

22 May '14

Hello, now that Genode's new directory structure is in place, let's take the next step towards a bullet-proof solution for integrating 3rd-party code with Genode (see [1] for the corresponding issue). The new solution, which is very much inspired by the fabulous Nix package manager [2] comes in the form of new tools to be found at 'tool/ports/' on the staging branch [3]. [1] https://github.com/genodelabs/genode/issues/1082 [2] http://nixos.org/nix/ [3] https://github.com/genodelabs/genode/commits/staging Hereby, I'd like to briefly explain how the new solution works from the viewpoint of a Genode user, describe the steps needed to add a new port to Genode, and outline how we will evolutionary move from the old 'make prepare' mechanism to the new concept. Note that even though the port mechanism described herein looks a bit like "package management", it covers a different problem. The problem covered here is the integration of existing 3rd-party source code with the Genode source tree. Packaging, on the other hand, would provide a means to distribute self-contained portions of the Genode source tree including their respective 3rd-party counterparts as separate packages. Package management is not addressed yet. The use of the new mechanism ---------------------------- Genode's source-code repositories used to come with Makefiles in their respective base directories. Those makefile provided the rules 'prepare' and 'clean'. The 'prepare' rule allowed for the automated downloading and installation of 3rd-party code, whereas the 'clean' rule reverted the installation. Source-code archives were downloaded at <rep-dir>/download/ whereas the extracted 3rd-party code usually resided at <rep-dir>/contrib/. In the case of ported libraries, the 'make prepare' step also used to create a bunch of symlinks within <rep-dir/include/ that pointed to the respective header files within <rep-dir>/contrib/. The old 'make prepare' approach was implemented for each individual repository. In contrast, the new solution unifies the procedure across all the repositories located at <genode-dir>/repos/. To install a port provided by any repository, just invoke the tool <genode-dir>/tool/port/prepare_port with the name of the port as argument. The tool will scan all repositories for the specified port and install the port to <genode-dir>/contrib/. Each version of an installed port resides in a dedicated subdirectory within the contrib/ directory. The port-specific directory is called port directory. It is named <port-fingerprint>-<port-name>. The <fingerprint> uniquely identifies the version of the port (it is a SHA1 hash of the ingredients of the port). If two versions of the same port are installed, each of them will have a different fingerprint. So they and up in different directories. Within the Genode source tree, a port is represented by two files, a <port-name>.port and a <port-name>.hash file. Both files reside at the <rep-dir>/ports/ subdirectory of the corresponding repository. The <port-name>.port file is the port description, which declares the ingredients of the port, e.g., archives to download, patches to apply. The <port-name>.hash file contains the fingerprint of the corresponding port description, thereby uniquely identifying a version of the port. To see, which ports are available, look out for <rep-dir>/port/*.port files: find <genode-dir> -mindepth 4 -maxdepth 4 -name "*.port" So how does Genode's build system find the source codes for the right port directory to use? If the build system encounters a target that incorporates ported source code, it looks up the respective <port-name>.hash file in the repositories as specified in the build configuration. The fingerprint found in the hash file is used to construct the path to the port directory under contrib/. Adding a port ------------- The basic steps of adding a new port to Genode are as follows. Let us assume the 3rd-party source codes comes in the form of a tar.gz archive. 1) Create '<rep-dir>/ports/<port-name>.port' file: LICENSE := unknown VERSION := <version> DOWNLOADS := <archive-name>.archive URL(<archive-name>) := http://the-url-of-the.archive.tar.gz The 'DOWNLOADS' declaration contains a list of items to download. Each item is suffixed with the type of the download. Supported types are 'file' (a plain file), 'archive' (an archive of the types tar.gz, tar.xz, tgz, tar.bz2, or zip), 'git' (a Git repository), or 'svn' (a Subversion repository). For each item, there have to be a few additional declarations, in particular the URL where to to download it from. 2) Create 'ports/<port-name>.hash' file with the content 'dummy'. This one will be used during the porting work and replaced once the port if finished. Because the hash file contains the string "dummy", the port directory will be located at <genode-dir>/contrib/dummy-<port-name>/. 3) Declaring the hash sum of a downloaded archive Try to execute the new port file to download the archive. <genode-dir>/tool/ports/prepare_port <port-name> This step will create the port directory and download the archive to the base of this directory. The prepare_port tool tries to validate the correct version of the downloaded file using an SHA1 hash sum. Because the port description lack the known-good SHA1 sum, the check will fail: Error: Hash sum check for <port-name> failed Calculate the SHA1 hash sum of the archive: sha1sum <port-dir>/<archive-name>.tar.gz Declare the hash sum of the archive in the <port-name>.port file: SHA(<archive-name>) := <hash-value> When executing the prepare_port step again, the integrity check for the downloaded archive should succeed. However, we get the following error message: Error: <rep-dir>/ports/<port-name>.port is out of date, expected <fingerprint> We get this message because we had specified the "dummy" hash value in the <port-name>.hash file. The prepare_port tool computes a fingerprint of the actual version of the port and compares this fingerprint with the hash value specified in <port-name>.hash. The computed fingerprint can be found at <port-dir>/<port-name>.hash. In the final step of the port, we will replace the dummy fingerprint with the actual fingerprint of the port. But before finalizing the porting work, it is practical to keep using the dummy hash and suppress the fingerprint check. This can be done by adding 'CHECK_HASH=no' as argument to the prepare_port tool: <genode-dir>/tool/ports/prepare-port <port-name> CHECK_HASH=no 4) Extracting the source code When executing the prepare-step now, the tool will present you with the following message: Error: Missing definition of DIR(<port-name>) in <port-file> We need to declare where to extract the downloaded archive. E.g., DIR(<port-name>) := src/lib/<port-name> Each port directory is principally organized like a Genode source-code repository. So it is good practice to place the extracted code at the location where it would reside if hosted within a repository. Most source packages distributed as tar archives contain a directory named after the package and the version number in the top-level directory of the archive. By default, the prepare tool will strip this directory when extracting the archive. So the actual content will be installed at the directory specified via the 'DIR(<archive-name>)' declaration. You can override the default extraction argument by specifying a custom 'TAR_OPT(<archive-name>)' declaration. 5) Declaration of the license Now that you have downloaded and extracted the 3rd-party source code within the port directory, revisit the code for its license. Update the LICENSE declaration in the <port-name>.port file accordingly. 6) Assembling the include directory exported by the port Define include files to be presented to the Genode build system, e.g.: DIRS := include DIR_CONTENT(include) src/lib/<port-name>/include/*.h This declaration tells the prepare_port tool to copy the files found in the include/ directory of the extracted archive to the <port-dir>/include/ directory. Using this mechanism, arbitrary directory structures can be constructed out of the downloaded content. Validate that the DIRS declarations work as expected by executing the prepare_port step again and revisiting the content of the port directory. 7) Using the ported code from Genode compilation targets Now the preparation step is complete. The final piece of the puzzle is telling the Genode build system to use the port. Within any library description file, target.mk file, or import-*.mk file, you can use the function 'select_from_ports' to query a port directory using the port name as argument. E.g., assuming <port-name> refers to a library, the corresponding import-<port-name>.mk file may contain the following declaration: INC_DIR += $(call select_from_ports,<port-name>)/include This declaration will add the <port-name>/include directory of the port to the include-search path of every target that uses the library. Similarly, the library description file may use the 'select_from_ports' function to define the vpath of the 3rd-party source codes. Under the hood, the 'select_from_ports' function looks up the fingerprint of the specified port by reading the corresponding <port-name>.hash file. It then uses this hash value to construct the directory path within the 'contrib/' directory that belongs to the matching version of the port. If there is no hash file that matches the port name, or if the port directory does not exist, the build system will present you with an error message. Finally, after having tested that both the preparation-step and the build of the ported source code works as expected, it is time to finalize the fingerprint stored in the <rep-dir>/ports/<port-name>.hash file. This can be done by copying the content of the <port-dir>/<port-name>.hash file. The next time, you invoke the prepare_port tool, do not specify the 'CHECK_HASH=no' argument. So the fingerprint check will validate that the <port-name>.hash file corresponds to your <port-name>.port file. From now on, the contrib/dummy-<port-name> directory will no longer be used because the <port-name>.hash file points to the port directory named after the real fingerprint. Transition to the new mechanism ------------------------------- In the last couple of days, I have reworked more than 60 ports to use the new mechanism. The ports not covered so far are: * libports; qt5 * base-codezero * base-fiasco * base-pistachio * base-foc * dde_rump * dde_linux * dde_ipxe * ports-foc * ports: gcc * ports: gdb * ports: seoul * ports: virtualbox During the transition phase (the next release cycle), we will keep the original 'make prepare' mechanism as a front end. So the 'make prepare' instructions as found in many tutorials will still work. But under the hood, 'make prepare' will just invoke the new _tool/ports/prepare_port_ tool. In the current version at the staging branch, the hash sum check is disabled for all ports installed via the old 'make prepare' front end. Nearly all hash files contain "dummy". This is because the prepare_port tool is still in flux. Each change of the tool would require new fingerprints for all packages, which is inconvenient while working on the tool. However, once the development of the tools settles, the dummy hash sums will be replaced by the real hash sums. I hope that the new mechanism will make Genode more convenient to use. Hopefully, the errors caused by missing or outdated 'make prepare' steps will be a thing of the past. However, the current change is just another step. Once we have fully adopted the prepare_port tool, we can fairly easily add further utilities to work with ports, e.g., adding dependency information between ports, garbage collecting stale versions, updating all installed ports, etc. Also, the new way of how ports are organized (having a layout similar to Genode repositories) will greatly help us to implement proper package management for Genode. For the latter, I'd love to embrace the Nix package manager. As immediate steps, we should rework the remaining ports (as mentioned above) to use the new port mechanism and update the documentation, in particular the porting guide [4] [4] https://github.com/genodelabs/genode/blob/master/doc/porting_guide.txt 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

7 10

Re: Simple demo doesn´t work
by . 22 May '14

22 May '14

Hello Norman, Hello Christian ! Thank you for your efforts to help me. After setting up another virtual machine running Kubuntu 14.04 I was successful in executing the simple demo. Best regards Markus

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users