Pogo pins power clarification - reading schematics

[bokomaru]

In the meantime, please have a look at the PineEye schematic, which uses the pogo pins.  It simply takes power from both USB-5V and DCIN pogo pins, again with no isolation (yikes!), and uses a separate 3.3 V regulator.

Wow! Yeah, that doesn't seem right.

Maybe the R7 and R8 are "jumpers" because you're supposed to populate which one you want to use? Yeah, based on all the time we've spent analyzing this, I personally would never short DCIN and USB-5V together like that :-)

That BOM also lists R6, R7, and R8 as "jumpers", which I take it means 0-ohm resistor. I hope that you're supposed to only populate one or the other of R7 or R8, or else I hope that we're wrong about how the pogo pins work.

Obviously, PineEye uses 3.3 V for its power supply voltage, which requires it to use a separate buck regulator.  However, some other "pogo mod" requiring 5 V as the power supply voltage would also have to use a separate buck/boost 5 V regulator, which IMHO raises some questions about the phone design.

Yeah! So no matter if you're using 3.3 V or 5 V, you still have to use your own regulator, because you don't know what voltage you're actually going to get. ha

[dsimic]

Maybe the R7 and R8 are "jumpers" because you're supposed to populate which one you want to use? Yeah, based on all the time we've spent analyzing this, I personally would never short DCIN and USB-5V together like that :-)

That BOM also lists R6, R7, and R8 as "jumpers", which I take it means 0-ohm resistor. I hope that you're supposed to only populate one or the other of R7 or R8, or else I hope that we're wrong about how the pogo pins work.

You're right, R8 actually isn't populated in the picture of an actual PineEye board.  However, the documentation or the schematic of the PineEye should provide a clear description of the resistors used as power source selectors, or anyone actually making a PineEye risks damaging their PinePhone.

So far, it seems that we're on the right track when it comes to decyphering the purpose of the pogo pins.

[bokomaru]

You're right, R8 actually isn't populated in the picture of an actual PineEye board.  However, the documentation or the schematic of the PineEye should provide a clear description of the resistors used as power source selectors, or anyone actually making a PineEye risks damaging their PinePhone.

Aha! So in that picture, USB-5V is used, which makes sense. DCIN would only be available when a charger is attached or when the Pinephone is acting as a USB host.

Totally agree. This should be documented clearly but doesn't seem to be. And the BOM seems to be incorrect by showing both R7 and R8 as being populated at the same time. There should be a BOM that matches the picture. Or at the very least, the BOM should explain that you pick one or the other, but not both at the same time.

I guess many people who went and actually got that PCB printed and soldered components on themselves, would figure this out. But if you follow the design blindly, it's too easy to make that mistake.

So far, it seems that we're on the right track when it comes to decyphering the purpose of the pogo pins.

Yeah, it's encouraging to find more evidence like this that keeps building up confidence in how we're reading the schematics!

The author of the PineEye may have had the same dilemma that we did: hmm what do these pogo pins actually do, which should I use? So designed in the choice of either. And the author seems to have ultimately chosen to use the same pogo pin that I would have chosen in this case: pogo pin #5, USB-5V.

[dsimic]

So far, I think the only two real problems I have with the design are 1) the lack of isolation between a power source on pogo pin #1 and the USB C port, and 2) the strange "sometimes regulated 5 V" output on pogo pin #5, which you apparently have to assume is a variable voltage anywhere between 3 V and 5 V.

I agree, no separation between the pogo pin #1 (DCIN) and the charger port is a real issue, but only when attaching an external battery.  The other issue, variable voltage on the pogo pin #5 (USB-5V) pretty much boils down to using a separate voltage regulator as part of any "pogo mod" device, which is bad but bearable.

Haha, sorry to add to the confusion there. In a later post I discovered that I originally had PIN1 and PIN5 backwards. So those measurements are still valid, but you have to swap the PIN1 and PIN5 labels in that quote.

