lanefu

Doing this should probably trigger it.  https://github.com/armbian/build/blob/master/lib/distributions.sh#L157

Also take a look at 

https://github.com/armbian/build/blob/master/lib/distributions.sh#L372-L379

 

Might be related to https://github.com/armbian/build/blob/master/packages/bsp/common/lib/systemd/system/armbian-firstrun-config.service#L9
 

Probably best to keep conversation here for now.  Mostly we use issues in GitHub for major bugs / problems

hi @kentAVR

Sorry I see that the confusion was now.  It was around user provided Kernel Configuration vs user provide Kernel Source Config.

here's an example of a kernel source config you could override.. https://github.com/armbian/build/blob/master/config/sources/families/rockchip64.conf

and yes, yourre correct, the pattern for providing a kernel build config in the top of the userpatches/ folder following the appropriate naming convention.

IMHO the right option is to buy technical support for your model from Armbian. You will get a ready-made, normally working system and a constant update of your devices, taking into account security and new packages. As a bonus, you will get a wide selection of different Debian\Ubuntu systems with a desktop or server versions.

Okay..  There's another open role that you may be interested in:

We're looking for someone who's interested in the hardware, likes to post on the forum to discuss and share technical improvements, but also get angry about low participation, and take any opportunity available to insult the Armbian project and yell at developers and contributors who generally have good intentions.
 
Is that something you'd be interested in taking on?

No worries. I am already an adult. To be more precise, I'm already over 60 years old. To use your words, I was scared by the tone and expectations of you developers. It's the first forum I've experienced that was designed for developers and not for users (3 of 18 sections are for users). A beginner has to come to terms with that first.
You constantly write about how much effort the development is and that you want support - but when one is ready to cooperate, he will be left out in the cold.

It is not yet 3 months since I bought my first rockpi4. Before that I had no contact at all with such small parts- and for so, I don't know anything about its requirements or handling.
 
From there - my question was meant seriously. But I also do not have to impose myself.
I have almost reached my goals, so I am quite satisfied.

Had similar report for a user of stable helios4 after their rootfs package updated. 
 
Ive modified jira issue to reflect broader scope

Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:

 
And a pinheader to solder onto the OrangePi Zero board itself.

 
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.


 
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:

 
ntp[sec] in action:

 
Thanks a lot!
Groetjes,
 
p.s. I still have to figure out why I needed this

anyway I think i solve it using sudo apt-get upgrade --fix-missing

Thanks for the detailed walkthrough.  Solved issues with QEMU and editing meson-g12b.conf
 
so far no stack traces dumped with 5.8.7.1_35809.20191129_COEX20191120-7777 88x2bu which is the root goal. normally had them every hr so that's a good sign.

Hi,
Have you checked "nut" (network UPS tools) to see if they have some prefab solutions?
Perhaps a custom nut driver, as I recall they have this type of behavior already available for "regular" UPSes.
Groetjes,

Hi, sorry, I forgot to mention that the configure-serial-tty script does require some target modification: it depends on the baudrate being fixed on the target, as sending <BRK> both triggers Magic SysRq and optional baudrate switch by *getty. To get this to work on my setup with highish successrate, I reconfigured the target's serial-getty configurations to only work on one baudrate.
 
See parts of my ansible task that sets that puppy up:
The ansible task shell script will try to parse the commandline to get the currently configured baudrates. It assumes the baudrates are sorted from high to low, i.e. 1500000,115200,38400,9600 for my NanoPi R2S and Helios64 boxen. It will replace the baudrates with the most-left it had parsed (which should be the highest baudrate). It also will disable the options to *getty that skip setting the baudrate explicitly (i.e. keep-baud and extract-baud).
 
Let me know if this worked out for you!
Groetjes,

I just have to share my method to test distros headless with my OdroidN2. The N2 boots eMMC before SD card, so what I did was to flash the SD card with an armbian distro and get it up and running. 
 
the SD card always shows up on mmcblk0 and the eMMC on mmcblk1. So it boots from SD when it can't find a bootloader on the eMMC. I can flash any image easily with
dd if=image of=/dev/mmcblk1 and just do a reboot, and it will boot the eMMC.
 
Whenever I want to test another image, i can just do
dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=1 to make the eMMC unbootable, causing it to start on the SD image on the next reboot.
 
A very nice way to test stuff out remotely. I only know it works on the N2, but the concept should be appliable to other SBCs (maybe USB/SD boot..?). I'm sure it's nothing new but the "aha" moment for me was the blanking of the bootloader (doing an unbounded dd if=/dev/zero of=/dev/mmcblk1 caused my device to hang not being able to reboot).

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

Hi,
I made a small detection script using expect. That will spit out the hosts it found per try and baudraute guesstimate. Afterwards it will query the USB port location using udevadm info and build udev rules on a name basis for the hosts it found on those ports.
It's not a generic solution, let me know if you are interested, I'll share when back at my workstation.
Groetjes,

https://www.zdnet.com/article/google-should-really-open-source-chromium/
https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

We also have our SBC test rigs which have GPIO power control.
 
I've proven out the general process of SSHing into a board,  doing `curl -s http://path/to/armbian.omg | dd of=/dev/blockdev bs=1M conv=fsync` and then immediately cutting power as a 90% reliable process for applying images.

I really want to tie this library. https://github.com/lanefu/sbc-gpio-pcf857x/blob/main/lib/gpio.sh

