users June 2018

users@lists.genode.org

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

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

Checkpoint/restore of four specific capabilities
by Joos, Lukas 05 Jul '18

05 Jul '18

Dear Genode community, I am currently trying to extend a checkpoint/restore mechanism based on Fiasco.OC and Genode 16.08 that has been discussed on this mailinglist before. [1] [2] During my analysis of the existing code I was able to identify four capabilities that do not show up in the child's capability space after a restore: CAP1: Fiasco.OC GATE representing Genode::Rpc_entrypoint::_exit_cap CAP2: Fiasco.OC GATE representing Genode::Entrypoint::_signal_proxy_cap CAP3: Fiasco.OC IRQ representing Genode::Signal_source_rpc_object::_blocking_semaphore (Fiasco.OC specific) CAP4: Fiasco.OC GATE representing "Capability<Constructor> constructor_cap" local to the Genode::Entrypoint::Entrypoint(Env &env) constructor scope Based on my current understanding I'd say that CAP4 is not needed after a component has been constructed. CAP1 may be needed when a component is destroyed and CAP2 and CAP3 are needed for the signalling subsystem to work correctly. Regarding the Fiasco.OC specific CAP3 there is also the problem that it has to be attached to the "signal handler" thread with a system call (l4_irq_attach). The current idea (which has also been discussed previously [3]) is to delegate the thread and IRQ capabilities to core, which then invokes the syscall with the translated kcap values. My questions are: 1) Which of those four capabilities actually need to be present in a restored child? 2) Do they have to be in the capability map? 3) Do they have to be in the capability space? 4) Does the memory where the Genode::Capability<RPC_INTERFACE> is stored inside the child component have to be altered after the restore? If you have any ideas on how to restore one or more of those capabilities I'd love to hear all about it. Thank you for your time. Sincerely, Lukas Joos [1] https://lists.genode.org/pipermail/users/2016-August/004703.html or https://sourceforge.net/p/genode/mailman/message/35322604/ [2] https://lists.genode.org/pipermail/users/2016-December/004863.html or https://sourceforge.net/p/genode/mailman/message/35529306/ [3] https://lists.genode.org/pipermail/users/2017-November/005611.html

1 1

Need help understanding packaging
by Guido Witmond 04 Jul '18

04 Jul '18

Hi Genodians, I've got this little project for a web service[1]. It works as a run-script and even boots as disk image on my intel box. *) It's fast. It serves a file at 40MBytes/second and only 5 ms latency between connecting to it and the first bytes on a Gbps LAN. Although that file was served from memory, half the speed of the LAN without any tuning is promising! But I get stuck with making it into a depot-package. I lack the clarity of what the next steps are. My subgoals: 1. make it a depot-package; 2. make it configurable by user; 3. replace ragel parser[2] with hammer library[3] as a dependency. How could I proceed with these steps? Is there an example run-script to package conversion I could follow? Cheers, Guido. 1: github.com/gwitmond/feather 2: https://www.colm.net/open-source/ragel/ 3a: https://github.com/UpstandingHackers/hammer 3b: http://www.langsec.org/ *) Sculpt runs fine on AMD's Ryzen too, except for SATA, virtualisation.

2 7

How to add missing symbols to stdcxx?
by Mark Albers 28 Jun '18

28 Jun '18

Hi, after switching from Genode 17.11 to 18.05, I just noticed that some symbols I need to link to in my implementation are missing in libports/lib/symbols/stdcxx. I temporarily added them manually and want to ask about the envisaged way of adding them. Thanks in advance! Regards Mark

1 0

depot question: clarification about hashes
by Johannes Schlatow 28 Jun '18

28 Jun '18

Dear Genodeians, I started working with the depot tools in order to create and deploy my own archives. Unfortunately, I'm a bit puzzled about the hashing/versioning. Let me clarify my confusion on a minimal example: $> git clone https://github.com/genodelabs/genode.git $> cd genode $> ./tool/depot/extract local/api/base Error: /home/johanness/repos/genode/repos/base/recipes/api/base/hash is out of date This error indicates that the archived source code has changed, which should be reflected by incrementing the archive version and updating the hash of the recipe. You may update the recipe hash via the following command: echo 2018-06-25 1cece72259a129c0906c20d32da078ee0638e545 > /home/johanness/repos/genode/repos/base/recipes/api/base/hash [...] The latest commit on the current master branch updated the recipe hashes, which is why I assumed the extract tool should calculate the same hashes but it doesn't. Next, I executed the same command with `VERBOSE=` to get the command that calculates the hash. I tried to run the command manually as follows: $> cd depot/local/api/base/incomplete $> find . -type f | sort | xargs -d '\n' cat | sha1sum | sed "s/ .*// 731162f0b76bebabc0741366600973b9bbe23651 As you can see, I get a different hash as the extract tool suggested before. Both hashes are different from the recipe hash, by the way. I might be lacking some sleep today and am probably misconceiving the process. Anyway, I'd appreciate if anyone could help and clarify this point. PS: I came across this issue when I tried to create my first recipe. As this uses the base API, it complained that the hash is out of date. This seems counterintuitive as the base API should be pretty stable and deploying my own archives should not require me to provide my own base API as well. Please correct me if I'm wrong. Cheers Johannes

2 2

minimizing physical memory budget
by Steven Harp 28 Jun '18

28 Jun '18