Believe it or not, there _is_ battery voltage on pogo pin #5, not 0 V, even when the phone is powered down. I measured it before, and I just measured it again just now to double check.

No worries and thank you for re-checking the measurement.  Here's a corrected summary of the earlier quotation, which I'll use to verify my conclusions further down in the post:

1) Phone powered down: 0 V at the pogo pin #1 (DCIN) and 4.0 V at the pogo pin #5 (USB-5V)
2) Phone powered up, no charger connected: 0 V at the pogo pin #1 (DCIN) and 3.9 V at the pogo pin #5 (USB-5V)
3) Phone powered up, charged connected: 5.0 V at the pogo pin #1 (DCIN) and 4.8 V at the pogo pin #5 (USB-5V)

As a side note, one more case should be worth trying:

4) Phone powered up, USB flash drive connected to the USB Type-C port (to turn the phone into a current source)

In the first case, having 0 V at DCIN is as expected because there's no charger connected.  The same applies to 0 V in the second case.  Also, having 5 V at DCIN in the third case is as expected, because there's a charger connected.

Actually, DCIN can be 0 V, and PS can still be nonzero voltage. From the PMIC's point of view, it can select 3 sources for PS: ACIN1/ACIN2, VBUS, or the battery. On page 6, Q600 is a (bulky) transistor which connects the battery directly to PS (through R601 though). It's turned on when the PMIC selects the battery as the source via N_BATDRV.

If I'm not wrong, R601 should be the PMIC's 0R01 current-sensing resistor, and it acts as a PCB trace when it comes to connecting VBAT to PS through Q600, which is controlled by the PMIC as you've described. 

In the first case above, I still have some doubts about 4 V at USB-5V.  First, why is Q600 enabled by the PMIC while the phone is turned off?  Second, the battery is declared with 3.8 V as the nominal voltage, so why don't we see voltage lower than 3.8-4 V at USB-5V, which should be caused by the voitage drop across D600?

Pretty much the same question about the voltage drop caused by D600 applies to the second case above.  Whenever the LP6226 isn't enabled, USB-5V should show VBAT minus the voltage drop across D600, which clearly isn't the case.  Thus, something doesn't add up, meaning that further investigation is required.

So the answer is that, not to worry, pogo pin #1 _doesn't_ provide VBAT. And if a power supply is not connected to the USB C port nor to pogo pin #1 itself, then pogo pin #1 always reads 0 V like you expect. (Unless we enable the LPW5206! We haven't tried that yet.) But I'll answer the same question for pogo pin #5.

The path is from VBAT, through R601, through Q600, through L606, through D600, to USB-5V, which is pogo pin #5.

Even when the LP6226 is disabled, the connection through L606 and D600 can still carry current from PS right along through to USB-5V (maybe with a voltage drop across D600). This happens even when the phone is powered off.

The voltage drop across D600, which doesn't show up on USB-5V, is something that needs to be investigated further, if you agree.

Let "Vs" be the "supply voltage" output setting on the variable power supply. Let Vb be the "battery voltage" that you'd measure directly across the +/- terminals on the removed battery. Now, for Vb ~= 4.08 V, and Vs = 4.70 V, 4.80 V, 4.90 V, 5.00 V, 5.10 V, 5.20 V, or 5.30 V:

Phone off:

Code:

PIN5 = Vs - 0.20 V
PIN1 = Vs - 0.35 V

Hmm, something is either wrong there, or I'm missing something.  As we know, as soon as a charger is connected, the phone powers on, so it would be pretty much impossible to measure the effects of connecting a charger while the phone remains powered off.

I also noticed the "power loop", but I dismissed it. I think that any computer with USB OTG must have this same problem. You have a USB port which can act as the "device" side, where VBUS is supposed to be provided to you as an _input_ from a connected host. Or, your same USB port can act as the "host" side, where you are supposed to provide VBUS as an _output_ to a connected device.

