users

users@lists.genode.org

1 participants
2310 discussions

Genode on RPI
by Tomasz Gajewski 30 Jan '19

30 Jan '19

Hi, I'll try to quickly move discussion about rpi to new thread to not pollute thread about Roadmap 2019. Bob Stewart <robjsstewart(a)gmail.com> writes: > I'm working on implementing a base-hw kernel on a Cortex A53 platform > (not Rpi) which is what the Rpi 3x is based on. So, that means a > significant amount of work to convert from the existing Genode code > supporting the armv7 architecture to support the armv8 > architecture. I'm focused initially on only the aarch64 instruction > set, but will later add support for aarch32. This is a retirement > project for me so my progress is not driven by any great need and is > slow. After about six months of casual working I'm at the stage of > debugging a virtual memory translation table enhancements need to > support 64-bit memory (a new Level-0 table in the page table code in > lpae.h). The means all the assembly code changes required have been > made (and about 12 other areas of change) and I clean compile a from a > log run script. My plans did not include targetting 64 bit implementation as seems to be too big target for amount of time I can devote to it. I just wanted to fix/workaround some problems which I expected to find when dealing with device drivers - not earlier. And only trying to use code available in Genode already (so 32bit for ARMv7). If I correctly understand 32bit instruction set for ARMv8 should be compatible with ARMv7. Am I wrong with this assumption? > For debugging at this level, you really only have two choices: Either > delve into the ARM hardware debugging facilites (CoreSight) or insert > small pieces of code to poke variable values or a trace number into a > currently unused region of memory. Code like: > > using ull = unsigned long long; > ull volatile * debug_ptr = (ull *)0x91000600; > *debug_ptr = MAX_ENTRIES; > debug_ptr += 0x01; > *debug_ptr = BLOCK_SIZE_LOG2; > debug_ptr += 0x01; > > if your booting into uboot to start up, you can inspect the memory > region through uboots' md command. Breakpoints can be implemented with > the assembly code line: asm volatile("hlt #01\n"); . Objdump gives > you the assembly code listing if you need it. Do I correctly understand, that I can go back to u-boot after running Genode with 'hlt #01' and analyze content of memory there? I would be surprised but definitely it would be useful. > I sincerely hope Genode does not implement a version of the Linux > DT. It is an error prone approach developed many years ago in the > embedded world. There are more elegant, syntax checkable, > configuration description approaches available today. Could you give some hints about those alternatives? I have no experience in this area and what seems to be tempting in device tree is that when you look into linux sources there are already dts files for all flavours of RPI including mine. U-boot uses this too - I wanted to use source from this due to smaller amount of code but that probably doesn't matter much. > Let me know if I can help with any compile/link issues you have, I > probably came across most of them in my work to-date. I'm using a > Linaro tool chain for aarch64. There is a separate one for aarch32 > which I don't currently use. Currently my "problem" is that my RPI doesn't pass through marked line in crt0.s /***************************************************** ** Setup multiprocessor-aware kernel stack-pointer ** *****************************************************/ mov sp, #0 /* for boot cpu use id 0 */ --> cps #31 /* change to system mode */ .global _start_setup_stack /* entrypoint for all cpus */ _start_setup_stack: I think it is due to RPI firmware is leaving processor in HYP mode - not SVC. But currently this is all I know. I tried to put code from FOC that is used switch processor back to SVC mode but as I don't understand details of it yet something is not working. There is some similar code in Genode implementation for Arndale board. On the other hand - maybe running in HYP mode is what is better for Genode? Some hints? If I comment out section with 'cps #31' it goes further and I it does not return from 'Bootstrap::Platform & p = Bootstrap::platform();' in 'extern "C" void init()' and last place which I found that is executing is constructor: Bootstrap::Platform::Board::Board in 'repos/base-hw/src/bootstrap/spec/rpi/platform.cc' I'll try to find out more and ask more specific questions about this part. Tomasz Gajewski

4 15

