users April 2019

users@lists.genode.org

17 participants
11 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

Heads-up about pending block-API changes
by Norman Feske 16 Apr '19

16 Apr '19

Hello everyone, hereby, I'd like to raise your awareness about pending API changes that affect block-level components. I post this here because block-level components outside our source tree will need an adaptation to the new API. The change consists of two parts, one for the server side and one of the client side. Both parts are already on our staging branch and will reach the master branch soon. The new server-side API is located at 'os/include/block/request_stream.h'. It is already part of Genode 19.02 but remained largely unused at the point of the release. In contrast to the traditional API at 'os/include/block/component.h', the new API anticipates the design of block services as state machines and is designed for the efficient batched processing of block operations. You can find an illustrative example of a block server using this API at 'os/src/test/block_request_stream'. The new client-side API has become part of the 'Block::Connection' located in 'os/include/block_session/connection.h'. Like the server-side API, it is designed for an asynchronous and batched mode of operation. It achieves this with the added notion of 'Job' objects associated to a connection. For more details, you can find the corresponding issue at [1]. The first component I updated to the new API is the block tester located at 'os/src/app/block_tester/'. So there is already a nice playground in the form of the block_tester.run and block_request_stream.run scripts, both located at 'os/run/'. [1] https://github.com/genodelabs/genode/issues/3283 The client-side as well as the server-side APIs completely hide the underlying packet stream mechanism so that we can - in the future once all components are migrated to the new API - simplify this transport mechanism. By hiding the packet stream, components become much simpler because the application code is no longer bothered with the handling of packet-stream corner cases. If you maintain custom block-level components, I hereby encourage you giving the new API a try and report your findings. At the current time, the original APIs are still maintained. So there can be smooth transition phase. Still, a few cosmetic adaptations even in the case of intermediately sticking to the old API are needed. * 'Block::Connection' has become a template. To make your code compile again, the default template argument may become handy. Just rename the type to 'Block::Connection<>'. * The 'Block::Session::info' RPC function has a new signature. Instead of using C-ish out parameters, the new version returns a compound object of type 'Info'. * The original 'Block::Session::Operations' type is gone. In practice, it was merely used to distinguished read-only from read-writeable block devices. Now, it has been superseded with a 'writeable' attribute of the 'Info' type. Much simpler. * SYNC and TRIM have become first-class asynchronous block operations. The former 'sync' RPC function does not exist anymore. I hope you like the direction for the API changes. Your feedback is very welcome. If this direction turns out well, we may take the design as blue print for other asynchronous inter-component communication APIs (NIC and file system come in mind) in the future. 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

Genodians.org Feature Requests
by John J. Karcher 09 Apr '19

09 Apr '19

Hello Genodians, The content on Genodians.org has been so interesting and varied that I worry we might lose valuable content in the sheer volume as time goes by. Here are a couple of ideas that I thought might help (probably already on the "to do" list, but just in case): 1. "Sticky" / "Featured" Posts - Things like the announcement for the latest release, other important news, etc. should probably be kept at/near the top or in a special area. 2. Search / Filter Tags - I think it would be helpful to add "tags" to the posts to make it easier to find items on a certain subject. I would recommend defining the format and adding the tag data as soon as possible, even if the feature isn't implemented for a while - it's always harder to go back over a lot of data than to enter it as the records are added. Just food for thought... Thanks! -- John J. Karcher devuser(a)alternateapproach.com

8 12

Genode Corner
by John J. Karcher 08 Apr '19

08 Apr '19

Hello Genodians, Over the last week or so, I slapped together a quick web page I am calling "Genode Corner", which is an attempt at a very simple community site for Genode users: http://www.alternateapproach.com/Computing/Genode/Genode_Corner/index.html Don't expect much. I am not a real web designer, and there is no interactivity at this stage. (It is generated from static XML files using client-side JavaScript.) And there is very little data to start. The point of it is to collect some useful information in one place for easy reference. For instance, I implemented my own feature request of "sticky" Genodians.org articles. ;^) Let me know if anyone sees any value in it. I am considering putting together a simple back-end, using a real database, which could eventually allow interactivity. But the effort I put into it will probably be proportional to the amount of interest. I put an e-mail alias on the bottom of the page to contact me about it. Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 1

Is anyone else running seL4 on the iMX.6 sabrelite?
by Joel Desermeau 08 Apr '19

08 Apr '19

I have a few noobish questions that I hope someone could answer! - After making a custom boot image, how should I format the sd card and where should I place the image? -How can I get u-boot to boot the image? Thanks :p Joel Desermeau

2 1

Noux dev environment
by Joel Desermeau 06 Apr '19

06 Apr '19

Hello again my friends :) I'm just a junior sysadmin, but I want to learn how to program in C and C++. Could a noux environment be created with compilers and debugging programs like gdb and valgrind? Maybe one day I'll be good enough to be a Genode developer :) I can dream. Joel Desermeau

2 1

