I am working on Zedboard Zynq 7020. I have booted the Linux via SD card through Zedboard. The linux display can be shown onto the monitor via VGA cable. But I cannot connect that linux to internet. Linux is not detecting any wireless network as well. I plugged the one end of LAN cable into Zedboard and other into PC. I tried to write ifconfig into the terminal of linux and I get this message : root@localhost:˜# ifconfig eth1 Link encap:Ethernet HWaddr 00:11:22:33:44:55 inet6 addr: fe80::211:22ff:fe33:4455/64 Scope:Link Here I cannot see this sort of thing: "inet addr:10.1.1.164 Bcast:10.1.1.255 Mask:255.255.255.0" As it is essential for detecting the ip address of PC. Please guide and suggest me the solution. Thanks

I'm having trouble programming my DE1-SoC from the Quartus Programmer. The board is powered and connected correctly and I've managed to find and program it before, multiple times, but even then Quartus was very inconsistent in finding it. I tried to understand under what circumstances it finds the board but I really didn't do anything special in those times. Under Hardware Setup --> Hardware Settings --> Currently selected hardware there only appears "No Hardware", and the DE1-SoC isn't listed: I don’t manage to take a screenshot when the dropdown is opened, but the only option is “No Hardware” and the board isn’t listed.

$ ~/intelFPGA_standard/24.1std/quartus/bin/quartus_sh --version
Quartus Prime Shell
Version 24.1std.0 Build 1077 03/04/2025 SC Lite Edition
Copyright (C) 2025 Altera Corporation. All rights reserved.

$ uname -a
5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/udev/rules.d/51-usbblaster.rules
BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6810", MODE="0666"

$ cat /etc/modprobe.d/DE1-SoC.conf
alias usb:v09FBp6810* ftdi_sio
install ftdi_sio /sbin/modprobe -i ftdi_sio && /bin/echo 09fb 6810 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

$ lsusb
Bus 001 Device 006: ID 10c4:ea70 Silicon Labs CP2105 Dual UART Bridge

