users July 2018

users@lists.genode.org

23 participants
26 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

Change to usb_drv? (17.11 -> 18.05)
by Steven Johnston 16 Aug '18

16 Aug '18

Hi All: One of my components that handles a USB device was working in 17.11 (x86_32, nova), but is causing problems when I attempt to run it in 18.05. The device is an FTDI-based USB-GPIO adapter (FT232H chip), along with a port of libftdi. The USB hub setup seems to work, but the FTDI setup generates an error in the log "ftdi_usb_reset failed", occurring when libusb_control_transfer() fails during a USB reset. There is a similar sounding issue mentioned in the release notes regarding usb_block_drv. Might it be the same? If so, has this been resolved in some general way? Thank you for any input, Steven

3 2

vfs_cow
by Roman Iten 30 Jul '18

30 Jul '18

Hello I created a vfs package archive containing vfs and vfs_cow and start it within the sculpt runtime providing the following configuration: <config> <vfs> <dir name="immutable"> <fs label="template_data"/> </dir> <dir name="mutable"> <fs label="user_data"/> </dir> <dir name="cow"> <cow ro="/immutable" rw="/mutable"/> </dir> </vfs> <default-policy root="/cow" writeable="yes"/> </config> Then, I changed the "target" file system of the noux package to use the above copy-on-write file system to play around with it... First thing I noticed is that the directories and files of "template_data" are not populated. I guess that's a feature that is not yet or will not be implemented and for my use case it doesn't bother me right now. But when I open/write a file (that exists in template_data), cow_vfs writes the following output: [runtime -> cow_fs] Warning: COW: block for replication... [runtime -> cow_fs] Warning: COW: block for replication... ...and never unblocks afterwards. If immutable is something like </ram> or </inline ...>, it works as I would expect it. Is this a known limitation? Or can someone point me to the right direction to solve it? I love the idea of the vfs_cow component and I guess it may cover many other use cases! Cheers, Roman

2 4

Fullscreen VM in sculpt
by Pirmin Duss 25 Jul '18

25 Jul '18

Hello Genodeans I would like to use my virtual machine in fullscreen mode on my sculpt. If I'm interpreting the configuration of the floating_window_layouter correctly, the key combination [SCREEN]+[ENTER] will toggle the fullscreen mode of a window. Further there is a normally disabled configuration in /config/input_fliter that remaps the key [LEFTMETA] to [SCREEN]. However when I enable the remapping and start the wm and the virtual machine, pressing [LEFTMETA] and [ENTER] as described in the sequence of the layouter.config nothing happens. Do I need to change something else? Best regards, Pirmin

5 8

Sculpt - default partition GENODE*
by Tomasz Gajewski 21 Jul '18

21 Jul '18

In the documentation of Sculpt-TC there is: The storage dialog hosts a convenient "Default" button that allows one to toggle a partition label between "GENODE" and "GENODE*". I don't have such a button. Is it a bug in documentation, bug in code or there are some restrictions under which it should appear? Regards Tomasz Gajewski

2 2

Creating an IRQ session
by Harsha Sharma 20 Jul '18

20 Jul '18

Hello, I get the following error when child component issues a session request for IRQ session: Error: Binding IRQ to the ICU failed But parent returns a session capability and then Error: unavailable IRQ requested I just want to test implementing different kind of sessions. Any help will be really appreciated. Thank you so much for your time. Regards, Harsha Sharma

2 4

Error: ID space not empty at destruction time
by Stefan Thöni 20 Jul '18

20 Jul '18

Hello Genodians, when the verify tool is terminated by removal from the init config after having done its job both ram_fs used for public and depot yield an "Error: ID space not empty at destruction time". Should I worry about these errors? Bests Stefan -- Freundliche Grüsse Stefan Thöni Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

lxip vfs and RM-session
by Stefan Thöni 19 Jul '18

19 Jul '18

