Creating fsbl.elf

[Rich Wilson]

I thought creating a new fsbl.elf was a no-brainer, but when I do so, I get

a non-booting system. Help!

Why: I believe that many configuration registers are initialized by the fsbl,

and I want to change the frequency of the clock exported to the PL. So

I need to create an fsbl from my Vivado project.

What I did:

First, I tested the procedure. I grabbed a set of files from git, and created

BOOT.bin from them. It booted.

Now, I went to the SDK, and (after exporting my hardware with bits from

Vivado) created a new fsbl.elf. I replaced the fsbl.elf from above with my

newly created file, created a new BOOT.bin, and the system no longer

boots.

I don't know if fsbl prints anything; by the time I get putty going on the

usb port, the terminal is totally dead.

(How can I force a reboot without disconnecting the USB?)

My sanitized boot.bif file:

//arch = zynq; split = false; format = BIN

the_ROM_image:

{

[bootloader]D:\...\Zynq_fsbl.elf

D:\...\impl_2\top.bit

u-boot.elf

[load = 0x2ff0000]D:\...\snickerdoodle-linux-prebuilt-master\snickerdoodle\boot_images\devicetree.dtb

[load = 0x3000000]D:\...\snickerdoodle-linux-prebuilt-master\snickerdoodle\boot_images\uImage

}

[Nick Burkitt]

Rich - you can use the reboot command to reboot with cycling power:

# reboot

[Rich Wilson]

I can't use the reboot command if Linux isn't booted.

(I can boot Linux, make the change that makes it not boot, and then reboot)

OK, when I do so, the fsbl does not appear to print anything.

--

Rich Wilson

[Nick Burkitt]

D'oh! I see you've got it figured out, though.

On Tuesday, August 9, 2016 at 2:16:16 PM UTC-7, Rich Wilson wrote:

I can't use the reboot command if Linux isn't booted.

(I can boot Linux, make the change that makes it not boot, and then reboot)

--
You received this message because you are subscribed to a topic in the Google Groups "snickerdoodle forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/krtkl-snickerdoodle/XafKUITD_wQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to krtkl-snickerdoodle+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/krtkl-snickerdoodle/f8a10407-1fca-467b-9ef0-376a73dbfcf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rich Wilson
ric...@gmail.com
425-337-7129 (land line)
425-374-4760 (Google)

[Bush]

While I'm not sure if this is the root of your problem, the FSBL project in SDK needs to be completely removed and re-generated anytime there are changes to your configuration. The FSBL project configuration is generated when the FSBL project template is selected for a particular hardware configuration so no changes to the hardware configuration are reflected in the FSBL source after the FSBL project has been created. Make sure to completely remove (delete) the project from your .sdk directory (with SDK closed) and restart SDK to generate a new FSBL project.

Also, you shouldn't need to include the devicetree.dtb and uImage in your boot.bif file unless you are planning on booting entirely from a standalone BOOT.bin image. Having separate devictree.dtb and uImage files makes your system more modular and easily upgrade-able so building those components into BOOT.bin only serves to add to the size of that file. As a counter-argument, keeping those images in a monolithic BOOT.bin image can give you a known bootable fall-back image. Just a heads-up in case you were redundantly duplicating the devicetree.dtb and uImage in your BOOT.bin and in your boot partition. 

On Tuesday, August 9, 2016 at 2:09:11 PM UTC-7, Rich Wilson wrote: