Rodrigo V. Lopes

ok, I've managed to sort this out on my own. I've decompiled the rockchip-rockpi4.dtb and find out that pwm is disabled by default. So I've wrote new overlay for pwm, just to enable it : 
 
/dts-v1/; / { compatible = "rockchip,rk3399"; fragment@0 { target-path = "/aliases"; __overlay__ { pwm0 = "/pwm@ff420000"; pwm1 = "/pwm@ff420010"; }; }; fragment@1 { target-path = "/pwm@ff420000"; __overlay__ { status = "okay"; }; }; fragment@2 { target-path = "/pwm@ff420010"; __overlay__ { status = "okay"; }; }; }; next, compiled it with dtc : 
dtc -O dtb -o rockchip-pwm-gpio.dtbo -b 0 -@ rockchip-pwm-gpio.dts and moved dtbo to /boot/dtc/rockchip/overlays, and activated it in overlays in /boot/armbianEnv.txt.
 
Now PWM works like a charm. I'm just leaving this thread and my resolution as reference, for anyone with the same problem.
 

First, "armbian-monitor -u". Edit your top post and add it at the top.
 
What you're seeing is initial ramfs (or initramfs), but is often written as inital ramdisk (or initrd) for historical reasons. It's singular job is to mount the root filesystem before init / SystemD takes over. It's basically a compressed archive (CPIO) of a bunch of scripts made by initramfs-tools (or dracut on systems like Redhat) that load drivers and pivot to the real filesystem before continuing.
 
In this case, it's attempting to mount the device listed as "/dev/mmcblk0p1", and it can't find it, and eventually gave up. Linux is running, but boot is stuck.
 
If the MMC interface is anything like the Ethernet subsystem, devices get enumerated based on the order they are found. So eth0 is first, eth1 is second and so forth. If two drivers load at the same time, there's a possible race condition and they can flip occasionally, and even change behavior after a software update. This is also the reason for the "persistent" Ethernet device names like "enp3s2" which are crazy looking, but deterministic.
 
I've noticed that many ARM boards get device names from the DTB aliases. But maybe it's not being used for whatever reason? Not sure.
 
In the meantime, if mmcblk0 and mmcblk1 occasionally swap position, it's probably far better to specify your root device via LABEL or even better, by UUID.
 
$ sudo blkid /dev/mmcblk0p1  
Then change your boot arguments to include "root=UUID=<WHATEVER>". Should be in /etc/armbianEnv.txt. but don't have it in front of me at the moment.
 
Also update your /etc/fstab to point to "UUID=<WHATEVER>", else you won't get much further.
 
More information on initramfs-tools, and boot arguments: https://manpages.debian.org/testing/initramfs-tools-core/initramfs-tools.7.en.html