UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer ariels1
Observer
12,963 Views
Registered: ‎07-22-2013

change u-boot on flash mtd with flashcp

Hi ,

is it possible to change u-boot on flash mtd?

 

i use zc702 with linux xlnx 3.9.

 

I tried the follow :

i configured the bif file to :

[bootloader]/Arc/UV/fsbl_UV_0/Release/fsbl_UV_0.elf
[offset = 0x050000]/Arc/UV/system_hw_platform/system.bit
[offset = 0x480000]/Arc/UV/linuxFiles/u-boot.elf
[offset = 0x600000]/Arc/UV/linuxFiles/uImage
[offset = 0xA00000]/Arc/UV/linuxFiles/devicetree.dtb
[offset = 0xA20000]/Arc/UV/linuxFiles/uramdisk.image.gz

 

I adjust the dts :

partition@qspi-fsbl {
label = "qspi-fsbl";
reg = <0x0 0x050000>;
};
partition@qspi-bitstream {
label = "qspi-bitstream";
reg = <0x050000 0x430000>;
};
partition@qspi-uboot {
label = "qspi-uboot";
reg = <0x480000 0x180000>;
};
partition@qspi-linux {
label = "qspi-linux";
reg = <0x600000 0x400000>;
};
partition@qspi-device-tree {
label = "qspi-device-tree";
reg = <0xA00000 0x20000>;
};
partition@qspi-ramdisk {
label = "qspi-ramdisk";
reg = <0xA20000 0x2E0000>;
};

 

after programming flash and  powerup i copy other u-boot to Mtd2 ( the u-boot's mtd)  :

flashcp -v u-boot.elf /dev/mtd2

 

but after shut down and power up i get no prints in the monitor.( i do see that the FPGA led is light, means - done ).

not even the fsbl prints.

replacing ramdisk in the above way works fine.

 

B.T.W

i checked both u-boot's and they both works fine after programming flash with jtag.

 

so , what am i missing ?

 

thanks & BR 

 

ari

 

 

 

0 Kudos
13 Replies
Scholar milosoftware
Scholar
12,962 Views
Registered: ‎10-26-2012

Re: change u-boot on flash mtd with flashcp

You cannot boot from .elf files. Besides that, the elf file isn't enough, you need a first stage bootloader in addition to the regular u-boot loader.

 

The Zynq board basically only accepts bootloaders that have been packed with "bootgen".

 

If you've built a BOOT.bin file with the GUI tools (or any other way), you can flash that to the mtd, e.g.

 

flashcp -v /media/mmcblk0p1/BOOT.BIN /dev/mtd0

 

I'm using the following partitioning (on zed, for the zc702 you'll need to make the rootfs partition smaller) to be able to boot from internal flash:

root@zedboard:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00060000 00010000 "qspi-bootloader"
mtd1: 00010000 00010000 "qspi-u-boot-env"
mtd2: 00010000 00010000 "qspi-device-tree"
mtd3: 00400000 00010000 "qspi-linux"
mtd4: 01b80000 00010000 "qspi-rootfs"

 

0 Kudos
Observer ariels1
Observer
12,955 Views
Registered: ‎07-22-2013

Re: change u-boot on flash mtd with flashcp

so , if i undersood ,u cannot change u-boot seperatly ?
does the u-boot is even sits in the address i gave in bif file? or that only the kernel dtb and ramdisk adresses can be defined by user?

what if i need to change the FPGA .bit file ?
can i copy it to its mtd i defined in the dts , or i need to create a new BOOT.bin every time i have a new .bit file ?

thanks for the quick answer ..

ari
0 Kudos
Scholar milosoftware
Scholar
12,951 Views
Registered: ‎10-26-2012

Re: change u-boot on flash mtd with flashcp

u-boot will have whatever address you configured it to have. You have to re-pack it into a boot.bin (together with fsbl.elf) every time again.

 

If you build u-boot outside the Xilinx tools (like me), you can generate it with a script like this:

    rm -f ${S}/BOOT.bin
    echo "the_ROM_image:" > bootimage.bif
    echo "{" >> bootimage.bif
    echo " [bootloader]${ZYNQ_FSBL}" >> bootimage.bif
    echo " ${ZYNQ_BITFILE}" >> bootimage.bif
    echo " [load = 0x04000000, startup = 0x04000000]${S}/${UBOOT_BINARY}" >> bootimage.bif
    echo "}" >> bootimage.bif
    echo "executing: {$ZYNQ_BOOTGEN} -image bootimage.bif -o i ${S}/BOOT.bin"
    ${ZYNQ_BOOTGEN} -image bootimage.bif -o i ${S}/BOOT.bin

 

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).

0 Kudos
Observer ariels1
Observer
12,929 Views
Registered: ‎07-22-2013

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.s
i 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

ari

 

0 Kudos
Adventurer
Adventurer
11,566 Views
Registered: ‎09-19-2014

Re: change u-boot on flash mtd with flashcp

I know this was a while ago, but I have the same problem as ariels1.

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:

0. fsbl

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

2. bitstream

3. uboot

....

0 Kudos
Adventurer
Adventurer
11,556 Views
Registered: ‎09-19-2014

Re: change u-boot on flash mtd with flashcp

Problem solved.

The u-boot and bitstream images need to be put through bootgen:

bootgen -image output.bif -split bin

 

with output.bif file:

the_ROM_image:
{
	[bootloader]fsbl.elf
	[offset = 0x100000]bitstream.bit
}

 

The -split bin part outputs as separate bin files:

output.bin (actually the fsbl)

bitstream.bin

 

I tried doing just the bitstream.bit through bootgen (I think I did it properly), and it failed to boot. So I found that -split was required.

You can use the u-boot.bin instead of u-boot.elf (both are generated for me, otherwise, just add the u-boot.elf into the list to generate a separate u-boot.bin with bootgen too).

 

I have found I can write these u-boot.bin and bitstream.bin files to the respective QSPI partitions, and it works!

I also tried writing the output.bin (fsbl) to the QSPI, and it caused the same boot failure with blank screen. So I'll leave that one alone for now.

0 Kudos
Adventurer
Adventurer
11,550 Views
Registered: ‎09-19-2014

Re: change u-boot on flash mtd with flashcp

Details on the "bootgen -split" are on page 64 of UG821:

http://www.xilinx.com/support/documentation/user_guides/ug821-zynq-7000-swdev.pdf

0 Kudos
Xilinx Employee
Xilinx Employee
11,540 Views
Registered: ‎03-13-2012

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.

0 Kudos
Adventurer
Adventurer
11,492 Views
Registered: ‎09-19-2014

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)

0 Kudos
Xilinx Employee
Xilinx Employee
6,120 Views
Registered: ‎03-13-2012

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.

0 Kudos
Adventurer
Adventurer
6,106 Views
Registered: ‎09-19-2014

Re: change u-boot on flash mtd with flashcp

Thanks.

I'm a little confused still I think.

So "If you use -split things are no longer part of the boot.bin ;)"

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.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,098 Views
Registered: ‎03-13-2012

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.

0 Kudos
Adventurer
Adventurer
6,085 Views
Registered: ‎09-19-2014

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.

0 Kudos