[Buildroot realtime image for nanopi neo]

I can try to get the AP6212 drivers working tonight. I don't know if I can get the EMMC to work, since that seems rather tricky. 

[To reduce the boot time]

The only way to get it to boot in under 2 seconds is to use a toolchain like Yocto or Buildroot. I can boot my nanopi neo (same CPU) in about 3 seconds using buildroot. There is a steep learning curve, though. 

[Buildroot realtime image for nanopi neo]

Yeah, I2S is a whole other beast with the H3. I know support exists on mainline, but I'm not adept enough at the DTS stuff for enabling I2S sound cards. I have an oscope I can check the signals with, but the tedium isn't something I'm interested in right now. The built in analog codec would be a simple task, as it already is known working on friendlyarm's mainline kernel, and its a matter of using diff to get the goods. 

 

Please ask any questions, buildroot is really cool. I'm using it for a synth, guitar pedal, and a tiny pxeboot image server. 

[Buildroot realtime image for nanopi neo]

I haven't needed the onboard audio to work, but I'll bet your answer lies in the device tree overlay stuff in linux/arch/arm/boot/dts, where you may need to check  the bindings in sunxi-h3-h5.dtsi and sun8i-h3-nanopi-neo.dts. You should create a patch that turns the status = "disabled"; line to status = "okay";

That might solve an issue with it enumerating correctly on boot. You may want to copy over an alsa config from a known working image, since that is might be an issue after the DTS stuff.

 

The USB storage means you should probably install udev and support for FAT and NTFS storage under the USB drivers in the make linux-menuconfig 

[Different take on armbian-config]

I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them.  Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo. 

 

The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going. 

 

I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place.  Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.

 

If anyone thinks this is cool (or that it sucks), let me know. Its still in development.

Here is a gif of it in action:

 

 

You can find the (in-progress) repo here: https://github.com/MitchRatquest/armbian-helper

[SmartGear multi-system emulator released as open-source]

Nice work! Do you have any videos of it in operation?

[Orange Pi Zero Plus as an ethernet gadget]

change your /etc/network/interfaces file to look like:

auto eth0
iface eth0 inet static
    address 192.168.100.1
    netmask 255.255.255.0

 

and type

sudo ifdown eth0 && ifup eth0

 

With that you should be able to ssh into the device using ssh USER@192.168.100.1

[Orange PI Zero + 4 USB-audio recording crackling]

This is very weird. I would not expect this behaviour. The only suggestions I can think of are: try the mainline linux version, try a real time kernel, or try some different usb audio recorders.  Maybe a USB device with stereo mic in, so you'd only need 2 of them? I have used these before: https://www.ebay.com/itm/361502397040 and they work without any special drivers. I'm using alsa and the throughput is fine. 

 

The real problem here is that it should work. I'm sort of confused about it. I think the mainline kernel is your best option, followed by a realtime mainline kernel.  I'm sorry I couldn't be of more help. 

[Orange PI Zero + 4 USB-audio recording crackling]

Interesting. Can you `cat /proc/interrupts` when recording with 3 cards vs 4? Which kernel are you using (output of `uname -a`)? Can your SD card write the files that quickly?

[Has anybody a good latency after the RT-PREEMPT patch?]

Great job! What CNC software are you running, and which CNC are you using? It looks nice and compact. Love that little PSU. 

[Has anybody a good latency after the RT-PREEMPT patch?]

Hey @MX_Master, reporting in with some more numbers with the 4.13 RT stuff. 

 

# uname -a
Linux nanopi-neo 4.13.11-rt3 #2 SMP PREEMPT RT Thu Nov 30 11:17:18 CST 2017 armv7l GNU/Linux

# cyclictest -a -t -n -p80 
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.11 0.10 0.03 1/94 920          