I run Quartus using sudo. I tried Terasic support but they suggested to reinstall, I find it weird because the hardware will occasionally (very very rarely, and I don't know what determines it) be found. I'm still in the state where I use simple, prepared projects, not something custom or fancy of my own, so I'm not deviating from the basic defaults. For example, I may run quartus and go Open Project --> ~/DE1-SoC_v.6.0.0_HWrevH_SystemCD/Demonstrations/FPGA/my_first_fpga/my_first_fpga.qpf (Which is a trusted basic demonstration by Terasic) and successfully compile. I would do the same thing on another educational project. In any case, the software would detect the hardware on occasions that seem random, and very scarce. This is very frustrating because it keeps me from moving forward. Any help would be much appreciated

I'm working on booting U-Boot from the SPI flash memory of an Arty A7 100T FPGA and encountering an issue where U-Boot does not execute after power-on **Issue** U-Boot does not produce any output on the UART console when booting from flash **Setup:** 1. I have built U-Boot for my RISC-V-based system and flashed it to SPI flash at address 0x0C000000 2. The expectation is that, upon power-on, the bootloader should be loaded from flash into RAM and executed **Observations:** 1. After flashing the bitstream into the FPGA, the board powers on, but U-Boot does not boot. I see no output on the UART console. 2. To test the flash execution path, I flashed a small UART print test program to 0x0C00 0000, which worked correctly, confirming that the flash itself is accessible. I verified the U-Boot binary in flash, and it appears to be written correctly 3. However, if I load the same U-Boot image directly into RAM using GDB, it boots successfully, indicating that the image itself is functional 4. After flashing U-Boot into the flash, I verified that the contents were written correctly **What I need help with:** 1. What could be preventing U-Boot from executing when loaded from flash? 2. What debugging steps can I take to analyze the issue further? 3. Could this be related to missing relocation, boot address misalignment, or an issue with the OpenSBI handoff?

I am working with an Intel SoC with a Hard Processor System (HPS), an Arm 64 core, and an FPGA fabric with a Nios soft processor. I would like to implement message passing between these two processors using RPMsg. Intel has a hardware mailbox IP which we have connected appropriately, and dual-port on-chip RAM has been instantiated in the hardware design and connected to the both the HPS and Nios. My understanding is that I need to develop a *remoteproc* driver which incorporates the mailbox notification setup, and more importantly, creates the resource table and instantiates the appropriate Virtio structures to enable the IPC. Overall, I would like: - Statically allocate the necessary virtio resources (vrings, message buffers) in the shared OCRAM. - Incorporate the platform specific mailbox driver (drivers/mailbox/mailbox-altera.c). - Create an interface for RPMsg (probably a char device, expose a device file to userspace for reading and writing). I have been digging in the kernel source, and I can't figure out what parts of this framework are platform agnostic and available for my use, and which components are board specific. My questions are: 1. Since I don't actually need to perform any life cycle management of the remote processor (Nios), I just need remoteproc to handle the virtio resources. Which rproc_ops do I need to implement? 2. How would I go about allocating my virtio resources statically in specific physical memory regions within my remoteproc driver? Do I need to make carveouts in the resource table, or is there another way to just force the virtio resources to be in the OCRAM? How is this communicated between the processors? 3. Assuming I have my remoteproc set up sufficiently, can I use /drivers/rpmsg/rpmsg_char.c off the shelf? Or do I need to create a different RPMsg client? 4. In general, what kernel source files in this whole framework are platform agnostic (and available for me to use)? I can't tell The Nios will be running a RTOS with OpenAMP or rpmsg-lite, but I'll cross that bridge after I deal with the kernel side. Any guidance would be greatly appreciated!

I'm trying to get the Linux kernel (and system as a whole) to sync to a monotonically incrementing clock from a FPGA register in memory. The clock is 64-bits wide and divided into two 32-bit sections: a 32-bit seconds register and a 32-bit nanoseconds register which increments in 10s of nanoseconds. I created an initial implementation based off of the ARM global timer thinking this would be a good starting approach. The driver successful registers (in kernel, not a kernel module), and I can switch the clocksource to the driver, but the timing is off and I get quite a few panics about the scheduler not executing. My goal is that I can use the typical POSIX APIs to set and get the time from a userspace application without having the userspace involved in reading a register in memory for the time. Is using the clocksource the right tool for this job? Or do I need something else?

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* Meta Information */
MODULE_LICENSE("GPL");

#define FPGA_TIME_DRIVER_NAME "fpga_time"


/* 32-bit seconds register */
#define FPGA_TIME_ADDR_CTRL_TIME_SECONDS         0x00
/* 32-bit subseconds register incrementing in 10s of nanoseconds
 */
#define FPGA_TIME_ADDR_INFO_TIME_SUBSECONDS      0x04

/* Rate at which the time is updated (10ns) */
#define FPGA_TIME_TIMER_TICK_100MHZ              (100 * 1000 * 1000)
/* Rating/priority of the clock source compared to other clocks.
 * Higher rating means it will be preferred over other clock sources.
 */
#define FPGA_TIME_TIMER_RATING                   (100)

static u64 FPGA_TIME_clocksource_read(struct clocksource *cs);

/**
 * @brief The global timer structure that holds the clocksource info and the
 * base register address for reading from memory.
 */
struct clocksource_fpga {
	void __iomem *reg;
	struct clocksource clksrc;
} g_timerInfo = {
	.clksrc = {
		.name = FPGA_TIME_DRIVER_NAME,
		.rating = FPGA_TIME_TIMER_RATING,
		.read = FPGA_TIME_clocksource_read,
		.mask = CLOCKSOURCE_MASK(64),
		.flags = CLOCK_SOURCE_IS_CONTINUOUS
	}
};

static u64 _FPGA_TIME_clocksource_read(void)
{
	u64 counter;
	u32 seconds, subseconds;

	seconds = readl_relaxed(g_timerInfo.reg + FPGA_TIME_ADDR_CTRL_TIME_SECONDS);
    subseconds = readl_relaxed(g_timerInfo.reg + FPGA_TIME_ADDR_INFO_TIME_SUBSECONDS);

	counter = seconds;
	counter <<= 32;
	counter |= (subseconds << 1);

	return counter;
}

static u64 FPGA_TIME_clocksource_read(struct clocksource *cs)
{
	return _FPGA_TIME_clocksource_read();
}

/**
 * @brief Linux scheduler clock read.
 * @return The current time as a 64-bit integer.
 */
#ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
static u64 notrace FPGA_TIME_sched_clock_read(void)
{
	return _FPGA_TIME_clocksource_read();
}
#endif

/**
 * @brief Registers the timewarp clocksource and if applicable, registers with
 * the scheduler.
 * @return Returns 0 on success, errno otherwise.
 */
static int timer_clocksource_init(void)
{
	int ret;
#ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
	printk(FPGA_TIME_DRIVER_NAME " - Registering the scheduler...\n");
	sched_clock_register(FPGA_TIME_sched_clock_read, 64, FPGA_TIME_TIMER_TICK_100MHZ);
#endif
	ret = clocksource_register_hz(&g_timerInfo.clksrc, FPGA_TIME_TIMER_TICK_100MHZ);
	printk(FPGA_TIME_DRIVER_NAME " - Registering the clocksource returned = %d\n", ret);
	return ret;
}

/**
 * @brief Device driver probed when detected in the device tree.
 * This reads in all the property values and initializes the driver.
 * 
 * @param pdev The plaform device which contains the information about the driver.
 * @return Returns 0 on success, errno otherwise.
 */
static int __init FPGA_TIME_register(struct device_node *np)
{
	printk(FPGA_TIME_DRIVER_NAME " - Loading the driver...\n");

    /* Get the base address and size. */
	g_timerInfo.reg = of_iomap(np, 0);

	return timer_clocksource_init();
}

I was barely able after much effort to get this to install 9 or so months ago, now it doesn't install on the same platform with a new update/upgrade. Here's the software version info: ubuntu@BDv4-10031:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy ubuntu@BDv4-10031:~$ After installing the long list of imports and dependencies and successfully navigating those in the successful past: sudo apt-get -y install cmake libglpk-dev sudo pip3 install meson pytest jupyter pandas numpy pvlib matplotlib scikit-learn sudo pip3 install tensorflow gym cvxpy cvxpyanalyzer vpython sudo pip3 install scip scipy cylp cbc ecos glpk copt cvxopt clarabel glop cplex xpress sudo updatedb # cd to the directory /site-packages/cvxpy/ pytest And I did try this without sudo pip3, makes no difference, the problem is package versioning. I got this in retrying after cvxpy install failed: ubuntu@BDv4-10031:~$ sudo pip3 install cvxpy Collecting cvxpy Using cached cvxpy-1.4.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (1.1 MB) Collecting ecos>=2 Using cached ecos-2.0.12.tar.gz (142 kB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... done Requirement already satisfied: numpy>=1.15 in /usr/local/lib/python3.10/dist-packages (from cvxpy) (1.26.2) Collecting osqp>=0.6.2 Using cached osqp-0.6.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (294 kB) Collecting scipy>=1.1.0 Using cached scipy-1.11.4-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (32.9 MB) Requirement already satisfied: pybind11 in /usr/lib/python3/dist-packages (from cvxpy) (2.9.1) Collecting clarabel>=0.5.0 Using cached clarabel-0.6.0-cp37-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (1.4 MB) Collecting scs>=3.0 Using cached scs-3.2.4.tar.gz (1.5 MB) Installing build dependencies ... done Getting requirements to build wheel ... done Installing backend dependencies ... done Preparing metadata (pyproject.toml) ... error error: subprocess-exited-with-error �� Preparing metadata (pyproject.toml) did not run successfully. ��� exit code: 1 ������> [2 lines of output] ('\x1b[31m',)meson-python: error: Could not find ninja version 1.8.2 or newer. [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed �� Encountered error while generating package metadata. ������> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. ---------- Then I tried to install the missing meson: ubuntu@BDv4-10031:~$ sudo pip3 install meson-python-1.8.2 ERROR: Could not find a version that satisfies the requirement meson-python-1.8.2 (from versions: none) ERROR: No matching distribution found for meson-python-1.8.2 ubuntu@BDv4-10031:~$ sudo apt install meson ninja-build Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: libflashrom1 libftdi1-2 Use 'sudo apt autoremove' to remove them. The following NEW packages will be installed: meson ninja-build 0 upgraded, 2 newly installed, 0 to remove and 6 not upgraded. Need to get 624 kB of archives. After this operation, 3675 kB of additional disk space will be used. Get:1 http://ports.ubuntu.com/ubuntu-ports jammy/universe arm64 ninja-build arm64 1.10.1-1 [105 kB] Get:2 http://ports.ubuntu.com/ubuntu-ports jammy/universe arm64 meson all 0.61.2-1 [519 kB] Fetched 624 kB in 1s (474 kB/s) Selecting previously unselected package ninja-build. (Reading database ... 275117 files and directories currently installed.) Preparing to unpack .../ninja-build_1.10.1-1_arm64.deb ... Unpacking ninja-build (1.10.1-1) ... Selecting previously unselected package meson. Preparing to unpack .../meson_0.61.2-1_all.deb ... Unpacking meson (0.61.2-1) ... Setting up ninja-build (1.10.1-1) ... Setting up meson (0.61.2-1) ... Processing triggers for man-db (2.10.2-1) ... Scanning processes... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. Failed to check for processor microcode upgrades. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. No VM guests are running outdated hypervisor (qemu) binaries on this host. ---------- Now retried installing cvxpy.py: ubuntu@BDv4-10031:~$ sudo pip3 install cvxpy Collecting cvxpy Using cached cvxpy-1.4.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (1.1 MB) Requirement already satisfied: pybind11 in /usr/lib/python3/dist-packages (from cvxpy) (2.9.1) Collecting scipy>=1.1.0 Using cached scipy-1.11.4-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (32.9 MB) Collecting scs>=3.0 Using cached scs-3.2.4.tar.gz (1.5 MB) Installing build dependencies ... done Getting requirements to build wheel ... done Installing backend dependencies ... done Preparing metadata (pyproject.toml) ... error error: subprocess-exited-with-error �� Preparing metadata (pyproject.toml) did not run successfully. ��� exit code: 1 ������> [3 lines of output] ('\x1b[31m',)meson-python: error: Could not find meson version 0.63.3 or newer, found 0.61.2 ('\x1b[31m',)meson-python: error: . [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed �� Encountered error while generating package metadata. ������> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. ubuntu@BDv4-10031:~$ sudo pip3 uninstall meson Found existing installation: meson 1.3.0 Uninstalling meson-1.3.0: Would remove: /usr/local/bin/meson /usr/local/lib/python3.10/dist-packages/meson-1.3.0.dist-info/* /usr/local/lib/python3.10/dist-packages/mesonbuild/* /usr/local/share/man/man1/meson.1 /usr/local/share/polkit-1/actions/com.mesonbuild.install.policy Proceed (Y/n)? y Successfully uninstalled meson-1.3.0 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv ---------- Tried uninstalling meson and reinstalling cvxpi, same error. My worry is that the KV260 platform with its dependence on petalinux for getting FPGA IP blocks to run, is being deprecated in the new, sleek petalinux-free KR260 platform and when things get harder to install on Ubuntu, it raises my platform end-of-life fears.

I have been working on a Altera DE1-SoC Development Board for 8 months. The system I was working on includes a Cyclone V FPGA chip, particularly the 5CSEMA5F31C6N. It was running an embedded Linux operating system on chip. All was well and development was on-going. Two weeks ago, a new custom board was put together by a hardware engineer in the company. The design and components were mostly similar to that of the Development Board. All HPS related pins are wired the same way, with one main difference being that the default console port was UART1 instead. That issue has since been resolved and I now am able to receive the U-boot and Kernel messages through UART1. But the system did not completely boot. I have pinpointed this to multiple reasons. Firstly, I had an init.d script that would export the GPIO LEDs and create a sysfs file. Exporting the gpio pin works, however, changing the direction, or changing the value, or reading from it, causes the system to freeze. I disabled that function on the init.d script and rebooted the device. This time the boot failed on another init.d script line. This line was going to change the value of a register in the lightweight bridge. The command was devmem 0xFF200XXX 32 1, with XXX being the specific register. I tried using devmem on all bridges but all attempts would freeze Linux. I tried using devmem on the UART register of HPS, on the SDCard register of HPS (referenced [here](https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html)) , and it does not freeze. I can verify that the bridge is enabled by reading the state sysfs file of each bridge: [fpga_bridge state returns enabled](https://i.sstatic.net/pqyha.png) I can also verify that the bridges are linked to the driver from this dmesg output: [dmesg output](https://i.sstatic.net/EQrDY.png) I have enabled all three bridges in the hps configuration using Quartus Platform Designer. I also have the following lines in my u-boot.scr:

fatload mmc 0:1 $fpgadata soc_system.rbf;
fpga load 0 $fpgadata $filesize;
setenv fdtimage soc_system.dtb;
run bridge_enable_handoff;
run mmcload;
run mmcboot;

I have also attempted enabling the bridges through the U-boot command line following [these instructions](https://www.rocketboards.org/foswiki/Documentation/GSRD131ProgrammingFPGA) . However, I am unable to write anything into $l3regs: [writing into l3regs](https://i.sstatic.net/s1pvY.png) I am building the OS using Buildroot 2016.05 with a 4.4 Linux Kernel. To create the .rbf, .dts, .dtb, preloader-mkpimage.bin, and u-boot files, I am using SoC EDS 18.1 [Build 625]. I have run out of things to try. I would consider the issue solved if I am able to toggle an LED on and off from the Linux OS, using sysfs files. Assuming that the hardware is correct, what else could be the cause and how do I fix it?

I am trying to read FPGA memory on a Xilinx Zynq board (zc702) as part of porting an RTEMS driver to Linux. I am using the devmem2 and mmap_test programs that I cross-compile for the board using the Yocto cross-compiler. The board has 1 GB of normal memory. This means that any read between 0x0 and 0x40000000 returns valid memory. The problem is, however, when reading from 0x7AA00000, the kernel crashes immediately without even printing a kernel panic message to the terminal (serial port with minicom and ssh). I even wrote small sample kernel modules to read from that address and use kprint, but it results in the same crash. Since the driver works with RTEMS, the physical memory address has been verified to be correct. What steps have to be taken to be able to read from the FPGA memory/registers without Linux crashing?

I'm currently working on systems that include FPGAs. We've various IP cores that support the AXI-Bus . To communicate with the IP cores of PL *(programable logic)*, we need to map them onto the address space of the PS *(processing system)*. For example, for the widely used Zynq PS the address space is as follows *(UG585 - Section 4.1: Address Map) * - **0x0000_0000 to 0x7FFF_FFFF:** Mapped to the physical memory. Either external DDR or on-chip memory - **0x8000_0000 to 0xBFFF_FFFF**: Mapped to the PL explained above - **0xE000_0000 to 0xFFFF_FFFF:** Various other devices on the chip As you can see, only the first 1GB of the address space is reserved to the physical memory, and the rest is occupied by the devices either in PL or PS. So, if possible, the virtualization range can be applied only for the first 1GB to allow faster access to devices on the chip by skipping the MMU. I know that by doing such a modification we allow any kind of process to access the physical devices of the system without any control of its privileges. So, the questions are - Is it possible to partially virtualize the physical address space? - If it is possible, would it be rational to do it?

I am developing an embedded Linux system with a 24 bit LCD display. I use terasic linux-socfpga to compile the kernel and I want to use the altfb driver to show the desktop in LCD. For that, I copied the Linux driver(https://github.com/coliby/terasic_MTL/blob/master/drivers/video/altfb.c) to my kernel code and then I successfully compiled the code. But the display did not work correctly. After several days of trial, I succeeded to display the desktop but its pixel values are not shown correctly. Finally, I succeed to display something like in the image as shown below. for that, I changed the code from writel(fbdev->info->var.xres * fbdev->info->var.yres/(fbdev->mem_word_width/32) to writel(fbdev->info->var.xres * fbdev->info->var.yres/(fbdev->mem_word_width/24) But the display showed like the attached image. Any help to solve the issue is appreciated. https://rocketboards.org/foswiki/Projects/TouchScreenLCDForAlteraSoC https://github.com/coliby/terasic_MTL/blob/master/drivers/video/altfb.c

I’m working with a fpga expansion card (pci-e connected; terasic de10 pro). My problem is whenever I don’t use the card for a couple of minutes it stops completely and only a complete shutdown can reawaken it. My driver tells me something like “device refuses to wake up from D3”. I assume the pci-e ip on the fpga has trouble handling power states(?) Has anyone an idea how to prevent the card from sleeping? Or has an idea why this is happening in the first place?

EDIT: Is there a better stackexchange site I should put this on? I am trying use the DDR4 connected to the FPGA side of a zynq ultrascale chip, specifically on Xilinx's devboard zcu102. I am using Vivado's MIG to generate the controller and connect to the HPM0 AXI port of the main processor. The memory is 0x2000_0000 long and mapped to physical address 0x4_0000_0000. The problem I am having is when accessing memory unaligned. I believe it to be some misconfiguration in the MMU due to a missing detail in the device tree. One thing I know is that this arm (A53) is supposed to be able to turn unaligned accesses into multiple access to the memory where necessary. My getting a bus error is telling me that the MMU is misconfigured in some way but I'm not sure how. The device tree is too long to put here, so I will put what I think are the most important parts directly in here and the rest as a pastebin . amba_pl@0 { #address-cells = ; #size-cells = ; compatible = "simple-bus"; ranges; ddr4@400000000 { compatible = "xlnx,ddr4-2.2"; reg = ; alignment = ; }; PERIPHERAL@ff380000 { compatible = "xlnx,PERIPHERAL-1.0"; reg = ; }; PERIPHERAL@ff990000 { compatible = "xlnx,PERIPHERAL-1.0"; reg = ; }; }; aliases { ethernet0 = "/amba/ethernet@ff0e0000"; i2c0 = "/amba/i2c@ff020000"; i2c1 = "/amba/i2c@ff030000"; serial0 = "/amba/serial@ff000000"; serial1 = "/amba/serial@ff010000"; spi0 = "/amba/spi@ff0f0000"; }; memory { #address-cells = ; #size-cells = ; device_type = "memory"; alignment = ; reg = ; }; I tried setting the alignment on both /memory and the ddr controller on the /amba_pl, but it doesn't seem to make a difference. In fact, it seems to be ignoring the /memory section, as it still boots off of main system memory and not the memory on the fpga. I am able to access memory using mmap and devmem as such: #include #include #include #include #include #include #include #define ARRAY_TYPE uint16_t int main(int argc, char *argv[]) { if (argc != 2){ printf("Wrong arg count\n"); return -1; } volatile ARRAY_TYPE * ps = malloc(sizeof(ARRAY_TYPE)*10); if (NULL==ps){ printf("Failed to malloc for ps\n"); return -1; } int fd = open("/dev/mem", O_RDWR | O_SYNC ); volatile ARRAY_TYPE *pl = mmap((void*)0x400000000, 0x20000000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x400000000); if (pl == MAP_FAILED) { perror("Can't map memory for pl"); printf("FAIL\n"); return -1; } //force them out of alignment by argv[1] bytes. volatile ARRAY_TYPE *ps_unaligned = (volatile ARRAY_TYPE *)(((uint8_t *)ps) + atoi(argv[1] )); volatile ARRAY_TYPE *pl_unaligned = (volatile ARRAY_TYPE *)(((uint8_t *)pl) + atoi(argv[1] )); printf("trying ps with offset %d\n", atoi(argv[1] )); ps_unaligned = 1; printf("trying pl with offset %d\n", atoi(argv[1] )); pl_unaligned = 1; munmap(pl, 0x20000000); free(ps); close(fd); return 0; } Whenever I try to access memory out of alignment on the main system memory it works fine. However when I access the memory hanging off the FPGA unaligned I get a bus error. root@zynq: ~ 17:22:08 $ ./memtest 0 trying ps with offset 0 trying pl with offset 0 root@zynq: ~ 17:22:12 $ ./memtest 1 trying ps with offset 1 trying pl with offset 1 Bus error root@zynq: ~ 17:22:13 $ ./memtest 2 trying ps with offset 2 trying pl with offset 2 root@zynq: ~ 17:22:14 $ ./memtest 3 trying ps with offset 3 trying pl with offset 3 Bus error I've also looked at the virtual memory mappings of the memory region by looking at /proc/$pid/smaps during a gdb session: Here's the section containing the system memory allocated with devmem/mmap: 400000000-420000000 rw-s 400000000 00:06 1054 /dev/mem Size: 524288 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB VmFlags: rd wr sh mr mw me ms pf io de dd Here's the section for the memory mapped from the FPGA: 5555567000-5555588000 rw-p 00000000 00:00 0 [heap] Size: 132 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB VmFlags: rd wr mr mw me ac I'm not sure if any of the differences in flags explains what is going on but I'm including them in case someone more proficient in memory mapping knows something.

I'd like to load the device tree from a separate dtb file. So in the end I'd like to end up with the following files on my boot partition: - BOOT.BIN (first stage boot loader) - image.ub (U-Boot second stage boot loader including a kernel and a file system) - system.dtb (device tree that is subject to change often due to the FPGA on the dev board) Is this even achievable? Any convenient alternatives are also acceptable. For what it's worth I am using a Ultra96 v2 development board with Petalinux 2019.1.

I have a SoC-FPGA(DE0-nano-soc) which contains an ARM-Cortex-A9 cpu with a Cyclone V FPGA on a single chip. the CPU has access to 1gb of DDR3 memory but the FPGA can also access this memory so they can share data. Now I have configured linux to only see 900M of the total RAM using the boot parameter mem=900M. This way I have some RAM left linux doesn't touch that I can use to communicate with the FPGA. I want to write to that part of the RAM using /dev/mem. I get a permission denied error when I memory map the appropriate address, I am guessing this is because my kernel has CONFIG_STRICT_DEVMEM set. Now I don't really want to unset this since I really only need to write to adresses which linux doesn't use. Is there a way to tell the linux kernel that it is fine to write to that specific part but the normal memory is still of limits?

I am currently working on creating a shared virtual address space in Linux arm64 on a Xilinx Zynq Ultrascale+ board. In the future it should be possible to share pointers/addresses between the Cortex A53s and the FPGA utilizing the built in ARM SMMU 500 (IOMMU) and the Cache Coherent Interface (CCI) without any user action necessary. To do so I used the driver/iommu/arm-smmu.c iommu driver of Linux kernel v4.14.0 and modified it to remove most of virtualization abstractions, along with a separate custom kernel module and ioctls. Thereby each process gets its own individual SMMU context bank which holds its own aarch64 page table. Right now it is already possible to successfully read and write data from the FPGA with virtual addresses using a separate page table by manually mapping the allocated pages to the same virtual addresses again. It would be more convenient if the MMU and SMMU could share the same page table, thus avoiding the unnecessary setup of a second, redundant page table. To do so, I made the following changes: - Configure SMMU to use 39 bit VA size and 40 bit PA size (4 KB page size) - Take the PGD pointer out of curr task_struct and pass it to the correct SMMU context bank PGD (TTBR) entry All other SMMU hardware configurations are the same as in arm-smmu.c. However, this leads to non-deterministic behavior. A test case where the FPGA reads multiple values and writes them back to a different location using the shared virtual addresses works only sometimes. I implemented the test program to intentionally pause after setting up all necessary data structures and initializing them and just before the FPGA is instructed to transfer the values. The longer the pause, the more values are correctly transferred. After about 10 seconds of pause the test always concludes successfully. In my opinion this sounds like a cache issue where the updated page table entries (PTE) created by Linux are still in CPU cache and the SMMU accesses the wrong ones which leads to no transfers (but also no translation error/failure in the SMMU). So either I have to flush/clean the cache at the correct location in linux source code or change some SMMU flags (context bank, stream-2-context register, ...), MMU flags or memory/shareability flags of the PTEs. I already discovered that the MAIR was setup differently for the SMMU. I changed the SMMU code to match the MAIR of the MMU and also use the correct memory attribute index when necessary. But that didn't work. Furthermore, I also checked chapter 1.5.2 "Differences between ARM architecture and SMMU translation schemes" in the ARM SMMU v2 architecture specification. What confuses me the most is that manually built page tables work correctly, but the Linux generated ones cause the described non-deterministic behavior. Any information or hints about how to correctly setup the SMMU to use/share page tables generated by Linux or either change the way Linux configures its page tables in order to work properly with the SMMU?

From what I understand, the partitioning of the Linux system - when booting from an SD card on an embedded device should look something similar to: I want to move partition 2 up and merge it with the unused space. In this scenario the ordering of the partitions would read 1, 3, 2. According to what I have read, the order of the partitions should not matter as long as the MBR partition start address is modified correctly or the boot loader is modified properly. After extensive googling I am unsure as per how to do this and if I am on the correct path. Any advice would be helpful. Thank you,

For Device Tree Blob it says several boards can use one SoC so the SoC level information is included in board level in order not to be duplicated(DTSI is included in DTS). So 1.What is considered to be BOARD and PLATFORM(difference)? 2. Is there a usable board without any SoC, FPGA or stuff like that? 3. How can several boards be connected to each other? (pins or ..??)

Running PetaLinux from sd card on ARM cortex A9 based Zynq zc702 board. Zynq is an SoC with ARM and FPGA. Before the log messages (corresponding to U-Boot) starts printing, the screen (serial console) is blank, but power is already given. So there is considerable time delay (actually around 10 seconds) between the point I give power and the u-boot log messages come on the screen. 1. What is happening during this time? 2. How to minimize this time? 3. How to print log messages of this duration? My U-Boot is in BOOT.BIN file, which has three components: 1. First Stage Boot loader (FSBL) 2. download.bit (FPGA configuration file) 3. U-Boot I have noticed that if I skip download.bit file, the resulting BOOT.BIN file is 500k. But If I keep download.bit file the resulting BOOT.BIN` file is 4.2 MB. Is this (i.e download.bit) the reason of delay? **Log messages** Power was give at approximately 14:32 and you can see u-boot is starting after 10 seconds. [Tue Apr 08 14:42:30.650 2014] [Tue Apr 08 14:42:30.650 2014] [Tue Apr 08 14:42:30.650 2014] U-Boot 2013.07 (Apr 07 2014 - 13:23:59) [Tue Apr 08 14:42:30.650 2014] [Tue Apr 08 14:42:30.650 2014] Memory: ECC disabled [Tue Apr 08 14:42:30.650 2014] DRAM: 1 GiB [Tue Apr 08 14:42:30.662 2014] SF: Detected N25Q128A with page size 64 KiB, total 16 MiB [Tue Apr 08 14:42:30.683 2014] In: serial [Tue Apr 08 14:42:30.683 2014] Out: serial [Tue Apr 08 14:42:30.683 2014] Err: serial

I use linux-socfpga from Altera's github repository (the master branch which is recently updated) with my DE2-115 FPGA. The output from jtag configuration is: $ jtagconfig1) USB-Blaster [2-2] 020F70DD EP3C120/EP4CE115 I wonder if it can find a USB memory that I attached? When I run lsusb nothing appears. Maybe it is the FPGA design that is wrong? # Linux version 4.11.0-rc7-00113-g94836ec (developer@1604) (gcc version 6.2.0 (Sourcery CodeBench Lite 2016.11-32) ) #24 Sun Apr 23 05:44:19 CEST 207 bootconsole [early0] enabled early_console initialized at 0xe8001400 ERROR: Nios II DIV different for kernel and DTS Warning: icache size configuration mismatch (0x8000 vs 0x1000) of CONFIG_NIOS2_ICACHE_SIZE vs device tree icache-size Warning: dcache size configuration mismatch (0x8000 vs 0x800) of CONFIG_NIOS2_DCACHE_SIZE vs device tree dcache-size On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c0e8a31c, node_mem_map c0eaab80 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32768 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyAL0,115200 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Sorting __ex_table... Memory: 114896K/131072K available (4366K kernel code, 114K rwdata, 1272K rodata, 9132K init, 113K bss, 16176K reserved, 0K cma-reserved) NR_IRQS:64 nr_irqs:64 0 clocksource: nios2-clksrc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 38225208935 ns Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=50000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) devtmpfs: initialized cpu cpu0: Error -2 creating of_node link clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns futex hash table entries: 256 (order: -1, 3072 bytes) NET: Registered protocol family 16 random: fast init done usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb FPGA manager framework clocksource: Switched to clocksource nios2-clksrc NET: Registered protocol family 2 TCP established hash table entries: 1024 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. random: crng init done workingset: timestamp_bits=30 max_order=15 bucket_order=0 jffs2: version 2.2. (NAND) �© 2001-2006 Red Hat, Inc. Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) io scheduler mq-deadline registered 8001400.serial: ttyAL0 at MMIO 0x8001400 (irq = 3, base_baud = 3125000) is a Altera UART console [ttyAL0] enabled console [ttyAL0] enabled bootconsole [early0] disabled bootconsole [early0] disabled 8001440.serial: ttyJ0 at MMIO 0x8001440 (irq = 2, base_baud = 0) is a Altera JTAG UART loop: module loaded libphy: Fixed MDIO Bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-platform: EHCI generic platform driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-platform: OHCI generic platform driver fotg210_hcd: FOTG210 Host Controller (EHCI) Driver Warning! fotg210_hcd should always be loaded before uhci_hcd and ohci_hcd, not after usbcore: registered new interface driver usbtmc usbcore: registered new interface driver mdc800 mdc800: v0.7.5 (30/10/2000):USB Driver for Mustek MDC800 Digital Camera usbcore: registered new interface driver usbserial usbcore: registered new interface driver adutux usbcore: registered new interface driver appledisplay usbcore: registered new interface driver cypress_cy7c63 usbcore: registered new interface driver cytherm usbcore: registered new interface driver emi26 - firmware loader usbcore: registered new interface driver emi62 - firmware loader ftdi_elan: driver ftdi-elan usbcore: registered new interface driver ftdi-elan usbcore: registered new interface driver idmouse usbcore: registered new interface driver iowarrior usbcore: registered new interface driver isight_firmware usbcore: registered new interface driver usblcd usbcore: registered new interface driver ldusb usbcore: registered new interface driver legousbtower usbcore: registered new interface driver rio500 usbcore: registered new interface driver usbtest usbcore: registered new interface driver usb_ehset_test usbcore: registered new interface driver trancevibrator usbcore: registered new interface driver usbsevseg usbcore: registered new interface driver yurex usbcore: registered new interface driver sisusb usbcore: registered new interface driver lvs usbip_core: usbip_core_init:766: USB/IP Core v1.0.0 usbcore: registered new device driver usbip-host usbip_host: usbip_host_init:302: USB/IP Host Driver v1.0.0 sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman usbcore: registered new interface driver usbhid usbhid: USB HID core driver NET: Registered protocol family 17 Freeing unused kernel memory: 9132K This architecture does not have kernel memory protection. INIT: version 2.88 booting INIT: Entering runlevel: 3 Starting logging: OK Initializing random number generator... done. Starting system message bus: done Starting network: OK Output from dmesg # dmesg Linux version 4.11.0-rc7-00113-g94836ec (developer@1604) (gcc version 6.2.0 (Sourcery CodeBench Lite 2016.11-32) ) #24 Sun Apr 23 05:44:19 CEST 2017 bootconsole [early0] enabled early_console initialized at 0xe8001400 ERROR: Nios II DIV different for kernel and DTS Warning: icache size configuration mismatch (0x8000 vs 0x1000) of CONFIG_NIOS2_ICACHE_SIZE vs device tree icache-size Warning: dcache size configuration mismatch (0x8000 vs 0x800) of CONFIG_NIOS2_DCACHE_SIZE vs device tree dcache-size On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c0e8a31c, node_mem_map c0eaab80 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32768 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyAL0,115200 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Sorting __ex_table... Memory: 114896K/131072K available (4366K kernel code, 114K rwdata, 1272K rodata, 9132K init, 113K bss, 16176K reserved, 0K cma-reserved) NR_IRQS:64 nr_irqs:64 0 clocksource: nios2-clksrc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 38225208935 ns Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=50000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) devtmpfs: initialized cpu cpu0: Error -2 creating of_node link clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns futex hash table entries: 256 (order: -1, 3072 bytes) NET: Registered protocol family 16 random: fast init done usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb FPGA manager framework clocksource: Switched to clocksource nios2-clksrc NET: Registered protocol family 2 TCP established hash table entries: 1024 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. random: crng init done workingset: timestamp_bits=30 max_order=15 bucket_order=0 jffs2: version 2.2. (NAND) �© 2001-2006 Red Hat, Inc. Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) io scheduler mq-deadline registered 8001400.serial: ttyAL0 at MMIO 0x8001400 (irq = 3, base_baud = 3125000) is a Altera UART console [ttyAL0] enabled bootconsole [early0] disabled 8001440.serial: ttyJ0 at MMIO 0x8001440 (irq = 2, base_baud = 0) is a Altera JTAG UART loop: module loaded libphy: Fixed MDIO Bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-platform: EHCI generic platform driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-platform: OHCI generic platform driver fotg210_hcd: FOTG210 Host Controller (EHCI) Driver Warning! fotg210_hcd should always be loaded before uhci_hcd and ohci_hcd, not after usbcore: registered new interface driver usbtmc usbcore: registered new interface driver mdc800 mdc800: v0.7.5 (30/10/2000):USB Driver for Mustek MDC800 Digital Camera usbcore: registered new interface driver usbserial usbcore: registered new interface driver adutux usbcore: registered new interface driver appledisplay usbcore: registered new interface driver cypress_cy7c63 usbcore: registered new interface driver cytherm usbcore: registered new interface driver emi26 - firmware loader usbcore: registered new interface driver emi62 - firmware loader ftdi_elan: driver ftdi-elan usbcore: registered new interface driver ftdi-elan usbcore: registered new interface driver idmouse usbcore: registered new interface driver iowarrior usbcore: registered new interface driver isight_firmware usbcore: registered new interface driver usblcd usbcore: registered new interface driver ldusb usbcore: registered new interface driver legousbtower usbcore: registered new interface driver rio500 usbcore: registered new interface driver usbtest usbcore: registered new interface driver usb_ehset_test usbcore: registered new interface driver trancevibrator usbcore: registered new interface driver usbsevseg usbcore: registered new interface driver yurex usbcore: registered new interface driver sisusb usbcore: registered new interface driver lvs usbip_core: usbip_core_init:766: USB/IP Core v1.0.0 usbcore: registered new device driver usbip-host usbip_host: usbip_host_init:302: USB/IP Host Driver v1.0.0 sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman usbcore: registered new interface driver usbhid usbhid: USB HID core driver NET: Registered protocol family 17 Freeing unused kernel memory: 9132K This architecture does not have kernel memory protection. # The FPGA design. In menuconfig I have the following settings.

I have a Xilinx FPGA PCIe end-point on the PCI Bus. Linux picks up the device just fine and everything in lspci looks perfect. My question is about PCI access options from user-space and what would be good/bad. Option 1: Direct access via /sys/.../resource0 ---------------------------- (only one I have managed to make work so far) I can open and mmap say /sys/bus/pci/devices/XXXX:XX:XX.X/resource0 then mmap that and read/write. Just need to fix permissions first. My question is, is this a good or bad approach? It feels like this might not be the preferred approach of accessing PCI address space? Option 2: using uio_pci_generic ---------------------------- I've managed to configure my FPGA so that this driver actually connects, the fact that it requires interrupts is really annoying. And it seems this gives access to nothing accept interrupts and configuration memory space? This doesn't seem very useful to me? Am I missing something? Option 3: Write my own uio driver ---------------------------- This might be a reasonable option perhaps? I'm not really sure how difficult this is. One possible advantage of this is that I might get access to DMA and therefore speed things up quite a bit. Option 4: Write a completely custom linux PCI driver ---------------------------- I would like to avoid this option if possible **My question is about what is the best approach and what are the down sides specifically of option 1. Or are there any other approaches I should consider?** (I'm running debian with kernel 3.14.15 rt patched)