piter75

Network issues are solved upstream.
eMMC tweak for your board is not in the build system yet. I will prepare it soon and give you a shout.

I have taken another route with this PR.
I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
Higher MTUs would require further shortening of the PBL.
 
I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.

The issue is fixed in v5.4.11 - I removed the patch from the build system for future builds.

See my post regarding Armbian for Rock Pi S on Radxa's forum.
 
Since then:
kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested.
I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks.
 
Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6.
I will probably prepare a "dev" kernel with one of 5.5 RCs soon.

See my post regarding Armbian for Rock Pi S on Radxa's forum.
 
Since then:
kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested.
I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks.
 
Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6.
I will probably prepare a "dev" kernel with one of 5.5 RCs soon.

Totally agree. This is the only way to get help in this case.
 
This crossed my mind before and I think it is a good idea.
We already have it in place for Rock Pi 4b (it was implemented before we had Rock Pi 4a as a separate board) and it works well when used with the same u-boot version on eMMC and SD.
 
@raidboy you can try to use Rock Pi 4b image which has priority set to SD and see if it works better in this scenario. Nothing is guaranteed as you are mixing stages of u-boots compiled with different configurations and even different code bases so... YMMV.

So it seems to be the same issue I had.
I will add the patch to the build as it does not seem to harm the eMMC modules that boot also without it.
 
The problem is definitely with 5.4.7+.
Others also started noticing and patching for it: https://gist.github.com/jakogut/bc21de0535b640f2374c1d07a710e8ab
I did not notice it as currently I am mostly spending time with NanoPi M4V2 which have mdio and phy nodes already setup in device tree.
Will dig a bit more into that issue.

Edit: hack deleted. Link to working patches added.
 
Patches to enable 12V from MPS MP8859 regulator.
https://github.com/Reichl/linux-next-roc-pc/commit/54ecff244bee053de72230f0b989b4a480d06ec2
and it's parents.

My Rock Pi 4B boots fine from eMMC in hs400es mode with 5.4.x but... I remember having similar issues to yours on one of Rock Pi 4A I had.
I found the difference between 5.x and 4.4 in regards to hs400es initialisation that made it work but finally returned the unit and did not pursue it any further.
 
Can you try building yourself an image with below patch applied or use the precompiled image I shared and see if it boots fine using eMMC?
fix-hs400es-init-on-some-boards.patch

there's a tool to test this:
 
https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test
 
@tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind
https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3
https://github.com/armbian/build/issues/546
 
 

Well... exactly. It also freezes some more packages.
 
I am not much of a "UI" guy ;-)

Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:
lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.
This should workaround power issues when powering from usb-c with pd compliant power units.

Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:
lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.
This should workaround power issues when powering from usb-c with pd compliant power units.

Sure, I was thinking about it.
Feeling motivated by your message  I will do that tonight

A lot of credit goes also to you
Once again thanks for testing the images since the beginning.
 
As for the slow boot it plaques now all rk3399 boards.
I am tempted to bring the following hack to Armbian: https://gitlab.collabora.com/rockpi/linux/commit/ea2fb5589b4cd92728a6139ee5043945d3e10173
I am using it for weeks now in my builds and don't regret it ;-)

I rebased my branch onto latest master changes.
Took me some time to make the sound working in kernel 5.4.
 
Branch is now named nanopi-m4v2-bring-up and supports "legacy", "current" and "dev" targets.
Did not test "legacy" much yet but "current" 5.4 works quite well.
In dev wi-fi is broken, but anyway "current" is much more compelling as it is 5.4 vs. 5.4-rc1 in dev.
 
Command line for "current":
./compile.sh BOARD=nanopim4v2 BRANCH=current RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no  

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

What we have right now is, probably, exactly what you wanted to achieve:
Option 2 for building Option 3 for packaging This boils down to having all bootloader components built from source code as opposed to having to load binary blob from vendor in the process.
 
I am not an expert on ATF but I understand it as a firmware running in a secure zone of the processor with a set of interfaces (eg. PSCI for power control) that let it interact with the rest of the software.
Not using ATF would mean that one had to code those interfaces themselves.

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

IMHO It could never work with mainline kernel.
At first it was named "RockPi-4B" in Armbian's custom device tree and then it was renamed to "Radxa ROCK Pi 4" following Rock Pi 4's device tree upstreaming somewhere around July.
 
At this point you could:
use "default" image which should work fine with "libmraa" make yourself and overlay with a model change to survive kernel updates try adjusting "libmraa" to make it work with mainline kernel (and upstreaming the change) - probably by the means of verifying that "compatible" contains "radxa,rockpi4" 3rd option would be best in the long run IMO.

There is one thing that comes to my mind... I have some features disabled in my config-minimal.conf.
I have AUFS disabled for sure, which is irrelevant. Will let you know about the rest later.
 
Dev kernel should have a sound card working by now 😉

Ok, the causes of the crashes could be different for us as I use it solely in the terminal
 
Anyway, I did something which I cannot imagine could help but... it seems that it helped.
I remember reading somewhere lately about instability of PX30 at 408MHz that was avoided by changing min frequency to 600MHz.
Our images for RK3399 have default min of 600MHz so I did the opposite and changed the min to 408MHz.
 
I will definitely observe it for a longer time but last 40-50 reboots were clean of errors while before it happened every 3-5 reboot.

I have been happily booting Rock Pi 4B v1.4 since August with both eMMC and SD.
As others already pointed it would be good if you had some console logs.
 
At this point I am running custom Armbian build based on latest u-boot and open source ATF but will burn SD with latest "official" image, check if it boots and will get back with the results.