Re: ext4.h not found
Hi Rumen, > I want to test out lwext4, however when I try to compile it, I get an error > that ext4.h was not found. I have attached my main.cc, target.mk and > squid.run files below. The platform I am using is x86_64 linux. If anyone > knows has any idea how to link the lwext4 library please let me know, as I > could not find much information online. > […] > TARGET = squid > SRC_CC = main.cc > LIBS = posix vfs_lwext4 you have to use the 'lwext4' library rather than 'vfs_lwext4', which itself is a user of the library and a VFS plugin dynamically loaded at run-time. The plugin may illustrate how to interact with the library, you have to provide your own block backend though. That being said, if you only want to access an Ext4 file-system from your component adapting the configuration to use of the existing VFS lwext4 plugin is easier. The run-script you have shown is actually configured in this way and the VFS fs plugin (instantiated via the '' node) should already allow for accssing the file-system via the pre configured 'vfs' server utilizing the VFS lwext4 plugin. Your squid component, one the other hand, has to be adapted. I noticed that you reference the 'posix' library in your target.mk. This, however, implies using a component making use of the 'libc' and requiring the common 'main()' function as entry-point for the component. So, depending on what you want to achieve, building a POSIX component entails solely linking against 'posix' and 'libc' and only utilize the POSIX API. If you want to go down the road of building a native Genode component I suggest to take a look at the 'fs_tool' (repos/gems/src/app/fs_tool) component that excercises Genode's native API and also makes use of the VFS still allowing for using 'vfs_lwext4'. Of course you are still free to use 'lwext4' directly but that is more involved and subtly advised against that. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/ZTJYJBHHVCGLXLM6MCTHUWRH2JNOYKJI/
Re: Logging Based File System Support in Genode
Hi Rumen, > > Does anyone know of any projects / plugins that support a logging file > > system (e.g. ext3/4) in Genode? > > There is lwext4_fs in the genode-world repository. I never used it, > therefore I can't tell you about state it is in. There is indeed a port of the 'lwext4' [1] library for Genode and by now a VFS plugin that utilizes the library. However, I recently moved it from genode-world to my personal Genode “playground” [2]. [1] https://github.com/gkostka/lwext4 [2] https://codeberg.org/jws/genode-wundertuete/src/branch/sculpt-24.04-2024-04-19 I use it on a daily basis (it is integrated in my personal Sculpt branch [3]) and at least in my limited usage it works well enough. There are known limitations in the library (some features of Ext4 that are enabled by default by now are not supported so you have to prepare the FS in a certain way and sparse files are not supported) and the plugin itself is quite plain. [3] https://github.com/cnuke/genode/commits/sculpt-24.04-2024-04-26/ So, since you aim for a “logging file system”, I assume your use-case might require specific properties and given its current state, the 'vfs_lwext4' plugin probably does not fit the bill. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/QTVAJ5H5F7GATLOJEPBK5NDGF3DVL5OT/
Re: Leitzentrale only displays NVME1
Hallo Jack, > Hello, I have 4 NVME SSD's in my laptop. However, the Leitzentrale > only allows shows me the NVME1 slot, but it will not display NVME2, > NVME3 or NVME4 to select. I wanted to use a SSD that was in the 4 > slot, so I physically had to swap the SSD in slot 4 with slot 1 with > so I could select the desired SSD for sculptOS to format and use on > the NVME1 slot. > > I am not sure if this is just a GUI bug, or if the other 3 NVME SSD's > are simply not being detected by the OS? Sculpt is configured in way that it only manages the first NVMe device it finds and thus is limited to making use of this particular device for the GENODE partition. So physically swapping devices, when possible, is the most straight-forward solution at the moment. That being said, you can modify Sculpt so that it will select a different NVMe device and additionally also allow for using the other NVMe devices for data storage. However, that involves building your own Sculpt image for now - but if you are willing to do that, I can give you a description of the necessary modifications. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/7BDSK4SIXFWJFMBWA5KTWROKE2BHZIR7/
Re: Using second block device
Hi, > […] > > I was quite happy to find that this is possible out of the box. I'd > suggest elaborating on "inspection" in the documentation as this may be > confusing for new users! I am glad you could help yourself but I am afraid you merely found the pragmatic workaround for utilizing multiple block devices as that use-case is not yet properly addressed with the current Sculpt. Since this not “officially” supported and diverting the inspection functionality is a happy little accident we refrain from documenting this behaviour. That being said, you can make it work by managing the NVMe device manually. That involves starting an appropriately configured 'part_block' as well as an 'ext2_fs' instance. You can use the pkgs published in my depot (see 'cnuke → Tools (Extra)) as they are not available in the genodelabs depot. The following examplary launcher reference those pkgs since configuring the block session, i.e. setting the label for the partition, is not possible via the GUI: # nvme-part_block # nvme-part_2_fs You can store the launcher on your USB stick (config/24.04/launcher) and start them manually or add them to your persistent deply config (so that they get started when you 'Use' the USB stick). Afterwards you just point the other components to 'nvme-part_2_fs'. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/UWFO2P52PIWDLYPZU5HQQYQJQN6XSZG7/
Re: Edit ram allocation to processes in Sculpt OS?
Hello Jack, > Hello, I've started using Sculpt OS and the integrated Falkon web > browser. It frequently crashes when I have several tabs open, I > believe this is because the ram it has been assigned is too small. I > couldn't seem to find any mention of how to edit the ram allocated to > processes in the Sculpt OS documentation? > > How do I dynamically edit the allocated ram to processes such as the > Falkon web browser? When I am using the Leitzentrale and I click on > the Falkon web browser, I can see it shows 1.95 GiB / 2.00 GiB, I am > guessing this is the allocated ram? However I am only assuming this is > the allocated Ram size as it does not specify what type of storage > this is, i.e Hard Drive Storage or Ram Memory. At the moment there is no out-of-the-box user-interface to change the RAM or CAP quota for deployed components and changing them currently involves some fiddling as you need to adjust the resource allowances manually. In this case it is especially involved as the 'falkon-jemalloc' pkg bundles mulitple components running in an statically configured sub-init. That being said, generally speaking, you can change the quota by adding a 'ram' and 'caps' attribute to either a '' or '' node and increase the value. That is one of the reasons where creating a launcher comes in handy as sometimes the pre-configured resource requirements might not be enough in all cases and one needs to override them. As you noticed that is true in particular when using the falkon pkg as its resource consumption is quite volatile depending on the website and number of tabs. Of course Genode itself contains all the means for reacting to such resource requests dynamically (and this already employed for certain components, like the 'depot_rom' or 'ram_fs') but is not enabled in general to prevent components from tipping on each others toes. How to better make use of available slack-resources is still ongoing research. > […] > > I will need to do more tests to see if the audio not working was a > fluke or I was doing something incorrectly before. On most systems the current audio driver can only be started once as the device might not produce sounds when the driver was restarted. Depending on the system you might get away by starting it several times until it is audible again but that is not always a given. Unfortunately switching presets might implicitly start and stop the driver and is best avoided (after the initial exploration or try-out phase of course) and for regular usage of Sculpt I would recommend making a preset persistent (as discussed in the documentation) and to mainly work with launchers. We will work on remedy this limitation but there is not time-frame for that yet. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/VOIT6EGMUNFDPUZRBTAFKV2TTGH4VCDG/
Re: Sculpt 24.04 Release Candidate
Hello John, > The only thing that didn't work for me (as Pirmin Duss already mentioned) > was that I didn't get any audio output for the web browser, although I did > hear a popping noise when enabling the Audio component, so something is > working there. (I haven't tried any other audio playback yet.) Like Pirmin, you could look at the audio driver's 'mixer_state' report, the actual mixer's report '/report/runtime/mixer/state' and look for any mentioning of 'azalia0: codecs: …' in the Sculpt LOG. Note that restarting the driver might render it unusable (e.g., you will not hear anything) until you reset your system. I also published a current version of my 'cmus' pkg for 24.04 that you could use for testing and there is also Alexander's 'firefox@seoul' pkg that features audio support as well. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/S4MDWBRHFQJQ4GU2AKANIUWM2XSAPRCS/
Re: Sculpt 24.04 alpha testing
Hello Pirmin, > Unfortunately I do not get any output on the headphones. > > I never had tested audio on this device with previous releases. You can enable reporting in the audio launcher by setting the 'report_mixer' attribute (the launcher currently contains the wrong attribute) and watch the '/report/runtime/audio/mixer_state' report while (un-)plugging your headphones. We already had to add quirks for other systems in the past to the driver where it did not identify the widgets properly. That could be the case here as well. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-le...@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/AZC7ENGQCE3AJSNBD2N7GFGXOONED5DA/
Re: Roadmap 2024
Hi, Reflections of 2023 I spent the year mostly around the usual topics of driver development and maintenance, mainly on the PinePhone and DDE Linux in general. Bringing the Linephone client and a GUI to the PinePhone together with Sebastian was a nice intermission in the last quarter of the year. Apart from that my personal projects did not far as well as most of them, namely the amdgpu_fb_drv, stalled by the mid of the year as I got occupied with other non-computer related things and the one or other one-shot was merely a gimmick. Plans for 2024 To be honest I do not have any elaborate plans for the year but there certainly will be one or the other topic I will work on in a supporting role. Best regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: PinePhone Sculpt SD Card Problem
Hi John, > Sorry for the delay in trying this image, but it worked for me! My > "Patriot" 16GB card that previously caused trouble now works fine. No problem; thanks for testing the image and the confirmation we have to play ball with some SD cards. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > I think I understand the logic of this commit, and in general it seems to > me a better way of handling the scheduling. I used cherry-pick to add it to > my branch [1], and it seemed to work the same as before. That said, I am > unable to trigger the signal handler issue with my hardware, even using > 'sudo ping -f'. Thanks for testing, so I'll keep an eye out on my side. > Ok, I think there won't need to be many changes to the wireless stack, but > the USB emulation code needs to be somewhere. So I suppose I should add a > lx_emul_usb.c to the dde_linux/lib/wifi directory, and besides that it will > require the code from wlan_usb.cc and wlan_usb.h to be copied somewhere. As > a most convenient option that can be in the same directory. Alternatively > such code could live somewhere in lx_kit/lx_emul independent of wifi, if > someone wanted to use it for porting another type of USB device driver, but > for now that might be too optimistic. Putting the code into either 'src/lib/wifi' or perhaps 'src/lib/usb_wifi' in the dde_linux repository is fine. It has to be picked-up explicitly by the component/library that wants to use it anyway and is of no concern to the other drivers. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > > D-Link dongle (running via USB passthrough in QEMU and flood pinging it > > from the out-site). I encountered the I/O signal handling issue once > > but since its a known problem I mostly ignored that for now. > > > > I had chased that away in "normal" use, but I'm not surprised you could > trigger it with a ping flood. We looked at the problem and could you give this commit [1] a try (it is still WIP and not finalized). It might be helpful to add a diagnostic message to 'alloc' in 'usb/packet_handler.h' to see when the situation occurs. [1] https://github.com/cnuke/genode/commit/8b4896e7 > I switched to those branches, it works for both my dongles (I suppose the > correct branch name is cnuke/ath9k_driver_support-2023-06-11 for > genode-world). Thanks for testing; I planned on renaming the branch but that evidently slipped my mind. > If I understand it right, the remaining suggestions are to switch to > virt_linux and to re-implement USB with the "Connection" object. For the > former I may take a look at it this weekend if I have time. I may also try > to build a Sculpt configuration around usb_report_filter and supporting > both dongles with the same configuration. Yes. At the moment you are working with a copy of the wireless stack, which is fine but makes the maintenance more involved. With the MNT Reform2, PC and PinePhone driver we now reference the common parts of the stack and each driver merely contains its specific portions (basically the dummies and required source files that among others result from the different Linux kernel configurations used for each platform). From my point of view 'virt_linux' is the natural platform for USB device drivers as they are somewhat platform agnostic and do not require the use of the Platform session. So it makes sense to base your wifi driver off of it and access the wireless stack like the other drivers do. Since 'virt_linux' has not been used for device drivers so far there is going to be some friction but probably nothing you cannot handle. So one way of going forward could be: 1. Adapt your current version (that is based on the PC platform) by using the PC wifi driver as a template to the way the other drivers are by now implemented. That could involve making additions to the wireless stack but that's fine as merging your changes eventually would be the preferred way. 2. Switch the used platform by going from 'pc_lx_emul' to using 'virt_lx_emul'. That will involve extending 'virt_linux'. 3. Re-implement the USB wrapper using the session directly. > Regarding the latter there is supposed to be a change to Genode's USB > structures pending so maybe I'll just wait to see what happens with > that? We plan on changing the USB session and the API you are currently using but I don't know the time-frame. That would affect 3. but I hope with the scheduler execution change in place the current USB wrapper will work better for the time being and the focus could be on 1. and 2. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > > Did you try with a recent branch? I've been having success with > > rt2x00 and ath9k both lately. > > No, I have not found the time yet but there should be some time this > weekend. I am happy to confirm that your driver also works with my Ralink-based D-Link dongle (running via USB passthrough in QEMU and flood pinging it from the out-site). I encountered the I/O signal handling issue once but since its a known problem I mostly ignored that for now. > > Ok. It may not be so completely simple. Likely there would need to be at > > least small changes to wifi_drv, for example compare "frontend.h" between > > the two, you will see some additional features like _remove_all_aps(), and > > IFACE-DEINIT had to be added to support hot-plug. > > Uh sorry, I missed those changes - naturally these should be included as > well. I added the missing feature to the generic driver binary and changed the 'wifi_ath9k.run' run-script to use that instead of the specific one. (I pushed the corresponding branches called 'usb_wifi-2023-06-11' for the genode and genode-world repo.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > Did you try with a recent branch? I've been having success with rt2x00 and > ath9k both lately. No, I have not found the time yet but there should be some time this weekend. > > That being said, yesterday I rebased [1] your changes to add hot-plugging > > support to the 'wpa_supplicant' (they compile but I did not test whether > > they work or not) to the staging branch containg the wifi stack changes > > for the upcoming release. > > I was able to get this to work with my "world" version [1]. You can see the > small changes I needed to make to the main repo in [2]. Commit 7f5c967 > fixes a small issue that wasn't revealed earlier where > wpa_supplicant_ctrl_iface_deinit is called with a null pointer for the > second argument. Commit 0b24c1c adds some switches to the linux compile > without which the usb version of rt2x00 won't build, and 76c138d adds > usb_report_filter to the config scenario and is not strictly necessary > unless you want to switch between two types of devices (ath9k and rt2x00) > on-the-fly. Thanks, I'll take a look. > > Maybe you want to give that a try? > > > > Ok. It may not be so completely simple. Likely there would need to be at > least small changes to wifi_drv, for example compare "frontend.h" between > the two, you will see some additional features like _remove_all_aps(), and > IFACE-DEINIT had to be added to support hot-plug. Uh sorry, I missed those changes - naturally these should be included as well. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: PinePhone Sculpt SD Card Problem (was: Re: Announcement: Sculpt OS 23.04 released)
Hi Cedric, thanks for testing with the debug image. > No change for me -- boot-up takes a couple additional seconds > (probably debugging/tracing enabled?) and the battery indicator says > "AC" for a few seconds before displaying the percentage. Yes, the image is build with serial logging enabled (if you attach the earphone jack serial cable to your PinePhone you will see all LOG messages). > I then proceeded to the setup steps, > - Expand... Confirm... still returns immediately > - Tapping "default" results in message "relabelling in progress" > displayed for about a third of a second, i.e. it returns immediately > too. > > FWIW, I have a bunch of SD cards/packages associated with this phone, > EMTEC, Verbatim, etc. It seems the one I'm dd'ing the SculptOS image > to is a 16 GB "Verbatim premium 80MB/s-read 533x (cl.1)" or some such. Unfortunately I have no follow-up advice for now - but to make sure, former versions of Sculpt on PinePhone did not exhibit these issues (perhaps with the same SD card)? (I normally use “SanDisk Ultra” cards, which did work fine so far.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: PinePhone Sculpt SD Card Problem (was: Re: Announcement: Sculpt OS 23.04 released)
Hi, * John J. Karcher [2023-06-08 01:32:14 -0400]: > On 6/7/23 12:26, ttco...@netcourrier.com wrote: > > […] > > - when invoking Expand... Confirm... it does not work for 20 seconds > > at all, in fact it returns immediately. > > - and the file system size label still says "15 MB", instead of > > indicating that the FS has been expanded to the full SD-card size > > (15 GB) > > - hence even after clicking "Default" (which didn't work, had to > > click "Use" instead) and... > > - ...activating Wi-fi and getting an IP address, any network > > download still remains stuck at "expanding" or even "fetching". > > This probably all goes back to the FS not (?) being expanded I guess. > > […] > > I had a similar, but not identical, situation on my 3GB version. In my > case, anything involving writing (expand, default, etc.) would never > complete, but slow the system to a crawl in the process. > > […] could you both please try out my debug image [1]. We already got a similar report from someone on the PinePhone forum [2] where changing the MMC clocking back to previous setting did the trick. [1] https://genode.org/files/sculpt-pinephone-23.04-2023-05-09.img.xz [2] https://forum.pine64.org/showthread.php?tid=14780&pid=117253#pid117253 Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > Thanks for your continous effort, I'll give your branches a try. as you may have noticed, besides briefly looking into your branches and pushing simple changes to make it easier to test the driver in Qemu I unfortunately did not find the time to dig deeper why it apparently was not working properly for me. That being said, yesterday I rebased [1] your changes to add hot-plugging support to the 'wpa_supplicant' (they compile but I did not test whether they work or not) to the staging branch containg the wifi stack changes for the upcoming release. I also sketched using the 'virt_linux' Linux target as basis for a USB wifi driver - it will not link as 'virt_linux' is not yet properly prepared for that scenario - as I believe that is beneficial for an USB driver where DMA memory (and to that extend the usage of the Platform service) is not necessary. My (somewhat uninformed) guess is that it could be as simple as using your 'lx_emul_usb.c' back end instead of, for example, 'lx_emul_pci.c' (omitting the gory details/obstacles lurking in the dark…). Maybe you want to give that a try? [1] https://github.com/cnuke/genode/commits/usb_wifi-2023-05-24 Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Fetches failing for latest img Sculpt PP
Hi, > P.S. 5GHz band is not available in options. AFAIK the RTL8723CS WLAN/BT chip used in the PinePhone does not support 5GHz, so its only possible to join networks operating in the 2.4GHz range. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin, > […] > > Josef I am curious if this version will also work for you? > > [1] > https://github.com/cvparker/genode-world/tree/ath9k_driver_support-2023-01-22 > [2] https://github.com/cvparker/genode/tree/ath9k_driver_support-2023-01-22 Thanks for your continous effort, I'll give your branches a try. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: PinePhone image 2023-04-06 (wifi, software-add tab, Jitsi preset)
Hi Cedric, thanks for testing the current image! > Having trouble with WiFi -- > Installed from scratch on a new micro-SD card ; booted, did "FS: make > default + expand" (or maybe the reverse) ; activated WiFi and typed my > password. The PinePhone then appears on the "active devices" web > interface of my router. Trouble is, all buttons are still disabled in > the Software pane, except the "Runtime" one which does open up when I > click it. Tried to reboot and re-connect to WiFi, no change... Do you see a valid IP(v4) address in the 'Wifi' dialog after you joined your WiFi network successfully? Did you also 'Use' the GENODE Partition on the SD card in the storage dialog? (Otherwise the tabs in the Software section apart from 'Runtime' will be disabled.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver (missing URLs)
> I stumpled across those issues as well ([1], [2]), sorry for not bringing > […] [1] https://github.com/cnuke/genode-world/commits/ath9k_driver_support-2023-03-15 [2] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-03-15 -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hi Colin,
> >> out why. For that I will take a closer look at your USB back-end work
> >> and its integration into the kernel.
> >>
> >
> I have done some investigation into this (see [1]), there is a simple issue
> and a harder issue.
> The simple issue is that for ath9k all control transfers were outgoing, so
> I simply neglected to support incoming control transfers. That was easily
> fixed, but exposed the other issue.
> The harder issue is that Usb::Packet_handler::submit can block, allowing IO
> (including timer) signals to be handled. Timer signals in turn can use
> Lx_kit::Scheduler::schedule to try to run the kernel. Hence, it is a risk
> to submit any USB transaction from the kernel emulation stack, since this
> will be a re-entrant call to schedule if it does block and a timer fires.
> For whatever reason this never happened with ath9k, but seems to happen
> with rt2800usb.
> […]
I stumpled across those issues as well ([1], [2]), sorry for not bringing
those to your immediate attention - I hope you did not spend too much time
chasing them down.
To be honest this USB API ('usb/usb.h') should not be used anymore,
especially as it contains such stumpling blocks under the hood. You took
care to use it a non-blocking fashion but the preferred way is Using the
Usb session directly.
(I currently don't have the capacity to give you well-grounded help
regarding changing the flow of your LX USB connection which is why I
omitted that part of your post.)
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: Adding more binaries from coreutils
Hi, > Can explain in little detail, on how to create and use runtime package. > > Do I need to create a noux package? One first step could be copying the system-shell's 'pkg' and 'raw' recipes and to exchange each 'coreutils-minimal' occurrence with 'coreutils'. I carry around my own personal shell pkg [1] and if you compare both you will spot the differences that might help you to create your own customized version. [1] https://github.com/cnuke/genode/commit/6a46a2aea51278bae115 Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: iwlwifi-9260-firmware
Hi Alice, > > Ah right, I have not thought of that. Since most distros will also pull > > there firmware images from there (I think) it makes correlating things > > easier. > > Oh, sorry for the misunderstanding. I meant, it makes sense to use the one > from [1] :) > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git Yeah, that is what I meant as well - sorry for being somewhat fuzzy ☺. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: iwlwifi-9260-firmware
Hi Alice, > I wonder why the size differs. It is a good question. I would have expected > not. > > As far as I remember, I got it from the Intel website [1]. I am sure I did > not look > into 'linux-firmware.git' as you mentioned. I assume it should be picked up > from > there. I overlooked that, sorry. Ah right, I have not thought of that. Since most distros will also pull there firmware images from there (I think) it makes correlating things easier. > I have tested it with your Genode branch, and it works! Thanks for testing, that is good to know. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: iwlwifi-9260-firmware
Hi Alice, > After some investigations, only the intel 'iwlwifi-9260-firmware' > needs to be included for it to work. I forked 'dde_linux_firmware' [1] > and created a pull request [2] to add the firmware and the license. > Please let me know if this is appropriate. Thanks for creating the PR. I was wondering where you got the image file from as the size differs from the one found in the vanilla 'linux-firmware.git' [1] repository that I normally turn to. However, I added the image found there to the 'dde_linux_firmware' report and I prepared two fixup commits [2]. It would be nice if you could give this FW image a try as well. [1] git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git [2] https://github.com/cnuke/genode/commits/issue%23xxx-iwlwifi-9260-razor15-2023-03-13 > Finally, I have a branch that implements the necessary changes on > the genode repository [3]. It currently uses my fork of 'dde_linux_firmware' > in 'dde_linux/ports/linux-firmware.port'. Wifi now works on my laptop. > > If [2] is correct and accepted. I can adapt those changes if welcome to > create a pull request for the genode repository. I goes without saying that we gladly would incorporate the changes. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Enumerating partitions, then "Error: Aborting: no partition table found."
Hi, > Anyway, the hard drive. It's an actual, old-fashioned hard drive, and > I've accumulated 21 partitions on it. As a heads-up: for the moment we only make the first 9 partitions available. If you need to access a partition beyond that you need to apply something like [1] and rebuild Sculpt. [1] https://github.com/cnuke/genode/commit/08d34a4c9b32d116631b > […] > [core] [init -> runtime -> ahci-0.part_block] Partition 1: LBA 40 (119537688 > blocks) type: [...] > > Then, immediately after it's listed them all, giving values that look > correct... > > [core] [init -> runtime -> ahci-0.part_block] Error: Aborting: no partition > table found. > [core] [init -> runtime -> ahci-0.part_block] Error: Uncaught exception of > type 'Block::Main::No_partition_table' > [core] [init -> runtime -> ahci-0.part_block] Warning: abort called - thread: > ep > [core] [init -> log] Error: corrupted string > [core] [init -> leitzentrale -> manager] Error: ahci-0.part_block got stuck > […] You will get this error if 'part_block' could not make use of either the MBR or GPT. It parse the table and makes note of each valid partition it encounters [2], [3]. For whatever reasons none of them appears to be valid. [2] repos/os/src/server/part_block/mbr.h:273 [3] repos/os/src/server/part_block/gpt.h:431 - What kind of partition table type do you use? - In case of MBR do you only use extended partitions? If you like contact my off-list and provide the complete table (LBA, size and type is sufficient). Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: PinePhone image user experience
Hi, > I couldn’t get data to work because I didn’t see a way to give it the > correct APN. Setting the APN is not yet supported. > PS Do USB/ethernet/charging Just Work via the hub that comes with the > 3GB PinePhone (once one learns how Sculpt OS works, at any rate), or > would that require more drivers to be written? AFAIK the hub not been tested yet, I suppose charging could work. That being said we focused on getting the second EHCI controller where the modem is attached to to work first. At the very least integration work is needed to make use of the ethernet device in the hub if not changes to the USB driver. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Sculpt: use second SSD for a VM
Hello Pirmin, > I have a notebook with two SSDs, On which I have installed Sculpt. > > I want to use the whole second disk for one VM. > > VMs that use partitions from the first disk work well. > > In the launcher for the VM using the whole second Disk I configured block > access as follows: > > > Where ahci-2 is the name of the second disk displayed in the Sculpt > Leitzentrale. > > When I start this VM, it looks, as it would wait to get access to the Block > session (only two lines of output are printed). > > Is this setup possible or do I need to change it in some way? I would imagine that your setup should work. As a test you could deploy the 'part_block' pkg and point that to your second SSD. If it is able to parse the partition table that would suggest that something in your vbox setup is missing. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hello Colin, > Good to hear. Was this done with the changes I made to the supplicant > interface? I'm curious if those break the existing wifi functionality, > which I can't test other than to say it compiles successfully. No, in this case I simply enabled the driver in the vanilla 'pc_wifi_drv' driver component. > At some point I believe this was re-named by me to pc_lx_ath9k_extras. You > should find it in world/lib/mk and the import file in world/lib/import. The > only point as I remember is to add the necessary files from the linux > contrib dir. Since the ath9k driver sits in world, rather than in "pc", the > corresponding source.list and dep.list files are not imported automatically > by pc_linux API, hence the need for the pc_lx_ath9k_extras API for depot > builds, and the import-pc_lx_ath9k_extras file to correctly locate the > imported files. But, I am a genode build/depot build newbie, so perhaps I > made this too complicated? If you want to build in the "pc" repo itself I > suppose it isn't needed. Nevermind, I did not pay close attention and misread the 'LX_SOURCE_EXTRAS' usage. (For additional changes see the Ralink comment below.) > […] Admittedly I was also thinking of some unusual scenarios, such as > multiple wifi adapters where it makes sense to have one supplicant and > multiple drivers. But that's strange enough maybe it doesn't need to > be supported. At least from my perspective I would rather treat the supplicant as a “minor” detail of the driver itself. So each instance has its own supplicant and a management component could take care of the overall configuration on the system level for multiple wireless devices. > BTW, were you able to build the wifi_ath9k_drv component? I hope that I > have a version that is suitable for others to try. Well, if anyone has the > hardware, which maybe is not as common as I thought since i bought it a > while ago. After adapting your commit - my 'world' repo is symlinked rather cloned in place - I was able to build the driver. Due to the lack of HW I did not test it though. However, I enabled the RT2800USB driver [0], added a 'wifi_ath9k.run' run script based on 'pc/run/wifi.run' to ease testing and will use this for further testing and development before tackling the Sculpt integration. I also had to adapt the test-bed somewhat [1] as the driver still requires the Platform session - removing this hard dependency is one of the tasks I implied by the PCI/USB split. [0] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-01-22 [1] https://github.com/cnuke/genode-world/commits/ath9k_driver_support-2023-01-22 So far the RT2800USB driver is non-working and the next step is figuring out why. For that I will take a closer look at your USB back-end work and its integration into the kernel. (Bare with me as this is done in my spare time, it might take a while.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Hello Pirmin, > Currently it crashes during startup (something wen creating sockets). The > current progress is at: > > https://github.com/trimpim/genode-trimpim/tree/intel_igc I am wondering why you need sockets in the first place. I do neither own nor know Intel IGC devices so I might miss something obvious but they appear to be 2.5Gbs ethernet devices. From a quick glance at your branch it looks like you used the 'pc_wifi_drv' as a template which I would not recommend (as it contains functionality not strictly needed for "simple" ethernet drivers, e.g. the socket call interface). I think a more fitting blueprint would be the allwinner 'nic/emac' driver, chances are that you do not have to implement that many functions yourself. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hello Colin,
I added the ath9k driver [0] to the 'pc_wifi_drv' driver where it worked
fine in my limited testing (with the one device I have at hand and the
GSI/MSI quick-fix).
[0] https://github.com/cnuke/genode/commits/pc_wifi_drv-ath9k-2023-01-15
I also started to look at your commits in more detail (I have split them
up somewhat to get a better grasp of the changes [1] - for the commit in
world I diff'ed the driver in pc and yours to get your adjustments and
additions). I noticed that the 'pc_lx_extras' library code seems to be
missing from your commit.
[1] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-01-15
(As it turned out I might have misremembered as the USB wifi dongle I own
is apparently an Ralink rt2800usb device and not a Realtek one, which
should not matter though.)
> Yes. Regarding splitting up the components, a thought I had was to make the
> 'wifi_supplicant' a separate Genode component. Since it already runs as a
> separate thread using a shared buffer and semaphores, it shouldn't be too
> difficult to split it as its own component. The advantages would be that
> all interfacing of sculpt_manager with the supplicant would be common
> across drivers, making it easier to port more drivers, and each driver
> would inherit the same feature set of the supplicant (e.g. if ad-hoc mode
> were enabled it would not require much, if any, change to the drivers).
I would not go as far as splitting the 'wpa_supplicant' from the driver
for now. From Sculpt's perspective the wifi-management-layer
('Wifi::Frontend') is the interface to talk to. If ad-hoc mode or even
host-ap functionality becomes a desired feature I would integrate support
for that in this interface as well.
That being said, I entertain the idea of changing the inner workings
of the wifi-management ↔ supplicant ↔ driver chain to get rid of the
internal socket call interface or rather clean it up a bit.
> > As you probably have noticed we have some ported USB device drivers, albeit
> > using the legacy lx_kit/lx_emul implementation, that share the glue-code.
> > Eventually we want to update them as well - so by all means, if you have
> > some ideas formed by your current experience feel free to share them.
> >
> Yes, I did see these drivers. My experience with the legacy lx_kit/lx_emul
> implementation has been much less positive than with the current version,
> sorry to say. My thoughts on porting USB drivers:
> […]
Thanks for your input, I will respond to that in time and keep it in mind
only for now.
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Hello Pirmin, > Most of my time working with Genode is related to my job. Privately i did > build a test machine to run Genode on. The onboard Nic of this machine isn't > supported by the ipxe network driver. Therefore I started porting the > intel_igc driver from Linux. I hope I can finish this soon. > The original plan was to port the AMD Radeon drivers (Framebuffer) from > Linux. This was interrupted by the intel_igc driver thou. Having a Linux-based ethernet driver for PC would be nice as I could piggyback on that with a RTL8125 driver (as that is also unsupported in iPXE). > If there is time left I would like to help in porting AMD Radeon drivers > from Linux and test them. Coincidentally I have started to port the 'amdgpu' driver as well. As that is also a pet project done in my spare time, the time frame is fuzzy. That being said, of course it would be nice to collaborated - I will contact you off-list. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: ath9k usb Wi-Fi driver
Hello Colin, I am glad you managed to get your USB wifi dongle working. >If anyone has the hardware (Atheros 9K chipsets are in >common/inexpensive usb wifi radios) and wants to try it out I would be >excited to hear if it works for you. I do not own such a device and since it was easier to acquire a used mpcie one supported by the ath9k driver I went with that instead (*). However, I do have a Realtek-based (probably some RTL8192xx chipset) USB wifi dongle somewhere. So I will use that as judging be the recent 'rtlwifi' enablement work adding other drivers is no longer as involving as it was in the past; the USB transport integration is probably the main focus point. (*) IIRC there are some people that use mpcie Atheros devices in their PCEnignes APU or MNT Reform which would also benefit from having the driver (although I am not sure if those devices actually are covered by the ath10k driver). I only briefly skimmed your commit series but I think it would be worthwhile to integrate your additions. As we want to use the driver component also on other platforms besides the PC the code should be restructured (i.e. move the common parts from the 'pc' into the 'dde_linux' repo) anyway. At this point splitting the PCI and adding the USB backend appears to be reasonable. >Also if there interest I have some thoughts on how porting usb device >drivers might be made easier if developing a library of usb device >drivers on sculpt is considered a worthwhile endeavor. As you probably have noticed we have some ported USB device drivers, albeit using the legacy lx_kit/lx_emul implementation, that share the glue-code. Eventually we want to update them as well - so by all means, if you have some ideas formed by your current experience feel free to share them. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Hello Norman, > This also makes me hopeful for the next round of an update of the > DDE-Linux PC drivers, which should be definite part of our road map. We could also think about replacing iPXE with an DDE Linux-based driver component. > Given your invaluable contribution to the PinePhone topic - speaking of > camera, GPU, and audio - your further engagement in these areas would be > very welcome as well. That is what I summarized under “project work” ☺. Of course I have some basic ideas concering the PinePhone (like having an eBook reader component - an updated MuPDF would fit the bill, or having an audio player where I already tinkered with LVGL as an interface for the 'audio_player' component) but hopefully I will manage to work an these a long the line. > The other two topics mentioned (NVMe and AMD) leave me a bit uncertain > regarding the road map. I already expressed my weariness regarding AMD > in my reply to Alex, and I must confess my lack the expertise about > NVMe. AMD support is more on the personal side of things, so I do not expect it to appear on the roadmap. > How would you describe the practical benefits of the mentioned NVMe > features for Genode users at large, for advertising them on the road > map? Again, it focuses on my personal use-case where I use multiple VMs that directly access the NVMe device (via 'part_block' of course) as storage backend (as such devices are able to make use of serveral I/O submission and completion queues and naturally feature MSI(-X) support one could exploit that for perfomance optimizations like minimizing cross-core IPC, handling clients in a disjunct fashion etc). Of course changing the driver component is only (arguebly) a small part as there are more parties involved (libc, VFS, kernel). Maybe the over all theme could be “Optimized I/O for ” as that would probably fall in line with the VFS renovations. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Hello, > How did you perceive the Genode year 2022? > What directions are you most excited about? One of the most profound developments was certainly the overall enablement of Sculpt on the PinePhone partly aided by the revitalized DDE Linux porting approach. Being able to provide a driver component in a manageable amount of time while focusing on the integration rather than spending time matching and mixing the pieces was an - I dare say - enjoyable experience. So, from that perspective I am curious where we end up by the end of this year when it comes to the PinePhone. > Which topics do you deem as interesting to explore yourself? > Do you already happen to have rough plans about 2023? Well, besides doing project work, as most of my pet projects start on a whim it is hard to say if I come up with a new itch to scratch or finally bring some of the stuff upstream. That being said, from the top of my head, taking advantage of modern I/O devices (multi-queue and multi-core interrupt handling in the NVMe driver) and extending support for the AMD systems I use at home are high up on my list. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Compiling toolchain on void
Hello Sagar, > Void doesn't have autoconf2.69. It has 2.71. > > How do I solve this? I built and installed that version from its source archive manually. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Compiling toolchain on void
Hello Sagar, > On voidlinux, packaged ncurses doesn't have non-UTF version > > It has ncursesw accroding to the devs there. > > $pkg-config --exists ncurses && echo foo > $ > > Above command doesn't print foo. Replacing ncurses with ncursesw does. > > Will I face future issues building toolchain with this? I cannot speak for the future but for the moment it should work fine. You might encounter problems bootstrapping the Ada/SPARK support on voidlinux but disabling that is an option if you do not require it. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Building a computer to run sculpt
Hello Pirmin, > From the unofficial Genode HCL (http://usr.sysret.de/jws/genode/hcl.html) I > would guess a 10th generation Intel with integrated graphics would be a good > a save starting ground. As the mainboard I would use a ASUS MB PRO Q570M-C > which is 11th generation ready. The reason for this MB is that the Q570 > chipset supports AMT which would allow me to debug problems via Ethernet. > > Do you think that a system built with these components would run sculpt well > or are there some pitfalls that I have overlooked? Briefly skimming the components I don't see any immediate pitfalls. (With regard to AMT, on a desktop system using a PCIe serial card or - if available - an onboard COM header works equally well in case you are mainly interested in serial output. That broadens the choices somewhat.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Sculpt OS 22.04 Release Candidate (RC)
Hello Pirmin, > I tested the new release over the weekend on my T460p. > > I both used wired and wireless networking to download packages. > > When I used wireless to update the Linux running the wireless connection > went down in the middle of transferring data. I was only able to bring it > back up after restarting the WiFi driver. When this happened downloading of > package archives in sculpt also failed. This could be related to #4083. Thanks for testing. It could be related to #4083 - due to Johannes' experiences I investigated the re-authenticate/disconnect issue further (see #4455) and there are some cases that are not properly handled yet. If you are willing you can cherry-pick commit 'accab77' and give it a try. (Since you omitted a LOG file I assume the driver did not exhibit errors obvious in the LOG like a page-fault or something similar.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: SulptOS with Intel(R) Dual Band Wireless-AC 8265
Hello Lonnie, > I am testing out Sculpt on my Intel NUC i7 and although it seems to boot, > it runs rather slow as well as will not find the wireless network card that > is built into the NUC (Intel(R) Dual Band Wireless-AC 8265) > > I am wondering if there are any updates on the wireless card detection for > SculptOS. We have not changed the detection mechanism and in principle 8265 cards should be supported. When selecting 'Network → Wifi' in the leitzentrale the driver messages are printed to the LOG. Perhaps it contains more information to pin point the apparent issue. > Also, I was thinking about the desktop and GUI (Nitpicker) and was > wondering how hard it might be to change out the graphics to something more > "themeable" like LVGL (https://lvgl.io/) but am still learning for which > Genode might have these capabilities. In theory most of Sculpt's current UI is already themeable, for all practical purposes the required hooks are not in place (yet). FWIW, I created a proof-of-concept port of lvgl [1] some years ago. One limitation of lvgl at the time was the inability to change the display geometry dynamically, which did restrict its application somewhat (AFAIK this features was added in a more recent version). [1] https://github.com/cnuke/genode-world/commits/littlevgl-2019-02-04 In line with what Cedric already mentioned it is about providing alternatives to Qt when realizing client components as nitpicker is the grey eminence pull strings in the background and orchestrating things. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: lwext4_fs test fail on ftruncate()
Hello Alexander, > I am trying to run lwext4_fs.run from world repo > > it gives the following error on linux/x86_64 > ... > [init -> test-libc_vfs] calling open(file_name4, O_CREAT | O_WRONLY) > file_name=test4.tst > [init -> test-libc_vfs] open(file_name4, O_CREAT | O_WRONLY) succeeded > [init -> test-libc_vfs] calling ftruncate(fd, 100) > [init -> test-libc_vfs] ftruncate(fd, 100) succeeded > [init -> test-libc_vfs] calling close(fd) > [init -> test-libc_vfs] close(fd) succeeded > [init -> test-libc_vfs] calling stat(file_name4, &stat_buf) > file_name=test4.tst > [init -> test-libc_vfs] stat(file_name4, &stat_buf) failed, ret=0, errno=2 > [init -> test-libc_vfs] Error: Uncaught exception of type 'Test_failed' > [init -> test-libc_vfs] Warning: abort called - thread: ep > ^Cmake: *** [Makefile:396: run/lwext4_fs] Error 130 > > can this error could be ignored? > is lwext4 port somhow usable in general on 21.11? Increasing a file via truncation is not supported by this version of the lwext4 library (I have not checked if this is addressed upstream by now). If your use-case depends on this feature, e.g. sparse files, 'lwext4_fs' cannot be used (also, 'cp(1)' from coreutils assumes it may use lseek/ftruncate to prevent unncessary I/O which will not work either). > can I utilise it as a main fs inside genode to store compilation > results in rw mode? I would recommend sticking to 'vfs/rump' for now as 'lwext4_fs' is not that well tested. *Iff* you are fine with debugging problems that arise from using it I suggest you rather take a look at 'vfs/lwext4' [1] as starting point because most file-system servers besides the 'vfs' component are on their way out. [1] https://github.com/genodelabs/genode-world/issues/278 Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: CBE key encryption
Hello Stefan, > But then the vfs_cbe requests to have a all zero key encrypted which due > to the ICV added by hardware black key handling fails. We cannot seam to > find out where the request originates or why vfs_cbe would ever encrypt > any key, let alone a key of all zeros. Whenever the CBE writes the current superblock back to the block device it first has to encrypt the current and the previous(!) key as both are stored within the superblock on the block-device. This is necessary because you may stop the CBE during rekeying and it needs the previous key to complete the operation as there are still blocks encypted with the old key around. So I assume in your case the previous key was not yet used and therefor is initialized to a default value that, as it happens, is all zeros and the CBE wants to write the superblock back (it does so on every 'sync' request), which is why you encounter this unexpected request. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: running CBE on RAM vfs
Hello Stefan, > As a precursor of running CBE on our i.MX8 IoT device, I'm trying to run > CBE entirely from RAM based in a vfs and testing it using the > block_tester. To achieve this I merged the vfs_cbe_init and vfs_cbe > runscript using a sequence to run cbe_init before vfs_cbe. > > My problem is that the cbe/current/data device seems to be only 4 KiB or > 1 block in size, regardless of how I parameterize cbe_init. > > Any ideas on why this happens or how to fix it? I took your branch and rebased [1] it to pull in CBE commits (which are now on staging) that are necessary for proper operation of the CBE. [1] https://github.com/cnuke/genode/commits/cbe_ram Additionally it contains 3 commits that allow for executing your run script - I have not checked if the CBE functions correctly though (i.e., if the data is properly stored). The 'vfs_block' commit, however, is the one that solves your problem where the size reported by the CBE's data file is incorrect. Issuing the explicit sync request will trigger the CBE to perform any operations necessary to finalize the initialization (the sync request leads to “freezing” the current state). At this point the 'file_vault' component is the reference implementation of a component that manages the CBE. I suggest you look into this component first. Although it requires a Gui session, which might not work well in your IoT use-case, and is somewhat extensive, eventually you will need a management component as well and this one shows you how to operate the CBE properly. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
#genode IRC channel now on libera.chat
Hello, as the subject line already reveals, we switched the IRC network and are now domiciled on libera.chat [1]. You are free to drop by and join the #genode channel via the web-client [2] without prior registration for one or the other round of Genode-related smalltalk. [1] https://libera.chat [2] https://web.libera.chat/#genode Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: how to open elf file image from inside genode? libbacktrace question
Hello Alexander,
> […]
> So, this is inside dl_iterate_phdr under mutex, as usual, and double
> mutex call related to search of errno.
> I suspect other potential code path where we can hit «seach for
> address of some functions from shared libraries»...
>
> Finally I will remove, as suggested , mutex guard from dl_iterate_phdr
> completely - while not so sure that this will not lead to error.
Please replace your mutex-remove commit with the following commit [1],
which replaces the linker mutex with the shared-object mutex. This
behaviour is in line with other dynamic-linkers.
[1] https://github.com/genodelabs/genode/commit/c45d964bc23f4f
(I moved the quotation down a bit to get concise block of text.)
> In short, it try to open ld.lib.so (from inside genode), open() fail,
> and it try to obtain libc errno (via jmp_slot/etc from shared library).
> So, this is inside dl_iterate_phdr under mutex, as usual, and double
> mutex call related to search of errno.
> I suspect other potential code path where we can hit «seach for address
> of some functions from shared libraries»...
> Also I add the following to the run file to allow read of ld.lib.so
> from inside (not sure that this is correct - may be need something
> else? like direct reference to rom session?)
>
In case libbacktrace wants to access other shared-objects directly, besides
the binary itself, I would deal with it in the same way, e.g:
! […]
!
!
!
!
!
!
!
!
!
!
!
!
! […]
This config operates under the assumption that libbacktrace wants to
access the shared-objects via 'open("/ld.lib.so")' - I have not checked
it that's true.
> Seems that after that operation my SMP small test with even 4 CPU
> works somehow (need more extensive tests to be run for golang and
> goroutunes).
>
> Question: how to verify that removed mutex call does not break
> something important?
Please just use the commit I referenced above. As far as our automated
tests go, it did not introduce any regressions (of course that is no
guarantee that all potential corner-cases are covered).
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: how to open elf file image from inside genode? libbacktrace question
Hallo Alexander,
> Returning to my question, could I use posix open(«/test-go») to open
> my binary from which I run executable, if I have the following code in
> run file:
> […]
Yes, using 'open()' is the way to go. As libbacktrace hardcodes a few
options you could piggy-back on one of them. I picked the '/proc/self/exe'
option:
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
With this VFS configuration in place libbacktrace opens the binary
successfully. However, you will be greeted with the by now infamous
deadlock ahead error message when using '-smp 2':
! [init -> test-go] Error: deadlock ahead, mutex=0x164040, return ip=0xf3383
The mutex in question is the 'Linker::mutex()' object. Again this is due
to the fact that as side-effect of 'dl_iterate_phdr' a jump-slot
relocation for 'mknod' takes place (*). Why that is I have not checked.
Now we are not entirely sure if taking the mutex in 'dl_iterate_phdr' is
strictly necessary - that is something we have to investigate. Removing
the mutex allows the 'go_app' to run through. So you are free to do the
same. But to be clear, we do not know if this leads to other regressions.
We are going to look into that.
(*) You can instrument that by applying the patch I attached that
makes the linker verbose and shows you the object and index for
the relocation:
! […]
! [init -> test-go] LD: SLOT libc.lib.so 0x20c
! [init -> test-go] LD: SLOT binary 0xe
! [init -> test-go] Error: deadlock ahead, mutex=0x164040, return ip=0xf3383
With this information you can check to which symbol the index
belongs to:
$ readelf --dyn-syms test-go|grep '\<14:'
14: 0 FUNCGLOBAL DEFAULT UND mknod
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
--- a/repos/base/src/lib/ldso/main.cc
+++ b/repos/base/src/lib/ldso/main.cc
@@ -293,10 +293,10 @@ struct Linker::Ld : private Dependency, Elf_object
Elf::Addr Ld::jmp_slot(Dependency const &dep, Elf::Size index)
{
try {
- Mutex::Guard guard(mutex());
+ if (verbose)
+ log("LD: obj: ", dep.obj().name(), " ", Hex(index));
- if (verbose_relocation)
- log("LD: SLOT ", &dep.obj(), " ", Hex(index));
+ Mutex::Guard guard(mutex());
Reloc_jmpslot slot(dep, dep.obj().dynamic().pltrel_type(),
dep.obj().dynamic().pltrel(), index);
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: next iteration of golang support attempt
Hallo Alexander, > hm, I apply patch- it works ok for UP. > But, for SMP (2 CPU - just replace -smp 1 option in .run file) it return the > following: > > [init] child "test-go" > [init] RAM quota: 20232K > [init] cap quota: 216 > [init] ELF binary: test-go > [init] priority: 0 > [init -> timer] 0x100 .. 0x10ff: linker area > [init -> timer] 0x4000 .. 0x4fff: stack area > [init -> timer] 0x3 .. 0x161fff: ld.lib.so > [init -> test-go] 0x100 .. 0x10ff: linker area > [init] child "timer" announces service "Timer" > [init -> test-go] 0x4000 .. 0x4fff: stack area > [init -> test-go] 0x3 .. 0x161fff: ld.lib.so > [init -> test-go] 0x10e0c000 .. 0x10ff: libc.lib.so > [init -> test-go] 0x10d7 .. 0x10e0bfff: vfs.lib.so > [init -> test-go] 0x10d36000 .. 0x10d6: libm.lib.so > [init -> test-go] 0x1328000 .. 0x14d: stdcxx.lib.so > [init -> test-go] Error: LD: jump slot relocation failed for symbol: > '_Unwind_Backtrace' > [init -> test-go] Error: Uncaught exception of type 'Linker::Not_found' > [init -> test-go] Warning: abort called - thread: ep My bad - the first commit from yesterday is incomplete. Merely making the symbols available for linking is not enough. Since the implementation is global hidden we have to make it also accessible. Please also apply the following commit [1]. [1] https://github.com/cnuke/genode/commit/3eb8312daee2ae24f7eea43adf7697dbfd0c9568 > interesting that I do not find a code for _Unwind_Backtrace inside libc.lib.so That is correct because the code is not there. We make the symbols available so that the linking stage for components that solely link against the libc will not fail. At run-time the implementation is provided by the dynamic linker (ld.lib.so). If you look around in the base repository's library .mk files and check the resulting unstripped shared-objects (e.g. objdump -x) the picture should become clear. (All in all, long-term it is probably better to provide the unwind functionality in way that accommodates the needs of the Genode base system as well as as the needs of different languague runtimes rather (ab-)using the one that is primarily tailored to Genode's base system.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: next iteration of golang support attempt
Hello Alexander, > I still have a problem with nested jmp_slot() related to call to > strlen() during stack unwind call and related nested mutex leading to > deadlock. > […] > call above inside test-go linked to strlen() to inside libc, as you see > from stack above and from disassemble test-go, where it call shared libc > […] > /genodelabs-genode-2491eee/contrib/gcc-3cade18cf9defeefa714aa91de3b157fbad4aa18/src/noux-pkg/gcc/libgcc/unwind-dw2-fde.c:300 > 11a8ca0: e8 db 6b 00 00 callq 11af880 > so, we take same mutex twice here and in attempt to search for strlen() > from @plt via jmp_slot… > This happens only with SMP, if I use UP configuration it is not happens. > Frankly, I am stuck a bit… this lib is a part of general toolchain, not > clear why this stack unwind staff call shared libc… > may be it is necessary to recompile toolchain and library and force > strlen() to be expanded to inlined one? Please give the following two commits [1], [2] a try. The first exports the required Unwind functions needed by the libgo runtime and the second removes the direct usage of the toolchain libraries. With both commits applied the 'go_app' test component still works and hopefully it addresses your SMP issue as well. [1] https://github.com/cnuke/genode/commit/e19b19e0367e544654bc917e09c2cb991b71b211 [2] https://github.com/cnuke/genode-world/commit/30ef976ebdd58becb1785993cd184344625f0403 Your problem boils down to using the toolchain libraries directly, which is not supported and forced the compiler to produce the PLT relocations (as strlen() is unresolved at this point). On Genode you are supposed to go through the base library, i.e. ld.lib.so, that already takes care of setting things up the proper way. As the Unwind symbols required by the libgo runtime were not exported the linking step of the 'go_app' probably failed. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: next iteration of golang support attempt
ot sure which > applications will have a problems > 7. check Go support for wider set of features > like floating point, os interfaces, etc, including cleanup of stubs in libgo > related to unused OS features from other subsystems (see README for list of > broken calls) > 8. add golang support for TCP network > need not only patch back some .go code, but also a set of sample .run files > and test examples for configuration > 9. port feature which allow to generate make file from «go build» process > in this moment go build and related compilation infrastructure not supported, > I use gccgo > 10. start port of docker libraries to Genode in the same way as it was done > by me for another microkernel before (kind of complex task requiring some > additional workforce support) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: next iteration of golang support attempt
Hallo Alexander, > I finalise move of mcontext and libgo_support libraries, as well as > update libgo a bit to reflect changes, and fix go test application. thanks, I will take a look today and get back to you. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: [set,get,make,swap]context from glibc for amd64 implementation and question for Norman
plementation should use the ucontext_t data structure from the libc to prevent any memory layout issues. If that is possible to uphold you could as well bring the glibc implementation back. (I removed the available makecontext implementation because it seems to be merely a left-over that is not required. Stubbing it as well feels more in line. I moved the implementation into the support library which is why it depends on libc to get access to the header files because I omitted making the compilation unit standalone.) So in case of go, the libgo library should be linked against such an support library, that - as it uses the Genode API - needs to be linked against the Genode base library. If that is not possible, presumeably because adding additional libraries to libgo's build-system is cumbersum, linking your go component against the library should do the trick. It goes without saying that this approach only works if you are fine with linking against the base library but I think for the time being that is workable solution. It removes extending the libc from your critical path and gives us time to decide how to deal with it properly. Please let me know if you share the assessment or if I am still missing something obvious. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: [set,get,make,swap]context from glibc for amd64 implementation and question for Norman
Hello Alexander, > as a base I borrow some code from glibc, and remove related files > (mostly _ucontext.h/ucontext.h) from genode > >> May I ask what is the reason for choosing and incorporating the glibc >> implementation rather than using/enabling the one in the FreeBSD libc? > > 1. current implementation of context switch in FreeBSD done completely > in kernel via sys call. E.g. this is full code of getcontext function > (stored in genode, not used): > […] > 2. context family support do require complex and misleading structure, > e.g. take a look for setcontext code: > […] > 3. ucontext.h and related is isolated in current libc and could be > easily replaced (because it used only in *context family of functions > and signals which has only rudimentary support > > 4. glibc implementation is straightforward and well supported, > relatively small and suitable for big set of platforms, without > complex kernel/__libc_interposing analogous and could be borrowed > (copied) with minimal efforts, I can confirm this. > > 5. glibc implementation of these functions do contain potentially > useful security feature of shadow stack support (under SHSTK_ENABLED > define - not enabled in my patch) > > So, I consider option to use existing freeBSD version and replacement > of code of functions to ones from glibc - and think that this make > everything too complex, related infrastructure not clear and not easy > to support. May be I am wrong. > > for me simplest for implementation and, especially, for future support > - is chosen approach (with part of glibc port). It is simple and > straightforward, easy to extend to arm/etc. > > Another option I consider is a usage of native context-switch > functions for genode low level Os (OS - dependent). Anyway, it will > significantly lower performance, and not portable option, so, I do not > choose it. > >> Strictly speaking containg such a large patch makes the commit >> unsuitable for the Genode main repo as the burden of maintaing it >> falls on our shoulders at the end and the reason for including it in the >> first place is not immediately clear. > > significant part of patch is a removal of old files like ucontext.h > and plain addition of new files, take a look for statistics, no > complex updates of files involved: > […] > By the way, I can make patch smaller if you give me a direction how to > remove some files during install or patch process without patch > itself, may be via .mk file (e.g. libc-gen.mk) Thanks for the thorough answer, which puts things into perspective. We briefly discussed the matter offline and somehow implementing the API with a mechanism that is already there (e.g. the setjmp/longjmp based task model that we use in various drivers and the libc) feels more natural. That being said, we do not know if there are any requirements in the *context API that would prevent us from going down that road. Do you know of any, besides the potentially worse performance? >> For better or worse, we still lack the resources (read man-power) as well >> as a deeper understanding for the issues at hand when it comes to the >> requirements of the golang-runtime (which somewhat is a consequence of >> the lack of resources) that such an undertaking arguably deserves. > > I need *context() implementation, and it can’t be moved to world > repository - its a part of libc. > > Also to use functions I need C interface for allocate_seconday_stack() > which should be somewhere inside (I choose libc > dummies.cc<http://dummies.cc> file) > Question: may be better other place? e.g. inline C interface function > as a part of e.g. thread.h? Any recommendations are welcome! > > I understand your point, so, another question is: how I can continue > if patch can’t be stored inside genode core? it can’t be significantly > smaller (4 functions/files to be add at least)... > > Everything else for golang support I will have in world, this is the > only part of core (may be together with extended anonymous mmap > support). Judging by the freestanding nature of the '*context()' implementation should it not be possible to get away with putting it into world as well? For example as part of a supplementary static run-time library that shadows the libc by resolving everything locally, including the stack functions. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: [set,get,make,swap]context from glibc for amd64 implementation and question for Norman
Hello Alexander, thanks for keeping the golang port effort going. > as a part of efforts related to golang port I make separate patch for > 21.02 genode related to implementation of > setcontext/getcontext/makecontext/swapcontext family in libc > > as a base I borrow some code from glibc, and remove related files > (mostly _ucontext.h/ucontext.h) from genode May I ask what is the reason for choosing and incorporating the glibc implementation rather than using/enabling the one in the FreeBSD libc? > related 2 patches are in https://github.com/tor-m6/genode.git in 21.02 repo > main one contains implementation to be applied to libc port > aux patch contains only simple test for these functions, you can run it as > > I need also to add C support for > alloc_secondary_stack/free_secondary_stack in dummies.cc to be able to > use them during allocation of stack for makecontext/etc (it should > work even in C files - current code do requires C++, I even can’t test > patch without them). May be this is wrong place for the wrappers… > > current problems with the patch: is support only x86_64 (while can be > easily extended to arm64) on nova (while should work on other OSes), > and it do not support signals save/restore (while seems that not many > of them supported by genode currently). Also some removal of code from > libc is not that clear and correct (implement it in patch). > > Question for Norman (and may be other maintainers): > is it suitable for main genode code, or I should keep patch only in my fork? > Is it worth to make a pull request? Strictly speaking containg such a large patch makes the commit unsuitable for the Genode main repo as the burden of maintaing it falls on our shoulders at the end and the reason for including it in the first place is not immediately clear. For better or worse, we still lack the resources (read man-power) as well as a deeper understanding for the issues at hand when it comes to the requirements of the golang-runtime (which somewhat is a consequence of the lack of resources) that such an undertaking arguably deserves. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: General Improvements for Sculpt
Hello Edoardo, > I don't know if "Chocolate Doom" is the homonymous video game, but > unfortunately I wasn't able to play it cause an infinite "I_init: > setting up machine state", the audio driver was the bsd_audio_drv > while the wm was the themed_wm (internet connection under nic_router), > do you know if I am doing anything wrong? I am not big fans of video > games, but I would like to try it! This is a known problem - some archives referenced by my index no longer work on vanilla Sculpt-20.08. Since I do not plan to update the archives I removed my index file to prevent others from stumpling upon this issue. > Josef, I started yesterday studying how Genode handles wifi connections, > it is almost identical to Linux, for the software stack (mac80211 and > cfg80211) but I haven't understood why in firmware.cc ( the text file > you linked to me ), in Fw_list struct some firmware images have NULL > as available name while others have their correspondent name? Are > still unimplemented some models ? For some devices the driver will ask for a different firmware version than is available because the the driver supports a range of different versions. However, not all supported firmware versions are publicly available (or were not at the time support for a device was added to the wifi_drv). In this case we supply the firmware version we have at hand. If you follow the implementation of 'request_firmware_nowait()' the intention becomes clear. > I would like to start writing a software stack for BLE, any hints? > Bluez could be a good starting point but honestly, I have no idea of > how to port it on A non Unix system. I have no experience with BLE; the general approach would be to look at how other OS' implement the stack - which parts are implemented by a kernel driver and which parts are implemented as user-land component and go from there. One example would by our USB LTE modem stack where we ported the kernel driver from Linux and created a driver component that presents the data channel as a Uplink session and the management channel as a Terminal session. The 'mbimcli' port uses the Terminal session via the libc and VFS to perform the necessary configuration of the modem while the Uplink is used to transfer the data. So in this case you have two components, a driver and a configuration component. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Cmus issue
Hello Dima, > [runtime -> bsd_audio_drv] Error: LD: jump slot relocation failed for symbol: > 'Genode::Timeout::Timeout(Timer::Connection&)' > [runtime -> bsd_audio_drv] Error: deadlock ahead, mutex=0x161a40, return > ip=0xebbb0 Yeah about that… I completely missed the fact that old WIP branch I updated the package from contains an ABI breakage, which probably renders the binaries unusable on vanilla 20.08. Sorry for wasting your time in that regard. I think at this point it is easier if you try to build the archives on your own (using 20.11 as basis) or wait for the next Sculpt release. > > For adjusting volume levels let me point you to Alex' [1] Genodians post. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Cmus issue
* Josef Söntgen [2021-02-08 11:32:23 +0100]: > You could do that but you need the following commit [2] from my > genode-world repository and you would have to build all archives > yourself. On that account it might be more reasonable to wait for the > next Sculpt release. > > [2] https://github.com/cnuke/genode-world/commit/d4e26a54ffcb56d Well, if you use the Genode 20.11 branch you will not need this commit. Sorry for the confusion. -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Cmus issue
Hello Dima, > Yes, I used your packages from the experimental section for Sculpt 20.08. > > If I noticed correctly, new package version installs replace the old > version without the need to manually uninstall it? > After adding the packages once again using the "+" menu, I found only > these (new) versions listed @ /depot/cnuke/pkg: > bsd audio drv 2020-09-24-b > cmus 2020-09-11-a You have to re-fetch the index first (by enabling/disabling the entry in the Selection pop-up menu). The new driver version is marked with “(fix)”. For adjusting volume levels let me point you to Alex' [1] Genodians post. For now it is a bit “fiddly”. [1] http://www.genodians.org/alex-ab/2019-02-13-sculpt-vc-audio > […] > > Should I compile Sculpt 20.11 from git and work with that version > instead (if cmus is known to work there)? You could do that but you need the following commit [2] from my genode-world repository and you would have to build all archives yourself. On that account it might be more reasonable to wait for the next Sculpt release. [2] https://github.com/cnuke/genode-world/commit/d4e26a54ffcb56d Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Cmus issue
Hello Dima, > I'm using Sculpt 20.08 (the officially released image). Here's the LOG output: Right, my bad. I was under the assumption you used a more recent branch, because cmus was introduced in 20.11 (although there was no “official” Sculpt release) after all. If you be any chance used the packages referenced in my index for 20.08 in the experimental section the problem is the audio driver. It references a version where the driver does not announce the Audio_out session but the mixer and in return cmus wait for it. Which is why it gets stuck waiting for a session that never comes. I have published a fixed version where you should see the driver announcing its session in the LOG. That being said, I am not sure in which state the various packages are as I built them on a WIP branch and some things changed/were fixed before they entered the mainline - here be dragons. I hope you did not spend too much time chasing down the problem. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Cmus issue
Hello Dima, > BSD audio drv: > Device access -> audio hardware > Region maps -> custom virtual memory objects > > Mixer: > Audio output -> bsd audio driver > Report -> system reports > > Cmus: > File system (media) -> ahci-1.fs > File system (home) -> ahci-1.fs > File system (fonts) -> fonts fs > GUI -> themed wm > Audio output -> mixer > ROM (clipboard) -> themed wm > Report (clipboard) -> themed wm > Real-time clock -> system clock > Region maps -> custom virtual memory objects > > What would be the proper configuration? The routing looks fine - is there any LOG output from the cmus subsystem? You should at least see something like the following snippet: [runtime] child "cmus" [runtime] RAM quota: 65288K [runtime] cap quota: 466 [runtime] ELF binary: init [runtime] priority: 0 [runtime -> cmus -> cmus] Error: no plugin found for socket() [runtime -> cmus -> terminal] Warning: scs_g0 not implemented for 66 [runtime -> cmus -> terminal] Warning: scs_g1 not implemented for 48 [runtime -> cmus -> terminal] Warning: Alternate Screen (new xterm code) not implemented [runtime -> cmus -> terminal] Warning: decrm not implemented for 4 [runtime -> cmus -> terminal] Warning: Application Cursor Keys not implemented [runtime -> cmus -> terminal] Warning: unhandled sequence ESC _(05/15) c(06/03) [runtime -> cmus -> terminal] Warning: unhandled sequence ESC \(05/12) ESC(01/11) [(05/11) Which version of Sculpt or rather which branch are you on? (I am using an older Sculpt version and have not yet checked if the cmus package still works on a current branch. A recent change that could be a problem is the Terminal change, where it now uses the gui session directly but in the past used a framebuffer session. The cmus package runtime is still unchanged in that regard.) Rergards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: general improvements for Sculpt
Hello Edoardo, > = > WIRELESS SUBSYSTEM > = > > *) I asked for the documentation on it before speaking (Thanks > Alexander), it is extremely similar to Linux wireless subsystem, > except for a modified libnl support for user space, could I have the > source code for it? I would like to study the modification you've > apported for libnl. > I am pretty fascinated by those modified subsystems. You can find all modifications in Genode's git repository in the 'dde_linux' repo [1], in particular 'src/lib/libnl'. The 14.11 [2] release-notes contain an overview of the architecture of the 'wifi_drv' component. Although some things are different by now the overall picture is similar. [1] https://github.com/genodelabs/genode/tree/master/repos/dde_linux [2] https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack > *) It would be great to extend the range for other devices, I saw you > implemented only the iwlwifi driver, would be great to implement also > brcmf (both HardMac and SoftMac) and even Qualcomm's wireless card, I > can give my full support for that. Having support for more/different wireless devices is certainly useful and at some point necessary. If you would like to join this effort, I can give you some hints on where or how to start. > /* > *) I have some ideas for controlling the iwlwifi blob, for now I would > like to test it on my own, in general it would be great to > ""customize"" the "blob loading". > */ If you look into 'repos/dde_linux/src/lib/wifi/firmware.cc' you will see that the firmware blobs are simply requested via a ROM session. With some tinkering in Sculpt you could set the system up in a way that it becomes possible to load the firmware-images differently. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2021
Hello fellow Genodians, TL;DR the better part of the last year I worked on the CBE, while doing some driver refactoring (NVMe and PCI Audio) in between. Some things I originally planned to work on, namely USB Audio support and a lwext4 VFS-plugin, got somewhat side-lined. But I could dig up my old OSSv3 PoC and eventually was able to use cmus on Sculpt, which is nice. So, on one hand this year I plan to tackle the things left over from last year. On the other hand, I would like to join the “iMX8 effort” by working on GPU/VPU support. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: mmap implementation for ANON mapping with desired address
Hello Alexander, > […] thanks for answering my questions so thoroughly, much appreciated. Unfortunately, I am currently occupied with other tasks and only skimmed over your reposonse so far. From what I gathered things are not as easy as I thought them too be, which is whay I am going to spend some time over christmas to look into Golang's internals (I guess on that account TamaGo is probably also worth a look) to gain a bit more insight and will get back to you after that. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: mmap implementation for ANON mapping with desired address
Hello Alexander,
as predicted I am back with some questions.
First, thanks for your efforts of bringing Golang to Genode. I took a
look at the commits on your topic branch and your README was very
helpful in getting started; especially the current limitations section
reflects questions I am going to ask. Please bear with me if some
questions sound obvious but I lack the understanding of the inner
workings of Golang's run-time and I did not follow all your previous
E-Mails on the ML.
So, I checked out your 20.11 branch and tried to follow your instructions.
Unfortunately, I could not compile libgo out-of-the-box because libtool
was complaining about “unrecognized options” and I stopped at this point.
This brings me to my first question
* Is there a technical reason for executing the auto-tools build system
rather than porting the libraries, i.e., create the .mk files for
Genode's build system?
The instructions in the README lack the motivation behind that decision.
and furthermore
* Is it strictly necessary to solely produce static libraries or could
we get away with a dynamic shared-object, libgo.lib.so, that incorporates
everything and the target application is linked against or is it possible
to have multiple shared-objects. After all, there is already a libffi port
- ffi - that is built as .lib.so.
While stepping through the libgo commit I noticed the patches:
* You choose to add a new run-time target, “inno”, that is based on NetBSD
rather than using the existing FreeBSD target. For all intents and
purposes, Genode appears to be FreeBSD for ported software due to using
its libc¹. Is there a reason why that is not possible for Golang's
run-time?
IIRC, on some platforms, e.g. Solaris(?), the normal Golang run-time
solely uses the libc to interface with the OS instead of wrapping
system-calls directly. Is it the same with gccgo's run-time?
With regard to the first questions, if we remove auto-tools from the
equation we could shadow specific run-time parts where the upstream
implementation does not work on Genode.
¹) Granted, our libc port is not feature-complete and might lack
expected functionality, e.g. kqueue/sysctl or as you already
noticed mmap handling, but we could take this as an opportunity
to extended our libc port.
* I noticed that you use internal headers for implementing the stack
handling. Is in this context the available Genode::Thread API not enough?
My somewhat naive point of view would be to use our POSIX layer wherever
possible and only diverge where necessary - that only boils down to
go-routine and stack handling or does it not?
Finally, the most important question:
* From what I can tell the port itself still somewhat feels like a
proof-of-concept that as you mentioned in the README is the side
result of a research project. It would require further clean-up
before we could add it to Genode.
(This includes the current short-comings like missing context
support for go-routines, reliance on -fno-omit-framepointer,
etc. The support code that is currently part of the component
should be moved to a central location like you already suggested.)
Would you be willing to do that clean-up work or is it from your
point of view enough to just keep the port as an example in case
somebody else wants to do that? Your reaction so far, creating
the github issue, suggest that you do have some motivation.
I ask because in the past we got a welcome one-time contribution
for Rust support on Genode. However, since we do not use Rust, we
merely dragged it along and eventually removed it². As support for
Golang has no immediate priority for us, we hesitate to spend our
limited time on this at the moment.
That being said, I wrote our CI-tools web front end in Golang and
running it on Genode certainly would be nice and could be a reason
to nonetheless set some time aside to get that up and running :-).
Judging by the reaction on your issue, we could very well make a
community effort out of supporting Golang.
²) To not make the same mistake I imagine adding support to our
tooling for creating Golang based components is necessary.
Maybe it is worthwhile to extend 'goa'[sic] in that regard so
that a Golang-developer can use 'go' to initially develop his or
her application and later one use 'goa' to create a binary for
Genode, while 'goa' does the heavy-lifting behind the scenes.
I think you briefly touched the “go build → Makefile” topic in
one of your mails. After all, rather than writing specific
Genode components in Golang I guess people want to deploy their
existing applications first and would be fine with interacting
with Genode via the POSIX/VFS layer.
Regards Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · h
Re: mmap implementation for ANON mapping with desired address
Hallo Alexander, > Now I think that it is closer to what I need for golang runtime, at least it > works here. > Could you take a look? > I just ported current set of patches to 20.11. > please, take a look at https://github.com/tor-m6/genode.git branch 20.11 > main implementation of mmap part temporary in 1 file and 1 patch > anon_mmap.cc<http://anon_mmap.cc/> from > https://github.com/tor-m6/genode/commit/cf79a564e1b004fef5660e84d01d6c2906742d3f > and genode files minor modifications > https://github.com/tor-m6/genode/commit/41b57fd06516c9b33b4b06e1f91cb134a3da8ce9 I'm going to take a look at your changes and probably will get back to you with some Golang related questions in general (it might take one or two days). Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Wifi drivers in Sculpt OS
Hi Colin, > Another thought that came to me is whether Sculpt VMs can do USB > passthrough, and then I could run a Linux VM which will have the drivers. > Is that possible? Could the network connection make it's way out of the VM? You can use USB passthrough on Sculpt, most prominently it is used for writing new Sculpt images to USB sticks [1]. It should also work for other USB devices like NICs and wireless dongles. However, there is no way for a VM to provide this as a service to the outside. [1] https://genode.org/documentation/articles/sculpt-19-07#Updating_the_USB_boot_device_from_within_VirtualBox Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Wifi drivers in Sculpt OS
Hello Colin, > On Thu, Jan 23, 2020 at 10:17:26PM -0500, Colin Parker wrote: > […] > Is bringing drivers over a pretty simple process like copying a few > files or is it an extensive effort? Thanks in advance for your > suggestions. As Stefan already pointed out, unfortunately it indeed is a more extensive effort. The 'wifi_drv' component is currently pretty much tailored to PCIe Intel wireless devices. Apart from porting the driver for an USB device the USB transport connection itself must be implemented. Since the current driver is somewhat entangled the first step would be the refactoring of the current implementation, i.e., separating its various parts a bit into - component frontend (basically the Nic session provding part) - wireless stack (mac80211, cfg80211, …) - iwlwifi driver and hide the PCIe transport portion into the iwlwifi part for now (although I'm not sure if that's easily achievable). The goal would be to make the wireless stack transport agnostic so that a USB backend can be easily added and the frontend, which includes WPA handling, may be shared by both kinds of devices. The next step is then porting a USB device driver and making the necessary adjustments. Yeah, it is a bit of work :-) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2020
Hello everyone, in 2019 I mostly focused on one project in particular and did not much else besides that. That lead to stalling on some of my pet projects. So for 2020 I plan on picking these up again (if time permits): * Enabling USB Audio Class1/2 support (since having the dde_bsd sources up to date making uaudio.c work should just be a matter of porting™). * Revive my cmus port including the minimal OSSv4 VFS plugin used in as backend in cmus I did back in November 2018. * Revive the lynx port (now that the libc is up the task). * Porting Netsurf (I already started at last years hack'n hike but did not get far). * Finish writing a lwext4 VFS plugin. I'm not sure how those fit into the overall roadmap but I'd already be happy enough if I manage to squeeze them into my personal time table. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: pre 19.05 feedback: libc port update breaks mkfs from e2fsprogs
Hello Pirmin, > mkfs.run from > https://github.com/trimpim/genode/tree/test-19.05-mkfs_fails fails with > the error message (KERNEL=nova): > "/dev/block: Memory allocation failed while setting up superblock". > > Through bisecting I determined, that the libc port update seems to be > the cause of the problem. > > a55af1828 last working commit > dd5aa1748 .. 057a8b0b3 build fails > 132ef4dcb compiles, test fails > > The error occurs in line 76 in the file > src/noux-pkg/e2fsprogs/lib/ext2fs/inline.c of the contrib code. Thanks for the report, we will look into it. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Community feature requests and bounties
Hi, thanks for putting this idea forward. > Just as a small start I've made a collection of notes using a > collaborative editor which I will dump project ideas into. Anyone > with the link can add notes, please try not to remove any notes that > are not yours. Its not going to scale, but its better than nothing. > > https://cryptpad.fr/kanban/#/2/kanban/edit/EDK5dT4S49OJeIUW3VqO5y9j/ > > Its some pretty heavy javascript, but I trust the developers not to > include any (stupid) external scripts. A central place to collect ideas is a good idea (I already have my own list [1] that I'll merge to the cryptpad) as a broader audience can see what is of interest and can express their own needs and desires. It stands to reason if more structure is needed long term but we are not their yet anyway. [1] https://usr.sysret.de/jws/genode/ideas.html Regarding your initial posting, having bounties would be nice too. Judging by my (limited) past experience, it is difficult to handle them well (speaking from on origanizational point of view and from putting a price-tag on things (if we talk about paid-for work)). That being said, I think having some means to prioritize “pet-projects” is certainly of value and at the same time having topics available that might poke the interest of newcomers (especially along the lines of mentoring new contributors). Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: CLI Tools and Applications
Hello Joel, > I like using all sorts of CLI programs on my GNU/Linux machines. How > far away are we from being able to run simple programs like Mutt and > Newsboat within a noux instance? Actually, we already have been at this point for few years now but for better or worse we did not make it much of a priority to work out all the remaining kinks. FWIW, there is my [1] branch which contains mutt but lies dormant for a while now - if you would like to resume the porting or rather integration effort please get in touch with me, I'm happy to help. [1] https://github.com/cnuke/genode/commits/noux_email Most of the time CLI tools just-work™ but sooner or later one stumples upon short-comings of our libc or terminal backend implementation. That being said, since there is increasing demand for using known CLI tools on Genode, we plan to spend more time on making it easier to port/build the programs by using the SDK. (On this note, we also plan to consolidate the libc and Noux as the only reason this somewhat artificial split still exists is because it provides simpler means to implement 'fork()'.) Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Debian download not working for me
> Please make sure that you use the current version, i.e. 19.03-p3. Sorry, make that '19.03-p1'. -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Debian download not working for me
Hello Joel, > When I start download_debian, nothing happens. Is anyone else experiencing > this? Please make sure that you use the current version, i.e. 19.03-p3. That being said, sometimes fetchurl gets stuck (total and now stay at '0.0'). It may help to start the 'download_debian' subsystem multiple times or to wait long enough (it might take a few minutes for the retry timeout to trigger). This is a regression within the current CE release and we will address the issue soon. > How can I manually use my own .iso? One way would be to put the .iso on another Ext2 or FAT32 formatted USB stick and to use 'Inspect' in the leitzentrale to copy the file over. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Problems with some partitions detection/mounting
Hello Valery,
> 1) Sculpt boots (only with x86_32 case, so far) fine until the desktop, it
> detects my Intel Gigabit LAN and Intel wifi just fine, and the network
> interface is up and assigned an IP. Also, it correctly detects the size of
> my 750 GB hard disk (actually, 698 GB, because 1 GB == 1024^3 bytes, not
> 1000^3 bytes). But the Leitzentrale lists only first three partitions, not
> all ones (see the screenshot below).
>
> My hard disk partitioning scheme is the following: [1]. The 1st primary
> partition is a 64 GB FAT32 partition. I tried to use it as a Genode
> partition, but Sculpt has problems mounting it, for some reason. The
> extended partition contains the following logical partitions within it:
>
> 1) a 3 GB HPFS partition with OS/2
> 2) another 3 GB HPFS partition (empty)
> 3) a 420 GB JFS partition, shared by OS/2 and Linux
> 4) 40 GB Linux swap partition
> 5) a 55 GB Linux ext3 partition
> 6) a 10 GB BeFS Haiku partition
> 7) a 90 GB freespace
Could you please give commit [1] a try. It should fix your problem
regarding the missing EBR entries.
[1] https://github.com/cnuke/genode/commit/e95e0d1b747bac1bfc41a7781b
To use it in the Sculpt, please cherry-pick the commit and make the
following changes to _repos/gems/run/sculpt.run_:
build { server/part_block }
append boot_modules { part_block }
Regards
Josef
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: Wish List
Hello Joel, > Is there an existing program/feature request list for Genode? > > What would all of you like to see on the list? In adition to the list already mentioned by Alex, I maintain my own lists ([1], [2]) of potentially interesting stuff to port to or implement for Genode. [1] https://usr.sysret.de/jws/genode/porting_wishlist.html [2] https://usr.sysret.de/jws/genode/ideas.html Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Version release 19.02 fixes my problem :) Leaves me with a question...
Hello Joel, > What should I choose for my File System (Target) for cnuke's Download > Debian procedure? You should choose the 'vm_fs' component because the .iso needs to be located in the VM directory. Using all other file systems will involve moving the .iso file around manually. That being said, I have not tried to run the pkg in the new Sculpt release myself yet - hopefully it will just work™. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Genodians.org BETA is live
Hello Johannes, > Curiosity led me into having a look at the recipes. It is nice to see that somebody took the time and looked at the scenario more closely. > I am a bit puzzled about the '/dev/random' emulation though as I'd > expect that it is accessed by openssl. Is there any reasonable > explanation for this or is it one of the reasons why it is treated as > BETA? Well, it would be one of the reasons indeed - using such high-quality entropy was a reasonable choice during the initial development of the scenario. After all, at this point, the features provided by the TLS stack were not that important and now there are still more pressing issues to resolve (functionality-wise). That being said, it will be changed to use a proper entropy source eventually :-) Regards -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Genodians.org BETA is live
Hello fellow Genodians, as already hinted to by Norman in the roadmap discussion, the Genodian's website [1] is now live. It is a federated microblogging platform operated by Genode Labs and running on a Genode system (it uses base-hw and runs within an KVM-based VM). All recipes needed for building the system image are available in the genodians.org repository [2]. [1] http://genodians.org [2] https://github.com/genodelabs/genodians.org The repository also contains the list of all authors whose content is aggregated and published on the website. For more information, e.g. how to participate, please look into the README file. Since there is probably one or the other rough edge left and we have not yet decided on a plan to replace the self-signed certificate, the current version should be treated as BETA - stuff is allowed to fall off :-). Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: geteuid / getpwnam not implemented
Hello Wouter, * Wouter van Oijen : > I succeeded in building and starting Mosquitto under Genode, but it > fails due to the not-implemented functions geteuid() and getpwnam(). > See log below. Are these functions already implemented somewhere? How > should I continue from here? At least 'getpwnam' got implemented by [1] but you need to configure the libc (please look at the run script included in the commit). Most of the time the user account/identity functions that are used to check various properties in a multi-user system (e.g. to drop priviledges or check for running as root) are of no concern on Genode - after all there is just a single user and the seperation is done at another layer, not the libc. You might have to check what your program expects and how, if necessary, to adapt it. [1] https://github.com/genodelabs/genode/commit/874ba409ca The back end implementation of the libc is located in [2]. [2] repos/libports/src/lib/libc > Also, what does the warning about exec_static_constructors() mean? > > […] Ported software might depend on calling static constructors but we have to make sure to execute the functions at the proper time, i.e., after the component's environment has been completely initialized. For now we do that for every libc based component unconditionally. The dynamic run-time linker, however, will print this diagnostic message in case the binary does not have any static constructors that need to be executed. Regards, -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: First steps with Sculpt on Dell XPS 13
Hello, it would be nice if the users of the Dell XPS could drop me a note (off-list is fine) about the exact configuration of their systems and the state of the support on Genode, i.e. which devices are working or not and other relevent information (like the ACPI issues) so I can add the systems to my HCL. Regards, -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: rump_cgd
Hello Steven, * Steven Harp [2018-09-10 17:30:14 -0500]: > Is rump_cgd (block encrypted devices introduced ~14.05) still > supported/operational in Genode 18.x? Issue #2224 mentions > "not converted" in transition to new base API [1], and #2778 seems > to have removed the 'tool/rump' script (which was handy to > prepare encrypted volumes) [2]. it is neither tested nor actively used, so most likely it will not work properly. That being said, I rather see it removed than being reactivated in the future. Regards, -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Checking WiFi driver
Hello Prakash, * Prakash A [2018-09-06 14:32:48 +0530]: > How to check whether WiFi driver is working or not. I mean what is run > command. There is no specific command to check the state of the wifi_drv. You can execute the 'repos/dde_linux/run/wifi.run' run script for your target machine and check the LOG messages. In case the driver does not find any supported device or if it cannot load the proper firmware image it will print a message and exit. Otherwise it will try to associate with the configured network. You can then check the state by inspecting the 'state' report. You may toggle the 'verbose' and the 'verbose_state' attribute in the 'wifi_config' to show some messages that will tell you what is going within the driver. (The same is true if you are running Sculpt instead of the afore mentioned run script.) Regards, -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Sculpt/wifi_drv regression: no IP address
Hello Ben,
* Nobody III [2018-08-30 23:38:47 -0600]:
> I updated to the 18.08 Genode release, built a Sculpt image, then booted it
> on my Dell Latitude 6430u laptop. I discovered that the WiFi driver, which
> worked in 18.05 (Sculpt TC) no longer works properly. In particular, the
> WiFi driver detects the access points and can connect to them, but doesn't
> get an IP address. I tried multiple access points, both my wireless router
> and my phone. With my phone, I used a clean lowercase alphabetic SSID
> ("bensphone"), to avoid any issues with problematic characters. I am using
> an Intel Ultimate-N 6300 wireless card.. Wired networking still works.
as noted in the release notes, support for 6000er cards has regressed with
the new driver. The cause is still unknown and we are working on a fix.
(It looks like some kind of race or timing issue as most of the time the
packets submitted to the firmware are not acknowledged but sometimes it
works just fine and the behaviour is influenced by debug messages.)
Regards,
--
Josef Söntgen
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
Re: Sculpt TC - Error Building "image/disk"
Hello John, * John J. Karcher [2018-06-05 18:55:48 -0400]: > Run script aborted because gdisk is not installed > Makefile:312: recipe for target 'run/sculpt' failed > make: *** [run/sculpt] Error 1 > > In fact, "gdisk" is installed, but it doesn't run under a normal user. I > could hack the scripts to use "sudo", but I thought I'd check here first, in > case there is a simple solution (since Ubuntu and Debian usually operate > similarly). Please check if '/sbin' is included in your $PATH variable. There are distros, e.g. Debian, which do not set the common 'sbin' paths in the shell when executed as non-root user. This issue comes up now and then but so far we have not decided on how - and if at all - to solve it. Personally, I always set the PATH variable myself so no suprises there. Regards, Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
