Vancouver

Ok, just switched to 5.83.190426: :~$ lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub So everything seems fine now. Thank you very much for your support!

Sorry, what do you mean by 'switching to beta'? The nightly builds, or another kernel? I just installed 4.20.7-sunxi, but there is no difference.

Hi, I have a problem with usbhost on a NanoPi Duo2 with Armbian Bionic: Linux nanopiduo2 4.19.36-sunxi #5.82 SMP Mon Apr 22 19:12:08 CEST 2019 armv7l armv7l armv7l GNU/Linux Everything works fine so far except for USB hosts. None of the connected USB devices is detected. I am quite sure that the voltage supply is stable. I tried to power the board in two ways: From an USB powerbank (2A) with a short USB cable From a laboratory power supply (1.5A) directly connected to the 5V and GND power pins In both cases, the board works ablsolutely stable, no reboots, no SD card issues, even with some I2C devices and a GPS receiver connected to UART and Wifi networking. However, no USB host. I am using a USB connector breakout board with very short connections to the NanoPi (everything mounted on a breadboard). VUSB and GND are connected to 5V/GND with ~2 cm wires. I have tried USB2 and USB3, and I have tried to swap D+ and D- on both ports. USBHOST0, 2, and 3 are enabled in armbian-config and the overlays are loaded at boot: ... 374 bytes read in 9 ms (40 KiB/s) Applying kernel provided DT overlay sun8i-h3-i2c0.dtbo 502 bytes read in 9 ms (53.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart1.dtbo 504 bytes read in 9 ms (54.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo 504 bytes read in 8 ms (61.5 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 504 bytes read in 8 ms (61.5 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo 4155 bytes read in 9 ms (450.2 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ... lsusb reports always the following, no matter if there is any USB device connected: :~$ lsusb Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub and :~$ dmesg |grep usb [ 0.000000] Kernel command line: root=UUID=82ac9789-2ef5-473c-81a2-1c4d59545882 rootwait rootfstype=ext4 console=ttyS0,115200 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 loglevel=1 ubootpart=5065b6de-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 1.360294] usbcore: registered new interface driver usbfs [ 1.360374] usbcore: registered new interface driver hub [ 1.360504] usbcore: registered new device driver usb [ 2.567569] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO [ 2.788367] ehci-platform 1c1a000.usb: EHCI Host Controller [ 2.788422] ehci-platform 1c1a000.usb: new USB bus registered, assigned bus number 1 [ 2.789881] ehci-platform 1c1a000.usb: irq 27, io mem 0x01c1a000 [ 2.804274] ehci-platform 1c1a000.usb: USB 2.0 started, EHCI 1.00 [ 2.804769] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 [ 2.804784] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.804796] usb usb1: Product: EHCI Host Controller [ 2.804807] usb usb1: Manufacturer: Linux 4.19.36-sunxi ehci_hcd [ 2.804818] usb usb1: SerialNumber: 1c1a000.usb [ 2.807807] ohci-platform 1c1a400.usb: Generic Platform OHCI controller [ 2.807874] ohci-platform 1c1a400.usb: new USB bus registered, assigned bus number 2 [ 2.808350] ohci-platform 1c1a400.usb: irq 28, io mem 0x01c1a400 [ 2.872742] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19 [ 2.872758] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.872770] usb usb2: Product: Generic Platform OHCI controller [ 2.872781] usb usb2: Manufacturer: Linux 4.19.36-sunxi ohci_hcd [ 2.872792] usb usb2: SerialNumber: 1c1a400.usb [ 2.876097] usbcore: registered new interface driver usb-storage [ 2.884958] usbcore: registered new interface driver usbhid [ 2.884964] usbhid: USB HID core driver [ 2.969162] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 2.976654] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 2.982968] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 2.991897] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 4.236043] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 4.480475] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 8.757860] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 8.798639] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.048938] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.078126] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.155500] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.176147] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.211080] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.269968] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 9.299488] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe [ 14.705827] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe I can not interpret the 'Couldn't get regulator' message... perhaps this is the problem? Possibly something wrong with the device tree? There is no further output in demsg when dis/connecting a USB device. I have tried several USB sticks: memory, RTL-SDR, Bluetooth, IR, but no success. Interestingly, the lsusb and dmesg outputs are exactly the same as shown above if USBHOST2 and 3 are disabled in armbian-config. I am running out of ideas, so any suggestions are welcome, Thanks.

Ok... thats a bit strange. And it is not possible to turn on the pullups again after configuring for I2C? The problem is that the expansion board is already finished (it was designed for and used on a RPi). The level shifter is made of two MOSFETs as described in here (pdf, see page 4). Inserting pullups requires a hardware patch. But it seems there is no way around. Thanks for your reply. Regards

