sick and tired of my Armbian desktop locking and crashing

[chwe]

1 hour ago, Da Alchemist said:

 

@chwe, think you never had a Rockpro in your hands.

2 hours ago, chwe said:

 

if we would kick out every board which is a bit troublesome during wip.. We would support only a few boards here..

 

So Devs can concentrate on the Boards that are worth to be supported.

forget to state but yes, I never had one.. but still considering buying one.. Devs here normally focus on board they're interested... not boards someone wants to have up..

 

18 minutes ago, Da Alchemist said:

@martinayotte, pineH64 is working better than Rockpro 

well.. send me rockpro and I'll send you a pineH64 back..

 

39 minutes ago, TonyMac32 said:

it will break the upgrade path on very nearly every board, since our current patching/boot situation is impossibly convoluted.

wouldn't agree on this.. but for sure it needs some sort of a merge script to ensure paths are properly set.. or at least old installations won't get updated into the merged family..

1 hour ago, TonyMac32 said:

Given the OP is not alone, and I completely understand his frustration, just imagine when that happens.  

given all boards are marked wip stated clearly that you shouldn't use them productive... Means you shouldn't use them productive..

 

1 hour ago, TonyMac32 said:

Well, I did say "opinion".  I would guess it takes more than my automotive-engineering-minded release conservatism to shut down or change the direction of the entire project.  I will open a new thread on this topic, I may have a compromise in mind. 

good idea.. even when I don't fully agree on the no wip image thing.

[martinayotte]

2 hours ago, chwe said:

well.. send me rockpro and I'll send you a pineH64 back..

I don't need another PineH64, I have one ... And since I´ve only one RockPro, I won't get rid of it ...

Do you have a spare "nvidia jetson nano", then, yes, I can take it ...

[Da Alchemist]

10 hours ago, chwe said:

forget to state but yes, I never had one.. but still considering buying one.. Devs here normally focus on board they're interested... not boards someone wants to have up..

 

 

So Armbian Devs are not wvery interested in Rockpro. @TonyMac32 explained why. One more reason to kickoff Rockpro.

 

10 hours ago, chwe said:

well.. send me rockpro and I'll send you a pineH64 back..

why not, if you want to change a 3Gb Model B and you are living in the EU (apart from the UK) lets talk about it.

[martinayotte]

2 hours ago, Da Alchemist said:

So Armbian Devs are not wvery interested in Rockpro

Yes, I am ... But I still struggling to migrate its u-boot from old v2017.xx to v2019.01 ...

[martinayotte]

14 hours ago, TonyMac32 said:

I will open a new thread on this topic, I may have a compromise in mind.

Sure ! I think it is better to have some WIP image from time to time instead of keeping old one, like for PineH64, there is currently an old 20180823, probably a Legacy one.

[chwe]

4 hours ago, Da Alchemist said:

15 hours ago, chwe said:

well.. send me rockpro and I'll send you a pineH64 back..

why not, if you want to change a 3Gb Model B and you are living in the EU (apart from the UK) lets talk about it.

nope.. they always grey us out in the middle of europe when they talk about the union.. Compared by the Britains.. we didn't join this club at all..

But in exchange for a 4gb rockpro I could think about a german address..

 

4 hours ago, Da Alchemist said:

15 hours ago, chwe said:

forget to state but yes, I never had one.. but still considering buying one.. Devs here normally focus on board they're interested... not boards someone wants to have up..

 

 

So Armbian Devs are not wvery interested in Rockpro. @TonyMac32 explained why. One more reason to kickoff Rockpro.

I don't see in his post that he isn't interested in the RockPro.. He just explained that the whole RK3399 development is a mess.. Including the NanoPi (even when they run 'stable' - in the future we won't maintain two 4.4 kernels so we might have some surprises for those as well in case we don't go for friendlyArms 4.4 fork)..

