Hello we're trying to get an usb-hid device working on linux system.(Currently Rpi-2B Buildroot 64bit)
But dmesg shows an error on device plugged in, while other keyboards/mouse work fine.
The error -22 isn't found with googling so I am stucking here.
Wondering what the code means or where to find the full error list. Or what our hw team can do to fix this.
Does anyone can help? Thanks in advance.
-22 is EINVAL defined as:
#define EINVAL 22 /* Invalid argument */
(usb subsystem returns negative error codes)
This error text comes from these lines:
ret = hid_add_device(hid);
if (ret) {
hid_err(hid, "can't add hid device: %d\n", ret);
goto err_connection_disable;
}
You can try to increase linux kernel loglevel to find the exact cause.
Related
I'm trying to build u-boot for our simple test board. (arm64)
After setting in include/configs/ab21m.h (our board),
#define CONFIG_SPL_BSS_START_ADDR 0x4f00000
#define CONFIG_SPL_BSS_MAX_SIZE SZ_32K
when I compile it, it gives me error while linking u-boot-spl. The error message is like this.
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
UPD include/generated/timestamp_autogenerated.h
CFGCHK u-boot.cfg
CC cmd/version.o
AR cmd/built-in.o
LD u-boot
CC spl/common/spl/spl.o
OBJCOPY u-boot.srec
OBJCOPY u-boot-nodtb.bin
SYM u-boot.sym
RELOC u-boot-nodtb.bin
COPY u-boot.bin
MKIMAGE u-boot.img
LD u-boot.elf
AR spl/common/spl/built-in.o
LD spl/u-boot-spl
aarch64-none-elf-ld.bfd: invalid length for memory region .sdram
make[1]: *** [scripts/Makefile.spl:509: spl/u-boot-spl] Error 1
make: *** [Makefile:1984: spl/u-boot-spl] Error 2
make: *** Waiting for unfinished jobs....
By the way, the linker script for spl starts like this after the build.
MEMORY { .sram : ORIGIN = 0x4000000,
LENGTH = (14*1024*1024) }
MEMORY { .sdram : ORIGIN = 0x4f00000,
LENGTH = SZ_32K }
OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
This is strange because this 0x4f00000 and SZ_32K is what I gave for CONFIG_SPL_BSS_START_ADDR and CONFIG_SPL_BSS_MAX_SIZE. I placed this range in the on-chip RAM area some enough space above CONFIG_SPL_TEXT_BASE and below CONFIG_SPL_STACK with enough stack space. (I referenced imx8mm_evk board). What should I correct?
BTW, I found CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_INIT_RAM_ADDR are all set to 0x40000000in imx8mm_evk, which is the DRAM start addrss. But CONFIG_SYS_INIT_RAM_SIZE is set to 0x200000 (2MB) where there is actually 3072MB DDR. Why is this value set to small size?
I asked two qeustions. Any help will be very much appreciated.
So, your first problem is a literal one. You have SZ_32K as the value for CONFIG_SPL_BSS_MAX_SIZE but since you're likely lacking #include <linux/sizes.h> in include/configs/ab21m.h you're not getting that constant evaluated.
As for what this is all doing, and why you should likely use something more like 2MB as seen on other platforms and place it in SDRAM rather than much smaller on-chip memory, if you look at arch/arm/cpu/armv8/u-boot-spl.lds you can see we're defining where the BSS should reside and that's likely larger than 32KB (and you'll get an overflow error when linking, if so).
I try to operate NI USRP-2920 by GNUradio.
At the first, I typed "uhd_find_devices".
Result is below.
----------------------------------------------
-- UHD Devices 0
----------------------------------------------
Device Address:
serial: 3077BE9
adde: 192.168.10.4
name:
type: usrp2
In the next, I typed "uhd_usrp_probe" in terminal.
Result is below.
Error: RuntimeError: Please update the firmware and FPGA images for
your device. See the application notes for USRP2/N-Series for
instructions. Expected FPGA compatibility number 11, but got 10: The
FPGA build is not compatible with the host code build. Please run:
"/usr/local/lib/uhd/utils/uhd_images_downloader.py"
"/usr/local/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.4"
Therefore, I runned uhd_images_downloader. But, I typed
"uhd_usrp_probe" is the same result(RuntimError:update the firmware).
Could you tell me any advices?
Thank you.
Thank you.
I typed "uhd_image_downloder" after renewing ubuntu.
As a result, I could connect USRP.
Thank you for advice.
I have this program that listens to the microphone and tries to recognize what was said:
#!/usr/bin/env python3
import speech_recognition
recognizer = speech_recognition.Recognizer()
class Recognition:
def __init__(self):
self.recognizer = speech_recognition.Recognizer()
def listen(self):
with speech_recognition.Microphone() as source:
self.recognizer.adjust_for_ambient_noise(source)
self.audio = self.recognizer.listen(source)
def recognize_sphinx(self):
decoder = self.recognizer.recognize_sphinx(self.audio, show_all=True)
for best, i in zip(decoder.nbest(), range(10)):
return best.hypstr
r = Recognition()
r.listen()
print(r.recognize_sphinx())
Although the code works, it does display the following warnings along with the output:
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
potato
The problem is I want a script to execute the code above and read its output (potato), but the returned result is mixed with all those errors. I tried the solution I saw here, but it only suppress the alsa warnings. Probably messing with alsa/pulseaudio configs will solve this problem, but I don't want to do that on every machine that runs the code.
I also tried redirecting stdin/stderr to null, but didn't suppress anything.
I have a workaround in mind that is, when the script runs this program, to get only the last line, but I want that only as a last resource.
The warning/status messages go to the standard error output (stderr), while the output of your print() call goes to the standard output (stdout).
It should be trivial to separate the two.
If you want to actually suppress the warning/status messages, you can have a look at my answer to the SO-question you were mentioning, or the more verbose answer I've linked to from there.
I am using this port of FreeRTOS and I am loading it onto the Cortex-M3 within an OMAP4430. This works fine using the remote proc framework and I am able to use RPMsg to communicate with it.
Sometimes, however, rproc fails to load the elf and gives the following error:
rproc remoteproc1: bad phdr da 0x0 mem 0x10310
rproc remoteproc1: Failed to load program segments: -22
rproc remoteproc1: rproc_boot() failed -22
This seems to happen when the size of the elf file gets too large: this happens when the size is 377331 bytes but does not happen when I simply remove a bunch of print statements and bring the size down to 342563 bytes.
I have tracked the error message down to this piece of code: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_elf_loader.c?v=3.9#L188. It seems that rproc_da_to_va is unable to find a segment in memory large enough to fit the ELF.
How can I make sure that there is enough memory for the size of my ELF? Can I tell the kernel that I specifically want a certain region preallocated for this kind of thing? Is there some way to ensure that this part of my ELF remains small?
Thanks!
Make sure that the FreeRTOS configuration constants configTEXT_SIZE and configDATA_SIZE agree with the amounts demanded by your linker script. For example, if your linker script contains
MEMORY
{
TEXT (rwx) : ORIGIN = 0x00000000, LENGTH = 1M
DATA (rwx) : ORIGIN = 0x80000000, LENGTH = 1M
}
then you should set configTEXT_SIZE and configDATA_SIZE to 0x100000.
I'm trying to understand debug output from a crash log. I have the following line from the crashlog:
22 FG 0x00022b94 0x1000 + 138132
I understand how to use atos on 0x00022b94 to get the source code location.
What I would like to know is why the crash log helpfully splits that number into 0x1000 + 138132? I have googled and the googles failed me.
0x1000 is where the __TEXT segment of that binary file (your app or some dylib) is mapped to, and 138132
is the (decimal) offset from that origin. This separation allows program to find the error location in a position-independent way.