jgauthier

Good news! I'm dumb! iperf defaults to a 1M transfer rate over UDP. Easily changed with -b option.

Hello, I am using a NanoPi Duo2 with Armbian 22.11 and Kernel 5,15,80. This device uses an AP6216 wireless interface, which I have noticed are pretty common on sunxi based boards. I ran some bandwidth tests and had pretty poor results: [ ID] Interval Transfer Bandwidth [ 3] 0.0000-1.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 1.0000-2.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 2.0000-3.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 3.0000-4.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 4.0000-5.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 5.0000-6.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 6.0000-7.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 7.0000-8.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 8.0000-9.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 9.0000-10.0000 sec 129 KBytes 1.05 Mbits/sec Not sure if the issue was the driver, hardware, or otherwise I connected a USB wifi dongle and disabled the AP6216. I've tested with the same results again: [ ID] Interval Transfer Bandwidth [ 3] 0.0000-1.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 1.0000-2.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 2.0000-3.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 3.0000-4.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 4.0000-5.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 5.0000-6.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 6.0000-7.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 7.0000-8.0000 sec 127 KBytes 1.04 Mbits/sec [ 3] 8.0000-9.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 9.0000-10.0000 sec 129 KBytes 1.05 Mbits/sec [ 3] 0.0000-10.0191 sec 1.25 MBytes 1.05 Mbits/sec It's my suspicion that the issue is now elsewhere - but where? I have no idea. Thanks for any ideas.

So, some time ago I made some custom changes to DTB to get the OV5640 camera working on a Banana Pi M2 Zero. I was successful, and made notes on the files that I changed. Now, I'm working with the same source tree, but cleaned out. So I wanted to make my changes again because I did not know about CREATE_PATCHES then. So, i built my new image, and made the changes to the dts files. But now, /dev/media0 does not show up. I have 2 boards. One with my prior image that is fully functioning (Board A), a new one that is missing /dev/media0 (Board B). First thing I did was compare the kernel configs. They are identical. For fun, I copied the kernel from A to B. That did not resolve the missing /dev/media0 from B. Then, I copied the board specific DTB file over from A to B. (sun8i-h2-plus-bananapi-m2-zero.dtb). Upon rebooting Board B, /dev/media0 shows up. Ah Ha. So, there is some change I made on the original build that does not show up in the new build. So, I reversed the DTB on both boards to DTS files and compared them. Sadly, the changes are minimal. Most of the difference are dynamic addresses defined during the build. I'm just really not sure what else could be going on here. If anyone has any experience, I would really appreciate it. I attached the 2 DTS files, and diff output is just this: diff sun8i-h2-plus-bananapi-m2-zero.dts sun8i-h2-plus-bananapi-m2-zero.dts.good 241d240 < broken-cd; 248c247 < cd-gpios = < 0x0c 0x05 0x06 0x00 >; --- > broken-cd; 255c254 < pinctrl-0 = < 0x0d >; --- > pinctrl-0 = < 0x0c >; 267c266 < mmc-pwrseq = < 0x0e >; --- > mmc-pwrseq = < 0x0d >; 275c274 < interrupt-parent = < 0x0c >; --- > interrupt-parent = < 0x0e >; 453c452 < phandle = < 0x0c >; --- > phandle = < 0x0e >; 518c517 < phandle = < 0x0d >; --- > phandle = < 0x0c >; 818,820c817,819 < device-wakeup-gpios = < 0x0c 0x06 0x0d 0x00 >; < host-wakeup-gpios = < 0x0c 0x06 0x0b 0x00 >; < shutdown-gpios = < 0x0c 0x06 0x0c 0x00 >; --- > device-wakeup-gpios = < 0x0e 0x06 0x0d 0x00 >; > host-wakeup-gpios = < 0x0e 0x06 0x0b 0x00 >; > shutdown-gpios = < 0x0e 0x06 0x0c 0x00 >; 903,904c902,903 < reset-gpios = < 0x0c 0x04 0x0e 0x01 >; < powerdown-gpios = < 0x0c 0x04 0x0f 0x00 >; --- > reset-gpios = < 0x0e 0x04 0x0e 0x01 >; > powerdown-gpios = < 0x0e 0x04 0x0f 0x00 >; 1305c1304 < gpio = < 0x0c 0x01 0x08 0x00 >; --- > gpio = < 0x0e 0x01 0x08 0x00 >; 1316c1315 < gpio = < 0x0c 0x01 0x09 0x00 >; --- > gpio = < 0x0e 0x01 0x09 0x00 >; 1328c1327 < gpio = < 0x0c 0x07 0x06 0x00 >; --- > gpio = < 0x0e 0x07 0x06 0x00 >; 1340c1339 < gpio = < 0x0c 0x07 0x03 0x00 >; --- > gpio = < 0x0e 0x07 0x03 0x00 >; 1402c1401 < reset-gpios = < 0x0c 0x06 0x0c 0x00 >; --- > reset-gpios = < 0x0e 0x06 0x0c 0x00 >; 1441c1440 < phandle = < 0x0e >; --- > phandle = < 0x0d >; 1449c1448 < gpio = < 0x0c 0x00 0x08 0x00 >; --- > gpio = < 0x0e 0x03 0x0e 0x00 >; 1461c1460 < gpio = < 0x0c 0x00 0x08 0x00 >; --- > gpio = < 0x0e 0x03 0x0e 0x00 >; 1473c1472 < gpio = < 0x0c 0x00 0x07 0x00 >; --- > gpio = < 0x0e 0x00 0x07 0x00 >; Each of these address is referenced in the file, like this: reset-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */ So I've reached the conclusion that it's most likely dynamically creating the address that it points to (&pio) at build time. The only other real difference is is cd-gpios = < 0x0c 0x05 0x06 0x00 >; This exists only on my good image, and it's attached to the MMC device for card detection. sun8i-h2-plus-bananapi-m2-zero.dts.good sun8i-h2-plus-bananapi-m2-zero.dts