I think your interpretation into his words is driven by the frustration you have with the board. Which is understandable, I had some frustrating boards as well (e.g. tinkerboards CSI camera, BPi R2 u-boot, BPI M2 zeros SD-Card interface, OPi Zeros ref. 1.4 overheating issues and RK3399's u-boot mess ). Actually I think I don't have many boards which were never frustrating..  Probably the OPi PC +..  And the LicheePi with 64mb ram worked also flawlessly with armbian (thanks to @Icenowy, never had such an easy 'board bring up' ) ..

It's part of the arm world that things don't work as expected.. Otherwise there would be no need for an Armbian..

 

3 hours ago, martinayotte said:

6 hours ago, Da Alchemist said:

So Armbian Devs are not wvery interested in Rockpro

Yes, I am ... But I still struggling to migrate its u-boot from old v2017.xx to v2019.01 ...

tried the same for the RockPi 4b.. Never got it to drop into u-boot shell.. When I think about it now, I think it's maybe a memory reallocation error once u-boot should reallocate itself to free up lower addresses for the kernel..

[martinayotte]

1 hour ago, chwe said:

tried the same for the RockPi 4b.. 

This is because RockPi4B has been created from RockPro as a template ...

1 hour ago, chwe said:

Never got it to drop into u-boot shell..

What do you mean ?

You're unable to stop U-Boot at startup using <spacebar> ?

It desn't sound like you're booting an Armbian U-Boot v2017.09, it should stop !

Maybe there is a Non-Armbian U-Boot elsewhere that has boot precedence ? Did you erase eMMC or did a "nand-sata-install" ?

 

[Maarti]

from the uboot mailing list

[dogshome]

On 4/1/2019 at 9:14 AM, AxelFoley said:

Thanks Igor ..... should I install lightdm as the default from armbian-config again ?

 

whats going to be the new default ?

 

Hi Axel, watching this thread. Armbian has been pretty bulletproof on all SBCs I've tried. Interested to see how this turns out. 

[AxelFoley]

On 4/1/2019 at 1:09 AM, NicoD said:

@JMCCYou could run Chromium with the terminal (just type chromium)and see if it gives any clues to what's going on.

@NicoD Brilliant idea ..... I don't know why I did not think of that ...

See attached ... I got those errors when 1st launching the Chromium browser. It works for a while as I navigate to the Armbian forum ... then locks up with no more command line output.   Interesting that it goes back to my hunch this was a graphics driver issue causing the instability. Its just strange that Chromium triggers the issue but not firefox!

 

 

[AxelFoley]

On 4/1/2019 at 1:26 PM, Da Alchemist said:

Using Rockpro64 for Desktop Scenarios is a really bad idea at this state of development.

@Da Alchemist that is a good point ... I made a rookie mistake thinking I could put up with a few glitches and still code. I then compounded it by using my  cluster master as my development IDE, git master, salt master, Prometheus master, Grafana server.... its my own fault. I think its time to restart from scratch and move my code to github and reformat everything. I have clearly managed to bugger up the graphics mail drivers on the cluster Master/Dev box through continual upgrades and a link on the wiki to install HW accelerated mali drivers  that are probably not feature complete.

 

The decision was in part due to the fact the pico cluster case only allows for one easy HDMI output and that was my cluster master.

I don't believe that there is thunderbolt support over USB C in the RockPor64 so a USB-C to HDMI Dongle is not an option.

 

I can reformat the cluster without desktop and I have a KVM so I can access a web browser and the cluster more easily and I can use vim (mostly I am writing C and python).

 

[AxelFoley]

On 4/1/2019 at 2:11 PM, AndrewDB said:

tail -f /var/log/{messages,kernel,dmesg,syslog}

@AndrewDB Thanks for the suggestions I did try this but the lockup is so instantaneous. Nothing gets logged to disk .... see attached for a before and after screenshot of the syslog / kernel log and the X.org log ...      this is why it has been so hard to troubleshoot.  However somebody brilliant idea to launch chromium from a terminal has given me some interesting new lead's!

see attached before crash, after crash and teh chromium error to the command line when launched from a terminal;

 

I really don't care about chromium ,,,,  when working on these boards I try to keep it as simple as possible and use stock packages in the hope I will have more  bugs squashed.   I am now using Firefox so I can at least start working on the GPIO code again.

 

Thanks for the suggestions.

 

It could be I need to run a debug kernel as I at least expected to see some issues there .... but the nature of the lockup could mean its a HW issue triggered in the Mali Graphics chip triggered by Chromium only

 

[AxelFoley]

On 4/1/2019 at 11:50 PM, chwe said:

If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?

 

 

but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..

 

but also this sub-forum has a nice reminder:

 

My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.

 

Just another reminder: https://forum.armbian.com/guidelines

especially this points here:

 

 

what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?

@chwe A quick heads up .... people may not be aware but the pine guys have their own image installer based on Etcher that automatically pulls the Armbian image down without any indication of WIP or Stable status of the project (see attached). This is here Pine falls down a bit ... they should have focus on one main desktop & command line release to recommend to users ... if they are going to obscure project status from their installer.

 

I only found out about WIP when I reported the issues.

 

I have been testing several desktop imaged and to be fair to Armbian ... they are all far away from where Ambian is on the RockPro64, its by far the best performing I have found (mrfixit build is broken atm if you have an emmc boot). Maybe this is just me but I only need a desktop when developing to access a web browser .... it to save me having to kill trees ...... I have had to print this lot all out so I could continue working because of the Chromium / Mali driver issue. 

 

However I think that I have no choice but to reformat the whole cluster ... with all these lockups I have seen evidence of packages installed through apt that are actually missing libraries and I had to do force installs.

 

apt install --reinstall lightdm

apt install --reinstall libegli

 

if it was not an issue with the armbian package release at the time or if the 10 RockPro64's I have were HW Locking up and resetting during a package install.

 

Sometime its better to go back to square one, Whats peoples opinion ?

 

I am happy to act as a tester for this board and Armbian and find out where the real issues are.

[AxelFoley]

On 4/1/2019 at 11:50 PM, chwe said:

what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?

@chwe Yes I have been working with the Pico Cluster guys to revise the power supply unit they ship with their cluster and we have upgraded it to a 12v unit instead of a 5V unit. I have also completely rewired the power cable loom and installed a buck converter for the 5v Switches and Fans.

I have not gone to the extreme of checking individual output voltages and currents to the Boards from the PSU. But I have been monitoring the clusters total power consumption. The cluster is not loaded at all because I have not been able to do any work on it due to the stability of it. at peak it has never pulled in more than 64watts (5.3A). Most of the load is Cassandra recovering after the node reboots as its multi threaded it can load all 6 cores.

 

The 12v DC In goes via two Buck Converters (SY8113B) to create 2 x 5.1v rail. One of those rails goes into a RK808 Buck converter which I think is embedded into the RK3399 chip.

That RK808 feeds the GPIO pints which I have measured to be 5.190v.

There is a 4 Pin SATA JST Connector that says its wired to the raw DC in (12v) (but SATA also has 12v, 5v and 3,3v specifications so I am not sure of one of those pins is in addition the 5v rail direct after the SY8113B).

 

@chwe  Do you want me to monitor the 5v rail after the SY8113B) with an Oscilloscope prior to lock up? Have you some concerns with with the board power design?

 

 

 

