users December 2018

users@lists.genode.org

16 participants
10 discussions

usb_drv error -92 for RPi | Genode 18.05 with Fiasco.OC 79
by Alexander Weidinger 18 Apr '19

18 Apr '19

Hello everyone, when executing 'lwip' on the RPi 2, I get the following output for the usb_drv: > [init -> usb_drv] dev_info: DWC OTG Controller > [init -> usb_drv] dev_info: new USB bus registered, assigned bus number 1 > [init -> usb_drv] dev_info: irq 9, io mem 0x00000000 > [init -> usb_drv] dev_info: USB hub found > [init -> usb_drv] dev_info: 1 port detected > [init -> usb_drv] dev_info: new high-speed USB device number 2 using dwc_otg > [init -> usb_drv] dev_error: device descriptor read/all, error -92 > [init -> usb_drv] dev_info: new high-speed USB device number 3 using dwc_otg > [init -> usb_drv] dev_error: device descriptor read/all, error -92 > [init -> usb_drv] dev_info: new high-speed USB device number 4 using dwc_otg > [init -> usb_drv] dev_error: device descriptor read/8, error -92 > [init -> usb_drv] dev_error: device descriptor read/8, error -92 > [init -> usb_drv] dev_info: new high-speed USB device number 5 using dwc_otg > [init -> usb_drv] dev_error: device descriptor read/8, error -92 > [init -> usb_drv] dev_error: device descriptor read/8, error -92 > [init -> usb_drv] dev_error: unable to enumerate USB device Does anyone have an idea what I can do, to get the Ethernet adapter working? Any help is appreciated! I don't really understand the problem here, since the driver works flawlessly for the RPi 1 B+ (using foc_rpi as platform) - which uses the same chip as the RPi 2 (SMSC LAN9514). My Genode version [2] and Fiasco.OC version [3]. To the backstory: ----------------- I am currently in the process of "porting" Fiasco.OC/Genode to the Raspberry Pi 2 (Model B). As a basis I use Genode in the version 18.05 and Fiasco.OC in the version 79. I created a new device, the rpi2, and based it on the already available rpi model. The main changes I did for the rpi2 platform [1] are - the different arm architecture - from armv6 to armv7a in a few files - the different physical base address - from 0x2000:0000 to 0x3f00:0000 - a RAM size of 1008 MB starting at 0x0000:0000 (1024 MB - 16 MB for peripherals) I use version 79 of the Fiasco.OC kernel since it adds support for the three different BCM283X platforms. In order to get version 79 of the kernel running with Genode, I used the official 79 as a basis and cherry-picked commits from Genode's version of Fiasco.OC (72). [0] My setup works completely fine for the RPi 1 (Model B+), even for the usb/nic driver. As the RPi 1 (Model B+) makes use of the SMSC LAN9514, instead of the SMSC LAN9512 (used in RPi Model B) it should also work for the RPi 2 (Model B), since this SBC also uses the SMSC LAN9514. [0] https://github.com/skalk/foc/commits/r72 [1] https://github.com/irgendwie/genode/commits/foc-rpi2 [2] https://github.com/irgendwie/genode/tree/foc-rpi2 [3] https://github.com/irgendwie/foc/tree/genode-r79-rpi2 ----------------- Best regards Alexander

5 15

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

Experiences with Sculpt VC
by Guido Witmond 19 Dec '18

19 Dec '18

Hi Genodians, I've been playing with Sculpt VC again. Doing so thought me a lot more about routing. This time I succeeded in creating a VM with partitions on two SATA disks. It runs Nixos inside with the /home partition on an encrypted ZFS mirror. (and the root partition on a virtual disk, just like the Debian VM). When I want to start the VM and the ahci-1.part_blk is not running, the Runtime manager reports with a diagnostic stating vm-nixos needs ahci-1.part_blk. To start my vm, I inspect a different partition on that disk. That starts the part_blk and Runtime starts my VM. So far so good. The problems start here: 1. When the VM runs and I stop inspecting that partition, the Runtime manager kills my VM. The manager was happy to start my VM when the resource came available but does not keep the part_blk alive when the inspector stops. 2. When the VM runs (and has a session to the part_blk for that partition, I can format that partition from the Storage component. I get data corruption errors in ZFS on that disk. (But ZFS lives on and repairs it from the other mirror). That seems to be in violation of The Book para 4.5.8: """The part-block component requests a single block session, parses a partition table, and hands out each partition as a separate block session to its clients. There can be one client for each partition. """ I would expect that the formatter would get an error because it should not get a session to that partition. Could someone shine a light on what's going on? The log file is here: https://paste.wtmnd.nl/xfNMa3yY I wrote a full write-up of my sculpting here: https://paste.wtmnd.nl/WKUQowg2 -- I intend to make it a blog post for others to learn from, hence the writing style. Regards, Guido.

2 3

OpenSSL version update
by Edward Sandberg 18 Dec '18

18 Dec '18

