I'm trying to configure the programmable logic inside the parallella board (based on zynq 7020), I insert an sd card that contains bitstream, fsbl.elf and hello_world.elf after the board is booted I tried to do this
zynq-uboot> fatload mmc 0 0x4000000 design_1_wrapper.bit
reading design_1_wrapper.bit
4045678 bytes read
zynq-uboot> fpga loadb 0 0x4000000 4045678
design filename = "design_1_wrapper;UserID=0XFFFFFFFF;Version=2014.3.1"
part number = "7z020clg400"
date = "2015/09/30"
time = "10:58:34"
bytes in bitstream = 4045564
Error: Timeout waiting for FPGA to config.
fpga - loadable FPGA image support
Usage:
fpga [operation type] [device number] [image address] [image size]
fpga operations:
dump [dev] Load device to memory buffer
info [dev] list known device information
load [dev] [address] [size] Load device from memory buffer
loadb [dev] [address] [size] Load device from bitstream buffer (Xilinx only)
loadmk [dev] [address] Load device generated with mkimage
For loadmk operating on FIT format uImage address must include
subimage unit name in the form of addr:<subimg_uname>
zynq-uboot> fpga info 0
Xilinx Device
Descriptor # 0x3dfb8b84
Family: Zynq PL
Interface type: Device configuration interface (Zynq)
Device Size: 4045564 bytes
Cookie: 0x0 (0)
No Device Function Table.
zynq-uboot>
why the PL is not configured? Is it the size?
Thank you
Related
I am trying to use f4pga to compile one of their examples in f4pga-examples from verilog into a bitstream and run it on my ZYBO Zynq 7000, following the instructions here:
https://f4pga-examples.readthedocs.io/en/latest/running-examples.html
(Note that I had to substitute "fatload" for "load", as there is no "load".)
zynq-uboot> fatload mmc 0 0x10000000 top.bit
reading top.bit
2083847 bytes read in 349 ms (5.7 MiB/s)
zynq-uboot> fpga loadb 0 0x10000000 2083847
design filename = "/tmp/tmpoyzn0_4q;Generator=xc7frames2bit"
fpga_loadbitstream: Wrong bitstream ID for this device
fpga_loadbitstream: Bitstream ID xc7z010clg400-1, current device ID 0/7z010
fpga - loadable FPGA image support
Usage:
fpga [operation type] [device number] [image address] [image size]
fpga operations:
dump [dev] Load device to memory buffer
info [dev] list known device information
load [dev] [address] [size] Load device from memory buffer
loadb [dev] [address] [size] Load device from bitstream buffer
(Xilinx only)
loadmk [dev] [address] Load device generated with mkimage
For loadmk operating on FIT format uImage address must include
subimage unit name in the form of addr:<subimg_uname>
zynq-uboot>
Ideas? Could it be as simple as changing the bitstream ID to something else?
The newer uboot (i tested master branch) does not check the device id.
should be not to hard to upgrade, only loading of images changed.
you have to take a look into extlinux and some other enviroment generation.
I could load the old bitstream but when I try a newer one my system hangs,
need more investigation.
br
TuxCoder
I am trying to restore an Allwinner A13 based OEM board to working condition, because the original SD card died and there is currently no way to get an original backup image.
Only thing I have so far is the linux rootfs and a partition table it wants to use (The original sizes and filesystems are too unknown to me, so I used what i deemed purposeful).
I have created the partition table, put the rootfs into its partition and set up the toolchain to compile the u-boot + spl.
The board itself only has one Micro SD slot, and this card contains the u-boot + SPL on its first megabyte after the partition table.
The spl and u-boot layout I use:
sector (512b) start size usage
---------------------------------------
0-15 (16) 0kb 8kb MBR+GPT
16-79 (64) 8kb 32kb SPL
80-2047 (1968) 40kb 984kb u-boot
2048 (----) 1024kb (----) partitions
The partition table:
1 MBR 512MB FAT "mmcblk0p1" drive for recovery firmware dumps
2 MBR 512MB FAT "mmcblk0p2" boot volume. perhaps for u-boot environment
3 MBR GPT Container
4 GPT
5 GPT
6 GPT 2048MB ext2 "mmcblk0p6" rootfs
7 GPT 4096MB ext2 "mmcblk0p7" file system for user data
8 GPT 1024MB ext2 "mmcblk0p8" squash image and/or backup are stored here
The rootfs partition contains a folder named boot with these files inside, so I assume the SPL / u-boot eventually wants to boot from there:
/boot/script.bin 32KB
/boot/devicetree.dtb 38KB
/boot/uImage 5200KB
The SPL dies with the following error message on the serial (it doesn't even find the u-boot, the result is the same with only the SPL part dd-ed on the card):
U-Boot SPL 2020.07-rc4-STT-LMT-00022-gbe79009f3b (Jun 12 2020 - 23:40:45 +0000)
DRAM: 256 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC2
MMC Device 1 not found
spl: could not find mmc device 1. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
How can I successfully have this boot the os on the rootfs?
I'm using PCIe bus on Freescale MPC8308 (as root complex) and the endpoint device is an ASIC with just one 256 MB memory region and just one BAR register. The device configuration space registers are readily accessible through "pciutils" package. At first I tried to access memory region by using mmap() but it didn't work. So at the next level, I prepared a device driver for the PCIe endpoint device which is a kernel module that I load into kernel after Linux booting.
In my driver the endpoint device is identified from device ID table but when I want to enable the device by pci_enable_device(), I see this error:
driver-pci 0000:00:00.0: device not available because of BAR 0 [0x000000-0xfffffff] collisions
Also when I want to allocate memory region for PCIe device by using pci_request_region(), it is not possible.
Here is the part of driver code which is not working:
pci_enable_result = pci_enable_device (pdev);
if (pci_enable_result)
{
printk(KERN_INFO "PCI enable encountered a problem \n");
return pci_enable_result;
}
else
{
printk(KERN_INFO "PCI enable was succesfull \n");
}
And here is the result in "dmesg" :
driver-pci 0000:00:00.0: device not available because of BAR 0 [0x000000-0xfffffff] collisions
PCI enable encountered a problem
driver-pci: probe of 0000:00:00.0 failed with error -22
It is worth noting that in the driver I can read and write configuration registers correctly by using functions like pci_read_config_dword() and pci_write_config_dword().
What's the problem do you think? is it possible that the problem appears because the kernel initializes the device prior to kernel module? what should I do to prevent this to occur?
BAR registers access are generally for small region. Your BAR0 size seems to be too large. Try with less memory (less than 1MB), it should works.
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'm writing a framebuffer for an SPI LCD display on ARM. Before I complete that, I've written a memory only driver and trialled it under Ubuntu (Intel, Virtualbox). The driver works fine - I've allocated a block of memory using kmalloc, page aligned it (it's page aligned anyway actually), and used the framebuffer system to create a /dev/fb1. I have my own mmap function if that's relevant (deferred_io ignores it and uses its own by the look of it).
I have set:
info->screen_base = (u8 __iomem *)kmemptr;
info->fix.smem_len = kmem_size;
When I open /dev/fb1 with a test program and mmap it, it works correctly. I can see what is happening x11vnc to "share" the fb1 out:
x11vnc -rawfb map:/dev/fb1#320x240x16
And view with a vnc viewer:
gvncviewer strontium:0
I've made sure I've no overflows by writing to the entire mmapped buffer and that seems to be fine.
The problem arises when I add in deferred_io. As a test of it, I have a delay of 1 second and the called deferred_io function does nothing except a pr_devel() print. I followed the docs.
Now, the test program opens /dev/fb1 fine, mmap returns ok but as soon as I write to that pointer, I get a kernel panic. The following dump is from the ARM machine actually but it panics on the Ubuntu VM as well:
root#duovero:~/testdrv# ./fbtest1 /dev/fb1
Device opened: /dev/fb3
Screen is: 320 x 240, 16 bpp
Screen size = 153600 bytes
mmap on device succeeded
Unable to handle kernel paging request at virtual address bf81e020
pgd = edbec000
[bf81e020] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: hhlcd28a(O) sysimgblt sysfillrect syscopyarea fb_sys_fops bnep ipv6 mwifiex_sdio mwifiex btmrvl_sdio firmware_class btmrvl cfg80211 bluetooth rfkill
CPU: 0 Tainted: G O (3.6.0-hh04 #1)
PC is at fb_deferred_io_fault+0x34/0xb0
LR is at fb_deferred_io_fault+0x2c/0xb0
pc : [<c0271b7c>] lr : [<c0271b74>] psr: a0000113
sp : edbdfdb8 ip : 00000000 fp : edbeedb8
r10: edbeedb8 r9 : 00000029 r8 : edbeedb8
r7 : 00000029 r6 : bf81e020 r5 : eda99128 r4 : edbdfdd8
r3 : c081e000 r2 : f0000000 r1 : 00001000 r0 : bf81e020
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: adbec04a DAC: 00000015
Process fbtest1 (pid: 485, stack limit = 0xedbde2f8)
Stack: (0xedbdfdb8 to 0xedbe0000)
[snipped out hexdump]
[<c0271b7c>] (fb_deferred_io_fault+0x34/0xb0) from [<c00db0c4>] (__do_fault+0xbc/0x470)
[<c00db0c4>] (__do_fault+0xbc/0x470) from [<c00dde0c>] (handle_pte_fault+0x2c4/0x790)
[<c00dde0c>] (handle_pte_fault+0x2c4/0x790) from [<c00de398>] (handle_mm_fault+0xc0/0xd4)
[<c00de398>] (handle_mm_fault+0xc0/0xd4) from [<c049a038>] (do_page_fault+0x140/0x37c)
[<c049a038>] (do_page_fault+0x140/0x37c) from [<c0008348>] (do_DataAbort+0x34/0x98)
[<c0008348>] (do_DataAbort+0x34/0x98) from [<c0498af4>] (__dabt_usr+0x34/0x40)
Exception stack(0xedbdffb0 to 0xedbdfff8)
ffa0: 00000280 0000ffff b6f5c900 00000000
ffc0: 00000003 00000000 00025800 b6f5c900 bea6dc1c 00011048 00000032 b6f5b000
ffe0: 00006450 bea6db70 00000000 000085d6 40000030 ffffffff
Code: 28bd8070 ebffff37 e2506000 0a00001b (e5963000)
---[ end trace 7e5ca57bebd433f5 ]---
Segmentation fault
root#duovero:~/testdrv#
I'm totally stumped - other drivers look more or less the same as mine but I assume they work. Most use vmalloc actually - is there a difference between kmalloc and vmalloc for this purpose?
Confirmed the fix so I'll answer my own question:
deferred_io changes the info mmap to its own that sets up fault handlers for writes to the video memory pages. In the fault handler it
checks bounds against info->fix.smem_len, so you must set that
gets the page that was written to.
For the latter case, it treats vmalloc differently from kmalloc (by checking info->screen_base to see if it's vmalloced). If you have vmalloced, it uses screen_base as the virtual address. If you have not used vmalloc, it assumes that the address of interest is the physical address in info->fix.smem_start.
So, to use deferred_io correctly
set screen_base (char __iomem *) and point that to the virtual address.
set info->fix.smem_len to the video buffer size
if you are not using vmalloc, you must set info->fix.smem_start to the video buffer's physical address by using virt_to_phys(vid_buffer);
Confirmed on Ubuntu as fixing the issue.
Really interesting, I'm currently implementing SPI-based display FB driver too (Sharp Memory LCD display and my VFDHack32 host driver). I also facing similar problem where it crashes at deferred_io. Can you share you source code ? mine is at my GitHub repo. P.S. that Memory LCD display is monochrome so I just pretend to be color display and just check whether the pixel byte is empty (dot off) or not empty (dot on).