Hm. Okay, Thanks. I guess it makes sense

I must have some conflicting options, or my understanding of what these options do is wrong. Can someone help? I did a complete image build. Now, I just want to rebuild the kernel. ./compile.sh CLEAN_LEVEL="make" CREATE_PATCHES="yes" BOARD="bananapim2zero" BRANCH="legacy" RELEASE="buster" KERNEL_ONLY="yes" KERNEL_CONFIGURE="no" As I read the documentation, "make" in CLEAN_LEVEL indicates it will "make clean" in the uboot and linux sources. KERNEL_ONLY="yes" will rebuild only the kernel. [ o.k. ] Using config file [ /home/jgauthier/armbian54/build/userpatches/config-example.conf ] [ o.k. ] Command line: setting CLEAN_LEVEL to [ make ] [ o.k. ] Command line: setting CREATE_PATCHES to [ yes ] [ o.k. ] Command line: setting BOARD to [ bananapim2zero ] [ o.k. ] Command line: setting BRANCH to [ legacy ] [ o.k. ] Command line: setting RELEASE to [ buster ] [ o.k. ] Command line: setting KERNEL_ONLY to [ yes ] [ o.k. ] Command line: setting KERNEL_CONFIGURE to [ no ] [ o.k. ] Preparing [ host ] [ o.k. ] Build host OS release [ focal ] [ o.k. ] Syncing clock [ host ] [ o.k. ] Checking for external GCC compilers [ o.k. ] Downloading sources [ o.k. ] Checking git sources [ u-boot v2020.04 ] [ .... ] Up to date [ o.k. ] Checking git sources [ linux-mainline orange-pi-5.4 ] [ .... ] Up to date [ o.k. ] Checking git sources [ sunxi-tools master ] [ .... ] Up to date [ o.k. ] Checking git sources [ rkbin-tools master ] [ .... ] Up to date [ o.k. ] Checking git sources [ marvell-tools A3700_utils-armada-18.12 ] [ .... ] Up to date [ o.k. ] Checking git sources [ marvell-ddr mv_ddr-armada-18.12 ] [ .... ] Up to date [ o.k. ] Checking git sources [ marvell-binaries binaries-marvell-armada-18.12 ] [ .... ] Up to date [ o.k. ] Checking git sources [ odroidc2-blobs master ] [ .... ] Up to date [ o.k. ] Checking git sources [ testing-reports master ] [ .... ] Up to date [ o.k. ] Checking git sources [ amlogic-boot-fip master ] warning: redirecting to https://gitlab.com/superna9999/amlogic-boot-fip.git/ [ .... ] Up to date [ o.k. ] Kernel build done [ @host ] [ o.k. ] Target directory [ /home/jgauthier/armbian54/build/output/debs/ ] [ o.k. ] File name [ linux-image-legacy-sunxi_20.08.0-trunk_armhf.deb ] [ o.k. ] Runtime [ 0 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=bananapim2zero BRANCH=legacy RELEASE=buster KERNEL_ONLY=yes KERNEL_CONFIGURE=no ] Thank you,

