users

users@lists.genode.org

3 participants
2319 discussions

how to find number of cpu (cores) available for application?
by Alexander Tormasov 24 Jul '20

24 Jul '20

I am trying to understand how many cpu or/and cored are available for running application. I check code related to sysctl in libports/src/lib/libc/sysctl.cc<http://sysctl.cc> and found extern "C" int __sysctl(const int *name, u_int namelen, void *oldp, size_t *oldlenp, const void *newp, size_t newlen) { … /* fallback values */ { switch(index_a) { … case CTL_HW: switch(index_b) { case HW_MACHINE: *oldlenp = 0; return 0; case HW_NCPU: *(int*)oldp = 1; *oldlenp = sizeof(int); return 0; } break; … in short, if I used standardised for BSD code (like below in golang) it always return 1! int32 getproccount(void) { int mib[2], out; size_t len; mib[0] = CTL_HW; mib[1] = HW_NCPU; len = sizeof(out); if(sysctl(mib, 2, &out, &len, NULL, 0) >= 0) return (int32)out; else return 0; } Any suggestions? How I can have portable code for Genode to obtain at least NCPU? Sincerely, Alexander

2 1

Genode Community Summer 2020
by Martin Stein 13 Jul '20

13 Jul '20

Last year, for the first time we held the Genode Community Summer for people that would like to work on their Genode project while being able to seek our assistance in person. The event was a success and we would like to give it another try this year. ** For whom? ** The gathering is open for everyone of the Genode community. Hence, it should be regarded as a public event. Each participant should have a concrete project to pursue during the time and be able to work on this project independently most of the time. Unlike a commercial offered workshop, there won't be any lecture or intensive coaching, but simply co-working in an informal and friendly setting. Anything confidential should better be left at home! This way, we can accommodate people with different backgrounds at the same time while the event bears potential for networking effects among different community members. If you are planning to participate as organization, please consider a limit of 2 persons per organization. With this, we aim for preserving versatility and the possibility for interdisciplinary exchange at the Genode Community Summer. ** Where? ** The event will take place in the lower floor of the Genode Labs office, Friedrichstraße 26, 01067 Dresden, Germany. Note, that lodging is up to each participant individually. ** When? ** Over two weeks from 31.8.2020 till 11.9.2020. It is possible to participate only for a part of this time. ** How to register? ** Each participant must register in advance since our space is limited but the event will be at no cost. Please register via mail to martin.stein(a)genode-labs.com. We will hold the event only if at least 4 people register until 17.8.2020. We will inform all participants as soon as we have 4 registrations. Your registration must contain a brief description of the project you're planning to pursue during the gathering. Please also add whether you like to participate for the whole two weeks, and if not, which part of that time you will participate. We've opened an issue in the Genode Github repository that serves for discussions and information sharing around the Genode Community Summer 2020: https://github.com/genodelabs/genode/issues/3818 If you have questions regarding the Genode Community Summer please don't hesitate to ask in this issue or via mail to martin.stein(a)genode-labs.com . Hope to see you there!

1 0

Crash on Windriver Simics : page fault, pd='init -> drivers -> acpi_drv' thread='ep'
by Parfait Tokponnon 09 Jul '20

09 Jul '20