What are the main factors in estimating the minimum RAM quantum needed by a component? (Excluding for this discussion any dynamic allocation an application might perform.) The Genode Foundations book (18.05) suggests that if no quantum is specified, "init has a reasonable default of 160K (on 32 bit)". Experimentally, it seems like even the most modest components need more. For example the client side of the hello_tutorial, essentially 5 source lines and a 20K stripped ELF binary, seems to need about 500K on a 32-bit x86 system. At quantum="480K" for hello_client, one sees: Warning: PD (init -> hello_client) RAM limit (used=380K, limit=394587) exceeded during transfer_quota(6K) (and the test hangs.) At 425K, the result is: [init] child "hello_client" requests resources: ram_quota=69632 page fault, pd='init -> hello_client' thread='hello_client' cpu=0 ip=0xa2adc address=0xa00fde50 stack pointer=0x0 qualifiers=0x6 irUWp reason=1 At 300K, we see: [init] Error: allocation of read-write segment failed [init] Error: hello_client: out of RAM during ELF loading Is there a way to tweak component compilation/linking parameters to minimize physical RAM required? // Steve Harp

2 1

Fwd: problem with routing of reports/ROMs inside runtime
by Pirmin Duss 28 Jun '18

28 Jun '18

Hello Norman On 27.06.2018 15:15, Norman Feske wrote: > just as a shot in the dark, could it possibly be that the > "layout_controller" closes the report session right after submitting the > report, e.g., by using a 'Reporter' as a local variable that is > destructed when leaving its scope? Yes, this is the problem. It uses an Expanding_reporter inside the method that creates the configuration. Many thanks, Pirmin

1 0

problem with routing of reports/ROMs inside runtime
by Pirmin Duss 27 Jun '18

27 Jun '18

Hello list While testing the configuration update for the floating_window_layouter I encountered a problem. Inside the signal handler for the config update the configuration is always "<empty/>". In the log I see that layout_controller writes the report "layout_controller -> layouter_config" and that the layouter receives a signal. But after a config.update() the content of config.xml() is always empty. <config> ... <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> ... <start name="report_rom"> <resource name="RAM" quantum="4M"/> <provides> <service name="Report"/> <service name="ROM"/> </provides> <config verbose="yes"> <policy label="layouter -> window_list" report="wm -> window_list"/> <policy label="layouter -> focus_request" report="wm -> focus_request"/> ... <policy label="layouter -> config" report="layout_controller -> layouter_config"/> </config> </start> ... <start name="layout_controller"> <resource name="RAM" quantum="4M"/> <route> <service name="Report" label="layouter_config"> <child name="report_rom"/> </service> <any-service> <parent/> <any-child/> </any-service> </route> </start> ... <start name="layouter"> <binary name="floating_window_layouter"/> <resource name="RAM" quantum="4M"/> <route> <service name="ROM" label="config"> <child name="report_rom"/> </service> <service name="ROM" label="decorator_margins"> <child name="report_rom"/> </service> <service name="ROM" label="focus_request"> <child name="report_rom"/> </service> <service name="ROM" label="hover"> <child name="report_rom"/> </service> <service name="ROM" label="window_list"> <child name="report_rom"/> </service> <service name="Report"> <child name="report_rom"/> </service> <any-service> <child name="wm"/> <parent/> <any-child/> </any-service> </route> </start> ... </config> I also have tried to change the route and the policy as follows: <service name="ROM" label="config"> <child name="report_rom" label="layouter_config"/> </service> <policy label="layouter -> layouter_config" report="layout_controller -> layouter_config"/> But this also didn't help. LOG: [runtime -> wm -> layouter] config at startup: <empty/> [runtime -> wm -> report_rom] report 'layout_controller -> layouter_config' [runtime -> wm -> report_rom] <config> [runtime -> wm -> report_rom] ... [runtime -> wm -> report_rom] </config> [runtime -> wm -> layouter] config update signal [runtime -> wm -> layouter] new config: <empty/> Does anybody see the error, that my colleague an I weren't able to find? Best regards Pirmin

2 1

Doubts regarding IRQ capabilities in L4 fiasco and genode
by Harsha Sharma 27 Jun '18

27 Jun '18

Dear Genode Community, I have some doubts regarding handling IRQ capabilities in L4 fiasco microkernel and Genode. L4 kernel maps IRQs to IRQ kernel objects which are created using l4_factory_create_irq using factory object. In genode, we attach IRQ capabilites to entrypoint thread with l4_irq_attach in core component. Also, signal handler session returns signal context capabilities from core component and l4_irq_attach is also called in signal_source_client. What is the difference between signal context capabilities and IRQ capabilities? (Or IRQ capabilities are kernel space capabilities and signal context capabilities are genode cap map capabilities) Is it possible to attach entrypoint thread to IRQ object capability outside of core component ? Actually, I'm working on checkpoint/restore project in genode and L4 fiasco. And comparing the kernel cap space before checkpoint and restoring state, we find out that IRQ kernel object capabilities are not same. Signal context capabilities are checkpointed and restored correctly, but problem is (most probably), that while restoring, we don't attach it to entrypoint thread. One approach is to intercept, IRQ session and then attaching irq capability to entrypoint thread capability in restoring process. Please correct me if I am wrong somewhere and any suggestions on above approach will be really appreciated. Thanks a lot. Regards, Harsha Sharma [1]. https://sourceforge.net/p/genode/mailman/genode-main/thread/f64ed643-33a3-d…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users June 2018