OK,I'll try to adjust again.
I made changes to 100-rockchip-rk3328-Add-support-for-FriendlyARM-NanoPi-R.patch according to commit.
- added startup-delay-us = <2000> to vcc_sdio;
- added +CONFIG_REGULATOR_GPIO = y
Finally, it still won't boot on my SD card.
@wevsty I can't apply the patch, I get this error:
~/openwrt$ git am 3277.patch
Applying: Add startup-delay-us to fix the issue of not booting on some MicroSD cards.
Applying: * uboot-rockchip: Fix NanoPi R2S some boot failed
error: patch failed: package/boot/uboot-rockchip/patches/100-rockchip-rk3328-Add-support-for-FriendlyARM-NanoPi-R.patch:75
error: package/boot/uboot-rockchip/patches/100-rockchip-rk3328-Add-support-for-FriendlyARM-NanoPi-R.patch: patch does not apply
Patch failed at 0002 * uboot-rockchip: Fix NanoPi R2S some boot failed
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Please simply download and replace the original file.
download link: https://github.com/openwrt/openwrt/raw/001654d8e9a84ca2f022a63dd99313bc48d8cf61/package/boot/uboot-rockchip/patches/100-rockchip-rk3328-Add-support-for-FriendlyARM-NanoPi-R.patch
Path is:
package/boot/uboot-rockchip/patches/100-rockchip-rk3328-Add-support-for-FriendlyARM-NanoPi-R.patch
You can recompile it directly after replacement.
I tried but didn't make any difference, it boots fine with the ext4 images and fails with squashfs images.
Please check to make sure you are using the latest link I posted above, I had some problems with the first link I posted.
EXT4 did boot successfully, can you post the boot log for squashfs?
Please tell me the make and model of the SD card.
If anybody is using squashfs image and has trouble setting up extroot, this is the bug.
https://bugs.openwrt.org/index.php?do=details&task_id=2231
I made a patch to it, and it should provide extroot support for squashfs image for all type of devices (e.g. x86). Now just need someone from openwrt to review and merge it..
It's terribly unstable. The USB ethernet adapter sucks. It crashed 3 times the first day I set it up. I think that's why it's cheap.
Hi,
Does anyone else have a problem with sensors command?
It worked with jayanta525's build, but after he merged it with master branch, it stopped working.
root@np0:~# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
root@np0:~#
root@np0:~# cat /sys/class/thermal/thermal_zone0/type
soc-thermal
root@np0:~# cat /sys/class/thermal/thermal_zone0/temp
49545
root@np0:~#
root@np0:~# ls -la /etc/sensors.conf /etc/sensors3.conf
ls: /etc/sensors.conf: No such file or directory
ls: /etc/sensors3.conf: No such file or directory
root@np0:~#
root@np0:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r14096-4f1a51f438'
DISTRIB_TARGET='rockchip/armv8'
DISTRIB_ARCH='aarch64_generic'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r14096-4f1a51f438'
DISTRIB_TAINTS='no-all'
root@np0:~#
Thanks!
I have tried:
- @jayanta525 squashfs image;
- official snapshot images on 2 different SD Cards
- built from source squashfs and ext4 images.
None of them boot properly.
I used two different SD Cards (Kingston and Adata), but still no luck.
The official image FriendlyWRT works flawlessly on both SD Cards.
Anyone has the same problem?
Post UART log.
I made a PR that maybe could fix connectivity issues on the r2s.
If anyone wants to try it out , here is the image with the fix applied.
https://github.com/mj22226/openwrt/raw/r2s/r2s/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img
1 Like
@jayanta525 fixed the problem, it was a weird problem with my USBtoSD card adapter. I used different adapters to burn the images.
As soon as I used my old one your image worked perfectly.
@mj82 tested and confirmed it fixes the LAN plug after booting problem.
I've been doing some performance comparison with Friendly WRT image vs Openwrt and CPU usage in the Friendly image is way lower.
Testing with my 250Mbps downstream line I get:
Openwrt CPU usage: 1 core at 55%, other core at 40%
FriendlyWRT usage: 1 core at 30%, other core at 15%.
Both tests without sqm.
Any ideas?
I tried a new solution.
Adding the regulator-boot-on parameter to my problem also solved it.
Hopefully this solution will be merged.
Is there an alternative for ethtool to force 100 Mbit on LAN if negotiation fails? Currently I use an additional Gbit switch. My R2S is running an experimental freifunk firmware but it's openwrt based. Because fastd performance is ~30 Mbit (with
echo "e" > /proc/irq/166/smp_affinity
already applied) a 100 Mbit link would be fine.
This is what I found in the r8152.53.56-2.13.0.tar.bz2 ReadMe:
# ethtool -s eth0 autoneg on advertise 0x002f (1G)
# ethtool -s eth0 autoneg on advertise 0x000f (100M full)
# ethtool -s eth0 autoneg on advertise 0x0003 (10M full)
I submitted a new PR for your project.
The same PR can also be used on the master branch of OpenWrt.
Here are the results of a test based on the openwrt master branch.
# When the hardware random number generator is disable.
# time dd if=/dev/random of=/dev/null bs=1024b count=1000
root@OpenWrt:~# time dd if=/dev/random of=/dev/null bs=1024b count=1000
0+1000 records in
0+1000 records out
real 0m 23.25s
user 0m 0.00s
sys 0m 0.02s
# cat /dev/random | rngtest -c 10
root@OpenWrt:~# cat /dev/random | rngtest -c 10
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 200032
rngtest: FIPS 140-2 successes: 10
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=5.897; avg=6.030; max=6.136)Kibits/s
rngtest: FIPS tests speed: (min=53.278; avg=56.148; max=56.936)Mibits/s
rngtest: Program run time: 32394527 microseconds
After enable:
# time dd if=/dev/random of=/dev/null bs=1024b count=1000
root@OpenWrt:~# time dd if=/dev/random of=/dev/null bs=1024b count=1000
0+1000 records in
0+1000 records out
real 0m 0.22s
user 0m 0.00s
sys 0m 0.02s
# cat /dev/random | rngtest -c 10
root@OpenWrt:~# cat /dev/random | rngtest -c 10
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 200032
rngtest: FIPS 140-2 successes: 10
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=599.762; avg=627.345; max=642.349)Kibits/s
rngtest: FIPS tests speed: (min=24.868; avg=48.607; max=57.624)Mibits/s
rngtest: Program run time: 315679 microseconds
My tests show that the performance of /dev/random will improve dramatically when enabled.
These patches should apply to other Rockchip chips as well.
The only problem is that rockchip's hardware random number generator doesn't seem to be designed well enough, and the quality of the random numbers isn't too good to use directly.
The direct use of /dev/hwrng gives terrible results.
# cat /dev/hwrng | rngtest -c 10
root@OpenWrt:~# cat /dev/hwrng | rngtest -c 10
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 200032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 10
rngtest: FIPS 140-2(2001-10-10) Monobit: 10
rngtest: FIPS 140-2(2001-10-10) Poker: 10
rngtest: FIPS 140-2(2001-10-10) Runs: 10
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=637.859; avg=1089.640; max=2441406.250)Kibits/s
rngtest: FIPS tests speed: (min=17.842; avg=19.543; max=38.767)Mibits/s
rngtest: Program run time: 218512 microseconds
But I didn't compile your project directly to test it.You can test it if you're interested.
1 Like
I've had some conversations with the rockchip engineers and after that I think enable HWRNG is not a good idea for RK3328.
The reason is that it is difficult for us to improve the quality of random numbers.
For RK3399 HWRNG there is still enabled value.
Got a performance downgrade in the last Snapshot (08-29-2020). Don't know which date it started...
Doing a simple LAN test with a desktop connected I get:
NanoPiR2s to Desktop: 930 Mbps (Expected speed)
Reverse DIrection: Desktop to NanoPi R2S: 725 Mbps
Anyone having the same issue?