No USB connection - phone not seen!

[---]

@plainenough - got a decent cable (https://uk.rs-online.com/web/p/usb-cables/1765702/) but no change.
@NobodyNew1 - thanks for the idea - unfortunately no change.

[plainenough]

@plainenough - got a decent cable (https://uk.rs-online.com/web/p/usb-cables/1765702/) but no change.

Interesting. Are you able to reflash the device?

I do not suggest you do this unless you are comfortable with the flashing process. Even so, it would certainly be a great idea to FLASH A SDCARD NOT THE PHONE eMMC.

I only suggest this possible route to see if it is software or hardware related.

[---]

@plainenough - got a decent cable (https://uk.rs-online.com/web/p/usb-cables/1765702/) but no change.

Interesting. Are you able to reflash the device?

I do not suggest you do this unless you are comfortable with the flashing process. Even so, it would certainly be a great idea to FLASH A SDCARD NOT THE PHONE eMMC.

I only suggest this possible route to see if it is software or hardware related.

I've been running from multiple reflashed SD cards, I haven't attempted to reflash the eMMC.
eMMC has original UBPorts edition Ubuntu Touch (updated/upgraded over wifi to Version 5).
The problem occurred after a kernel update while running from SD.
Booting from eMMC or SD(Phosh, Mobian, Sxmo, ui-free-postmarketOS) produces usb/ethernet error.
I'm considering replacing the usb-c-side-board (optimistically).

What advantage does eMMC reflashing have over SD reflashing?

[plainenough]

@plainenough - got a decent cable (https://uk.rs-online.com/web/p/usb-cables/1765702/) but no change.

Interesting. Are you able to reflash the device?

I do not suggest you do this unless you are comfortable with the flashing process. Even so, it would certainly be a great idea to FLASH A SDCARD NOT THE PHONE eMMC.

I only suggest this possible route to see if it is software or hardware related.

I've been running from multiple reflashed SD cards, I haven't attempted to reflash the eMMC.
eMMC has original UBPorts edition Ubuntu Touch (updated/upgraded over wifi to Version 5).
The problem occurred after a kernel update while running from SD.
Booting from eMMC or SD(Phosh, Mobian, Sxmo, ui-free-postmarketOS) produces usb/ethernet error.
I'm considering replacing the usb-c-side-board (optimistically).

What advantage does eMMC reflashing have over SD reflashing?

Try putting it into the ubports direct flash mode.  
Take out the sdcard, put the battery in and hold the volume up button and power button until the LED goes red. It should hit that "Update" window from ubports, then plug the phone in and see if your os detects the device.

The USBC boards are cheap enough. Do you ever plug it in without the cover on?

[---]

@plainenough - I have been using the phone without the back extensively for cooling while testing.

Replaced back and:
1) held vol^ + power until RED led, eMMC UBPorts - udevadm monitor = no change.
2) held vol^ + power until GREEN led, eMMC UBPorts screen shows 'Awaiting command' - udevadm monitor responded (extract below, see https://bpa.st/MGTA):

ID_VENDOR=Pine64
ID_VENDOR_ENC=Pine64
ID_VENDOR_ID=1209
ID_MODEL=PinePhone
ID_MODEL_ENC=PinePhone
ID_MODEL_ID=4201
ID_REVISION=0506
ID_SERIAL=Pine64_PinePhone_Jumpdrive
ID_SERIAL_SHORT=Jumpdrive
ID_BUS=usb
ID_USB_INTERFACES=:0202ff:0a0000:080650:
ID_VENDOR_FROM_DATABASE=Generic
MAJOR=189
MINOR=3

Pc file system now shows various mounted partitions:

1.0 MB - boot.scr.
2.6 GB - android, bin, boot, dev, etc, home (etc).
67  MB - lost+gounf, dtb, initrd.img, vmlinux.
67  MB - lost+found, modules, config-5.6.0-pine64, dtb, initrd.img, System.map-5.6.0-pine64, vmlinuz.
8.4 MB - lost-found.
cache  - lost+found, recovery, system-image-upgrader.log.
userdata - android-data, system-data, user-data, .last_update, SWAP.img.

So it appears the usb/ethernet is probably electrically functional?

Normally booting the phone from eMMC/SD either inhibits usb starting or stops it. UBPorts direct flash mode provides apparently normal usb access leaving the phone in a state 'Awating command'. Does this imply that reflashing eMMC would solve the issue?

[---]

I haven't used UBPorts, only updated/upgraded it as the default eMMC installation. Now I realise the 'Awaiting command' state indicates usb access available via (e.g.) telnet. Presumably there are relevant settings in this working mode that I can compare/copy in  a standard eMMC/SD boot?

[jmorris]

Just got mine, same issue.  The solution is to plug into a USB 2.0 port, not 3.0 or 3.1.  Downside is you charge very slowly that way.

When you plug into a 3.x it is seen and then this shows up in dmesg:

[955678.668673] usb 8-1: new high-speed USB device number 2 using xhci_hcd
[955678.683113] usb 8-1: New USB device found, idVendor=18d1, idProduct=d001, bcdDevice= 5.07
[955678.683121] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[955678.683126] usb 8-1: Product: PINE64 PinePhone
[955678.683129] usb 8-1: Manufacturer: PINE64
[955678.683133] usb 8-1: SerialNumber: postmarketOS
[955678.688404] rndis_host 8-1:1.0 usb0: register 'rndis_host' at usb-0000:03:00.0-1, RNDIS device, de:83:75:29:f7:b9
[957015.764067] radeon_dp_aux_transfer_native: 32 callbacks suppressed
[983680.416737] usb 8-1: USB disconnect, device number 2
[983680.417894] rndis_host 8-1:1.0 usb0: unregister 'rndis_host' usb-0000:03:00.0-1, RNDIS device
[983680.418054] xhci_hcd 0000:03:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.


So it is some sort of software issue and not a hardware thing, means it will get better as soon as somebody who deeply understand USB has a look.

[---]

@jmorris - thanks for the suggestion, glad it worked for you. My issue must have (at least) a subtle difference.

I am examining the working usb UBPorts 'rescue mode' file system for settings/clues to compare with the failed usb 'eMMC/SD standard boot' settings.

I am also curious about the possibility of an eMMC reflashing solution.
Why would 'rescue mode' provides usb access but not fresh updated SD images?
Are proprietary blobs influencing 'rescue mode' usb settings and therefore negating a reflashing solution?

[jmorris]

@jmorris - thanks for the suggestion, glad it worked for you. My issue must have (at least) a subtle difference.

Addendum: After experimenting more it is also a requirement you insert the plug after the phone has booted and is stable.  If the cable is in at boot it isn't seen by the host (running Fedora).  Curious.  Betting there is an event being triggered on insertion, need to detect a cable during boot and synthesize that event.  USB is a tangles web though, will be digging though and report if any progress is made.

This is not a hardware problem, installed GloDroid to an SD over USB and it worked fine, right through a few restarts.

[---]

@jmorris I've been struggling with this issue and it's varying symptoms since July. In frustration I decided to optimistically reflash the eMMC with mobian-pinephone-20200905.img. The problem remains with either eMMC or SD. Previously my client pc was reporting Pinephone interface renaming (from usb0 to enp0...) and subsequent disconnection.

Starting the Mobian based phone without usb cable connected reveals that usb0 is 'unavailable'.

usb0: unavailable
"usb0"
ethernet (musb-hdrc), --:--:--:--:--:--, hw, mtu 1500


GENERAL.DEVICE:                        usb0
GENERAL.TYPE:                          ethernet
GENERAL.HWADDR:                        --:--:--:--:--:--
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                    --
GENERAL.CON-PATH:                      --
WIRED-PROPERTIES.CARRIER:              off

I'm still trying to rename and raise this interface - any advice greatfully received as I particularly want to use the 'convergent properties' of the device.