My Rockpi5 4GB using 16GBmicro SD arrived and I am trying to get it set up. Burning Debian went well, but, I can’t make any kind of internet connection, I see no eth0 though ifconfig does give me an ip address.
the suggestion to use dhclient enP4p65s0 returns a warnng that /etc/resolve.conf is not a symbolic link
Im currently unable to update/upgrade or install any software, can anyone suggest a resolution?
ip a blah blah network blah to get a message length
PS what image are you using?
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enP4p65s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:e0:4c:68:00:b3 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.25/24 brd 192.168.1.255 scope global dynamic noprefixroute enP4p65s0
valid_lft 81324sec preferred_lft 81324sec
inet6 fdd4:40f0:f40b:b400:1491:2840:9237:af50/64 scope global temporary dynamic
valid_lft 6796sec preferred_lft 3196sec
inet6 fdd4:40f0:f40b:b400:b9ae:9eda:9149:4777/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6796sec preferred_lft 3196sec
inet6 fe80::c85d:e428:d7cb:d6e1/64 scope link noprefixroute
valid_lft forever preferred_lft forever
rock@rock-5b:~$ ifconfig
enP4p65s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.25 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fdd4:40f0:f40b:b400:b9ae:9eda:9149:4777 prefixlen 64 scopeid 0x0<global>
inet6 fe80::c85d:e428:d7cb:d6e1 prefixlen 64 scopeid 0x20<link>
inet6 fdd4:40f0:f40b:b400:1491:2840:9237:af50 prefixlen 64 scopeid 0x0<global>
ether 00:e0:4c:68:00:b3 txqueuelen 1000 (Ethernet)
RX packets 7620 bytes 5516042 (5.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3024 bytes 250630 (250.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 134
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 285 bytes 22607 (22.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 285 bytes 22607 (22.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
its the debian 11 from the rockpi 5 download page , not quite sure what the rest of your message is asking?
Lols it was just to get a minimum msg length 
Then tacked on the rest
There isn’t eth0 it is enP4p65s0 that is you eth connection, but not sure why you can not update/upgrade if you are being allocated an ip address
ah ok
I think it was an issue with my work server, not being too happy with allowing access.
I just hooked it up at my home system and its now perfectly fine, so I can install and update
thanks
ok with the internet connected I was able to install a few things and do a test build of my Raspberry Pi4 project with its high intensive graphics and… yeah it worked, not 100%, a few things are going a bit wrong but even so…quite impressive,. Normally it takes a few days to get a build up and running on a new machine, and often I have to give up.
I read somewhere that Rockpi5 debian does not have graphic drivers, is that true? If so its doing an amazing amount of work emulating the OpenGLES3.1 performance of my project, clock 30fps wth Anti aliasing enabled.
No the debian drivers are installed they are just not that great. There is a MCU in the GPU called a Command Stream Frontend.
What we have and the way the kernel works is not doing that great a job as if we check
cat /sys/devices/platform/fb000000.gpu/utilisation you will prob find its only about 40%
Which is good and bad news as there is far more performance to be had but the drivers currently likely with the CSF are not acting like a asynchronous co-ordinator for cpu & gpu irq co-ord so they have some parallism as think cpu & gpu are acting synchronously.
The OpenCl methods seem to be better as if you use this as a base.
Then do a few hacks so we don’t have the cpu doing a lot of work whilst the gpu is running ML
Then via openCl cat /sys/devices/platform/fb000000.gpu/utilisation is about 75%
Thats very interesting, and ineed it bodes well for future updates, There’s a lot of GPU power here that will be nice to have fully optimised
I think we need to get off the Rockchip BSP (Board Support Package) that is an Android kernel of 5.10 as there is this chicken & egg situation where much work currently is to get that 100% for users, but likely will swap to mainline linux as elements are added (I think a very basic boot setup is all that mainline has) so not much action yet.
If you want to test and try the GPU with more load then for ML OpenCl can gets loads of approx 75%.
I did a bit of a simple guide to get the ArmNN tutorial going and a better run script that doesn’t mix CPU & GPU code as it runs inference after the whole audio have been converted to MFCC.
Run on Ubuntu as ArmNN seems very distro sensitive but the Radxa Debian image you can run Glmark2-Es2 where the GPU is working but with the CSF and everything GPU loading is only about 40%
In the above I was also interested in power consumption where loading the cpu with stress-ng -c 8 and running inference on GPU causes approx 11.5 watt which think is maybe total for GPU of 4-5watt which like the CPU is considerable power for wattage.
Mainline can be a long wait as increments are pushed out to Linux-next where on release the next increments take place, it can be a really slow process, but as a SoC the rk3588/S seems to have had much adoption by many vendors which will help.
as tempting as that is I find digging into drivers too much of a rabbit hole for me, I prefer to use out of the box systems so that my experience is as average as possible.
I am sure that the improvments will come, becuase honestly this is a nice bit of kit, its rare that I am able to get my game projects up and running so quickly on a target other than the Raspberry4 which this is optimized for.
I managed to “fix” the poly clash issues by changing the shader precision to highp from mediump though of course I should be able to expect mediump to work fine it still seems to be doing pretty well, on a fairly rough render system in debug mode…
You can colour me impressed with this board. I still have some minor issue going on with my mouse seletion systems but pretty sure thats my code not the hardware, however fixing it on the RockPi5 will probably resolve/improve it on the Rpi4