T: 0 (  915) P:80 I:1000 C: 238476 Min:      6 Act:    9 Avg:    9 Max:      38
T: 1 (  916) P:80 I:1500 C: 158983 Min:      5 Act:    9 Avg:    9 Max:      27
T: 2 (  917) P:80 I:2000 C: 119238 Min:      8 Act:    9 Avg:    8 Max:      17
T: 3 (  918) P:80 I:2500 C:  95390 Min:      7 Act:    9 Avg:    9 Max:      16

 

[Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiver]

No H3 board I've seen has broken out the connections for line in. I'd really love that simple addition to any board, but it hasn't happened yet. 

[Orange PI One OTG HID]

If you are using the mainline kernel, you can use configfs for setting up USB HID. Try this example:

    modprobe libcomposite
    mount -t configfs none /sys/kernel/config
    cd /sys/kernel/config/usb_gadget
    mkdir g1
    cd g1
    mkdir configs/c.1
    mkdir functions/hid.usb0
    echo 1 > functions/hid.usb0/protocol
    echo 1 > functions/hid.usb0/subclass
    echo 8 > functions/hid.usb0/report_length
    cat my_report_desc > functions/hid.usb0/report_desc
    mkdir strings/0x409
    mkdir configs/c.1/strings/0x409
    echo 0xa4ac > idProduct
    echo 0x0525 > idVendor
    echo serial > strings/0x409/serialnumber
    echo manufacturer > strings/0x409/manufacturer
    echo HID Gadget > strings/0x409/product
    echo "Conf 1" > configs/c.1/strings/0x409/configuration
    echo 120 > configs/c.1/MaxPower
    ln -s functions/hid.usb0 configs/c.1
    ls /sys/class/udc > UDC

 

Which I got from my own working USB OTG ethernet + midi + file storage script and this example here. Note that they create a file called "my_report_desc" for HID specific stuff. 

[Samba Setup]

Need to see your smb.conf file to help you on this.  Its most likely a permission problem, like allowing guests to see the samba share. 

[How would one create a DPI LCD interface?]

This isn't a feature with the H2/H3 device trees because those CPUs don't have a DPI interface. You could try to use notro's fbtft library using the parallel option to drive your display, but I don't think he has support for RGB24. 

[Has anybody a good latency after the RT-PREEMPT patch?]

Cool, I didn't know RT patches for 4.13 were out already! Thats great news, I should bump up my version. Are you building your kernel using the armbian toolset or your own?

 

Another point is that mine is specifically for the nanopi neo, which doesn't involve any HDMI setup or clocking. I'm not sure if that affects the results of cyclictest, but it might, as the HDMI subsystem must involve interrupts to the kernel. Armbian also ships with irqutils, which balances the irqs over the 4 cores (or 3, as you have one isolated). I have no idea if that matters either. 

 

I'm using my stuff for audio, and having the full RT kernel helps with audio dropouts on my USB device. Using alsa (no jack) I can get it down to ~10ms round trip. Without RT it was more like ~30ms. I've found the best test of any RT system is how it responds with your application.

[Has anybody a good latency after the RT-PREEMPT patch?]

Sure thing! Here are my results:

# cyclictest -p 80 -t5 -n -a
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.12 0.17 0.08 1/93 193          
T: 0 (  186) P:80 I:1000 C: 551057 Min:      5 Act:    8 Avg:    8 Max:      29
T: 1 (  187) P:80 I:1500 C: 367371 Min:      5 Act:    8 Avg:    7 Max:      44
T: 2 (  188) P:80 I:2000 C: 275529 Min:      7 Act:    8 Avg:    7 Max:      13
T: 3 (  189) P:80 I:2500 C: 220423 Min:      7 Act:    8 Avg:    7 Max:      11
T: 4 (  190) P:80 I:3000 C: 183685 Min:      5 Act:    8 Avg:    7 Max:      24

I have isolcpus=2,3 running, and I'm running a mainline 4.11 kernel with the rt patch, as well as an ethernet patch and usb otg patch. It is also a buildroot environment, so I'm not sure how much that is skewing these results in my favor. 

