USB device mode by default?

[po1]

Hi,

I built my own 4.2-based kernel from the linaro tree, and I am having issues with the USB controller.
At boot time, it looks like the board is in device mode.
I can load a gadget driver like g_mass_storage and plug the board to a computer and use it as such, but I can not run lsusb, it fails with error -99.

Once I unplug the micro USB cable, though, the host controller is detected by the kernel, and everything starts working fine.

Here are my steps:

0. boot board with nothing plugged in (except the power cord)
1. host USB doesn’t work
2. connect micro USB to board and plug into a host
3. unplug the micro USB cable
4. host USB works

I tried playing with the ‘USB HOST’ switch on the board, but it didn’t change anything.

Did I miss anything somewhere?

Thanks,
Paul

[anon91830841]

hi,

if you boot with nothing plugged in, then it should default to USB HOST. So HOST should work. At least this is how it is supposed to be, and I just checked on my board, and it worked. So let me ask a few questions:

1. how did you setup the board initially after you got it? SD install image, fastboot?
2. did you install/flash the bootloaders?
3. which kernel commit/tag are you building, and which kernel config are you using?
4. have you tried the same with the released boot image, instead of your own built kernel?

cheers

[po1]

1. how did you setup the board initially after you got it? SD install image, fastboot?

I always use fastboot to program the board. I make a boot image with 'skales' and flash it to the 'boot' partition.

2. did you install/flash the bootloaders?

Yes, I flashed a new gpt to replace the android partitions with a 'rootfs'. The bootloader that I flashed came from eInfochips, who also manufacture a snapdragon 410 board.

3. which kernel commit/tag are you building, and which kernel config are you using?

I started off the 'integration-linux-qcomlt' branch from https://git.linaro.org/landing-teams/working/qualcomm/kernel.git, and I merged it with the 'v4.3' tag from Linus' tree. I realized then that the wifi wasn't working and I made a small modification to the device tree from a partial patch from Fengwei Yin:

--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -400,8 +400,7 @@
 				qcom,smd-edge = <6>;
 				qcom,remote-pid = <4>;
 
-#if 0
-				bt {
+                               bt {
 					compatible = "qcom,hci-smd";
 					qcom,smd-channels = "APPS_RIVA_BT_CMD", "APPS_RIVA_BT_ACL";
 					qcom,smd-channel-names = "event", "data";
@@ -413,7 +412,7 @@
 				};
 
 				wifi {
-					compatible = "qcom,wcn3680";
+					compatible = "qcom,wlan-ctrl";
 					qcom,smd-channels = "WLAN_CTRL";
 
 					interrupts = <0 145 0>, <0 146 0>;
@@ -421,8 +420,8 @@
 
 					qcom,wcnss_mmio = <0xfb000000 0x21b000>;
 
-					qcom,tx-enable-gpios = <&apps_smsm 10 0>;
-					qcom,tx-rings-empty-gpios = <&apps_smsm 9 0>;
+					// qcom,tx-enable-gpios = <&apps_smsm 10 0>;
+					// qcom,tx-rings-empty-gpios = <&apps_smsm 9 0>;
 				};
 
 				wcnss_ctrl {
@@ -431,7 +430,6 @@
 
 					qcom,wcnss_mmio = <0xfb21b000 0x3000>;
 				};
-#endif
 			};
 		};
 
@@ -937,7 +935,7 @@
 			};
 		};
 
