users

users@lists.genode.org

2285 discussions

Why DDE BSD for audio?
by Alexander Senier 01 Feb '17

01 Feb '17

Hi all, when looking into Genodes driver support, I was wondering about DDE BSD. The audio_* ports seems to be its only use case. Is there any (technical) justification for not porting audio drivers from Linux using DDE Linux? With USB, WiFi and GMA there were much more complex driver ported using DDE Linux after all... Thanks! Cheers, Alex

3 3

performance benchmark
by Parfait Tokponnon 30 Jan '17

30 Jan '17

Hello all, Is there any benchmark (performance) tool ready to run in Genode? I am trying to introduce some redundant execution scheme into the Nova kernel and I would like to have a hint of the performance impact (on Genode components). Since it is an unfinished work, the demo is the only scenario I can run now. I have read about the trace session in 13.08 release which may help but I failed to build the trace example scenario (to get some insight of the feature) *Here are the outputs* In the master branch: make run/trace ... cp: cannot stat ‘bin/rpc_name’: No such file or directory while executing "exec cp bin/$binary [run_dir]/genode" (procedure "copy_and_strip_genode_binaries_to_run_dir" line 4) invoked from within ... In the 13.08 release make run/trace Makefile:91: /mk/global.mk: No such file or directory make: *** No rule to make target `/mk/global.mk'. Stop. I also read about the* TCP/IP Automated benchmarking* in 13.05 release. In the master branch: make run/network_test_nic_raw Error: No run script for network_test_nic_raw In the 13.05 release Makefile:91: /mk/global.mk: No such file or directory make: *** No rule to make target `/mk/global.mk'. Stop. Any suggestion is welcom. -- Parfait T.

2 1

Genode on Odroid-XU4
by Yevgeny Lavrov 24 Jan '17

24 Jan '17

Greetings I would like to try Genode on Odroid-XU4. I aware that there's no support available for this ARM device yet. However, I want to give it a try, but I don't know where to start. Can you please point me in the right direction so I can find the information that I'll need to get started this task? Thanks

2 8

Recipes not working
by Chris Rothrock 20 Jan '17

20 Jan '17

There are two recipes that I was able to successfully compile and run in Genode 16.08 that are no longer working with Genode 16.11 and was wondering if I could get assistance to make them work in this version. The default make run/demo works fine for me but if I try using the make run/demo with the Nova kernel I get an error "Error: target 'drivers/usb' does not exist". Also, I am trying to run the recipe for virtualbox (using Nova hypervisor) and this worked with Genode v16.08 but now I can't make this recipe. The port libiconv is required but I get an error trying to prepare_port on this one (Error: Hash sum check for libiconv failed). I also tried to update the hash (./tool/port/update_hash libiconv) but this didn't work. Any assistance on these two issues would be appreciated. Thanks, Chris -- Thank You, Chris Rothrock Senior System Administrator (315) 308-1637

2 1

Native Android Application Execution in Genode (Dalvik VM / ART)
by Alexy Gallardo Segura 17 Jan '17

17 Jan '17

Hello, I am writing to consult everyone on a topic in the genode section Challenges, in particular on the "Dalvik VM of Android natively in Genode". Norman Feske told me that currently Android also uses ART (Android runtime). Especially I have no preference, I'm only interested in running Android applications in GenodeOS. I am interested in working on this topic, but I have some questions to ask. Is anyone working on this topic? I reviewed the current issues but I did not find Anything related. Which would be better to incorporate to Genode Dalvik or ART, or any other variant? Finally, if you have any suggestions on where to start the review first? regards Alexy Gallardo Segura

1 0

Thinkpad X250 vs X260 ?
by Peter Lindener 17 Jan '17

17 Jan '17

The list of unofficially supported Genode compatible systems <http://usr.sysret.de/jws/genode/hcl.html#list_systems>.. might suggest that the most expedient path towards developing / working with Genode is likely the Thinkpad X250 or X260... Even with the i7 Skylake's on chip graphics, waiting for my Dell XPS 15 to join this list seems like it might be a bit of a long shot. Thus i write asking for an update on if I should spring for a Thinkpad X250 or X260? last time I queried Norman mentioned one should order it with Intel's (user facing) remote management engine enabled.. ( always enabled for use by the NSA )... Any other features / configuration suggested for Genode development? I am also interested in cross development of Genode to ARMv7, ARMv8.. for ARM development, it seems like the Arndale Board <http://www.arndaleboard.org/wiki/index.php/Main_Page> is currently the path of least resistance?... I currently have a Zynq-7000 (dual ARM9) based SnickerDoodle <http://krtkl.com/> on my bench that may be fairly easy for Genode to boot up? is Genode likely to support a more modern ARMv8 implementation likely in the near term? -Peter