Amateur Radio
by Tyrell Jentink 29 Jan '19

29 Jan '19

Hello everyone, I am new to this mailing list, and to Genode generally; I will probably be doing most of my experiments in the near future with a Raspberry Pi, and I'm likely to be fairly quiet about it, but I haven't actually fired anything up yet. My background is with Linux, and I anticipate a bit of discomfort as I try to adapt to the Genode Way... My interest is largely in Amateur Radio; The Linux community has a long history of supporting Amateur Radio with protocol stacks (Such as AX.25) and both hardware and virtual Terminal Node Controllers in the kernel. There are also userland implimentations. Some of those run on Windows... some are open source... In other words, lots of code is out there... In various levels of loyalty to the Unix philosophy... Putting it in the kernel may have never made sense... And the "Genode Way" has value in organizing the complexity of the AX.25 networking stack, similar to how it separates the organization of the Ethernet stack... How much, if any, actually belongs in Genode and/or Sculpt OS is beyond me... It all probably deserves to be an installable package, rather than a core package... But it probably also benefits from Capabilities, as it will interface with hardware, so probably more than just an untrusted Linux instance... Fldigi also seems like it could benefit from being broken apart into smaller components, with a stronger capability based trust model... Or not, I really don't know... Anyway... I'm new... And I'm still trying to wrap my head around the "Right" way to think about these things... Are there any other hams out there interested in bouncing around ideas? 73, Tyrell Jentink, KD7TKJ

1 0

target 'lib/ld/linux' does not exist
by Wouter van Oijen 28 Jan '19

28 Jan '19

