large bss size for sample applications

[Jeff Webb]

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.

./rtems-git/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac

#
# Zynq Memory map can be controlled from the configure command line. Use ...
#
#   ..../configure --target=arm-rtems4.11 ... BSP_ZYNQ_RAM_LENGTH=256M
#
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[xilinx_zynq_a9_qemu],[256M])
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[xilinx_zynq_zc702],[1024M])
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[xilinx_zynq_zc706],[1024M])
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[xilinx_zynq_zedboard],[512M])
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[*],[256M])
RTEMS_BSPOPTS_HELP([BSP_ZYNQ_RAM_LENGTH],[override a BSP's default RAM length])
RTEMS_BSPOPTS_SET([BSP_ZYNQ_NOCACHE_LENGTH],[*],[1M])
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,

-Jeff