lanefu got a reaction from malaga in collect data (temperature & humidity) from DHT22 into csv and sending them over the net
to @arox's point.. MQTT is a good fit for this.
Mosquito is easy to install.
Here's an example of doing something similar.. with a different library
lanefu got a reaction from pfeerick in Unable to boot 'focal' or 'buster' images on SOPine Clusterboard
Any chance you can share the patched version of the dts. Will make it easier to add it back into armbian build
lanefu reacted to binarym in NanoPi R2S: lan0 goes offline with high traffic
Hi all !
I faced the same issue with my Nano PI R2S : even with nightly builds, the r8152 randomly hanged and lan0 disappeared.
I built a minimal armbian buster and revert the driver to previous 1.11 version.
I also manually modified my /etc/udev/rules.d/70-rename-lan.rules with the following content:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rk_gmac-dwmac", KERNEL=="eth0", NAME="wan0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off rx off"
It manages correctly my home fiber with ~600Mbps for DL and ~300Mbps for UL.
Under heavy charge, i didn't experiment lan0 freeze for at least 1h (previously, it froze every 10 minutes).
I guess 2.5Gbps support is lost but:
For people with 1Gbps network, it's enought. I have serious doubt regarding the ability of R2S to route 2.5Gbps traffic ;-)
For people interested and who do not have time/skill/machine for compilation you can download the image here (~950MB uncompressed) : https://drive.google.com/file/d/1RRvmObBDi58TRTnZN661PL0PYFRbAi0_/view?usp=sharing
lanefu reacted to kgblack in Differences Between Armbian and Debian
Here's a package comparison I did today of fresh installs (yesterday) of Armbian and Debian. Unfortunately, I forgot to do an update/upgrade of Armbian before listing the packages, so Armbian may appear to be slightly out of date compared to Debian, but the comparison took me too long to repeat it just for that update.
comparison in pdf
comparison in csv
Here are the 28 Armbian packages I updated after the comparison:
armbian-config armbian-firmware armbian-zsh avahi-autoipd base-files curl
debian-archive-keyring groff-base iputils-arping iputils-ping libbsd0
libcurl3-gnutls libcurl4 libnss-myhostname libpam-systemd
libpython3.7-minimal libpython3.7-stdlib libssl-dev libssl1.1 libsystemd0
libudev1 linux-libc-dev openssl python3.7 python3.7-minimal systemd
lanefu reacted to SteeMan in Make forum messages friendlier -- 2021 Edition!
Given the following comment posted in response to the new invalid message discussed above:
"Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums. While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear. To that end I have the following suggested wording changes:
To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
>> https://armbian.com/bugs <<
Issue reports that are not following these guidelines will be removed without further notice!
Important Please Read Before Posting a New Topic (Bug Report)!
You are about to post a new topic in the Armbian Bug Tracker. Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
>> https://armbian.com/bugs <<
With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported. Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.
lanefu reacted to NicoD in Video : Running Debian Buster on the Odroid Go Super and review of the hardware
I recently bought the Odroid Go Super. It is a great handheld for emulation gaming. But that isn't the main reason why I bought it.
It can also run Linux, tho not Armbian.
In this video I show how I use Debian Buster from Meveric on the Odroid Go Super and I also review the hardware. Greetings.
lanefu reacted to hexdump in Jetson Nano
just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
lanefu reacted to Palaretri in Can't see eMMC on BPI-P2
I'm working with a BPI-P2 board.
I installed the last Armbian version for BPI-M2 as the two boards are basically the same except the RJ45 connector and the eMMC.
I installed it on an SD card, and everythig worked perfectly.
Now I need to put the OS on the eMMC and then completely remove the SD card, but I'm struggling.
The default Armbian for BPI-M2 is not intended to support eMMC, so I'm not surprised that with this version the eMMC dosn't show up.
So I tried to modify the dtb and enable the eMMC nodes, and then reboot.
Here the changes I made:
reg = < 0x1c10000 0x1000 >;
pinctrl-names = "default";
pinctrl-0 = < 0x0d >;
resets = < 0x03 0x08 >;
reset-names = "ahb";
interrupts = < 0x00 0x3d 0x04 >;
status = "okay";
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
compatible = "allwinner,sun7i-a20-mmc";
clocks = < 0x03 0x17 0x03 0x4a 0x03 0x4c 0x03 0x4b >;
clock-names = "ahb\0mmc\0output\0sample";
vmmc-supply = < 0x0b >;
vqmmc-supply = < 0x0b >;
mmc-pwrseq = < 0x0e >;
bus-width = < 0x04 >;
phandle = < 0x44 >;
pins = "PC5\0PC6\0PC8\0PC9\0PC10\0PC11\0PC12\0PC13\0PC14\0PC15\0PC16";
function = "mmc2";
drive-strength = < 0x1e >;
allwinner,drive = < 0x03 >;
phandle = < 0x54 >;
Sadly this wasn't enought, and I still can't see the eMMC.
I read a lot of threads, but I've not been able to find a solution.
I guess that I have some problems with the uBoot or with the drivers not present in the kernel.
I'm quite new to Linux, and I've never recompiled a kernel or a uBoot.
Please, can someone help me?
lanefu reacted to zimme in Odroid C2 : no eth0 with latest image
I just wanted to write an update on this issue as I've ran into it also, but I figured out a way to make it work.
My board was in a "broken" state where the network card wasn't working with any of the latest versions of Armbian using a newer u-boot like 21.04-rc3.
I compiled my own versions to test the latest edge and using u-boot 21.04-rc4, etc. but nothing worked.
I got it working by accident and I wasn't sure how but then I flashed the sdcard again with a different version and got into the broken state again.
This lead me down an evening of frantically testing a bunch of things and that's when I discovered a way to get out of this broken state with a newer
version of u-boot (21.04-rc or later).
Grab the latest stable image which uses u-boot 21.04-rc3, flash it to an sdcard and boot the board and wait 5 min or something to make sure the board has actually booted (I'm running headless so no monitor connected).
Once you're sure the board has booted, unplug the network cable and reconnect it. Then wait for a couple of minutes and then power cycle the board and that made the network card work again for me every time I
got into this broken state.
Hope it helps someone else and if not I guess that something else made my network card work again.
lanefu reacted to vmiceli in Defaults for Ethernet coalesce?
I have completed my Armbian NTP server based on the wonderful little NanoPi Neo3. However something bothers me a bit, i.e. how much delay or latency is in eth0 (It is a 1Gbs port).
By checking the default eth0 settings (ethtool -c eth0) I have the parameters below. In particular rx-usec = 327usec means that when a packet is received, the IRQ to alert the CPU can be delayed up to 327usec. With these settings on the nanopi (NTP server) I get about 1msec delay on the NTP client (Windows PC). By cutting the rx-usecs to 35 usecs I get a delay on the client of about 450usec, so a massive improvement and 30% faster than rpi 4.
At the moment, in order to change this parameter after boot, I have the two lines below into /etc/rc.local, the delay is needed as the command may be issued before eth0 is ready to accept it (I found this the hard way):
sleep 10 sudo ethtool -C eth0 rx-usecs 35
The question: Is there a place where those eth0 defaults are saved? If there is a config file somewhere or even in the Kernel (I can re-build it) I could change them to a new default and avoid the rc.local hassle and delay. I guess I like a leaner approach :-)
root@nanopineo3:~# ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 327 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 100 tx-frames: 25 tx-usecs-irq: 0 tx-frames-irq: 0
lanefu reacted to tparys in Avnet MicroZed
Foreward: Not sure if this better fits in board bring up, but I can't post there, so feel free to move if appropriate.
I'm looking into the feasibility of using the Armbian build system to generate OS images for the Avnet MicroZed board. This board is based on the Xilinx Zynq 7000 platform, which is a SoC made up of a dual core 500 MHz CPU, and a Artix-7 generation FPGA. The CPU is nothing to write home about, but the FPGA opens up an interesting array of possibilities. Just in case you need an ARM board with 100+ GPIO, over two dozen serial ports, or your own function generator. Really, you're limited only by pin count, FPGA fabric usage, and what you can manage in Vivado. Xilinx also has an active presence on GitHub, and branches for kernels as new as 5.12, so sees active support.
The big rub, is that the Zynq CPU boots off a VFAT partition, that contains a file named "boot.bin". This boot file combines the first stage bootloader (FSBL) and u-boot, and needs to execute a C application to assemble this file. The application is recently open sourced, and previously existing open source software also exists. But I'm not sure how best to integrate that with the build system, or identify that the platform u-boot package depends on this extra package.
lanefu reacted to Igor in Avnet MicroZed
Would come handy sometimes. For the next version of our test gears perhaps.
FAT is not a problem. https://github.com/armbian/build/blob/master/config/boards/odroidc1.csc#L7-L8 Build system can support weird boot processes - this way:
lanefu reacted to piter75 in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x
I am not sure of that.
My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
-rockpi-4b legacy focal cli stable yes means that focal legacy image for rockpi-4b will not be built.
Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
lanefu reacted to Drakes in H6 Famous Reboot problem
Hi all, it's 2021 and this famous reset problem is still a problem with the Allwinner A64. I've made a long article about everything I tried to get a A64 reset to initiate, even low-level register writes, but I'd like to get another set of eyes on this. Maybe I'm missing something obvious?
lanefu reacted to Salvador Liébana in 640x480 modeline doesnt work
many thanks for your time. it did not resolve the problem but it switched to modsetting
Device-1: display-subsystem driver: rockchip_drm v: N/A bus ID: N/A
Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A bus ID: N/A
Device-3: rk3399-mali driver: panfrost v: kernel bus ID: N/A
Display: x11 server: X.Org 1.20.9 driver: modesetting
OpenGL: renderer: Mali T860 (Panfrost)
v: 3.1 Mesa 21.1.0-devel (git-befd9fb 2021-03-21 focal-oibaf-ppa)
what component of those it's the faulty or the one without this kind of support if you can guess?
the thing is we run wine games... and they are very low res. 640x480 and 800x600 are quite common then and it doesnt work at all at those resolutions.
@Kwiboo do you know something about this?
lanefu reacted to bunducafe in Does anyone actually have a stable system?
After fiddeling aroud I finally have the helios64 also running solid. I never had any freezes before just some problems with getting the system to boot from the emmc device and, see other thread, with setting up OMV - LUKS - Snapraid - UnionFS
I am currently under: Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux
OMV Version 5.6.2-1 (Usul)
So I would say that OMV is not the culprit out of the box. The system works fine but it always depends on what kind of plugins you are using etc. So far I have no docker installed here but I certainly will do that again. I do recommend the OMV Backup Plugin so I can boot from the latest stable release via SDcard if I mess up with something. That's also nice.