large bss size for sample applications
jeff.webb at nta-inc.net
Wed Sep 23 16:31:10 UTC 2015
Thank you all for the very warm and swift responses. I have replied to several of your comments below.
On 09/22/2015 08:32 PM, Gedare Bloom wrote:
> The bss defaults to take up the leftover space in the memory map, so
> it will appear large. This is where the C program heap lives, and also
> the "RTEMS Workspace" (where dynamically allocated, but statically
> configured size, blocks of memory are located).
Thanks for the explanation. That makes more sense. I don't fully understand the workspace area yet, but I get the idea.
> I believe you can use RTEMS in under 64K with some hacks. Anything
> above 256K should work very well except for the new networking stack.
> I don't know off-hand its size reqs.
That sounds promising. I don't foresee a requirement for networking at this point.
On 09/22/2015 09:59 PM, Joel Sherrill wrote:
>>> I tried shrinking the memory map for the zedboard using various techniques,
>>> but it looks like I'm running out of memory. One technique I attempted was
>>> to add something like "BSP_ZYNQ_RAM_LENGTH=1536K
>>> BSP_ZYNQ_NOCACHE_LENGTH=128K" to the configure command, which would yield an
>>> error message like this:
> Are those parameters listed in configure.ac for the BSP?
I think so. I tried overriding some of the others on the command line, but they didn't take effect. I think I understand what these variable do, but I think some other parts of the linker configuration are giving me trouble, as Sebastian pointed out.
# Zynq Memory map can be controlled from the configure command line. Use ...
# ..../configure --target=arm-rtems4.11 ... BSP_ZYNQ_RAM_LENGTH=256M
RTEMS_BSPOPTS_HELP([BSP_ZYNQ_RAM_LENGTH],[override a BSP's default RAM length])
RTEMS_BSPOPTS_HELP([BSP_ZYNQ_NOCACHE_LENGTH],[length of nocache RAM region])
On 09/23/2015 02:16 AM, Chris Johns wrote:
>> Is it possible to do
>> anything useful in a few hundred kilobytes of RAM on the Zynq platform?
> Yes I suspect so. It will depend on you application.
Thanks for the encouragement to proceed.
> This is a very interesting design challenge. I assume you are looking to
> use just the OCM ?
Yes. We were also hoping to be able to use the 512K L2 cache as memory also.
> I am not sure what is needed to get this to link for you without digging
> in and looking. I suspect you will need a custom MMU configuration to
> get the OCM at mapped correctly.
> A challenge will be getting the FSBL to load the bitfile. It has been a
> while but I seem to remember it needing DDR to load the bit file into
> before send it over the PCAP interface to the PL.
Thanks for the tips - I'm sure this will get hairy. At this point I just want to see if our code can fit in the available space. Right now, I would be happy to use DRAM, but only, say 256K of it.
On 09/23/2015 07:50 AM, Sebastian Huber wrote:
> I would use a custom linker command file. Use c/src/lib/libbsp/arm/xilinx-zynq/startup/linkcmds.in as a template. In particular the line
> bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M;
> is probably not the right thing for you. Maybe use
> bsp_section_rwbarrier_align = 1;
Thanks for the detailed information, Sebastian. I am still digging into this. So far, I just tried changing bsp_section_rwbarrier_align to 1, but I had the same error. I will look into this more deeply and reply with some more questions if I can't get it figured out. It might help to understand why rwbarrier and nocache are required and what is going on here. I don't think the raspberry pi configuration had these, but I might be mistaken.
Thanks again to everyone,
More information about the users