Werner

Btw. when did you identify yourself last time with nickserv @Igor? Just asking as I noticed a message from JackFrost last night:

As stated please retry with a different sd card. Do you have access to a USB-TTL converter? If not pick one up. Very useful for debugging through the serial connectors of many boards out there. Also dirt cheap. Try different power source as well. Voltage from cheaper supplies can break down on load and run the board into an undefined state.

How long did you wait after it stuck at "Starting kernel..." and what is the size of the SD card you used? Did you try a different sd card? Maybe it is broken.

I never used Invision software practically as well. I used to administer phpBB, WBB and vBulletin boards but that was as much other things many years ago and things changed in the meantime. I see your point about the well...strange taste in the mouth by this combination. There are really nice board software thingies out there like phpBB. Though from experience I can tell you they are not designed for larger communities. First they lack in performance, commercial boards are heavily optimized and last but not least are basically ALL boards in the web out there that run on free software under permanent attack of spam bots. Sure commercial ones are as well but quite minor.

Odd. I did IRC stuff many years ago as well but it should not be a big deal to register a channel for a group and therefore gain op status in it... Maybe I find some time to take a look into that.

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.

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: https://github.com/armbian/build/pull/1182 https://github.com/armbian/build/issues/1584

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 https://github.com/armbian/build/blob/f4f33ce2274d77a6d97a5fbda4db279731098a4e/packages/bsp/common/usr/bin/armbianmonitor#L151 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 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 %) - ondemand Though 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=ondemand It 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

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-sunxi64 Though 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?

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

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.