Closed shawwwn closed 4 years ago
Hi, @shawwwn
Rock Pi S based off the rk3308 would supposedly be a good 100Mbps router along with a USB-eth adapter. But, looking at the specification of the Rock Pi S, I wouldn't say so. Rock Pi S seems to target the audio/voice application with its voice detection engine and wouldn't suit the purpose of a router with its single 100Mbps eth port and USB2 port.
I would suggest you look at the Rock Pi E from the same manufacturer, goes for 15$, and comes occupied with dual-eth port and USB3.0.
The repo for RockPiE is over at https://github.com/jayanta525/rock-pi-e
OpenWrt support can be added for this new target based on rk3308, but I will need testers to test preliminary builds. But IMO, this isn't worth it because of the 100M eth port.
Rock Pi S seems to target the audio/voice application with its voice detection engine and wouldn't suit the purpose of a router with its single 100Mbps eth port and USB2 port.
Yes, it's an audio chip I know, but I am rooting for A35's ultra-low power consumption
I'm using a nanopi neo with a usb-eth adapter on vendor‘s openwrt(friendlywrt). Even thou I have disable hdmi and audio output (via device tree overlay), it idles about 1 watt. Not particularly great but still beats the heck out of its MIPS counterpart. As for the NATing capacity, quad-A53 seems to be a little overwhelming for mere 100Mbps connection. The little beast can push ~250Mbps even under openvpn. My experience with quad-A53 has led me into thinking maybe quad-A35 is a better choice for a 100Mbps router.
OpenWrt support can be added for this new target based on rk3308, but I will need testers to test preliminary builds. But IMO, this isn't worth it because of the 100M eth port.
GREAT! I'm buying a Rock Pi S so I can be your tester. It would take weeks for my shipment to arrive.
As for the NATing capacity, quad-A53 seems to be a little overwhelming for mere 100Mbps connection.
@shawwwn Bear in mind your statement may be accurate if the scenario is not taking into account the load of SQM. IMHO, SQM is very important for most connections (fiber may be more debatable, depending on factors of asymmetry). The necessary CPU overhead it adds onto routing/NATing is often overlooked, and should not be.
For instance, I bring the quad-A53 @ 1.5Ghz to its knees when I try to do cake diffserv4 on my 400/20Mbps docsis connection. The CPU becomes so bogged down that responsiveness of the whole unit suffers while at that upper limit.
I am not suggesting everyone has to run the same cake config, but my point is that the quad-A53 might be very much the right size for a well-tuned SQM config using layer_cake on a 100Mbps connection, while still allowing enough CPU to maintain responsiveness for other processes.
I'm using a nanopi neo with a usb-eth adapter on vendor‘s openwrt(friendlywrt).
@shawwwn IMO, FriendlyWrt is heavily bloated. In some cases, I've seen the CPU set at max-freq all the time.
Have you tried measuring the power consumption with an OpenWrt-build for the nanopineo?
I used to have the OrangePi R1 cortexA7 CPU running 24x7, with periodic reboots. It was perfect for a 100Mbps firewall, pushing 100Mbps NATed.
GREAT! I'm buying a Rock Pi S so I can be your tester. It would take weeks for my shipment to arrive.
I will start the work in the rock-pi-e repo, building with CircleCi.
@Fail-Safe QoS on a 400Mbps connection is definitely something not to be taken lightly of, as I said in earlier stmt, quad-A53 can only push ~250Mbps vpn traffic(aes) at the very best. Afaik, if you are not doing something crazy with your wrt, then quad-A53 can still be an overkill for 100Mbps connection. I am looking for a low power consumption alternative atm and have my eyes on quad-A35.
@jayanta525 My nanopineo on stock friendlywrt idles at 480MHz. and when I am streaming 4k yt, CPU freq bumps up to 624MHz.
Have you tried measuring the power consumption with an OpenWrt-build for the nanopineo?
There wasn't a community build of OpenWrt lying around when I set it up so no, but I suspect numbers are more or less the same.
I used to have the OrangePi R1 cortexA7 CPU running 24x7, with periodic reboots. It was perfect for a 100Mbps firewall, pushing 100Mbps NATed.
I am looking for something more power efficient. The power consumption numbers of Allwinner H2 are identical to H3's, if not more.
I will start the work in the rock-pi-e repo, building with CircleCi.
Sorry if I start a discussion in the wrong repo. I saw this repo is one commit ahead of the rock-pi-e so I assume this is where the development is going.
@shawwwn is it the nanopi neo2 you're using?
@jayanta525 I am using a nanopi neo w/e usb-eth adapter. The openvpn claim is on nanopi r2s, therefore generic quad-A53.
Can you perform a power consumption comparison with this official openwrt build.
Yea, but not right now. I will update you tonight.
@jayanta525 Shoot, I made a mistake for taking allwinner h3 as a quad-A53 chip wheras it is quad-A7 chip. >_<
Yup. That clears the confusion.
@jayanta525 Results are back! Here is what I have been getting:
Official OpenWrt:
FriendlyWrt:
The friendlywrt build uses approx. 1.5w during boot (same as the official build), then it drops down to <1w (as the cpu governor kicks in, I think).
However, I couldn't get a frequency reading from the official build because it doesn't seem to include a cpufreq driver, there is nothing under /sys/devices/system/cpu/cpufreq/
.
EDIT: The test was done on a nanopi neo + usb-eth adapter(RTL8153) operating on 100Mbps line speed.
@jayanta525 Any chance you can make a port to the RockPi S? My board has just arrived. I can test it out for you.
Can you provide me the UART log while booting Armbian, as well as the official debian/ubuntu?
Sorry for the delay. Here are some bootlogs.
(STOCK) rockpis_debian_buster_minimal_arm64_20200809_0853-gpt https://pastebin.com/jy5X2Qpd
Armbian_20.05.6_Rockpi-s_buster_legacy_4.4.217_minimal https://pastebin.com/ZXe3XL0c
Armbian_20.05.6_Rockpi-s_focal_dev_5.7.4 https://pastebin.com/GeZc0kGF
@jayanta525. I tried to fiddle with openwrt's building process but with no luck. I look into the atf-builds repository and found no prebuilt BL31 for rk3308. If I use the the stock BL31 binary, will it still boot? And which dts should I use? Can I use the same dts for u-boot and for the kernel?
Hi @shawwwn for atf, please look here: https://github.com/ARM-software/arm-trusted-firmware
I will have some test builds ready by tomorrow.
@jayanta525 Cool! Can't wait to test it out.
@jayanta525 do you have any idea when your github will be ready for Rock Pi S ? I love your work of Rock Pi E. it compiles in my machine smoothly.
@dastathagata Is it out?
@shawwwn my mistake. I meant to say E. I am eagerly waiting for similar git code for S as well
@jayanta525 Any update?
Hi @shawwwn could you give some feedback on these initial test builds.
@jayanta525 Both builds(001 and 002) did not boot. Nothing is showing in the serial console.
@shawwwn which UART did you try?
I tried both UART0 and UART1. None has yielded any information.
@shawwwn
try UART2
Tried it. Didn't work.
Nothing gets printed.
I took out the kernel and dtb, then used the stock bootloader to boot it. This is what I got:
Device 0: unknown device
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
365 bytes read in 5 ms (71.3 KiB/s)
## Executing script at 00500000
29076 bytes read in 9 ms (3.1 MiB/s)
12068872 bytes read in 525 ms (21.9 MiB/s)
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Device Tree to 000000000f501000, end 000000000f50b193 ... OK
Adding bank: 0x00200000 - 0x10000000 (size: 0x0fe00000)
Starting kernel ...
I tried different dtbs and bootargs(console=ttyS0,1500000
console=ttyS1,1500000
console=ttyS2,1500000
), kernel still not printing anything.
@shawwwn Yes, that's because UART2 is disabled in the kernel. That's for the next build. Can you explain how you got to this stage?
It took me some digging and found this: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Since there is no way I could get openwrt's bootloader to work, I just use the Rockchip blob straight up. All I did was:
dd if=idbloader.img of=/dev/sdc seek=64
dd if=uboot.img of=/dev/sdc seek=16384
dd if=trust.img of=/dev/sdc seek=24576
Assuming /dev/sdc
is my sd card.
All three img's were obtained from Radax's repo (when you done compiling their u-boot).
Still nothing gets printed in build 004.
uart2 is not yet enabled in build 004. But uboot and ATF should work with 004.
Please post whatever log is generated from uart2 during boot.
The next build 005 enables uart2 in kernel. Keep on checking https://dev.jayantajit.me/openwrt
@jayanta525 Still seeing nothing from build 005. Tried both UART0 and UART2.
@dastathagata OpenWrt is now supported on the ROCK Pi S.
Here's the link to discussion: https://forum.radxa.com/t/openwrt-for-rock-pi-s-testing/4443
Rock Pi S would make an excellent 100Mbps router with a usb ethernet adpater, given it's ultra low power consumption. It would be nice if this repo could support rk3308.