Hello, I want to run Genode on Windriver Simics <https://www.windriver.com/products/simics/>. I've just created a disk image with the demo scenario from a freshly cloned Genode. It crashes with the following error. > page fault, pd='init -> drivers -> acpi_drv' thread='ep' cpu=0 > ip=0x1011062 address=0xbff00000 stack pointer=0x401fbbc0 qualifiers=0x4 > irUwp reason=1 > addr2line -e debug/acpi_drv 0x1011062 > The IP 0x1011062 resolves to repos/base/include/util/mmio.h:54 > /** > * Read '_ACCESS_T' typed from MMIO base + 'offset' > */ > template <typename ACCESS_T> > inline ACCESS_T _read(off_t const &offset) const > { > addr_t const dst = _base + offset; > 54 ACCESS_T const value = *(ACCESS_T volatile *)dst; > return value; > } > When using the Genode::backtrace(), I get this > Error: > PAGE-FAULT IN CORE addr=0x204 ip=0x1b32b8 (read) > > stack pointer 0x403feda0, qualifiers 0x4 irUwp > faulter utcb 0x403ff000, last message item count 0 > #1 0x00000000403feda0 0x00000000001b32b8 > #2 0x00000000403feea8 0x000000000015e7c3 > [ 0] Killed EC:0xffffffff8103b4c0 SC:0xffffffff81148040 V:0xe CS:0x2b > IP:0x1c6ac3(0x2155ca) CR2:0x100000008 ERR:0x4 (Livelock) Pd::root > [ 0] Killed EC:0xffffffff8103bb80 SC:0xffffffff81148040 V:0xe CS:0x2b > IP:0x1b32b8(0x1) CR2:0x204 ERR:0x4 (IPC Abort) Pd::root > [ 0] Killed EC:0xffffffff81139280 SC:0xffffffff81148040 V:0xe CS:0x2b > IP:0x1010ab2(0x0) CR2:0xbff00000 ERR:0x4 (IPC Abort) > [ 0] Killed EC:0xffffffff816cb280 SC:0xffffffff816d9040 V:0xe CS:0x2b > IP:0x1021b10(0x1) CR2:0x1021b10 ERR:0x14 (IPC Timeout) > [ 0] Killed EC:0xffffffff8178d280 SC:0xffffffff8106b040 V:0xe CS:0x2b > IP:0xf11fb(0x1067000) CR2:0x1392fff ERR:0x6 (IPC Timeout) > [ 0] Killed EC:0xffffffff8178d040 SC:0xffffffff8106b040 V:0xe CS:0x2b > IP:0xccd34(0x0) CR2:0xccd34 ERR:0x14 (IPC Timeout) > [init -> drivers -> acpi_drv] Error: Uncaught exception of type > 'Genode::Ipc_error' > [init -> drivers -> acpi_drv] Warning: abort called - thread: main > The IP:0x1010ab2 resolves to /home/parfait/git/genode20.05/repos/os/src/drivers/acpi/acpi.cc:254 where I can read following : Fadt(addr_t a) : Genode::Mmio(a) > { > features = read<Fadt::Feature_flags>(); > reset_type = read<Fadt::Reset_reg_type>(); > 254 reset_addr = read<Fadt::Reset_reg_addr>(); > reset_value = read<Fadt::Reset_value>(); > } > It seems like there is an issue with the parsing of the acpi table, especially the FADT. How can I proceed to resolve this ? -- Parfait T.

3 6

We're hiring!
by Sid Hussmann 09 Jul '20

09 Jul '20

Hello Genodians It's now about three years ago since four of my fellow long-term hard-core Genode enthusiasts and myself came to the conclusion that this OS framework has the potential to be a game-changer. Not only the concepts, but also the quality of the implementation, the top-notch team at Genode Labs and last but not least the open and collaborative community, are utterly unique. While exploring different market-entry strategies at the beginning, our Trustworthy Execution Platform (TEP) is currently used by hardware security module manufacturers to provide trusted execution environments in the banking and payment sector. Yet, this is only the beginning. We envision gapfruit TEP as a general purpose platform built on the solid foundation of the Genode OS Framework. The next step is to expand to the IoT/Edge market. We are breaking new ground and there's a lot to explore and a lot of work ahead. To succeed, we need your help! gapfruit is seeking software engineers at nearly every level of the software stack. From firmware, device drivers, protocol stacks, microkernels, hypervisors, higher-level management software to interacting with cloud environments. If you're curious, please get in touch with us: careers(a)gapfruit.com While we prefer on-site in Zug, Switzerland, we support remote work as well. Cheers, Sid -- Sid Hussmann CTO & Founder gapfruit AG Baarerstrasse 135 6300 Zug - Switzerland sid.hussmann(a)gapfruit.com https://twitter.com/SidHussmann

1 0

components sequence and libc
by Alexander Tormasov 07 Jul '20

07 Jul '20

