Hello all,
It has taken a lot longer than I hoped initially, but I have some progress to report on the USB driver port for the USB armory.
The current state is that the controller bringup looks like it *does something* but the functionality (and device hotplugging) does not work.
My current code is in here: https://github.com/vladimir-lu/genode/tree/issue/imx53_usb_host_staging
As I mentioned, upon hotplugging a device (tested with a memory stick and of course the official host adapter) - there seems to be no log activity, but when the memory stick is plugged in from boot time it at least recognises that there is something connected to the port. The two log files are here: https://gist.github.com/anonymous/101496bdfb266b460e51
The relevant line in the log is: [init -> usb_drv] dev_dbg: state 7 ports 1 chg 0002 evt 0000
vs (in the non-recognised case) [init -> usb_drv] dev_dbg: state 7 ports 1 chg 0000 evt 0000
I do not have any good ideas at the moment where to go next with debugging this problem - can anyone suggest places to look?
I guessed that the issue is in the clock setup, but writing to the Usboh3_60M and Usbphy1 in Ccgr2 and Ccgr4 respectively does not seem to make any difference. The usb phy has no tranceiver on this platform so does not need enabling. The OTG port is being used for host mode.
As you may notice, the platform.cc now contains a few header definitions + functions that I copy+pasted from the wifi driver but did not want to put in lx_emul.cc - is that correct or should I just stick them in linux_emul.cc for all to use?
I have also run the input-test and that does not print any events received. One interesting line comes out after a few seconds however:
[init -> usb_drv] dev_dbg: debounce: port 1: total 2000ms stable 0ms status 0x401
I want to get host mode working before I start with the OTG + gadget porting (there is some diff primarily in the OTG stuff between 3.14.5 and 4.0 so I am not sure how much of 3.14.5 will actually "work" without getting a 3.14.5 kernel running on the armory first...)
Kind regards, Vladimir
Hi Vladimir,
good to see that you made some progress.
On 07/13/2015 12:57 AM, Vladimir Lushnikov wrote:
Hello all,
It has taken a lot longer than I hoped initially, but I have some progress to report on the USB driver port for the USB armory.
The current state is that the controller bringup looks like it *does something* but the functionality (and device hotplugging) does not work.
My current code is in here: https://github.com/vladimir-lu/genode/tree/issue/imx53_usb_host_staging
As I mentioned, upon hotplugging a device (tested with a memory stick and of course the official host adapter) - there seems to be no log activity, but when the memory stick is plugged in from boot time it at least recognises that there is something connected to the port. The two log files are here: https://gist.github.com/anonymous/101496bdfb266b460e51
The relevant line in the log is: [init -> usb_drv] dev_dbg: state 7 ports 1 chg 0002 evt 0000
vs (in the non-recognised case) [init -> usb_drv] dev_dbg: state 7 ports 1 chg 0000 evt 0000
I do not have any good ideas at the moment where to go next with debugging this problem - can anyone suggest places to look?
I guessed that the issue is in the clock setup, but writing to the Usboh3_60M and Usbphy1 in Ccgr2 and Ccgr4 respectively does not seem to make any difference. The usb phy has no tranceiver on this platform so does not need enabling. The OTG port is being used for host mode.
As you may notice, the platform.cc now contains a few header definitions
- functions that I copy+pasted from the wifi driver but did not want to
put in lx_emul.cc - is that correct or should I just stick them in linux_emul.cc for all to use?
I have also run the input-test and that does not print any events received. One interesting line comes out after a few seconds however:
[init -> usb_drv] dev_dbg: debounce: port 1: total 2000ms stable 0ms status 0x401I want to get host mode working before I start with the OTG + gadget porting (there is some diff primarily in the OTG stuff between 3.14.5 and 4.0 so I am not sure how much of 3.14.5 will actually "work" without getting a 3.14.5 kernel running on the armory first...)
Sounds good, if I have some spare time, I will have a look and try your stuff out on the Armory and see what might be the problem. So far your output looks reasonable, the controller receives HUB events and the 'debounce' message is also normal. You could try to enable the 'DEBUG_TRACE' macro in 'lx_emul.h' and look for suspicious dummy functions calls that might be important for the correct functioning of the controller.
Unfortunately some guessing is required when porting Linux code,
Sebastian
-
Sebastian Sumpf -
Vladimir Lushnikov