Technicavolous

And I STILL can't get my pi's to do some things that I want ... it's amazing how far Armbian supported boards have taken me and my classes.
 
Keep it up, Armbian crew! No one beats you.

Back in the day we would take a Rubidium source like an SA.22c (can be found on ebay ~$100 - $150) and make a GPS Disciplined Oscillator. The rubidium was accurate for the short period (hours) and the GPS held it really accurate for long time (years).
 
https://www.microsemi.com/document-portal/doc_view/136649-sa22c-user-guide-2017
 
can't find the project we used, but this one makes the point -
https://hackerstuebchen.de/making-a-rubidium-gpsdo
 
Sounds like fun!

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
 
@JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
 
I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

Obviously the author does not need further assistance. Therefore assuming solved.

You can plug the circuit in some simulator (like falstad.com, LTSpice or similar) to check what the parameters do. 
I did that for you here: https://tinyurl.com/yemxbzmt  As you guessed R6 in combination with LM358 B does work as a schmitt trigger.
 
See also this circuit with just the B half. https://tinyurl.com/yehg4ooh
 
The exact size of R6 probably does not matter all that much.

Thx mate..this is the right answer on question!

or... you SSH into a working SBC and use it's spare UART pins to ttl into the non-working SBC... 
Likely to be one of the most silly things I've ever did with an SBC.. But hey, it works...  (at least @martinayotte will like it.   )
 

 

 
 
do we have UART2 and UART3? at least on mine (4.14) we use UART3...  @TonyMac32? Or was it back then when we used UART2? Can't remember anymore..  

This has to be set
 
# max cpu frequency in MHz unit if test "${variant}" = "n2_plus"; then setenv fdtfile meson-g12b-odroid-n2-plus.dtb setenv max_freq_a73 "2400" setenv max_freq_a53 "2016" else setenv fdtfile meson-g12b-odroid-n2.dtb setenv max_freq_a73 "1800" setenv max_freq_a53 "1896" fi
... but I it looks like it doesn't work anymore. I found the problem. Will be fixed at next release.
 
Edit: Tested
 

I get a message that I don't have permission to read that thread ... :[
Still interested in this, I'm much stronger in hardware.

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

Essentialy, yes. VPU is identical in last generation SoC's RK3328 and RK3399, lacking VP9 capabilities in the older RK3288.
 
GPU, on the other hand, is very similar in the high-end SoC's (RK3288 and RK3399), much faster and supporting OpenGLES 3 and OpenCL 1.2. The weaker one, RK3328, supports only GLES2 and no OpenCL, plus no ISP camera either.
 
There is also a parallel solution for Odroid XU4, I will document it soon. In that case, VPU decoding capabilities are reduced (no 4K, only 1080p). But GPU is the strongest one, as well as VPU encoding.

From little I know about Ansible, it seems like it may perhaps even be "the right" tool(?).
 
However, languages / frameworks that current (and likely future) maintainers already know and are comfortable with, IMO, should also be an important consideration.  Perhaps even more important?  I kind of lean this way, but... how willing are people to learn new tool and switch to it?  Especially if that would reduce work / maintenance burden in the long run (which I suspect is true, but do not even know for sure, maybe @lanefu can elaborate here as he seems to be the one with most experience with it)?
 
Just $0.02 from someone who fancies themselves a bit of a strategic thinker and student of computer / tech history.
 
EDIT:  This may seem like a "small" decision, but I don't think it should be rushed.  "Complete re-writes" in different language / framework have been known to kill entire projects (some with much. much more resources behind them than we have).  Therefore the benefits should be clear and real, and not simply based on personal preferences.

Have they released Office/Windows under F/LOSS license?  Tells you everything you need to know.  Leopard don't change their spots, which is why I am not buying that they suddenly "got religion" about open source.
 
Remember, they tried (very hard!) for decades to kill F/LOSS!  Referring to it as "cancer", etc.  Back then, the future was not certain, I can assure you!  By now, things look a lot better, it appears we won and they lost!  We are not only still here, but growing, which is why they had to switch tactic/marketing, or else become irrelevant.  But that is all it is, marketing (i.e., lies, as their actions prove otherwise, see first point).
 
So let them die off already, IMO.  By virtue of their past actions, they no longer deserve to be a part of the collaborative future we are building together.  Make no mistake, they are still the enemy.  And the enemy deserves neither aid nor comfort from us.
 
If you are going to disregard all the above and put it in anyway, then yes, Vscodium would be a more palatable alternative (removing the spyware).  But still misses the (IMO) more important political point.  Not to mention the fact that such a fork is necessary only serves to reinforce my earlier points that M$ still does not really "get it."  Even when trying to do "open source" they still cannot help themselves but put spyware into it, have a EULA, and all the other nonsense we have always expected from them.

For power management install :
 
sudo apt install xfce4-power-manager  

Armbian is (probably) the the only distribution that doesn't use u-boot from 2015. All others are still using stock private Hardkernel boot loader ... We try to get rid of vendors dirty security hazardous code as soon as possible and problems as such is the price that we need to pay.
 
