guidol reacted to NicoD in Real time operating system
I was thinking exactly the same question. Why do you bother and waste your time here if you don't like Armbian?
Lately I've red few complaints of people who have "many years of experience". But they don't want to bother reading and learning new skills.
Experience is not the same as knowledge
As knowledge is not the same as experience
With experience you can have gained knowledge about much but not being specialized at one thing, or know a lot about a small section of the industry and be blind to all other.
Thousands of people happily use Armbian on their devices and for 99% of the usecases everything is fine. The other 1% we try to help here.
I've made tons of informative videos about SBCs. I show how to do all the basic stuff, and some more advanced things.
The forum also has the Reviews, Tutorials and Hacks section where almost everything you could want to learn about Armbian is explained.
Then there is Armbian Docs also full of information.
All these things have cost us time, and so also money. We are here to serve. And then you say our work is "garbage".
Sorry, but I do not take that lightly.
You can't teach someone who is convinced to know it all. Greetings.
guidol got a reaction from malaga in [Invalid] - operating-system wanted for the Alwinner A 20 - which one to take
find at https://www.armbian.com/download/ all downloads
- Alwinner /banana Pi A 20
- Udoo Quad Makerboard Rev. D.
- Orange PI Prime rev 1.0
guidol got a reaction from Igor in Odroid C2 : no eth0 with latest image
My C2 did already work/reboot with
U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2
But today I compiled the new u-boot
U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
which does also work/reboot fine on my C2
System diagnosis information has been uploaded to http://ix.io/2SaS
does also work with newer dev-kernel
FROM Linux 5.10.19-meson64 TO Linux 5.11.4-meson64
System diagnosis information has been uploaded to http://ix.io/2SaU
# dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,0525366 s, 13,4 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2 # dpkg -i ./linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb cd /usr/lib/linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64 dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=./u-boot.bin of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 [reboot] # dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,04659 s, 15,1 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
guidol reacted to Adrian Cable in H2/H3: "old problem" Link (eth0) is Up/Down syndrom
We have a commercial product running on Armbian based on the OPi Zero platform. We occasionally get reports from customers of intermittent connectivity, which (looking at the dmesg log on affected devices) manifests itself as something that looks very much like the up/down syndrome reported here. In this case we advise customers to purchase a cheap switch (e.g. https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unmanaged/dp/B07S98YLHM/ref=sr_1_3?dchild=1&keywords=4+port+switch&qid=1614793487&sr=8-3) and put it between our product and their existing switch or router. We have found this always resolves the issue.
We still don't understand the cause, but at least we have a workaround (albeit not a perfect one).
guidol reacted to Elclaudio in Odroid C2 : no eth0 with latest image
OK I FOUND THE CULPRIT ! the issue come from UBOOT like I imagined. After installing older uboot ETH0 worked straight away
Since I couldn't find the uboot .deb used in my old armbian 5.95 in https://imola.armbian.com/apt/pool/main/l/
I took the uboot files from my WORKING armbian version kernel 4.19.69 in /usr/lib/ linux-u-boot-next-odroidc2_5.95_arm64
there should be 2 files : bl1.bin.hardkernel and u-boot.bin
copy them wherever you want on the latest armbian (currently in test : Armbian 21.02.2 Buster with Linux 5.10.16-meson64,) Linux odroidc2 5.10.16-meson64 #21.02.2 SMP PREEMPT Sun Feb 14 21:50:52 CET 2021 aarch64 GNU/Linux
I backed up the original files in the same directory with .ORI extension
Then I run the commands here
If you do it beware with dd it could crash your partition if missused, also adapt the paths and filename to your particular case.
#!/bin/bash # install older uboot from armbian kernel 4.19.69 dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/u-boot.bin.OLD of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 # restore original uboot #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/u-boot.bin.ORI of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1
It would be nice now to debug what's gone wrong with uboot code...
guidol reacted to martinayotte in [Warning] NPi K1 Plus (not Pihole) seems to have trouble with kernel 5.11.1
If you look at the resulting image, maybe the rtl8189fs.ko is still present and broken ...
Anyway, I've done builds+tests on all my OPi which using this rtl8189, and results are successful, I've done this commit :
guidol got a reaction from Werner in [Warning] NPi K1 Plus (not Pihole) seems to have trouble with kernel 5.11.1
As a test I updated on a secondary Pihole-Server (buster on NanoPi K1 Plus) the kernel to 5.11.1-dev and at startup Pihole did seem to make some trouble
The server isnt getting to the login prompt and on the serial console the last info is "Starting kernel..."
I updated some of my SMB-Servers with kernel 5.11.1-deb without problems.
Will later try a new resinstall with buster and 5.11.1 and see if Pihole will run on a complete new installation.
guidol reacted to tparys in What diffirend armhf and arm64 for .deb packets?
Some additional information for the curious ... https://www.debian.org/ports/arm/
The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.
guidol got a reaction from DominicanGuy in Updated armbian-config v5.81
Did create a more compact version for me (and you?)
nano /etc/update-motd.d/10-armbian-header ARMBIAN_bsp=$(more /etc/armbian-release|grep VERSION|cut -f 2 -d '=') ARMBIAN_kernel=$(dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_uboot=$(dpkg -s linux-u-boot-$BOARD-$BRANCH|grep Version|cut -f 2 -d ' ') ARMBIAN_dtb=$(dpkg -s linux-dtb-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_firmware=$(dpkg -s armbian-firmware|grep Version|cut -f 2 -d ' ') ARMBIAN_config=$(dpkg -s armbian-config|grep Version|cut -f 2 -d ' ') printf '\n' printf 'pkg-version kernel[\e[0;91m%s\x1B[0m] u-boot[\e[0;91m%s\x1B[0m] dtb[\e[0;91m%s\x1B[0m] firmware[\e[0;91m%s\x1B[0m] config[\e[0;91m%s\x1B[0m]\n' "$ARMBIAN_kernel" "$ARMBIAN_uboot" "$ARMBIAN_dtb" "$ARMBIAN_firmware" "$ARMBIAN_config" printf '\n'
guidol reacted to Igor in 2021: Year of the Armbian Desktop!
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.
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
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.
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!
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:
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:
During this change we also added most recent userland(s):
guidol got a reaction from Igor in NanoPi A64 doesnt connect with onboard Ethernet/WiFi with new compiled current/dev image
its working again with 5.10.10 (with my - at this time- local .dts/.dtb-change)
_ _ ____ _ _ __ _ _ | \ | | _ \(_) / \ / /_ | || | | \| | |_) | | / _ \| '_ \| || |_ | |\ | __/| | / ___ \ (_) |__ _| |_| \_|_| |_| /_/ \_\___/ |_| Welcome to Armbian 21.02.0-trunk Buster with Linux 5.10.10-sunxi64 No end-user support: built from trunk package bsp-kernel[21.02.0-trunk] u-boot[21.02.0-trunk] dtb [21.02.0-trunk] firmware [21.02.0-trunk] config[21.02.0-trunk] branch[dev] System load: 4% Up time: 14:55 Memory usage: 10% of 985M IP: 192.168.6.116 CPU temp: 27°C Usage of /: 10% of 15G
System diagnosis information has been uploaded to http://ix.io/2Npi
guidol got a reaction from Igor in NanoPi A64 doesnt connect with onboard Ethernet/WiFi with new compiled current/dev image
@Igor I created https://github.com/armbian/build/pull/2579
but please ignore the old part about the configuration.sh from 2019 - its only the 2021-part about the phy-mode patch
guidol reacted to Igor in Bug GUI Armbian on Pinebook
Yeah, that's it. IMO something is wrong with / around LCD driver. I suspect this - Pine only sells Pinephone, which is the very similar hw, just in different form factor and by upstreaming LCD on Pinephone they break support for Pinebook somehow ... Since we already lost several afternoons trying to fix this it is unlikely to repeat that anytime soon. Not possible
guidol got a reaction from Igor in [Q] NanoPi Neo2 doenst boot anymore (complete) because of longer UUID
@Igorstrange - got near the same problem this evening with a nanoPi K1 Plus
(after updating to pihole FTL 5.5.1 and reboot = https://pi-hole.net/2021/01/19/pi-hole-ftl-v5-5-released-update-today#page-content )
The NPI K1 Plus is searching a shorter UUID than shown as blkid
The Boot-Error does show
So I did put the card of the NPI K1 Plus in my Neo2 (IP24) and monuted it on /mnt/sdb1
But with blkid and in /etc/fstab and /boot/armbianEnv.txt I ons could find the long UUID:
boot-err 971c3757-23ee-42 blkid 971c3757-23ee-4281-b0cb-989e7255e3d9 fstab 971c3757-23ee-4281-b0cb-989e7255e3d9 armbianEnv 971c3757-23ee-4281-b0cb-989e7255e3d9
Everthing seems OK - so because the Neo2 had the problem in /etc/fstab I deleted (the correct one) and replaced it with (in my sight) the same text and did put back the card in the NPI K1 Plus and it worked again ?? just fine Dont know what happend - while booting- the 4 times before I removed the card...
This is the second time this month with a different device...
System diagnosis information has been uploaded to http://ix.io/2MCd
guidol reacted to Igor in again a "no ethernet after update" - this time NanoPi K1 Plus with 5.10.4-dev
Thank you - you save others I didn't spot this problem ... fixed. I guess I'll need to expand my test rig with a few more boards.
guidol reacted to klbmnbdd in [Info] How to compile the actual 64Bit version of stockfish chess engine
Thank you for providing these valuable infos.
I successfully installed picochess with the current Stockfish 12 engine and the 3-4-5-men syzygy endgame tables on a 64 GB eMMC chip with Ubuntu 20.04.
Now I can use my Odroid C2 with a DGT Smartboard in conjunction with a DGT 3000 chessclock.