Werner

I was talking to @soerenderfor about getting on IRC (and some initial confusion he had) which reminded me of something I was already thinking about before:
 
Originally we discussed redirecting irclogs.armbian.com -> whitequark log display website, but somehow we ended up with irc.armbian.com -> whitequark website.
 
I have always thought that to be a bit confusing, perhaps at irc.armbian.com we should have a landing page or some instructions, wherein contains another link to the exterior logging page (and clarifying it is an external page perhaps). And/or also redirect irclogs.armbian.com to there.
 
Since DNS / site level stuff rises above my pay grade to @Igor and/or @lanefu, I am pinging them here.

tl;dr: irc://chat.freenode.net/armbian
 
In Germany we have an adage "Was lange währt, wird endlich gut." which means Good things come to those who wait.
Thanks to their kind staff we managed to obtain owner privileges of our IRC channel hosted on the Freenode IRC network after years of idling unofficial status.
 
Feel free to join us:
Server: chat.freenode.net Ports: 6697 / non-SSL: 6667 Channels: #armbian, #armbian-commits  
Or simply use their webirc client: https://webchat.freenode.net/
 
We may add more channels in future if necessary or the main channel gets too spammy
 
Don't hesitate to get in touch with us

I think at this point I can say: Done

A full time hobby then... 