3 3

Roadmap 2017
by Dr. Florian Manfred Grätz 17 Jan '17

17 Jan '17

Dear community, I am very excited about the entire Genode project and looking forward to the upcoming releases. Please keep up the quaterly release cycle. Let me share my thoughts on several issues, which have already been communicated: * From a newbee's point of view I would say, that you guys are heading into the right direction: I understand the core component to be a kernel abstraction layer. Therfore ABI stability of the core would be awsome - no matter what the kernel is, you could use the same binaries (as long as you are running on the same processor, of course) for drivers and applications. That would be a prerequiste for a working packaging system. * The build process indeed needs a little make-over. I have noticed side effects with the ports, which are hard to describe in detail, as I have not yet fully understood them. Generally speaking the ports (including the drivers) should be built separately from the kernel/core/init. Once again - a stable ABI would help. No matter what the kernel is, you would use the same binaries for the drivers/applications. * A dynamic init component would greatly help, too: reconfigure your system, don't rebuild it. This would also enhance the turmvilla scenario. Let me also add an idea of mine: for your turmvilla scenaria it might help to provide .iso images with a running system (e.g. using grub-mkrescue) and make them accessible for download. You would then use dd to copy the image on a USB pendrive or an SD card and reboot your computer from this external storage device without installing it on your internal hard drive. You could also use this mechanism to install the system on your internal hard drive, if you have the capability to dynamicly resize your partitions, but you wouldn't have to. The way I see it, a dynamic init component would be a prerequisite. To say it with the words of Karl Valentin: everything has been said - just not by everyone. All the best, Florian.

3 2

Loading of software modules at runtime vs. loading at boot time.
by Dr. Florian Manfred Grätz 16 Jan '17

16 Jan '17

Dear Genode community, I am gradually digging into the details of the Genode framework and was thinking about compiling a Live-CD. My intension is to give unexperienced users a first impression of Genode by simply downloading an .iso image and either booting it into their real machine using a thumb drive or using an emulater like qemu/virtualbox. Please refer to my last post for the rationale behind it. The good news is, that genode-world seems already to provide a set of software packages, which have been ported. However, I am currently under the impression, that genode currently is not capable of loading software modules at runtime. Instead, it appears to me, that all required software modules are linked into a large elf file, which is then loaded during boot time. Am I missing something crudential here or is loading of modules at runtime not yet implemented? Regards, Florian.

2 1

report_rom clarification about the validity of ROMs in case the report session was closed
by Johannes Schlatow 16 Jan '17

16 Jan '17

Hi, I (more precisely: a student of mine) noticed that a ROM provided by the report_rom is cleared once the corresponding Report session is closed. I looked at the implementation, which intentionally clears the dataspace when the writer (i.e. the report session) is unregistered from the Rom_module. I'm curious about the reason for this. More specifically, I am wondering why the report_rom does not invalidate and notify the registered ROM sessions after the content was cleared. Currently, the ROM clients will just see that the content disappeared without getting any signal, which seems a bit counterintuitive/inconsistent to me. Cheers Johannes

2 4

Unified build directories / adaptation to the new API
by Norman Feske 13 Jan '17

13 Jan '17