Hey everyone, I ported a new version of OpenSSL (1.1.0i) to Genode. I have it working for x86_32 and x86_64. All of my testing was done using the seL4 kernel. The changes are here: https://github.com/sand7000/genode/tree/openssl-1.1.0i Updating OpenSSL impacted Curl and LibSSH. I ported a newer version of Curl and started porting a newer version of LibSSH. Additional work is required to complete this, including adding support for ARM, completing the port of LibSSH and completing the depot packaging. The following is included in my release, if other folks want to carry it on from here: * OpenSSL 1.1.0i works for x86_32 and x86_64 * Curl 7.50.3 works for x86_32 and x86_64 * LibSSH 0.8.3 port compiles but I have not tested it -- Edward Sandberg Adventium Labs 111 3rd Avenue S. Suite #100 Minneapolis, MN 55401 ed.sandberg(a)adventiumlabs.com

2 2

TTS and Genode
by ttcoder＠netcourrier.com 14 Dec '18

14 Dec '18

Howdy all, We are a (very small) company looking for a good home for our software suite. The Be-derived OS we've been using served us well for a long time, but instability has become a problem of late, with kernel/drivers crashes -- obviously that is where a micro-kernel/framework would shine. My thinking goes, if we are to 'port' our SW we might as well go for state of the art. That way, it will be the first and last time we do that transition. Our clients don't need (nor event want!) all the bells and whistles of a commodity OS; they just need a solid kernel with our apps running full-screen. So it appears to be a perfect match with Genode/nova, nitpicker et alia, keeping in mind I of course have some huge work ahead of me. Anyway long story short: although I'm very enthusiastic about Genode, I first need to get my greedy hands on it and compile it. I've been failing at that repeatedly ever since doing my first git clone, ca. 18.05 A collaborative worksheet might be better suited for copy-pasting error messages and for organizing thoughts (rather than cluttering this mailing-list): I've created this etherpad as a companion venue for working on this, in case there is interest: https://etherpad.net/p/KcMuF3Ylbu_gcc I'll update it with my progress. Very eager to get the ball rolling and start working with Genode. If all else fails I guess I'll download/install/learn to use Linux. But since all my software is haiku native, I'd have to constantly reboot from one OS to the other, hurting productivity. It's probably worthwhile for me to invest time in building Genode and run 'scenarios' (qemu) directly from within Haiku. Thanks, Cedric, TuneTracker Systems LLC - http://www.tunetrackersystems.com

3 3

Skeleton / Example PCI Device Driver
by John J. Karcher 11 Dec '18

11 Dec '18

Hello, In my slow quest to port/write the VirtualBox Guest Additions, the first step is a driver for the virtual PCI device that handles communication with the VirtualBox host. Is there a skeleton device driver for PCI devices? My first goal is just the boilerplate init code, attaching to the IRQ and I/O memory, and logging the interrupts as they come in. If there isn't a skeleton driver, could anyone recommend the simplest example that I could use as a starting point? Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 1

prepare Qt5 port fails
by Pirmin Duss 11 Dec '18

11 Dec '18

Hallo Genodeans tool/port/prepare_port qt5 fails, as the file http://ftp.icm.edu.pl/packages/qt.old/solutions/lgpl/qtscriptclassic-1.0_1-… doesn't exist anymore. Is there a backup location that provides this file? Best regards, Pirmin

4 4

Activate Co-Processor for Bare-Metal via Genode
by Matthias Adams 06 Dec '18

06 Dec '18

