lanefu

Hi all,
I got my helios4 sometimes in 2019 and it was one of the best purchases I ever made. It has served and was solid as a rock. Unfortunately all that ended couple of days ago when I noticed the Helios was not powering up properly, think it was the power supply not connected well (because I just recently changed the location) I removed and fitted the PSU a couple of times, I could see the led light come on but still it would not boot properly.
 
By the time I found out what the real problem is things had gone worse, the reason for the incomplete boot was the SD card has been removed. Unfortunately, it seems my constant removing and refitting the PSU to the board most have done some damage because right now the board has refused to come on.
 
I used a multi-meter to check the reading from the PSU and it is constantly at 12.5v but the molex for the sata is are all completely 0v. Same for the fan ground and 12v pin for the Fan male header. Curious enough, the control and sense pin out for the FAN reads about 4v. This is pretty much the only thing I was able to get reading from. Rest of the board just seem dead, no LED, no indication whatsoever that PSU is connected to the board.
 
I am aware that the PSU was one of the weak side of the Helios4, But like I said, the pin out of the PSU reads 12.5v so I am thinking maybe this is an issue with a blown mosfet? I am a total newb when it comes to computer hardware. There are no device out there (arm based and DIY) That comes close to the Helios so I am pretty much stuck. Any advise on how to troubleshoot this would be very much welcome.

Congratulations. Armbian is adedd to the distrowatch list. 
https://distrowatch.com/table.php?distribution=armbian
Already 2 years ago I submitted you to the list but then they refused to listen to me, despite the fact that RaspbianOS was placed a long time ago.
I think that this will further influence the popularity of the venture.

We have community member in France who needed an RPI3 for $dayjob.  They found one and dont need one.
 
But it turns out @NicoDhas some RPIs for sale and more.
 
Help support Nicod and channel by purchasing all the crap in his office so he can clean up his camera angles !   😂😂😂

Legacy functionality -- bbcode support has been disabled.   The current editor version has richer formatting support natively..   Disabling the bbcode formatting should improve editor performance.
 
 

Ran ran job looks approved.  (Link PR next time on post please)

Even though I do not often send code or changes I think the suggested stuff makes sense.

As our projects grows in size and complexity it is getting more and more important to add additional measures to improve code quality. Code is added almost daily and therefore we have to do what is possible to improve chances that things doesn't break or have obvious bugs.
 
Therefore I propose to enable additional conditions applied to the build framework master branch:
 
- code must be submitted via a pull request
- pull requests require at least one review and approval from another individual
- all changes open requests resolved before merge.
- in-line conversation on merge request has to be resolved before merge
- commits pushed to master must have verified signatures,
- conversation on merge request has to be resolved before merging.
 
@private/contributor

Most of the things we already use, so new thing is mandatory review - counts from anyone except from the one that is sending a pull request.
 
Speak up if you find those measures too draconian.

Also I would like to point out another change related to our label system. It seems too complicated, some tags were never used and not many people are using them. So limiting them down significantly - comments are welcome here https://armbian.atlassian.net/browse/AR-959

https://www.armbian.com/newsflash/armbian-22-02-pig-release-announcement/
 
Please promote, share, etc. on social media!
 
 

Hi @yang and @TRS-80,
 
If it's not too late, I'd like to pick up OrangePi Zero Plus2 H3 as a maintainer.
I have two Plus2 boards with expansion boards, and can to test for releases and troubleshooting.
Don't have much experience in SW development, but have some as Linux basic admin.
 
As an experiment built an image for "BRANCH=current KERNEL_ONLY=no BUILD_DESKTOP=yes RELEASE=bullseye", all seems to work: http://ix.io/3Qdm.
I like the board and would like to keep it in the game.

If possible it would be great if all maintainers could send a PR with fixed tag for kernel source.
Follow this PR https://github.com/armbian/build/pull/3500
This would allow for more reproducible builds.
 
This together with Igors suggestion of merging 
https://github.com/armbian/build/pull/3489
https://github.com/armbian/build/pull/3499
could go into a new RC branch.
 
 
@Contributor/Maintainer
 

I created branch with Ebin improvements and PR https://github.com/armbian/build/pull/3498
 
This is still WIP. Feedback + help welcome. 
 
Currently building TF-A fails because:
 