Hi, When I try to run a scenario with "KERNEL=nova" on platform "linux", in most cases I get the following error: Error: target 'lib/ld/linux' does not exist Does anybody know what causes this and how I can resolve this error? (NB: I'm currently working with Genode 18.08 on Ubuntu 16.04.10) Kind regards, Wouter van Oijen

2 3

Networking under linux platform
by Chris 28 Jan '19

28 Jan '19

Dear Genodians, I have been successfully playing around with Networking in the 16.XX releases using the linux_x86 platform as a target. My genode instance used to run in a Ubuntu 14.04 LTS VM with a Windows host. Despite the "creative" setup, the tun/tap setup bridged with one of the VM's adapters worked like a charm. After a jump to 18.11, using the linux platform as a target, I am experiencing troubles with the linux_nic_drv: The creation the driver component seems to fail during the creation of the file descriptors for its dataspaces: lx_mmap in _map_local fails with 22 (EINVAL) (see attached console output from the lwip_lx example). I tested under Ubuntu 14.04 LTS in my old build environment as well as on a vanilla 16.04 LTS with a freshly installed genode toolchain & the current master. Other examples, such as the demo scenario, run without any problems. I have found an older discussion on the list from 2014 about failed memory mappings, but the thread ended without coming to a real conclusion. I'd be more than glad for any idea what where to look for possible reasons for this behavior. Best regards, Chris ======= console log, for run/lwip_lx =========== using 'core-linux' as 'core' using 'linux_timer_drv' as 'timer' using 'ld-linux.lib.so' as 'ld.lib.so' spawn ./core Genode 18.11-117-ged65267 <local changes> 17592186044415 MiB RAM and 8998 caps assigned to init [init] parent provides [init] service "ROM" [init] service "IRQ" [init] service "IO_MEM" [init] service "IO_PORT" [init] service "PD" [init] service "RM" [init] service "CPU" [init] service "LOG" [init] child "timer" [init] RAM quota: 776K [init] cap quota: 68 [init] ELF binary: timer [init] priority: 0 [init] provides service Timer [init] child "linux_nic_drv" [init] RAM quota: 3848K [init] cap quota: 68 [init] ELF binary: linux_nic_drv [init] priority: 0 [init] provides service Nic [init] child "test-lwip_httpsrv" [init] RAM quota: 4872K [init] cap quota: 68 [init] ELF binary: test-lwip_httpsrv [init] priority: 0 [init -> linux_nic_drv] Error: _map_local: lx_mmap failed(addr_in=0x0, addr_out=0xffffffffffffffea/-22) overmap=0 [init -> linux_nic_drv] Error: LD: exception during program load: 'Genode::Region_map::Region_conflict' [init -> linux_nic_drv] Error: Uncaught exception of type 'Genode::Region_map::Region_conflict' [init -> linux_nic_drv] Warning: abort called - thread: ep Warning: blocking canceled in entrypoint constructor [init] child "linux_nic_drv" exited with exit value 1 [init -> test-lwip_httpsrv] Error: LD: symbol not found: '_nsyyin' [init -> test-lwip_httpsrv] Error: Uncaught exception of type 'Linker::Not_found' [init -> test-lwip_httpsrv] Warning: abort called - thread: ep [init] child "test-lwip_httpsrv" exited with exit value 1 [init] child "timer" announces service "Timer"

2 1

create_uboot for wand_quad
by Pirmin Duss 24 Jan '19

24 Jan '19

Hello Genodeans I'm currently porting Genode to the Apalis iMX6 board of Toradex. As a starting point I used the wand_quad. Currently I'm able to build run/log for both base-hw and base-sel4. My problem arises when I run tool/create_uboot I get the following error: In file included from /var/cache/genode_contrib/uboot/include/linux/compiler.h:54:0, from /var/cache/genode_contrib/uboot/include/linux/byteorder/little_endian.h:12, from /var/cache/genode_contrib/uboot/arch/arm/include/asm/byteorder.h:29, from /var/cache/genode_contrib/uboot/include/compiler.h:125, from /var/cache/genode_contrib/uboot/include/image.h:19, from /var/cache/genode_contrib/uboot/include/common.h:82: /var/cache/genode_contrib/uboot/include/linux/compiler-gcc.h:114:30: fatal error: linux/compiler-gcc6.h: No such file or directory #include gcc_header(__GNUC__) ^ I have a work around, for compiling Uboot. By using the uboot tree provided by Toradex (see: https://github.com/trimpim/genode/blob/apalis_imx6/tool/create_uboot) the Image is created. Does Martin's uboot tree do some special configuration things? the only change I see is that it adds an empty file. Best regards, Pirmin

2 1

This year's Genode Hack'n'Hike
by Norman Feske 23 Jan '19

23 Jan '19

Hello, there will be another Genode Hack'n'Hike this year! Besides FOSDEM, this annual event is certainly one the Genode highlights of the year. It is a small gathering of around 10 to 20 developers and enthusiasts of Genode and provides a healthy mix of daylight outdoor activities and candlelight hacking activities. The informal character of the Hack'n'Hike presents a great opportunity for newcomers to get acquainted with the people behind Genode. This year, it will take place during May 10 to 13 in Königstein nearby Dresden/Germany. The event is sponsored by Genode Labs. There is no registration fee. If you like to participate, please register by commenting at the corresponding topic on our issue tracker linked below. There you can also find the most up-to-date information about traveling arrangements and the exact location: https://github.com/genodelabs/genode/issues/2841 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

Error: hammer ABI contains Genode-internal symbol '__bss_start'
by Guido Witmond 18 Jan '19

18 Jan '19

Dear Genodians, I'm back at learning how to do packaging. By following the developer-resources/porting_libraries guide, I ported the Hammer parser combinator library into a Genode port [1]. It builds and runs a simple test. (commit 665e71d). Now I want to make it a depot package. I copied the structure from libports/expat and adapted it. I have a recipes/{api,src}/content.mk (commit XXXXXX) I created the lib/symbols/hammer file by ! tool/abi_symbols bin/hammer.lib.so Then I run the build: ! ~/genode/tool/depot/create guido/bin/x86_64/hammer UPDATE_VERSIONS=1 FORCE=1 KEEP_BUILD_DIR=1 It starts good: ! created guido/api/base/2018-11-23 ! created guido/api/hammer/2019-01-08 ! created guido/api/libc/2018-11-26 ! created guido/src/hammer/2019-01-08-a However, I get this error during the compile of hammer. ! MERGE hammer.lib.so ! Error: hammer ABI contains Genode-internal symbol '__bss_start', ! Error: hammer ABI contains Genode-internal symbol '__eh_frame_start__' all from the symbol_blacklist defined in check_abi. It ends with this error: recipe for target 'hammer.lib.checked' failed So where did I go wrong? (Maybe this is an item for the list of missing documentation). 1: https://github.com/gwitmond/genode-hammer-library

3 7

I would like you to intergrate my work in bt2hmda in Genode
by Unidef 16 Jan '19

16 Jan '19

Bt2hmda stands for binary trees to high multidimensional arrays Sample code is at https://GitHub.com/unidef/quantum It doesn’t have to be large arrays, it can be like twenty arrays of 5 I still need to write how to move in neural space, but I failed calculus so I plum gave up You’ll need a revolving dma to properly adequate it to modern pc’s, but my dream is to make it into a small sql library that can hold exobytes through md threading and buffering Sent from my iPhone

1 0

Roadmap 2019
by Norman Feske 15 Jan '19

15 Jan '19

Hallo everyone, hereby, I'd like to follow up on our tradition to discuss Genode's road map on the mailing list. Let's take the turn of the year to recapture the events of 2018 and make plans for the next twelve months. Please feel welcome to chime in! By mid of January, I'll finalize Genode's official road map and would like to take your input into account. In the following, let me share my personal reflections and goals. The Year of Sculpt When I declared 2018 as Genode's Year of Sculpt, I had no concrete idea how Sculpt OS would shape up. I was convinced that we had - functionality-wise - all building blocks of a general-purpose OS in place. But it was rather unclear how to best put them together to attain a practical system. The unconquered design space seemed vast, which was both exciting but also - at times - a bit paralyzing. I ultimately had to bang a few nails into the wall, taking decisions with uncertain outcome. The Year of Sculpt was - more than anything - a design-space exploration, not an up-front planned activity. In the process, I came up with many half-baked thoughts and had the fortune of having our team at Genode Labs scrutinizing my ideas while also taking me seriously. Whenever an idea was indefensible, we jointly came up with a better one. Whenever uncertain about a proposed solution, I went forward with implementing it and took our team as guinea pigs. Whenever an idea was blocked by a limitation of an existing component, I could count on the support of the others to lend a helping hand with tweaking the components as needed. Unsurprisingly, many topics of the past year had a direct connection to Sculpt, e.g., the NIC router, the huge device-driver efforts, the GUI-stack improvements, and the work on the file-system and networks stacks. For me personally, this ride was certainly the most rewarding period in Genode's history so far. Now, when looking at the result, I am overwhelmed about what we achieved together! Whenever I have the chance to showing off Sculpt running on my laptop, Sculpt doesn't fail to impress. That said, during the course of the year, this positive sense of achievement eventually blended with the rather dull feeling that our hard work remains largely unnoticed outside the inner circle of Genode enthusiasts. The public at large remains quite indifferent (e.g., I was unable to capture the interest of FOSDEM to feature a talk about Sculpt OS on their main track). For a long time, I tricked myself into believing that once we overcome all technical road blocks, Genode will eventually become widely recognized automatically. There was always a technical challenge to take on. With Sculpt, we have reached a point where this excuse doesn't hold anymore. There is no technical piece missing. This leaves me with the question of how to make Genode relevant at a larger scale? Since this is not a technical question, I admittedly struggle to find a good answer. When thinking of the overall leitmotif for 2019, I always come back to this question. Plan for 2019 I see three directions to help Genode to become more widely recognized. 1) Widening the audience of Sculpt OS 2) Fostering the community spirit around our project 3) Marketing of Genode-based products Let me outline my thoughts behind each point. 1) Widening the audience of Sculpt OS Sculpt works well, but it is arguably still too hard to use for non-technical users and it lacks a lot of software that users take for granted today. Consequently, we should improve its ease of use. In particular, I'd love to explore the more consequent use of Sculpt's component graph as an intuitive user interface for both the composition and the configuration of components. The ultimate goal would be to eliminate the need for editing any text files. With respect to software availability, I have high hopes in the Genode SDK that we introduced in Genode 18.11. Let's follow this route further. 2) Fostering the community spirit around our project Our project enjoys a healthy community of users and contributors. But the community is rather scattered and the various groups work pretty much in isolation. As a result, the work of one group is often invisible to the others, not to speak of any public visibility. Could we possibly establish an instrument that would help each participant to gain more visibility and thereby help the community at large to become more relevant? I'll come up with a concrete proposal for such an instrument soon. One technical element may be a feature of Sculpt that would allow the user to browse the software depots provided by various community members and install/deploy packages by just a few clicks. This would vastly ease the discoverability of the available software and highlight the roles of the respective developers. A non-technical element may be a dissemination of Genode-related news at a higher rate than the current release announcements. 3) Marketing of Genode-based products Let's build Genode-based solutions to real-world problems and talk about them. The more diverse the solutions, the better. Be it server appliances, network equipment, controlling devices, or other forms of embedded systems, there are so many opportunities. One important trait of such products is the trustworthiness of Genode. So we constantly need to reinforce the confidence in Genode's quality. We should continue and expand our quality-assurance and software-hardening activities. For example, I see a huge potential in cultivating the use of Ada/SPARK for certain security-critical components. These are my high-level thoughts about the direction of the project. I deliberately left out a list of technical items from this initial posting. Let's fill in the technical substance together. :-) Please don't hesitate to share your thoughts. You may consider the following questions: * What are your ambitions for 2018? * Which areas of Genode would you like to see improved? How would you possibly contribute to these improvements? * Which technical topics do you find tempting? * If you imagine a Genode-based system one year in the future, how would it look like? * Do you have further ideas that would help making Genode relevant at a larger scale than today? 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