Just to clarify my earlier post: I have not withdrawn as a moderator, I was panicking from just browsing through this forum and realising how much work has been done by members and how complex the questions are , most of which I could not answer without much deeper knowledge of Armbian code and hardware architecture.
In plain English: I got cold feet ...
Sorry for that.
Will behave better and cooperate more with other Moderators ...
I am also using the IRC channel (chat.freenode.net  #armbian) for better understanding of Armbian 

There are no spikes in the Google analytics which suggest more for some bot activity.

Buy!
 
I personally have HC1 for almost two years and no problems. Alternatively, you might think about HC2 if 3.5 inches will interest you in the future, especially if you need something above 5TB at normal prices it will be a better solution than 2.5.

As for OS, install Armbian based on buster but with 4.14.y kernel because currently 5.x has big problems with HC, it doesn't boot at all. But 4.14 is not a problem because some time will be supported.
As for samba, stretch has 4.5.16, buster has 4.9.5 If you need 4.11.3, you will need to install samba from bullseye / sid sources.

Buy a decent PSU, don't save !!!
I also recommend buying a branded A1 / A2 SD card.
If you are thinking about using a USB port, it would be good to have a HUB with power. In general, imho Odroid has something of poor quality USB ports, quite loose and likes to have problems with pin contact, sometimes you need to bend the metal plates for better contact but these are random cases. My HC1 works well with the rf receiver and the USB sound card.

After buying it is worth checking if the Firmware is new, if not update ... https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

My armbian HC1 handles omv, pihole, kodi, xrdp and chromium. If you have fast hdd / ssd then getting 80-100MB/s should not be such a problem with SMB.

You can also think of a uart-usb cable especially dedicated to odroid just in case.

Generally it's ok and stable, I do uptime 20/30/50 days.

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.

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

I split @Vanitarium last couple posts off into a new topic: Proposed Forum Structure Change.
 
EDIT: Moderating the moderators! So meta!

One of my first thought was wondering if there were enough of these type of little advices to make a wiki page or moderation sub forum, or maybe just a sticky post?
 
I think such a resource would help to get new moderators up to speed more quickly, and also lessen the impact of inevitable turnover. Maybe as I get to grips with how to perform this new job over the coming days and weeks I could start to collect some brief notes (from perspective of someone brand new to it) and see if such thing will even be necessary...
 
I am really excited about being able to contribute to such an important project! 

Thank you Igor.

I will read the term and guidelines and moderate accordingly.

And you are correct, I really did not read them when I joined.

I am happy I can contribute to the Armbian project.


Sent from my iPad using Tapatalk

Granted! Thank you.
 

Great!
 
Forum is our common problem and it should be moderated according to that. We created some https://forum.armbian.com/terms and https://forum.armbian.com/guidelines. Read and use them, change if needed and keep in mind that people usually don't read them ... remember when you read the small print last time?
 
I have no intention to lead forum moderation - tell you what to do, but I will tell you if you went to far ... I expect the same treatment - I am just a forum user. (even I do have the same power and more as you do). There are topics which need to be sorted out - merge or move - and there are important topics which are floating in the see of banal - I work on this when I find some time which is less and less. Important stuff should be pinned and some, that are there are not relevant anymore, unpinned. If you can not decide on a specific case, but its important, speak up here, publicly. Only if there is a special need for privacy, in private. Administrator rights - for changing more critical things on the forum - contact @lanefu and me. We are both quite busy, so perhaps we shell also expand this role later on if you will come up with lots of ideas for changes.
 
Can't believe how quick we sorted this out.  And as a side effect, perhaps an IRC channel might get live soon. Thank you!

We have LEGACY, CURRENT and DEV tags.

Legacy will upgrade on 4.19., current on 5.4.y and DEV on whatever is attached there. 5.5.y at this moment. You had to switched to DEV once and then it goes on that path. Going back to CURRENT kernel with 5.4.y is what you need to do. Then apt upgrade will not switch to 5.5.y (or we have a bug)

I got some Sunxi/Sunxi64 board running 5.5.0-rc2 running for some days (one or two weeks) and couldnt find any freezes.
Today dev is going on my systems to 5.5.0-rc6 - I will see if there will be any freezes.
 
Running Boards are OPi Zero, OPi One, BPI M2 Berry, NanoPi A64, NanoPi Neo2

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.

@jernej - success! finally ... it was the atf - i now built the atf myself (v2.2) and just emptied the axp probing function (so that it does nothing anymore and just returns an error back, i.e. no axp) and voila: it boots ... with the mainline u-boot it still resets dozens of times until it finally continues to boot, but it always does at some point in time after a few seconds or minutes (with the libdram version it boots absolutely reliable) ... so we are back to trying to improve the dram setup and timing to maybe get rid of the resets - please let me know in case you have any idea what else to maybe test ...
 
a lot of thanks for all you help and support and best wishes - hexdump
 
... resetting ... U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100) DRAM:PLL = b0003500 DRAM PHY PGSR0 = 20003d DRAM PHY DX0RSR0 = 0 DRAM PHY DX1RSR0 = 0 DRAM PHY DX2RSR0 = 0 DRAM PHY DX3RSR0 = 0 Error while initializing DRAM PHY! resetting ... U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100) DRAM:MBUS port 0 cfg0 0100000d cfg1 00640080 MBUS port 1 cfg0 06000009 cfg1 01000578 MBUS port 2 cfg0 0200000d cfg1 00600100 MBUS port 3 cfg0 01000009 cfg1 00500064 MBUS port 4 cfg0 20000209 cfg1 1388157c MBUS port 5 cfg0 00640209 cfg1 00200040 MBUS port 6 cfg0 00640209 cfg1 00200040 MBUS port 8 cfg0 01000009 cfg1 00400080 MBUS port 11 cfg0 01000009 cfg1 00640080 MBUS port 14 cfg0 04000009 cfg1 00400100 MBUS port 16 cfg0 2000060d cfg1 09600af0 MBUS port 25 cfg0 0064000d cfg1 00200040 MBUS port 26 cfg0 20000209 cfg1 1388157c MBUS port 37 cfg0 01000009 cfg1 00400080 MBUS port 38 cfg0 00640209 cfg1 00200040 MBUS port 39 cfg0 20000209 cfg1 1388157c MBUS port 40 cfg0 00640209 cfg1 00200040 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):v2.2-dirty NOTICE: BL31: Built : 16:17:47, Jan 10 2020 NOTICE: BL31: Detected Allwinner H6 SoC (1728) NOTICE: BL31: Found U-Boot DTB at 0xc07ad38, model: Eachlink H6 Mini INFO: ARM GICv2 driver initialized NOTICE: PMIC: Probing AXP805 <=== this is actually not doing anything in this version INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100) Allwinner Technology CPU: Allwinner H6 (SUN50I) Model: Eachlink H6 Mini DRAM: 2 GiB MMC: mmc@4020000: 0, mmc@4022000: 1 Loading Environment from FAT... Unable to use mmc 1:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1103 bytes read in 5 ms (214.8 KiB/s) 1: Armbian Retrieving file: /initrd.img-5.4.7-stb-ah6+ 11947280 bytes read in 1201 ms (9.5 MiB/s) Retrieving file: /Image-5.4.7-stb-ah6+ 21233672 bytes read in 2131 ms (9.5 MiB/s) append: root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyS0,115200 console=tty0 no_console_suspend cons0 Retrieving file: /dtb-5.4.7-stb-ah6+/sun50i-h6-eachlink-h6mini.dtb 21044 bytes read in 7 ms (2.9 MiB/s) ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 4949b000, end 49fffd10 ... OK Loading Device Tree to 0000000049492000, end 000000004949a233 ... OK Starting kernel ... Booting Linux on physical CPU 0x0000000000 [0x410fd034] Linux version 5.4.7-stb-ah6+ (root@eachlink) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1 SMP 0 Machine model: Eachlink H6 Mini ...  

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)  

why didnt you use the install instructions from the github page?
or do use a newer kernel?
for which board you will use the driver?
whats the model name of you usb device?

It should run as your regular user. Can you launch the browser from console (as your regular user), and post here the output?

Armbianmonitor: http://ix.io/260w 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