Heisath

Today is code freeze day. *ice* I am currently testing mvebu 5.15 + 5.16 - afterwards I will do the code freeze / RC branch. Is anyone still working on something important, that should go into this release / RC ? @private/contributor @Contributor/Maintainer

As said many times before, we will gladly check and accept any PR to https://github.com/armbian/build which improves Espressobin. This can be MAC improvements, Uboot updates whatever. But we do lack the resources to do and test these changes ourselves. That is the reason we moved espressobin in the Armbian buildsystem to CSC, Community support. Some work seems to have been done here, https://github.com/armbian/build/pull/3453 feedback is welcome. BTW. @Pali thanks for your work on mvebu (clearfog) on the PCI mailing list, nice to see some of the Russel King patches finally making it's way to mainline.

Reminder! The release meeting is happening this saturday 14:00 UTC+1 (which is 13:00 UTC or 8 am EST or 2 pm CET or 5 am PST (sorry california dudes) or 9 pm CST). I will look through the Jira issues remaining today. Would be great if you could check them too and add the ones you have finished (or are planning to include in 22.02) to the release. @Igor @Werner @TonyMac32 @martinayotte @piter75 @ning @Myy @balbes150 @sfx2000 @ebin-dev @chwe @gprovost @aprayoga @lanefu @5kft @JMCC @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @tony013 @rpardini @yang @adeepn

I would still go on with the February release, we skipped last one, lets get this one done. Am targeting 2022-01-29 (Saturday, 29 of January 2022) for release meeting, and then about 4 weeks later 2022-02-25 (Friday, 25 of February 2022) for actual release. Release meeting earlier than 2022-01-25 is not possible from my calendar.

The power cable you bought probably will not work. Check the pinout and connections + voltages. Compare with Helios64 here: https://wiki.kobol.io/helios64/sata/#hdd-power https://wiki.kobol.io/helios64/sata/#j8-pinout https://wiki.kobol.io/helios64/sata/#hddssd-harness

I did the upgrade from Buster to Bullseye. As far as steps: - Backup - apt update & full-upgrade - Disable /etc/apt/sources.list.d/armbian.list all entries to stop armbian from upgrading - Use normal debian upgrade steps -> Change release in /etc/apt/sources.list - apt update & full-upgrade - Restart, validate working system - Update /etc/apt/sources.list.d/armbian.list with new release (buster->bullseye) - apt update & full-upgrade - Should be done. Take extra care for some new/renamed packages. armbian-bsp-cli-<BOARD> is new. Older armbian-root-* packages dont exist anymore (I think). For me this worked flawless, you might have to fix some dependency problems, and make sure at least some working version of armbian-image-* armbian-dtb-* is installed before rebooting.

Probably start by taking a fresh sd card, install current armbian, do not install anything else and try again. If it does not restart is seems OMV problem. If it does, check WOL (wake on lan) or similar functions. And attach serial console and log it while powered off, to see what happens on start. Maybe the hardware / power supply is faulty or do you by chance have intermittent power failures where you live? I am pretty sure there is no "auto restart" in general armbian. For helios64 specifics you can check here: https://github.com/armbian/build/tree/master/patch/kernel/archive/rockchip64-5.10 https://github.com/armbian/build/tree/master/packages/bsp/helios64 And since no one else is reporting this, I cant image it is a general problem

Please try building hirsute or impish on Hirsute host / builder. There are problems with qemu (which is used by debootstrap) again and again, when using it for newer versions. See https://github.com/armbian/build/issues/2787

192.168.2.222 is probably the host you are using to connect to the bananapi via SSH, you have 2 connections open -> The two Port 22 tcp. time01.nevondo.com AND ntp2.wup-de.... Are probably NTP hosts your system is using to synchronize the time. NTP uses UDP via port 123. Which totally explains your UDP log (incoming from NTP server port 123, outgoing from your box on random free port) *.canonical.com are all Ubuntu Servers, so you are using an ubuntu system and it is doing some background stuff (Updates? Status?) littlericket.me seems to be some kind of Telegram bot. No idea if you are using that in any way https://botostore.com/c/messagestatisticsbot/ (see subscribe/unsubscribe url) I think that was all - btw easily googleable. Or what undefined traffic did you mean?

Should be easy enough to grab 5V of the wiring harness for the HDDs. J8 is the place to go for your high power 12V or 5V needs. https://wiki.kobol.io/helios64/sata/#j8-pinout (there is even a picture with the wire harness). The GPIO header is not the right place to get high current from .)

This is a problem with the echo behaviour of putty and serial ports. I have the same, it is not armbian related. Try to test out other ssh clients (Windows has built in ssh for example), maybe they handle these linebreaks better. As a workaround you can configure bash to not list the complete path you're in at the moment

Release Candidate Code Freeze Date: 2022-02-14 Release Planning Meeting Date: 2022-01-29 14:00 UTC+1 Release Planning Meeting Location: Armbian IRC Release Date: 2022-02-28 Release Branch Link: https://github.com/armbian/build/tree/v22.02 Release Changelog: Release Coordinator: @Heisath and hopefully some new person on the team Already creating this release topic for 22.02, to discuss upcoming changes, no longer maintained boards and help new people get into the release / maintain flow. Current steps: - Refine supported/WIP/CSC/etc. board status - Update maintainer list - Onboard new maintainers / contributors - Move Jira issues to new release - Select release name @Igor @Werner @TonyMac32 @martinayotte @piter75 @ning @Myy @balbes150 @sfx2000 @ebin-dev @chwe @gprovost @aprayoga @lanefu @5kft @JMCC @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @tony013 @rpardini Pls. ping developers I forgot

You can check the trigger settings on the led. Something along 'cat /sys/class/leds/helios64:blue:net/trigger'

