FossCoder

Great thanks, this worked for me!
 
I had the same problem as Antoine: I already owned one ROCK64 board and I just added other 2 (v3.0 2018-1105) and I was having issues with the network. All of them had the same MAC and efuse is empty also.
 
$ xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
 
I flashed the image (Armbian_20.11.3_Rock64_focal_current_5.9.14_desktop in my case) on the eMMC and then I modified /etc/network/interfaces before starting for the first time, and all worked like a charm.
 
I usually modify also the hostnames, so the avahi announce on the network is different for each board.
 

After much searching, reading, testing and failures; this worked for me on Armbian.
Create /etc/fw_env.config with:
/dev/mmcblk0            0x3F8000        0x8000 Ensure good settings by running fw_printenv, ensure no CRC error.
# fw_printenv
arch=arm
baudrate=1500000
board=evb_rk3328
board_name=evb_rk3328
... Set new MAC address using fw_setenv
# fw_setenv ethaddr {new MAC} Reboot, confirm MAC address with 'ip link' I tried using the Windows tools to much failure. Once I put in good fw_env.config settings standard tools under Linux "just worked".
Happily removed udev rule, no need for extra setup in /etc/network/.

I got this working changing it in /etc/network/interfaces:
 

This is actually good news that they are present and are different
Do you see the production week markings on top of the package? What is it? - both of mine are 1810.
 
I must admit that this scenario crossed my mind when I read that you have two boards. The explanation is a bit long but pretty simple...
 
Many boards that Armbian support does not have a stable MAC address and have it randomly generated on each startup.
On the first run Armbian checks the current MAC and creates the NM connection configuration with this random MAC as cloned address.
Thanks to this the next time you boot the board it uses this MAC instead of another generated one achieving some degree of stability - until next reimage.
 
With Rockchip (rk3328 and rk3399 at least) it is a bit different as the MACs for first two ethernet interfaces are generated based on CPUID stored in CPU's NVRAM.
Armbian does not recognise it (not all versions of u-boot can do this generation) and also saves this MAC as a cloned MAC in NM connection settings.
 
When you switched the SD card between boards you started assigning a stable MAC address from the first board to the second one (as a cloned MAC) and the first one was still using the same stable MAC that's assigned to it ;-)
The best you could do IMHO in this situation would be to simply delete the cloned-mac-address stance from connection files on both of your boards and enjoy two stable and different MACs for your boards

Is the result of the following command anything different than mine?
root@rock64:~# xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Both of my rock64 CPUs have their efuse empty and thus both also have the same mac address which is generated by u-boot and based on CPUID. CPUID should be present in bytes 0x07 - 0x16.
I always wondered if it is a common issue...
I also have ROCK Pi E and NanoPi R2S - both based on RK3328 - but they have their efuses set.
 
Did you deactivate and activate the connection after editing cloned mac address?
 
My "/etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection" looks like this and it overrides the default mac address
 
 

@ejolson Do you have a technique for determining the current clock speed of the memory?
 
Thanks!

Since this is the thread linked on the Rock64 page with "In case you face stability issues, check this", I'm posting my issue experience and different workaround here.
 
After getting pretty consistent freezing even while idle on my 1GB Rock64 board I flashed the SPI to enable USB boot and switched to booting from external SSD drive rather than SD card and it has completely cleared up my freezing issues while also giving a huge performance/storage boost.
 
The board has been able achieve a stable uptime of over 60 days, now only intentionally going down for power losses or updates. Reverting back to booting from SD card immediately brings back the random freezing issues and occurs with multiple known good high quality cards from Samsung & Sandisk. I've maintained this no-SD card / USB boot stability through several upgrades since July 2020, current stable set up is Focal 5.9.14-rockchip64.
 
I don't know if there is a relationship between the higher memory speed and SD card access causing the issue as I never tried under-clocking the memory or if this is a separate issue altogether, but for those experiencing stability issues this might fix it for you as well while adding some performance rather than taking it away.
 
Ref:
Ayufan SPI flash to enable USB boot - https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md
 

Here is a performance comparison between the original 786MHz memory clock and the reduced 333MHz clock when running John McCalpin's stream memory bandwidth benchmark.
 


The performance reduction for the scale operation was measured to be about 2.26 times which is slightly less than the expected 786/333=2.36 factor loss expected by just dividing out the clocks.
In real world applications much of this performance reduction might be mitigated by cache memory; however, it would seem having a 600MHz setting might be a better compromise between super slow and super unstable.
 
At any rate, I'll be performing some stress tests over the next few days to determine whether the system is really stable now.  For reference, I also have a thread running on the Pine64 forum
 
https://forum.pine64.org/showthread.php?tid=11209&pid=76363#pid76363
 
and will update both as resolved as soon as I verify the system is now stable.

It seems patching the SD card is not very difficult.  I downloaded
 
rk3328_ddr_333MHz_v1.16.bin
rk3328_miniloader_v2.46.bin
 
Then I followed the instructions on
 
http://opensource.rock-chips.com/wiki_Boot_option
 
typed as root

# mkimage -n rk3328 -T rksd -d rk3328_ddr_333MHz_v1.16.bin idbloader16.img # cat rk3328_miniloader_v2.46.bin >>idbloader16.img # dd if=idbloader16.img of=/dev/mmcblk0 seek=64 conv=notrunc # sync
and then rebooted.
 
I'll report back later how much slower everything is later and whether the segmentation faults and kernel oops are gone.  Thanks for all your work on Armbian!

My understanding is that this is a common problem with the Rock64 v2 boards and simply the result of some optimistic overclocking that should never have been done in the first place.  While such overclocking appears to be necessary to meet the minimum performance needed for playing back certain high-definition video, my usage for the Rock64 is not watching television but for it to function as a computer.
 
This is essentially a new board that sat in storage for six months due to certain shelter at home rules.  As returning it is not an option, I would instead like to reduce the memory frequency to a rate that runs reliably.  I was having difficulty converting the instructions I read for Arch Linux to Armbian and thought I'd ask here.  Before adding some more waste to the landfill, I'd like to give the 333 MHz option a thorough test.
 
I understand your reluctance to assist.  It must be irritating to continually deal with manufacturers that cut corners in unexpected ways with later revisions of their hardware.  Any guidance how to get started rebuilding the uboot initialization code for Armbian with the desired memory frequency would be appreciated.

We need to see serial console logs.

I have 85 tinkers running with armbian 5.41 xenial next 4.14.23.  Normally I run a script that apt upgrades them all but I run a small batch of them first as a test.  Today I ran apt update/upgrade on three of them and they are all bricked.  No output to the screen.  Can't ping them.  Any ideas?