I am trying to run application which have libc component and my own golang part. I use nova kernel on x86_64 version. I found that during the process of linker initialization of components I have uninitiated variable: #0 Genode::Stack::size (this=0x401fef28, size=0x40000) at /media/psf/Home/gen/20.05/repos/base/src/lib/base/thread.cc:34 #1 0x00000000000fb094 in Linker::Binary::call_entry_point (env=..., this=0x15e010 <unmanaged_singleton<Linker::Binary, 8, Genode::Env&, Genode::Heap&, Linker::Config const&, char const*>(Genode::Env&, Genode::Heap&, Linker::Config const&, char const*&&)::object_space>) at /media/psf/Home/gen/20.05/repos/base/src/lib/ldso/main.cc:436 #2 Component::construct (env=...) at /media/psf/Home/gen/20.05/repos/base/src/lib/ldso/main.cc:825 #3 0x000000000007cf7f in (anonymous namespace)::Constructor_component::construct (this=0x400fec10) at /media/psf/Home/gen/20.05/repos/base/src/lib/base/entrypoint.cc:319 #4 Genode::Meta::call_member<Genode::Meta::Empty, (anonymous namespace)::Constructor_component, Genode::Meta::Empty> (func=<optimized out>, server=...) at /media/psf/Home/gen/20.05/repos/base/include/util/meta.h:464 #5 (anonymous namespace)::Constructor::Rpc_construct::serve<(anonymous namespace)::Constructor_component, Genode::Meta::Empty> (args=<synthetic pointer>..., server=...) at /media/psf/Home/gen/20.05/repos/base/src/lib/base/entrypoint.cc:293 #6 Genode::Rpc_dispatcher<(anonymous namespace)::Constructor, (anonymous namespace)::Constructor_component>::_do_serve<(anonymous namespace)::Constructor::Rpc_construct> (args=<synthetic pointer>..., this=0x400fec98) at /media/psf/Home/gen/20.05/repos/base/include/base/rpc_server.h:146 #7 Genode::Rpc_dispatcher<(anonymous namespace)::Constructor, (anonymous namespace)::Constructor_component>::_do_dispatch<Genode::Meta::Type_list<(anonymous namespace)::Constructor::Rpc_construct> > (in=..., out=..., opcode=..., this=0x400fec98) at /media/psf/Home/gen/20.05/repos/base/include/base/rpc_server.h:180 #8 Genode::Rpc_dispatcher<(anonymous namespace)::Constructor, (anonymous namespace)::Constructor_component>::dispatch (in=..., out=..., opcode=..., this=0x400fec98) at /media/psf/Home/gen/20.05/repos/base/include/base/rpc_server.h:235 #9 Genode::Rpc_object<(anonymous namespace)::Constructor, (anonymous namespace)::Constructor_component>::dispatch (this=0x400fec10, opcode=..., in=..., out=...) at /media/psf/Home/gen/20.05/repos/base/include/base/rpc_server.h:272 #10 0x000000000009d08d in Genode::Rpc_entrypoint::<lambda(Genode::Rpc_object_base*)>::operator() (obj=0x400fec10, __closure=<synthetic pointer>) at /media/psf/Home/gen/20.05/repos/base-nova/src/lib/base/rpc_entrypoint.cc:177 #11 Genode::Object_pool<Genode::Rpc_object_base>::apply<Genode::Rpc_entrypoint::_activation_entry()::<lambda(Genode::Rpc_object_base*)> > (func=..., capid=<optimized out>, this=0x12e4b0 <Genode::bootstrap_component()::startup+528>) at /media/psf/Home/gen/20.05/repos/base/include/base/object_pool.h:147 #12 Genode::Rpc_entrypoint::_activation_entry () at /media/psf/Home/gen/20.05/repos/base-nova/src/lib/base/rpc_entrypoint.cc:180 #13 0x0000000000000000 in ?? () code #1 contains the following: void call_entry_point(Env &env) { /* apply the component-provided stack size */ if (Elf::Addr addr = lookup_symbol("_ZN9Component10stack_sizeEv")) { /* call 'Component::stack_size()' */ size_t const stack_size = ((size_t(*)())addr)(); /* expand stack according to the component's needs */ Thread::myself()->stack_size(stack_size); } … it found _ZN9Component10stack_sizeEv function for libc and then call the following function #0 from base/src/lib/base/thread.cc: void Stack::size(size_t const size) { /* check if the stack needs to be enhanced */ size_t const stack_size = (addr_t)_stack - _base; if (stack_size >= size) { return; } /* check if the stack enhancement fits the stack region */ enum { UTCB_SIZE = sizeof(Native_utcb), PAGE_SIZE_LOG2 = 12, PAGE_SIZE = (1UL << PAGE_SIZE_LOG2), }; addr_t const stack_slot_base = Stack_allocator::addr_to_base(this); size_t const ds_size = align_addr(size - stack_size, PAGE_SIZE_LOG2); if (_base - ds_size < stack_slot_base) throw Thread::Stack_too_large(); /* allocate and attach backing store for the stack enhancement */ addr_t const ds_addr = _base - ds_size - stack_area_virtual_base(); try { Ram_allocator * const ram = env_stack_area_ram_allocator; Ram_dataspace_capability const ds_cap = ram->alloc(ds_size); … here I found that env_stack_area_ram_allocator is null, not initialized! in core base/src/core/stack_area.cc I found part which probably should be called before previous code: void Genode::init_stack_area() { static Stack_area_region_map rm; env_stack_area_region_map = &rm; static Stack_area_ram_allocator ram; env_stack_area_ram_allocator = &ram; } seems that this initializer should be called before libc component initializer (it belong to different component)? Nesessary initialization probably happens in class constructor of class Genode::Core_env : public Env_deprecated, Noncopyable base/src/core/include/core_env.h seems that something wrong in link sequence. Question: ======== how I can fix the order of different component initialization? I probably need class Genode::Core_ to be initialized first as a part of general code of core-nova.o. may be I missed something like crt*.o in link? crt0.o definitely present in $libs/startup-nova/startup-nova.lib.a… on previous version I found some magical sequence which works after some manipulations with link order, but now with 20.05 it is not working any more for me. Some info about my code: in my code dummy.cc I have function (C style) main and component constructor void Libc::Component::construct(Libc::Env &env) { // Genode::Heap heap(env.ram(), env.rm()); // _verbose = false; static int c = 1; static char * myname = "GolangApp"; int r = 0; Libc::with_libc([&r] () { r = main(c, &myname); }); env.parent().exit(r); } my current link command line: libs=/media/psf/Home/gen/20.05/build/x86_64/var/libcache; genode-x86-gcc -B /media/psf/Home/gen/20.05/build/x86_64/../tool_chain-19.05/x86/gcc/gcc/ -Wl,-melf_x86_64 -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--dynamic-list=/media/psf/Home/gen/20.05/repos/base/src/ld/genode_dyn.dl -nostdlib -Wl,-nostdlib -Wl,-Ttext=0x01000000 -m64 -mcmodel=large -Wl,--dynamic-linker=ld.lib.so -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-T -Wl,/media/psf/Home/gen/20.05/repos/base/src/ld/genode_dyn.ld -Wl,--whole-archive -Wl,--start-group dummy.o main.o myacontext.o mycontext.o $libs/base-nova-common/base-nova-common.lib.a $libs/base-nova/base-nova.lib.a $libs/startup-nova/startup-nova.lib.a $libs/timeout/timeout.lib.a ld.lib.so libc.lib.so libm.lib.so vfs.lib.so -Wl,--no-whole-archive -Wl,--end-group /media/psf/Home/gen/20.05/build/x86_64/var/libcache/libc-gen/libc-gen.lib.a /media/psf/Home/gen/20.05/build/x86_64/var/libcache/libgo/libgobegin.a /media/psf/Home/gen/20.05/build/x86_64/var/libcache/libgo/libgolibbegin.a /media/psf/Home/gen/20.05/build/x86_64/var/libcache/libgo/libgo.a /media/psf/Home/gen/20.05/build/x86_64/var/libcache/libc-stdlib/libc-stdlib.lib.a /media/psf/Home/gen/20.05/build/x86_64/var/libcache/cxx/cxx.lib.a /media/psf/Home/gen/20.05/build/x86_64/../tool_chain-19.05/x86/gcc/x86_64-pc-elf/64/libgcc/libgcc_eh.a /media/psf/Home/gen/20.05/build/x86_64/../tool_chain-19.05/x86/gcc/x86_64-pc-elf/64/libgcc/libgcc.a Thanks!