[AxelFoley]

On 4/1/2019 at 11:50 PM, chwe said:

Just another reminder: https://forum.armbian.com/guidelines

especially this points here:

.... post some logs etc etc

@chwe My bad .... to be fair ... every time I loaded the forum to post logs from the unit itself ... it chromium crashed the board  :-)

I did not release that armbianmonitor posted to a urlupload site ... smart !

 

http://ix.io/1Fs4

 

See attached to the results from armbianmonitor -u

[AxelFoley]

Right I have now caught up with everybody's comments and questions and hopefully answered them.

I now need some guidance on what to do next ....

 

### Hypothesis 1 ###: 

The root cause of the instability was a fundamental issue with the current Armbian code base (kernel/driver) and the rockpro64 4GB V2.1 + NVME + 64GB EMMC triggered by chromium loading the Armbian forum (100% reproducible)

*** Action ***

Continue to troubleshoot the unstable cluster master when using Chromium and figure out how to trap the HW Lockup when chromium launches the Armbian forum (nothing captured in the system log files

The only hint I get is from launching Chromium from a terminal (thanks @NicoD I had no leads until you suggested this as it was a complete HW Freeze\Lockup);

 

root@rockpro64_0:~# chromium-browser
libGL error: unable to load driver: rockchip_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: rockchip
[17517:17517:0406/144119.625593:ERROR:sandbox_linux.cc(364)] InitializeSandbox() called with multiple threads in process gpu-process.
[17647:17672:0406/144121.185188:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.

 

 

### Hypothesis 2###:

The root cause of the issue is a corrupted Ambian installation caused by interruption to salt distributed "apt-get update && apt-get upgrade" (indicated by the need to force reinstall libegli due to missing libraries)

*** Action ***

Reformat the entire cluster using a desktop edition for the master and a cli version for the nodes and retest to see if we can recreate the issues with Chromium and also see if 20% of the nodes are still rebooting constantly.

 

I have a spare EMMC 64 Chip so I can save the current boot image on the cluster master if I need to go back to that image.

 

Q). Should I restart from scratch and reformat the cluster with an image recommended by this forum and I start testing from a known good stable place ?

(seems Armbian does not have anybody offering to test the RockPro64 4GB V 2.1 + PCIe NVME + BlueTooth\WiFi Module seeing as I have 10 of them I may be a good volunteer)  

 

Or

 

Should I look at validating the current master Armbian packages and kernel driver installs to make sure there was not a corrupted installation / driver configuration issue that may lead to unearthing a genuine bug report?

 

 

 

 

[NicoD]

2 hours ago, AxelFoley said:

Continue to troubleshoot the unstable cluster master when using Chromium and figure out how to trap the HW Lockup when chromium launches the Armbian forum (nothing captured in the system log files 

The only hint I get is from launching Chromium from a terminal (thanks @NicoD I had no leads until you suggested this as it was a complete HW Freeze\Lockup);

 

Did you turn off the gpu in chromium? It's been said somewhere above.

quote from AndrewDB
 

In Chromium (if you absolutely insist on using it instead of Firefox), check in advanced options if hardware acceleration support is enabled or not. If it is enabled, disable it. Also check your memory/swap usage while loading the Armbian Forum in Chromium. 

Or https://simpleit.rocks/linux/ubuntu/fixing-common-google-chrome-gpu-process-error-message-in-linux/
 

Could you tell us if Firefox does work? Or maybe Vivaldi Browser.

Best thing would be to build the latest image from Armbian and test that on one of your RockPro64s. Try many different thngs. Maybe compile the latest version of Chromium.

3 hours ago, AxelFoley said:

 

I love to see that. Looks vey nice.
You by now know the RockPro64 wasn't the best choice, but it can only improve(let's hope)

Measure the USB/GPIO voltage to see if the board has a stable voltage. The wattage/amperage isn't that important, as long as you stay under the total allowed by the PSU.
Good luck. I hope you're going to find a sollution quickly.
 

[AndrewDB]

17 hours ago, AxelFoley said:

libGL error: unable to load driver: rockchip_dri.so

This is all you need to know, actually. As I wrote before, this is a problem with hardware acceleration being used by Chromium. You can turn it off in advanced settings. 

[balbes150]

For what purpose do you need a cluster ?

[AxelFoley]

4 hours ago, AndrewDB said:

This is all you need to know, actually. As I wrote before, this is a problem with hardware acceleration being used by Chromium. You can turn it off in advanced settings. 

@AndrewDB apologies I missed the suggestion ... I disabled the HW Acceleration and restarted chrome from the terminal. Disabling the HW Acceleration stopped error messages being displayed in stdout.

However the rockpro64 still locked up with a HW freeze loading the Armbian  forum.  But I think the whole graphics drivers on some of my cluster node have gone foo-bar for some reason.

I may need to "apt install --reinstall [graphics subsystem packages] " to be sure that this is a bug not a missing library during interrupted apt update && apt upgrade

[AxelFoley]

1 hour ago, balbes150 said:

For what purpose do you need a cluster ?

@balbes150 It for prototyping, education and engineering ... essentially enabling a quick and dirty evaluation of SOA (Service Oriented Architecture) concepts for myself and some other devs. e.g. NOSQL Databases and in particular how to integrate Service discovery and RDMA paradigm's such as the OFED stack (RoCE), and building restFul interfaces & API Abstraction while understanding principles such as standardized Data and message models. In essence to evangelize open source software and frameworks as a solution to proprietary software integration & inter-operation inertia.

[chwe]

On 4/6/2019 at 3:07 PM, AxelFoley said:

Q). Should I restart from scratch and reformat the cluster with an image recommended by this forum and I start testing from a known good stable place ?