with ansible and our netbox inventory to find board and gpio on our pdu.
 
I have POC of ansible inventory
 


We also have an armbian ansible collection which currently has a facts module for identifying armbian specifics in /etc/armbian-release
 
https://github.com/armbian/ansible-collection-armbian

We have lots of great pieces now we need to glue them together!

In the past few weeks I have been working to improve processes of deploying our work. Scripts that runs in the background are combination of tools that are build into the main tool and additional scripts that run on the server. They are (will be) summed in a (private) scripts repository, but the functioning - which could be interested for any maintainer - are summed in this document:

https://docs.armbian.com/Process_CI/
 
Welcome to add your ideas, especially for the merge request part, which remain unchanged. Otherwise its planned to extend this automation to execute tests, similar or the one from @William Bonnet on virtual image (image already boots insite Github actions) and real hardware (need implementation).
 
Examples:
 
- updating images and kernel update for families that those boards belong to: rockpro64, station-p1, station-m1, odroidc2, odroidn2, odroidc4, odroidhc4, odroidxu4, nanopir4s, udoo, cubox-i, rockpi-s, rockpi-e, rockpi-n10. nanopct4, espressobin, tinkerboard
- building under Docker and booting qemu image inside Github action (WIP, not enabled yet)
- upstream kernel changes for a few families caused rebuild and updating of both repositories
 

Manually or by driving our test rig?
 
 
 

Cleaned up and sorted Jira Board

https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&selectedIssue=AR-572&atlOrigin=eyJpIjoiY2FjZTM3YjZmZDI2NDI0MmIzY2MzYzdmYzg3Nzc1YjIiLCJwIjoiaiJ9

This issue is fixed in upstream u-boot by commit a246e21 ("arm64: dts: meson: odroidc2: readd PHY reset properties"), which is included in u-boot  v2021.07-rc1. The regression was caused by the backport of a kernel commit that had change a reset timing too aggressively, and first went into u-boot v2020.07. See upstream discussion, openSUSE bug 1187095.

I'll report back once I see the issue resolved. I think a couple days was the maximum time without losing the NICs.

@Igor @lanefu There are two options working in this branch.
For 5.12, the standard process for applying patches is.
For 5.10, a series of patches is used.
Both variants use the new mechanism and version numbering for the kernel and u-boot.
Here I have laid out a hand tool with which I extract a series of patches.
 
My lib.config
~/build$ cat userpatches/lib.config # KERNELSOURCE="https://github.com/megous/linux" if [ "$KERNELPATCHDIR" == "sunxi-current" ]; then KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git' KERNELBRANCH=tag:v5.10.37 fi  
Result:
~/build$ ls output/images/ Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.sha Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.txt ~/build$ ls output/debs armbian-config_21.08.0~trunk_all.deb linux-dtb-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware_21.08.0~trunk_all.deb linux-headers-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware-full_21.08.0~trunk_all.deb linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-zsh_21.08.0~trunk_all.deb linux-libc-dev-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb extra linux-source-edge-sunxi64_21.08.0~trunk_all.deb focal linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb ~/build$ dpkg --info output/debs/linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 287004 bytes: control archive=424 bytes. 335 байт(а), 11 строк control Package: linux-u-boot-orangepipc2-edge Version: 2021.04-armbian-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 1 Section: kernel Priority: optional Provides: armbian-u-boot Replaces: armbian-u-boot Conflicts: armbian-u-boot, u-boot-sunxi Description: Uboot loader 2021.04-armbian ~/build$ dpkg --info output/debs/linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 28504152 bytes: control archive=72124 bytes. 483 байт(а), 13 строк control 282583 байт(а), 2821 строк md5sums 422 байт(а), 15 строк * postinst #!/bin/bash 297 байт(а), 12 строк * postrm #!/bin/bash 898 байт(а), 33 строк * preinst #!/bin/bash 295 байт(а), 12 строк * prerm #!/bin/bash Package: linux-image-edge-sunxi64 Source: linux-5.12.9-sunxi64 Version: 5.12.9-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 126265 Provides: armbian-edge, linux-image, linux-image-armbian Section: kernel Priority: optional Homepage: https://www.kernel.org/ Description: Linux kernel, armbian version 5.12.9-sunxi64 edge This package contains the Linux kernel, modules and corresponding other files, version: 5.12.9-sunxi64.  
P.S. I am waiting for healthy criticism and suggestions.

Thank you for showing your script.
Beautiful work! I love verbose coding :)
 
Thanks for that command!
Haven't read about fdtoverlay before.
That's a very nice way (with little additional scripting) to enable overlays for cases where dynamically overloading is not supported.
 
Good job!
This is by far the first reason for using "new" gpiod layer.
Your key sample didn't convince me. I prefer "my" way of button handling. But finding pins by pin-name is sexy :)
 
Do you mind to publish the source of your overlay?
I asked dtc for the source, and it looks terrible. Can't believe, that you had to write such ugly stuff.
 
Do you know about a way to find conflicts between muxed modules, which share the same pin?
A developer told me, that pwm-pin for the fan control of penta-sata-hat conflicts with hdmi sound (I2S ?).
I'd like to verify that. But I can't
I use both - the fancontrol on the same rockpi4 which generates the sound for my AVR (over HDMI) and I can't confirm any conflicts as I don't hear any problems.

In case its help i made a helper script for managing relays
 
https://github.com/lanefu/sbc-gpio-pcf857x

ifupdown