users November 2020

users@lists.genode.org

14 participants
21 discussions

Start a nNew thread

Network issue
by Dima Sokolov 01 Feb '21

01 Feb '21

3 3

mmap implementation for ANON mapping with desired address
by Alexander Tormasov 21 Dec '20

21 Dec '20

I am trying to implement not-yet supported (as mentioned by nfeske@ in mailing list) option for mmap() related to anonymous mapping with pre-defined (desired) address. Like libc function with desired address out_addr. void *Libc::Mem_alloc_impl::alloc_at(void *out_addr, size_t size) I use a couple of useful function in avl allocator. Anyway, I found that straight - forward implementation do not work because of allocation gaps filled together with main allocation. In particular, if we want to allocate e.g. 0x10000 from address 0x500000 then we typically allocate 0x13000 bytes, including ones for avl metadata/etc stored in the same space, and receive virtual address range used, e.g. 0x500000 - 0x513000: /* * Calculate block size of needed backing store. The block must hold the * requested 'size' with the requested alignment, a new Dataspace structure * and space for AVL-node slab blocks if the allocation above failed. * Finally, we align the size to a 4K page. */ size_t request_size = size + max((1 << align_log2), 1024) + Allocator_avl::slab_block_size() + sizeof(Dataspace); Software I used (golang runtime) sometimes try to expand previous allocation, e.g. it can request allocation of 0x8000 bytes before previous range, like 0x4f8000 - 0x500000. In that case I can’t perform the operation - because it will try to allocate 0xa000 bytes from desired address 0x4f8000 - and it obviously fail due to Range_conflict. So, I split allocation to 2 parts - one for this gap by standard alloc() and random placement and second one by my own alloc_at() with size exactly correspond to the requested one. Implementation available as a patch to 20.05 at https://github.com/tor-m6/genode/commit/78fc751bea8acc2b515e04bec9f3a883461… Problem I see here is a free operation: it just free the block with requested address, and do not touch others, gap-related blocks. For me it is not obvious that they need to be free, because in the code (e.g. by unmap()) I do not see explicit free of other allocated structures, in particular, dataspace extension or related block metadata. Question: should I make additional efforts to trace and delete something else - except what standard free does here: /* forward request to our local allocator */ _alloc.free(addr); Like for dataspace structure or address ranges for second «auxiliary» allocation? PS Another potential problem is a probability to overlap of first «random address» allocation with desired address. This happens with first attempt to implement allocator - it allocates address from desired range, and immediately put here 0x18 bytes of Dataspace structure, and then fail because requested address is already busy by this structure! Anyway, I consider such a probability relatively small with proposed approach and ignore it (may be I am wrong)

4 23

Announcement: Genode OS Framework version 20.11 released
by Norman Feske 27 Nov '20

27 Nov '20

We just released Genode version 20.11 today. With this version, we continue this year's overarching theme of supporting 64-bit ARM hardware. Thanks to intensive work on the framework's driver infrastructure and the actual device drivers, Sculpt OS has now become able to run on 64-bit ARM hardware, specifically the NXP i.MX8 EVK board. A second highlight of this release is the first version of our new CPU-load balancing mechanism, which aims at improving the CPU utilization when running complex multi-threaded workloads like a web browser on top of Genode. As with every Genode release, these major highlights are accompanied by many improvements throughout the framework, as listed here: - CPU-load balancing - Sculpt OS on 64-bit ARM hardware (i.MX8 EVK) - Multicore virtualization on ARM - VFS: Open Sound System ioctl emulation - VirtIO networking - Improved support for OpenBSD audio drivers - HWP support for recent PC hardware - NOVA: I/O-MMU support for AMD Please find the detailed release documentation at: https://genode.org/documentation/release-notes/20.11 Cheers 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

1 0

question about Region_map::Region_conflict in attach_at()
by Alexander Tormasov 17 Nov '20

17 Nov '20

