How to create patch to modify the device driver? - linux-device-driver

I need to modify the busb.c to from the bluetooth device drivers to work with the bluetooth USB dongle with the Yocto dunfell.
I know, how to create the patch and include with the yocto image for the Device Tree Source file (DTS)
But, with the Linux kernel module, I'm facing the error while baking the image.
Can any one redirect me to customize the kernel module via patch under Yocto?

Related

SDIO probe function isn't been called after moving SDIO device driver library to an old Linux platform using platform device and no device tree

I currently porting a sdio device driver (which's working on linux 4.3 or higher) to an old linux platform 3.10.14. The new one uses device tree to manage sdio bus and the driver uses some sdio api like sdio_register_driver, int sdio_probe(struct sdio_func*, struct sdio_device_id*), but the old one uses platform device with api platform_device_register used in the kernel. I installed the module to system have the old kernel and the probe function isn't called, please help me to fix this. I'm a newbie, I hope you guys can understand what I describe.
Thanks,
I tried replace field drv.of_match_table in struct sdio_driver (because of no device tree in old kernel) to drv.name (because platform device detects base on name field) but the probe function still isn't called

How to debugging and flashing Nucleo32 board from TrueStudio?

I'm trying to flash my code to NUCLEO-L432KC(STM32L432KC) by TrueStudio. It was failed.
[
It looks tool cannot detect ST-Link probe. I just connected it by USB cable from PC (Windows10). Code and project file are generated by STM32CubeMX.
What is the missing? What should I do?
I have confirmed following.
From STM32CubeProgrammer GUI, it cannot detect ST-Link connection.
From STM32CubeProgrammer CLI, it can detect S/N of ST-Link. But cannot connect.
From STLinkUpgrade 3.3.0, it can detect device and S/N. Also can update to V2J33M25.
From IAR Embedded Workbench, it can build and flash code and debug. No problem at all.
It looks same result using by STM32F4 Discovery kit for STM32F429 MCU.
Make sure you don't have another program such as ST-LINK utility running while you use the debugger. Some versions of the ST-LINK "hogs" the debug pod access and other programs then would have trouble connecting to it.
Install the drivers https://www.st.com/en/development-tools/stsw-link009.html
Choose the correct micro in the debug configuration window

Viewing a remote camera stream in Scratch

I'm doing a project for my son where we're going to have a remote Pi Zero with a camera and various sensors and actuators, connected via wired Ethernet to a Pi 3 as a controller with a Scratch GUI.
Seems like I can get a local camera to send video to the background of the Scratch project, or I can get a remote camera to stream back to e.g. VLC Player using RTSP.
Being as how I want to teach my son how to build a scratch GUI on the Pi3 to remote control the sensors and actuators on the Pi Zero, I'd really like the rtsp video stream to show up as the Scratch project background so I don't have to have a separate VLC window open.
So... how to pick up an RTSP video stream and send it to the Scratch backdrop?
Anyone got any ideas as to where I could start? I have intermediate raspbian, python and Scratch skills.
Thanks in advance,
Ben
Just a wild suggestion. Maybe it is possible to access your USB camera on the remote pi zero as a local camera using remote USB (I admit I have never tried it).
This functionality is provided by the package usbip
https://packages.debian.org/jessie/usbip
You can install this package using the following command on both raspberry pi devices:
sudo apt-get install usbip
For more information about the setup enter the command:
man usbip.

How do you get a waveshare 3.5 inch touch LCD to work with Raspbian Jessie?

I have a waveshare 3.5 inch touch LCD display and I m trying to get it working with the latest version of Raspbian A.K.A Raspbian Jessie. I followed futurice.com 's tutorial on getting it to work (tutorial is titled I'd like some LCD on my pi) and it worked on Raspbian Wheezy just fine. All I get now is a blank white screen. All help is greatly appreciated! (I must use the official Raspbian Jessie image without NOOBS from the Raspberry pi website.) I have a Raspberry Pi 2 Mobel B +.
From the product page:
Why the LCD doesn't work with my Raspbian? To use the LCD with the
Raspberry Pi official image, driver should be installed first. Please
refer to the user manual. However, for the first testing, you may want
to use our provided image directly. Why the LCD still doesn't work
with the Waveshare provided image? Make sure the hardware connection
is correct and connects fine. Make sure the image in TF card is burnt
correctly. The PWR will keep on and the ACT will keep blinking when
the Raspberry Pi starts up successfully, in case both of the two LEDs
keep on, it is possible that the image was burnt incorrectly OR the TF
card was in bad contact. Which power supply should I use? It is
strongly recommended to use a stand-alone 5V/2A power adapter, because
the PC's USB port might doesn't have enough power to support the Pi
and LCD. For more info, please check the wiki page
You can find more info on their wiki.
It sounds like you either need to use their Raspian image, or install the driver for this display on your existing Raspian install:
wget http://www.waveshare.net/w/upload/7/73/LCD-show.tar.gz
tar xvf LCD-show.tar.gz
cd LCD-show/
sudo ./LCD35-show

Filed to run Contiki applications in QEMU

I was trying to play with several tiny operating systems in an emulator but got stuck with Contiki in QEMU. Ideally the compiled executable should be run as a kernel in QEMU. For all OS's I was playing with I used this simple command to run executables in QEMU:
qemu-system-platform -nographic -kernel compiled_executable
In the case of Contiki, QEMU freezes regardless of any target platform the executables are compiled for, even for target platform "native", which according to the documentation, is built with "x86 gcc".
I also tried ARM-based platforms with the same freezing issues. If I specify a correct CPU model (e.g. cortex-m3 for cc2538dk), I received a segmentation fault instead.
I am wondering if I was missing any steps to cause the QEMU to freeze. Does it mean that the compiled executable cannot be treated as kernels (yet), unless I provide some QEMU-specific codes to initialize QEMU as a "board" for Contiki?
The native platform is used to build a "natively" (i.e. on Linux or other OS) executable image of Contiki - an userland app, rather than an OS kernel.