plat/marvell/armada/a3k/common/a3700_common.mk:148: *** "Platform 'a3700' for WTP image tool requires CRYPTOPP_PATH or CRYPTOPP_LIBDIR. Please set CRYPTOPP_PATH or CRYPTOPP_LIBDIR to point to the right directory". Stop.  
 
Got it working, see https://github.com/armbian/build/pull/3498 
Compilation seems to work now. Waiting on feedback from ebin owners.
 
armbianEnv.txt still needs adjustment!

Release candidate has been branched off. Please direct all bugfixes to 'master' AND 'v22.02-RC'.  Please build, test etc. the RC branch. 
 
https://github.com/armbian/build/tree/v22.02-RC

Fixed 3D support on Debian desktop.
https://github.com/armbian/build/pull/3480
 
I only tested with Debian SID on / Allwinner H5, need few checking on RK3399 and Amlogic.

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

I received at least one PM so far that I did not know the answer to.
 
So, rather than all of us spend a lot of effort duplicating info, I thought maybe good idea to compile these in one place.  Especially as we have an influx of new Board Maintainers at the moment.
 
I also encourage people to stop by IRC and say hello.  I shall also endeavor to copy the most useful bits from IRC into this thread as they come up.  Maybe later can be distilled even further into some docs page or ...?  Anyway...
 
So, first up:
 
Q: How /what checks/tests to run?
 
A: OK, I guess I thought armbian/autotests was more about that (long in development hardware), however looking again now it seems it's actually just a script which can be run on its own, just directly on SBC (even without that test rig).  Amirite?

I had started to remove the automatic generation of PDF from documentation, but now I am starting to wonder if that was actually a good idea. 
 
In case you did not know, in addition to https://docs.armbian.com/ you can also download a PDF copy of same from here.
 
Maybe this is helpful for people who are offline while working on their SBC?
 
Anyway, please speak up if you are using this!
 
Related Issue: 96 and PRs: 176, 177.

Is there any available log from the meeting? Sorry for not attending, Saturday afternoons are busy for me sometimes.

A question about Quartz64. Can I create a PR for CSC or do we not support it in any form ?

Sorry for short notice, but if any of you guys see this in time please join release meeting in a few hours:
You are welcome to come and just see how things work.
 
Besides that, I would encourage to idle in IRC and help each other out, ask questions, solve problems together, etc.  And/or on the forums.

schedutil is my default governor, where I recognised the issue first. Tested several times, same like with ondemand the little cores stay at 100 MHz during tmpfs file read and write. Also I'm not sure whether it triggers on I/O alone, as has no option for this like ondemand.

Yeah, valid to mention I did a big rework of current/5.10.y last year that has not been included in any release yet. The images we have up (from August?) do not include them and are very problematic.
The rework fixes a ton of problems and usually brings 5.10.y/current stability, apart from reducing the impact of N2 on the other G12's.
In the process, UHS speeds for SD were lost (they were implemented via vendor uboot 2015 hacks by HK), governor was set to performance.... all things that may have been fixed in latest versions of mainline u-boot; and Neil Armstrong has already pointed me to fixes for a bunch of things, so only more good things to come.
Some users have built from master or tried my unofficial images and feedback was pretty good. If only HK would support us somehow or at least work in a more mainline-oriented way on their own branches....
For next release I hope we can keep 5.10.y as current for some real users to try and after that I'll rework edge kernel to bring 5.15 / 5.16 goodness, uboot 2022.01 already is done by Igor, 100% mainline even for SPI boot (and even SATA boot on HC4).
Right now my N2 is "in production" and has 55 days uptime with 5.10.83-meson64 and is a beast; I'd accept a second one for development, although I'm focused on the HC4 now.
 
 

