users October 2020

users@lists.genode.org

16 participants
14 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users October 2020