I have been testing this hopeless situation for 3 years, long before the Rock 5B was a twinkle in someone’s eye. You’re so funny, being a clueless troll.
ROCK 5B Debug Party Invitation
Can you please do a systematic test using the OS image I talked about multiple times now (link also multiple times posted) and report back whether your ‘90watt PD’ is working reliably or not?
Great. So you only care about mainline Linux (and potentially broken drivers there) and nothing else.
I guess Radxa is more interested in what works today and for the next years: and that’s the BSP kernel with Android (a very valid use case of this board BTW) and Linux (see @willy’s efforts/checks to get Rockchip’s forward ported 5.10 mess into something that’s more close to 5.10 LTS)
2 Likes
My opinion as Feedback to Radxa is the design is just a bad idea.
Its just a BSP and you can still apply static rail and it works so its nothing that stops use.
Mainline is the destination and hacking the Android Kernel to the Linux LTS is not a solution, just a stop gap.
Do not tell others what they care about or dictate what they should do, keep it to your input and what opinion and testing you have done with the hardware.
I understand you have a range of neural diversity that is often different to others and appreciate the info you often provide, but keep your opinion to the hardware and not to others.
I guess the TL;DR version of your post was: “I am amongst those badmouthing Rock 5B powering (USB PD broken) and I also refuse systematic testing”, correct?
1 Like
To be honest, yeah pretty much. But even ignoring the obvious shitshow the Rockchip Linux kernel is, the tcpm and fusb302 that’s being added to the kernel by radxa are pretty close to the mainline drivers. This is not a good starting point, and quality of supply is going to be a huge problem, even if we somehow get around all the inherent issues on the device side.
My honest expectation is that a dedicated bring-up in early config of u-boot using a driver intended for microcontrollers combined with removing the device from the linux device tree entirely will be the most stable solution, of course then there are still questions about various supplies and their issues, but at least the board itself shouldn’t be the culprit. Say goodbye to the type C alt modes though. shrugs
No its now on a new revision and it is what it is but I just don’t think there is much point with further testing and again keep to the hardware not to others.
My opinion is I don’t like the current design but its gone forward anyway and the debug party has essentially ended and some of us realise this and are giving a final summary.
@tkaiser Here are some info recently from radxa:
Radxa is trying to do PD negotiation in u-boot. Some codes are already pushed:https://github.com/radxa/u-boot/commits/stable-5.10-rock5.
PD negotiation in u-boot makes things better because it’s far earlier than the negotiation in kernel after the power is pulgged into the typec port. Because of the low speed of tf card, when the kernel starts to negotiate with the PD source, the PD source is in a timeout state and then hard reset, which means power down. I’ve tested the new u-boot, which will make the system on tf card boot up. There are still some power down during the boot process but I think that is software issue. And radxa is now working on it.
I like the full-featured typec, and I’ve been testing it many times to get closer to the root cause of the PD related issues. And I believe radxa will finally get these things done.
Just for the record: @stuartiannaylor you personally contributed to this. Here in this ‘debug party’ by talking about your ‘90W PD’ not working. Also in some hidden communication channels others claimed the same.
Here where discussion should happen some participants of the ‘debug party’ (that is there to launch a product hopefully soon) discovered that there are problems with USB-C PD compliant chargers related to OS release. So if it’s about a ‘blocking issue’ that gets spread it would help if such claims can be verified.
Asides that your or mine opinions (I also prefer barrel plug with wide-range input instead of USB-C) really don’t matter much in the context of some ‘debug party’. While it’s great that Radxa gets so much free quality advise from you and e.g. from the Armbian guys where the TL;DR version is obviously ‘Radxa should neither use Rockchip reference designs nor Rockchip software!’ it certainly doesn’t help launching this product.
Thank you for clarification 
But it also highlights why this ‘debug party’ isn’t one. Since majority of relevant communication happens somewhere else so participants here just waste their time.
The next time Radxa starts something like this they really should try to learn from e.g. Hardkernel.
There is only you who has had the problem Radxa participate in all comms channels and they have the info they need.
I read about the updated DTB’s here and also the new revision and it has been said that Discord is merely for social chat, but there is only you that seems to have problems or believes a majority of communication happens elsewhere as it does not.
Section 6.3.13 in the PD spec (2.0 since we’re dealing with that class of hardware) claims a soft reset request can be used to recover the protocol layers without changing any negotiated voltages. Obviously none of these drivers are truly behaving this way. I believe this was the attempt made on the mainline driver for the ROC-PC. That can of course be revisited. It’s likely some supplies simply don’t honor that and go full reset anyway.
It could be better if we enable fusb302b in uboot, but maybe we still need more capacitors to make USB/pcie peripherals to keep power on during boot.
We are still troubleshooting this issue now, this need to dive deep into the PD protocol and state machine. To solve current issue, we will have to negotiate voltage in u-boot for sure, I can understand @Tonymac32 's pain but I think this is a whole eco-system issue. Someone should push this anyway. I think we are close to that.
2 Likes
No. The power loss is because of communication issue, so we should fix it. It seems we should set the i2c clock to fusb302 to 1Mhz to avoid the packet loss.
3 Likes
So the normal power mode switch speed is fast enough for not causing power loss during switching but PD hard reset still causes this?
My oldest 5V SBC power brick with A-to-C cable:
in0: 5.00 V (min = +5.00 V, max = +5.00 V)
curr1: 0.00 A (max = +0.00 A)
in_voltage0_raw: 4081
in_voltage1_raw: 4093
in_voltage2_raw: 3275
in_voltage3_raw: 4
in_voltage4_raw: 4089
in_voltage5_raw: 3237
in_voltage6_raw: 888 -> 888 / 175 = 5.07
in_voltage7_raw: 1724
RPi USB-C power brick:
in0: 5.00 V (min = +5.00 V, max = +5.00 V)
curr1: 3.00 A (max = +3.00 A)
in_voltage0_raw: 4082
in_voltage1_raw: 4092
in_voltage2_raw: 3042
in_voltage3_raw: 4
in_voltage4_raw: 4092
in_voltage5_raw: 2435
in_voltage6_raw: 927 -> 927 / 175 = 5.3
in_voltage7_raw: 1169
Apple 96W charger:
in0: 9.00 V (min = +9.00 V, max = +9.00 V)
curr1: 3.00 A (max = +3.00 A)
in_voltage0_raw: 4080
in_voltage1_raw: 4093
in_voltage2_raw: 3282
in_voltage3_raw: 4
in_voltage4_raw: 4088
in_voltage5_raw: 3238
in_voltage6_raw: 1565 -> 1565 / 175 = 8.94
in_voltage7_raw: 1988
24W charger with default DT (maxing out at 12V):
in0: 12.00 V (min = +12.00 V, max = +12.00 V)
curr1: 1.50 A (max = +1.50 A)
in_voltage0_raw: 4080
in_voltage1_raw: 4094
in_voltage2_raw: 3283
in_voltage3_raw: 3194
in_voltage4_raw: 4094
in_voltage5_raw: 3227
in_voltage6_raw: 2096 -> 2096 / 175 = 11.98
in_voltage7_raw: 2376
24W charger with adjusted sink-pdos DT entries:
in0: 15.00 V (min = +15.00 V, max = +15.00 V)
curr1: 1.60 A (max = +1.60 A)
in_voltage0_raw: 4080
in_voltage1_raw: 4090
in_voltage2_raw: 3277
in_voltage3_raw: 6
in_voltage4_raw: 4088
in_voltage5_raw: 3234
in_voltage6_raw: 2625 -> 2625 / 175 = 15
in_voltage7_raw: 2418
The 175 divider I just pulled out of nowhere…
From the schematic. The other appear to be board rev/etc
The others are described on page 15 of the schematic.
Since not being an EE or having any clues of hardware… is the 175 divider ok or not?
saradc is 1.8v so 12 bit FFF (4095) I guess.
35e to decimal = 862 / 4095 * 1.8 = .378
The resistor network is just the ratio of the total so 8.2k1/ 108.2k1
According to that
888 = 5.150v
927 = 5.376
1565 = 9.07
2096 = 12.156
2625 = 15.225
172.5 is closer. As Stuart pointed out, it’s a voltage divider. An easy reference though is that 20V is advertised as D79 hex, 3449 decimal. 3449/20V = 172.45