2 3

Re: Undefined references when extending Child in repo "Base"
by Simon Himmelbauer 06 Jul '20

06 Jul '20

Hi Sebastian, > In case you want to call 'Child::test_print()' from outside of the base > library (e.g., a dynamically linked program), you need to add the > mangled 'Child::test_print' symbol to the Genode base library symbol > file [1]. This way the dynamic linker can find and export the function. > > [1] repos/base/lib/symbols/ld Thanks for your help, I could fix the problem. However, I am wondering whether there is an automated way to insert the mangled symbols? It seems cumbersome to add every symbol by hand. Best regards, Simon

2 1

Virtualbox recipe?
by Lonnie Cumberland 06 Jul '20

06 Jul '20

Greetgins all, I am back at it to try and work with Genode and Sulpt OS 20.02 now and am wondering if there is a setting up and running virtualbox in sculpt OS recipe that is known to work and that I can follow to test out things here? Any help would be greatly appreciated. Cheers, Lonnie

2 1

Undefined references when extending Child in repo "Base"
by Simon Himmelbauer 06 Jul '20

06 Jul '20

Hi Genodians, I am attempting to extend the class Child (base/include/base/child.h) with an additional function. However, when compiling my test program, I receive an undefined references error, even though I added the implementation to src/lib/base/child.cc. My observation seems to be that the generated object file does not get linked into the executable but calling any other Child-related function works fine. My child.h looks pretty much like this: class Genode::Child : .... { .... void test_print(); } and in child.cc: void Child::test_print() { log(__PRETTY_FUNCTION__); } Is there anything I am overseeing? Thanks in advance! Cheers, Simon