(seems Armbian does not have anybody offering to test the RockPro64 4GB V 2.1 + PCIe NVME + BlueTooth\WiFi Module seeing as I have 10 of them I may be a good volunteer)  

  

Or

 

Should I look at validating the current master Armbian packages and kernel driver installs to make sure there was not a corrupted installation / driver configuration issue that may lead to unearthing a genuine bug report?

 

or disconnect host from the cluster, remove the eMMC doing some tests with armbian on a spare eMMC, SD-Card whatever storage you prefer.. if the desktop part runs as expected add a few slaves from your cluster and see what happens... Having a installation which crashed (how many times) might probably be somehow somewhere corrupted..

 

It's not that we don't want to see your cluster running cause the platform is wip, but I would go for a more 'conservative' approach.. First fix the master without much attached to it.. and if this works as expected, let's see how you get the slaves properly connected to it.

[AndrewDB]

18 hours ago, AxelFoley said:

Disabling the HW Acceleration stopped error messages being displayed in stdout.

That's one problem solved, then.

18 hours ago, AxelFoley said:

However the rockpro64 still locked up with a HW freeze loading the Armbian  forum.

HW freeze without kernel messages and no ssh access = power supply problem with 99% probability, the other 1% is some other hardware problems.

[AndrewDB]

7 hours ago, chwe said:

I would go for a more 'conservative' approach.

@AxelFoley I agree with chwe. Btw I too have an armbian cluster for development purposes, 100% stable, 5 nodes, 32 x A53 cores. Total cost was around $100. PM me if you need more info.

 

andrew@andrew-ThinkPad-T420:~$ ssh andrew@192.168.51.24
 ____  ___  _ ____  
/ ___|/ _ \/ |___ \
\___ \ (_) | | __) |
 ___) \__, | |/ __/
|____/  /_/|_|_____|
                    

Welcome to ARMBIAN 5.75 user-built Ubuntu 18.04.2 LTS 4.20.5-aml-s912   
System load:   0.00 0.00 0.00   Up time:       41 days
Memory usage:  17 % of 837MB    Zram usage:    7 % of 418Mb     IP:            192.168.51.24
CPU temp:      40°C           
Usage of /:    49% of 15G    

[ General system configuration (beta): armbian-config ]


andrew@km8p2:~$

 

[AxelFoley]

Interesting!!!!    Fresh build on the spare EMMC64   Armbian_5.75_Rockpro64_Ubuntu_bionic_default_4.4.174_desktop.img

created new user pico after changing the root password.

 

The Device initiated nodm which initiated Xorg. Loaded the Armbian desktop ....... and hung immediately! HW Freeze and lock screen.

 

Subsequent boots only boot to command-line  with login prompt not desktop.   /etc/default/nodem still has user root as default user to log in not pico.

 

manually starting startx  results in black screen of death as pico user (or on second try HW lockup see attached) but root user loads desktop OK when running startx

 

I have done no apt upgrade && apt update

 

armbianmonitor -u results below.

http://ix.io/1FGs

 

mmc driver issues

[Mon Apr  8 19:23:29 2019] rockchip_mmc_get_phase: invalid clk rate
[Mon Apr  8 19:23:29 2019] rockchip_mmc_get_phase: invalid clk rate
[Mon Apr  8 19:23:29 2019] rockchip_mmc_get_phase: invalid clk rate
[Mon Apr  8 19:23:29 2019] rockchip_mmc_get_phase: invalid clk rate

 

PMU issues may affect efficiency of CPU idle when not under load
[Mon Apr  8 19:23:29 2019] rockchip_clk_register_frac_branch: could not find dclk_vop0_frac as parent of dclk_vop0, rate changes may not work
[Mon Apr  8 19:23:29 2019] rockchip_clk_register_frac_branch: could not find dclk_vop1_frac as parent of dclk_vop1, rate changes may not work

 

some possible pcie\nvme issues

[Mon Apr  8 19:23:30 2019] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
[Mon Apr  8 19:23:30 2019] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
[Mon Apr  8 19:23:30 2019] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
[Mon Apr  8 19:23:30 2019] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed

 

[Mon Apr  8 19:23:31 2019] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[Mon Apr  8 19:23:31 2019] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-1f] (conflicts with (null) [bus 00-1f])

 

some pwm issues

[Mon Apr  8 19:23:31 2019] pwm-regulator: supplied by vcc_sys
[Mon Apr  8 19:23:31 2019] vcc_sys: could not add device link regulator.8 err -2
[Mon Apr  8 19:23:31 2019] vcc_sys: could not add device link regulator.8 err -2

[Mon Apr  8 19:23:31 2019] vcc_sys: could not add device link regulator.11 err -2

.... etc a load of these

 

some sound driver issues

