08-10-2020 11:54 PM
I am using Zynq 7000 SoC - QSPI booting using FSBL sample code from Ultrafast design tutorials. Our bare metal application can run successfully after the FSBL.
For changing a new Firmware, burning the Flash with new image (FSBL.elf + *bit + App2.elf) takes time & is very frequent in our application. To avoid this, I am exploring if Host booting is possible.
That is, the host will send the App2.ELF file to App1 that is already running.
App1 will load the App2 in respective memory and trigger App2 to execute.
Assume all PL configuration is done by App1 and there is a clear memory distinction between App1 and App2, how to achieve this?
Any advice or direction to explore in this regard is much appreciated.
08-20-2020 10:28 AM
I don't think this is strait forward method. you need to do it manually. the each and every application should implemented with handoff mechanism.
So that when a new application comes from the host, the existing application should finish all the pending transfers give the handoff to new application. Then the new application will execute without any issue.
08-20-2020 06:38 PM
Thanks for the response.
I am pondering which is the right direction to proceed:
So should I understand how FSBL example (image_mover.c) does the handoff and re-use the same
Explore how to build an SSBL to load the new application.
AFAIK, There is no SSBL example for Baremetal application but only Uboot to load Linux OS,
09-21-2020 01:27 AM
You are able to transfer bin/elf files to RAM using either tftpboot or kermit through uboot. Then you can use uboot to transfer the bin/elf file to QSPI (etc) and change your boot-arguments (offset and size in QPSI) such that uboot boots both of your bare-metal applications.
You should use c-code in APU0 to boot APU1 - however uboot should place the bin files in ram.