ROCK 5B Debug Party Invitation

#207

Yeah I think we are all the same stuck with LLvmPipe, tried to install the rockchip drivers but failed.
PS there is also now a vulkan pipe https://www.phoronix.com/scan.php?page=news_item&px=Lavapipe-Vulkan-1.3-Official
If stuck with the CPU.

#208

It’s certainly possible to use the Mali driver as icecream95 showed, but it’s not enabled by default in the Debian 11 (May 1, 2022) image that shipped with the board.

#209

Yeah just saying like you its not enabled by default and didn’t manage to get it installed.
Also on the 5.10 BSP image its likely the only driver we will get.
I didn’t try too much as many got the board before me and presumed the lack of benchs until @icecream95 was indicative of some problems or needs.

I don’t know what will end up as the G610 was designed with a strong focus on Vulkan not openGL, due to Vulkan specific hardware is creating things like Zink which is OpenGL on Vulkan.

The Mali driver gives openGL but don’t think it gives Vulkan but have not tested as maybe it does.
It will certainly act as a stop gap until the long haul to mainline and a Mesa/Kernel combination that does give Vulkan and by that time I guess there will be various choices.
Its like what Alyssa Rosenzweig wrote in the above Conformant open source support for Mali-G57 article and, dunno as all confusing and guess we shall have to wait and see.

#210

To elaborate on this further.

Now that first board reviews start to appear that show wrong I/O performance (for example at @CNXSoft where USB3 Superspeed maxes out at 325/380 MB/s while hardware and drivers are capable of 415/425 MB/s) maybe it’s time to do something before all the crappy YouTube reviews are about to follow?

When looking at RK3588 Geekbench scores cpufreq governor defaults to schedutil while on Radxa’s OS image it is set to ondemand though with the needed tweaks missing and as such resulting in wrong performance numbers in almost every review now and that will follow.

Reason? Using a ‘vanilla OS image’ that contains some ugly unmaintained shell script AKA ondemand.service.

Issue identified back in 2016, resulting in Armbian masking ondemand.service so it couldn’t make things worse. Back then this was some script only affecting Ubuntu since being part of Ubuntu’s initscripts package, now it became part of systemd and is everywhere (maintainers most probably not noticing since the effects on x86 are not existent).

As such Linux images for arm/arm64 other than Armbian run with wrong settings for sure (vanilla as @stuartiannaylor calls it). Using ondemand without proper settings will result in crappy storage performance. With Armbian only wrong settings on more powerful boards like ODROID N2+ or VIM3.

Suggested fix by me for Armbian (where all of this is broken on recent big.LITTLE machines since years but nobody cares): https://armbian.atlassian.net/browse/AR-1262 (of course ondemand also should be masked on Debian but hey, who cares there about low-level optimizations any more?).

On other OS images where cpufrequtils is not installed and configured for ondemand by default of course my script snippet needs to be adjusted.

3 Likes
#211

I will try and say this one more time it doesn’t matter if or not your scripts are fixes, crappy or whatever pathetic description or general lousy attitude you may come out with to describe them.

They are not the norm and why those fixes are needed should be fed upstream and questioned not merely hacked into an image and forgot about.
The images should stay vanilla as in plain, no extra scripts by anyone.
Create a entry in the wiki and share rather than creating only your own github pages and declaring as yours all the time.

Those scripts should not go in the image they should be documented in the wiki as also further down the line for any reason just like ondemand.service may have effects and again document it and upstream it and share the details on a wiki not more hidden scripts in an image.

Its that way because you will know there are in the image because you put them in the image not someone else unknown.

If someone wants add an image as we will likely have a plethora of optimised images to choose from, but the images from Radxa should be base images for us all to build on.

#212

Me as well:

  • vanilla is broken wrt I/O performance on arm/arm64 for reasons identified long time ago
  • in the past this only affected Ubuntu, now also Debian (and maybe other distros relying on systemd as well)
  • this will result in low real-world and benchmark I/O performance on arm/arm64 especially compared to x86 where the same ondemand.service has no effect today. Reviews will compare ~320 MB/s with USB3 on ARM with +400 MB/s on x86 and the conclusion will be either ‘forget about ARM for I/O’ or ‘there’s a lot of work still to do software-wise’ while in reality the problem is identified and has been actually fixed (just not on the board vendor’s images).

