users

users@lists.genode.org

2357 discussions

running virtualbox5 on genode
by fixed-term.peter.jacobi＠sojus-software.de 20 Oct '20

20 Oct '20

Greetings. My name is Peter new to Genode and just trying to run the vbox5_win10_64.run script, btw. any of the scripts in genode/repos/ports/run/ are giving me the same result. It seems that the building works fine but I get no kind of output. A help and some indication on my wrong'ings would be much apreciated. My execution command: make run/vbox5_win10_64 KERNEL=nova BOARD=x86_64 My "build.conf" file and the building output called "out" are attached. My work operating system is Linux Ubuntu 20.04. My goal, create an mikrokernel with genode-framework starting 2 linux Virtualbox applications creating a simple communication between them. Best regards, Peter

2 1

Suggestions for contributing
by Mihail Feraru 16 Oct '20

16 Oct '20

Hello everyone, I've recently asked my Operating Systems professor about an interesting project to contribute to, and he recommended Genode. After a glimpse of the docs and playing a little bit with the tutorial repo, it really got my interest. It would be great if any of you would like to guide me a little bit about how I could be useful to the project. Maybe there are good issues for a new contributor or any feature testing to be done, anything that you consider relevant. About me, I have a little bit of experience with kernel development as I've worked on a hobby kernel project. Regards, Mihail PS. I've seen this strange output message after running hello_tutorial: "17592186044415 MiB RAM and 8997 caps assigned to init" and it feels pretty wrong, maybe it's a bug.

3 3

C++ exceptions handing deadlock with gcc unwind code in dynamic library
by Alexander Tormasov 13 Oct '20

13 Oct '20

What I found is a deadlock of recursive Linker::mutex call. - If we have an exception in some code (e.g. code which call NOVA syscall, in my case this is attach_at() RPC call) then it somehow processed in caller. In particular, during processing it call the following stack from injected by gcc function _Unwind_Resume - pay attention to function dl_iterate_phdr(): #0 Linker::mutex () at /home/tor/gen/20.08/repos/base/src/lib/ldso/main.cc:68 #1 0x0000000000124997 in dl_iterate_phdr (callback=0x119e7a0 <_Unwind_IteratePhdrCallback>, data=0x403fdde0) at /home/tor/gen/20.08/repos/base/src/lib/ldso/exception.cc:41 #2 0x000000000119fa0f in _Unwind_Find_FDE (pc=0x119dc76 <_Unwind_Resume+54>, bases=bases@entry=0x403fe128) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde-dip.c:469 #3 0x000000000119bfc3 in uw_frame_state_for (context=context@entry=0x403fe080, fs=fs@entry=0x403fdec0) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2.c:1257 #4 0x000000000119cfe0 in uw_init_context_1 (context=context@entry=0x403fe080, outer_cfa=outer_cfa@entry=0x403fe2b0, outer_ra=0x1000bcd <Genode::Region_map::attach_at(Genode::Capability<Genode::Dataspace>, unsigned long, unsigned long, long)+259>) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2.c:1586 #5 0x000000000119dc77 in _Unwind_Resume (exc=0x1b41a8 <Genode::init_cxx_heap(Genode::Env&)::initial_block+5256>) at /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind.inc:235 #6 0x0000000001000bcd in Genode::Region_map::attach_at (this=0x1304068 <vm_reg0+8648>, ds=..., local_addr=0x80000000, size=0x40000, offset=0x0) at /home/tor/gen/20.08/repos/base/include/region_map/region_map.h:127 The code of dl_iterate_phdr(): extern "C" int dl_iterate_phdr(int (*callback) (Phdr_info *info, size_t size, void *data), void *data) { int err = 0; Phdr_info info; Mutex::Guard guard(mutex()); for (Object *e = obj_list_head();e; e = e->next_obj()) { info.addr = e->reloc_base(); info.name = e->name(); info.phdr = e->file()->phdr.phdr; info.phnum = e->file()->phdr.count; if (verbose_exception) log(e->name(), " reloc ", Hex(e->reloc_base())); if ((err = callback(&info, sizeof(Phdr_info), data))) break; } return err; } Py attention that it take Linker::_mutex object (lock). Inside, it call the callback() function for main C++ code which resolved to _Unwind_IteratePhdrCallback from contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde-dip.c which internally call get_fde_encoding() and get_cie_encoding() which contain very simple line /home/tor/gen/20.08/contrib/gcc-20345a83596fa42a25a85938329aea54bb4b2146/src/noux-pkg/gcc/libgcc/unwind-dw2-fde.c:300 p = aug + strlen ((const char *)aug) + 1; /* Skip the augmentation string. */ strlen() is not inlined/instantiated here. In machine code it call strlen@plt which mean that strlen assumed in the shared library, and typically it should be processed by linker relocation code. To find the code it call jmp_slot@PLT and, in turn, call from src/lib/ldso/main.cc:294 function Elf::Addr Ld::jmp_slot(Dependency const &dep, Elf::Size index) { Mutex::Guard guard(mutex()); if (verbose_relocation) … Pay attention that it call the same Linker::_mutex object (lock) Voila! we have recursive call of the same linker mutex and deadlock in exception processing. definitely key problem here is in the usage of linker mutex in Genode implementation of dl_iterate_phdr() So, question: how to fix this? May be we need different mutexes for Ld::jmp_slot and for dl_iterate_phdr? Sincerely, Alexander

