RockPi 4b 'board bring up'

chwe · May 7, 2019

3 hours ago, NicoD said:

I saw that "new hardware : RockPi4"

means initial device tree is now upstream.. Doesn't mean that this is complete... e.g. you want thing anything like:

https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch

on the other hand, our RX & TX settings for gmac slightly differ:

+	tx_delay = <0x28>;
+	rx_delay = <0x20>;

https://github.com/armbian/build/blob/66b5cea466557222d8a9d4f140f7c9e3b3acee4f/patch/kernel/rockchip64-dev/add-board-rockpi4b.patch#L304-L305

	tx_delay = <0x28>;
	rx_delay = <0x11>;

https://github.com/torvalds/linux/blob/8ff468c29e9a9c3afe9152c10c7b141343270bf3/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts#L155-L156

maybe this makes a difference.. who knows.. It's not that 5.1 will be boring.. But I would only push if first Ayufan pushes as well and second we can adjust all patches in one attempt..

3 hours ago, TonyMac32 said:

Well, there has been a lot of peripheral stuff going I with Rockchip as well,

It's not that there isn't anything interesting.. You will probably know in which parts I'm interested due to a few PMs.. :lol: But I still think that some of them are just not ready yet.. Or might need additional DT tweaking.

3 hours ago, TonyMac32 said:

I think 5.2 may be the more interesting

and then.. 5.3 will be more interesting cause maybe a LTS kernel (~3 months/kernel means november - okay.. if we assume 2 months/kernel then it will be 5.4 who cares)..

We definitively should push to either 5.1 or 5.2 to avoid having to much to fix later.. But it's IMO not priority.

TonyMac32 · May 8, 2019

3 hours ago, chwe said:

on the other hand, our RX & TX settings for gmac slightly differ:

ours weren't for the RockPi, so that's why.

Honestly I've kind of snoozed on RK3399 with all the ridiculous U-boot nonsense, then my build machine was being difficult...

chwe · May 8, 2019

11 hours ago, TonyMac32 said:

ours weren't for the RockPi, so that's why.

I know where the whole device tree comes from. But since I never had network issues (e.g. lot of dropped packages or bad performance).. I didn't tried to nail down those settings.. BTW. The settings we find for the rockpi come likely from here:

https://github.com/radxa/kernel/blob/33fb3acc053189406d28184582239e952abe3589/arch/arm64/boot/dts/rockchip/rock960-model-c-linux.dts#L956-L957

https://github.com/radxa/kernel/blob/33fb3acc053189406d28184582239e952abe3589/arch/arm64/boot/dts/rockchip/rock960-model-ab-linux.dts#L979-L980

https://github.com/radxa/kernel/blob/33fb3acc053189406d28184582239e952abe3589/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi#L247-L248

https://github.com/radxa/kernel/blob/33fb3acc053189406d28184582239e952abe3589/arch/arm64/boot/dts/rockchip/rk3399-evb.dtsi#L525-L526

which locks like reference design.

Tido · May 1, 2020

Hi,

I try to set up the server of Armbian_20.02.1_Rockpi-4b_buster_current_5.4.20.img - as the boot was very slow I wanted to see the systemd-analyze plot

systemd-analyze plot > RockPi4B_boottime-$(date +%Y%m%d_%H%M%S).svg

Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

tido@rockpi-4b:~/just_data$ systemctl list-jobs
JOB UNIT                                 TYPE  STATE  
109 rk3399-bluetooth.service             start running
  1 graphical.target                     start waiting
110 systemd-update-utmp-runlevel.service start waiting
  2 multi-user.target                    start waiting

4 jobs listed.

The system itself is updated and rebooted:

Spoiler


All packages are up to date.

root@rockpi-4b:/home/tido/just_data# apt upgrade 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

RPi-Monitor doesn't work on Buster, but did so on Armbian_20.02.1_Rockpi-4b_bionic_legacy_4.4.213_desktop.img

Spoiler


root@rockpi-4b:/home/tido/just_data# armbianmonitor -r
Installing RPi-Monitor. This can take up to 5 minutes. Be patient pleaseE: Unable to locate package rpimonitor

/usr/bin/armbianmonitor: line 697: /usr/share/rpimonitor/scripts/updatePackagesStatus.pl: No such file or directory
/usr/bin/armbianmonitor: line 193: /etc/rpimonitor/template/raspbian.conf: No such file or directory
/usr/bin/armbianmonitor: line 196: cd: /etc/rpimonitor/: No such file or directory

sed: can't read /etc/rpimonitor/template/temperature.conf: No such file or directory
sed: can't read /etc/rpimonitor/template/cpu.conf: No such file or directory
sed: can't read /etc/rpimonitor/template/version.conf: No such file or directory

Now you're able to enjoy RPi-Monitor at http://192.168.11.5:8888

Is this in relation with the 5.x Kernel? Linux rockpi-4b 5.4.32-rockchip64 #20.02.11 SMP PREEMPT Tue Apr 14 17:30:19 CEST 2020

Looks like bluetooth was responsible for the 'hanger'.. and a picture of the situation:

It was difficult to get a proper plot, so that gThumb doesn't crash. I reached that goal by disabling: sudo systemctl disable rk3399-bluetooth.service ; the plot reduced from 1,4MB to 181kB.

However, the boot itself takes an eternity, here some more details, from serial-getty@ttyS2.service (at 66 seconds) to launch user-1000.slice (at 134 sec.) Booting completed at 145 seconds.

grafik.png.23905b5ea713b249cf7b9c547043d95f.png