2 1

Re: Genode 20.05 : how to build kernel nova with debugging symbol ?
by Alexander Boettcher 19 Jun '20

19 Jun '20

On 19.06.20 13:11, Parfait Tok wrote: > Hi Alex, > > > Le ven. 19 juin 2020 à 10:55, Alexander Boettcher < > alexander.boettcher(a)genode-labs.com> a écrit : > >> >> look into build/x86_64/debug directory. There you find the hypervisor >> binary with debugging symbols. >> >> That used to be the case until now. > I've just made a fresh install from the git and there is nowhere I can find > the *kernel* debugging symbols, > although other binaries debugging symbols are right there in the > build/x86_64/debug directory. > This is the list of commands I issued. > git clone https://github.com/genodelabs/genode.git genode20.05 > cd genode20.05/ > ./tool/create_builddir x86_64 > xxx/genode20.05/prepare_port dde_linux nova x86emu dde_ipxe dde_zircon libc > seoul x86emu nova grub2 -j8 > xxx/genode20.05/tool/depot/create > genodelabs/pkg/x86_64/drivers_interactive-pc > genodelabs/bin/x86_64/base-nova genodelabs/bin/x86_64/demo > genodelabs/bin/x86_64/global_keys_handler genodelabs/bin/x86_64/init > genodelabs/bin/x86_64/nit_focus genodelabs/bin/x86_64/nitpicker > genodelabs/bin/x86_64/report_rom genodelabs/bin/x86_64/rom_filter > CROSS_DEV_PREFIX=/usr/local/genode/tool/19.05/bin/genode-x86- > cd build/x86_64/ > make run/demo KERNEL=nova > After build completed, > find -name *hypervisor* > ./var/run/demo/boot/hypervisor > What did I miss? If you invoke a script, using depot packages, you indeed get no binaries with symbols. The packages by default contain only stripped binaries. In this case you have to build the binary once, since you want to debug it, e.g. in your case: make -C build/x86_64 KERNEL=nova kernel to find in build/x86_64/debug the binaries with debugging symbols. Cheers, Alex. -- Alexander Boettcher Genode Labs https://www.genode-labs.com - https://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Genode 20.05 : how to build kernel nova with debugging symbol ?
by Parfait Tok 18 Jun '20

18 Jun '20

Hello, With the latest version, I don't know where to find the kernel binary (Nova) with its debugging symbols. Is there any option to pass to the building script in order to get this? Or how to modify the script to generate the kernel debugging symbols? I used to comment the line > exec [cross_dev_prefix]strip [run_dir]/boot/hypervisor > in file > tool/run/boot_dir/nova > but with the 20.05 version, it does not help. Thanks

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users