I cannot remember where (maybe in the PineBook Pro schematic?), but I've seen power switches as part of the USB circuitry that are used to cut off the bus power when a power source (not a power sink) is connected to a OTG-capable USB port.  Those power switches were described by the component manufacturer as made specifically for use with OTG USB ports.

Of course, providing a power input that way should not happen when a charger is connected, as that would allow the power source from USB-5V to be fed to a charger; there's no isolation of power sources.

So I'll stand by my interpretation that we shouldn't provide power _to_ pogo pin #5 as an _input_ to the Pinephone.
Even so, yes, there is no isolation between pogo pin #1 and the USB C port's VBUS.

I really have nothing against that rule, but then what's the actual purpose of the LPW5206?  Unless there are actually different "USB-5V" power planes inside the PinePhone, instead of a single USB-5V plane, the schematic allows USB-5V to become a power source.  I know, it's strange and I don't see the actual purpose, but that's what the schematic shows to us.

As a note, any power provided to the phone through the pogo pin #5 would be limited to 500 mA or 1 A, depending on the type of LPW5206 used in the phone (there are two types of the LPW5206 IC).  That makes the whole design even more weird; why would anyone make the power input limit that low?

The 500 mA or 1 A limit must be for when the phone is acting as a USB host and is driving the USB C connector's VBUS; this limit makes sure that not more than 500 mA (or whatever) is drawn from the Pinephone as an _output_ through the USB C port.

That's exactly what I thought initially, because it makes perfect sense.  But, that would be the case only if the IN and OUT of the LPW5206 changed their places in the schematic.  With the IN becoming OUT and vice-versa, the LPW5206 would be taking DCIN and passing it to USB-5V, while limiting the current to 500 mA (or 1 A).  But, that's simply not the case currently, unfortunately.

Anway, I do think that the LPW5206's intended purpose is only for the Pinephone to provide 5V to the USB C port when it's acting as the USB host. Like you're saying, depending on the OTG state.

That would make perfect sense, but unfortunately that is not what the schematic tells us.

I think that if you ignore pogo pin #5, it's exactly what the schematics tell us. Just because pogo pin #5 is on the input side of the LPW5206, it doesn't mean that we _have_ to provide power there, or even that we _can_ or should. We definitely can draw power from there, though like we said before, we don't know exactly how much current is safe.

Could you, please, explain how did you come to that conclusion, based on the schematic?  I agree that it would be logical, but that is not what's in the schematic, unfortunately.

