My question is about Lichee Pi Zero board (based on Allwinner/Sunxi V3s SoC).
Initially I used pre-built Linux image (kernel 4.10.02), it has no built-in Wi-Fi support (for Realtek 8327BS chip), so I downloaded the latest kernel version from here and built it with the default settings.
LCD is ok, Wi-fi looks good too (LED is blinkikng), but I cannot use keyboard anymore - there is no reaction from OS, when I connect something to USB (no message and no input from keyboard).
Hardware is OK and works good with the old Linux image.
I have also tried the latest kernel from kernel.org with the same bad result.
Please help to understand the reason. I suppose bad settings, but HID supoort is enabled.
Update 1.
I establish connection through UART. As I see, some USB features are detected during boot:
I'm able to load some drivers using insmod also:
Unfortunately, Linux still does not recognize any USB Device. I have connected mouse, keyboard, hub, mass storage and got no reaction from OS. It looks like devices do not get power (there is no light from mouse).
Update 2.
The best way I have found at the moment is to use buildroot-licheepi-zero.
It's very easy to use:
make licheepi_zero_defconfig
make menuconfig (optional)
make
After many-hour wainting I got the sdcard.img. It includes all neccessary files (zImage, RootFS, u-boot.bin, etc) and could be placed to SD with linux dd or etcher.
Linux boots successfully, but you can use terminal only through UART, as there is no LCD output.
You can put LCD itself to work:
make uboot-menuconfig
make
BUT there is still no user login prompt on the LCD after boot. So I need to log in and put command through UART.
Please share suggestion if any.
Update 3.
The change below enables login prompt on LCD (and disables it through UART):
make menuconfig
Now we are able to use Wi-Fi:
insmod /lib/modules/4.14.14-licheepi-zero/kernel/drivers/staging/rtl8723bs/r8723bs.ko
ifconfig wlan0 up
edit file /etc/wpa_supplicant.conf to add your Wi-Fi SSID and PSK
wpa_supplicant -B -d -i wlan0 -c /etc/wpa_supplicant.conf
udhcpc -i wlan0
Connection is established now, we can ping and so on.
There is still the question - how to enable full-functional terminal both on LCD and UART.
Many thanks!
With regards,
Maksim
The best solution is to use Buildroot.
Please check updates at topic start for details.
Related
I have a USB HID device that can work in two different modes. The selection of modes is based on the sequence of USB enumeration/initialization packets sent to it.
I am using a Raspberry Pi 3 running Raspbian, however I also see the same issue if I compile my code for my desktop Ubuntu distro.
The issue I have is that linux is recognizing the USB device as a HID device and then sending the sequence of commands that it deems necessary to start the device, and this works correctly and starts the device in "Mode 1".
However I need to start the device in "Mode 2" and to do this I need to send a slightly different set of enumeration/initialization commands.
I am new to linux but very experienced with LibUSB and LibUSBDotNet under windows and can get the behavior I desire under windows.
Windows has similar behaviour to linux in that it will enumerate, recognise the device as a USB HID device and then initialise it as it deems fit resulting in the device going into "Mode 1". To prevent windows doing this I can create a LibUSB filter driver for the device, which then replaces the default driver, so windows will now do the initial enumeration, realise that the VID and PID of the device are managed by the LibUSB filter driver (rather than the windows HID driver) and then stop enumeration/initialization - this allows my code to take over and complete the initialization into "Mode 2".
How can I stop Linux from fully enumerating/initializing this device (as I do with windows). Perhaps I need to do something with udev rules or something, but I would have no idea what as I am new to linux.
Any help greatly appreciated
you have right, you have to play with the udev rules.
First of all you have to identify your device. Find the idProduct and the idVendor of your device. You can use:
lsusb
Then in the rules.d folder (/etc/udev/rules.d) create a new file with the name:
10-my-usb.rules
In this file add this line
SUBSYSTEM=="usb",ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="XXXX", MODE="666", GROUP+="plugdev"
Replace the XXXX with the value you get before
Then restart your udev rules:
sudo udevadm trigger
Then unplug and replug normally you can use it
I want to change Vendor_ID and Device_ID from a PCI device.
However, every change I make will not save and I have no clue why.
First I tried making changes using setpci which results in this:
# sudo setpci -s 01:00.0 00.w
# 8086
# sudo setpci -s 01:00.0 00.w=168C
# sudo setpci -s 01:00.0 00.w
# 8086
Then I tried making the same changes using two different hex editors, editing the config file located in /sys/bus/pci/devices/0000:01:00.0/, but after saving, the file seems unchanged.
I did open it as root and I don't get any errors when saving.
I also tried ethtool, but it cannot even access the registers:
# sudo ethtool -e wlan0
# Cannot get EEPROM data: Operation not supported
I tried everything of the above on both Lubuntu 15.10 and Knoppix 7.6, resulting in the exact same behaviour.
So, why does this happen?
If the registers are protected, is there a way to unprotect them?
Some more information:
The mentioned pci device is a Intel 7260-AC Wireless Network Adapter
I want the BIOS to recognize it as a Qualcomm Atheros AR9485 Wireless Network Adapter, because it's whitelist blocks everything else.
Modifying the BIOS is not an option.
I'm running Lubuntu and Knoppix from a USB drive
PCI Configuration registers typically have attributes such as read only (RO), read write (RW), or other less common ones.
The problem is that you are trying to write a value to a read only register. I have not seen the documentation for this particular device, but I have worked with other Intel PCI devices and I have never seen a RW (read/write) device ID or vendor ID register. For example, look at this link on page 96, the VID and DID registers are RO (read only).
Unfortunately, there is no way to change the read only attribute of the register, as this is almost certainly enforced at the hardware level.
Assuming you could change the device ID or vendor ID registers, I imagine this would not necessarily mean a working network adapter, as the BIOS and OS use these values for ACPI and device drivers. There may be a way to fake the device ID and vendor ID in the BIOS, but as you say that is not an option and I don't think it would work anyway.
Depending on how/why your BIOS is whitelisting Qualcomm wireless adapters versus Intel wireless adapters might provide some workaround for this problem. I say the best solution would be to alter the BIOS whitelist somehow, perhaps through an update.
In case it helps, I have code that can modify PCI configuration registers of any device (although this will not circumvent hardware level restrictions such as RO, RW, ...). I don't think this will fix your problem but at the very least you can learn more about PCI configuration registers from it.
This issue is driving me nuts. I am working on a project with some other guys who built the electronics. We have custom boards with an atmega 1284p. For USB cummunication with the 1284p we use a FTDI FT230X USB Bridge. This doesn't have DTR; RTS is used to reset the board using a capacitor (pretty much like with off the shelf arduinos).
The arduino bootloader is used, and we use mighty-1284p to upload. The board selected is "Original Mighty 1284p 8MHz". After installing the right FTDI drivers from http://www.ftdichip.com/Drivers/VCP.htm I can upload to the board from a mac. Linux has these drivers built into the kernel. However, I cannot upload to the board. AVR gives the following error:
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
dmesg gives the following:
...
[ 51.299964] usbcore: registered new interface driver ftdi_sio
[ 51.300088] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
...
and lspci:
...
Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
...
The settings for the mac and linux machine are identical. On both I use arduino 1.0.5. Both do see the correct serial port.
I've seen many posts in this forum with similar problems, but have yet to find one with a solution that works for me. Holding reset, or clicking it just before uploading does not work. As suggested in some forums I have tried with removing brltty to no avail. I have tried uploading with the Arduino IDE, Eclipse with AVR plugin and AVR via command-line. None will work. I've tried it on different machines as well with different versions of ubuntu, and uploading works in none of them. Adding -c arduino to avrdude command doesn't do the trick either. Any ideas on how to fix this?
My user is part of the dialout group, and I can upload to other arduino boards (like duemilanove) without problems.
This question was originally asked here: http://forum.arduino.cc/index.php?topic=244363
You mentioned Ubuntu; are you doing this as a normal user?
If so, you may need to add your account to the correct group, the serial port device belongs to.
You can do that like this:
sudo usermod -a -G dialout yourself
then (easiest) logout and log back in again.
However, it is possible that it is called something other than dialout in the latest Ubuntu, I haven't checked. I can confirm it is still dialout here on Debian Wheezy.
(this is a little odd, though, if it works; usually you get a permission error instead...)
I know this is quite an old question, but in addition to the dialout group problem I've had issues with ModemManager interrogating anything that looks like a serial port (and screwing up programmers in particular because they're not expecting those bytes). I don't know if that's what's happening in your case but it's worth a shot for others who end up here.
I just removed it entirely (which is a large hammer, probably temporarily disabling it is best...):
sudo apt-get remove modemmanager
If you want to try disabling it, maybe:
sudo systemctl stop ModemManager.service
I have a popular drawing tablet that I connect to my PC with USB. Once connected, the tablet detects hand movements and manipulates the pointer accordingly. Somewhere, the tablet is transmitting this data to my computer.
My goal is to intercept these transmissions and manipulate the mouse after I process the data. The buzzwords I have found are: device drivers and HID, but I haven't been able to piece together much more than that.
Assuming this is possible, I have a few questions:
How is this done if the data format is known?
How is this done if the data format is unknown/proprietary?
My computer is running Ubuntu (but answers related to any form of a Linux OS are greatly appreciated!).
Note: This question is similar but intended for Windows.
Actually you missed a buzzword "USB sniffing". ;-)
Here are a few tutorials on USB sniffing on Linux, to get you started.
Official Wireshark wiki for USB monitoring
biot.com/blog/usb-sniffing-on-linux (InternetArchive)
tjworld.net/wiki/Linux/Ubuntu/USBmonitoring
Essentially you use the usbmon Linux kernel module to capture the USB-packets and Wireshark as a front-end to display and analyse the captured USB stream.
To add another useful resource: Kernel manual for usbmon
You can use the following commands on Debian Linux to view debug log for usbmon in text format using usbmon Kernel's built in usb monitoring:
$sudo -i to use root
#modprobe usbmon
#ls /sys/kernel/debug/usb/usbmon to view bus sockets
#cat /sys/kernel/debug/usb/devices to view devices at each bus socket
#cat /sys/kernel/debug/usb/usbmon/<bus socket> to view or you can route stdout to a file using >
I'm running Ubuntu 11.10 on a BeagleBone with an Edimax EW-7711UAn wifi adapter plugged into the USB port. I've configured /etc/network/interfaces and the wifi works, BUT:
The wlan0 interface doesn't always come up when booting the device. It comes up successfully about one in three attempts.
The interface sometimes goes down again, especially when not used for a while.
The /etc/network/interfaces file includes:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid "Bodoni"
wpa-psk "<mypassword>"
In order to try to address point 1), I put the following in /etc/rc.local:
nohup sh -c "ifdown wlan0 && ifup wlan0"
But it hasn't seemed to help much. I'm guessing that the second problem might be connected with power management, so I might try turning that off in /etc/rc.local.
But does anyone have any thoughts on how I might get the wifi to come up reliably on boot? I'm running the BeagleBone headless with no Ethernet (it's on a robot) so it's important I get this fixed!
FYI, I'm using the default drivers - lsmod gives:
Module Size Used by
aes_generic 27837 2
arc4 1111 2
rt2800usb 12386 0
rt2800lib 45146 1 rt2800usb
crc_ccitt 1457 1 rt2800lib
rt2x00usb 10595 1 rt2800usb
rt2x00lib 39077 3 rt2800usb,rt2800lib,rt2x00usb
mac80211 228509 3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211 167722 2 rt2x00lib,mac80211
rfkill 16703 1 cfg80211
binfmt_misc 6224 1
spidev 4620 0
I'm hoping not to have to compile a new driver because I haven't had much success with that!
I've had a similar problem with my BeagleBones using another wifi adapter using the rt2800usb driver. Specifically I am using a DLINK DWA-125 (HW Rev A2) which is based on the rt3070 chip.
Same exact symptoms that you are reporting if I plug the DWA-125 directly into the USB port on the BeagleBone.
BUT if I plug the adapter into a USB extension cable and then plug the extension cable into the BeagleBone USB port, everything works fine. I have done 100s of hours of Cloud9 development using this setup and no problems with Wifi whatsoever.
I am running the Angstrom distro - and I find the same issue on all three of last BB releases (4/22. 5/? and 6/18).
Length of USB extension cable doesn't seem to matter (at least between 1ft and 12ft - haven't tried anything below 1ft.)
I have 6 BeagleBones (4 ver A5 and 2 ver A6) - behavior is the same on all of these Beaglebones.
Also have 4 DWA-125 Rev A2 USB adapters - behavior is the same on all of these.
I have not experimented with other USB Wifi Adapters using the same or other chips/drivers. And I haven't spent the time to track down the root cause of this behavior - I have code to write!
But, give it a try in case your experience matches mine - its a quick and easy 'fix'.
---- Addendum:
I just tried an experiment with the Belkin N150 Micro USB Wifi Adapter - based on the rtl8192cu chip and the standard drivers that come with the 6/18 BeagleBone Angstrom distribution.
Got very similar behavior: The Wifi doesn't work at all when plugged directly into the USB port. But when plugged in via a 1ft USB extension cable, everything works fine.
I had the same problem. The best explanation i've found so far is this one from Adafruit
The main idea is that the Wifi dongle is destructed by the HDMI adapter, that is situated just under the USB slot. You have two workarounds in this case:
Put the Wifi-dongle as far as possible from the USB-slot by means of a cable
Disable the HDMI interface if you don't really need it!
Only the second option helped me.
Here are the steps:
> mkdir /mnt/boot
> mount /dev/mmcblk0p1 /mnt/boot
> nano /mnt/boot/uEnv.txt
Remove the # in front of the cape_disable command
##Disable HDMI
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
I hope it will help you guys!
I've fixed the problem by removing the USB ESD spike protection IC (U10, TPD4S012). It should be wired between the USB connector and the CPU but it was placed after the USB connector on my board (rev. A4). I don't know if this is fixed on later revisions.
Update: this won't help much in some cases. Check this thread.
I had a similar problem for most of a year until I googled long enough to find
wicd
After setting things up with wicd my 5 beaglebones have been rock solid on my home network on wifi dongles from the back bedroom to the garage. /etc/network/interfaces is not the way to go. I must have tried hundreds of configurations and some seemed to last for a day or two. I do remember the doc gave a good default for interfaces, very barebones. And wicd runs your supplicant if ever needed.
It took me ages to get reliable WiFi on the BeagleBone. In the end, the answer was to use an Atheros dongle, since I had poor luck with RealTek and RALink chipsets. The NetGear WNA1100 works very reliably for me, in both Angstrom and Ubuntu. See my post here.