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
Related
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 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
I am working on Freescale board imx50evk. I have built the uboot.bin and uImage using LTIB (linux target image builder). At the U-Boot prompt I enter the bootm addr command, and then it hangs after showing the message "Loading Kernel..."
> MX50_RDP U-Boot > boot
MMC read: dev # 0, block # 2048, count 6290 partition # 0 ...
6290 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.35.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1323688 Bytes = 1.3 MB
Load Address: a0008000
Entry Point: a0008000
Verifying Checksum ... OK
Loading Kernel Image ...
You need to verify that your board really has RAM at 0xa0008000, which is the kernel "load address". U-Boot is probably trying to copy the image to that region of memory when it appears to hang.
[By your comment, I'll assume that you have verified that main memory does not exist at physical address 0xAXXXXXXX.]
The uImage file that you are using was made from the zImage file using the mkimage utility.
You probably have to manually edit the line that looks like
zreladdr-y := 0xa0008000
in arch/arm/mach-XXX/Makefile.boot for your board. The convention is that this address should be the base of physical RAM plus an offset of 0x8000 (32K). Then adjust the other values in the file. Delete the zImage file and perform another make for the kernel.
While building 3.20 development kernels for rockchip's rk3288 I found using LZO image compression made the device hang at 'Starting the kernel.' I assume it's because of a version miss-match between the build hosts LZO and the deployed decompression code, so it could probably happen with any of the compression algorithms. In my case switch to gzip fixed it.
This is only my assumption for why changing the compression algorithm gave a bootable kernel. Please correct me if I'm wrong.