piter75

This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.

This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.

This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.

Did you change the mac address of the interface by using `btmgmt` according to this message?
Without it the device is using default mac address from firmware and thus is set to `DOWN RAW` status.
 

I advise sticking with the legacy kernel until the stability issues with the current kernels (specific to the NanoPi M4 V2) have been resolved.

It is fixed for some time already. It's just that there were no releases built for the board in the meantime.
It is however part of v20.05.1 - after you upgrade you should not see it disappearing again.

u-boot does not recognise the storage and tries to boot from network.
I see that you have built yourself an image yesterday but it is probably using some old Armbian build repository revision as it still uses v2017.09 u-boot which is switched to mainline for RockPi 4 in current sources.
 
Did you also try to use the ready made v20.05.1 images from https://dl.armbian.com/rockpi-4b/archive/? Does it also get stuck with them?
 
Please use Spoiler next time for boot log ;-)

You are right, eMMC modules are compatible with both M4 and M4V2.
Do you install eMMC modules the right way? eMMC in M4V2 needs to be rotated 180º vs. the way it was installed in your M4.

There are some older threads where people noticed it too, myself included 
 
Would you like to participate in testing of a possible cure workaround for those issues?
Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
 
I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.

You probably meant RockPro64 which is indeed a SBC name that is now part of rockchip64 family.
 
Well... IMHO the name is fitting well.
 
The idea of rockchip64 family is to consolidate one day all (rockchip 64) bit boards if possible - that means all based on 64 bit SoCs, eg. rk3328, rk3399 and rk3308.
The rockchip64 family is nothing new - it already exists and contains rk3328 and rk3399 boards.

There are some older threads where people noticed it too, myself included 
 
Would you like to participate in testing of a possible cure workaround for those issues?
Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
 
I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.

I wonder what was actually changed to fix this.
Nonetheless we will keep our changes in u-boot for the "current" target which is v5.4.x

Mainline kernel is known to be unstable for this board
Legacy is the way to go for now if you want it stable.

I had a lot of stability issues with the original Orange Pi image, and it's running like a charm with Armbian.
Thanks, folks!

FYI. I am talking with Olimex to produce this board in a quantity of around 20 pcs.

Well done!
 
I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)

Well done!
 
I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)

Well done!
 
I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

So initially I had some trouble booting the Armbian images even the one I built locally.
I'm certain this was because I had not properly wiped the MicroSD card after trying out the images from Orange Pi (I ended up using gparted to create an new msdos partition table) .
Anyway I got around to testing some of the images and though I'd post the state of those as well:
 
1. Armbian_19.11.9_Orangepi4_buster_current_5.4.16_minimal.img
This was the image found here on Page 3 posted by @piter75
It seemed to boot fine. eth0 and WLAN exist but I did not get connectivity (this was an issue with my router)
https://asciinema.org/a/313413
2. Armbian_20.02.6_Orangepi4_bionic_current_5.4.27_minimal.img
Downloaded from https://www.armbian.com/orange-pi-4/#kernels-archive-all
Some issues seen during booting, but eventually it boots.
eth0 and WLAN exist but I did not get connectivity due to my router
https://asciinema.org/a/313424
3. Armbian_20.05.0-trunk_Orangepi4_bionic_current_5.4.27_minimal.img
Image built locally using the docker guide.
Kernel seems to take a bit longer to boot and there is no output from it as before.
eth0 and WLAN exist, after messing with router eth0 works as expected.
https://asciinema.org/a/313427
Image available at https://mega.nz/#!jgZmzAzb!yp-g2viNrXAjO-rpM_25meDVBNSxOo2I8gOqD6t-p7g
4. Armbian_20.05.0-trunk_Orangepi4_bionic_dev_5.5.13_minimal.img
Image built locally using the docker guide.
Kernel seems to take a bit longer to boot and there is no output from it as before.
eth0 and WLAN exist, after messing with router eth0 works as expected.
https://asciinema.org/a/313445
Image available at https://mega.nz/#!LpIinS5I!MzscJ_tS5S4_5pcxpz5CZXKUeFxf3LdeE8IBIfORl-A

All images flashed with Etcher
MicroSD was Samsung Evo Select 64GB
Board was OrangePi 4 4GB v1.3 without eMMC (cheapest config for this RAM)
PSU was the USB barrel connector to a known good phone charger.
 
I also tried out the mPCIe adapter with a mPCIe SATA card (ASM1061). The speeds were disappointing at max 210mb/s considering the card can definitely do 350mb/s+ in my laptop.
I had hoped the newest os/kernel version would solve this, but it does not appear to do so. Maybe my testing methodology is wrong but I am doubting this after trying 2 different cards and multiple OSs.
Another thing to note is that this board runs hot at ~75*C even with a small heatsink (no fan was used) and little going on.
 
If anyone has something they'd like me to try then please ask.

Unfortunately... yes. I did not test the upgrade path with latest changes
 
At this point, if you can discard your install, you can download latest image (v20.02.06 / v4.4.217).
If you want to recover your install you need to mount the SD in some other PC or SBC and modify "boot/armbianEnv.txt" as follows:
add line overlays=uart0 change overlay_prefix line to overlay_prefix=rk3308 I will be more careful next time...
 
As for the Radxa repos I don't use them.

+ updates to: rockpis, rockchip64 and odroidxu4 legacy kernel

Do you happen to be using the same SD card that you used previously for Xunlong's BSP?
If so this is a known issue: 
 

We could do that but I am pretty sure, although of course may be wrong ;p, that it's not a CPU frequency issue.
 
What I observed so far is that most of the time when I cold boot the board I see following lines at the end of DDR training in Rockchip's binary:
change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 0, cs 1, advanced training done channel 1, cs 0, advanced training done channel 1, cs 1, advanced training done channel 1, cs 0, dq 31 RISK!!! TdiVW_total violate spec channel 1, cs 1, dq 31 RISK!!! TdiVW_total violate spec ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 Those "dq 31 RISK!!! TdiVW_total violate spec" lines do not look promising.
OTOH most of the times when I reboot the board after some time I do not see those lines which may mean that memory chips used in M4V2 require a bit different params.
As a piece of additional info, I also tried to use u-boot's TPL to train LPDDR4 in v2020.01 and although it works well for RockPi 4, RockPro64 and ROC-RK3399-PC it ends up with a kernel crash on 100% of boots with M4V2

I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
 
I did not have any issues with it on my boards so I did not pursue to change it but...
When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
https://github.com/armbian/build/compare/rk3399-disable-overclocking
 
It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.