Currently we use u-boot based on 2020.xx, but it looks like it's possible that we need the one from 2021 as this is the case with C2. Some eMMC needs this. Mine obviously don't since it works without any intervention.
Try this image:
https://users.armbian.com/igorp/images/Armbian_21.02.0-trunk_Odroidc4_focal_current_5.10.12.img.xz

The subscriptions behaves weird sometimes. As for myself who was on the intermediate level a few month too I ended up simply canceling everything within forums and paypal, waiting to expire and then do the whole subscription from scratch.

hello.
first i want to say thank you to every armbian supporter and the hole team. thanks for providing this nice project and your work.
 
i did some work for adding an external sound card - the audioinjector pi stereo, which is based on a wm8731.
i used the radxa rockpi4(b)  board based on the rk3399. i choose this board because of pinout header is nearly the same as the one you find on raspberrys. so adding/ using raspberry Hats won´t be too hart in this case.
this will also work with radxa kernel https://github.com/verplant23/kernel
so there shouldn´t be any troubles porting it to armbian legacy.
 
i´m not a coder and i don´t know about linux that much.  for most things this was try and error of code snippets + lot´s of time. 
i tried diffrent ways and there are diffrent ways how thing can be get to work - for sure you guys could make things work better because there are still errors while dmesg.
 
i used 20.05 dev kernel but basicly this also work on master or current. 
please post what you think of or how to improve.
 
install debs or build your own by adding userpatch from 
https://github.com/verplant23/armbian_patch.git
 
after installing / compiling follow up the armbian docs and add i2c7 by adding 
overlays=i2c7  
to your /boot/armbianEnv.txt
 
i wasn´t able to use armbian-add-overlay. because error told me that i don´t use the correct device...
you can use the dtbo inside repo. it was build with the radxa kernel repo (link above). you can find dts inside.  
add the folder /boot/overlay-user/  and copy audioinjector-wm8731-audio.dtbo inside
 
follow up the armbian docs and add 
user_overlays=audioinjector-wm8731-audio
to your /boot/armbianEnv.txt
 
after reboot 
cat /proc/asound/cards should show up the card
 
dmesg will show some error:
audioinjector-stereo sound-ext-card: snd_soc_register_card failed (-517)
 
but since dmesg | grep i2s will show
audioinjector-stereo sound-ext-card: wm8731-hifi <-> ff890000.i2s mapping ok
the device should work.
 
when getting no sound go to alsamixer and check the mute cases especially  Item: Output Mixer HiFi is not muted
 
you can make it sound-card-0 by default
sudo nano /etc/modprobe.d/alsa.conf
should be something like
alias snd-card-0 wm8731-hifi
alias snd-card-0 snd_soc_audioinjector_pi_soundcard
alias snd-card-0 snd_soc_simple_card
options snd slots=,hdmisound,rockchiprk3399,snd_soc_audio_graph_card
 
make sound-card-0 default device 
sudo nano /etc/asound.conf
defaults.pcm.card 0
defaults.ctl.card 0
 
have fun and keep healthy
 

Follow some bash tutorials.  Maybe the advanced bash scripting guide.
 
then just use a text editor and mess with the code
https://github.com/armbian/config
 

Ideas I'm great at ;] but I've wanted for a long time to learn to work with armbian-config.
Will reply on that thread.

I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  

tl;dr. The 500€ subscription has been removed. No one took the generosity challenge
 
As a replacement we added a 20€ monthly subscription to attract people who would like to give more than 5€ but 50€ would be too much.
Existing Small business subscriptions have been "upgraded" to Angel color-wise.
 

Ideas I'm great at ;] but I've wanted for a long time to learn to work with armbian-config.
Will reply on that thread.

No and armbian-config needs to be written from scratch. We have talked about to:

- discuss how to do this @tparys
- make a plan
- divide work into several parts. 

It's a lot of work so we should plan it carefully. I would propose to finish desktop integration first - which is also a very big change, then we go for this. But we can already start talking about - "how to to do this?".

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

So when you boot it while attached to a serial terminal, do you see any quick text go by before you get to that point? Do you see an option to hit any key to stop loading? it's quick lasts 2 seconds ... you're certain you messed up the flash?
 
The UART method is difficult for people who say they have no experience in this 'low level' activity - perhaps the SATA method will work for you?
http://wiki.espressobin.net/tiki-index.php?page=Bootloader+recovery+via+SATA
 
Most likely you have the 1gb 2 chip version. You can tell by identical chips on the top and bottom sides of the board.
In this post is a pic of a board with 1g2cs - I was pointing out that mine did not have emmc in this particular post.
 
 
This post shows top and bottom pics of a 1g1cs board.
 
To be honest, in several cases where I'm told a board has been 'completely erased,' carefully following the instructions on the Armbian Espressobin download page has been successful
https://www.armbian.com/espressobin/
 
I can only help you with Armbian. I have a couple of these boards and they are working flawless for me, although I have them set up at almost the lowest speed it can go (800-800).
 
Let us know if you get Armbian running on your board. If nothing else it will prove the hardware for you.