Hello everyone, I am currently working on a Pandaboard ES, on which a Genode 18.02 runs using a L4 Kernel and I would like to use the Co-Processor of the Pandaboard (namely Cortex M3). I used an example like [1] in order to write my application for the M3, which works perfectly when loaded by the program suggested in [1]. [1] https://github.com/apopple/Pandaboard-FreeRTOS In order to get things working, when a Genode system is running on the main Processor (Cortex A9) I wrote a "driver" similar to the gpio driver, which should set-up the MMU for the M3 and start it, but absolutely nothing happens. The driver compiles and runs without any warnings or errors. Reads and writes to physical addresses look good to me, but the M3 does not seem to start (it should blink an LED for now). I triple checked all physical addresses, which I added to 'repos/base/include/drivers/defs/panda.h': /*M3 */ CM_MPU_M3_CLKSTCTRL_BASE = 0x4a008900, CM_MPU_M3_CLKSTCTRL_SIZE = 0x40, RM_MPU_M3_RSTCTRL_BASE = 0x4a306900, RM_MPU_M3_RSTCTRL_SIZE = 0x20, M3_L2MMU_BASE = 0x55082040, M3_L2MMU_SIZE = 0x40 I used these bases, in order to create my Registers like: struct M3_CM_MPU_reg : Genode::Attached_io_mem_dataspace, Genode::Mmio { M3_CM_MPU_reg(Genode::Env &env, Genode::addr_t const mmio_base, Genode::size_t const mmio_size) : Genode::Attached_io_mem_dataspace(env, mmio_base, mmio_size), Genode::Mmio((Genode::addr_t)local_addr<void>()) { } struct Clkstctrl : Register<0x00, 32> {}; struct Clkctrl : Register<0x20, 32> {}; }; struct M3_RM_MPU_reg : Genode::Attached_io_mem_dataspace, Genode::Mmio { M3_RM_MPU_reg(Genode::Env &env, Genode::addr_t const mmio_base, Genode::size_t const mmio_size) : Genode::Attached_io_mem_dataspace(env, mmio_base, mmio_size), Genode::Mmio((Genode::addr_t)local_addr<void>()) { } struct Rstctrl : Register<0x10, 32> {}; }; struct M3_L2MMU_reg : Genode::Attached_io_mem_dataspace, Genode::Mmio { M3_L2MMU_reg(Genode::Env &env, Genode::addr_t const mmio_base, Genode::size_t const mmio_size) : Genode::Attached_io_mem_dataspace(env, mmio_base, mmio_size), Genode::Mmio((Genode::addr_t)local_addr<void>()) { } struct Cntl : Register<0x4, 8> {}; struct Ttb : Register<0xc, 32> {}; }; The registers are then written and read in my driver like below: class Omap4_driver : public M3::Driver { private: Genode::Env &_env; M3_CM_MPU_reg _m3_cm_mpu; M3_RM_MPU_reg _m3_rm_mpu; M3_L2MMU_reg _m3_l2mmu; Omap4_driver(Genode::Env &env) : _env(env), // see repos/base/include/drivers/defs/panda.h _m3_cm_mpu(_env, Panda::CM_MPU_M3_CLKSTCTRL_BASE, Panda::CM_MPU_M3_CLKSTCTRL_SIZE), _m3_rm_mpu(_env, Panda::RM_MPU_M3_RSTCTRL_BASE, Panda::RM_MPU_M3_RSTCTRL_SIZE), _m3_l2mmu(_env, Panda::M3_L2MMU_BASE, Panda::M3_L2MMU_SIZE) { } public: static Omap4_driver& factory(Genode::Env &env); /****************************** ** M3::Driver interface ** ******************************/ void setup_l2mmu(Genode::addr_t ds_phys_addr, Genode::Ram_dataspace_capability ttb_cap, Genode::addr_t ttb_phys_addr) { Genode::addr_t ttb_addr = _env.rm().attach(ttb_cap); Genode::log("L2: attached dataspace"); /* Brings the L2 MMU out of reset and sets up virtual addresses */ unsigned clkctrl = _m3_cm_mpu.read<M3_CM_MPU_reg::Clkctrl>(); clkctrl = 0x01; _m3_cm_mpu.write<M3_CM_MPU_reg::Clkctrl>(clkctrl); unsigned clkstctrl = _m3_cm_mpu.read<M3_CM_MPU_reg::Clkstctrl>(); clkstctrl = 0x02; _m3_cm_mpu.write<M3_CM_MPU_reg::Clkstctrl>(clkstctrl); unsigned rstctrl = _m3_rm_mpu.read<M3_RM_MPU_reg::Rstctrl>(); rstctrl &= ~0x4; _m3_rm_mpu.write<M3_RM_MPU_reg::Rstctrl>(rstctrl); int *TTB = ((int*) ttb_addr); /* Initialise address translation table */ /* Every address will be mapped to M3_LOAD_ADDRESS */ for(int i = 0; i < 4096; i++) { TTB[i] = (((ds_phys_addr) & 0xfff00000) | 0x00c02); } /* Set the last entry to point to the GPIO1 peripheral to flash a light */ /* ie. Virtual address of GPIO1_DATAOUT is 0xfff1013c */ TTB[4095] = 0x4a300c02; /* Set the base address */ Genode::log("physAddr: ", Genode::Hex(ttb_phys_addr)); _m3_l2mmu.write<M3_L2MMU_reg::Ttb>(ttb_phys_addr); /* Enable MMU */ _m3_l2mmu.write<M3_L2MMU_reg::Cntl>(0x6); Genode::log("L2 enabled"); } void start_m3() { /* Release Cortex-M3 from reset */ unsigned rstctrl = _m3_rm_mpu.read<M3_RM_MPU_reg::Rstctrl>(); rstctrl &= ~1; _m3_rm_mpu.write<M3_RM_MPU_reg::Rstctrl>(rstctrl); } }; Any idea on how to get things working or on how to further debug would be great! Thanks, Matthias

1 0

How to pass command-line arguments to Genode application?
by Wouter van Oijen 03 Dec '18

03 Dec '18

Hello, I want to pass one or more command-line arguments to my Genode application. So instead of starting "mosquitto", I want to run "mosquitto -p 1888", for example. How do I do this? I've found run files that pass arguments to Noux applications (using a start-element inside the config-element), but this does not seem to work for my application. So how are command-line arguments passed to the application in general? Below is the part of the init configuration that I currently use to start the application. <start name="mosquitto"> <resource name="RAM" quantum="100M"/> <config> <vfs> <dir name="dev"> <log/> <rtc/> </dir> <dir name="socket"> <lwip ip_addr="10.0.2.55" netmask="255.255.255.0" gateway="10.0.2.1"/> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" rtc="/dev/rtc" socket="/socket" /> </config> </start> Regards, Wouter

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users December 2018