Also note that USB-5V definitely isn't _only_ controlled by the state of the USB port. I've already showed (by actually measuring) that if you only apply 5 V at DCIN, without touching any other USB pins (e.g. D+/-), the voltage of USB-5V will follow PS as it increases from battery voltage to 5 V. We also assume that you could otherwise enable the LP6226 (via the Allwinner A64's PD8 GPIO) to boost from PS from battery voltage to 5 V.

We should investigate that first, if you agree.  Your measurements are hard facts, but the schematic, as already described, provides a lot of conflicting information.

Sure, that would be a good experiment: Modify the kernel to allow direct control over PD8-VCC5V_EN, then compare measurements with that enabled vs disabled.

Maybe I can give that a try later. My approach would be to remove PD8 from the regulator node to make it available to userspace, then to just control it via the sysfs GPIO interface, e.g.,

Code:

$ echo 1 > /sys/class/gpio/gpioXX/value

That would be a very good test.

My guess is that the intention of the DCIN pogo pin is to connect an external battery.

I agree, but even more generally. The intention of the DCIN pogo pin #1 is to connect an arbitrary 5 V power source. Doesn't matter whether that's provided by a battery or a windmill. And depending on what the PMIC decides, that power source might be used to charge the Pinephone's internal battery, and/or to power all (or most) of the components on the mainboard.

Well, yes, but not easily if there is also a charger connected to the phone's Type-C port.  Let's remember, there's no isolation between the power sources inside the phone.  D'oh!

---

Edit: Recently announced February community update includes more details about the PinePhone keyboard case.  Here's a quotation:

Due to the battery’s size taking up the bulk of the space inside the keyboard’s bottom section, the charging circuitry had to be shrunk down to a tiny PCB. But don’t be deceived by it’s tiny size, this charging circuit can simultaneously charge the keyboard and the PinePhone via the keyboard’s USB-C port. Since I know someone will ask: the USB-C port on the keyboard can only be used charging, it doesn’t support data or any alternate modes.

Thus, the keyboard case, as already expected, will include built-in separate charger circuitry, but with a twist: it will charge both batteries.  Another twist is that the case will have a separate USB Type-C port, which looks like a workaround, IMHO.  Now, I'm wondering what will happen to the charging through the phone's USB Type-C port?  It will probably be incompatible with the keyboard case, so the phone's USB port will be used for data only, which can also be concluded from the following quotation:

This effectively completely frees up the USB-C port on the PinePhone. You can plug a convergence dock into it or use it for any other common USB-C devices, e.g. thumbdrives.

On second thought, having a dedicated power input through the keyboard case might actually be a good thing from the usability standpoint, but a phone with two attached USB cables will surely look a bit funny in 2021.

[bokomaru]

I agree, no separation between the pogo pin #1 (DCIN) and the charger port is a real issue, but only when attaching an external battery.

The problem is more general than that. It's an issue no matter what you connect to pogo pin #1. Doesn't matter if it's an external battery or not, or even whether you're using pogo pin #1 as an input or as an output.

If you are providing power as an input to the Pinephone, then there is the possibility of two power sources being shorted together at DCIN. One from pogo pin #1, the other from the USB C connector.

If you are drawing power as an output from the Pinephone, then the presence/absence of that power at pogo pin #1 depends on (1) is a charger connected to the USB C connector, or (2) is the Pinephone in USB host mode.

As a side note, one more case should be worth trying:

4) Phone powered up, USB flash drive connected to the USB Type-C port (to turn the phone into a current source)

Sure, this is a similar test to the one we talked about before: controlling PD8-VCC5V_EN.

In the first case above, I still have some doubts about 4 V at USB-5V.  First, why is Q600 enabled by the PMIC while the phone is turned off?

Why not? :-P

The battery can still power something while the A64 is off. You can provide ACIN while the phone is off, too, e.g., you can charge the battery.

Hmm, something is either wrong there, or I'm missing something.  As we know, as soon as a charger is connected, the phone powers on, so it would be pretty much impossible to measure the effects of connecting a charger while the phone remains powered off.

Nothing wrong there. Connect the charger, let the phone power on, then shut it down from software. Leave the charger plugged in, and ta da! You're charging while the A64 is off.

Second, the battery is declared with 3.8 V as the nominal voltage, so why don't we see voltage lower than 3.8-4 V at USB-5V, which should be caused by the voitage drop across D600?

Two things.

(1) Sure, the "nominal" voltage is 3.8 V. But depending on how "full" it is, a lithium polymer/ion battery will range from around 3.4 V to 4.2 V, unloaded. When drawing current, battery voltage dips, and can go as low as 3.0 V or so. This is not specific to the PinePhone; this is based on my knowledge of hobby lithium polymer batteries for radio control electronics.

(2) We don't know where any voltage drop comes from, or what the voltage drop across D600 would/should be. And we haven't been carefully measuring voltage drops, which seem to be only ~ 0.15 V. D600 was only a guess/example for a possible explanation of a relatively minor, constant voltage difference in one or more scenarios.

Pretty much the same question about the voltage drop caused by D600 applies to the second case above.  Whenever the LP6226 isn't enabled, USB-5V should show VBAT minus the voltage drop across D600, which clearly isn't the case.  Thus, something doesn't add up, meaning that further investigation is required.