12 27

Re: Roadmap 2019
by ttcoder＠netcourrier.com 14 Jan '19

14 Jan '19

Thank you for the encouragement Norman. That gives me determination to deliver on the 'hype' I posted.. and be useful to the community this coming year. Now that I'm aware of the upcoming "genodians.org" it seems I should have waited before registering at neocities.org Anyway here's the micro-blog as it is now: https://tts-genode.neocities.org/genode.html Will migrate the entries in there to genodians.org when is ready -- looking forward to it yes. More entries are queued up to help "prime the pump" if need be. > We ultimately should strive for a agreed-upon official way. Right now, > however, I feel that it's still too early to take informed decisions. So > may we take 2019 as the year for desktop experimentation? I'll try to do my part, fueled by feedback as well. 'Experimentation' is an interesting perspective: One key ingredient/catalyzer, I believe, is ease of programming: when things take a lot of time and energy, developers get 'shy', overly cautious, think twice before coding.. Discussions heat up as there is more at stake. When it's easy to come up with an (at least partial) implementation however, the discussion is less abstract as it moves forward supported by quickly-put together concrete examples. Over time my 'library' of code and framework have reached a point where I can write GUI code very easily and quickly.. Meaning any given project does not have me too worried about it possibly ending up in the trash later. (as the Jam/MR guys say, "make simple things simple, make complex things manageable") We'll see how that factors in! > Indeed. However, we have a rough plan to enable features like > screenshots and screen recording. Maybe, these are worth considering for > the road map? Considering the conflicting imperatives -- prioritizing security on the one hand, and some quote-unquote "urgency" to enable developers to "show off" on the other hand... Maybe it would make sense to prioritize implementing (a rough version of) the feature, but keep it hidden behind a compile-time flag? There would be a prominent comment near the if-def, "leave this commented out in production!" Just a thought. I can use a digital camera to shoot the screen in the meantime. Cedric

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users