Odroid C2 hangs booting

matec.89 · Post by **matec.89** » Thu Dec 17, 2020 8:20 pm

Dear,

We are having problems with the Odroid C2 board, which has an eMMC v0.4 installed.
SO: Android 6.0.1.
Kernel: 3.14.29
In the last few days I have noticed that some C2 boards stop working after one or two reboots. I have connected the UART-USB board and I have seen that there are always emmc disk errors like this (attached log):

[ 5.674075@0] aml_sd_emmc_data_thread : 2156
[ 5.674098@0] mmcblk0: response CRC error sending r/w cmd command, card status 0x400900
[ 5.674318@0] [aml_sd_emmc_irq] emmc: response ecc,vstat:0x2400,virqc:3fff

I tried using an eMMC v0.3 and that issue doesn't occur.
If I rewrite the emmc disk, the problem appears again. If I change the disk the problem goes away, so it seems not a C2 board problem. It seems an emmc disks problem!
It happens in a 10% of emmc disks (I'm mounting hundreds of boards) and I'm very worried!

Do you have any information about this? Could you tell me why this problem is caused and how can I solve it?

We are using an eMMC module (orange v0.4) (image attachment)
Is a proper configuration the use of Odroid C2 + eMMC 32GB module v0.4 + Android Marshmallow V3.3?

Best regards.

matec.89 · Post by **matec.89** » Thu Dec 17, 2020 9:24 pm

Another important fact:
We are downloading the Android ISO to configure the ttyS2 and ttyS3 serial ports.
Is there a difference between memory mmc described on the page?

Post by **odroid** » Fri Dec 18, 2020 9:50 am

We've not heard this issue.
I think we released the Orange eMMC module 0.4 almost two years ago but you are the first user who raises the issue.

Anyway, we will try reproducing the issue with random 20~30 Orange eMMC module samples and a few C2 samples early next week.
We will use this latest 6.0.1 OS image for the test with some C2 samples.
https://wiki.odroid.com/odroid-c2/os_im ... allow_v5.8

Update.
We could reproduce the issue

The failure rate was around 4~5%.
We will share a solution by replacing a dtb file soon.
It will be reducing the eMMC clock frequency slightly to improve the stability.

Luke.go · Post by **Luke.go** » Fri Dec 18, 2020 5:54 pm

Please test with the attached dtb files.

First, unzip the meson64_odroidc2.dtb.zip file.
Second, flash this the dtb file by fastboot command.
Instruction -> https://wiki.odroid.com/odroid-c2/softw ... ux_kernel1

Once you confirm the stability, we will release a new image.

matec.89 · Post by **matec.89** » Fri Dec 18, 2020 8:58 pm

Luke.go wrote: ↑
Fri Dec 18, 2020 5:54 pm
Please test with the attached dtb files.

First, unzip the meson64_odroidc2.dtb.zip file.
Second, flash this the dtb file by fastboot command.
Instruction -> https://wiki.odroid.com/odroid-c2/softw ... ux_kernel1

Once you confirm the stability, we will release a new image.

Thansks a lot! This dtb have a ttyS2 asnd ttyS3 serial port?
I will be testing, and I confirm

matec.89 · Post by **matec.89** » Sat Dec 19, 2020 3:43 am

odroid wrote: ↑
Fri Dec 18, 2020 9:50 am
We've not heard this issue.
I think we released the Orange eMMC module 0.4 almost two years ago but you are the first user who raises the issue.

Anyway, we will try reproducing the issue with random 20~30 Orange eMMC module samples and a few C2 samples early next week.
We will use this latest 6.0.1 OS image for the test with some C2 samples.
https://wiki.odroid.com/odroid-c2/os_im ... allow_v5.8

Update.
We could reproduce the issue
The failure rate was around 4~5%.
We will share a solution by replacing a dtb file soon.
It will be reducing the eMMC clock frequency slightly to improve the stability.

I tried the Android v5.8 image, with the .dtb sent by @ Luke.go and the truth is that I could not reproduce the problem, since I need if or if the ports ttyS2 and ttyS3 are enabled, and they are not.
I would need them to tell me from where I can download the .dtb necessary to have these two ports enabled, or from where I can download all the source files to be able to modify the .dts and compile the file I need.

Thanks

Luke.go · Post by **Luke.go** » Mon Dec 21, 2020 9:08 am

Please check the wiki page.

https://wiki.odroid.com/odroid-c2/appli ... /gpio/uart

matec.89 · Post by **matec.89** » Mon Dec 21, 2020 10:14 am

Luke.go wrote: ↑
Mon Dec 21, 2020 9:08 am
Please check the wiki page.
https://wiki.odroid.com/odroid-c2/appli ... /gpio/uart

But doing for that I need to download all the sources.
This change that happened in the dtb file, would it be inside the dtb file that I generated?

I understand that the .dtb they gave me has a modification in the frequency of work of the eMMC, and that this modification is not available in git.

Luke.go · Post by **Luke.go** » Mon Dec 21, 2020 11:50 am

matec.89 wrote: ↑
Mon Dec 21, 2020 10:14 am

Luke.go wrote: ↑
Mon Dec 21, 2020 9:08 am
Please check the wiki page.
https://wiki.odroid.com/odroid-c2/appli ... /gpio/uart
But doing for that I need to download all the sources.
This change that happened in the dtb file, would it be inside the dtb file that I generated?

I understand that the .dtb they gave me has a modification in the frequency of work of the eMMC, and that this modification is not available in git.

You just need to download the linux kernel, not all of the sources.

Please download the linux kernel and change the branch to the c2 android's.
And modify the dts file. reference is wiki page the above.

Code: Select all

make odroidc2_defconfig
make dabs
fastboot flash dtb arch/arm64/boot/dts/meson64_odroidc2.dtb

matec.89 · Post by **matec.89** » Mon Dec 21, 2020 11:57 am

Luke.go wrote: ↑
Mon Dec 21, 2020 11:50 am

matec.89 wrote: ↑
Mon Dec 21, 2020 10:14 am

Luke.go wrote: ↑
Mon Dec 21, 2020 9:08 am
Please check the wiki page.
https://wiki.odroid.com/odroid-c2/appli ... /gpio/uart
But doing for that I need to download all the sources.
This change that happened in the dtb file, would it be inside the dtb file that I generated?

I understand that the .dtb they gave me has a modification in the frequency of work of the eMMC, and that this modification is not available in git.
You just need to download the linux kernel, not all of the sources.
Please download the linux kernel and change the branch to the c2 android's.
And modify the dts file. reference is wiki page the above.
Code: Select all
make odroidc2_defconfig
make dabs
fastboot flash dtb arch/arm64/boot/dts/meson64_odroidc2.dtb

Okay!
So in the image of Android v5.8 is the modification on the working frequency of the memory already found?

Post by **odroid** » Mon Dec 21, 2020 12:06 pm

Let's separate two issues and focus on the eMMC stability first.
Can you please confirm the new DTB solved "Odroid C2 hangs booting" problem for all the problematic eMMC/C2 boards?
If yes, we will make a new version v5.9 soon.

After that, we will help you to enable the extra UART ports.

matec.89 · Post by **matec.89** » Mon Dec 21, 2020 12:13 pm

odroid wrote: ↑
Mon Dec 21, 2020 12:06 pm
Let's separate two issues and focus on the eMMC stability first.
Can you please confirm the new DTB solved "Odroid C2 hangs booting" problem for all the problematic eMMC/C2 boards?
If yes, we will make a new version v5.9 soon.

After that, we will help you to enable the extra UART ports.

As I mentioned earlier, I need the serial ports enabled in order to try to reproduce the eMMC boot problem (the installed app, with which I was able to detect the bug, needs those ports enabled)
If they confirm that by downloading the kernel and modifying the dts this update is done, I modify it and test it.

Luke.go · Post by **Luke.go** » Mon Dec 21, 2020 3:19 pm

Please apply attachments.

This patch will be applied to our github linux repository.

matec.89 · Post by **matec.89** » Tue Dec 22, 2020 2:40 am

Luke.go wrote: ↑
Mon Dec 21, 2020 3:19 pm
Please apply attachments.

This patch will be applied to our github linux repository.

Hello!
I was able to modify the dts to be able to generate the dtb.
These days I will be testing it and confirm if it is resolved

matec.89 · Post by **matec.89** » Wed Dec 30, 2020 1:21 am

Dear,
I hope they are well.
I am having a problem with Odroid C2 (with Android 6.01 - v5.8) and UV7 Plus display.
Indeterminately turns off and on (with the black background on) the screen. But the touch continues to work, since when the image of my application reappears, I see the change of the selected option

Inside the app "Odroid Utility" it is configured with a resolution of 1024x600 at 60Hz.
And I notice that in the boot.ini file, set setenv vout_mode "hdmi".
I also tried another updated board (Android M v5.8) by setting the display to vout_mode "dvi" and display resolution "VU7 Plus", and then you will see several attempts the same thing happened.

What is the difference between setting the display with the screen resolution and setting it with the display name?
What is the difference between HDMI and DVI settings?

It should be clarified that before the modification in the Image (v3.3) this problem, I cannot reproduce it
How can I solve this problem?

Post by **odroid** » Wed Dec 30, 2020 9:31 am

As far as I remember, the old Vu7-Plus model must use 'dvi' mode since it doesn't support sound feature while Vu7A-Plus support the audio output which needs 'hdmi' vout mode.

Anyway, we will try to reproduce the issue.

Luke.go · Post by **Luke.go** » Wed Dec 30, 2020 11:16 am

Can you check vid &pid by "lsusb" command?

And Please get the kernel log via dmesg command.
Let me know the result.

matec.89 · Post by **matec.89** » Wed Dec 30, 2020 8:31 pm

I pass what is requested.
When executing the command "lsusb" it returns the following:

root@odroidc2:/ # lsusb
Bus 001 Device 002: ID 05e3:0610
Bus 002 Device 002: ID 16b4:0705
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002

After being able to reproduce the fault (in an environment at approximately 28 ° C), I connected a keyboard and disconnected and reconnected the display power to be able to export the log.
In the attachment I leave the kernel log of the board that has v5.8 with the serial ports enabled and the eMMC frequency modified as indicated in previous messages.
One detail that I observed, when this happens, is that the two display LEDs (green and red) are on (black screen, photo attached).
As happened with the eMMC frequency, is it possible that the HDMI has a greater frequency (transfer rate / clock / signaling) than the old Android 6.0.1 (v3.3)?

Check that the display model is VU7A Plus (image attached), but looking at the kernel log it shows "dwav_usb_mt 2-1: 1.0: ODROID VU7 Plus MultiTouch (1024x600)"

I'll be waiting for news. Thank you!

Post by **odroid** » Thu Dec 31, 2020 11:59 am

Thank you for capturing the kernel logs. But I couldn't find any clue.

Vu7+ and Vu7A+ are sharing the same touch screen controller, and the VID/PID are identical. You have the latest controller ID and there shouldn't be a problem.
The eMMC host clock frequency must be fully isolated from the HDMI clock generator.
Vu7A+ should work regardless of 'vout' mode settings.
Anyway, we will test the Vu7A+ display and touchscreen functionality early next week again.

Meanwhile, try connecting a separated stable 5V PSU to Vu7A+ via DC input micro-USB port near the headphone jack.
It will narrow down the root causes.

matec.89 · Post by **matec.89** » Fri Jan 01, 2021 12:22 am

odroid wrote: ↑
Thu Dec 31, 2020 11:59 am
Thank you for capturing the kernel logs. But I couldn't find any clue.

Vu7+ and Vu7A+ are sharing the same touch screen controller, and the VID/PID are identical. You have the latest controller ID and there shouldn't be a problem.
The eMMC host clock frequency must be fully isolated from the HDMI clock generator.
Vu7A+ should work regardless of 'vout' mode settings.
Anyway, we will test the Vu7A+ display and touchscreen functionality early next week again.

Meanwhile, try connecting a separated stable 5V PSU to Vu7A+ via DC input micro-USB port near the headphone jack.
It will narrow down the root causes.

I'm not saying that the eMMC depended on or associated with the HDMI frequency, but with the version change made in the operating system, could something have changed in the HDMI working frequency? (since after the version change, they asked me to change the maximum frequency of the eMMC).
I tell you that a test I did was to move the HDMI cable from one side to the other without disconnecting it on a board with Android v5.8 and the red led turns on (as if there were some false contact).
I did the same on another board with Android v3.3, and this does not happen.
I clarify that the green led is always on (in the photo attached to the previous comment it cannot be distinguished)

Next week i'm going to try to do the test, because I don't have a 5V CC source.
In case I can do it, I will give details of the tests carried out.
Thank you and happy new year!

codewalker · Post by **codewalker** » Mon Jan 04, 2021 3:30 pm

Try to this firmware for eMMC issue.
https://dn.odroid.com/S905/Android/ODROID-C2/
https://dn.odroid.com/S905/Android/ODRO ... 133.img.xz
https://dn.odroid.com/S905/Android/ODRO ... er-133.zip

Luke.go · Post by **Luke.go** » Mon Jan 04, 2021 3:45 pm

I have tested vu7a+ with your methods.
But I can't reproduce the problem.
The display was always working.

Please check the J1 pins. If you not removed J1 Jumper, please remove it and try again.
And, According to your log, there may be a bad connection problem. So please change the HDMI cable and try again.

I tested it on the 5.8 and 4.0 . Because I couldn't get the version 3.3

matec.89 · Post by **matec.89** » Tue Jan 05, 2021 3:59 am

Luke.go wrote: ↑
Mon Jan 04, 2021 3:45 pm
I have tested vu7a+ with your methods.
But I can't reproduce the problem.
The display was always working.

Please check the J1 pins. If you not removed J1 Jumper, please remove it and try again.
And, According to your log, there may be a bad connection problem. So please change the HDMI cable and try again.

I tested it on the 5.8 and 4.0 . Because I couldn't get the version 3.3

To connect the HDMI port with the odroid, we are using an HDMI 1.4b cable, HDMI A male to HDMI A male (https://www.qualtekusa.com/product/1721001-03/).
Is there any compatibility difference with the Odroid C2 specification, which says it is HDMI 2.0 4K?

With the HDMI cable that comes with the display, try and the same thing happens. When moved from side to side (from the display connector), the red LED on the display lights up.

Luke.go · Post by **Luke.go** » Tue Jan 05, 2021 9:24 am

No, I don't means change 1.4b to 2.0. Just Try with another cables.

the red LED on the display lights up means, the poor contact.

matec.89 · Post by **matec.89** » Tue Jan 05, 2021 12:34 pm

What other cables? I tried with two 1.4b cables (one of them the short cable that comes with the display and the one I mentioned above) and the other of 2.0 which cannot reproduce the problem, so I ask if it could be something of compatibility.
Any specs other than cable type I need to know?
I have had this problem since last week and I can't find a solution.

Post by **odroid** » Tue Jan 05, 2021 4:40 pm

There is no specific specs. C2 and Vu series display could work with a very old HDMI 1.3 cable.
But, we've seen some HDMI cable manufacturers omitted a couple of wire connections for the EDID or HPD protocol interface.
In that case, automatic resolution detection feature couldn't work properly.

Or, the connectors on the Vu board or cables have poor contact surface due to oxidation or foreign matter on the contact surface..

matec.89 · Post by **matec.89** » Thu Jan 07, 2021 12:59 am

We tried different cables (and bought one to have more variety) and it kept happening that I lost the signal.

Now we are testing the same cables, but the difference is that we glued the cable to the case of the equipment we are developing and the problem could not be reproduced.
Anyway we are going to continue testing, since the "solution" of having to glue the cable is somewhat uncomfortable.

The problem with the eMMC (root of the forum thread) did not occur again.

Post by **odroid** » Thu Jan 07, 2021 11:19 am

matec.89 wrote: ↑
Thu Jan 07, 2021 12:59 am
The problem with the eMMC (root of the forum thread) did not occur again.

Thank you for the confirmation.
We've released a new Android image.
https://wiki.odroid.com/odroid-c2/os_im ... allow_v5.9

matec.89 · Post by **matec.89** » Mon Jan 18, 2021 9:24 pm

odroid wrote: ↑
Thu Jan 07, 2021 11:19 am

matec.89 wrote: ↑
Thu Jan 07, 2021 12:59 am
The problem with the eMMC (root of the forum thread) did not occur again.
Thank you for the confirmation.
We've released a new Android image.
https://wiki.odroid.com/odroid-c2/os_im ... allow_v5.9

Dear,
Going back to testing, I found this in the kernel log, which is emerging from some attempts to turn off and on:

emmc: Card stuck in programming state! __mmc_switch

The operating system does not start, leaving the screen black.
I attach the complete log.

Post by **odroid** » Thu Jan 21, 2021 10:25 am

How frequently have you met the problem?
We couldn't reproduce the issue so far with the lowered eMMC clock speed.

matec.89 · Post by **matec.89** » Thu Jan 21, 2021 8:41 pm

The frequency is 180 MHz, what happened to me to modify a few weeks ago to modify in the dts.

Post by **odroid** » Fri Jan 22, 2021 9:30 am

I meant how many times you met the problem if you booted 20 times.

matec.89 · Post by **matec.89** » Fri Jan 22, 2021 10:23 pm

In about 20 times we were able to reproduce 2 times. It doesn't always happen, it's random.

Otra consulta, ¿cómo puedo restablecer el toque desde el archivo boot.ini? Dado que no funciona repetidamente. Tengo una pantalla VU7 Plus.
I found this thread on the forum (viewtopic.php?t=32763), but when I run it, it doesn't:

root@odroidc2:/data # ./resettouch.sh
: Permission denied can't create /sys/class/gpio/export
: No such file or directoryreate /sys/class/gpio/gpio126/direction
'/resettouch.sh[3]: sleep: syntax error: Invalid argument '1
: No such file or directoryreate /sys/class/gpio/gpio126/value
'/resettouch.sh[5]: sleep: syntax error: Invalid argument '1
: No such file or directoryreate /sys/class/gpio/gpio126/value
1|root@odroidc2:/data # lsusbn
/system/bin/sh: lsusbn: not found
127|root@odroidc2:/data # lsusb
Bus 001 Device 002: ID 05e3:0610
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 16b4:0705

Post by **odroid** » Mon Jan 25, 2021 12:23 pm

The script was made for Linux/Ubuntu.
You needed an Android Super-user permission to access the GPIO on Android.

matec.89 · Post by **matec.89** » Mon Jan 25, 2021 10:06 pm

odroid wrote: ↑
Mon Jan 25, 2021 12:23 pm
The script was made for Linux/Ubuntu.
You needed an Android Super-user permission to access the GPIO on Android.

We have superuser access entering through adb. I need some script like the previous one applied to Android, to be able to reset the touch.
And to be able to solve the problem of turning on the system that I had also consulted.
Thank you

Post by **odroid** » Tue Jan 26, 2021 11:11 am

We will try to find a way to reset the USB chip first.

codewalker · Post by **codewalker** » Tue Jan 26, 2021 2:19 pm

adb shell start usb_reset

Code: Select all

 99 service usb_reset /system/bin/usb_reset.sh
100     class core
101     user root
102     group root
103     disabled
104     oneshot
105 
106 on property:dev.bootcomplete=1
107     start usb_reset
108     start makebootini

matec.89 · Post by **matec.89** » Wed Jan 27, 2021 11:38 pm

matec.89 wrote: ↑
Mon Jan 18, 2021 9:24 pm

odroid wrote: ↑
Thu Jan 07, 2021 11:19 am

matec.89 wrote: ↑
Thu Jan 07, 2021 12:59 am
The problem with the eMMC (root of the forum thread) did not occur again.
Thank you for the confirmation.
We've released a new Android image.
https://wiki.odroid.com/odroid-c2/os_im ... allow_v5.9
Dear,
Going back to testing, I found this in the kernel log, which is emerging from some attempts to turn off and on:

emmc: Card stuck in programming state! __mmc_switch

The operating system does not start, leaving the screen black.
I attach the complete log.

And the topic of the beginning, could you see it?

Post by **odroid** » Tue Feb 02, 2021 5:43 pm

Sorry. I missed this thread.
Still we couldn't reproduce the issue.

BTW, did you figure out the USB hub reset?

matec.89 · Post by **matec.89** » Wed Feb 03, 2021 3:32 am

odroid wrote: ↑
Tue Feb 02, 2021 5:43 pm
Sorry. I missed this thread.
Still we couldn't reproduce the issue.

BTW, did you figure out the USB hub reset?

Yes I tried it.
On an Odroid board, a usb keyboard and mouse were connected to it. After starting, from the app "Terminal" the command was executed as root, and it did not work.
The touch still did not respond.
But it was solved by disconnecting the power cable from the display.

We have problems with the touch screen controller used in VU7A+ display. We want to reset the USB driver, to check if is not the issue related to the "USB Hub IC issue" link https://wiki.odroid.com/odroid-c2/troub ... usb_hub_ic. We are using your Android Marshmallow (v5.9) SO image. When we try to execute the "USB Hub IC reset script" proposed cannot be done. You suggest to run:

echo 126 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio126/direction
sleep 1
echo 0 > /sys/class/gpio/gpio126/value
sleep 1
echo 1 > /sys/class/gpio/gpio126/value
echo 126 > /sys/class/gpio/unexport
sleep 1

But at the line "echo out > /sys/class/gpio/gpio126/direction" we have an error:

root@odroidc2:/ # echo out > /sys/class/gpio/gpio126/direction
/system/bin/sh: can't create /sys/class/gpio/gpio126/direction: No such file or directory

How can access GPIO throught Android shell? How can reset USB hub throught Android shell?
Regards,

sebastianrds · Post by **sebastianrds** » Wed Feb 10, 2021 10:06 am

Hi guys,

We have the same issue with the touch controller. Sometimes, once every ten hard power cycles, the touch controller don't response (it don't work) after boot. We are using Odroid-C2 and VU7A+ with the last Android released image (Android Marshmallow v5.9). Problem also occurs at least with versions 5.7 and 5.8 too. Touchscreen controller seems to be loaded correctly. Comparing logs (dmesg) between good boot (where touch works) and bad boot (where touch don't work) are equal. We have near of our 20 final equipments (first mass production) that show the issue, we are discussing about stop production while solve the issue.

In the topic viewtopic.php?t=20959 (2016) other users describes a similar issue, also HardKernel (through Odroid user) say in a post "We will keep looking this issue. We also could reproduce the issue once when we tried 20 times of hard booting." and suggest a solution that was first remove and then insert a module associated to the touch, but in the current Android release, this module is not present (I think because is other kernel too), so we cannot test with that. In the dmesg (attached) we see that the touch controller is associated to dwav_usb_mt module/service/thread. We are using the OTG USB port at Odroid C2 side to connect with the VU7A+ touch controller, we cannot use other of the USB ports. We have a super stabilized 5.1V up to 3A dedicated power supply for the display and exactly other for the Odroid C2 board, so no voltage/current issue with them. If we disconnect and connect the USB cable, touchscreen starts working properly. The usb_reset.sh (located /system/bin/usb_reset.sh) is not applicable to VU7A+ because doesn't reset the USB, uses other VID/PID of touch and, it's very strange, enables the wlan driver ???

???. Also when we try to use GPIO bit manipulating to reset the OTG power manager device (GPIOAO_5), we cannot do because GPIO filesystem access (on Android) is not working.

We need a solution for this issue, it's very strange that in 5 years it keeps without changes or workarounds. We are trusting in HardKernel boards to use in our equipments, Odroid-C2 is going to be discontinued, so we need to migrate to other board like C4, but if these problems occurs in the C4 board too, we need to considerate other solution like Raspberry.

Please suggest a solution or a workaround for this situation.

Thanks in advance,

Sebastián

Post by **odroid** » Wed Feb 10, 2021 12:58 pm

Sorry for our late response.
We could reproduce the issue of the GPIO permission problem on Android.
After Lunar new year holiday, we will make a functional USB hub reset feature in the next week.

sebastianrds · Post by **sebastianrds** » Wed Feb 10, 2021 1:20 pm

Thanks for the answer, but what about the touchscreen issue. Will it be solved with the USB reset? What will do this reset? A GIOAO_5 pulse to power off then on the USB port or will do other internal routine?

codewalker · Post by **codewalker** » Mon Feb 15, 2021 5:26 pm

Hi, I fixed two problems and uploaded a test version.
You can manually reset the USB hub controller and the Vu7A+/Vu5A+ specific auto-reset function works now.

Code: Select all

Author: Chris <codewalker@hardkernel.com>
Date:   Mon Feb 15 16:51:19 2021 +0900

    ODROID-C2: Fix usb hub reset bug.
    
    Change-Id: I58d1d257970680aa28163f5c0cc6ad705d7a202b

diff --git a/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c b/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
index 1cb9bf60c9d3..ce9bc9f56492 100644
--- a/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
+++ b/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
@@ -1079,6 +1079,8 @@ static int dwc_otg_driver_probe(struct platform_device *pdev)
                                gpiod_direction_output(hub_gd, 0);
                                mdelay(100);
                                gpiod_direction_output(hub_gd, 1);
+                               mdelay(20);
+                               gpiod_put(hub_gd);
                        }
 #endif
                        prop = of_get_property(of_node, "host-only-core", NULL);

Code: Select all

Author: Chris <codewalker@hardkernel.com>
Date:   Mon Feb 15 17:00:55 2021 +0900

    ODROID-C2: Fix usb_reset condition.
    
    Change-Id: Id38d66143e128854bdd1c3bd670f2fa7b88f2496

diff --git a/files/usb_reset.sh b/files/usb_reset.sh
index d344fc6..f3fcb75 100644
--- a/files/usb_reset.sh
+++ b/files/usb_reset.sh
@@ -2,7 +2,7 @@
 
 for x in $(lsusb); do
        echo $x
-       if [ "$x" == "16b4:0703" ]; then
+       if [[ "$x" == *"16b4:"* ]]; then
 
                result=`getprop wlan.driver.status`

https://dn.odroid.com/S905/Android/ODROID-C2/test/

Post by **odroid** » Tue Feb 16, 2021 3:23 pm

We double checked all the USB devices disconnected/connected automatically in the booting process. The USB host reset function seems to be working fine at least.
I hope this will dramatically improve the random touchscreen malfunction issue.

Code: Select all

[   17.703641@2] usb 1-1.2: USB disconnect, device number 4
[   17.705175@3] usb 1-1.3: USB disconnect, device number 5
[   18.027308@3] usbcore: registered new interface driver rtl8812au
[   19.463351@3] dwc_otg: Indeed it is in host mode hprt0 = 00021501
[   19.643295@3] usb 1-1: new high-speed USB device number 6 using dwc_otg
[   19.644479@3] dwc_otg: Indeed it is in host mode hprt0 = 00001101
[   19.846837@0] hub 1-1:1.0: USB hub found
[   19.847181@0] hub 1-1:1.0: 4 ports detected
[   19.851587@2] init: no such service 'usb_modeswitch'
[   20.123570@0] usb 1-1.1: new full-speed USB device number 7 using dwc_otg
[   20.229898@0] input: Logitech USB Receiver as /devices/dwc2_b/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C52B.0004/input/input7
[   20.235611@0] hid-generic 0003:046D:C52B.0004: input: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-dwc2_b-1.1/input0
[   20.251117@0] input: Logitech USB Receiver as /devices/dwc2_b/usb1/1-1/1-1.1/1-1.1:1.1/0003:046D:C52B.0005/input/input8
[   20.260615@2] hid-generic 0003:046D:C52B.0005: input,hiddev0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-dwc2_b-1.1/input1
[   20.274442@2] hid-generic 0003:046D:C52B.0006: hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-dwc2_b-1.1/input2
[   20.285701@3] init: no such service 'usb_modeswitch'
[   20.353628@0] usb 1-1.2: new full-speed USB device number 8 using dwc_otg
[   20.467585@3] init: no such service 'usb_modeswitch'
[   20.543540@2] usb 1-1.3: new high-speed USB device number 9 using dwc_otg
[   20.830443@0] usb 1-1.3: 88XXau 40:a5:ef:d6:97:59 hw_info[107]
[   20.847002@3] init: no such service 'usb_modeswitch'
[   22.371262@2] alarm lock suspend
[   26.704259@1] alarm lock suspend

sebastianrds · Post by **sebastianrds** » Thu Feb 18, 2021 4:11 am

codewalker wrote: ↑

Mon Feb 15, 2021 5:26 pm

Hi, I fixed two problems and uploaded a test version.
You can manually reset the USB hub controller and the Vu7A+/Vu5A+ specific auto-reset function works now.

Code: Select all

Author: Chris <codewalker@hardkernel.com>
Date:   Mon Feb 15 16:51:19 2021 +0900

    ODROID-C2: Fix usb hub reset bug.
    
    Change-Id: I58d1d257970680aa28163f5c0cc6ad705d7a202b

diff --git a/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c b/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
index 1cb9bf60c9d3..ce9bc9f56492 100644
--- a/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
+++ b/drivers/amlogic/usb/dwc_otg/310/dwc_otg_driver.c
@@ -1079,6 +1079,8 @@ static int dwc_otg_driver_probe(struct platform_device *pdev)
                                gpiod_direction_output(hub_gd, 0);
                                mdelay(100);
                                gpiod_direction_output(hub_gd, 1);
+                               mdelay(20);
+                               gpiod_put(hub_gd);
                        }
 #endif
                        prop = of_get_property(of_node, "host-only-core", NULL);