Hello Genodians, I'm currently trying to use a lxip stack in a vfs component (name tcpip) in a package in the sculpt runtime. This fails with the following error: [runtime] Warning: upd: no route to service "RM" [runtime -> upd -> tcpip] Error: RM-session creation failed (ram_quota=65536, cap_quota=2) [runtime -> upd -> tcpip] Error: __cxa_guard_abort called [runtime -> upd -> tcpip] Error: failed to create <lxip> VFS node [runtime -> upd -> tcpip] Error: dhcp="yes" The RM-session seems properly configured in both runtime and deploy. The "tcpip" vfs component then continues to run and accepts file system session, but obviously the socket part doesn't work. [runtime -> upd -> tcpip] session opened for 'subinit -> tcpip' at '/' [runtime -> upd -> subinit -> fetchurl] fetch https://... [runtime -> upd -> subinit -> fetchurl] Error: failed to open new socket at /tcpip/socket/udp/new_socket [runtime -> upd -> subinit -> fetchurl] Error: Couldn't resolve host name, failed to fetch https://... Any ideas what the problem with said RM-session could be? Bests Stefan -- Freundliche Grüsse Stefan Thöni Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

Re: Linker Issues in base-hw for an Armv8 Implementation
by Bob Stewart 19 Jul '18

19 Jul '18

Looks like my reply from yesterday got held up for being too long. Shorter version:- There is actually no error message indication why the linker failed. Assuming that it was because --build-id was expected later in the linker operations, I added the linker option -Wl, --build-id=none to the final image linker command in build_core. That resulted in the linker completing successfully and sensible image sizes being created as shown in the objdump output: objdump-p ../build/dragonboard/var/run/log.bootstrap|more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Program Header: LOAD off 0x0000000000001000 vaddr0x0000000081000000 paddr0x0000000081000000 align 2**12 filesz0x000000000003b840 memsz0x000000000003b840 flags r-x LOAD off 0x000000000003d000 vaddr0x000000008103c000 paddr0x000000008103c000 align 2**12 filesz0x00000000000041fc memsz0x000000000000d109 flags rw- LOAD off 0x00000000000411fc vaddr0x0000000000000000 paddr0x0000000000000000 align 2**12 filesz0x0000000000000000 memsz0x0000000000000000 flags r-- The executable image produced, image.elflooks okwith a quick scan using readelf. Sebastian, do you have any thoughts on why the linker gets upset with when the .note.gnu.build <http://note.gnu.build>-idsection is not discarded? Thanks, Bob Get Outlook for Android <https://aka.ms/ghei36> ------------------------------------------------------------------------ *From:* Bob Stewart <robjsstewart(a)gmail.com> *Sent:* Wednesday, July 18, 2018 1:55:02 PM *To:* users(a)lists.genode.org *Subject:* Re: Linker Issues in base-hw for an Armv8 Implementation There is actually no error message indication why the linker failed. Assuming that it was because --build-id was expected later in the linker operations, I added the linker option -Wl, --build-id=none to the final image linker command in build_core. That resulted in the linker completing successfully and sensible image sizes being created as shown in the objdump output: objdump -p ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Program Header: LOAD off 0x0000000000001000 vaddr 0x0000000081000000 paddr 0x0000000081000000 align 2**12 filesz 0x000000000003b840 memsz 0x000000000003b840 flags r-x LOAD off 0x000000000003d000 vaddr 0x000000008103c000 paddr 0x000000008103c000 align 2**12 filesz 0x00000000000041fc memsz 0x000000000000d109 flags rw- LOAD off 0x00000000000411fc vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x0000000000000000 memsz 0x0000000000000000 flags r-- objdump -h ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Sections: Idx Name Size VMA LMA File off Algn 0 .text 0003b840 0000000081000000 0000000081000000 00001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000718 000000008103c000 000000008103c000 0003d000 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .got 000000e0 000000008103c718 000000008103c718 0003d718 2**3 CONTENTS, ALLOC, LOAD, DATA 3 .got.plt 00000018 000000008103c7f8 000000008103c7f8 0003d7f8 2**3 CONTENTS, ALLOC, LOAD, DATA 4 .eh_frame 00003084 000000008103c810 000000008103c810 0003d810 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gcc_except_table 00000968 000000008103f894 000000008103f894 00040894 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 00008f09 0000000081040200 0000000081040200 000411fc 2**3 ALLOC The executable image produced, image.elf looks ok with a quick scan using readelf. Sebastian, do you have any thoughts on why the linker gets upset with when the .note.gnu.build-id section is not discarded? Thanks, Bob

