I am working on zynq7030.
I have written data from an image sensor to DDR memory using AXI DMA, but while reading the data in Linux environment data is written only in alternative locations.
Example, if we read data from DDR the sensor's data is written only in 0x0, 0x8. Data in 0x4 and 0xC are junk values instead of sensor data.
Custom AXI (full) master -> Interconnect -> Zynq_PS (HP0 slave port)
The custom AXI master produces data (simple counter, written to DRAM, starting at 0x10000000).
according to xsct console -> mrd 0x10000000 10
0x000165c9
0x000266ca
0x000367cb
0x000468cc
0x000569cd
BUT in linux while reading
Please check below the output when I read the DDR location from 0x10000000 using peek command.
root#swan1GB:~# peek 0x10000000; peek 0x10000004 ; peek 0x10000008 ; peek 0x1000000C ; peek 0x10000010
0x000165c9----->data
0x0cbfb405------->garbage data
0x000367cb------->data
0xe0c84100-------->garbage data
0x000569cd-------->data
As we can see the first location has a counter pattern(0x000165C9), the second location should have been written with 0x000266CA but it has some junk value.
Related
I'm writing a character driver which acts are bridge b/w mailbox framework and expose fops for userspace applications.
The user apps do data xfer to remote processors using this char driver. However, a requirement is remote processor wants the data to be in a fixed memory range. The range is provided to char drv in probe() fn.
I could do memremap() of the addr range provided and use it if there was a single user application but in my current case I'm having multiple applications trying to send data buffers to remote core.
So, I need to have the allocation for kernel buffer in a specific memory range and then do copy_from_user() on each data buffer received, then pass the physical addr to the remote core(arm m0+)
Are there any APIs in Linux kernel which does this kind of allocations?
Any pointers on this would be very much appreciated and helpful. Thanks in advance for any suggestions/questions.
ps: the memory addr range provided by remote core is a RAM addr within lower 2GB range(0x8000_0000 - 0xFFFF_FFFF)
I have an Intel FPGA PCIe endpoint. It shows up correctly in lspci and all of the lspci -vv information looks correct (memory map, IRQ, BAR0 size all look OK). I want to stream some data over BAR0 and read/write status registers inside of my IP. My host machine has an Intel x86_64 CPU and running a Debian OS.
What I"m currently doing is this:
open() call to /sys/class/uio/uio0/device/resource0 -> returns a file descriptor.
mmap 4 KB on that file descriptor with PROT_READ + PROT_WRITE protection, and MAP_SHARED flags. Offset is 0. --> returns a pointer.
In a loop, set offsets relative to the pointer to random numbers. Do this for ~1000 bytes, 4 bytes at a time. After each write to the pointer, call msync.
Read back the pointer one DWORD at a time.
Read back the pointer in bulk using memcpy.
The outcome of step #4 is that most of the data looks correct, but some is not (which is strange). The outcome of number 5 is that I get 0xffff_ffff for everything, which is even stranger.
If I try to replace step #3 with a single memset / msync sequence, the program hangs for a little while and then returns a bus error. After this, lspci states that BAR0 is disabled and I can no longer interact with it.
Any ideas what I'm doing wrong? It could be a HW issue, but the HW is really simple right now. I configured the FPGA to act purely as a slave device, with its read response being the registered write data coming across the BAR0 interface. The IP I am working with only has a read-response-valid line (no write response valid, somehow) which I have hard-coded to 1. Seems that burst sizes more than 1 cause some kinds of issues with the PCIe core as seen in the memcpy/memset issues, but I don't see why that would be the case.
EDIT/UPDATE:
I was able to work around this. Supposedly the MMIO is only for 32b, so writing a loop that access the pointer 32b at a time is the solution here.
I am at moment having some problems storing an image generated in the PS part of my Zynq into the DDR3 of my board, and then read that image into the PL side of the board such that the VGA driver created there can
The PS creates a 640x480 image, which ideally i want to store in the Dram.
I've until now used the DMA to transfer the data back and forth and store it as in some way (not storing all pixels) into the block ram of my system. but that isn't a ideal solution and I know so too..
So my question is how do i access the DDR ram of my zynq board, i know it is located on the PS side, but cant seem to find any documentation explaining how it should be interfaced and so..
Usually on zynq you try to use Axi interface for the data.
You can use that by the interconnects and the adress.
In Vivado you have right of the block design diagram a tab called "Address Editor".
In my case a simple test application (axi dma with fifo) is used.
I configured the axi dma to the base address "0x4040_0000" Range of 64K so the High Adress is "0x4040_FFFF".
In The SDK you can access this memory via a C/C++ program.
Here is a short AXI DMA example:
axi dma example
This example was written for the zedboard but I tried it with the z-turn 7020 board and it worked in Vivado 2014.4 and 2016.1.
I hope this helps you.
I am dealing with android boot.img which is a combination of compressed kernel, ramdisk, and dtb. I see from the serial console log from uboot about the booting process and here's the part that triggers my curiosity
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Temperature 27 C
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
check_and_clean: reg 0, flag_set 0
Fastboot: Normal
flash target is MMC:1
Net: FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 3 2 1 0
boota mmc1
kernel # 14008000 (7272352)
ramdisk # 15000000 (869937)
fdt # 14f00000 (44072)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7102 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1920x1080M#60,bpp=32 video=mxcfb1:off video=mxcfb:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consolebalank=0 androidboot.hardware=freescale cma=384M
## Flattened Device Tree blob at 14f00000
Booting using the fdt blob at 0x14f00000
Loading Kernel Image ... OK
Using Device Tree in place at 14f00000, end 14f0dc27
switch to ldo_bypass mode!
Starting kernel ...
The kernel's address is 14008000, ramdisk 15000000, fdt 14f00000.
I have found out that these values are saved in the boot.img header and when I manually mess with this values, the image will not boot even though the actual contents are not modified.
Why is this address so critical? Why does it have to be these values? why not other values?
One of my own guess is:
these load address values are hardcoded inside the kernel so if I change it in the boot.img header it will cause side-effects. To elaborate my own theory, loading the kernel to the 'modified' load addr won't be a problem. But when actually executing the lines, it will cause severe problems because these codes are fixed to work with the proper 'load addr'.
Is my theory wrong? If so, I'd be grateful if you could correct me.
After the U-boot finished, it needs to handover the further execution to kernel so that kernel takes care for all further processes. Plus Kernel have some set of routines which are essential to initialize the board.
These set of routines have a entry point start_kernel(). Before this some other routines are also called to execute start_kernel. That can be identified by this linker script and this init.S.
To maintain execution in this procedure kernel need to be started from a particular address, moreover its data segments and other memories are also attached with that so to load and run all these in a proper manner, exact memory location need to be provided.
With this kernel needs the device tree blob for probing the devices attached to it and the rootfs to bring up the user space, here to load the device tree and rootfs exact offsets are needed so that any data should not be missed or corrupted. Every single byte is important for all these execution.
So to safely bootup all these values are being stored in bootloader's configuration.
I have no real experience with hardware programming. I would like to know how to find out which registers, i.e their addresses, are used for an ethernet connection to send and receive information in a processer. In particular, for ATMEL's at91sam9g20 processor. I have searched the documentation and I'm not sure of the following of what I've found:
-Transmit data: signal name ETX0-ETX3. Receive data: signal name ERX0-ERX3.
Also, Offset: 0x18 Receive Buffer Queue Pointer Register and offset: 0x1C Transmit Buffer Queue Pointer Register.
I would appreciate any help as I'm very stuck on this issue.
Thank you
In the procesor documentation you find the following:
chapter 8 - general memory mapping - this gives the offset of the EMAC memory block as 0xFFFC:4000
chapter 36 - description of the Ethernet MAC subsystem
item 36.3.2 - memory interface - tells how the memory buffers for RX and TX is set up
item 36.5 - user interface - table 36-6 gives the names and offsets to all registers used by the subsystem
The signals (=pins) and register offsets you describe are correct.