Code: Select all

Author: Chris <codewalker@hardkernel.com>
Date:   Mon Feb 15 17:00:55 2021 +0900

    ODROID-C2: Fix usb_reset condition.
    
    Change-Id: Id38d66143e128854bdd1c3bd670f2fa7b88f2496

diff --git a/files/usb_reset.sh b/files/usb_reset.sh
index d344fc6..f3fcb75 100644
--- a/files/usb_reset.sh
+++ b/files/usb_reset.sh
@@ -2,7 +2,7 @@
 
 for x in $(lsusb); do
        echo $x
-       if [ "$x" == "16b4:0703" ]; then
+       if [[ "$x" == *"16b4:"* ]]; then
 
                result=`getprop wlan.driver.status`

https://dn.odroid.com/S905/Android/ODROID-C2/test/

Hi codewalker, thanks for your answer. At https://dn.odroid.com/S905/Android/ODROID-C2/test/ we can see only a .bin (selfinstall-odroidc2.bin). How can we use this file?

Best regards and thanks for your support!

codewalker · Post by **codewalker** » Thu Feb 18, 2021 9:08 am

Try to write with Etcher or dd command to your eMMC or SDCard.
If you tell the result, we will release fixed firmware as soon as possible.

If Etcher can't accept .bin file, rename .bin to .img.

sebastianrds · Post by **sebastianrds** » Tue Feb 23, 2021 4:33 am

Hi guys,

The issue still exists with the image provided from Codewalker. We tested with some Odroid-C2 boards with different VU7A+ display modules and the issue persists. Is it possible to restart the OTG driver (not only make a hardware reset to the IC power controller) to check if the driver is down? Maybe forcing a complete restart of the OTG driver resurrect the touch interface.

We keep waiting your replies.

Best regards,

Sebastián

Post by **odroid** » Tue Feb 23, 2021 11:12 am

We need to check if it is really impossible control the VBUS power or not on the OTG port.

BTW, have you tested the latest image with the USB host ports? We've test over 100 times of cold booting cycle and touch screen always worked.
Was there zero improvement on your side?
If yes, the OTG VBUS power cycling will not give us any improvement very likely.

Anyway, we will provide a trial image with the OTG power reset feature.

codewalker · Post by **codewalker** » Tue Feb 23, 2021 5:56 pm

Try this.
https://dn.odroid.com/S905/Android/ODRO ... dc2.bin.xz

We modified OTG vbus power reset function.