Hi! I have a problem in the following code (64 bit NOVA 20.08, 3GB RAM, with gdb): void Component::construct(Env &env) { Rm_connection rm(env); Region_map_client my_rm(rm.create(0x1400000)); char *_base = env.rm().attach(my_rm.dataspace()); Region_map_client my1_rm(rm.create(0x1000)); env.rm().attach_at(my1_rm.dataspace(), 0x102e000); log("my create managed dataspace", Hex((addr_t)_base)); } it return _base [11000000,12400000) and it give error during attach_at() call (which is far from requested address 0x102e000) Error: Uncaught exception of type 'Genode::Region_map::Region_conflict’ Why it is happens? Where this error generated in the NOVA code (or genode NOVA wrapper)? I assume that I can create 2 RM clients to be able to fill it (attach_to) ds later? Thanks! Sincerely, Alexander run file #debug go application via gdb # set build_components { core init timer lib/ld drivers/uart app/gdb_monitor lib/vfs/pipe noux-pkg/mmaptest } lappend build_components "lib/gdbserver_platform-$::env(KERNEL)" build $build_components create_boot_directory proc local_heap_default_size {} { return "0x1400000" } install_config { <config verbose="yes" ld_verbose="yes"> <parent-provides> <service name="ROM" /> <service name="LOG" /> <service name="RM" /> <service name="CPU" /> <service name="PD" /> <service name="IRQ" /> <service name="IO_MEM" /> <service name="IO_PORT" /> </parent-provides> <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> <default caps="200" /> <start name="timer"> <resource name="RAM" quantum="2M»/> <provides> <service name="Timer"/> </provides> </start> <start name="pc_uart_drv"> <resource name="RAM" quantum="2M" /> <provides> <service name="Uart"/> <service name="Terminal"/> </provides> <config> <policy label_prefix="gdb_monitor" uart="1" /> </config> </start> <start name="gdb_monitor" caps="4800"> <resource name="RAM" quantum="80M" /> <provides> <service name="mmaptest" /> </provides> <config verbose="yes" ld_verbose="yes"> <target name="mmaptest" caps="2800"> <config verbose="yes" ld_verbose="yes" local_heap_default_size="} [local_heap_default_size] {"> <vfs> <dir name="dev"> <log /> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" /> </config> </target> <preserve name="RAM" quantum="50M" /> <vfs> <dir name="dev"> <log/> <terminal/> </dir> <dir name="pipe"> <pipe/> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" pipe="/pipe"/> </config> </start> </config> } # evaluated by the run tool proc binary_name_gdbserver_platform_lib_so { } { return "gdbserver_platform-$::env(KERNEL).lib.so" } build_boot_image { core init timer ld.lib.so libc.lib.so vfs.lib.so libm.lib.so pc_uart_drv posix.lib.so stdcxx.lib.so vfs_pipe.lib.so posix.lib.so stdcxx.lib.so vfs_pipe.lib.so gdb_monitor gdbserver_platform.lib.so vfs.lib.so mmaptest }

2 6

Re: Running Genode on a Raspberry Pi 3
by Simon Himmelbauer 15 Nov '20

15 Nov '20

Hi Genodians, I just wanted to give a quick update regarding my issue with the random output on the serial line when running a Genode image from uboot on a Raspberry Pi 3. The issue was somehow caused by the Raspberry firmware. Downgrading to commit 204245361ea, which is the same version Tomasz used for his tests, fixed my problem. I have not identified yet which commit is actually responsible for the regression. Thanks to everyone, especially Tomasz, for dedicating the time to assist me! Best regards, Simon

1 0

Genode and clang
by Piotr Tworek 13 Nov '20

13 Nov '20