Many thanks for this. I played a bit more around with these and found the following logic:
With TOACODEC OUT EN and TOHDMITX one can enable analogue 3.5mm output and digital HDMI output. With TOACODEC SRC resp. TOHDMITX I2S SRC one can select the I2S device used for 3.5mm output respectively HDMI output. I cannot get I2S A working (because there is no TDMOUT_A at all), but I2S B and I2S C work for both HDMI and 3.5mm each. I assign it like you did, I2S B to TOHDMITX I2S SRC and I2S C to TOACODEC SRC. Now, with TDMOUT_B SRC SLT resp. TDMOUT_C SRC SLT one can assign I2S B resp. I2S C to an ALSA device, i.e. which one will be hw:0,0, hw;0,1 or hw:0,2. Since there is no TDMOUT_A, I cannot assign I2S A to any ALSA device. I set TDMOUT_B SRC SLT (HDMI) to IN 0 (device 0) and TDMOUT_C SRC SLT to IN 1 (device 1). FRDDR_[ABC] SRC [123] EN needs to additionally enable the I2S sources on the ALSA device, but somehow it is associated in a confusing way: FRDDR_A is related to ALSA device 0, FRDDR_B to ALSA device 1 etc, SRC 1 is related to I2S A, SRC 2 to I2C B etc. Would have been easier to understand when those would be named FRDDR_[012] SRC [ABC] so that device index and I2C identifier match. However, hence I need to enable FRDDR_A SRC 2 and FRDDR_B SRC 3, matching the TDMOUT_[BC] SRC SLT assignments above. Finally I think its the output channels which need to be split for the used ALSA devices, FRDDR_[ABC] SINK [123] SEL. Basically, at least when all channels are used, the three sinks for the used ALSA devices need to be split. With my 2.0/2.1 test audio hardware I just use OUT 0, OUT 1 resp. OUT 2 for each FRDDR_[AB] SINK 1, 2 resp. 3. All other controls seem to have no effect in my case, I guess its about SPDIF input and assigning capture devices/microphones, as of TODDR (to) and FRDDR (from) hence to which audio device input is sent compared what we assigned from which audio device the stream is received and sent to which sinks/channels, or so.

I have two questions regarding mainline (5.10.x) kernel on Odroid N2(+), hope it is fine to ask them here:
It is expected that the boot.ini contains legacy kernel command-line parameters, which are not supported by mainline kernel anymore, including HDMI settings, HPD, overscan, CPU count and clock, right? I saw https://github.com/armbian/build/pull/2629 but the CPU frequency settings are still/again ignored, the CPU always runs at highest possible frequencies. However, it is not a big issue since min/max frequencies can be easily set via CPUFreq API. Interestingly, when using display_autodetect "true", hdmimode "custombuilt" and modeline are set and "hdmitx edid" seems to create two related files in /boot, but all without effect, it seems? I did RAM R/W benchmarks by writing and reading back a ~2 GiB file to /tmp (tmpfs) and evicting filesystem cache between both steps (sync; echo 3 > /proc/sys/vm/drop_caches), via dd (+conv=fdatasync on write step) which reports back the read/write speeds. Somehow with Linux 4.9 provided by Hardkernel (e.g. with the image provided by Meveric here: https://oph.mdrjr.net/meveric/images/Buster/), I get ~doubled speeds, compared to Armbian Linux 5.10 (reproducible, with nice -19, no other significant processes running etc). I have not yet tested the Armbian image with legacy kernel, but has anyone an idea what the reason could be, or whether the benchmark method is faulty for some reason?

Hello gents,
 
I have been out of the loop for quite some time...
Therefore did not update my armbian dev env either for quite a while, was a bit "surprised" after a " git pull " most boards went to CSC, but read the story why...
 
Anyway I was wondering rgd the "new" OP1 Rockpi4+ boards, if same image can be used for these boards ?
Most likely a new entry to compile, armbian building script,  will appear sooner or later. Also noticed current kernel 5.16 holds commits for 4A+ and 4B+ :
 
Rockchip ... Add RK3399 ROCK Pi 4A+ board commit Add RK3399 ROCK Pi 4B+ board commit ...  
 
In +/- two months like to start a PoE ROCK Pi 4A+ board project , checking current status I most likely should start building for "rockpi-4a" and change kernel config a bit.
Hopefully by then a "Bleeding edge" ( 5.16 kernel ) can be compiled for these boards ... 
 
Currently compilation.log shows ( see below ) and suspecting these patches :
Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] board-rockpi4-0005-arm64-dts-enable-es8316-audio.patch info Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] general-fix-es8316-kernel-panic.patch info  
 
 
Grtz! 

UPDATE:
Even changing the cables, the disks keep failing over time. I wasn't able to have my NAS running more than a day or two without a failure on the disks. After buying an APC UPS with Boost and Trim Automatic Voltage Regulation (AVR), my NAS is now running without any failure over more than a week!
So the problem was the unstable energy in my house. Maybe I'll try to put back the original ones to see if it works.