Hello everyone, I am happy to report that we wrapped up the first phase of our big API adaptation work today and introduced the unified build directories into the master branch. This posting is both a heads-up warning and an invitation to experiment with the new mechanism. First, the warning part (quite literally): With the commit "Warn about the use of deprecated env() function" [1], a compiler warning will appear each time the legacy 'env()' function is used, either explicitly or implicitly. This makes it easy to spot the places that need our attention because they still rely on global side effects. Since New Year, we have been very busy to overhaul our code base and made huge progress. Thanks to everyone involved! However, as you will see, there are still many places left unattended. Therefore, the warnings somehow spoil the impression when building Genode right now. Their main downside is that build errors and important warnings are more difficult to spot. Please bear with us. ;-) Don't worry though, the "deprecated" warnings are merely cosmetic and will gradually disappear. [1] https://github.com/genodelabs/genode/commit/a7f40b24cad0a34f0ac0bd9256a5285… Second, I proudly present you the fruit of my labor with respect to the Genode ABI. Genode has now become able to use different kernels from within the same build directory. Of course, this change comes with a sight change of the tooling, in particular to the 'create_builddir' tool, the build system, and the autopilot tool. Let's take the new version for a quick test drive. 1. Checkout the current master branch of Genode. git clone https://github.com/genodelabs/genode.git 2. Invoke the 'create_builddir' tool to see the new options of build directories. cd genode ./tool/create_builddir As you can see, the original kernel-specific platform parameters are still there but they are marked as "deprecated". They will be removed shortly. The new unified build directories are the new way to go now. There is one option for each supported hardware platform, e.g., 'x86_64', or 'usb_armory'. Note that the kernel is left unspecified. Assuming you have a 64-bit Linux host system, let us create a build directory that matches your Linux system: ./tool/create_builddir x86_64 (if you are using a 32-bit Linux system, specify 'x86_32' instead) Now, enter the build directory and look at the build configuration: cd build/x86_64 <editor> etc/build.conf You may notice the changed "Run-tool configuration" section. Parts this configuration are dependent of a new 'KERNEL' variable. The variable has the following effects: * It selects kernel-specific run-tool arguments 'KERNEL_RUN_OPT', * It selects kernel-specific Qemu arguments, e.g. 'QEMU_OPT(nova)' * It adds the kernel-specific 'base-<kernel>' directory to the list of source-code 'REPOSITORIES'. Once you have your build.conf open in your editor, you may enable parallel build by uncommenting the corresponding line at the beginning of the file. 3. Let's build a Genode component, e.g., init: make init Wow, that was quick! The build system created the init binary without even building any parts of the Genode base system. How is that possible? The answer lies at 'repos/base/lib/symbols/ld', which is the binary interface provided by Genode's dynamic linker. The build system uses this information to build a pseudo shared object that is linked against init instead of the real dynamic linker. From the perspective of the init executable (just put yourself into the shoes of an ELF executable to follow me), it feels like being linked against Genode's dynamic linker that provides the base framework. But in reality, you got presented just an empty hull of Genode - a bunch of symbols. In case you are curious, you can find this ABI stub library at var/libcache/ld/ld.abi.so. If you look closely into the build subdirectory of init/, you will see that the used 'ld.lib.so' is actually a symlink to the stub. At this point, the build directory is clear from any kernel- specific peculiarities. 4. Building a kernel To build a kernel, the build system needs to know the kernel- specific parts of Genode, i.e., the corresponding 'base-<kernel>' source code repository must be added to the 'REPOSITORIES'. The default build configuration does this automatically if you specify a 'KERNEL' argument: make kernel KERNEL=nova At this point, the build system may point out that you will need to download the kernel source code. Just follow the proposed command to do these preparatory steps. If done, execute the above command again. In the particular case of NOVA, the result of the kernel build can be found at 'kernel/nova/'. 5. Executing a scenario on Linux Let's build and execute Genode's graphical demo scenario on your Linux host system: make run/demo KERNEL=linux The build will take a while. Most of the produced components are kernel-independent. Only a few, such as core, fb_sdl, and the timer driver are Linux-specific. Also a Linux-specific version of Genode's dynamic linker will be built. It is named 'ld-linux.lib.so'. Once the build completes, the scenario is executed. So you should see a window with the demo scenario popping up. 6. Switching to another kernel Now, let's execute the same scenario on, let's say, NOVA. To use this kernel instead of Linux, a few actual drivers are needed. So let us enable the 'libports' and 'dde_linux' repositories in the build configuration. At this point, you may have guessed the command to use: make run/demo KERNEL=nova You will be prompted to prepare a few ports of 3rd-party software, in particular, the libc, dde_linux (USB driver), x86emu (for VESA). After installing those ports, issue the above command again. Note that the build process will build the additional drivers and NOVA-specific parts of Genode. But all the components that we built before when executing the scenario on Linux remain untouched now. At the end of the build process, the scenario is stared in Qemu. To sum it up, switching from one kernel to another has become just a matter of the 'KERNEL' argument. This has a number of benefits: * When using multiple kernels, there is no need to have multiple build directories. You waited an hour to build a Qt5-based scenario on NOVA but want to run it on Linux now? This is now possible in a few seconds. * If an executable has a bug, the bug will be there regardless of the kernel being used. To debug the problem, you can use the kernel with the most appropriate debugging instruments available. * The packaging of kernel-agnostic binary packages has become within close reach now. * The new ABI feature that works so well for Genode's dynamic linker can actually be leveraged by arbitrary libraries. For example, I just introduced an ABI for the libc (libports/lib/symbols/libc). So in the future we can even have multiple levels of ABI stability. I hope that you will like the unified build directories. This being a very recent development, there may still be rough edges. Your feedback is very welcome. I hope that we will have smoothened those edges and removed most of the "deprecated" warnings by the time of releasing version 17.02 at the end of February. 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users