Good day all!
I have an issue in code that I cannot find.
See here
Is it possible to setup GDB to see what the UART is getting in incoming serial data?
Thanks!
I'd suggest you to modify UART driver for Linux kernel and inside of this driver dump the incoming data. The GDB works in user space but you need to do this on the lower level - in UART driver. GDB has no access to registers of the physical device as the UART is.
Related
I am working on a project with SAMA5D3-xplained board with CortexA5 processor and embedded Linux. I would like to send and receive some data via UART during U-Boot is running and before a kernel is loaded to the RAM. I have no idea what I should do. Should I add the second UART to U-Boot device tree source file? Should I change something in a board configuration file? Do you have any ideas on what steps I should take to achieve my goal? Thank you in advance for any help.
EDIT
I would like to use UART from U-Boot C code, not from U-Boot commands. I need to communicate with one of a peripheral device before the kernel is loaded to the RAM.
I assume that you are using the upstream U-Boot from https://source.denx.de/u-boot/u-boot.git.
The device-tree arch/arm/dts/at91-sama5d3_xplained.dts already contains the definitions for six different uarts called serial0 - serial5. serial0 is set in the /chosen node as the standard serial connection. You should be able to see all six devices with the 'dm tree' command.
The currently used UART can be switched by setting the stdin and stdout environment variables.
If you do not want to switch these variables, because you still want output on the default UART you will have to access the device driver. Unfortunately drivers/serial/serial-uclass.c does not yet export functions for this. But _serial_putc(), __serial_getc(), and __serial_tstc() should give you an idea how this is done.
Is it possible to write serial driver in userspace, yet, have the device appear as regular serial driver /dev/ttyS0 in the system ?
The full story is that we have a pci express fpga, and there are several devices behind the pci express fpga: serials, canbus, i2c, mdio, etc.
I thought to implement it as uio_pci_generic, yet the serial driver is a bit problematic because we rather that it will appear as regular serial /dev/ttyS0.
If the above is not possible: Is it possible to implement some of the pci devices in kernel (serial) and others in userspace ? Is it problematic in terms of interrupt ?
Thanks for any idea.
Yes, you can do this using a pty. The user mode driver opens the master end of the pty and the application that wants to use the serial port opens the slave end. Search for Linux pty.
Everywhere where you need to use interrupts you need to write code for kernel space not user space. Interrupt handlers need to be serviced in atomic context and user space is not able to provide atomic context. Second thing - if you need to write HAL layer - it also has to be written in kernel space.
I am having troubles with a Linux kernel panic which I need to investigate further. When it happens, the kernel panic output always goes to the display adapter only and is shown on the monitor.
I need to have the kernel panic output to a serial USB console, not only on the display adapter. In the situation where the panic happens there is no monitor available.
I have a serial USB console working, can log in from there and I also see some kernel messages there sometimes. However when I provoke a kernel panic with echo c > /proc/sysrq-triggerthe kernel panic output is just on the display adapter visible, not on USB console.
I am using Debian 8 with kernel 4.14. ttyUSB0 is running with systemd.
Kernel cmdline contains ... console=tty0 console=ttyUSB0,9600n8
What I can do to get the kernel panic logged to USB serial port?
I don't think that it is possible in Linux to dump any message after kernel panic on USB console. You may try to configure ethernet console but in this case I also doubt if it will dump anything during panic. If I'm not wrong you will be successful only with serial UART console.
I guess you only need access to the kernel dump information somehow, without having a monitor attached. You can set up kdump to automatically save a kernel dump image to disk which you can then later have look at. Here's a tutorial on how to setup this on Debian: https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
I am using mcp3021.c file for Microchip MCP3021 IC. My module's init and exit functions are replaced with module_i2c_driver(mcp3021_driver), But I don't see the driver register print in my Kernel log when I ran the code. Can anybody please help me with this ?
First thing which kernel version you are using ? because this macro is introduced in Linux kernel after version 3.3 .
So if your are using kernel version below this you should actually get error while compiling the kernel.
You have verify are few things to make it work,
Ensure that I2C device is properly mounted in hardware.
Confirm that your device is not in reset state.
Ensure that in your device tree you are using the appropriate I2C bus and driver id is properly configured.
Check your kernel configuration(.config) that your driver is enabled.
I2C Probe will be called only if above all conditions are met.
We are creating small system which has GPS receiver and PC. We want to test my GPS receiver, We do not want to go for a driver on the first go. First I would like to test my circuit works or nor. GPS IC has been set to output NMEA sentence. We want a program which just reads data from USB port and print it on the screen.
Can we write something like this easily ? Do we have any open source tool which will achieve this purpose ?
Platform : Windows 7
All devices need a driver, so I'm going to interpret your question as "how can I read NMEA data from my GPS using only drivers provided by the OS, so I don't have to write my own?"
If the GPS chip has a USB interface, then you should have gotten a driver with it. But most GPS chips have a UART interface which in your case sounds like it is connected to a separate USB-UART conversion chip. That conversion chip most likely came with a driver as well, but if not, you could jumper the reset pin of the converter chip, disabling it, and then attach a TTL/RS-232 level converter (available off-the-shelf) to the UART traces and then to your computer's serial port.
Unless you suspect that the driver for the USB-UART converter is causing problems, I wouldn't bother.
Anything connected via USB is a device. Devices require a device driver, period.
You might be able to get away with an existing driver built into Windows. This is how USB memory keys work for example - they present a generic device that looks like a removable disk, and Windows already includes the drivers for generic removable disks.
You would need to check the documentation for your device to see if it can emulate a device which already has drivers. Otherwise you must install the company's drivers, or you're out of luck.
Have a look at libusb. You should be able to read the data with that and a little code. (Yes, it's a driver. I take the question to mean "without writing a driver".)
You need a device driver for your device. Unless Windows already have a class driver for the device.
For USB devices on Windows 7 you can write a user-mode driver, see UMDF.