Nearly at 300€ already, getting too pricey for me, sorry guys :/

Arduino solutions will be the only more efficent way going forward. I mean, reading RS232 to SD card is super simple. Untested code below, it would watch Serial and SoftSerial for incoming data, write it to a file on sd card (in 100 char chunks or on every newline, syncing sd card after every chunk). Should be simple enough to adjust for some power down mechanism (and maybe add a button to manually sync data before removing sd card)... #include <SoftwareSerial.h> #include <SD.h> char buffer[100]; int buffer_pos = 0; uint8_t sdavail; #define CurrentBaudrate 115200 SoftwareSerial softSerial = SoftwareSerial(5, 4, false); void setup() { sdavail = SD.begin(SDC_CS); setupScreen(); Serial.begin(CurrentBaudrate); softSerial.begin(CurrentBaudrate); softSerial.listen(); } uint32_t lastTouched = millis(); char msg; void loop() { while (Serial.available() || softSerial.available()) { msg = Serial.available() ? (char)Serial.read() : (char)softSerial.read(); buffer[buffer_pos++] = msg; if (buffer_pos >= sizeof(buffer)) break; } if (msg == '\n' || buffer_pos >= sizeof(buffer)) { writeBuffer(); } } void writeBuffer() { if (sdavail) { File dataFile = SD.open("datalog.txt", FILE_WRITE); if (dataFile) { dataFile.write(buffer, buffer_pos); dataFile.close(); } } buffer_pos = 0; }

Added to watchlist. If it stays cheap enough, I'll buy it. Can't guarantee you "Supported" flag, but I will have it running edge and notice problems

Responded with Tested-by. First time sending something to a kernel mailing list, hope it lands at the right spot.

Hi @Pali, thanks for linking me to that mailing list topic and providing the patches. I have tested v3 on Clearfogpro with LK5.10 (based on Armbian build). Works perfectly! I'll integrate the patch into Armbian in the next days, if it's ok for you. [ 6.093263] systemd[1]: Finished Raise network interfaces. [ 6.113471] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 6.137862] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid [ 6.259786] ath10k_pci 0000:01:00.0: assign IRQ: got 89 [ 6.271951] pci 0000:00:02.0: enabling device (0140 -> 0142) [ 6.271966] pci 0000:00:02.0: enabling bus mastering [ 6.271973] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142) [ 6.271983] ath10k_pci 0000:01:00.0: enabling bus mastering [ 6.272152] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 6.292488] systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. [ 6.463645] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 0000:0000 [ 6.463653] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 [ 6.464176] ath10k_pci 0000:01:00.0: firmware ver 10.2.4-1.0-00047 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 35bd9258 [ 6.501127] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 0a) 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 0a) 01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter

Hello all, it is this time of the year again. The pcie struggles with certain devices have returned with LK5.10 and are unfortunately not magically gone with LK5.13 As interest around clearfog is not that high, I am not expecting quick solutions here. But will post my findings and perhaps solution. If you have ideas welcome to chime in. pcie especially with wifi cards has been troublesome on clearfog (maybe even linux on the whole) forever(?). In LK5.4 we had it at a point where multiple different ones ran fine. Even "higher performance" ones as QCA988X (WLE600). We also list them as "supported hardware" on the download page... Now starting from LK5.10 they are making problems again. QCA988X is not booting while older one Intel Centrino N2200 works fine. I will try to figure this out... Below are relevant 'dmesg' extracts from the boot. All kernel versions have been booted from the same uboot2018 armbian is using for mvebu/clearfog. Working good LK4.19 Working good LK5.4 Breaking LK5.10 Still broken LK5.13 All bootlogs etc. are also in the armbianmonitor link attached to this post. From a first glance there are some errors assigning the pci memory regions, and the main problem seems to be the power state not changing. I try to figure out breaking version. Greetings, Heisath

Sure I went from stretch to buster to bullseye. There's lots of instructions on the web (basically update/upgrade your current system, change apt sources, then update/upgrade again and fix errors as they appear). I did that on my clearfogpro relatively flawless, although I absolutely recommend having a backup It is pretty much the same as any other debian system. For stability on espressobin, I'd recommend checking the threads in the A380/A3700 subforum. Maybe helpful threads: https://forum.armbian.com/forum/32-armada-a388-a3700/

Probably 'apt install busybox' is the easiest / straightforward way to fix your immediate problem. Regarding further problems with upgrading from Stretch: Espressobin is CSC and Debian Stretch (along with all armbian 5.90) is long out of support/maintenance. You can try upgrading to something more modern (buster / bullseye) but are on your own. Or reinstall / redownload more current image.

The repo is on github, problematic line seems to be this one: https://github.com/kobol-io/sys-oled/blob/master/bin/sys-oled#L78 I do not have an OLED display attached to my helios4 but running this simple python test script has worked. Maybe you can try it? Just put it in a file, make executable (chmod +x ) and run it. #!/usr/bin/env python3 import psutil sens = psutil.sensors_temperatures() temp = psutil.sensors_temperatures()['f10e4078.thermal'] print(sens) print(temp) Give us the output of the test script and also attach the 'armbianmonitor -u' output or tell us which exact version you are using.

Something that's probably gonna keep happening if nobody is using the beta repository (nightly/edge) and reporting errors before they make it to the current version. FYI there is no Helios64 in Armbians testing "facility"

I think what he meant is: "Your data is expensive, don't stick to ARM" -> Buy a better / easier supported and more stable / mature board like literally ANY x86 small form factor thing. Can get them easy with actual SATA etc. Real BIOS....

@halfa merging both files into one is the proposed solution. No need for PR, I already created one here: https://github.com/armbian/build/pull/3092 One thing I am not sure about is removing the old file(s) in case of update...