I am sorry but even after long searching I could not find out how to enable internal pull up resistors in an A20. I am on a BananaPro with Bionic, kernel 4.14.70. I want to use the pull ups on I2C-1. Presumably it is quite easy. I know that internal pull resistors are usually too weak for I2C, but the I2C is only connected to an external level shifter since all connected I2C devices have 5V lines. So the internal resistors should be sufficient, and the expansion board is working reliably on an old Rapsberry model B with internal pull ups. So, how can I enable internal pullups? The I2C-1 overlay seems not to have an option for that. Can it be done via device tree or writing to /sys/class? Thanks for suggestions. Best Regards

Hi, exactly the same issue on an OPi2+ here, same Kernel. However, this extra clock pulse does not have any effect on the operation of my SPI slaves. I have connected an SPI TFT display and a PIC microcontroller on the same SPI bus but different chip selects. If you monitor chip select and spi clock simultaneously on the scope, you will see that the extra clock cycle occurs around the falling edge of the cs signal, so the SPI slave "sees" only the falling edge of this clock pulse, and data is sampled on the rising edge in my case. I dont know the reason for the extra pulse, but as far I can say, it does not cause any problem. Are you sure that the extra clock pulse is really the problem why your slave refuses working? Perhaps you can alter the sampling clock edge of the slave and play with the CPOL/CPHA settings.

nmtui is also not available here. I will find out how to install and then get back to you. Standby... :-)

Ok, I used 'sudo service start network-manager' and network-manager is up now. However, 'nmcli con add con-name..' complains Error: 'con' command 'add' is not valid.

Hm, there is no systemctl on my system. Did you mean sysctl? But 'sudo sysctl start network-manager' reports sysctl: cannot stat /proc/sys/start: No such file or directory sysctl: cannot stat /proc/sys/network-manager: No such file or directory

Thanks tkaiser, I will try your suggestion. Can I be sure that network-manager does not interfere with the AP configuration of wlan0?

Sorry, I forgot to mention two things. First, a snippet from dmesg: [146505.927251] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [158802.546876] sun7i-dwmac 1c50000.ethernet eth0: Link is Down [231079.235691] RX IPC Checksum Offload disabled [231079.235726] No MAC Management Counters available [231578.280995] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Second, this behavior did not occur with legacy kernel.

Hi, not sure if this problem is related to Armbian, but in my case it occurs only on an Armian system. I have mainline kernel (4.7.x) running on a Banana Pro. wlan is configured as access point and works without any problems. eth0 is configured as client with static IP. The Banana is running 24/7, but the ethernet port is used only sporadically. The switch where eth0 is connected to is powered down most time. The problem is that eth0 forgets its IP configuration after a while, ifconfig then reports no IP address for eth0. I have to login via wlan and then ifdown/ifup eth0, then it works again. After a couple of hours (I dont know exactly how long), the IP is lost again. What is going wrong here?

Hi together, I spent a lot of time in understanding the SPI driver architecture, and I came to the conclusion that I cannot gain the performance required for my application while using this linux SPI driver. Maybe I am wrong with that, but each SPI transfer requires traversing a driver architecture of three levels (spi-sun4i.c, spi.c, spidev.c) with many function calls in between. Even if the time for a pure SPI data transfer is determined by the SPI clock frequency only, the setup time before starting the transfer is significantly longer. This does not play a role as long as we want to readout a temperature or inertial sensor a few ten times per second, but for controlling a QVGA tft display it is definitely too slow. The display in question (see http://admatec.de/pdfs/C-Berry_0.pdf)is shipped with a demo software for the Rapsberry Pi, and on an Raspberry (an old model B+) I interestingly do not have any performance issues. The display runs as expected with about 2-3 fps. So I looked into their source code and found that they bypass the kernel's driver architecture. The software is based on the BCM2835 library which seems directly write into the peripheral registers via /dem/mem. In the BCM library documentation is said "In order for bcm2835 library SPI to work, you may need to disable the SPI kernel module [...]" There is a port of the bcm2835 library available for the Banana which claims to be fully compatible, but in fact the Banana version takes the long way over the linux driver which is about 10 times slower. In order to come to a solution, I went the same way as the Raspberry software and handled all the SPI and GPIO stuff via the /dev/mem interface. The display performance is comparable to the Raspberry version now. However, accessing peripheral registers directly from the user space is clearly a nightmare from the kernel's point of view. So I decided to go the clean way and changed it into a separate kernel driver. Somebody already wrote a framebuffer driver for this display on the Raspberry again. I modified this driver and replaced the BCM specific parts by the A20 register interface. Then I build a kernel version without any SPI driver (except mine). There is still some potential or enhancement, for example I take control over some GPIO pins even if the GPIO register space is occupied by another driver. Here I have to take care not to change any GPIOs used by other devices. However... it works. It was a very long way to come here, but I think this is the best way. I tested some small demo applications using pygame. The speed is as I would expect from an SPI connected display.

Hi all, thanks a lot for your replies. Good to know I'm not alone with this problem. However, I could proceed a little bit with the problem of slow SPI transfers on the A20. I upgraded to kernel 4.7.2 (which did not solve the problem), and I modified the SPI low level driver. In drivers/spi/spi-sun4i.c there is a function sun4i_spi_set_cs(), that takes control over the CS handling. Here, the A20 is configured for software controlled CS and the CS state is set every time this function is called. (I don't know if the H3 uses the same driver as the A20, but the SPI subsystem may be similar) I just commented out the lines that configure CS for manual control and set the CS state, so this function simply does nothing now (CS is under hardware control by default). After compiling and installing this modified driver, the delay between CS becoming active and start of SPI clocking reduced to 2usec at 1Mhz SPI clocking, and even 150nsec at 10Mhz. Without the modification, it was about 20usec minimum independently from the clock speed (opened a bottle of wine here...) However, the sun4i_spi_set_cs() function is still called from somewhere, and this seems still to cause a delay. So, sending a number of SPI words still takes approximately the same time as without the kernel modification, but the CS pulses are significantly shorter while the pause between the transmissions is still much too long. So there is still some work to do. I have to find out where sun4i_spi_set_cs() is called from (possibly, the spidev driver?). I wonder if there were a better way for switching between manual and hardware control for CS than changing driver code. How is this handled in Raspberry? Moreover, the CS polarity is wrong and I could not set it correctly so far. For an unknown reason, the low level driver cannot be compiled as a module, so always the kernel must compiled and installed completely, which is time consuming. I will keep you informed. However, any help is welcome.