My personal wishlist
by Joel Desermeau 02 Apr '19

02 Apr '19

Stickynotes are cute and would be easy to implement, but here is my real Genode wishlist: Email client - I would be happy with anything IRC client - I love communicating with IRC chat, and the folks at #genode are very helpful :) RSS Reader - I have my most important news sent to me via RSS, and it seems most Genodians like RSS as well Native Firefox - this is but a dream Office Suite - I hear LibreOffice is being ported to Genode?? Cool stuff indeed VPN - Wireguard/OpenVPN GUI audio player With all of this, I would be able to switch to Genode without needing to virtualize anything. I would be as happy as a clam

6 8

iMX6 sd_card file systems > 2GB
by Pirmin Duss 02 Apr '19

02 Apr '19

Hello Genodeans I have created a run script that creates a file system a SD-Card (4GB) connected to my iMX6q. Whenever I try to create a file system that is larger than 2048MB, mkfs.ext2 fails with "Bad file descriptor while zeroing block 953328 at end of filesystem". This lets me think, that probably there is a overflow in a signed 32-Bit integer somewhere. I have tried to understand how the sd_card_drv operates. If I'm understanding it right, the read_dma()/write_dma() functions pass the block_number (64-Bit value) to the constructor of Write_multiple_block, which in turn stores it in its arg member (32-Bit register). But this, truncation of the block number, would not explain to me why the error occurs after 2GB, as the data on the sd_card is accessed in blocks of 4096 bytes. Can anybody help me with some clues, where to investigate further? Best regards, Pirmin

1 0

Re: New french Wikipedia article about Genode
by Valery V. Sedletski 01 Apr '19

01 Apr '19

Sebastian Sumpf wrote: > Hey Valery, > > On 3/28/19 7:05 PM, Valery V. Sedletski wrote: >> Martin Stein wrote: >>> I'm happy to announce that, thanks to a collaboration with the >>> community >>> member 'ttcoder', Genode can now also be found on the french Wikipedia: >>> >>> https://fr.wikipedia.org/wiki/Genode >>> >>> If there are French speakers who would like to review it and mail me >>> corrections (or apply them directly if they like to), this would be >>> very >>> appreciated! >>> >>> I also again encourage everyone whose native language (or well known >>> second language) cannot be found yet amongst the Genode >>> Wikipedia-articles: If you'd like to fix this, please let me know. Your >>> translation skills would be of big help! >> I could try to update russian wikipedia article. Though, it's content is >> completely different from english article. Also, it's name is >> "Genode_OS_Framework", instead of being just "Genode". So, I'd suggest >> to preserve the old article as is, and create a second "Genode" article, >> which >> should be the translation of the official english article. What do you >> think? >> Is the older article needed? It would be better to have russian >> translation >> the same name as the english original. The older page may contain some >> additional info. We could add a link to the older page from the new one, >> and link to the english original, in case someone needs it. > Cool to hear that you are up for it. A completely new article sounds > great. If it is possible I would altogether remove the old article and > add any information that is missing to the new one. Yes, I'd better even merge the content of both articles, and create a redirect from one name to another. The existing article also contain some additional information, some of which is outdated. As people noted, the old russian wikipedia article existed before any other national articles, and it contains some original content, whereas other national articles are mostly translations of the english one. So, russian article misses some useful info that the official one contained, but it contains some extra info. > The old article seems to be updated, though, because it shows the > latest Genode release. Yes, there were some edits in this month. So, it is a bit updated, but some info, like about L4Linux port, which is discontinued, is a bit outdated. > Maybe we could get in touch with the author who did these latest changes > (in case it was not you). If this is not feasible, we could mark the > old article as outdated and link to the new one at the top. Yes, I also think so. I need to contact the original article authors and discuss it with them. (I know one of the authors, it is my friend Oxyd. But he had disappeared for some time, so I need to have the occassion to meet him again to discuss it). For now, I created the draft for my translation here: https://ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0… Most probably, we'll need to join the content of both articles into the "Genode" article, and create a redirect from the "Genode_OS_Framework" page (or vice versa). Greetings, Sebastian

2 3

QTimer clock source in Genode
by Steven Harp 01 Apr '19

01 Apr '19

I tripped across a situation where one of my Qt5 applications that used a periodic QTimer stops receiving timeout signals after 1 hour 10 minutes of normal operation. (This is in Genode 18.08, x86_32 and x86_64, nova and seL4.) The same application keeps on ticking (for many hours at least) when compiled and run under Linux. A Qt Forum participant speculates "a 2^32 wraparound? Because 4294967296 (2^32) microseconds is 4295 seconds." This is just about the observed time. The Qt5 documentation suggests that some Qt timers on some platforms can have this problem--it depends on the underlying clock source. Can anyone comment on the relevant clock source for QTimer in the Genode port? For reference, a native Genode Timer connection does not exhibit this problem, so using it in this application was a viable workaround. // Steve

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users April 2019