We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome,
Firefox,
Internet Explorer 11,
Safari. Thank you!

As for the FPGA .bit file, I never put that into the boot.bin because it makes booting incredibly slow.

I just put the bitstream into the root filesystem, that way it can be compressed (e.g. usign ubifs or jffs2) and it loads in a few milliseconds using "cat /usr/share/fpga.bin > /dev/xdevcfg". And it allows you to re-program the FPGA without even rebooting the system.

In theory, bootgen can convert a .bit file into a .bin file, but I never got this to work, so I wrote a small python program (and posted in here a few months ago) that performs the same task (and works for any FPGA, not just the zynq).

Re: change u-boot on flash mtd with flashcp

hi,i use SDK (create zynq boot image ) for building the mcs file for the flash. i give also the bitstream to it and it loads also in a few milliseconds.. as i understood according to ug821, the fsbl first loads the bitstream to the FPGA, so it's not supposed to take more than that..

i dont realy understand what the diffrence between the ramdisk for example which i can change with flashcp to its mtd and the u boot which i cant?

thanks milosoftware.

p.si didn't find your python program in your posts. we use SDK on windows , so we just tried the -split option to the bootgen and it seems to give a .bin file. best regards

Re: change u-boot on flash mtd with flashcp

I have a similar QSPI partition layout. I can update the Linux ramdisk, kernel, devicetree partitions from within Linux by using the flashcp command.

However, just attempting to update the bitstream file the same method makes the system not able to boot (it prints nothing, just as ariels1 said).

Similarly, updating u-boot the same way also makes it unable to boot.

Is it possible to update u-boot or the bitstream partitions from within Linux? Surely. How?

There must be some difference between the ramdisk, kernel, and devicetree, which are just straight byte copies, and the bitstream and u-boot, which must be in some slightly transformed form. What is happening there in creating a Zynq Boot Image in SDK?

The answers so far don't really help me.

I already have an FSBL (so did ariels).

It's not true that the Zynq boards only accept a single boot partition made with bootgen. I've already got my multi-partition one that works via JTAG!

I'm not sure what is meant by booting with the bitstream is incredibly slow... I have found the bitstream to be loaded incredibly quickly, but the Linux kernel and ramdisk to be loaded very slowly.

I don't think I can make one of the partitions a combined BOOT.bin (fsbl + bitstream + uboot), because my partitions leave space for the u-boot environment settings:

Re: change u-boot on flash mtd with flashcp

Overwriting images that are part of a boot.bin is problematic, since the boot.bin has several headers that include information about the contained data (I think the document you referenced also explains those headers).

So, overwriting things might corrupt headers if they happen to be in the way. Or simply the header information does no longer match the data. E.g. if the partition header says the image has a length of N bytes but you overwrote the data with an image of M > N bytes you have a problem.

And some parts of the image are even protected by a checksum which needs to match.

IMHO, it's not a good idea to selectively replace parts of a boot.bin.

Re: change u-boot on flash mtd with flashcp

I'm assuming you're defining a BOOT.bin as a package of:

1. fsbl

2. bitstream

3. u-boot (or whatever bootloader)

There is a bit of disconnect in my mind with this concept and my QSPI setup, because even the examples I was working off treat these components separately, in separate partitions (i.e. not as a whole package).

So are you suggesting that the binary image files for these partitions (as outputted by the split method I mentioned above) are not actually independent, but have linked information contained in the other components? If so, that seems a bit troublesome!

1. Why is the split option even allowed then?

2. Why has my testing shown that I could change the bitstream and u-boot successfully? (Or did I just get lucky with those, because they were similar enough to the previous?)

3. Surely they could make it work still if the partitions are fixed in their offsets and sizes... the header can just refer to these fixed parameters, and the checksum for each partition can be stored within its own partition?

4. It's funny that fsbl is the one that fails, which is the first component, and would probably be the one that contains the header anyway... (and it's unlikely in my mind that the other components would refer backwards to this partition)

Re: change u-boot on flash mtd with flashcp

Well, reality is complicated :) I carefully chose my words when I said, you have to be cautious when overwriting parts of a boot.bin. If you use -split things are no longer part of the boot.bin ;)

IMHO, it comes down to: What is interpreting the data/partitions?