Hello Genodians, A couple of months ago I started wondering how hard would it be to add Genode support to clang. Since I nowadays have bit of extra free time on my hands I decided to give this a try. As one may guess adding support for a new platform to a complex codebase like llvm/clang is a relatively big undertaking so I decided that for the first stage I want to limit the scope of the work a bit. 1. Clang running on already supported "host" platform (in my case Linux) to compile code for Genode on x86_64, x86_32, arm_v7a and arm_v8a architectures. No support for running clang and all the llvm utils on Genode itself. 2. Try to use as many llvm tools as possible (llvm-ar instead of GNU ar, llvm-objcopy instead of GNU objcopy, etc), but don't try to replace GCC toolchain completely if it requires major effort (ex clang integrated as instead of GNU as, ld.lld instead of ld.bfd, etc). 3. Use libstdc++, libsupc++, libgcc instead of respective llvm replacements. With those goals I started hacking and fast forwards those few months I've mostly achieved my goal. I currently have Clang 11.0.0 port able to compile working binaries for all the target architectures when using base-hw and base-linux. Obviously this did require a bunch of changes in Genode codebase itself, but most issues found were relatively simple and generally not specific to clang itself. For example clang is much better at spotting unused variables in the code, see the following PR: https://github.com/genodelabs/genode/pull/3938 When using clang I also managed to stumble upon some code relying on undefined behaviour, which happens to produce different results in clang than it does in GCC, ex: https://github.com/genodelabs/genode/pull/3941 Overall the number of problems encountered was lower than I expected, which I think puts Genode codebase in very positive light. As one may easily guess there is still a lot of code Genode project consists of which I haven't even tried building, yet. The reaason I'm writing this email is to ask if Genode project would be potentially interested in having clang support in the main repo? I know that officialy supporting another compiler might not be an interesting prospect for the project and I won't mind if the answer is no. Its enough for me if generic fixes I make get merged :). If there is an interest in clang support however, I'll be happy to spend a few evenings cleaning up my work and making a few more PRs out of it. If needed I can also push my remaing clang support patches in the existing, slightly chaotic form, to some branch so Genode developers can see how much work having clang support in Genode would entail. /ptw

2 2

Re: Running Genode on a Raspberry Pi 3
by Simon Himmelbauer 13 Nov '20

13 Nov '20

> Hi Simon, > > On 10.11.20 21:12, Simon Himmelbauer wrote: >> config.txt: >> >> enable_uart=1 >> arm_64bit=1 >> init_uart_baud=115200 >> kernel=u-boot.bin >> > does it work with the following line? > > init_uart_clock=3000000 > > I remembered it being mentioned on the mailing list in the past with regard to serial output issues. > > Christian Hi Christian, yeah, I have tried to add this line as well but it didn't make any difference. I followed Tomasz suggestion and set up a Genode 20.08 environment. I used the provided "hello_tutorial" as a test image and unfortunately, I still receive garbage output on the uart, even when changing the Fiasco.OC kernel to the Genode ("hw") kernel. Is there anything else I can try? My next idea would be to compile some older version of u-boot in order to see whether this fixes my problem. Other than that, I don't really know where to look at anymore. Best regards, Simon

1 0

armemu: grabbing file
by Michael Grunditz 13 Nov '20

13 Nov '20

Hi I have started on my arm32 emulator. Since I had problems with calling outside world from assembler, I start with pure c/c++. It is dead slow , but one thing is really promising. The code runs twice as fast on hw than on linux (same cpu) and in hw case the cpu is running on half speed. Now on to my question: I need to get my executable (32 bit binary) into a ds. Do I need to do read() / copy everything in or is there some magic bits I can use? Michael

2 2

Unable to build drivers/timer
by fixed-term.christo.bita＠sojus-software.de 12 Nov '20

12 Nov '20

Hello all, in the Genode OS 20.05 documentation, section "Using the build system/Building components", it says that the timer driver is build with the "make drivers/timer" command. In my case I get the following error "target 'drivers/timer' does not exist" as I tried the second part of the "hello world" lab. May the reason be that there is no "timer" directory, with the corresponding files, in the "os/src/drivers" directory? Best regards, Christo

2 2

Hello from RK3399! (including odd debug messages!)
by Michael Grunditz 11 Nov '20

11 Nov '20

Starting kernel ... xaydzKernel: cpu pool1 Kernel: cpu constructor Kernel: arch_init Kernel: cpu pool1 kernel initialized ROM modules: ROM: [0000000002212000,0000000002212184) config ROM: [000000000249c000,000000000249d000) core_log ROM: [000000000220f000,0000000002211698) hello ROM: [00000000021bd000,00000000021fe278) init ROM: [0000000002108000,00000000021bc570) ld.lib.so ROM: [000000000249a000,000000000249b000) platform_info ROM: [00000000021ff000,000000000220e9c0) timer Genode sculpt-20.08-72-g5be1c793a <local changes> 507 MiB RAM and 64533 caps assigned to init [init -> hello] Hello world from RK3399!

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users November 2020