ygoe

Alright, I've retried with the Debian instead of Ubuntu image. Same steps as before. I can indeed hear something now. Very loud. And very noisy. Nothing but noise actually. I've prepared a very quiet mp3 file (scaled down by -20 dB) because I knew 100% volume would be way too loud. And it just comes out of my speakers as loud noise. Seems like the device was actually found this time but the data it generates is completely unusable, near random. The noise stops as soon as I terminate mpg123. I'm afraid my speakers might get damaged by this. Totally unusable. If this is all we get, I'll have to find a solution with Raspberry Pi really. I don't want that because these boards are much bigger, more expensive and need 3x the power. I haven't tried with a Raspberry Pi Zero (non-W), might need to get one of them. But their hardware is really old now. And I need an ugly external USB Ethernet adapter for it. I wish Raspberry Pi OS supported other hardware, too. But I really need the software volume control as well because my amplifier or speakers have no control, they just do what they get. It's those tiny 3 W boards but I found they're totally enough for my ears (and also my neighbours'). BTW, is it normal that the second 'dtc' command to compile the device tree writes out 223 warnings?

Well, I cannot reproduce your configuration. It just doesn't work on my copy of the device. Are you sure the kernel already knows what to do without recompiling? Can I verify this somewhere? Should I find a log entry somewhere? Or how else can I see why aplay lists a device that noone else can find? Are we talking about a current version of "Armbian 21.08.2 Focal with Linux 5.10.60-sunxi" on a NanoPi NEO? I'm using a fresh installation, latest download image as of yesterday, nothing else installed or modified so far. BTW, in the meantime I've also tried out FriendlyElec's own Ubuntu Linux image. It already comes with all sorts of audio devices but none of them works either. I can't remember the details, I've posted it to their forum. But that looks pretty dead to me, my post as a new user wasn't moderation-approved within 3 days and I cannot see my post anymore/yet. Here's the current output of speaker-test -DI2Smaster -c2 speaker-test 1.2.2 Playback device is I2Smaster Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM I2Smaster Playback open error: -2,No such file or directory

Here's the asound.conf file I used successfully on a Raspberry Pi 3B+, including volume control. But I can't make any sense of its content. Would there be something in it that is useful for a NanoPi?

Okay, thank you, that looks much more like my skillset. I followed all the steps and gathered the mentioned files from the rest of the thread. I can see an I2S device but volume control and MP3 playback don't work yet. aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I2Smaster [I2S-master], device 0: 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 [1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 aplay -L null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=I2Smaster I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Default Audio Device dmix:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct sample mixing device dsnoop:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct sample snooping device hw:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Direct hardware device without any conversions plughw:CARD=I2Smaster,DEV=0 I2S-master, 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 Hardware device with all software conversions alsamixer cannot open mixer: No such file or directory alsamixer -c 0 This sound device does not have any controls. mpg123 some.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.25.13; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock Segmentation fault speaker-test speaker-test 1.2.2 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Playback open error: -2,No such file or directory Something seems to be different today than when you showed your log.

Oh dear, that is complicated. I don't have such an Armbian build system. I guess that needs to be a powerful Linux computer. What exactly is the trouble if this was enabled right in the distribution kernel? Is it unstable? Could it cause random noise or data loss? Does it eat kittens at night? I'm actually looking towards a Raspberry Pi Zero with a USB Ethernet adapter for my project instead of the nice little NanoPi.

Hello, I've been playing on my Raspberry Pi 3B+ with an I2S audio amplifier and could play music from it. Now I want to add more devices to experiment with multi-room systems. The only other system with I2S support I have here is a NanoPi NEO. It has dedicated I2S pins so that shouldn't be too complicated. I thought. But it doesn't work. 'aplay -l' says "no soundcards found" and 'speaker-test -c2' essentially says the same. 'armbian-config' doesn't have a switch to enable I2S, only SPDIF, which sounds plausible considering that the SPDIF pin is multipurpose while the I2S pins are not. A web search for several terms didn't bring up something useful. Searching this forum for "i2s" gives me even no result at all, which I consider an error because I've seen this topic discussed here from the web results already. So I have no clue how to make I2S work on a NanoPi NEO with Armbian (all updated). The pins are connected correctly (I believe) but the software doesn't seem to know that these pins exist. On the RasPi I had to create the file /etc/asound.conf. I also tried that on Armbian but it has no effect. Maybe its contents does not apply here? What do I have to configure or install to make this work? Shouldn't it work on its own already as the other tools are also pre-installed?

Not sure about the bridge. I have none, says "brctl". armbian-config didn't use a bridge either. The "bridge=br0" line was commented out from the start. At least I'd expect to connect to the device itself, even if I won't get anywhere else. That'd be fine if I want to configure the IoT device via an AP WLAN interface. It doesn't need to provide a WLAN gateway to the internet for me. Update: I've attached the dual-band adapter again. This time, after a reboot, the channel 5 was actually applied. I have no idea why it worked now when it didn't yesterday. And I still have no bridge but can connect to the internet via this AP. traceroute confirms this extra hop. So a bridge certainly isn't required here. Very confusing. Or maybe just unreliable. Still, the 2.4-GHz-only adapter doesn't work at all. And it's one with known good Linux support from Edimax, recommended for RasPi.

Maybe my description was a bit confusing. I'll try to clarify. I don't want to have an access point on both bands at the same time. I just want it on one (configurable) band. That's already enough. At first the armbian-config tool chose the 5 GHz band for me and everything was fine. But it didn't offer me to change that (or it did and failed, I can't remember). I wanted to use the same dual-band adapter and have the network on 2.4 GHz now. That is part one. Doesn't work because the SSID isn't visible in 2.4 GHz, only in 5 GHz channel 40. Part two is that I tried with a different WLAN adapter that can only handle 2.4 GHz. This time, the SSID appeared on channel 5 (which also certainly isn't blocked anywhere in the world) but dnsmasq failed to start, probably because the WLAN adapter doesn't have the static IP address that's configured for it. Can a WLAN adapter driver bug cause the static IP address assignment to fail? Without any entry in dmesg? Recently I've learned that Linux drivers can contain any bugs anyone could or could not imagine, including bugs that haven't been invented yet. But this sounds pretty simple to me. WLAN access point configuration looks very complicated to me, with lots of settings no user of a regular access point consumer device would ever see. I'm wondering if all of this is necessary. The more settings there are, the more mistakes one can make setting them. Can I just leave some of them out? Is there a minimal working config set described anywhere? Each WLAN AP tutorial on the web shows completely different settings and values.

Not at the same time. Only one WLAN adapter is attached at any time. First I tried one, then I tried the other that only has 2.4 GHz to see if I can force the AP onto that band this way. I could but got other problems.

Hello, I'd like to set up a WLAN access point with WLAN adapters attached to USB on my Orange Pi Zero. First I started with a dualband adapter and used the armbian-config tool. It took forever (like minutes with a black screen) but eventually completed and gave me a working access point on channel 40. That's fine but I also need to be able to change this to a 2.4 GHz channel. That's where things got problematic. I edited /etc/hostapd.conf and changed the channel number from 40 to 5, then restarted hostapd. That didn't work. The service restarted but there was no access point anywhere to be found on the air. Also, the WLAN adapter's LED didn't blink regularly as before, but only occasionally. I couldn't find anything in the logs. Can't I just change the channel number? Do I also need to change other settings? Next I tried with another WLAN adapter that only supports 2.4 GHz. I rebooted the device with the other adapter attached. It was also recognised. I updated these files to use the new network interface accordingly: /etc/network/interfaces.d/armbian.ap.nat /etc/hostapd.conf /etc/dnsmasq.conf The access point comes up on the desired channel this time. But I can't connect because dnsmasq isn't running. It wants to bind to the WLAN's IP address but that isn't assigned. I'm not sure how a statically assigned IP address can't be assigned. Maybe I need another magic spell for that one as well. So for now, nothing except 5 Ghz works. That's not enough. Here are my current config files: /etc/network/interfaces.d/armbian.ap.nat #allow-hotplug wlx0013eff45e2e # dual-band adapter allow-hotplug wlx801f02e695a0 # 2.4 GHz adapter #iface wlx0013eff45e2e inet static iface wlx801f02e695a0 inet static address 10.0.0.1 netmask 255.255.255.0 network 10.0.0.0 broadcast 10.0.0.255 /etc/hostapd.conf ssid=ARMBIAN #interface=wlx0013eff45e2e # dual-band adapter interface=wlx801f02e695a0 # 2.4 GHz adapter hw_mode=g channel=5 #bridge=br0 driver=nl80211 logger_syslog=0 logger_syslog_level=0 wmm_enabled=1 wpa=2 preamble=1 #wpa_psk=34ed41c482f2bb8ffbbf589952245121ee70c666d1186ebefa51a86b17829990 wpa_passphrase=12345678 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 ## IEEE 802.11n ieee80211n=1 ht_capab=[HT40-][SHORT-GI-40][SHORT-GI-40][DSSS_CCK-40] country_code=DE ieee80211d=1 ## IEEE 802.11n ## IEEE 802.11a #hw_mode=a # disabled for the 2.4 GHz adapter ## IEEE 802.11a ## IEEE 802.11ac #ieee80211ac=1 # disabled for the 2.4 GHz adapter vht_capab=[MAX-MPDU-11454][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP3] vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=42 ## IEEE 802.11ac # controlling enabled ctrl_interface=/var/run/hostapd ctrl_interface_group=0 /etc/dnsmasq.conf #interface=wlx0013eff45e2e # dual-band adapter interface=wlx801f02e695a0 # 2.4 GHz adapter listen-address=10.0.0.1 bind-interfaces server=8.8.8.8 domain-needed bogus-priv dhcp-range=10.0.0.10,10.0.0.199,12h This is the output of ip a: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 (...) 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 12:42:35:f1:2d:fe brd ff:ff:ff:ff:ff:ff 4: wlx801f02e695a0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 80:1f:02:e6:95:a0 brd ff:ff:ff:ff:ff:ff eth0 is my wired network, wlan0 is the on-board WLAN I'm not using (no antenna attached). The other wlx... interfaces are the USB WLAN adapters. And this is my general system info: http://ix.io/3xLF What do I need to do to make this WLAN access point work with both adapters, and on any channel I want (supported by the hardware)?

I have found the solution. The bus number must be 1, not 0 as explained everywhere. This will create the device /dev/spidev1.0 instead of spidev0.0 and applications must be adapted. But with this modification I can access the SPI device. So here's the relevant overlay configuration in /boot/armbianEnv.txt: overlays=spi-spidev param_spidev_spi_bus=1 And the SPI interface can be used only under this path: /dev/spidev1.0 Who knows where that bus number 0 leads to...

I guess you mean the param_spidev_spi_bus parameter? Sorry, I've pasted the complete file in the other response that never made it to the forum. Here is the file /boot/armbianEnv.txt: verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=spi-spidev usbhost2 usbhost3 param_spidev_spi_bus=0 rootdev=UUID=4a65461e-d8ac-4d8f-94c0-05ecd12f6d58 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I used armbian-config to enable SPI and also read that I need to manually add this parameter to the file. That's where I am now. I followed the pinout from this image (and many others which look the same): I have now also verified that the pins work correctly as GPIO with the spi overlay disabled. So it's not a hardware failure. The software just isn't sending any SPI signal. SCLK, MOSI and CS0 remain low at all times when sending to SPI.

(Finally this forum lets me enter a new topic. It's failing most of the time, making it really hard to solve my actual problem if the infrastructure also fails.) I'm using an Orange Pi Zero board and try to make it talk to a radio module via SPI. The whole thing already works on a Raspberry Pi so the module and cabling is correct. But the module doesn't respond to requests on the Orange Pi. Since this doesn't do anything, I searched for issues like this and along the way found an SPI loopback tool. I tried it and it returned all zeros. The tool readme suggests that the MOSI and MISO pins are not connected, but they are. I checked and resoldered those pins and connected both with a jumper. The hardware is 100% correct. It must be the software that doesn't understand the SPI interface here. The same tool shows a correct echo on the RasPi. I also found another topic here about the Allwinnder H6 chip where a patch in Armbian was necessary to resolve the same issue. I couldn't respond there due to a permanent forum outage and then lost the link. So I believe that the same error is in the Orange Pi Zero image. I didn't understand what was changed there, something deep within the system. The armbianmonitor -u command failed with an internal server error response, so I uploaded the logs elsewhere. The Google form in front of this bug report recommended paste.debian.net but that service is unsuitable because its length limit of 150 kB is not sufficient.

Hello, I've bought a USB Bluetooth adaptor on Amazon and wanted to try it on my Armbian device, an Orange Pi Zero. The installed system is Armbian Focal (Ubuntu). That adaptor seems to have the Realtek rtl8761a chip, according to the error message in syslog. The firmware could not be found. It should be included in the "firmware-realtek" package but that doesn't exist. I couldn't find anything else that provides that firmware. That USB adaptor has an average rating, a second one I've also ordered has a better rating. Both have the same chip inside. Both don't work on a current Windows 10 because the unsigned driver from Realtek (to be downloaded from two different Chinese websites) crashes my computer (I really do mean crash, I had to unpower it). Both product descriptions only mention Windows compatibility, no Linux. But that doesn't say anything. So I thought I'd give them a last try on Linux before returning them. Does anybody know where that firmware can be found? If there's nothing available, what would be the recommended method to bring Bluetooth connectivity to a small Linux device? A different USB adaptor? A custom chip with an SPI interface? Nothing at all because Bluetooth doesn't work?

Hello, Today I found that the "serial-getty@ttyS0.service" service restarts every minute. It says "serial-getty@ttyS0.service: Succeeded." in the syslog/journal and then starts again, so it exited with code 0. The restart counter is already at 3085, so it's been like that for 2 days. No output is logged from the service itself. So I looked up its start command and ran it interactively. Again, with no output, after a minute, it returned with code 0. So I straced that thing and saw that it did lots of things, then print "Password:" somewhere, wait a while and then print "Login timed out after 60 second" and exit with code 0. strace /sbin/agetty -o '-p -- \u' --keep-baud 115200,38400,9600 ttyS0 linux >agetty.trace 2>&1 Looking further up the trace, it seems that it prints "login:" somewhere several times, and once it reads single characters as input, assembling to the string: "Armbian 20.05.2 Focal ttyS0 \r" It echos every single character, then proceeds to the password prompt. But no further input is read, so it gives up. Here's the full trace output: https://ygoe.de/s/JSCkKnW7Th90xghl I'm wondering where that ghost input comes from and who is sending this string, character per character, every time? There's a USB to serial adapter connected to the serial port, but GND is currently left open (or the adapter's LED would light from the TX line voltage) and the USB is not attached anywhere. And that certainly won't generate such a string. When I had last used that USB to serial adapter, I could log in with user name and password just fine. The device is an Orange Pi Zero with (I think) Armbian_20.05.2_Orangepizero_focal_current_5.4.43. Support log: http://ix.io/2wbG

Thank you for the suggestions. I first wanted to see what happens after that reboot. The issues has just gone away. I have not changed anything with the system or software, just rebooted when it was so busy. Since then, the load is constantly low and memory usage is also low. My own client app keeps happily sending its data to the server and the LED timer still works nicely. First a week with LAN connection, now a few days with WLAN only. So whatever it was, it didn't come back and a reboot solved it. Maybe I should set up a watchdog that reboots (not hard-resets, as long as possible) the system on unexpected high load or slow reaction speed.

Oh, I downloaded that image 2 weeks ago. Have to update again. Do I have to copy it to the SD card again or can I upgrade it from the system like 'apt upgrade'? I did the latter just this weekend when I set things up. Igor, you showed the load values. Doesn't that mean that the system is juggling many things in parallel, some of which could just be IO waits so no real CPU activity? The 'free' command said I have plenty of free memory and swap. I looked into top but couldn't see anything especially interesting there besides "kswapd0" taking much CPU time. I'll look again tomorrow. Had to restart the system because nothing worked anymore. At least I could issue a reboot command and didn't have to cut the power.

Here's the link: http://ix.io/2pT5

I've copied Armbian Ubuntu Focal onto a brand-new SD card and started it on an Orange Pi Zero. This has worked before with the Bionic version. After setting it up and upgrading all packages, I rebooted and everything was running smoothly. Now I've done the same as before but found that the system is totally slow after running for just one day. It's set up to collect data from a 1-Wire temperature sensor and send it to my server. And it lets the green LED blink twice every 30 seconds to show it's still there and has a network connection. The network is connected via Ethernet cable, WLAN is not used. Observation 1: It took half a minute to login the first time today. Manpages take a while to load and even the shell echo isn't instant (up to a few seconds behind). Observation 2: There's plenty of free memory (85 of 245 MB used), swap is like 45 of 120 used. 'top' shows that the process kswapd0 has by far the most CPU usage. Often it's between 5 and 30%, in total it's much more than any other process. Observation 3: The LED should blink twice with a delay of 1 second. It actually blinks once and maybe a second time sometime later. But definitely not within a second. It's a shell script that just calls 'sleep' to wait. So even 'sleep' doesn't return in time here. I've tried to use 'swapoff -a' but it doesn't change anything. It prints "Killed" and then swap still shows up in the output of 'free'. System diagnosis data was uploaded to: (waiting many minutes...) (still uploading... I'll provide the link as soon as it's done) What could be the cause of such misbehaviour? It's like it has aged decades in just one day, doing almost nothing. On a new board and new SD card. Very strange, I've never seen that before.

No, that card was in use in an Android phone for a few years. It was a light usage, not too much activity. But do you have more information about how Armbian treats SD cards better than Raspbian? The SSH bug is already known here: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/216847 PS: Why can I only post once a day? Am I considered a spam bot or so?

What does that mean? The file system is read/write. Meanwhile I have another suspect. After recreating the system, I never unplugged the power and let it run for a few days. Still, after a reboot, the filesystem was corrupt and remounted read-only. When I ran 'fsck' on it, it found and fixed hundreds of errors. I don't know whether it would ever complete. I unplugged the power while it was still running. Maybe the SD card isn't reliable anymore. I'm going to order new ones and try again. If they fail, too, the RAM or the entire device would be defective. I have a second device of that type I can then try. Regarding the same device mounted twice: Does that mean you can't tell why that's the case? I found it in the output of 'mount'. It just appears twice. No idea why. There are a dozen other mounts I also mostly don't know. Can't look up anything right now without a working SD card. But what is that /var/log.hdd anyway? I also had that impression, but found out my test was incomplete. I tried to connect via SSH but there's a bug in SSH/Debian for over 10 years: if there's no IP address at boot time, sshd will fail and never start again. The WLAN connection seems to take a minute or two to come up, though. My file system broke again before I could test a workaround for that.

Hello, I've copied the Armbian Bionic image onto an SD card (and verified it) and put it into my new Orange Pi Zero LTS 256 MB. I already have experience with Raspberry Pis and Raspbian for a few years, so this isn't entirely new to me. While I was trying to establish a stable network connection (wired and wireless), I misinterpreted some "host not reachable" as "network failed" when instead other issues existed. In the process, I unplugged the power a few times after the device has booted up but wasn't reachable via the network. Only then I connected the serial console and investigated further. There I found out that it wasn't actually booting anymore because it needed a manual filesystem check. When I ran that, a large number of errors was corrected. This was surprising because I thought ext4 fs journalling was active and should prevent such situations completely. It might still ask (not sure, but I haven't configured anything else yet), but it really shouldn't see dozens of errors. To be sure, I reflashed (and verified) the SD card to have a clean filesystem again. Now I'm trying to figure out why this could happen and how I can prevent it in the future. There are discussions on the web (including this forum) that explain the use of 'dumpe2fs' and 'tune2fs' and the options for the '/etc/fstab' file. But it doesn't make much sense in my case. According to 'dumpe2fs', the 'has_journal' flag is set and the journal should be active. 'tune2fs' cannot disable the journal because I cannot remount the root filesystem as read-only ("mount point is busy"). So I couldn't see what it looks like when the journal should be inactive. Then, I should be able to use the "data=journal" option in fstab to actually use the journal. But last time I did this, it couldn't mount the filesystem anymore and failed to boot. Correcting this from the outside is complicated (I have no other Linux box at hand) so I'd have to reflash the SD card again in this case. Can somebody please explain to me what the real situation with the ext4 journal is? Should it be used by default or do I have to opt into it? If it is active, then why could the filesystem become so corrupted by plugging out the power? If it's not active, and should prevent this corruption at all, then how should I proceed to enable it? Here's the output from 'armbianmonitor -u': http://ix.io/2o7w BTW, why is the same device mounted twice to '/' and '/var/log.hdd'? How can this be possible? And should I ignore the second mount point?