hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img file i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Hello,
On Wed, Sep 14, 2022 at 03:08:51PM +0530, Divya Sharma wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img file i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
If you do not have the i.MX 8MQ hardware available, you simply cannot execute the image you've mentioned. Alternatively, to execute Genode on Qemu, you can instead use another "board" as target. Currently, we offer "pbxa9" and "virt_qemu_arm_v7a" as boards to target ARM 32-bit, and "virt_qemu_arm_v8a" to target ARM 64-bit on Qemu.
When running make, set the variable:
BOARD=virt_qemu_arm_v8a
instead of:
BOARD=imx8q_evk
Be aware, that you cannot use the following RUN_OPT setting, when not targeting i.MX 8MQ:
RUN_OPT += --include image/imx8mq_mmc
because, this will produce an SD-card image including boot-loader for the i.MX 8MQ board. Just remove the setting from your RUN_OPT variable.
To execute a very simple scenario on Qemu using ARMv8, you can do the following steps within a Genode repository that was freshly checked out:
tool/create_builddir arm_v8a cd build/arm_v8a make run/log BOARD=virt_qemu_arm_v8a KERNEL=hw
I hope this is helpful.
Regards Stefan
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt file but still we are getting error "Board not supported".
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, divyasharma26546@gmail.com wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img file i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Hello,
On Thu, Sep 15, 2022 at 10:45:41PM +0530, Divya Sharma wrote:
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt file but still we are getting error "Board not supported".
Indeed, the support for individual run-scripts might be restricted to certain board/kernel combinations only, e.g., because there is no sufficient driver support available.
Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
Alternatively, you can first investigate interactive run-scripts like the "demo.run" script, which already supports the virt_qemu_arm_v8a platform.
Regards Stefan
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, divyasharma26546@gmail.com wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img file i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello genodians, We are trying to port genode for BOARD=virt_qemu_arm_v8a
So for that we need to change this file
" Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'. "
Can you please explain more about this?
On Tue, 20 Sep, 2022, 7:21 pm Stefan Kalkowski, < stefan.kalkowski@genode-labs.com> wrote:
Hello,
On Thu, Sep 15, 2022 at 10:45:41PM +0530, Divya Sharma wrote:
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt file
but
still we are getting error "Board not supported".
Indeed, the support for individual run-scripts might be restricted to certain board/kernel combinations only, e.g., because there is no sufficient driver support available.
Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
Alternatively, you can first investigate interactive run-scripts like the "demo.run" script, which already supports the virt_qemu_arm_v8a platform.
Regards Stefan
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, divyasharma26546@gmail.com wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img
file
i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello genodians This is continuous from previous mail
I'm fine a lot about virt_qemu in previous mails and any other sources but unable to find proper documentation or anything.
So if anyone suggest anything for virt_qemu for arm that would be great.
Thanks and Regards Divya
On Sat, 1 Oct, 2022, 1:30 pm Divya Sharma, divyasharma26546@gmail.com wrote:
Hello genodians, We are trying to port genode for BOARD=virt_qemu_arm_v8a
So for that we need to change this file
" Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'. "
Can you please explain more about this?
On Tue, 20 Sep, 2022, 7:21 pm Stefan Kalkowski, < stefan.kalkowski@genode-labs.com> wrote:
Hello,
On Thu, Sep 15, 2022 at 10:45:41PM +0530, Divya Sharma wrote:
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt file
but
still we are getting error "Board not supported".
Indeed, the support for individual run-scripts might be restricted to certain board/kernel combinations only, e.g., because there is no sufficient driver support available.
Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
Alternatively, you can first investigate interactive run-scripts like the "demo.run" script, which already supports the virt_qemu_arm_v8a platform.
Regards Stefan
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, <divyasharma26546@gmail.com
wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img
file
i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Divya,
as has been said, the virt_qemu_arm_v8a platform is not supported to run Sculpt yet. Nonetheless, essential drivers that need to be assembled to run Sculpt OS on this platform are already available in Genode. Therefore, it is mostly some integration work necessary, which you would need to do on your own. I'm afraid there is no ready-to-use documentation available to assist you in doing this integration work. However, there are some helpful pointers I can deliver.
First you should read how the process of Sculpt OS image creation works, which is described in Genode release 22.02:
https://genode.org/documentation/release-notes/22.02#Framework_for_special-p...
Second you can have a look at the genode-imx repository from the genodelabs Gitub account. It showcases how to provide a Sculpt OS variant for i.MX 8MQ EVK for instance. Here you might have a look at the driver subsytem in file `sculpt/drivers/imx8q_evk`, which states what drivers are statically started at boot time, and the file `sculpt/default-imx8q_evk.sculpt`, which describes what driver subsystem has to be used, and what packages need to be integrated additionally to the generic ones. To decide how to adapt the driver subsystem for the virt_qemu_armv8a board, you might have a look into the drivers_interactive package for this platform, especially the file: `repos/os/recipes/raw/drivers_interactive-virt_qemu_arm/drivers.config`. It shows which drivers are needed, and how to combine them to drive a graphical user-interface. Persistent storage is not available for this platform, but you won't need it to run Sculpt OS. You can use the RAM filesystem available in Sculpt instead.
As soon as you have a setup that successfully starts the Sculpt OS GUI on top of Qemu, you can extend the sculpt.run script's `nic_drv` procedure to return the right NIC driver's name for the virt_qemu_armv8a board, which is `virtio_mmio_nic` in your case.
Best regards Stefan
On Tue, Oct 04, 2022 at 01:43:15PM +0530, Divya Sharma wrote:
Hello genodians This is continuous from previous mail
I'm fine a lot about virt_qemu in previous mails and any other sources but unable to find proper documentation or anything.
So if anyone suggest anything for virt_qemu for arm that would be great.
Thanks and Regards Divya
On Sat, 1 Oct, 2022, 1:30 pm Divya Sharma, divyasharma26546@gmail.com wrote:
Hello genodians, We are trying to port genode for BOARD=virt_qemu_arm_v8a
So for that we need to change this file
" Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'. "
Can you please explain more about this?
On Tue, 20 Sep, 2022, 7:21 pm Stefan Kalkowski, < stefan.kalkowski@genode-labs.com> wrote:
Hello,
On Thu, Sep 15, 2022 at 10:45:41PM +0530, Divya Sharma wrote:
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt file
but
still we are getting error "Board not supported".
Indeed, the support for individual run-scripts might be restricted to certain board/kernel combinations only, e.g., because there is no sufficient driver support available.
Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
Alternatively, you can first investigate interactive run-scripts like the "demo.run" script, which already supports the virt_qemu_arm_v8a platform.
Regards Stefan
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, <divyasharma26546@gmail.com
wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this img
file
i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported board. (basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Thanks a lot Stefan for your explanation about the driver configuration. I followed your roadmap and tried to configure the drivers with help of the driver subsystem file that you mentioned for virt_qemu_arm_v8a platform and generated the image.elf at / *genode/build/arm_v8a/var/run/sculpt/boot/image.elf.* While executing it to get the gui on QEMU i got the following error message.
Maybe I did something wrong in the *genode/repos/gems/sculpt/drivers/virt_qemu_arm_v8a* and missed any drivers in the /*genode/repos/gems/sculpt/default-virt_qemu_arm_v8a.sculpt*. Also I am not sure how to write this configuration. Kindly guide me to configure the required drivers to boot the image in qemu.
Regards, Divya.
On Tue, Oct 4, 2022 at 5:27 PM Stefan Kalkowski < stefan.kalkowski@genode-labs.com> wrote:
Hello Divya,
as has been said, the virt_qemu_arm_v8a platform is not supported to run Sculpt yet. Nonetheless, essential drivers that need to be assembled to run Sculpt OS on this platform are already available in Genode. Therefore, it is mostly some integration work necessary, which you would need to do on your own. I'm afraid there is no ready-to-use documentation available to assist you in doing this integration work. However, there are some helpful pointers I can deliver.
First you should read how the process of Sculpt OS image creation works, which is described in Genode release 22.02:
https://genode.org/documentation/release-notes/22.02#Framework_for_special-p...
Second you can have a look at the genode-imx repository from the genodelabs Gitub account. It showcases how to provide a Sculpt OS variant for i.MX 8MQ EVK for instance. Here you might have a look at the driver subsytem in file `sculpt/drivers/imx8q_evk`, which states what drivers are statically started at boot time, and the file `sculpt/default-imx8q_evk.sculpt`, which describes what driver subsystem has to be used, and what packages need to be integrated additionally to the generic ones. To decide how to adapt the driver subsystem for the virt_qemu_armv8a board, you might have a look into the drivers_interactive package for this platform, especially the file: `repos/os/recipes/raw/drivers_interactive-virt_qemu_arm/drivers.config`. It shows which drivers are needed, and how to combine them to drive a graphical user-interface. Persistent storage is not available for this platform, but you won't need it to run Sculpt OS. You can use the RAM filesystem available in Sculpt instead.
As soon as you have a setup that successfully starts the Sculpt OS GUI on top of Qemu, you can extend the sculpt.run script's `nic_drv` procedure to return the right NIC driver's name for the virt_qemu_armv8a board, which is `virtio_mmio_nic` in your case.
Best regards Stefan
On Tue, Oct 04, 2022 at 01:43:15PM +0530, Divya Sharma wrote:
Hello genodians This is continuous from previous mail
I'm fine a lot about virt_qemu in previous mails and any other sources
but
unable to find proper documentation or anything.
So if anyone suggest anything for virt_qemu for arm that would be great.
Thanks and Regards Divya
On Sat, 1 Oct, 2022, 1:30 pm Divya Sharma, divyasharma26546@gmail.com wrote:
Hello genodians, We are trying to port genode for BOARD=virt_qemu_arm_v8a
So for that we need to change this file
" Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
"
Can you please explain more about this?
On Tue, 20 Sep, 2022, 7:21 pm Stefan Kalkowski, < stefan.kalkowski@genode-labs.com> wrote:
Hello,
On Thu, Sep 15, 2022 at 10:45:41PM +0530, Divya Sharma wrote:
Hello genodians,
Based on the suggestion we tried to build sculpt for virt_qemu.
We tried to add support for virt qemu and adding it default.sculpt
file
but
still we are getting error "Board not supported".
Indeed, the support for individual run-scripts might be restricted to certain board/kernel combinations only, e.g., because there is no sufficient driver support available.
Given the sculpt.run script in 'repos/gems/run/', you'll find the restrictions in lines 13-23. Of course you might add the virt_qemu platform here. However, you've to build a proper drivers configuration for sculpt to work on this emulator under 'repos/gems/sculpt/drivers', and a default-virt_qemu_arm_v8a.sculpt file under 'repos/gems/sculpt'.
Alternatively, you can first investigate interactive run-scripts like the "demo.run" script, which already supports the virt_qemu_arm_v8a platform.
Regards Stefan
On Wed, 14 Sep, 2022, 3:08 pm Divya Sharma, <
divyasharma26546@gmail.com
wrote:
hello genodians,
I'm Trying to port Genode OS for i.MX 8MQ boards (arm_v8a). successfully generated .img file but don't know how to run this
img
file
i don't have i.MX board so I have to run on Ubuntu (linux). I have tried qemu emulator but i think qemu doesn't supported
board.
(basically want to run genode os for ARM.)
Please give some guidance on this.
Thanks & Regards
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Divya,
The log file you attached contains nothing substantial because, AFAICT, you have to add LOG=core to your command line:
make run/sculpt_test ... LOG=core
Please consider re-sending the log file with the mentioned option added.
As Stefan already mentioned, Sculpt + ARM + Qemu is not officially supported yet. If this is an alternative for you, Sculpt + Qemu + x86_64 is supported:
./tool/create_builddir x86_64 cd build/x86_64/ sed -i "s/#REP/REP/" etc/build.conf echo "MAKE += -j8" >> etc/build.conf echo "CCACHE := yes" >> etc/build.conf make run/sculpt_test KERNEL=hw BOARD=pc DEPOT=tar LOG=core
Cheers, Martin
On 06.02.23 14:40, Divya Sharma wrote:
Thanks a lot Stefan for your explanation about the driver configuration. I followed your roadmap and tried to configure the drivers with help of the driver subsystem file that you mentioned for virt_qemu_arm_v8a platform and generated the image.elf at /*genode/build/arm_v8a/var/run/sculpt/boot/image.elf.* While executing it to get the gui on QEMU i got the following error message.
Maybe I did something wrong in the *genode/repos/gems/sculpt/drivers/virt_qemu_arm_v8a* and missed any drivers in the /*genode/repos/gems/sculpt/default-virt_qemu_arm_v8a.sculpt*. Also I am not sure how to write this configuration. Kindly guide me to configure the required drivers to boot the image in qemu.
Regards, Divya.
Thanks, martin. I added the mentioned arguments and executed *sudo make run/sculpt_test KERNEL=hw BOARD=virt_qemu_arm_v8a DEPOT=tar LOG=core* The command then got the following log messages on the terminal . After by changing some driver configuration at *genode/repos/gems/sculpt/drivers/virt_qemu_arm_v8a * I got the GUI running the sculpt in QEMU but it still got stuck in the INIT itself and shows the earlier ROM error. and also giving some warning like [init -> drivers -> event_filter] Warning: no policy defined for label 'keyboard' [init -> drivers -> event_filter] Warning: no policy defined for label 'mouse' Maybe I missed some driver configuration and because of that I am not able to do anything with the keyboard and mouse (like moving the cursor pointer and selecting the menus )in the running image in QEMU. Kindly help me to figure it out.
Coming to execution of arm image in QEMU it is said that the virt_qemu_arm_v8a platform is not supported to run Sculpt yet. But we can use the Alternatively, to execute Genode on Qemu, you can instead use another "board" as target. Currently, "pbxa9" and "virt_qemu_arm_v7a" as boards to target ARM 32-bit, and "virt_qemu_arm_v8a" to target ARM 64-bit on Qemu and that is what i am trying. If I am going the wrong way then please guide me on that.
Best......., Divya.
On Mon, Feb 6, 2023 at 10:00 PM Martin Stein martin.stein@genode-labs.com wrote:
Hi Divya,
The log file you attached contains nothing substantial because, AFAICT, you have to add LOG=core to your command line:
make run/sculpt_test ... LOG=core
Please consider re-sending the log file with the mentioned option added.
As Stefan already mentioned, Sculpt + ARM + Qemu is not officially supported yet. If this is an alternative for you, Sculpt + Qemu + x86_64 is supported:
./tool/create_builddir x86_64 cd build/x86_64/ sed -i "s/#REP/REP/" etc/build.conf echo "MAKE += -j8" >> etc/build.conf echo "CCACHE := yes" >> etc/build.conf make run/sculpt_test KERNEL=hw BOARD=pc DEPOT=tar LOG=core
Cheers, Martin
On 06.02.23 14:40, Divya Sharma wrote:
Thanks a lot Stefan for your explanation about the driver configuration. I followed your roadmap and tried to configure the drivers with help of the driver subsystem file that you mentioned for virt_qemu_arm_v8a platform and generated the image.elf at /*genode/build/arm_v8a/var/run/sculpt/boot/image.elf.* While executing it to get the gui on QEMU i got the following error
message.
Maybe I did something wrong in the *genode/repos/gems/sculpt/drivers/virt_qemu_arm_v8a* and missed any drivers in
the /*genode/repos/gems/sculpt/default-virt_qemu_arm_v8a.sculpt*.
Also I am not sure how to write this configuration. Kindly guide me to configure the required drivers to boot the image in
qemu.
Regards, Divya.
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Divya,
Your drivers seem to come up fine, but your event filter (the server for filtering and multiplexing your input events) indicates that it cannot accept the sessions that the drivers are trying to create [3] because you didn't configure event_filter appropriately. However, the config for the event_filter is normally created dynamically by the sculpt_manager component. Please run [6] to see where this happens. Together with [1] and [2] you could then fix the event_filter config in the sculpt_manager.
The same way you can find a solution for [4], which is also due to bad event_filter configuration.
Finally, [5] is because you need some server to provide a numlock.remap file to the event_filter. I assume that your drivers config is simply missing the numlock_remap_rom server that you can find, for instance, also in [7].
IMO, you're not going the wrong way. You simply are going a way that is not officially supported yet and therefore needs some effort and insight in order to work ;)
I hope this helps?
Cheers, Martin
[1] repos/os/recipes/raw/drivers_interactive-virt_qemu_arm/event_filter.config
[2] repos/os/src/server/event_filter/README
[3] [init -> drivers -> event_filter] Warning: no policy defined for label 'keyboard' [init -> drivers -> event_filter] Warning: no policy defined for label 'mouse'
[4] [init -> drivers -> event_filter] Warning: invalid <output> configuration
[5] [init -> drivers -> event_filter] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="numlock.remap") [init -> drivers -> event_filter] Error: Could not open ROM session for "numlock.remap"
[6] grep -r "event_filter" repos/gems/src/app/sculpt_manager/ [7] repos/allwinner/sculpt/drivers/pinephone
On 07.02.23 10:17, Divya Sharma wrote:
Thanks, martin. I added the mentioned arguments and executed *sudo make run/sculpt_test KERNEL=hw BOARD=virt_qemu_arm_v8a DEPOT=tar LOG=core* The command then got the following log messages on the terminal . After by changing some driver configuration at *genode/repos/gems/sculpt/drivers/virt_qemu_arm_v8a * I got the GUI running the sculpt in QEMU but it still got stuck in the INIT itself and shows the earlier ROM error. and also giving some warning like [init -> drivers -> event_filter] Warning: no policy defined for label 'keyboard' [init -> drivers -> event_filter] Warning: no policy defined for label 'mouse' Maybe I missed some driver configuration and because of that I am not able to do anything with the keyboard and mouse (like moving the cursor pointer and selecting the menus )in the running image in QEMU. Kindly help me to figure it out.
Coming to execution of arm image in QEMU it is said that the virt_qemu_arm_v8a platform is not supported to run Sculpt yet. But we can use the Alternatively, to execute Genode on Qemu, you can instead use another "board" as target. Currently, "pbxa9" and "virt_qemu_arm_v7a" as boards to target ARM 32-bit, and "virt_qemu_arm_v8a" to target ARM 64-bit on Qemu and that is what i am trying. If I am going the wrong way then please guide me on that.
Best......., Divya.
Hi Divya,
As a further notice, there is also the alternative way of providing the event_filter config statically (instead of the dynamic way via the sculpt_manager).
In order for this to work you'd need an individual *.sculpt file for your platform (see [1] and [2] for how this works). In this file you can then reference your static event_filter config file, like it is done in [3] (the corresponding config file is [4]).
Cheers, Martin
[1] repos/gems/run/sculpt.run -> sculpt_path [2] https://genode.org/documentation/release-notes/22.02#Framework_for_special-p... [3] repos/allwinner/sculpt/phone-pinephone.sculpt -> event_filter: phone [4] repos/allwinner/sculpt/event_filter/phone
On 07.02.23 15:15, Martin Stein wrote:
Hi Divya,
Your drivers seem to come up fine, but your event filter (the server for filtering and multiplexing your input events) indicates that it cannot accept the sessions that the drivers are trying to create [3] because you didn't configure event_filter appropriately. However, the config for the event_filter is normally created dynamically by the sculpt_manager component. Please run [6] to see where this happens. Together with [1] and [2] you could then fix the event_filter config in the sculpt_manager.
The same way you can find a solution for [4], which is also due to bad event_filter configuration.
Finally, [5] is because you need some server to provide a numlock.remap file to the event_filter. I assume that your drivers config is simply missing the numlock_remap_rom server that you can find, for instance, also in [7].
IMO, you're not going the wrong way. You simply are going a way that is not officially supported yet and therefore needs some effort and insight in order to work ;)
I hope this helps?
Cheers, Martin
[1] repos/os/recipes/raw/drivers_interactive-virt_qemu_arm/event_filter.config
[2] repos/os/src/server/event_filter/README
[3] [init -> drivers -> event_filter] Warning: no policy defined for label 'keyboard' [init -> drivers -> event_filter] Warning: no policy defined for label 'mouse'
[4] [init -> drivers -> event_filter] Warning: invalid <output> configuration
[5] [init -> drivers -> event_filter] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="numlock.remap") [init -> drivers -> event_filter] Error: Could not open ROM session for "numlock.remap"
[6] grep -r "event_filter" repos/gems/src/app/sculpt_manager/ [7] repos/allwinner/sculpt/drivers/pinephone
hello guys, After many efforts and with your generous help I'm able to build and run sculpt an image for "virt_qemu_arm_v8a". But now I want to enable some driver support in OS like USB,Wifi and Lan-Ethernet. while trying to configure Lan got this error. " Error: nic_drv: environment ROM session denied (label="nic_drv", ram_quota=6144, cap_quota=3, diag=0) "
can you suggest a way to enable mentioned driver support?
On Tue, Feb 7, 2023 at 8:13 PM Martin Stein martin.stein@genode-labs.com wrote:
Hi Divya,
As a further notice, there is also the alternative way of providing the event_filter config statically (instead of the dynamic way via the sculpt_manager).
In order for this to work you'd need an individual *.sculpt file for your platform (see [1] and [2] for how this works). In this file you can then reference your static event_filter config file, like it is done in [3] (the corresponding config file is [4]).
Cheers, Martin
[1] repos/gems/run/sculpt.run -> sculpt_path [2]
https://genode.org/documentation/release-notes/22.02#Framework_for_special-p... [3] repos/allwinner/sculpt/phone-pinephone.sculpt -> event_filter: phone [4] repos/allwinner/sculpt/event_filter/phone
On 07.02.23 15:15, Martin Stein wrote:
Hi Divya,
Your drivers seem to come up fine, but your event filter (the server for filtering and multiplexing your input events) indicates that it cannot accept the sessions that the drivers are trying to create [3] because you didn't configure event_filter appropriately. However, the config for the event_filter is normally created dynamically by the sculpt_manager component. Please run [6] to see where this happens. Together with [1] and [2] you could then fix the event_filter config in the sculpt_manager.
The same way you can find a solution for [4], which is also due to bad event_filter configuration.
Finally, [5] is because you need some server to provide a numlock.remap file to the event_filter. I assume that your drivers config is simply missing the numlock_remap_rom server that you can find, for instance, also in [7].
IMO, you're not going the wrong way. You simply are going a way that is not officially supported yet and therefore needs some effort and insight in order to work ;)
I hope this helps?
Cheers, Martin
[1]
repos/os/recipes/raw/drivers_interactive-virt_qemu_arm/event_filter.config
[2] repos/os/src/server/event_filter/README
[3] [init -> drivers -> event_filter] Warning: no policy defined for label 'keyboard' [init -> drivers -> event_filter] Warning: no policy defined for label 'mouse'
[4] [init -> drivers -> event_filter] Warning: invalid <output> configuration
[5] [init -> drivers -> event_filter] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="numlock.remap") [init -> drivers -> event_filter] Error: Could not open ROM session for "numlock.remap"
[6] grep -r "event_filter" repos/gems/src/app/sculpt_manager/ [7] repos/allwinner/sculpt/drivers/pinephone
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Divya,
AFAIK, only NIC and input are supported currently on virt_qemu in general, but I'm not too much into that topic.
The error you posted is simply saying that the program that prints it (see the label prefix in the log) tries to open an image file named "nic_drv" and that the request was denied by the surrounding system for some reason. I assume that an image file with this name is not present, but without further information about your sculpt setup (package list, sculpt config, etc.), I cannot say for sure.
I just noticed, that the virt qemu NIC driver binary is not named nic_drv but virtio_mmio_nic. Maybe this is it!? Are you using this [1] archive?
If you want to get a better picture of virt_qemu hardware support, I'd suggest you use these commands:
find repos/ -type d -wholename *virtio* grep -r "src/virtio" repos/
I hope that helped?
Cheers, Martin
[1] repos/os/recipes/pkg/drivers_nic-virt_qemu_arm_v8a
On 14.02.23 09:15, Divya Sharma wrote:
hello guys, After many efforts and with your generous help I'm able to build and run sculpt an image for "virt_qemu_arm_v8a". But now I want to enable some driver support in OS like USB,Wifi and Lan-Ethernet. while trying to configure Lan got this error. " Error: nic_drv: environment ROM session denied (label="nic_drv", ram_quota=6144, cap_quota=3, diag=0) "
can you suggest a way to enable mentioned driver support?
Hello,
some reason. I assume that an image file with this name is not present,
but without further information about your sculpt setup (package list, sculpt config, etc.), I cannot say for sure.
I just noticed, that the virt qemu NIC driver binary is not named nic_drv but virtio_mmio_nic. Maybe this is it!? Are you using this [1] archive?
From the log:
ROM: [000000004092e000,0000000040987030) mke2fs ROM: [00000000411cd000,0000000041213918) ncurses.lib.so ROM: [000000004059d000,00000000405fdce8) nic_router <-- no "nic_drv" above ROM: [0000000040e63000,0000000040e64e12) nic_router.xsd ROM: [0000000040cfc000,0000000040d4a428) nitpicker ... ROM: [0000000040119000,00000000401312d0) virtio_mmio_fb_drv ROM: [000000004184d000,0000000041863f70) virtio_mmio_input_drv ROM: [0000000040d4b000,0000000040d68eb0) virtio_mmio_nic <---- ROM: [000000004058a000,000000004058a3fb) virtio_mmio_nic.xsd ROM: [000000004030e000,00000000403460c0) wm
Based on the above snippet I think what Martin says must be the case. When I have wanted to change the drivers in sculpt, I had to edit the sculpt_manager component to launch the component I wanted, using the "binary=" attribute. The Genode team may know a better way though. You may also need to change default routes to services, which you can obtain from a run script that uses virtio_mmio_nic.
Hope it helps!
-CP
Thanks Martin and Colin for your help. I configured the virtio_mmio_nic configuration for virt_qemu_arm_v8a using [1] archive? But after that i got stuck in the error [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="")
Saying that there is no route for Uplink service because I am not able to set up that, I also tried to find those scripts mentioned by Colin but I could not. I also went for the following command to find the routes but I could not find the script that needed the modification.
find repos/ -type d -wholename *virtio* grep -r "src/virtio" repos/
So ,kindly guide me on how to set up the route for the Uplink service and which are those scripts required to be modified for it. route
Best, Divya.
[1] repos/os/recipes/pkg/drivers_nic-virt_qemu_arm_v8a
On Tue, Feb 14, 2023 at 6:38 PM Colin Parker cvparker@gmail.com wrote:
Hello,
some reason. I assume that an image file with this name is not present,
but without further information about your sculpt setup (package list, sculpt config, etc.), I cannot say for sure.
I just noticed, that the virt qemu NIC driver binary is not named nic_drv but virtio_mmio_nic. Maybe this is it!? Are you using this [1] archive?
From the log:
ROM: [000000004092e000,0000000040987030) mke2fs ROM: [00000000411cd000,0000000041213918) ncurses.lib.so ROM: [000000004059d000,00000000405fdce8) nic_router <-- no "nic_drv" above ROM: [0000000040e63000,0000000040e64e12) nic_router.xsd ROM: [0000000040cfc000,0000000040d4a428) nitpicker ... ROM: [0000000040119000,00000000401312d0) virtio_mmio_fb_drv ROM: [000000004184d000,0000000041863f70) virtio_mmio_input_drv ROM: [0000000040d4b000,0000000040d68eb0) virtio_mmio_nic <---- ROM: [000000004058a000,000000004058a3fb) virtio_mmio_nic.xsd ROM: [000000004030e000,00000000403460c0) wm
Based on the above snippet I think what Martin says must be the case. When I have wanted to change the drivers in sculpt, I had to edit the sculpt_manager component to launch the component I wanted, using the "binary=" attribute. The Genode team may know a better way though. You may also need to change default routes to services, which you can obtain from a run script that uses virtio_mmio_nic.
Hope it helps!
-CP
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Divya,
On Sat, Mar 11, 2023 at 6:19 AM Divya Sharma divyasharma26546@gmail.com wrote:
Thanks Martin and Colin for your help. I configured the virtio_mmio_nic configuration for virt_qemu_arm_v8a using [1] archive? But after that i got stuck in the error [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="")
I believe this happens because your [init -> drivers -> virtio_mmio_nic]
driver can't access the Uplink service provided by [init -> runtime -> nic_router]. However, if you look at your log file, there is also a component [init -> runtime -> virtio_mmio_nic]. If you don't launch [init -> drivers -> virtio_mmio_nic] and only launch [init -> runtime -> virtio_mmio_nic], the latter component might be able to find the route to [init -> runtime -> nic_router]. I see that the "drivers" version is getting a MAC address while the "runtime" version is not, possibly this is because the first one to launch claims a resource and prevents the other from accessing it (that's a wild guess though). In my Sculpt system, the net drivers are launched by "runtime" not "drivers", so the routing there should (hopefully) be all set up. Another option might be to provide some routing rule in the "init" component to route Uplink requests from "drivers" to "runtime".
Saying that there is no route for Uplink service because I am not able to set up that, I also tried to find those scripts mentioned by Colin but I could not. I also went for the following command to find the routes but I could not find the script that needed the modification.
I'm not sure it's necessary to do more on this in your configuration, since the component seems to get launched by "runtime" somehow anyway.
Hope it helps.
-CP
As you said i launched only [init -> runtime -> virtio_mmio_nic] component,but still the runtime version is not getting the mac address,as seen in the log ,don't why.Is there anything left for routing the uplink request from nic driver to virtio_mmio_nic.
kindly guide me on it.
Divya.
On Sat, Mar 11, 2023 at 6:48 PM Colin Parker cvparker@gmail.com wrote:
Divya,
On Sat, Mar 11, 2023 at 6:19 AM Divya Sharma divyasharma26546@gmail.com wrote:
Thanks Martin and Colin for your help. I configured the virtio_mmio_nic configuration for virt_qemu_arm_v8a using [1] archive? But after that i got stuck in the error [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="")
I believe this happens because your [init -> drivers -> virtio_mmio_nic]
driver can't access the Uplink service provided by [init -> runtime -> nic_router]. However, if you look at your log file, there is also a component [init -> runtime -> virtio_mmio_nic]. If you don't launch [init -> drivers -> virtio_mmio_nic] and only launch [init -> runtime -> virtio_mmio_nic], the latter component might be able to find the route to [init -> runtime -> nic_router]. I see that the "drivers" version is getting a MAC address while the "runtime" version is not, possibly this is because the first one to launch claims a resource and prevents the other from accessing it (that's a wild guess though). In my Sculpt system, the net drivers are launched by "runtime" not "drivers", so the routing there should (hopefully) be all set up. Another option might be to provide some routing rule in the "init" component to route Uplink requests from "drivers" to "runtime".
Saying that there is no route for Uplink service because I am not able to set up that, I also tried to find those scripts mentioned by Colin but I could not. I also went for the following command to find the routes but I could not find the script that needed the modification.
I'm not sure it's necessary to do more on this in your configuration, since the component seems to get launched by "runtime" somehow anyway.
Hope it helps.
-CP _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Divya,
On 2023-03-15 11:27, Divya Sharma wrote:
As you said i launched only [init -> runtime -> virtio_mmio_nic] component,but still the runtime version is not getting the mac address,as seen in the log ,don't why.Is there anything left for routing the uplink request from nic driver to virtio_mmio_nic.
may [1] be the missing piece of the puzzle?
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
By convention, Sculpt labels the nic driver as "nic_drv". When the sculpt manager generates the <start> node for runtime, it uses this generic name as binary name. Also, the <policy> node generated for the nic router takes this name as key for selecting the network domain.
If the label does not match, the nic router leaves the uplink session unused because it has no matching policy.
To bridge the gap between the generic convention and the platform- specific driver name, the sculpt.run script uses the 'nic_drv' and 'nic_drv_dtb' functions to rewrite the labels for the ROM sessions for the binary and dtb to the corresponding platform-specific names of the ROM modules at core.
Cheers Norman
Thanks Norman for your suggestion. I modified the sculpt.run as you said but still the uplink session is not getting created may be because of the label mismatch.
[init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="") [init -> drivers -> virtio_mmio_nic] Error: Uncaught exception of type 'Genode::Service_denied'
I tried to figure it out by inspecting the run scripts and runtime configuration working behind the scenes but I am not able to provide that route to nic_router.So,Is there anything that needs to be changed in [1] to give the route to the uplink session. Also as you said that by default Sculpt labels the nic driver as "nic_drv" so is there any way to make it to virtio_mmio_nic by modifying these .cc files [2],[3],[4].Maybe i could be wrong for it.
Then kindly guide me towards it. Also i am sharing the modification that i did to scripts.
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [3] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [4] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m...
Best Divya.
On Wed, Mar 15, 2023 at 4:53 PM Norman Feske norman.feske@genode-labs.com wrote:
Hello Divya,
On 2023-03-15 11:27, Divya Sharma wrote:
As you said i launched only [init -> runtime -> virtio_mmio_nic] component,but still the runtime version is not getting the mac address,as seen in the log ,don't why.Is there anything left for routing the uplink request from nic driver to virtio_mmio_nic.
may [1] be the missing piece of the puzzle?
[1]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
By convention, Sculpt labels the nic driver as "nic_drv". When the sculpt manager generates the <start> node for runtime, it uses this generic name as binary name. Also, the <policy> node generated for the nic router takes this name as key for selecting the network domain.
If the label does not match, the nic router leaves the uplink session unused because it has no matching policy.
To bridge the gap between the generic convention and the platform- specific driver name, the sculpt.run script uses the 'nic_drv' and 'nic_drv_dtb' functions to rewrite the labels for the ROM sessions for the binary and dtb to the corresponding platform-specific names of the ROM modules at core.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On Sat, Mar 25, 2023 at 2:28 PM Divya Sharma divyasharma26546@gmail.com wrote:
Thanks Norman for your suggestion. I modified the sculpt.run as you said but still the uplink session is not getting created may be because of the label mismatch.
[init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="") [init -> drivers -> virtio_mmio_nic] Error: Uncaught exception of type 'Genode::Service_denied'
I tried to figure it out by inspecting the run scripts and runtime configuration working behind the scenes but I am not able to provide that route to nic_router.So,Is there anything that needs to be changed in [1] to give the route to the uplink session. Also as you said that by default Sculpt labels the nic driver as "nic_drv" so is there any way to make it to virtio_mmio_nic by modifying these .cc files [2],[3],[4].Maybe i could be wrong for it.
Then kindly guide me towards it. Also i am sharing the modification that i did to scripts.
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [3] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [4] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m...
Best Divya.
Dear Norman Feske ,
Is there any way possible to do so then kindly help me with this.
Thanks, Divya,
On Wed, Mar 15, 2023 at 4:53 PM Norman Feske norman.feske@genode-labs.com wrote:
Hello Divya,
On 2023-03-15 11:27, Divya Sharma wrote:
As you said i launched only [init -> runtime -> virtio_mmio_nic] component,but still the runtime version is not getting the mac address,as seen in the log ,don't why.Is there anything left for
routing
the uplink request from nic driver to virtio_mmio_nic.
may [1] be the missing piece of the puzzle?
[1]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
By convention, Sculpt labels the nic driver as "nic_drv". When the sculpt manager generates the <start> node for runtime, it uses this generic name as binary name. Also, the <policy> node generated for the nic router takes this name as key for selecting the network domain.
If the label does not match, the nic router leaves the uplink session unused because it has no matching policy.
To bridge the gap between the generic convention and the platform- specific driver name, the sculpt.run script uses the 'nic_drv' and 'nic_drv_dtb' functions to rewrite the labels for the ROM sessions for the binary and dtb to the corresponding platform-specific names of the ROM modules at core.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Divya,
First of all, I'm not sure whether you see this right: It's not your NIC router that is missing a route but your NIC driver. In Genode NIC drivers are NIC session clients and the NIC router is a NIC session server.
Second, the main problem in your case seems to be that you do the NIC driver deployment different from how it is done normally in Sculpt. You added the NIC driver statically to your "drivers" subsystem. However, normally, the "drivers" subsystem contains only the most essential drivers for bringing Sculpt up and the NIC driver is getting deployed on demand only by the Sculpt manager [1][2] in the "runtime" subsystem (the typical space for user applications).
I'd recommend you to remove the NIC driver <start> node from your "drivers" subsystem and instead let the Sculpt manager do this for you. As far as I can tell you have already achieved the second part. When asked to do so, the Sculpt manager starts the NIC driver with name "nic_drv" which causes the driver to request a binary named "nic_drv" from within "runtime" and as you can see in [3], this is re-routed to the a binary with the name you provide through [4].
So, once you removed your own NIC driver instance from "drivers", network should work when you click on "Wired" in your "Network" menu in Sculpt.
Cheers, Martin
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_m... [3] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [4] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
On 27.03.23 16:32, Divya Sharma wrote:
On Sat, Mar 25, 2023 at 2:28 PM Divya Sharma <divyasharma26546@gmail.com mailto:divyasharma26546@gmail.com> wrote:
Thanks Norman for your suggestion. I modified the sculpt.run as you said but still the uplink session is not getting created may be because of the label mismatch. [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="") [init -> drivers -> virtio_mmio_nic] Error: Uncaught exception of type 'Genode::Service_denied' I tried to figure it out by inspecting the run scripts and runtime configuration working behind the scenes but I am not able to provide that route to nic_router.So,Is there anything that needs to be changed in [1] to give the route to the uplink session. Also as you said that by default Sculpt labels the nic driver as "nic_drv" so is there any way to make it to virtio_mmio_nic by modifying these .cc files [2],[3],[4].Maybe i could be wrong for it. Then kindly guide me towards it. Also i am sharing the modification that i did to scripts. [1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L153 [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_manager/network.cc [3] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_manager/runtime/nic_drv.cc [4]https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/sculpt_manager/runtime/nic_router.cc Best Divya.
Dear Norman Feske , Is there any way possible to do so then kindly help me with this.
Thanks, Divya,
Hello,
I modified the sculpt.run as you said but still the uplink session is not getting created may be because of the label mismatch. [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="") [init -> drivers -> virtio_mmio_nic] Error: Uncaught exception of type 'Genode::Service_denied'
this message tells us that you have added the network driver to the drivers subsystem. It does not belong there. In fact, if you inspect the routing rules for the 'drivers' subsystem [1] in sculpt.run, you will see that the drivers subsystem is not supposed to request any 'Uplink' session. So the driver's attempt to request such a session is denied.
Sculpt hosts the network driver inside the runtime subsystem. The driver is dynamically spawned by the sculpt manager - always named 'nic_drv' - once the user selects 'LAN' in the network dialog. The change in [2] is needed because the executable binary of the driver (as present in core's ROM service) is named differently from 'nic_drv'. With the relabeling in place (see [3]), the runtime subsystem will obtain the 'virtio_mmio_nic' executable binary whenever a ROM named "nic_drv" is requested from within the runtime subsystem.
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [3] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
Regards, Norman
Thanks Norman and Martin for details explanation,
I removed the static drivers configuration rules from drivers subsystem and kept the other scripts(like sculpt.run) as it is modified at [1] and got the following log entries in terminal when clicked on wired in Sculpt.
[init -> runtime] child "nic_drv" [init -> runtime] RAM quota: 20232K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_drv --> [init -> runtime] priority: 2 [init -> runtime] child "nic_router" [init -> runtime] RAM quota: 9992K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_router [init -> runtime] priority: 2 [init -> runtime] provides service Nic [init -> runtime] provides service Uplink
Seeing above logs it seems that nic_drv is not able to load the virtio_mmio_nic(instead ELF binary: nic_drv) ELF binary at runtime and mac address allocation, I don't know why. Also I did further modification [2] [3] to sculpt.run to make it happen which is shown below.
[1] proc nic_drv { } {
if {[have_board pc]} { return ipxe_nic_drv } if {[have_board imx8q_evk]} { return fec_nic_drv } if {[have_board mnt_reform2]} { return fec_nic_drv } if {[have_board virt_qemu_arm_v8a]} { return virtio_mmio_nic } //added binary
return nic_unavailable }
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
[2] proc virtio_mmio_nic { } { // proc nic_drv -->
if {[have_board pc]} { return ipxe_nic_drv } if {[have_board imx8q_evk]} { return fec_nic_drv } if {[have_board mnt_reform2]} { return fec_nic_drv } if {[have_board virt_qemu_arm_v8a]} { return virtio_mmio_nic } //added binary
return nic_unavailable }
[3] <service name="ROM" label="nic_drv"> <parent label="} [virtio_mmio_nic] {"/> </service>
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
still the progress is the same, not able to set up the network in the sculpt . Is there anything else that needs to be taken care of or changed ??
Thanks. DIVYA.
On Tue, Mar 28, 2023 at 3:32 PM Norman Feske norman.feske@genode-labs.com wrote:
Hello,
I modified the sculpt.run as you said but still the uplink session is not getting created may be because of the label mismatch. [init] Warning: drivers: no route to service "Uplink" (label="drivers -> virtio_mmio_nic -> ") [init -> drivers -> virtio_mmio_nic] Error: Uplink-session creation failed (ram_quota=3538944, cap_quota=8, mac_address="52:54:00:12:34:56", tx_buf_size=1638400, rx_buf_size=1638400, label="") [init -> drivers -> virtio_mmio_nic] Error: Uncaught exception of type 'Genode::Service_denied'
this message tells us that you have added the network driver to the drivers subsystem. It does not belong there. In fact, if you inspect the routing rules for the 'drivers' subsystem [1] in sculpt.run, you will see that the drivers subsystem is not supposed to request any 'Uplink' session. So the driver's attempt to request such a session is denied.
Sculpt hosts the network driver inside the runtime subsystem. The driver is dynamically spawned by the sculpt manager - always named 'nic_drv' - once the user selects 'LAN' in the network dialog. The change in [2] is needed because the executable binary of the driver (as present in core's ROM service) is named differently from 'nic_drv'. With the relabeling in place (see [3]), the runtime subsystem will obtain the 'virtio_mmio_nic' executable binary whenever a ROM named "nic_drv" is requested from within the runtime subsystem.
[1]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [3]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
Regards, Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Divya,
On Wed, Mar 29, 2023 at 19:52:03 CEST, Divya Sharma wrote:
[init -> runtime] child "nic_drv" [init -> runtime] RAM quota: 20232K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_drv --> [init -> runtime] priority: 2 [init -> runtime] child "nic_router" [init -> runtime] RAM quota: 9992K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_router [init -> runtime] priority: 2 [init -> runtime] provides service Nic [init -> runtime] provides service Uplink
Seeing above logs it seems that nic_drv is not able to load the virtio_mmio_nic(instead ELF binary: nic_drv) ELF binary at runtime and mac address allocation, I don't know why.
The above messages do not hint any failure, why do you think so? It's more important what happens after the runtime init log these messages. Did you try to enable verbosity in the Virtio driver (see https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/nic/vi... for details)?
Regards
The reason I said that is it is not loading the required ELF binary ( virtio_mmio_nic). Also when i clicked on wired in sculpt there is no mac address initialization i can see into the sculpt. Also i am not able to download and add any components in running sculpt. It is just running in the runtime scenario.Could not figure out what is going on behind the scene , whether virtio_nic_drv is really brought into the network or not.
Best, DIvya.
On Thu, Mar 30, 2023 at 12:44 PM Christian Helmuth < christian.helmuth@genode-labs.com> wrote:
Hello Divya,
On Wed, Mar 29, 2023 at 19:52:03 CEST, Divya Sharma wrote:
[init -> runtime] child "nic_drv" [init -> runtime] RAM quota: 20232K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_drv --> [init -> runtime] priority: 2 [init -> runtime] child "nic_router" [init -> runtime] RAM quota: 9992K [init -> runtime] cap quota: 266 [init -> runtime] ELF binary: nic_router [init -> runtime] priority: 2 [init -> runtime] provides service Nic [init -> runtime] provides service Uplink
Seeing above logs it seems that nic_drv is not able to load the virtio_mmio_nic(instead ELF binary: nic_drv) ELF binary at runtime and
mac
address allocation, I don't know why.
The above messages do not hint any failure, why do you think so? It's more important what happens after the runtime init log these messages. Did you try to enable verbosity in the Virtio driver (see
https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/nic/vi... for details)?
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · https://genodians.org/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users