-		pronto_rproc {
+		pronto_rproc: pronto_rproc {
 			compatible = "qcom,tz-pil";
 
 			interrupts-extended = <&intc 0 149 1>,
@@ -970,6 +968,61 @@
 
 			memory-region = <&peripheral_mem>;
 		};
+
+                qcom,wcn36xx@0a000000 {
+                        compatible = "qcom,wcn3620";
+                        reg = <0x0a000000 0x280000>,
+                                <0xb011008 0x04>,
+                                <0x0a21b000 0x3000>,
+                                <0x03204000 0x00000100>,
+                                <0x03200800 0x00000200>,
+                                <0x0A100400 0x00000200>,
+                                <0x0A205050 0x00000200>,
+                                <0x0A219000 0x00000020>,
+                                <0x0A080488 0x00000008>,
+                                <0x0A080fb0 0x00000008>,
+                                <0x0A08040c 0x00000008>,
+                                <0x0A0120a8 0x00000008>,
+                                <0x0A012448 0x00000008>,
+                                <0x0A080c00 0x00000001>;
+
+                        reg-names = "wcnss_mmio", "wcnss_fiq",
+                                    "pronto_phy_base", "riva_phy_base",
+                                    "riva_ccu_base", "pronto_a2xb_base",
+                                    "pronto_ccpu_base", "pronto_saw2_base",
+                                    "wlan_tx_phy_aborts","wlan_brdg_err_source",
+                                    "wlan_tx_status", "alarms_txctl",
+                                    "alarms_tactl", "pronto_mcu_base";
+
+                        interrupts = <0 145 0 0 146 0>;
+                        interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq";
+
+                        // qcom,pronto-vddmx-supply = <&pm8916_l3>;
+                        // qcom,pronto-vddcx-supply = <&pm8916_s1_corner>;
+                        // qcom,pronto-vddpx-supply = <&pm8916_l7>;
+                        // qcom,iris-vddxo-supply   = <&pm8916_l7>;
+                        // qcom,iris-vddrfa-supply  = <&pm8916_s3>;
+                        // qcom,iris-vddpa-supply   = <&pm8916_l9>;
+                        // qcom,iris-vdddig-supply  = <&pm8916_l5>;
+
+                        pinctrl-names = "wcnss_default";
+                        // pinctrl-names = "wcnss_default", "wcnss_sleep",
+                        //                                "wcnss_gpio_default";
+                        pinctrl-0 = <&wcnss_default>;
+                        // pinctrl-1 = <&wcnss_sleep>;
+                        // pinctrl-2 = <&wcnss_gpio_default>;
+
+                        // clocks = <&rpmcc RPM_XO_CLK_SRC>,
+                        //         <&rpmcc RPM_RF_CLK2>;
+                        //clock-names = "xo", "rf_clk";
+
+			rproc = <&pronto_rproc>;
+                        qcom,has-autodetect-xo;
+                        qcom,wlan-rx-buff-count = <512>;
+                        qcom,is-pronto-vt;
+                        qcom,has-pronto-hw;
+                        // qcom,wcnss-adc_tm = <&pm8916_adc_tm>;
+                };
 	};
 };
 
-- 

I used the arm64 defconfig, and I removed some graphical drivers since my setup is headless.

4. have you tried the same with the released boot image, instead of your own built kernel?

I don’t remember where I got it from, but I have a working 4.2 boot image, with both wifi and USB working properly, so yes, there seems to be something wrong with my setup, I just would like to know what, since I would prefer to be able to build custom kernels.

Thanks for the help!
Paul

[anon91830841]

hi,

the integration branch that you are using, is our ‘development’ branch. It is not stable, it is rebased every other week, it has issues ‘by design’. Once a new kernel is released (from Linus) we freeze the integration branch into the ‘next release’ branch, and it is stabilized. The integration branch is the merge of all the developers branches along with all the patches from mailing list that we care. When a series is updated on the list, we try to update (rebase) the integration branch.

so your problem is that the USB HOST/device is currently broken in the integration branch, thanks for all the details.

One main difference with the integration branch is that it’s always based on the latest kernel -rc release (worst case is 1 to 3 weeks old kernel…) … however one drawback is that we don’t do much testing on this branch (but we want developer to help of course!), and there are features that we don’t merge there (like wifi for example, and a few others).

If all you need is to be able to rebuild/customize your kernel, and that you don’t really need the very latest kernel tag, I would suggest you use the release branch instead. In each release note you will find the kernel tag that was used for this release, and how to build it. In general if the release comes with a x.y[.z] kernel version, it is safe to checkout the branch release/qcomlt-x.y in our tree.

would that work for you?

[po1]

Sure, that would work. I don’t really need the bleeding edge, but I was eager to see if there was a version of the kernel that could work on top of the latest kernel release.

I will spend a few more cycles trying to gather more data on why the USB is broken.
Is there a good place for me to report my findings?
Would the patch to fix the wifi on the integration branch be of any use?

[po1]

Also, the following wiki page links to the integration branch to build custom kernels: https://github.com/96boards/documentation/wiki/Dragonboard-410c-Boot-Image

Maybe correct it to point to a release tag?

[anon91830841]

• if you have more data for USB, let us know. we will fix it anyways when we start the next release branch… so if you beat us on it, good for us.

• for the WLAN patch, that’s ok, we know about it, and it’s trivial to fix. so far we had decided not to have WLAN in the integration because the code wasn’t ready. We decided recently that we will add it now… so we will fix it, don’t worry about this one.

• if you find bugs, you can use the forum, but even better you can report them on our bugzilla https://bugs.96boards.org/. and if you have patches/comments they can go there too.

• for the wiki link… you’re right… and actually I wrote this wiki it has caused more confusion that help… I had already thought I would remove the first section. I will do it now. This wiki is really here to explain how to post process the kernel image with skales tools. We shouldn’t mention the integration branch here, but just assumes that if you read this wiki, you’ve already built your kernel. I will fix the wiki.