not sure, whether this is right subforum, but I just did not find a better.
First of all: I recently got a NanoPi R4S with 4GB of RAM to run ipfire on it, and actually was amazed, how easily I could get it to run. After using BalenaEtcher to burn lastest image to a microSD and then an ARMbian system to do u-boot work, the NanoPi booted into setup as I was used to from x86 installations in the past.
And at the first glance everything was splended. Especially the really low power (1,5-1,8W), while running the red net (via the RTL NIC) with 100Mbps. Which is because of my cabeling to the most opposite end of my flat, where DSL comes in.
Only then I got a not really nice surprise, when I unplugged the serial-to-USB-adapter, I needed for installation. Supply current stepped up about 160mA! And it is reproducable: As soon as I connect serial-to-USB-adapter again, supply current goes down to some 310mA. Why? And how can I prevent it?
There is still another issue, regarding cpufreq drivers, that seem to be not available in core180, but that for now is not as important as supply current issue because of missing serial console.
Note: If you have problems booting without the serial interface connected, add a 10k ohm resistor between GND and RX.
it is from this wiki page:
I know you are not having booting issues but it is worth a try.
EDIT:
is the serial-to-USB-adapter one of the types that can apply power to the device?
Three wires connected would be ground, transmit, receive. Four wires connected would include power. If it is 4 wire or includes power, disconnect the power wire on the serial-to-USB-adapter and test the current draw again
thanks for your post, but solution was something different. Though your second idea was quite near to it. Only that there cannot be any power supplied by serial-to-USB-adapter, because NanoPi R4S has no fourth pin on serial connector, just GND, RX and TX.
The surprising current step actually was because of the ground line of adapter, which obviously “shorted” the shunt of my USB U/I/P meter, an AT34. I found it out today, when I tried again with a completely separate supply for the NanoPi rather than the USB hub from yesterday, where I had both, the AT34 and the serial adapter, plugged in.
Ok, the 1.5-1.8W, that AT34 told of before, are now 2.3-2.6W for ipfire on NanoPi R4S, running it as a gateway only, but with secure DNS already. While my 50Mbit DSL gets loaded to its limits (5.8-5.9 MBps). But this is already more than 1W below my lowest power x86 system, which uses cpufreq with ondemand governor. Guess, if cpufreq will work with Rockchip ARM (again?), power can still go down some more.
It only does not word no more. The “echo” results in “-bash: /sys/devices/system/cpu/cpufreq/policy0/scaling_governor: No such file or directory” and trying to mkdir policy0 in “mkdir: cannot create directory ‘policy0’: Operation not permitted”. Even sudo does not help.
On the other hand: With latest aarch64 ipfire cpufrequtils is offered as an add-on and installs, but then does not find a suitable driver.
Starting cpufreq... scmi-cpufreq qoriq-cpufreq imx-cpufreq-dt imx6q-cpufreq
Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
for example because of hardware which cannot be set to a specific frequency
or because the userspace governor isn't loaded? [ FAIL ]
And this when trying to run cpufreq-info (PuTTY via SSH):
[root@ipfire-ARM ~]# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
analyzing CPU 1:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
analyzing CPU 2:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
analyzing CPU 3:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
analyzing CPU 4:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
analyzing CPU 5:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 4294.55 ms.
[root@ipfire-ARM ~]#
BTW: cpufreq-utils are 008-12, as given by pakfire and/or testing repository. And if interesting, my NanoPi’s profile is ea47fe140298d2ed98e60e038c63cd53644697b.
Over the weekends I’m normally not able to post here. Please wait until monday evening.
After I did some tests with R4S running ipfire versus friendlyWRT, I’m sure, that I will follow ipfire rather than friendlyWRT. Because ipfire web GUI is straighter on by far, and ipfire does not draw that peak currents on boot, that friendlyWRT draws, and which may let an .af PoE run into overload.
If this also means that the board won’t boot when uart is not connected.
This is due to the fact that uboot enters cli mode cause of a hardware bug in uart which shorts it and passed garbage entry when uboot waits for user input to enter cli.
This can be fixed by making ctrl+c as default in uboot to make it only enter cli when these key combination of met.
Furkan, sorry for delay, but the difference in current was just because of the same power ground of my USB-Meter to NanoPi and my USB-to-serial-adapter. With the NanoPi powered by a fully separate supply, there was no current difference no more.