Thanks. In the few times I tried to run armbianmonitor -u, it would not return an url. It did this time though. http://ix.io/2ADz I'll check those patches. With my limited understanding of what creates /dev/media0. I wonder if something I've done in the DTB definition has caused it's lack of creation.

Greetings, Some time ago, I built armbian with kernel 5.4.51. I applied a patch to two dts files that allowed for the OV5640 camera to work. By "work", I mean /dev/video0 was present in the system and /dev/media0 was also present. I could set camera parameters with media-ctl pointing to /dev/media0. Now, I've updated, and using a legacy kernel, 5.4.65, I cannot reproduce this. I've applied the same dts changes, but upon booting this image /dev/media0 is missing. I've compared the two kernel configurations, and there are very minimal differences: # diff config-5.4.51-sunxi /boot/config-5.4.65-sunxi 3c3 < # Linux/arm 5.4.51 Kernel Configuration --- > # Linux/arm 5.4.65 Kernel Configuration 2116d2115 < # CONFIG_BLK_DEV_SR_VENDOR is not set 2644a2644 > # CONFIG_RTL8192EU is not set 3165a3166 > CONFIG_SPI_DYNAMIC=y likewise, comparing loaded modules shows me that on my 5.4.65 build ov5640 is not in use: Module Size Used by ov5640 28672 0 On my 5.4.51 build, it is in use. I'm not sure where to go from here.

Yup, you are correct. I am removing it in my next build.

@martinayotte You're correct. reg_vcc_af_csi: vcc-af-csi { compatible = "regulator-fixed"; regulator-name = "vcc-af-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 7 GPIO_ACTIVE_HIGH>; /* PA7 */ enable-active-high; regulator-boot-on; regulator-always-on; }; PA7 is assigned as HIGH, to the CSI connector. My issue is that due to forgetting about this, I've pulled PA7 out for another custom use. That was very bad. PA7 will have to be reassigned for my custom use. While this did not go where I thought, you helped me look at stuff and figure out my problem. I set this CSI connector up months ago and completely forgot about it. Thank you!

Yes, it's an armbian build, I built it myself. I've built a DTS package to enable the CSI camera. Unfortunately, I do not have access to that DTS configuration to look at it right now and confirm what pin it's using. I'll have to look it up later and post it. Thanks!