So good luck fixing this ‘upstream’ for ‘vanilla’ performing at least ok-ish and in the meantime I guess @hipboi is happy getting bad ROCK 5B reviews.

Also there’s no need to add scripts here and there since if OS images are created in an automated way this can be added as part of image building as a service e.g. called radxa-hardware-optimization or whatever. At least that’s how I would do it since manually creating images or basing on those of someone else is weird anyway…

Finally a quick look at the competition: how does Hardkernel for example deal with such problems? A) they manage to build a community (by keeping discussions in their forum and not establishing fragmentation) and B) they think about what reviewers are doing (especially the clueless ones) and set their own images to performance from the beginning. Bad for consumption numbers, good for reviews.

2 Likes
#213

What is the the default governor on the Pi?
Radxa should create base images of vanilla ubuntu & debian that really should not even have a desktop. As for Radxa the more they include the more they have to support.
Then a wiki and Arch Linux style would be amazing as a forum is only for initial discussions and painful to search for correct settings.
Add an entry in the wiki ‘Performance optimisations’ add add your tweaks or maybe even submit a package to Radxa.

2 Likes
#214

Mine works with a 5V USB-A adapter connected via a USB-A to USB-C cable, but when on my PC’s noname USB-C charger it reboots as well when booted from the debian image on the eMMC. The ubuntu one on the SD works with any PSU. When connected to another USB-C power adapter (lenovo round plug to usb-c) then it works fine. I don’t know the characteristics beyond the voltages and current. But there’s definitely something that’s triggered by software at the end of the boot and that makes some PSUs cut the juice. I suspect it has anything to do with touching the USB-C connector’s role (otg/device maybe) but could be wrong. In any case it does not seem to cause problems with dumb chargers.

#215

Kever’s answer:

I sync with my colleague for this module and here is the reply:

For both FUSB302 and TCPM(type-C framwork) source code are from upstream, so
we think the upstream driver should work for these two module, you will
need to check the dts config for your board and maybe also how FUSB302
co-work with the charging IC.

Maybe this is the workable way to make it easier to make this feature work
on top of upstream code:

  1. Ask board vendor(Radxa or Pine64?) to make this feature works base on RK’s
    BSP, they should able to contact rockchip support if they need help, we believe
    this feature works on rockchip platform(if there is no hardware issue on the
    board);

  2. After you get the BSP with USB PD power feature enable, sync the dts to
    mainline kernel first,it should be work;

  3. If step 2 does not work, them check the source code about usb
    pd/type-C/FUSB302, we have some bugfix, but basic function should already work
    in step 2.

2 Likes
#216

Highlights the anti-pattern I was suggesting around using these things without a battery

1 Like
#217

Yes, it seems clear the question answered was “Does PD and TCPM drivers generally work”.

The power delivery negotiation is working fine, etc, but there is a built in assumption that there is an energy storage medium to maintain system power while the TCPM shuts down the VBUS and re-enables it. This simply is not acceptable for a single board computer without a battery backup.

This has to be false :smiley:

last note, the schematic shows the voltage in rail being fed to a SAR ADC through a voltage divider. I haven’t checked yet if that is exposed to the user in the Radxa image, would be worth watching to see for any supply “hiccups”

2 Likes
#218

The power delivery with PD is sort of crazy chain where at each step you lose efficiency.

Often a PD Brick will have a buck giving out approx 21v that is fed to a switchable dc-dc to give the 20/15/9/5.

Curently that is fed into the first 5v onboard buck which is then fed into a 2nd 4.1v or something buck (close enough with my memory)

So on PD we have buck->dc-dc->buck->buck feeding various power sources and further regulators, which are quite a number of steps where conversion loss occurs.
I had a 12v and a barrel to usb-c already but purchased a Amazon recommended 90watt purely for testing and curious to what the efficiencies are.
Likely powering GPIO 5v direct is the most efficient as that will bypass the 1st onboard (I presume, but someone will look at the schematic again) and wondering at the wall how big the difference is.

#219

You can try armbian
They have merge request for rock5b

#220

You are replying to the wrong person about Armbian as not a fan of there images.
What I posted is purely hardware and can not be effected by any merges.

1 Like
#221