[Mon Apr  8 19:23:32 2019] of_get_named_gpiod_flags: can't parse 'simple-audio-card,hp-det-gpio' property of node '/spdif-sound[0]'
[Mon Apr  8 19:23:32 2019] of_get_named_gpiod_flags: can't parse 'simple-audio-card,mic-det-gpio' property of node '/spdif-sound[0]'
[Mon Apr  8 19:23:32 2019] rockchip-spdif ff870000.spdif: Missing dma channel for stream: 0
[Mon Apr  8 19:23:32 2019] rockchip-spdif ff870000.spdif: ASoC: pcm constructor failed: -22
[Mon Apr  8 19:23:32 2019] asoc-simple-card spdif-sound: ASoC: can't create pcm ff870000.spdif-dit-hifi :-22
[Mon Apr  8 19:23:32 2019] asoc-simple-card spdif-sound: ASoC: failed to instantiate card -22

 

some Ethernet nic issues (but still works)

[Mon Apr  8 19:23:46 2019] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[Mon Apr  8 19:24:02 2019] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[Mon Apr  8 19:24:35 2019] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[Mon Apr  8 19:25:39 2019] cdn-dp fec00000.dp: [drm:cdn_dp_request_firmware] *ERROR* Timed out trying to load firmware

[Mon Apr  8 19:23:32 2019] asoc-simple-card: probe of spdif-sound failed with error -22

[Myy]

On 4/6/2019 at 1:56 PM, AxelFoley said:

http://ix.io/1Fs4

Since the Ethernet driver is sending warnings, have you tried to launch Chromium on some static HTML files, without the Ethernet cable plugged in ?

[AxelFoley]

I think I have found the issue !!!!!!!

 

Its the PCIe Express NVMe Card.

 

I remove it and the desktop seems not to hang .... I add it back in .... and the desktop hangs.

 

I wonder if this has something to do with power spikes when there is graphics activity the errors in the dmesg indicate that

vpcie1v8 = 5.1v rail   Shared with GPU

vpcie0v9 = 3v Rail 

 

Both of these rails hang off the same core buck converter SY8113B, the other SY8113B manages the USB peripherals seperatly.

 

@AndrewDB    .... looks like you may be correct it was power all along  but it looks like its a kernel issue with the PCIe Power Management ?

 

[chwe]

it's always the power...

 

but one of the few time people got properly barrel plug powered devices down... might be a funny one for @tkaiser

 

PSUs don't like powerspikes.. when they run near to their limit.. what usually happens is that voltage drops and soonish the device locks up..

On 4/6/2019 at 1:44 PM, AxelFoley said:

Have you some concerns with with the board power design?

no.. but with your clusterbuilders powerdesign..

[NicoD]

32 minutes ago, chwe said:

but one of the few time people got properly barrel plug powered devices down... might be a funny one for

I've had it very badly with the OPi3 and a barrel jack to USB A cable. It was wose than on the RPi. Even moments of under 4V. Strange it didn't crash because of this. I also had it with my NanoPi M4 with USB type-c. Too long/bad cable was the cause.
So barrel jacks are no certainty of good power. My PSU's with barrel jack don't have this problem.

@AxelFoley Hope that'll be it. Good luck with it.

[pfry]

5 hours ago, chwe said:

it's always the power...

[...]

no.. but with your clusterbuilders powerdesign..

The board power design is interesting. I'd expected a more (even more?) uniform reference implementation across RK3399 designs. The RockPro64 uses a 5V 3A regulator to power... well, the board, essentially. The NanoPC-T4 uses a 3.3V 8A regulator for the same purpose, so it has no additional regulator for its M.2 slot, while the RockPro64 has a 3.3V (in this case) 2A (3A peak) regulator for its 3.3V bus (which includes the PCI-e slot). So Friendly makes 25W available on the NanoPC-T4 where Pine64 has 15W for the RockPro64 (the power domains appear to be equivalent); in addition, 2-3A seems low for a 3.3V domain that includes a PCI-e slot (alone rated at 3A). I'm not an EE and I haven't done any testing, so my opinion is worth less than the time it takes to read this. Still, it's interesting.

The Samsung 970EVO consumes what? 3.3V 1.8A peak? I doubt the PCI-e -> M.2 card has any on-board regulation (to utilize the 12V power); other devices on the 3.3V bus include the USB, Wi-fi, Ethernet and SPDIF phys, and the eMMC - none likely to be a heavy draw.

Aside: the NanoPC-T4 also has an 8A regulator for 5V (USB and audio). I'm paranoid, so I glued heat sinks to the SY837 and 838, the NB680 (3.3V regulator) and the RK808 on my NanoPC-T4. They don't even get warm. The RK3399, on the other hand...