Here's what I got: gpiochip0: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-1 ( |sysfs ) in hi IRQ gpio-7 ( |vcc-af-csi ) out lo gpio-110 ( |vdd-1v5-csi ) out hi gpio-203 ( |host-wakeup ) in lo gpio-204 ( |shutdown ) out hi gpio-205 ( |device-wakeup ) out higpiochip1: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-353 ( |vdd-cpux ) out lo gpio-355 ( |power ) in hi IRQ ACTIVE LOW gpio-358 ( |usb0_id_det ) in hi IRQ gpio-359 ( |reset ) out hi ACTIVE LOW gpio-362 ( |bananapi-m2-zero:red) out lo Thanks, I hope this means more to you than it does to me ;)

@martinayotte Well, I think it's more complicated than that. I'm using the WiringPI from here for the BPI series here: https://github.com/BPI-SINOVOIP/BPI-WiringPi2/tree/master/wiringPi in wiringPi/wiringPi_bpi.c it looks for /var/lib/bananapi/board.sh In there I have this entry: BOARD=bpi-m2z That said, sysfs doesn't work. echo 7 > /sys/class/gpio/export -bash: echo: write error: Device or resource busy I can access the GPIO pins with the gpio utility using the physical pin: gpio toggle 21 I don't believe (but I also don't know) that the DTS uses the wiringpi interface. It seems much lower level than that. So, I would think in the DTS file I can access it by gpio 7, which is the BCM ID. PA7, specifically.

Wow, I neglected to mention it's a banana pi m2z. I can check on the build of gpio, but that doesn't change my attempt with the dts config does it?

Hello, I have a GPIO pin that is high when starting the board. I am trying to force it low. Taking a look at gpio readall +-----+-----+---------+------+---+---Pi ?---+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 12 | 8 | SDA.1 | ALT5 | 0 | 3 || 4 | | | 5v | | | | 11 | 9 | SCL.1 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 6 | 7 | GPIO. 7 | ALT3 | 0 | 7 || 8 | 0 | ALT3 | TxD | 15 | 13 | | | | 0v | | | 9 || 10 | 0 | ALT3 | RxD | 16 | 14 | | 1 | 0 | GPIO. 0 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO. 1 | 1 | 16 | | 0 | 2 | GPIO. 2 | ALT3 | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | GPIO. 3 | ALT3 | 0 | 15 || 16 | 0 | ALT3 | GPIO. 4 | 4 | 15 | | | | 3.3v | | | 17 || 18 | 0 | ALT3 | GPIO. 5 | 5 | 68 | | 64 | 12 | MOSI | ALT3 | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | MISO | ALT3 | 0 | 21 || 22 | 0 | ALT3 | GPIO. 6 | 6 | 2 | | 66 | 14 | SCLK | ALT3 | 0 | 23 || 24 | 0 | ALT3 | CE0 | 10 | 67 | | | | 0v | | | 25 || 26 | 0 | ALT3 | CE1 | 11 | 71 | | 19 | 30 | SDA.0 | ALT3 | 0 | 27 || 28 | 0 | ALT3 | SCL.0 | 31 | 18 | | 7 | 21 | GPIO.21 | OUT | 1 | 29 || 30 | | | 0v | | | | 8 | 22 | GPIO.22 | ALT3 | 0 | 31 || 32 | 0 | ALT3 | GPIO.26 | 26 | 354 | | 9 | 23 | GPIO.23 | ALT3 | 0 | 33 || 34 | | | 0v | | | | 10 | 24 | GPIO.24 | ALT3 | 0 | 35 || 36 | 0 | ALT3 | GPIO.27 | 27 | 356 | | 17 | 25 | GPIO.25 | ALT3 | 0 | 37 || 38 | 0 | ALT3 | GPIO.28 | 28 | 21 | | | | 0v | | | 39 || 40 | 0 | ALT3 | GPIO.29 | 29 | 20 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+---Pi ?---+---+------+---------+-----+-----+ it can be seen the following line is active: +-----+-----+---------+------+---+---Pi ?---+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | 7 | 21 | GPIO.21 | OUT | 1 | 29 || 30 | | | 0v | | | I've tried to force it off, but doesn't seem to work: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { poweroff_pins:poweroff_pins { allwinner,pins = "PA7"; allwinner,function = "gpio_out"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { poweroff: poweroff { compatible = "gpio-poweroff"; gpios = <&pio 0 7 1>; }; }; }; }; Is this the wrong approach? Thanks!