It will still go through the regulator, there is no bypass, best case the switch goes fully “on” and the only losses are across the RDS_ON of the switch and the resistance of the inductor. I’d recommend 5.5V as a starting point.

Show me on the doll where Igor touched you. :smiley: You are, however, perfectly correct about the images, they bring nothing new to this design flaw discussion concerning the power. I’m certainly not contributing fixes to a kernel I will never use, so waiting for some more patches to hit mainline for RK35xx in general.

The power discussion is getting stale. It is a driver issue that either requires a software rewrite and a push to mainline to make this device relevant without stinky Rockchip android/linux mashup kernels, or a hardware change. It’s unfortunate, but that is the situation. The “Let’s send unregulated 12V down a cable into a Type C adapter” argument is a dangerous hack that will result in someone breaking something.

3 Likes
#222

That is what PD does as there is a 4.5-26v buck onboard and as long as in that range doesn’t matter 5v is the most efficient, 12v is named as a typical application with 20v or more being the least efficient.
Confirmed by jack but also the schematic

2x MP8759 one setup to give 5.148V that feeds another to give 4.039V

The 1st also gives the GPIO its 5v so GPIO is on the out side so powering via GPIO likely bypasses that 1st buck and maybe not a wise idea to put 5.5v on there even though only the fan & usb and the 2nd buck as again the 2nd buck converts to 4.039V and is a regulator.

Its just perked my interest to how efficient/inefficient they are and the difference driving gpio direct which I will try, keep meaning to root through my box of s hit and find that little inline meter thing I have.

There is nothing personal with Igor, I have snapped at sales speak a few times but my preference of image is raspbian lite or whatever you want to call it now purely because its consistent and then when I can get it usually a Manajaro minimal image (if it exists) as a big Arch Linux fan which generally in the forums I reply to whatever without spamming my fave distro.
That is why I think Radxa should only provide base images as I call vanilla that all can build on and have a wiki for tweaks and package recommendations as others will provide optimised and customised that many I don’t have much interest in.
I am often doing something specific where I will be installing and evaluating and want a clean image that after I will try to optimise for whatever scenario it provides and that is why I have my preference not persona. :slight_smile:

Every buck, dc-dc convertor is not 100% efficient and all have losses and in the PD power trail to the onboard in this design we have many.

#223

You still going with your old way of 12v barrel huh. Only old ppl loves them. Personally i prefer to have mobile UPS like ZMI, which i can take with myself and use it on the way. Not some junky barrel which requires me to somehow get 12v power supply.

For gods sake, forfeit barrel already, there is enough of this junk in others boards :slightly_smiling_face:

As for using GPIO - it’s really not recommended way to do it, since you actually need to supply 6A over 5V line. To do this you need additional HAT which will around 0 length between power output and input to evade all losses

#224

I don’t actually care about the connector its about a strange scenario where we are robbing the usb-c to power a board by PD that really expects a battery as it has been designed if its mobile type device.
Whatever we power it with it doesn’t really matter and whatever voltage PD supposedly smart provides is just a pointless extra.
The usb-c is actually a great charging port but we can not because we are sticking power in it.
Could be another dumb USB-C for all I care but yeah I would likely not use PD to power it as the dc-dc in the power adapter is completely pointless you could rip it out and feed the 21v its fed and things would work fine.

Its an overcomplex and in terms of efficiency a bad design and for use it steals the usb-c which is not great either.

#225

No it’s not, because phone charger is a way more popular, than good 12v supply. Also a good PD supply is more available (because of notebooks and phones), rather than good old junk 12v power supply.

For god sake. Stick with pi4 then. It’s have so awesome design (not).

First time you are using SBC as on-way cheap laptop? Or as web server? ZMI Power Bank cost a way less then UPS that can provide 220v for at least 18 hours straight.

#226

Yes. I’m an electrical engineer and can read the schematic. :wink: But your cell phone doesn’t and neither do other devices. For a production device to require such standard-breaking behavior is bad practice, end of story.

Yes, misread what you wrote, I was assuming still feeding power in through the normal way so you don’t need to reproduce any protection circuitry.

Yikes. Only people who don’t care about reliability make fun of them. Of course my preference is screw terminals, but you can’t always get what you want. :slight_smile:

I don’t disagree, but it is convenient assuming it works. The one plug fits all thing.

2 Likes