I created an image for raspberry pi zero 2 w using buildroot,
Also added overlay gpio-ir in config.txt but not able to receive ir signal.
No logs are printed for gpio in dmesg.
No devices are showing in /proc/bus/input/devices
Can anyone help?
I found solution my self.
Actually buildroot is not start gpio-ir-recv module at boot time.
So we need to load module manually at boot time.
We can load module by this command
modprobe gpio-ir-recv
So i have created one service to load module in /etc/init.d
Related
I installed this module and have the corresponding RaspberryPi HAT(Waveshare Rpi 35A) attached to my Raspberry Pi.
After running modprobe ili9486 in the terminal:
In /sys/module, I see the device.
In /dev/ and /dev/spi/, I don't see anything with ili9486 in it's name.
How do I send a command to the device?
In specific how do I send the command to ili9486_probe, which will in turn, send the command to waveshare_command? My goal is to get the command to reach waveshare_command?
I didn't install the dtoverlay on the Waveshare github because I do not want touch screen features. I just want to write to the screen.
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
I am learning about u-boot and how this works in the Raspberry Pi system.
This is what I understood so far:
The first stage from the RPI cannot or should be modified. In this stage the BootROM simply loads the bootloader from the flash EEPROM.
In the second stage the EEPROM boot loader finds and loads start.elf, whose task is to load the kernel. It first reads "config.txt" which contains a kernel parameter. This is where u-boot is "injected".
kernel=u-boot.bin
U-boot can then in turn load the actual kernel. For a CM4 this would be "kernel7l.img".
I would be super satisfied with this knowledge, but in practice I have (possibly) seen other ways of integrating u-boot. I am here referring, for example, to Yocto recipes for the CM4 (meta-raspberrypi / u-boot). The boot directory of such an image contains: boot.scr, uboot.env, and uImage.
The readable part of boot.scr specifies that uImage will be loaded:
value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
if test ! -e mmc 0:1 uboot.env; then saveenv; fi;
bootm ${kernel_addr_r} - ${fdt_addr}
config.txt does not contain a kernel parameter.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot? boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
is uImage just another name for u-boot.bin?
In this scheme how does u-boot know it must load "kernel7l.img"?
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
Thank you very much for your help!
The boot.scr script is read by U-Boot.
fatload mmc 0:1 ${kernel_addr_r} uImage loads a kernel in deprecated U-Boot specific format which can be created with the mkimage command.
The bootm ${kernel_addr_r} - ${fdt_addr} command receives the addresses of uImage and the device tree. The address for the initrd is left out ('-'). bootm starts the kernel and passes the device tree address to it.
Adding kernel=u-boot.bin to config.txt is the correct way to invoke U-Boot on a Raspberry.
Distributions like Suse and Fedora prefer to boot Linux via GRUB on the Raspberry using U-Boot's bootefi command.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot?
The kernel=... parameter in the config.txt is an optional parameter that specifies an alternate (kernel) filename to load by the EEPROM boot program.
The default filename to load from the boot partition depends on the RPI version.
According to RPi documentation, the default kernel filename on the Pi 1, Pi Zero, and Compute Module is kernel.img, on the Pi 2, Pi 3, and Compute Module 3 it is kernel7.img, and on the Pi4 it is kernel7l.img
If "there is no kernel parameter", then inspect the kernelx.img file; what are the contents?
boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
Incorrect, boot.scr is not "run before u-boot.bin".
The file boot.scr contains script that can be interpreted by U-Boot.
(The executable image for U-Boot is the u-boot.bin file.)
is uImage just another name for u-boot.bin?
No, those are two distinct filenames with completely different uses.
The u-boot.bin file is the executable image for U-Boot.
A uImage file is a kernel image with the U-Boot wrapper for identification and verification. The U-Boot wrapper/header can be used for a variety of objects such a U-Boot script or a standalone executable besides a kernel image.
See Image vs zImage vs uImage
In this scheme how does u-boot know it must load "kernel7l.img"?
U-Boot does not have that directive (in this situation).
According to the boot.scr file that you posted, the booting sequence that U-Boot will perform is to load the uImage from the boot partition.
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
As mentioned in your post and the other answer, an explicit kernel=u-boot.bin in the config.txt would be the obvious/preferred method to invoke U-Boot.
Otherwise, IDK. Today's alternative could be tomorrow's deprecated method.
I have been trying to locate a working library for the MSR605X magnetic card reader/writer. At time of writing, I have tried five separate libraries. Only two of these were explicitly for the 605X the other three were for the older 605. All the libraries I have tried either did nothing at all or errored before completing a command (can't figure out the errors either).
I am running Raspberry Pi OS 32 bit on a Raspberry Pi 3 B+ the MSR605X communicates via a USB connection.
So far the library that seems to be most complete is: https://pypi.org/project/msrx/
However, I can not get this library to read or write (either nothing happens or I get a Serial exception "cannot reconfig port).
Any help or links to documentation for this reader is welcome.
EDIT: Adding the commands ran with the above library
msrx -D /dev/input/event4 read
msrx -D /dev/input/jso0 read
The -D is to specify the device path (default is /dev/ttyUSB0 which doesn't exist on my system). I obtained the above two paths by searching for USB serial devices then matching the search result to the device ID which I obtained from lsusb.
Running these commands results in a serial exception (could not reconfig port) which I assume means that I have the wrong device path. I have also checked for any tty* device paths that are changed when I plug in the reader. I consistently get a permission denied error whenever trying to run the above commands with a tty* device path (I am root on this system).
msrx author here — MSR605 requires an external 9V power injected into its cable (via the barrel jack port), otherwise it won't power up properly.
I am using custom Linux Kernel built through Yocto. I generated sdimg and try to boot it using an SDCARD and it boots perfectly fine. Here along with the Kernel I also use INITRAMFS files. Using config.txt and cmdline.txt file in partition 1, I tell the kernel to load my INITRAMFS file. This procedure is working fine.
Now, I am trying to net boot my Raspberrypi. For this I have another PC which has DNSMASQ installed and it acts as DNS server. I have all the required files in my /tftpboot directory. When I turn on the client RPI, it gets all the files from the server except my INITRAMFS file. I have added the initramfs file name as shown below in the config.txt, but still it is not being requested by my PI. How to make the RPI request for the INITRAMFS file? It just boots up the kernel7.img and thats it !
//appended the following lines to config.txt
ramfsfile=myramfs.cpio.gz
initramfs myramfs.cpio.gz followkernel
Please note that I am not using u-boot.
I was able to resolve the issue. When we do TFTP booting, the first file requested by Raspberry pi(Rpi) is startx.elf, this will be run on the GPU core. Next file that is requested is config.txt. For some reason, if I append the above 2 lines it doesn't work. I read in one of the raspberry pi forums that if the config.txt file is above some size limit, it will be ignored. So I cleared the config.txt file and added just these lines, and voila! Now my initramfs file is requested by the PI and boots successfully :)