• Posts

  • Joined

  • Last visited

1 Follower

Profile Information

  • Gender
  • Location

Recent Profile Visitors

2118 profile views

Heisath's Achievements

  1. You can check the trigger settings on the led. Something along 'cat /sys/class/leds/helios64:blue:net/trigger'
  2. Nearly at 300€ already, getting too pricey for me, sorry guys :/
  3. 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; }
  4. 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
  5. Responded with Tested-by. First time sending something to a kernel mailing list, hope it lands at the right spot.
  6. 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
  7. 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
  8. 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/
  9. 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.
  10. 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.
  11. 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"
  12. 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....
  13. @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...
  14. Ok @SIGSEGV thanks for confirming that the old bug is back. So the buildscript still does not correctly seperate between legacy and current. If you are able to build images yourself it would be great if you could build a helios64 image (current) from this pr/branch https://github.com/armbian/build/pull/3092 and test if it works + the correct files are present.
  15. @Igor no. This is a) a new problem and the proposed fix is IMHO not correct. AND b) the old fix (on branch https://github.com/armbian/build/tree/helios64-udev-hwmon-fix) was never merged, tested or anything else. Regarding the old problem: As mentioned in the previous thread, I do NOT have a helios64 so cannot test any changes. Nobody else stepped up to test and report back. Also sometime later someone said: SO I assumed this had magically fixed itself and did not need further attention. Read here for full thread: Regarding the new problem: Simply changing the fancontrol rules from thermal-cpu to thermal-board is incorrect AFAIK. Looking at the udev rules: https://github.com/armbian/build/blob/master/packages/bsp/helios64/90-helios64-hwmon.rules It should be thermal-cpu for the cpu temperature and thermal-board for the board temperature. And then it only makes sense to attach the fancontrol to the CPU temp. Why the thermal-cpu is not available anymore I don't know. But it is not a solution to the root cause to just fix the fancontrol to the board temp. We should instead investigate why the thermal-cpu node is not available anymore and fix it. Maybe @aprayoga or @gprovost are back from their break? EDIT: Looking back at it, maybe it is the same problem. @SIGSEGV can you check if you have the 90-helios64-hwmon.rules or the 90-helios64-hwmon-legacy.rules in your udev? EDIT2: PR here: https://github.com/armbian/build/pull/3092