# uname -a
Linux nanopi-neo 4.11.9-rt7 #1 SMP PREEMPT RT Fri Sep 22 10:38:22 CDT 2017 armv7l GNU/Linux

 

[Has anybody a good latency after the RT-PREEMPT patch?]

You can find discussion about this in another post on this forum: 

 

I find you don't get great latency in the legacy kernel, whereas my post with the mainline kernel has a max latency of 42 us. 

 

[How to change OTG mode from serial to HID keyboard on the Orange pi zero?]

Looks like g_hid is broken on this build of armbian. Not sure why this hasn't been patched yet. 

[How to change OTG mode from serial to HID keyboard on the Orange pi zero?]

Sorry, put sudo before those commands and run them again. It must be run as root. I'll try with a legacy stable image tonight and see if I can get it operational.

[How to change OTG mode from serial to HID keyboard on the Orange pi zero?]

Which kernel are you using? If you are using mainline, I understand than the OTG options aren't there yet.

 

If on legacy, you can try: modprobe -r g_serial

followed by: modprobe g_hid

 

From there, see if any new devices are created.  Full documentation is here: https://www.kernel.org/doc/Documentation/usb/gadget_hid.txt

[Testers wanted Real Time Kernel image builds for H3 boards]

If you want the cyclictest results from a mainline kernel, here are mine:

 

Linux nanopi-neo 4.11.9-rt7 #2 SMP PREEMPT RT Mon Aug 7 21:41:13 CDT 2017 armv7l GNU/Linux

 

# cyclictest -p 80 -t5 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.05 0.05 0.01 1/96 220          

T: 0 (  208) P:80 I:1000 C: 572399 Min:      5 Act:    6 Avg:    8 Max:      42
T: 1 (  209) P:80 I:1500 C: 381600 Min:      6 Act:    9 Avg:    8 Max:      34
T: 2 (  210) P:80 I:2000 C: 286200 Min:      5 Act:    9 Avg:    7 Max:      25
T: 3 (  211) P:80 I:2500 C: 228960 Min:      6 Act:    9 Avg:    8 Max:      29
T: 4 (  212) P:80 I:3000 C: 190800 Min:      5 Act:   11 Avg:    8 Max:      30
 

[Testers wanted Real Time Kernel image builds for H3 boards]

You can find a 4.11.9 rt patch here: https://www.kernel.org/pub/linux/kernel/projects/rt/4.11/older/

 

I have a vanilla mainline kernel with that patch applied and it works for me. I think armbian uses a separate github directory, so you might need to tweak the patch. 

[Buildroot realtime image for nanopi neo]

It looks like your patches applied correctly, comparing your images to my make menuconfig shows its the same. I'm not sure why you're not getting ethernet. Once your board boots up, if you type "ifup eth0" it should come up. Also check the /etc/network/interfaces file to make sure eth0 is define, like this:

 

auto eth0

iface eth0 inet dhcp

       wait-delay 15

 

I tested my mainline image on an orangepi zero and it booted right away with ethernet, so I'm not sure what is wrong. If you change out your SD card and power supply or USB cable you may have luck.

 

 

[Replicating an existing release?]

There is a way to roll back changes, and its almost straightforward. I successfully did it by manually going back through the git commits in armbian/build until I found the date that matched the uname output, and cloned it from that point. Then you have to add an empty file on the same directory as compile.sh with: touch .ignore_changes 

From there, you have to change how it grabs the sources, and make sure that repo is from the same date. Here is the build repo commit for Feb 2: https://github.com/armbian/build/tree/813cfaa16cb3164acb3f8feade5f269a218121c9

And here is the linux repo from January 20th: https://github.com/armbian/linux/tree/e0a8ecfd409ffb14fe382804fdc180e6c52413e0

 

From there you have to dig around in armbian/build and change which git repo it clones, and don't allow cleaning the directory before it compiles. With enough perseverance you should be able to get it to work.