2 1

driver_manager RAM quota for boot_fb_drv
by Colin Parker 13 Oct '20

13 Oct '20

Hello, I just upgraded to the 20.08 version of Sculpt. There seems to be a problem with the boot_fb_drv component, from what I can guess the changes to this component because of the graphics refactor make it need more RAM, but the driver_manager computes the ram as "_pitch * _height + 512*1024". Changing this to "2 * _pitch * _height + 512*1024" (i.e. doubling the framebuffer part) fixed it for me. Is there a smarter way to understand how much RAM is actually needed here, rather than using blunt tools like "double until it works"? Does this problem only affect me for some reason? This is in qemu which gives a very large screen, but it used to work in the old version (20.02 I think). Regards, Colin

3 2

iMX8 not all cores starting
by Duss Pirmin 07 Oct '20

07 Oct '20

Hi Genodians As mentioned in an earlier mail I'm currently enabling base-hw on the IoT gateway of CompuLab [1]. The used SoC is a iMX8mm, which is a bit different from the iMX8mq used on the EVK [2]. On a running Linux I used `memtool` to read register values. In `src/bootstrap/spec/iot_gateway/platform.cc` I have changed the following things: - the values for the `regulator` registers - the register offsets and values for the ARM_PLL registers - the values of the IOMUX configuration Now the code bootstrap finishes and the kernel begins to run. By adding some `Genode::raw()`s to `void kernel_init()` I'm able to see, that the initialization for kernel waits for all CPUs to start at `while (!pool_ready) { ; }`. If change `NR_OF_CPUS` to 1, I'm able to run the log run script. log output of IoT gateway [1]: ``` Kernel: Board() :: 324 Kernel: Board() :: 342 Kernel: wake_up_all_cpus() :: 352 --- 1 Kernel: wake_up_all_cpus() :: 352 --- 2 Kernel: wake_up_all_cpus() :: 352 --- 3 Kernel: kernel_init() :: 56 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 ``` log output from EVK [2]: ``` Kernel: kernel_init() :: 56 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 3 Kernel: initialize() :: 188 --- 3 initialized=3 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 2 Kernel: initialize() :: 188 --- 2 initialized=2 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 1 Kernel: initialize() :: 188 --- 1 initialized=1 kernel initialized ``` Has anybody an idea what registers could have an influence on the start up of the CPUs? [1] https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm… [2] https://www.nxp.com/design/development-boards/i-mx-evaluation-and-developme… Best regards, Pirmin

4 12

Re: users Digest, Vol 30, Issue 4
by Simon Himmelbauer 06 Oct '20

06 Oct '20

