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!