Strange. Which kernel are you using? Legacy (3.x) or mainline (4.x)? This is interesting. Does this also suppress all the early kernel boot messages output on uart, or is the uart released after boot has finished?

Ok, on Kernel 4.5.5 I had to sudo update-rc.d -f rc.local remove sudo update-rc.d -f rc.local defaults for starting rc.local at boot time. Moreover, the bus numbering of the i2c busses has changed in contrast to legacy kernel. However, this way the hardware clock is set quite at the end of the boot process. It would be fine to have the correct time as soon as possible. No idea how to do that.

Not sure if this is the "official" way, but on a Banana Pro on kernel 3.4.x I solved this by adding the following lines to /etc/rc.local: # enable ds1307 rtc chip connected to i2c-2 bus echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-2/new_device # wait for one second, then set system time from /dev/rtc1 device sleep 1 hwclock -s -f /dev/rtc1 Here 0x68 is the i2c device address of the 1307 (may be DS3231 is different). Take care of the correct i2c bus number and the correct /dev/rtc device. After the "echo" a new rtc device should appear. On version 4 kernels however this seems not to work any more, as I just noticed. It works when executing the commands by hand but not from rc.local. Is rc.local not executed any more on the mainline kernels?

As far as I know, you can disable the boot console output in the /boot/boot.cmd file. There is a line like setenv bootargs console=ttyS0,115200 ... Try to remove the console= entry. Afterwards you have to compile the boot.cmd file, for an example see here: http://forum.armbian.com/index.php/topic/139-change-resolution-rotation-bootcmd/ I don't know if there is a way to disable console output after booting has finished. Hope that helps :-)

Hi all, there is an issue with SPI on a Banana Pro (A20). I am on mainline kernel 4.5.5 now, but the problem already occurred on 3.4.109. SPI transfers are way to slow for my application, independently from the SPI clock. Investigating the SPI signals it turned out that there is an enormous delay between CS going active (low) and the transmission starting. The delay is in the magnitude of 10...20 usec which is a large multiple of the pure transmission time, so increasing the SPI clock does not solve the problem. The connected device is an SPI TFT display, so I have to send a large number of SPI words of 2 bytes each, where CS must toggle after each word (required by the target device). Consequently, the transmission of a large amount of data takes about several hundred times longer than required. I am not a driver expert, but I have looked into the source code of spi_sun4i.c which is the low level driver used for the A20 as far as I know. Here it seems, that the CS signal is under software control, i.e. it is handled as a normal GPIO. CS must be set/cleared by an explicit function call. I wonder, if this is the reason for the large delay. I found a quick-and-dirty workaround, where somebody configured the SPI controller directly via /dev/mem (i.e. bypassing kernel driver) and kept CS under hardware control, so the delay between CS and start of transmission is only some hundred nanoseconds. Now I am thinking of a modification of the SPI low level driver to keep CS under hardware control as well. However, I am not sure if this is a solution to my problem. Does anybody have a similar experience or a better idea than kernel modification? Any comments are welcome :-) Thanks