cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ruijie
Adventurer
Adventurer
1,368 Views
Registered: ‎08-06-2018

FSBL occupies too much ocm

Jump to solution

Hi,

I'm working on zynq 7000, sdk 2017.4. 

I have two baremetal apps running on the arm dual cores. I use the demo FSBL as the bootloader to boot up dual cores from qspi. Here is my problem, that fsbl occupies too much ocm and that ocm can't be re-used by dual core app until it handsoff. I wonder how can my app reuse it when it handsoff since all the image loading has already done.

In my case, both of my dual core apps resides in ocm and ddr as parital (I modified fsbl to let partial of my app code reside in ocm) , and I hope more ocm can be used by app code and data since ocm access is faster than the ddr.

I optimized fsbl project with -Os but it still around 130K size .  Thus like half of the ocm is occupied by fsbl that cannot be used by my app, since LoadImage()  would crash the fsbl if my app's sections have any overlap with the fsbl.

And I don't want to use XIP to execute the fsbl in nor since its too slow.

So, is there any other way to compress the fsbl to a smaller size or is it possible to let app's section cover fsbl's section safely without crashing the fsbl before it handsoff ?

BRs

0 Kudos
1 Solution

Accepted Solutions
johnmcd
Xilinx Employee
Xilinx Employee
1,341 Views
Registered: ‎02-01-2008

Check out http://xkb/Pages/71/71563.aspx for usage of OCM.

If you are not using Linux, then you probably do not need ATF and can therefore free up some of high ocm.

Also, you can usually lock down the noload linkerscript stuff such as stack and heap. By fixing no-load addresses for fsbl, you can re-use that same address range for your noload stuff in hello world.

Disable some of the options in xfsbl_config.h. If you are booting from QSPI, you can exclude SD boot etc.

I haven't compiled FSBL for zynq7 in a while but I expect that it is using LTO (Link Time Optimization) which squeezes the memory footprint pretty well.

Increase optimization of your hello world BSP by adding -Os to BSP extra compiler flags

View solution in original post

5 Replies
johnmcd
Xilinx Employee
Xilinx Employee
1,342 Views
Registered: ‎02-01-2008

Check out http://xkb/Pages/71/71563.aspx for usage of OCM.

If you are not using Linux, then you probably do not need ATF and can therefore free up some of high ocm.

Also, you can usually lock down the noload linkerscript stuff such as stack and heap. By fixing no-load addresses for fsbl, you can re-use that same address range for your noload stuff in hello world.

Disable some of the options in xfsbl_config.h. If you are booting from QSPI, you can exclude SD boot etc.

I haven't compiled FSBL for zynq7 in a while but I expect that it is using LTO (Link Time Optimization) which squeezes the memory footprint pretty well.

Increase optimization of your hello world BSP by adding -Os to BSP extra compiler flags

View solution in original post

ritakur
Xilinx Employee
Xilinx Employee
1,324 Views
Registered: ‎09-01-2014

AR#71563 is not open to the public.
Please Check Wiki page for the FSBL reserved memory region and Flag to reduce the size
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842019/FSBL
0 Kudos
ruijie
Adventurer
Adventurer
1,290 Views
Registered: ‎08-06-2018

Thank you @johnmcd  and @ritakur ,

@johnmcd  thank for the advice of NOLOAD, it is very helpful. However, it still occupies around 60K of ocm and that's still too much.

I try to put several functions to a specific section using __attribute__((section("")), however, the project can compile but when I create the boot image, I get " Multiple executable program sections in FSBL.elf" error . So it seems that there are some constrains on defining the sections of FSBL. What are the constrains ? Is it because of the BootRom code that force the FSBL to be like this? Must the .text section starting from fixed address 0x0 in case the bootrom code could correctly find the fsbl?

I checked the link @ritakur metioned, but didnot get the answer I need.

BRs

 

0 Kudos
johnmcd
Xilinx Employee
Xilinx Employee
1,231 Views
Registered: ‎02-01-2008

Last I tried, both xsct dow command and bootgen required the downloaded section of code to be consecutive with no wholes. If you 'realy' want a code segment to be forced into another location, you would have to copy the code from consecutive location to isolated location.

You can always try to play around with copying parts from one location to another, or to re-use a region of memory.

Something else you could look at is re-using the FSBL bsp for your app that runs on cpu0. This means adding your cpu0 app to the FSBL src.

0 Kudos
ruijie
Adventurer
Adventurer
1,179 Views
Registered: ‎08-06-2018

Thank you so much @johnmcd ,

Your suggestions give me more ideas to save more space to be used by my app.

Separate code into different section is not my goal, why am doing it is to separate code into two parts, one is code that cannot be covered during loadimage() because coping sections onto this code will crash the fsbl execution, and one is code that can be covered during loadimage() since this code already executed and crashing it won't effect the following exection. Thus this second part of code can be re-used by  my app, so only a small size of ocm will be occupied by fsbl.

here is another thread I posted which related to this problem, I described my goal and more details in  https://forums.xilinx.com/t5/Embedded-Boot-and-Configuration/FSBL-error-when-creating-boot-bin/td-p/987593 But no any useful answer.

0 Kudos