Werner
-
Posts
4539 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Werner
-
-
For 1: The red led can be turn off or used for any other purpose. I am not at home so I cannot tell you the exact location but simply do something like du -a /sys|grep led and search for the orangepi red led and trigger. For example you can do echo heartbeat > trigger and it should flicker.
For 2: Odd. As for me I never used the HDMI on it as I prefer SSH as well. Though you can give either an older or a newer dev build image a shot and check if anything changes. Makes it easier to track it down. You may also want to provide an armbianmonitor -u output here.
For 3: No idea.
-
If you interested in experimenting with higher clocks you may check these commits which have been removed/altered when switching to 5.4.x
https://github.com/armbian/build/commit/b79b3558e7086eea038826fde605c5f765541401
https://github.com/armbian/build/commit/d11511ab2d1490a57c02e25a8eb324159de9ba79
-
It was integrated into the build script. You can find more information here:
-
The cryptoroot feature was added by user contribution and is broken for several month now. Therefore you might be on your own to fix this.
-
The cheap and dirty way would be to add ifconfig eth0 (my dedicated IP) netmask 255.255.255.0 up to your /etc/rc.local
The correct way would be to check /etc/network/interfaces as the static ip should have been set there.
-
Missunderstanding. Please try to ping any of these adresses: 141.1.1.1, 8.8.8.8 or 9.9.9.9
Check the output of ifconfig if it makes sense and matches your local area network.
-
It seems like
in comparison between linux-mvebu64-legacy.config and linux-mvebu-legacy.config the whole dvb secion is missing for mvebu64. the only config file that includes dvb is linux-mvebu64-legacy.config. The entire section seems missing in any other mvebu(64) config.I'll try looking into that.
PR provided. For current mvebu at least. Either wait until someone approves or build your own kernel using the updated config. https://github.com/armbian/build/pull/1707
-
I assume you connected a serial console to get this information?
Anyway as far as I see there is a problem with dns resolution.
Check if /etc/resolv.conf containing valid dns server addresses.
Check if you can ping a known IPv4 address like 141.1.1.1, 8.8.8.8 or 9.9.9.9
Also interesting
It seems like for any reason the script did not stop here as it should...
-
Get a different sd card and try to boot it with a fresh image to make sure the board is not broken.
If it boots the only way to debug this further is to help yourself to an USB-TTL converter to get a serial console to the board.
-
5.3.x has been superseded by current stable and upcoming LTS kernel 5.4.x. Have you tried to update your kernel to the current current branch? You can use armbian-config for that
FYI: You can use the spoiler for longer pastes of log files and similar to keep posts more clear
-
Wherever you are around the world I wish you all a happy new year!
May 2020 bring all the best for you, your family and your friends. Don't party too hard
-
Yeah I noticed this as well. Was just curious
-
I see. Makes sense.
Do you get any higher clocks that 1.01GHz from the board?
-
Armbianmonitor:
Armbianmonitor for 5.4.6: http://ix.io/260C
From switching between 4.19.x and 5.4.x kernels I noticed that the lower cpu frequencies got missing.
It should start at 120MHz like this:
root@horangepione:~# uname -a Linux honeypot2 4.19.84-sunxi #19.11.3 SMP Mon Nov 18 18:39:42 CET 2019 armv7l GNU/Linux root@horangepione:~# cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 1 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 2 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 3 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemandThough on 5.4.x the minimum frequency is 480MHz.
Since the default cpufrequtils file was not there I created one:
cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=120000 MAX_SPEED=1200000 GOVERNOR=ondemandIt seems to have an effect because when changing the minimum frequency it clocks up as it should.
Frequencies beyond 1.01GHz missing as well but that is a different story...I guess.
Cheers
Werner
-
Quote
[ 6.869660] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator
[ 6.869678] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000)
[ 6.869789] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator
[ 6.869797] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000)
[ 6.869880] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator
[ 6.869887] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000)
[ 6.869990] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator
[ 6.869996] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)I think this is the reason for the cap. This is the same in all kernels from 4.19.84 up to 5.5.0-rc2
Edit: Interesting. On 4.19.35 it is still capped, though more information in dmesg
[ 5.745212] cpu cpu0: Linked as a consumer to regulator.5 [ 5.745277] cpu cpu0: Dropping the link to regulator.5 [ 5.745464] cpu cpu0: Linked as a consumer to regulator.5 [ 5.746315] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746328] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 5.746436] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746443] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 5.746569] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746579] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 5.746669] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746676] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 5.746783] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746790] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 5.746926] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746935] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 5.747030] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.747038] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 5.747155] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747163] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 5.747290] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747299] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) -
Looking decent.
___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ | | | | |_) | | | | | | '_ \ / _ \ | |_| | __/| | | |_| | | | | __/ \___/|_| |_| \___/|_| |_|\___| Welcome to Armbian Buster with Linux 5.5.0-rc2-sunxi [...] root@honeypot:~# lsmod Module Size Used by wireguard 57344 0
Edit: OPi0+ looking good too.
___ ____ _ _____ ____ _ / _ \| _ \(_) |__ /___ _ __ ___ | _ \| |_ _ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_) | | | | / __| | |_| | __/| | / /| __/ | | (_) | | __/| | |_| \__ \ \___/|_| |_| /____\___|_| \___/ |_| |_|\__,_|___/ Welcome to Armbian buster with Linux 5.5.0-rc2-sunxi64Though CPU is capped to 1.01GHz while the H5 should work at 1.2GHz.
Found this:
[ 6.037059] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037083] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 6.037167] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037174] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 6.037301] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 6.037309] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 6.037392] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 6.037400] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)Maybe something missing in the dts?
-
4 hours ago, guidol said:
I did compile with
./compile.sh EXPERT=yes WIREGUARD=no AUFS=no BUILD_KSRC=noand it did also work for for my non-64Bit-sunxi SBCs OPi Zero, OPi One and my BPi M2 Berry
At this time I have no need for WireGuard.Wireguard seems to work in 5.5.0-rc2. It compiled at least.
LD [M] drivers/net/wireguard/wireguard.ko LD [M] net/wireguard/wireguard.ko INSTALL drivers/net/wireguard/wireguard.ko INSTALL net/wireguard/wireguard.ko -
13 hours ago, Igor said:
Its expected to fail.Of course I did not expect everything works out of the box. Though I wanted to mention it anyways ;).
-
aufs5-standalone.patch fails to apply to the sources and therefore the build fails obviously. I will retry without AuFS.
Edit: Yep, works.
-
On 12/16/2019 at 9:55 AM, dolphs said:
Probably some patches are new obsolete since their content has been merged into mainline. Though they getting applied anyways which results in duplicate note errors. Same procedure as every time when a new kernel is released.
Try to find the unneeded patches and disable them.
-
The OPP table change has quite a story behind but that is another thing. Anyway. Armbians patch containing 1.8GHz as well as far as I understand. It just alters the voltages.
-
Did you check your syslog for abnormalities when such disconnects happen?
If the VPN is configured a way to route all traffic through it it is clear that no connections from "outside" are accepted anymore.
-
Quote
get garbage
Pure guess: Did you set the rate to 115200?
-
Quote
upgrade
Just for the heck of it did you try using a fresh image on a different sd card?
Buster image for OPi 1+ works fine, with red light on
in Allwinner sunxi
Posted
The brightness thingy did not work for me either, maybe it is not even supported by the board.
I used the rc.local to echo 0 to the trigger to switch if off after the system booted.