I'm porting the musb driver code from Linux, using the 14.02 release of Genode. Basically, I'm using the main.cc code in dde-linux/src/lib/usb to start the usb subsystem and usb port drivers. The main.cc code is essentially unchanged and the start_usb_driver function is identical to the release code.
When running the executible containing this code a page fault occurs when _run is called in Routine::main(). The reason appears to be the schedule() function returns a pointer to 0x0 it got from _next which was returned from _list. The pointer in in _list appears to have been removed at the start main(). It looks to me like the code in main.cc in src/lib/usb would fail for any usb driver code. What am I missing?
Thanks, Bob Stewart
On 04/02/2014 10:40 AM, Bob Stewart wrote:
I'm porting the musb driver code from Linux, using the 14.02 release of Genode. Basically, I'm using the main.cc code in dde-linux/src/lib/usb to start the usb subsystem and usb port drivers. The main.cc code is essentially unchanged and the start_usb_driver function is identical to the release code.
When running the executible containing this code a page fault occurs when _run is called in Routine::main(). The reason appears to be the schedule() function returns a pointer to 0x0 it got from _next which was returned from _list. The pointer in in _list appears to have been removed at the start main(). It looks to me like the code in main.cc in src/lib/usb would fail for any usb driver code. What am I missing?
Thanks, Bob Stewart
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Appears to be related to not including a call to subsys_usb_init() which I had commented out inadvertently. Not sure why that is the case but I'll figure it out. With that call included, main() now runs as expected.
Thanks, Bob Stewart
Hi Bob,
On 04/02/2014 06:15 PM, Bob Stewart wrote:
On 04/02/2014 10:40 AM, Bob Stewart wrote:
I'm porting the musb driver code from Linux, using the 14.02 release of Genode. Basically, I'm using the main.cc code in dde-linux/src/lib/usb to start the usb subsystem and usb port drivers. The main.cc code is essentially unchanged and the start_usb_driver function is identical to the release code.
When running the executible containing this code a page fault occurs when _run is called in Routine::main(). The reason appears to be the schedule() function returns a pointer to 0x0 it got from _next which was returned from _list. The pointer in in _list appears to have been removed at the start main(). It looks to me like the code in main.cc in src/lib/usb would fail for any usb driver code. What am I missing?
Thanks, Bob Stewart
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Appears to be related to not including a call to subsys_usb_init() which I had commented out inadvertently. Not sure why that is the case but I'll figure it out. With that call included, main() now runs as expected.
The 'Routine' code resembles a sort of user-level threading. Each Linux thread will get a stack there and scheduling is done by performing setjmp/longjmp calls. To bootstrap this scenario the USB main thread is added as a routine during startup, it calls all the initialization functions, which in turn might create new Linux threads (that become routines in the end). For USB controllers Linux creates at least the HUB thread (see: contrib/drivers/usb/core/hub.c). After initialization we don't need the main thread anymore, since it does not perform any Linux driver related work, so it is removed from the routine list. By not calling 'subsys_usb_init', the HUB thread will not be created, causing the thread list in routine to be empty, which it cannot handle right now, hence the page fault. The whole purpose of this scheme is to avoid races and only schedule Linux threads a well defined points, like 'wait_for_completion', have a look at 'src/lib/usb/signal/events.cc' for most points. This way we don't have to deal with Linux's synchronization primitives and all it's pre- and post-conditions.
I hope this clarifies things a little,
Sebastian
Thank you Sebastian for your very clear explanation.
I'm moving forward now into the wonderfull world of platform device initialization.
Bob
Sent from my android device.
-----Original Message----- From: Sebastian Sumpf <Sebastian.Sumpf@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Fri, 04 Apr 2014 12:22 PM Subject: Re: dde-linux, musb driver code page faults in Routine:Main
Hi Bob,
On 04/02/2014 06:15 PM, Bob Stewart wrote:
On 04/02/2014 10:40 AM, Bob Stewart wrote:
I'm porting the musb driver code from Linux, using the 14.02 release of Genode. Basically, I'm using the main.cc code in dde-linux/src/lib/usb to start the usb subsystem and usb port drivers. The main.cc code is essentially unchanged and the start_usb_driver function is identical to the release code.
When running the executible containing this code a page fault occurs when _run is called in Routine::main(). The reason appears to be the schedule() function returns a pointer to 0x0 it got from _next which was returned from _list. The pointer in in _list appears to have been removed at the start main(). It looks to me like the code in main.cc in src/lib/usb would fail for any usb driver code. What am I missing?
Thanks, Bob Stewart
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Appears to be related to not including a call to subsys_usb_init() which I had commented out inadvertently. Not sure why that is the case but I'll figure it out. With that call included, main() now runs as expected.
The 'Routine' code resembles a sort of user-level threading. Each Linux thread will get a stack there and scheduling is done by performing setjmp/longjmp calls. To bootstrap this scenario the USB main thread is added as a routine during startup, it calls all the initialization functions, which in turn might create new Linux threads (that become routines in the end). For USB controllers Linux creates at least the HUB thread (see: contrib/drivers/usb/core/hub.c). After initialization we don't need the main thread anymore, since it does not perform any Linux driver related work, so it is removed from the routine list. By not calling 'subsys_usb_init', the HUB thread will not be created, causing the thread list in routine to be empty, which it cannot handle right now, hence the page fault. The whole purpose of this scheme is to avoid races and only schedule Linux threads a well defined points, like 'wait_for_completion', have a look at 'src/lib/usb/signal/events.cc' for most points. This way we don't have to deal with Linux's synchronization primitives and all it's pre- and post-conditions.
I hope this clarifies things a little,
Sebastian
------------------------------------------------------------------------------ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
On 04/04/2014 06:52 PM, Bob Stewart wrote:
Thank you Sebastian for your very clear explanation.
I'm moving forward now into the wonderfull world of platform device initialization.
Good luck with that one .-) If it's an ARM-SOC, I would try to see if Uboot could do the work for me, otherwise is Linux often the last resort, since hardware manufacturers just love to omit things like PHY-documentation or even clock gates.
Please let me know how things go along for you and as you might know: Contributions are always welcome over here,
Sebastian
The platform I'm currently working with is indeed an ARM SOC, a Beaglebone Black (AM3359) from TI. I've got a base-hw implementation working with UART, DMTIMER, SDCARD, gpio with pin muxing, and PWM working using TI Technical Resource Manual for the AM335x series. The USB documentation in the TRM looks, on the surface, pretty complete, so I'll see how I go, using it for USB. My real goal is to get a complete musb running with dma and gadgets, then port an 802.11 device driver under it. I'll let you kown when I get the musb driver ported, I'm just at the stage of getting the ported musb code to compile and link under the Genode build system, so it will be a while before I get near a robust port.
Thanks, Bob Sent from my android device.
-----Original Message----- From: Sebastian Sumpf <Sebastian.Sumpf@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Fri, 04 Apr 2014 1:54 PM Subject: Re: dde-linux, musb driver code page faults in Routine:Main
On 04/04/2014 06:52 PM, Bob Stewart wrote:
Thank you Sebastian for your very clear explanation.
I'm moving forward now into the wonderfull world of platform device initialization.
Good luck with that one .-) If it's an ARM-SOC, I would try to see if Uboot could do the work for me, otherwise is Linux often the last resort, since hardware manufacturers just love to omit things like PHY-documentation or even clock gates.
Please let me know how things go along for you and as you might know: Contributions are always welcome over here,
Sebastian
------------------------------------------------------------------------------ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Bob Stewart -
Sebastian Sumpf