I have a tx6s-8035 SoC which we integrated into a custom board. We connected an Asix 88772B to the usbotg port and we need it to start in host mode.
We grounded the USBOTG_ID pin and we tought it will start in host mode. It didn't happen unfortunately.
I have investigated the issue and I see a strange behaviour... I wrote dr_mode = host as an extra property into the official device-tree. After that I modified the ci_hdrc_imx driver to print what it got in the device_node and it said "peripheral". I backtraced the problem and when the of_usb_get_dr_mode() function is being invoked the device-tree already contains dr_mode = peripheral.
Any ideas? I just can't imagine what happens there...
p.s.: I double-checked that I'm updating the device-tree in a proper manner.
I found the issue:
The u-boot overrides the 'dr_mode' property with it's 'usbotg' parameter so I had to change the environment variable in u-boot and it works since that.
Maybe it helps others too.
Related
I tried implementing the variable store function to switch groups in a keyboard layout I developed, only for them to fail to implement in real use. To give you an idea, I'll write the gist of it in pseudocode
begin group(main)
group(main)
store(mode) 'off'
if(mode='off') > use(off)
if(mode='on') > use(on)
group(on) using keys
'+ {key} > set(mode='off')
group(off) using keys
{key} > set(mode='on')
Now When I implemented this on my computer after I reset said computer, I found it wouldn't actually use the different group when I actually installed the keyboard. Stranger yet, when I used the save function to save the variable stores, It cause the keyboard and whatever app I was using it in, to crash.
I did a bit of looking and found that my antivirus program (MCafee livesafe) was quarantining the crashpad_handler.exe files in the keyman installation folders. So after getting them back in my system and repairing the installation, I thought that would solve the problem, but it didn't.
Anybody else experiencing this? What did you do to solve it? For reference, everything was working fine before I reset my PC.
I am using the following library to connect via USB to an external device:
https://github.com/node-serialport/node-serialport
I set up the following sample project to narrow down where the issue might be:
https://github.com/nyoung697/node-serial-test
This code works on my Mac. The device I am connecting to accepts an ascii command and the carriage return to terminate that command.
In the example project, I am passing in 'V\r' and am expecting the version of the device to be returned. When I run this code on my Mac, I get the expected response.
However, when I run it on my Windows 10 machine, I do not get any response at all. Neither the port.on('data') or port.on('error') events are hit.
I tested downgrading the serialport library to version 4.0.7 and it does work.
Does anyone have any ideas what might have changed between 4 => 6?
P.S. I edited this question, as I originally thought it had something to do with Electron, however after doing this simple test with only node.js, I believe I have narrowed it down to this version of the library on Windows.
Okay... I just figured this out.
All I needed to do was add the property 'rtscts' to the openOptions object I pass in to the constructor and set it to true.
const SERIAL_PORT_SETTINGS = {
baudRate: 115200,
rtscts: true
};
let port = new SerialPort(devicePath, SERIAL_PORT_SETTINGS);
I figured this out by digging around in the release notes. I noticed that from v5.x.x to 6.0.0 the breaking changes included making this value default to false.
windows: We previously hard coded to have RTS on for windows at all times it now default to off.
How are you? I hope you can help me with something, I have a problem from Artix Linux, I want to connect my Wii Remote to use it as a Gamepad, it does not want to work because the uinput module does not want to interpret the events associated with Gamepad Inputs, it does not catch for example "BTN_A" or others, but if I put another as "KEY_A" if it recognizes it but acts as a keyboard input in that case. What solution do you propose?
Note that I use WMinput, and I have already installed cwiid, wminput, and even fixed the uinput module in the kernel.
I had the same problem. In my case the error was that I tried to pass the button as an unsigned char. I realized later that BTN_A is not defined as 131 but as 0x131, so it doesn't fit into the unsigned char and gets truncated. Hope this helps!
Revised Question (based on the now documented AVPlayer bug):
I found a workaround using this code as a base: https://stackoverflow.com/a/25623647/6697755
I found isWWAN flag can be used to check network type
var flags: SCNetworkReachabilityFlags = []
let isCellular = flags.contains(.isWWAN)
It seems to be a pretty reliable check.
So I can now derive a network type change and reboot the player.
...only took me about 80 hours to find this workaround ;|
I ran into the same problem when I updated to iOS 11. I filed a bug at Apple's Bug Reporter and Open Radar - rdar://35270862
I've edited my question with a workaround to resume playback after leaving or entering wifi.
If anyone has any info on how to fix this or exactly why this issue occurred in iOS11 please let us know.
I have compiled and installed the tiny_serial driver example from the book Linux Device Drivers by Greg Kroah-Hartman. I use the sources from https://github.com/duxing2007/ldd3-examples-3.x.git
The device node /dev/ttytiny0 is successfully created but I am having trouble reading anything from the device. Looking at the driver, it seems that I should be able to read a 't' character.
Running stty gets me the following below error:
root#brijesh-M11BB:~/ldd3-examples-3.x# setserial /dev/ttytiny0
/dev/ttytiny0, UART: unknown, Port: 0x0000, IRQ: 0
root#brijesh-M11BB:~/ldd3-examples-3.x# stty -F /dev/ttytiny0
stty: /dev/ttytiny0: Input/output error
Similarly doing cat /dev/tinytty0 also reports a similar error. I also tried minicom -D /dev/ttytiny0 but the device is always shown as offline.
It seems I am missing something, can anyone please point out what I am missing?
This is happening with me on both Ubuntu 15.10 (3.19.x kernel) and older 2.6.28 kernel.
I have debugged it and found the root cause.
strace shows -EIO on tinytty0 device. -EIO was generated from driver tty layer (-ENO_TTY_DEVICE). The reason for ENO_TTY_DEVICE was port->type is set to 0 (i.e unknown). Setting the port->type = PORT_16550A before adding uart driver resolved the issue.
While the previous answer was correct, it did not explain where to fix the code.
Note: I am using linux kernel 3.10
I implemented the one-line fix in the declaration of the uart_port struct, here is how:
static struct uart_port tiny_port = {
.ops = &tiny_ops,
.type = PORT_16550A, // THIS IS THE FIX
};
I believe this may be a bug in the kernel code, because by not setting the uart_port type, it defaults to PORT_UNKNOWN.
While I understand this may be a protection, it seems more correct to leave it at PORT_UNKNOWN rather than that of another random device.
BONUS POINTS:
After fixing the PORT_UNKNOWN issue, if you get a kernel panic for dividing by 0, comment out the following lines from duxing2007's code:
baud = uart_get_baud_rate(port, new, old, 0, port->uartclk/16);
quot = uart_get_divisor(port, baud);
BONUS POINTS 2:
This link shows how a developer with a similar issue (Ira Snyder) implemented the tiny_exit() function, so that you can remove the kernel module without causing a hang.