What should the voltage drop be across D600? We haven't looked it up.

The voltage drop across D600, which doesn't show up on USB-5V, is something that needs to be investigated further, if you agree.

Meh, the voltage drop could be investigated. But I don't necessarily think that knowing exactly where the ~ 0.15 V drop comes from is critical to understanding this. There's enough other evidence clearly showing that pogo pin #5's voltage is related to charger or battery voltage.

I cannot remember where (maybe in the PineBook Pro schematic?), but I've seen power switches as part of the USB circuitry that are used to cut off the bus power when a power source (not a power sink) is connected to a OTG-capable USB port.  Those power switches were described by the component manufacturer as made specifically for use with OTG USB ports.

Sure. I don't have a lot of experience designing/analyzing OTG hardware, and I haven't seen PineBook Pro schematics. Anyway, what you're describing is handled by the combination of the AXP803, the ANX7688S, the A64, the LPW5206, and the LP6226. If I remember correctly, there is actually an option (in hardware or in software) to select between the AXP803 or the ANX7688S as the "controller", who senses or decides, for example, when a particular type charger is connected.

So I'll stand by my interpretation that we shouldn't provide power _to_ pogo pin #5 as an _input_ to the Pinephone.

I really have nothing against that rule, but then what's the actual purpose of the LPW5206?

It has two purposes.

(1) Limit current flowing from USB-5V to DCIN.

(2) Enable/disable the ability for that current to flow at all.

[edit: And the larger purpose is for USB host mode, where the Pinephone supplies 5 V on DCIN, which goes through the USB C connector as an output. I trace the flow of current for that below, from PS to the USB C port.]

Unless there are actually different "USB-5V" power planes inside the PinePhone, instead of a single USB-5V plane, the schematic allows USB-5V to become a power source.  I know, it's strange and I don't see the actual purpose, but that's what the schematic shows to us.

No, it doesn't. Unless you can show that, for example, 5.3 V at USB-5V would not flow backwards across zener diode D600 to PS, a power source should not be connected as an input to the Pinephone at pogo pin #5.

That's exactly what I thought initially, because it makes perfect sense.  But, that would be the case only if the IN and OUT of the LPW5206 changed their places in the schematic.  With the IN becoming OUT and vice-versa, the LPW5206 would be taking DCIN and passing it to USB-5V, while limiting the current to 500 mA (or 1 A).  But, that's simply not the case currently, unfortunately.

No, LPW5206 _is_ connected properly for when the phone is acting as a USB host and is driving the USB C connector's VBUS. IN needs to be on USB-5V, and OUT needs to be on DCIN.

The name "DCIN" is confusing there. It is actually not _only_ a 5V input to the phone. When the phone is a USB host, DCIN is a 5V output from the Pinephone.

There is no need for a device like the LPW5206 to monitor current going into the phone. DCIN goes directly to the PMIC's ACIN/VBUS inputs.

I think that if you ignore pogo pin #5, it's exactly what the schematics tell us. Just because pogo pin #5 is on the input side of the LPW5206, it doesn't mean that we _have_ to provide power there, or even that we _can_ or should. We definitely can draw power from there, though like we said before, we don't know exactly how much current is safe.

Could you, please, explain how did you come to that conclusion, based on the schematic?  I agree that it would be logical, but that is not what's in the schematic, unfortunately.

The schematics tell us that pogo pin #5 is not for connecting a power source as an input to the Pinephone.

(1) If you supply power at pogo pin #5, current could travel backwards across the zener diode D600, connecting a power input the the PS output of the AXP803. This depends on the actual voltage provided at pogo in #5, and on the zener breakdown voltage of D600.

(2) When the Pinephone is a USB host, current flows from PS, through D600 and the LP6226 to USB-5V, through the LPW5206 to DCIN, through the 40PIN connector to the "USB-C small board", through an AW338XX, to the USB C connector.

