RockPi 4b 'board bring up'

[TonyMac32]

Well, there has been a lot of peripheral stuff going I with Rockchip as well, I have a lot of catching up to do now that my build machine is building again. I think 5.2 may be the more interesting

Sent from my Pixel using Tapatalk

[NicoD]

1 minute ago, TonyMac32 said:

I think 5.2 may be the more interesting

That's also the one I'm waiting for. 5.1 is nice. But what's promised for 5.2 seems amazing. Lima, Panfrost and Cedrus h264 for multiple Allwinner SoC's. And the H6's should be a lot better then too.
And that's only for Allwinner. Great for the SBC community.
Can't wait for it.

[chwe]

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.. 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]

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]

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]

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.

 

 

and 68 seconds later it continues:

 

Edited May 1, 2020 by Tido
systemctl stop bluetooth.service