Lope got a reaction from guidol in [SOLVED] Orange Pi Zero analog audio not working (using expansion board)
Hi @guidol Thank you
I just did some more searching and found your very useful forum posts about audio issues you had with orange pi zero
I did try making /etc/asound.conf as per examples on the orange pi forums, which didn't help.
I'm going to see if I've got all the modules loaded.
I've edited my first post with more commands and outputs.
sun4i_codec sun8i_codec_analog to /etc/modules
$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0  Subdevices: 1/1 Subdevice #0: subdevice #0 YES!!! IT WORKS. IT WORKS!!!
It's ALIVE!!!!! (demented laughter)
Wow! I'm impressed with the sound quality!!!
Lope got a reaction from lomady in Change default Kernel options: TC (traffic control (shaping)) options available as modules/enabled
These boards are well suited to routing/network traffic control functionality.
Currently the kernel has been compiled with Traffic Control stuff disabled, which makes it impossible to perform traffic shaping on stock Armbian kernel.
I'm busy recompiling the kernel as a temporary solution, but I will really appreciate it if the kernel build maintainer can please change the traffic control options from DISABLED to MODULE (at least)?
I have a bunch of Armbian boards but I'm testing with NanoPi Neo 2 right now.
I'll let you know the size of the modules once I've finished compiling.
Lope got a reaction from jscax in Orange Pi Zero with Gigabit Ethernet for $10?
I think Xunlong should be able to make a Orange Pi Zero with 512MB RAM and Gigabit ethernet for around $10. If they did, would you buy it? Do you think it would be a good product?
The H2/H3/H5 is capable of gigabit ethernet, they just need an external ethernet chip that costs about $1.
If you think about it. To go from an Orange Pi PC which has 1GB RAM @ $15, to an Orange Pi 2E with 2GB RAM $35, thats more than double the cost to double the RAM.
But if you go from an Orange Pi Zero with 100Mbit ethernet at $9 to 1000Mbit ethernet at $10, that's only a 0.1X increase in cost for a 10X increase in performance. That means you get about 10.5x more value for money (performance) by upgrading the ethernet vs upgrading the RAM.
For many years Raspberry Pi (and alternatives) fans have wanted a low cost SBC with good IO capabilities. RaspberryPi has never delivered.
Now Xunlong have come and provided us the Orange Pi 2E (thanks to Tkaiser's suggestion), it's got gigabit ethernet, lots of RAM and 4 real USB ports. It's great.
But now if you want a cheap SBC with powerful IO, currently the only option is FriendlyArm NanoPi Neo2. But that board costs much more than necessary at $15 (if you just want IO) because it uses the H5 chip.
One application is a router. Routers need a lot of IO, but not that much RAM usually. But it depends. Some routers deal with massive IPsets and do deep packet inspection VPN, VoIP and all kinds of stuff.
So let's see who else thinks a Orange Pi Zero with 512MB RAM and Gigabit ethernet would be a good idea?
Also another suggestion is I've seen comments that the H2 supports about 130 GPIO's. But there are only a few of them exposed on the 40 PIN RbPi style GPIO header.
The new Orange Pi Zero can expose all the GPIO without much extra size as 0.1" spaced holes on the PCB, without increasing the cost much.
That's another very cheap way to increase the IO capabilities and make this product really competitive with other options for people who need IO.
To keep everyone happy, if the additional GPIO are placed at the end of the PCB, the few modders who care about a few mm of space and want a really tiny PCB can just cut the end off (at their own risk)
I edited the questions so my answers got a bit messed up, but I won't edit the questions again.
Lope got a reaction from guidol in [EDIT] Neo2 only 2 USB ports working (female A and "USB2" pin header)
overlays=usbhost0 usbhost2 usbhost3
to /boot/armbianEnv.txt so it looks like this
verbosity=1 console=both overlay_prefix=sun50i-h5 rootdev=UUID=c9cfe2c8-bfa6-421a-badc-4e58e9288de2 rootfstype=ext4 overlays=usbhost0 usbhost2 usbhost3 And uboot showed
U-boot loaded from SD Boot script loaded from mmc 152 bytes read in 151 ms (1000 Bytes/s) 24232 bytes read in 354 ms (66.4 KiB/s) 385 bytes read in 407 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost0.dtbo 385 bytes read in 399 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 385 bytes read in 390 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost3.dtbo 4179 bytes read in 369 ms (10.7 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 5001817 bytes read in 440 ms (10.8 MiB/s) 12285960 bytes read in 869 ms (13.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... And now when I plugin USB devices into the female USB A cables I've soldered to the PCB as per
to the port labelled "USB1" I get nothing, but for the port labelled "USB2" I get
[ 156.201286] usb 5-1: device descriptor read/64, error -62 [ 156.497302] usb 5-1: device descriptor read/64, error -62 [ 156.973314] usb 5-1: device descriptor read/64, error -62 [ 157.269327] usb 5-1: device descriptor read/64, error -62 [ 157.977369] usb 5-1: device not accepting address 20, error -62 [ 158.577391] usb 5-1: device not accepting address 21, error -62 [ 158.583375] usb usb5-port1: unable to enumerate USB device So at least there are signs of life for one USB port.
I'm going to check my solder joints again.
microUSB port didn't work
When powering the NanoPi2 via the UART 5v line from USB (it was a bit underpowered, voltage sagged down to 4.64)
I plugged a (tested working) USB OTG cable into the microUSB and nothing I connected showed up in dmesg.
(for all other tests, the board was powered with 2A microUSB)
The "USB1" (as shown in the pinout diagram) headers were unresponsive in all cases.
How to know that your D+ and D- are backwards
I noticed my soldering had left a bit of flux behind on the board, after scratching it off I got a different error in dmesg
[ 115.875561] usb 5-1: new low-speed USB device number 2 using ohci-platform [ 116.059563] usb 5-1: device descriptor read/64, error -62 [ 116.355565] usb 5-1: device descriptor read/64, error -62 [ 116.647578] usb 5-1: new low-speed USB device number 3 using ohci-platform [ 116.831581] usb 5-1: device descriptor read/64, error -62 [ 117.127593] usb 5-1: device descriptor read/64, error -62 [ 117.419605] usb 5-1: new low-speed USB device number 4 using ohci-platform [ 117.835618] usb 5-1: device not accepting address 4, error -62 [ 118.019628] usb 5-1: new low-speed USB device number 5 using ohci-platform [ 118.435638] usb 5-1: device not accepting address 5, error -62 [ 118.441516] usb usb5-port1: unable to enumerate USB device Then I swapped D+ and D- and the "USB2" port worked!
Having 2 working USB ports is enough progress for me, for now. I'm going to leave this issue as is for now.
BTW I also found that with a 5 meter USB extension cable and a hub on the end of it, I couldn't connect 2 wifi adapters to the female USB A port. But if I connect the hub directly to the port I can connect 2 wifi adapters.
Lope reacted to tkaiser in Quick review of Orange Pi One
The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown.
Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One
The most important differences between One and PC as follows:
Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180Â° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store.
So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer.
The Orange Pi PC fits exactly:
And that's how it looks with the One:
You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180Â° rotation).
Different voltage regulator and the consequences:
Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity.
Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC.
On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board).
Fex/script.bin fixes necessary when using OS images for PC:
When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this:
[ARISC ERROR] :message process error [ARISC ERROR] :message addr : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr : 2 [ARISC ERROR] :message type : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings
At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment.
So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values.
How does voltage switching works on the One?
So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state:
pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same:
pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use
pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read:
pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important.
Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues.
Final chapter: Software support for the Orange Pi One:
First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too.
In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!)
Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One)
It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time.
And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress
Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working.
EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress.
Lope reacted to tkaiser in H3 board buyer's guide
Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
Mainline kernel: The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far. In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public) BSP kernel: So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices). Allwinner's 1st BSP kernel variant: Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards) Loboris' kernel: The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking. Yann Dirrson's fork: When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis. 1st Armbian legacy kernel: Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings) Alwinner's 2nd BSP kernel variant: When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes. 2nd Armbian legacy kernel: So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot. Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes) The SinoVoip experience: While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board. Further improvements: In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards) Summary: Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)