The IN of the LPW5206 is on USB-5V, and the OUT is on DCIN, allowing current to flow in this direction. If IN and OUT were flipped, the Pinephone would not be able to act as a USB host by driving DCIN.

Well, yes, but not easily if there is also a charger connected to the phone's Type-C port.

Right, there's no isolation between pogo pin #1 and the USB C port; it's the same net. That's the only real functional/safety concern that I have with how the mainboard pogo pins are designed. [edit: Also, no isolation between a power source on pogo pin #1 and the Pinephone's USB host mode]

There is actually an AW338XX on the USB-C small board, which we've talked about before, but I don't think it fixes this problem.

Let's remember, there's no isolation between the power sources inside the phone.

I don't think you meant it that way, but this isn't literally true for all power sources. So to clarify:

There is separation and control for other power sources and power modes. For example, the battery is connected to the PMIC in a different place than the USB C port. And for example, there is sensing and control so that the Pinephone can either act as a USB _host_ by driving the USB C VBUS, or as a USB _device_ by drawing current from there.

[bokomaru]

Correcting myself about D600...

(1) If you supply power at pogo pin #5, current could travel backwards across the zener diode D600, connecting a power input the the PS output of the AXP803. This depends on the actual voltage provided at pogo in #5, and on the zener breakdown voltage of D600.

Not a zener diode, it's a "Schottky Rectifier" or "Schottky Diode". (The symbols are similar)

https://en.wikipedia.org/wiki/Schottky_diode

Also see the datasheet for the SS24. (I found one on Digikey or something)

What should the voltage drop be across D600? We haven't looked it up.

See attached screenshot from the SS24's datasheet. The drop will vary with current, and by extrapolating beyond the limits of this graph, at less than 100 mA, the voltage drop is less than 0.25 V; decreasing more as current decreases. I don't know how this interacts with the LP6226; maybe as a whole, the SS24 and LP6226 make up a "perfect" regulator or "super" diode.

Unless you can show that, for example, 5.3 V at USB-5V would not flow backwards across zener diode D600 to PS, a power source should not be connected as an input to the Pinephone at pogo pin #5.

Another screenshot attached, showing that "reverse" current won't exceed 10 mA until we exceed 120 V. (which I would call the "breakdown" voltage for a zener diode)

The datasheet says "These rectifier are suited for free wheeling, secondary rectification, and reverse polarity protection applications."


That being true, _maybe_ you could supply power at pogo pin #5 as an input to the Pinephone, _if_ the LP6226 is disabled. I still don't think it should be done.

Unlike for DCIN, there is no "detection" logic that would allow us to determine whether or not an external power source is connected to pogo pin #5. There would have to be cooperation with software to ensure that PD8-VCC5V_EN is "off", and I'm not sure how we would do that, other than by manually controlling it. Or by permanently hogging it to "off", making us unable to act as a USB host while on battery power (no voltage boost to 5 V).

[bokomaru]

Thus, the keyboard case, as already expected, will include built-in separate charger circuitry, but with a twist: it will charge both batteries.

Ha!

You can plug a convergence dock into it or use it for any other common USB-C devices, e.g. thumbdrives.

Wait...

Is the keyboard/battery case using DCIN?

What if the keyboard/battery case provides power to DCIN, and the Pinephone simultaneously enables USB host mode by turning on the LP6226 and the LPW5206?! Isn't that what would happen?

So two power sources could get shorted together: the Pinephone's LP6226/LPW5206 output, and the keyboard/battery case. All it takes is for the Pinephone to decide to be a USB host, which is what it would do to talk to the convergence dock or a flash drive.

I don't understand how this is OK; maybe I'm missing something. If I'm right about this, and if the keyboard/battery case uses DCIN without some other safety check, then the February update is wrong, and you shouldn't use the Pinephone's USB C port at all.

Another twist is that the case will have a separate USB Type-C port, which looks like a workaround, IMHO.

