users

users@lists.genode.org

3 participants
2319 discussions

CLI Tools and Applications
by Joel Desermeau 25 Mar '19

25 Mar '19

I like using all sorts of CLI programs on my GNU/Linux machines. How far away are we from being able to run simple programs like Mutt and Newsboat within a noux instance?

2 1

Add VPN tunnel to network stack?
by Joel Desermeau 25 Mar '19

25 Mar '19

How cool would it be to have a VPN service like OpenVPN/Wireguard implemented directly on the left Leitzentrale panel.

2 1

Notifications for new announced software
by Joel Desermeau 22 Mar '19

22 Mar '19

- Will we usually find out about new software via genodians.org? - Can we be emailed or notified of new changes to the Depot?

2 1

Thanks for helping me :)
by Joel Desermeau 21 Mar '19

21 Mar '19

I still have much to learn, I appreciate all of the friendly and helpful mailing list replies

1 0

Debian download not working for me
by Joel Desermeau 21 Mar '19

21 Mar '19

When I start download_debian, nothing happens. Is anyone else experiencing this? How can I manually use my own .iso?

4 4

Sculpt as a Community Experience (CE)
by Norman Feske 21 Mar '19

21 Mar '19

Dear Genode community, I am more than happy to announce the official release of the fourth incarnation of Sculpt OS. The faint vision of our Genode-based general-purpose OS - as laid out one and half years ago - has now become real. Some of you followed the story of Sculpt from the beginning. Initially geared towards die-hard enthusiasts only, each revision became more and more approachable. The previous version Sculpt VC already offered a glimpse of Sculpt's unique user interface in the form of an interactive component graph. The just released Sculpt OS "as a community experience" (CE) combines this tangible notion of component compositions with a new federated software provisioning model that eliminates the need for middlemen like app stores or distributions. With Sculpt CE, components can be offered by a federation of independent software providers. The software installation is sandboxed and protected by digital signatures. The integration of components with the rest of the system is completely under control of the user. With the principle of least privilege at the heart of Sculpt's architecture, you - the user - can fearlessly install and run software without ultimately trusting the software providers. Sculpt CE is intended to work in tandem with our community blog https://genodians.org where developers and users exchange experiences and announce new software. The best way to watch how the Sculpt story continues is the RSS feed of Genodians.org. To dive right into Sculpt CE, you can download a ready-to-use disk image here: https://genode.org/download/sculpt Please also consider the new documentation, which received a major update: https://genode.org/documentation/articles/sculpt-ce https://genode.org/documentation/sculpt-ce.pdf (PDF version) Have fun with Sculpt CE! Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 3

Genode build system
by Valery V. Sedletski 18 Mar '19

18 Mar '19

Hi all. Does Genode build system only allow to build a binary or library with each "target.mk" makefile? Is it possible to have non-binary targets in these makefiles, or have more than one target? Specifically, I need to generate a "map" file with some functions addresses. So, I use "nm" on a just built binary to generate a map file with lines like <Function_name> <Function_address> The map file should be a dependency of the binary itself, but I was not able to figure out, how to trigger a map file generation after the binary is built. I tried to add a rule like this: all: map to target.mk. So, the map file should be a dependency of "all" target, but this does not work, because "map" then is built before the binary specified as TARGET = <binary_name> Does someone have any ideas, how it's possible to accomplish this? WBR, valery

3 6

Cache invalidation issue on arm
by Tomasz Gajewski 13 Mar '19

13 Mar '19

Hi, during my attempts to make framebuffer driver working on rpi3b+ I had problems with memory caching. Effect was that I received from gpu information that result message was processed but couldn't see results - read memory always contained content of message and not response. Before I found a simple fix - ask dataspace for an uncached memory - I tried to call 'Kernel::update_data_region' but it didn't work for me. During my experiments I tried to dump memory from 'Kernel::Thread::_call_update_data_region()' for virtual address range passed to this function and it worked. In that function there is a comment that states that kernel operates in different address space than the caller for threads other than core. In that case different method of cache invalidation was called: 'clean_invalidate_data_cache', that should invalidate all cache. For core threads 'clean_invalidate_data_cache_by_virt_region' was used. Successfully dumping memory passed to _call_update_data_region() (using virtual address) made me think that a comment there about address spaces is wrong and - as an attempt to see what happens - I changed code to always call invalidating memory for given region only. This change [1] resolved issues with not seeing responses from gpu regarding framebuffer setup. If I'm not mistaken then: 1. Comment in 'Kernel::Thread::_call_update_data_region()' is not true anymore and code can be changed to always call more efficient version that invalidates always only cache for region of memory. 2. 'clean_invalidate_data_cache' is not working on rpi3b+ properly. I wouldn't be really surprised as I used code from Cortex A15, available already in Genode, without checking if Cortex A53 requires a different code (even for AArch32 mode). Please give me information if kernel is now mapped into every address space (as is stated in the aforementioned comment as a future goal) and my change is a correct one. If it is not the case can you provide some other possible explanation of this? Tomasz Gajewski PS. As a minor addtion I found a trivial function documentation bug that I fixed in [2]. [1] https://github.com/tomga/genode/commit/5a5adc06d9889129f2f1efd9a36be0ef52bb… [2] https://github.com/tomga/genode/commit/f25fad3c2957b843b549665cd7bcb50bec1d…

2 2

Porting Node.js
by Max 12 Mar '19

12 Mar '19

Hi, Genodians! I want to port Node.js for Genode OS, but I understand that it is not a simple matter. Maybe someone has already started to do this work and I would connect to this process. If answer is NO, then maybe someone will tell something sensible (for a starting point, I familiarized myself with information described at https://genode.org/documentation/developer-resources/porting_noux_packages). I would be very grateful for any useful information. Thanks!

3 2

Genode (x86_64) reboots on Thinkpad T420
by Valery V. Sedletski 10 Mar '19

10 Mar '19

Hi, Genodians! Some days ago, I ordered a Thinkpad T420, which is listed in Genode unofficial HCL by cnuke. I set up Genode booting remotely via PXE+Intel AMT. It boots the system image (x86_32 arch) just fine on real hardware. But if I try booting an x86_64 image, it reboots on most kernels, or traps on Fiasco.OC. Last messages in the log I see are from "bender" [1]. This is when booting using NOVA kernel. If I try Fiasco.OC as a kernel ([2]), It goes until "bootstrap", and last I see in the log are "bootstrap" messages, until it attempts to start the kernel. And at the same time, I see the following trap screen from bootstrap: [3]. All registers are zeroes, except a few ones. So, with "foc" kernel, I see a Trap #0 (division by zero). In case of "NOVA" and "base-hw" kernel, it does not trap, but just reboots. I tried to remove the "novga" parameter from NOVA kernel, but I still see a blank screen. BIOS memory map is here: [4], [5] Looking at the memory map, I don't see any memory holes at the same place where modules were loaded. Any ideas? [1] Boot log with NOVA kernel: sculpt64-nova.log (attached) [2] Boot log with Fiasco.OC kernel: sculpt64-foc.log (attached) [3] A trap screen from bootstrap, Fiasco.OC kernel: ftp://osfree.org/upload/img/20190307_004.jpg [4] BIOS memory map (part 1): ftp://osfree.org/upload/img/20190307_001.jpg [5] BIOS memory map (part 2): ftp://osfree.org/upload/img/20190307_002.jpg WBR, valery

2 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users