Hi Norman, >> Anyways, regarding your timing problems, how exactly did you measure >> them? My current setup consists of taking a start and stop timestamp via >> a timer-connection but I only seem to get milliseconds-precision (I >> tried using elapsed_us() but it seems to always produce >> "microsecond"-values ending with three zeroes.). I currently run >> everything inside QEMU so I don't know whether real hardware will simply >> fix this. > apart from the lack of precision, the 'Timer::Session::elapsed_ms()' RPC > function induces unwelcome overhead, in particular the context switch > forth-and-back between your component and the timer driver and the timer > driver's interaction with the physical timer device. > > For capturing timing behavior at a higher precision and with much less > overhead, you may find the 'Trace::timestamp()' utility useful. The > function returns a platform-dependent timer tick value. On x86, this > would be the time-stamp counter (TCS), on ARM it returns a CPU counter > value. > > As the value returned by 'Trace::timestamp()' depends on the platform > (e.g., the CPU frequency), you will need to apply some kind of > calibration. To determine the calibration factor, you may use the > 'Timer::elapsed_ms' or 'Timer::elapsed_us' functions before running your > actual tests, e.g., by measuring the number of timer ticks passed within > one second. > > As a heads-up, please regard the 'Trace::timestamp()' with a healthy > dose of skepticism. In our experience, the values are not always > perfectly proportional to real-world time. In particular, > > - On the ARMv6-based Raspberry Pi, the counter value is increased only > if the CPU is not idle. > > - On some x86 platforms, the TCS values are not perfectly stable. > In particular, the TCS values taken with different CPU cores cannot > be assumed to correlate. > > You can find the implementations of the 'Trace::timestamp' function at > the base/include/spec/<arch>/trace/timestamp.h header, where <arch> is > the CPU architecture (like arm_64 or x86_64). > > Cheers > Norman > thanks for the input, I might have a look at this once I get to real-hardware testing. Cheers, Simon

1 0

No output with Genode::raw and Fiasco.OC
by Simon Himmelbauer 05 Oct '20

05 Oct '20

Hi Genodians, I'm currently writing a time sensitive-program using Fiasco.OC as a kernel. For debugging purposes I wanted to use Genode::raw in order to avoid the overhead of Genode::log. However, my calls to raw() don't seem to print anything on the console. Is there something I need to enable/configure first? Thanks in advance! Cheers, Simon

4 6

Re: No output with Genode::raw and Fiasco.OC
by Simon Himmelbauer 02 Oct '20

02 Oct '20

Hi Christian, > For Genode::raw() to work on Fiasco.OC, the component needs the debug > capability to access the kernel debugger for output. This may be a > robustness/security risk in production systems and is, therefore, not > enabled by default. The access can be enabled by adapting the code > [1] and after recompilation all components can access the Fiasco > kernel debugger. Your solution worked, thanks for the help! Cheers, Simon Himmelbauer

1 0

Out of tree hardware platforms
by Duss Pirmin 02 Oct '20

02 Oct '20

Hi Genodians I'm enabling base-hw on the IoT gateway of CompuLab [1]. I do this in a separate repository in the same way as arndale, panda etc are done in genode-world. This works well apart from some minor modifications on the imx8q_evk (for which I will create an issue as soon everything is finalized and cleaned up). The only thing I'm struggling with is that /tool/run/boot_dir/hw isn't used. This leads to the error unknown platform no linker address known If I add the platform to genode/tool/run/boot_dir/hw building works. But as with the other out of tree platforms I'd like to keep the platform out of the Genode repository, for cleanness. The repository is linked to genode/repos/... and added to REPOSITORIES in build/arm_v8a/etc/build.conf. [1] https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm… Best regards, Pirmin

3 2

The Falkon browser / Chromium engine running natively on Genode is absolutely beautiful
by baconicsynergy＠protonmail.ch 29 Sep '20

29 Sep '20

I can't access my Gmail or Protonmail yet (it says the engine isn't up to date), but I don't care - this is a huge step forward for Genode's web capabilities! I can't tell you how excited this makes me. Considering that Firefox usage is much lower lately (unfortunately :/) investing in a Chromium based web browser is wise. It's also going to be very nice not needing to spin up a virtual machine to use a feature-filled web browser Looking forward to future updates!

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users