1 0

Linker Issues in base-hw for an Armv8 Implementation
by Bob Stewart 18 Jul '18

18 Jul '18

Hi, I realize my issues are far from the current mostly-Sculpt roadmap, but perhaps someone can throw some light on my problems...at least I'm dealing with current hardware devoid of parallel ports :o I've been carefully creating a build structure in base-hw that will support armv8 and at least AArch64 over the past several months. I'm at the point where I have made all the architectural additions to support armv8 and the arm64 assembler which includes support for the assembler instruction changes from armv7, execution modes, and exception levels (only EL0 and EL1, initially). Everything builds for a cortex A-53 platform but fails in the final linking steps in two ways as described below. But first, my build tools are a copy of the Linaro toolchain, version 6.4.1, which used binutils 2.27, and my CROSS_DEV_PREFIX points to its location. I'm building in Genode 18.02 1. The final linking step fails initially with the "_impure_ptr" global not being resolved (see the build output in build_impure.log). Typically this global is supplied via libc, but Genode's special libc does not contain it. This global is a pointer to a structure that contains "errno" from failed C-code execution, along with some concurrency data for threading, if remember correctly. The pointer is only used in vterminate.cc which comes from the toolchain. In the currently used Genode toolchain the library supc++.o contains vterminate.o which is stripped, so the linker would not complain about the pointer. Is this by design because the process is about to die anyway when vterminate is called? To temporarily work around this problem I created a dummy void * _impure_ptr global in base/lib/cxx/misc.cc. The linker now continues and eventually completes. 2. The second problem is the size of the executable image files that the linker produces, several gigabytes! The actual memory image of the executable appears correct based on a dump of the section header but the header information shows that the File Offsets to the sections appears to be based off the link address. For example, in the creation of the boot image, build_core creates the binary log.bootstrap, the dump of which is: objdump -h ../build/dragonboard/var/run/log.bootstrap |more ../build/dragonboard/var/run/log.bootstrap: file format elf64-little Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 0000000000000000 0000000000000000 81042000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0003b840 0000000081000000 0000000081000000 81001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .data 00000718 000000008103c000 000000008103c000 8103d000 2**3 CONTENTS, ALLOC, LOAD, DATA 3 .got 000000e0 000000008103c718 000000008103c718 8103d718 2**3 CONTENTS, ALLOC, LOAD, DATA 4 .got.plt 00000018 000000008103c7f8 000000008103c7f8 8103d7f8 2**3 CONTENTS, ALLOC, LOAD, DATA 5 .eh_frame 00003084 000000008103c810 000000008103c810 8103d810 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gcc_except_table 00000968 000000008103f894 000000008103f894 81040894 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .bss 00008f09 0000000081040200 0000000081040200 810411fc 2**3 ALLOC It would appear that all the "File off" values are the expected value plus the bootstrap_link_address which is 0x81000000. Additionally, there is no stack unwind sections present, that is .ARM.exid/extab. The linker script being used is base/src/ld/genode.ld, as it should be. I don't have sufficient knowledge about linker functioning to begin to understand how the File offset values are determined or how the c++ stack unwind section is added, or not. Any suggestions would be very helpful. Thanks, Bob Stewart

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users July 2018