Exactly. To me, the extra USB C port feels like a "hacky" solution to work around:

(1) switching between (or simultaneously) drawing power and providing power via pogo pins; as implemented, the keyboard doesn't need to draw power to charge its own battery

(2) lack of isolation between pogo pin #1 and the USB C port

The problem of isolation between pogo pin #1 and the Pinephone's USB host mode is still unsolved even by this workaround?

Now, I'm wondering what will happen to the charging through the phone's USB Type-C port?

It will probably be incompatible with the keyboard case, so the phone's USB port will be used for data only...

Yeah, with the keyboard/battery case attached, I'd say we aren't allowed to charge through the phone's USB Type-C port anymore.

This effectively completely frees up the USB-C port on the PinePhone.

To add USB ports, I would have thought, why not just plug a charger into the convergence dock, or a similar USB C "power delivery capable" hub? Seems like we're not allowed to, though.

[GregH]

Hi All, just wanting to relate my experience on this fascinating but rather complex topic, in the hopes of finding a solution for my needs.

A bit of background - I am wanting to use the PinePhone as a miniaturised version of the Pine A64 LTS SBC with the screen built-in. I have a prototype that looks quite a lot like Project Anakin floating around :-)

There is an RS232 USB device (a sensor) which I connect to the PinePhone USB-C with a USB-A adapter. I'd like to be able to charge the phone via the pogo pins (DCIN/GND) while also powering and reading from the USB sensor. I could do this on the A64 LTS no issue (via DCIN barrel). Mobian is the operating system on the PinePhone, Armbian on the A64 LTS.

On the PinePhone:
* Before attaching the USB device, I found that I could charge via DCIN. Good.
* I then attached the USB device without supplying power to DCIN. USB device worked fine. Good.
* I then supplied +5V to DCIN. Good new? No magic smoke! Bad news? No charging.
* For completeness, I disconnected the USB device and supplied power to DCIN - charging OK.
* While charging I connected the USB device - device would not come up (/dev/ttyUSB*). I have to disconnect the power to DCIN to get the USB device to register.

Another side effect is that the device will not stay off with DCIN powered - no charging while switched off, it keeps booting up again :-(

I'd love if there was a magic way to charge the phone via a pogo pin (ie USB-5V) as debated here, perhaps with USB driver / kernel trickery. My fall-back position right now is to wait for the keyboard/battery to come out and borrow their strategy, assuming they can charge the phone and host a USB device at the same time. Fingers crossed!

Questions:
 * Has anyone tried this on KDE/Manjaro or other distro with better results?
 * Any chances some USB driver / kernel trickery could fix my problems?

Other comments:
 * The wiki should really be updated! At very least I suggest a link to this discussion, mostly to help people avoid possibly costly mistakes.
 * On the A64 LTS (same AXP803 PMIC), the USB +5V rail gets battery voltage when the board is powered down - which sucked, I had to devise a high-side MOSFET switch to work around it. High-side because the screen I was using provided a ground route to all USB devices...ugh

[bokomaru]

Hi @GregH, I'll start with the wiki, since it's the most important first step.

The wiki should really be updated! At very least I suggest a link to this discussion, mostly to help people avoid possibly costly mistakes.

Can't argue with that! We have enough info to offer to the community that we shouldn't wait any longer.

I made some incremental updates to the pogo pins section; here's the full diff.

https://wiki.pine64.org/index.php?title=...oldid=9369

Also updated the labels on this image using my questionable GIMP skills; good enough for now :-)

https://wiki.pine64.org/wiki/File:Pineph...ilehistory

I tried to capture most of what we've collectively learned + agreed on in this thread; at the same time, tried not to claim things that we're usure about. Should be a good start. @scholbert, @dsimic, @GregH: please point out anything false or missing!

[scholbert]

Hey bokomaru,

great work, especially the latest conclusions!
I just had a quick look at your additions to the wiki and it looks O.K. to me.

Cheers,
scholbert