While my device boots up, I get the following message in the dmesg log:
<6>[ 0.087051] [0: swapper/0: 1] i2c-msm-v2 78ba000.i2c: probing driver i2c-msm-v2
<3>[ 0.087121] [0: swapper/0: 1] i2c-msm-v2 78ba000.i2c: error on clk_get(core_clk):-517
<3>[ 0.087146] [0: swapper/0: 1] i2c-msm-v2 78ba000.i2c: error probe() failed with err:-517
<6>[ 0.087180] [0: swapper/0: 1] platform 78ba000.i2c: Driver i2c-msm-v2 requests probe deferral
I'm a newbie in linux device driver and I'm aware of I2C in a very basic level.
I would like to know why this message appear and how to fix it?
Is this a result of an unmatching name problem?
I'm grateful for your help.
This problem relates to the driver probe order. Because clk inits after probing i2c, so that i2c failed to get clk.
This problem can be solved by changing Makefile (in /drivers). Just move clk upto a higher position than i2c.
I checked it this way and now the error message disappears :)
Related
I want to create a program that logs a message when net_ns_net_exit function in the kernel is called.
SEC("fexit/net_ns_net_exit")
int BPF_PROG(net_ns_net_exit, struct net *net, long ret)
#endif
{
__u64 netns_inum = BPF_CORE_READ(net, ns.inum);
debugf("removing: netns_inum: %u", netns_inum);
return 0;
}
bpftool v7.0.0
using libbpf v1.0
features: libbfd, libbpf_strict, skeletons
I am building in on Ubuntu 22.04 with kernel 5.15.0-52-generic, AMD. The program works well on this machine, but when I try to run it on GCP with kernel version 5.10.133+ it fails with error:
libbpf: failed to find kernel BTF type ID of 'net_ns_net_exit': -3
libbpf: prog 'net_ns_net_exit': failed to prepare load attributes: -3
libbpf: prog 'net_ns_net_exit': failed to load: -3
libbpf: failed to load object 'remove_net_ns'
libbpf: failed to load BPF skeleton 'remove_net_ns': -3
loading remove_net_ns skeleton failed with error: -3
I've checked if vmlinux is available on machines and I found that both: GCP and my local ubuntu have: /sys/kernel/btf/vmlinux. I've checked the content(with vim) on the VM and I've noticed that my VM has net_ns_net_exit but GCP doesn't. I am not sure if it's related and how exactly make it works. Method: net_ns_net_exit was introduced to the kernel a long time ago so I've expected that it should be available. Maybe someone had this problem and has some advice or knows how to approach this issue?
The fexit hook points don't offer a stable API. So if the function you are trying to trace is inlined (as seems to be the case with your GCP kernel), then your only choice is to find another function that gives you the same information.
I was trying to program my ESP32_CAM module, but every time I got this error:
Serial port COM4
Connecting.................................
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:51:82:d4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x0016efff...
Compressed 18528 bytes to 12759...
A fatal error occurred: Packet content transfer stopped (received 8 bytes)
A fatal error occurred: Packet content transfer stopped (received 8 bytes)
Has anyone had a similar problem?
This link says it means there is something wrong with the esp file system rendering it "broken"... Not sure if there is a way to fix the issue though.
EDIT:
I found that if I disconnected some of my peripherals from esp32, the error went away. Perhaps too much power was being drawn.
As if right now I am in a bit of a rush to get an answer to my problem. The model has been trained and the server works locally with the NN running in the background, but on the server we get the following error message:
2020-04-08 11:54:15.787274: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency: 2799865000 Hz
2020-04-08 11:54:15.787801: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x4b5ca00 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-04-08 11:54:15.787830: I tensorflow/compiler/xla/service/service.cc:176] StreamExecutor device (0): Host, Default Version
terminate called after throwing an instance of 'std::system_error'
what(): Resource temporarily unavailable
It seems that the server host doesn't like the fact that Tensorflow is trying to log the following error/warning message:
2020-04-08 11:53:42.453164: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to
use: AVX2
Is there a way in JS to disable these error logs so we can run the trained model on the server? Thanks in advance!
tl;dr: flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
Hello,
my device is based on a STM32F103CBTx which came with a proprietary firmware and had readout protection on.
I connect to it with a ST-Link v2 SWDIO and SWCLK connected to PA13 and PA14 and this command:
sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
I don't remember how I removed flash protection, but it worked as the original firmware didn't work anymore. Then I created a simple hello world firmware which pulls up and down three gpios and flashed it. The gpios are pulled up and down in 700ms intervals.
After flashing, I can't connect with openocd anymore. I forgot to specify the offset, the manual says the offset defaults to 0 and as it worked, I suppose instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
This is the last contact I had:
> halt
halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
> flash write_image erase fw.hex
flash write_image erase fw.hex
auto erase enabled
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 4096 bytes from file fw.hex in 0.285697s (14.001 KiB/s)
> reset
reset
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Any directions highly appreciated.
Edit:
What I get now, also tried another st-link:
% sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244356
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
No, it doesn't matter at all, they are the same.
After reset, the MCU loads the word at address 0 in SP, and the next one at address 4 in PC. The BOOT0 and BOOT1 pins control which memory gets mapped to 0x00000000. Usually, BOOT0 is tied low, and flash memory at 0x08000000 gets mirrored at 0x00000000.
instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
The factory bootloader is indeed write protected, openocd can't overwrite it.
However, your application could have reconfigured the SWD pins, by writing a wrong value in GPIOA->CRH or AFIO->MAPR, thereby preventing openocd from working. It's the most common cause of this problem.
Fortunately, there is a way to recover.
Connect under Reset
If the reset pin of the controller is held low for a while when openocd is started, the application is prevented from starting, and messing up the GPIO configuration.
Openocd can do this automatically, when
It's told to do so, the line reset_config srst_only srst_nogate is present somewhere in the configuration script.
The MCU reset pin is connected to the debugger hardware, pin 15 on an official ST-Link/V2.
Or you can do it manually, by whatever means your board provides. If you are lucky, it has a reset button, if not, you must find a way to somehow ground the MCU reset pin.
Pull the reset pin low
Start openocd
Wait until the Info : Target voltage line appears. Maybe a second longer.
Release the reset pin.
It requires a bit of trial and error, you'll get better with practice.
Then you can flash your improved application, which carefully avoids reconfiguring the SWD pins.
I bought a HotPi a while ago, and decided to use it. So I followed the procedure to configure the IR and after a few hours I was able to IR signals on my Raspberry 1.
But my purpose here is to send IR signals, which I tried, without any luck.
So this is the command I try to do (just for test):
irsend SEND_START devinput KEY_POWER ; sleep 3
And this is what lircd tells me:
lircd-0.9.4c[907]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.4c[907]: Info: Cannot configure the rc device for /dev/lirc0
lircd-0.9.4c[907]: Error: invalid send buffer
lircd-0.9.4c[907]: Error: this remote configuration cannot be used to transmit
lircd-0.9.4c[907]: Error: error processing command: SEND_START devinput KEY_POWER
lircd-0.9.4c[907]: Error: transmission failed
lircd-0.9.4c[907]: Info: removed client
Edit:
It seems I'm not using the good drivers. According to the HotPi documentation, I'm suppose to use lirc-rpi, which I'm suppos to install with
sudo modprobe lirc-rpi
Which, at least, doesn't return an error. But trying to configure the interface tells me that the driver doesn't exist:
pi#raspberrypi:~ $ mode2 --driver lirc-rpi --device /dev/lirc0
Driver `lirc-rpi' not found. (Missing -U/--plugins option?)
Available drivers:
accent
alsa_usb
asusdh
atilibusb
atwf83
audio
audio_alsa
awlibusb
bte
bw6130
commandir
creative
creative_infracd
default
devinput
dfclibusb
dsp
dvico
ea65
file
ftdi
ftdi-exp
ftdix
girs
i2cuser
irlink
irtoy
livedrive_midi
livedrive_seq
logitech
macmini
mouseremote
mouseremote_ps2
mp3anywhere
mplay
mplay2
pcmak
pinsys
pixelview
samsung
sb0540
silitek
slinke
sonyir
srm7500libusb
tira
tira_raw
udp
uirt2
uirt2_raw
usb_uirt_raw
usbx
zotac
Here is no info what lirc version you are using. There are vast differences between the legacy 0.9.0 still used in some distros and modern lirc.
That said, the logs seems pretty clear. You are using the devinput driver, right? This driver does not support sending data, reflecting the fact that also the kernel doesn't.
You then need to use another driver - first stop might be the default one. If/when using this other driver, you need another lircd.conf.
Please refer to http://lirc.org/html/configuration-guide.html
EDIT: Ah, lirc-0.9.4c says the log. Sorry, my bad. The reply should still be valid, though.
When you record the remote, use:
irrecord -d /dev/lirc0 -f name.conf
The -f uses raw mode. This then worked for me on the transmit side, before I got same error as you.