For the FSBL there is only one option, the bootrom needs to find it. I.e. it must be part of a boot.bin that is interpreted by the bootrom and the bootheader needs to match.

The FSBL needs to hand off to somewhere (unless you do JTAG-boot and manually load images). The FSBL also parses the boot.bin and its headers. So, for everything you expect to be done/interpreted by the FSBL, the boot.bin and its headers need to match up (as I hinted at before, overwriting the binary parts with smaller images is probably working OK. And replacing the bitstreamm too, since it has a fixed size, AFAIK).

For everything else, there are plenty of different options and most of them usually only need the offset and size of the image in flash (e.g. U-Boot). U-Boot does not need any of the boot headers. It just takes as much data as you tell it to, from the address you point it to and interprets it the way you want it to. I.e. it's user responsibity to make sure those things add up.

Just loosely related, but FWIW, I recently wrote a python tool to dump the headers from a boot.bin: https://github.com/sorenb-xlnx/unbootgen . It turned out to be useful for some debugging, probably somebody else finds it usefull too.

Re: change u-boot on flash mtd with flashcp

So I think we conclude that I used -split, and therefore I don't have a "boot.bin" as such? I'm not sure how to interpret the rest then.

"[fsbl] must be part of a boot.bin that is interpreted by the bootrom and the bootheader needs to match."

Well mine isn't part of a boot.bin. The rest of the sentence makes sense.

"The FSBL also parses the boot.bin and its headers. So, for everything you expect to be done/interpreted by the FSBL, the boot.bin and its headers need to match up"

I don't have a boot.bin. Where are the headers stored? Within each partition? Does that mean each partition is independent with respect to checksums and offsets (internally) and such? I'm not sure how to translate this information to my situation. Okay, so replacing just the bitstream and u-boot partitions looks okay, as it worked fine for me when I tested.

"For everything else, there are plenty of different options and most of them usually only need the offset and size of the image in flash (e.g. U-Boot). U-Boot does not need any of the boot headers. It just takes as much data as you tell it to, from the address you point it to and interprets it the way you want it to. I.e. it's user responsibity to make sure those things add up."

Yes, that's all fine, and has been a well-established fact I've seen in my testing (it's not controversial).

I think I see what you're trying to do by answering in general terms, but the trouble I'm having is applying that to my specific case. Why does the updating the FSBL partition not leave it in a bootable state? It still has the header contained within its own partition, so it is internally consistent.

Just to reiterate what I said before:

"I don't think I can make one of the partitions a combined BOOT.bin (fsbl + bitstream + uboot), because my partitions leave space for the u-boot environment settings:

0. fsbl

1. uboot-env <<< fixed address that I need to cater for

2. bitstream

3. uboot"

Thanks for your help sorenb!

Interesting tool - thanks. I haven't used it yet, but it's handy to have in the back pocket.

Re: change u-boot on flash mtd with flashcp

To be honest, I never thought about what the -split really does and how this would work. But running unbootgen on a boot.bin generated with -split seems to explain it.

It seems it generates a boot.bin that includes the FSBL and _all_ headers + separate binary blobs containing the partition data for all other parts of the image.

So, overwriting the FSBL partition replaces all headers. And basically what I said before should apply.

If you overwrite a data partition, without updating the FSBL partition, things may work, but strictly speaking the headers don't necessarily match the data anymore.

Replacing the FSBL partition without any of the others, updates the headers without updating the data accordingly.

So, rewriting the bitstream most likely works. It does not change in size, so the header should not really differ much.

Similarly, U-Boot: As long as the updated U-Boots are smaller or equal in size as the one you used when generating the headers, things are likely to work.

And for the FSBL, I don't see why that shouldn't work. But you'd definitely have to use the same bif and commandline as you used for the original set of files to make the newly generated headers match what you already have in flash.

Re: change u-boot on flash mtd with flashcp

Ah, thanks sorenb. :)

Interesting about all the headers being in the FSBL partition.

Okay, so if those three split partitions (FSBL, bitstream, u-boot) are generated with the one bootgen -split call, then it sounds like it should work fine to update all three of those. I think I'll have to make sure that's the standard procedure. I found that updating the FSBL with even the partition data that was already on there (via JTAG) made it not boot. I suspect that's a different problem that I'll have to investigate though.