CREATE_PATCHES worked great. I wish I hadn't missed that before, but it will streamline this for future builds!

Well, I took the original source code, from the linux kernel tree. I modified it, and then created the diff. That did not work, so I built armbian, and let all the patches do their things. Then I took the fully patched file (from the build) made my chanbges, and created a diff. I put that diff in userpatches. I was able to get this to work by forcing it to patch last, by prefixing the file name with 'zzz'. I wasn't aware of CREATE_PATCHES, but that is great. I will try that

Greetings, I'm attempting to apply a custom patch during the build process for a bananapi-m2-zero. (specifically, DTS changes) I went into the kernel source, and created a diff, and put it in the user customized patches directory. Unfortunately, the patch failed. So, I dug into it, and discovered the source changes because of patches in the armbian patches/ directory. So, instead I started the build, let these patches apply,, and aborted the build. Then I created the diff again. Sadly, the patch is still being rejected. Now, I might be able to fight with this, and make it work. But the next time I pull a new update it could be broken and I have to go through this again. So, is there any way I can make this work?

Sorry about that. I actually loaded the module before I posted. Since it didn't resolve anything I assumed that it didn't make a difference so I didn't mention it. Linux armbianbuild 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux lsmod|fgrep binfmt binfmt_misc 24576 1 Then I mounted the raw image on /mnt # chroot /mnt # sudo ls qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped)

It's not all executables, just specific ones. It's reproducible by putting a "bash" in your customization script and then running at least: sudo git There may be others. It can also be tested by mounting an existing disk image (say /mnt) then chroot'ing to /mnt. The OS automatically runs /usr/bin/qemu-arm-static /bin/bash -i when the chroot is executed. Then it's like being in the build environment. # sudo ls qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) So it's not the build environment at all, but an issue with qemu. I'm just surprised no one has seen this much. But maybe people aren't trying to highly customize and mass produce armbian images.

I built a quick Focal system on VirtualBox and ran into the same issue. So, I realized it's not the qemu host that I was using previously, but the qemu instance running on the build environment. /usr/bin/qemu-arm-static /bin/bash /tmp/customize-image.sh buster sunxi bananapim2zero no I'm not sure this is an easily solvable problem.

I'm using QEMU as my host VM platform and run several VMs in it for my own use. One of those is an Ubuntu VM intended for building armbian. I'm going to edit my post for clarification on that.

Is anyone else running their build environment in a VM? Specifically hosted by QEMU? I'm running into some strange things, and wondering if anyone has seen it. I'm running an Ubuntu (20.04) in a VM using QEMU as the hypervisor. Basically, the build generally works fine. However, as I add more features/processes to the customization script, I am starting to see segmentation faults. I see this with sudo and when I try to git pull something. This is what I get: qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) I got here by dumping into a bash script from 'customize-image.sh', so it's an arm-based chroot environment. I can work around some things, by doing them on the board. and them moving over the directories (or whatever), but I can't always do that. Interested if anyone else is doing this with this system platform. QEMU emulator version 4.2.0 (qemu-4.2.0-7.fc32) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

I tried this (and gpio line to bitbang i2c) on my banana pi m2 zero and had no luck.

Ok, it was an understanding issue. Thank you!

Keep in mind, that I don't know very much about DTS. As my Linux experience is specific to PC hardware and Raspberry Pis. That said, my terminology/understanding my not be accurate. When the kernel (or uboot?) portion of the build takes place a DTS file is chosen. This appears to be sun8i-h3-orangepi-zero-plus2.dt from the compile logs. I would have suspected it to be sun8i-h2-plus-bananapi-m2-zero.dts Since my board is a bananapi m2 zero.