I am a beginner in kernel porting. I am trying to port Linux kernel (version- 4.9.22) on Custom SoC (cpu = arm1176jzfs based) for custom evaluation Board. I am having ARM Prime cell pl011 UART in my SoC. And it is physically mapped to 0x5800_1000 address. While i am trying to use it as Debug UART, kernel is asking for its virtual Address. How should i configure this option.
i.e:
-> Kernel low-level debugging functions
-> kernel low-level debugging port (Kernel low-level debugging on via ARM Ltd PL01x Primecell UART)
(0x58001000) Physical base address of debug UART
(??) Virtual base address of debug UART
Thanks,
Vivek T.
If you have a debugger, then you can certainly debug why your kernel is not booting up.
You can watch this steps:
-In Kernel configuration, enable CONFIG_DEBUG_INFO (Kernel Hacking -> Compile-time checks and compiler options)
-Compile the kernel
-From the debugger software, load the symbols from the elf. The command varies from one debugger to another
-Find symbol "log_buf", and chose option to "Display memory as dump"
So I think the kernel logs stored in the buffer. Maybe it can help you :)
Standard UART addresses are:
Standard port addresses are:
COM1 0x3F8 (1016)
COM2 0x2F8 (760)
COM3 0x3E8 (1000)
COM4 0x2E8 (744)
Additional port addresses are:
COM5 0x3E0 (992)
COM6 0x2E0 (736)
COM7 0x338 (824)
COM8 0x238 (568)
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
I'm trying to write a PCIe driver for an ARM machine (Cavium ThunderX2). I'm working with Xilinx Alveo FPGAs. Our work involves migrating pages between heterogeneous nodes (x86 and ARM) and the driver takes care of the DMA between the host and the FPGA, and handles the device interrupts.
The DMA doesn't work (From Device/To Device) and I get "ARM SMMU v3.x 0x10 event occurred" errors. I tried disabling the SMMU (recommended by some threads in the NVIDIA community - https://forums.developer.nvidia.com/t/how-dma-works-in-arm-the-dma-stopped-working-with-our-pci-driver/53699), but that leads to a protection issue ("RAS Controller stopped"), and the system hangs.
I use dma_map_single APIs from dma-mapping.h to convert the virtual address to a DMA-capable bus address. Would dma_alloc_coherent make a difference? (Of course, I'll try this out)
I'm unable to figure out the problem. Is this is a PCIe driver issue or an issue with the device or is there a fix/patch available for ARM PCIe DMA ops? Any help would be appreciated!!
Thanks,
Narayan
Error snippet
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.
I compiled the xilinx pcie driver using this as a starting point.
https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
and then instead of using this to the prebuilt image:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
I copy kernel file .ko directly to the image as:
fs#fs:/opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/met/0.1-r0$ scp xpcie.ko root#172.17.100.101:/lib/modules
then when I insert this kernel module with hardware connected:
root#imx7d-phyboard-zeta-001:/lib/modules# insmod /lib/modules/xpcie.ko
Base hw val 0
Base hw len 0
BAR0 of 0K
BAR0 of 0M
xpcie: Init: Could not remap memory.
insmod: ERROR: could not insert module /lib/modules/xpcie.ko: Operation
not permitted
root#imx7d-phyboard-zeta-001:/lib/modules#
What is the reason?
Is it not allowed to copy kernel directly on already built image like this?
Futhermore when I add it to the image as in local.conf file:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
again built and load the image, it is not available in /lib/modules/ directory. Where i can find it? or using other 3 methods will be better?
Using insmod to install the driver is the right thing to do. It does not seem to be the cause of the problem you are seeing.
When you build the driver, the .ko file will usually be in the source directory where you built it, unless you make modules_install.
Getting back to the actual problem:
Looking at the driver source, the message "Could not remap memory" indicates that the driver could not map the PCIE memory region into the kernel address space.
Looks like the base address registers were not configured. On all the machines I use, the BIOS has to configure the base address registers before Linux can use the device.
We program the FPGA, reboot the machine, and then load the driver and use the FPGA. Did you try this? Does your FPGA show up with lspci?
Once the FPGA is programmed, if the PCIE configuration does not change you can tell the kernel to rescan and it will write the base address registers with the same values.
I want to capture a signal in the kernel when it detects power over ethernet is connected.
I don't have gpios to do this business.
I am working on the atheros chipset based access point. It has Realtek RTL8363SB ethernet module. Is there any mechanism/interrupt/signal/api in kernel which detects from where it is getting power?
I have enabled CONFIG_POWER_SUPPLY while building kernel V 2.6.36
Thanks.