large bss size for sample applications

[Jeff Webb]

On 09/24/2015 12:48 AM, Sebastian Huber wrote:
> On 23/09/15 18:31, Jeff Webb wrote:
>> 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.
>
> The purpose of the bsp_section_rwbarrier_align is to separate the read-only from the read-write sections so that we can use the MMU (granularity 1MiB) to protect the read-only sections. There is probably a bug in the MMU setup in case the bsp_section_rwbarrier_align is not 1MiB. You can set the nocache memory to 0 if you don't need this.
>

Thanks for the additional information.  That helps.

I apologize for my mistake, but it turns out that making the following configuration command and change to linkcmds.in does indeed allow me to compile ticker.exe with a 256KB memory map:

../rtems-git/configure \
   --target=arm-rtems4.11 \
   --enable-rtemsbsp=xilinx_zynq_zedboard \
   --enable-tests=samples \
   --enable-networking \
   --enable-posix \
   --prefix=/opt/rtems/bsps/4.11 \
   BSP_ARM_A9MPCORE_PERIPHCLK=333333333U \
   BSP_ZYNQ_RAM_LENGTH=1280K BSP_ZYNQ_NOCACHE_LENGTH=0

$ git diff
+/*
  bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M;
+*/
  
(I believe the base linker script sets bsp_section_rwbarrier_align to 1 with the above line commented out.)

The resulting memory map is:

../bsps/4.11/arm-rtems4.11/xilinx_zynq_zedboard/lib/linkcmds

MEMORY {
    RAM_INT_0 : ORIGIN = 0x00000000, LENGTH = 64k + 64k + 64k
    RAM_INT_1 : ORIGIN = 0xFFFF0000, LENGTH = 64k - 512
    RAM_MMU   : ORIGIN = 0x00100000, LENGTH = 16k
    RAM       : ORIGIN = 0x00100000 + 0x00004000, LENGTH = 1280K - 1M - 16k - 0
    NOCACHE   : ORIGIN = 0x00100000 + 0x00004000 + 1280K - 1M - 16k - 0, LENGTH = 0
}

which gives me 1280K - 1M - 16k = 240KB of RAM to work with.

Running readelf on the stripped executable yields:

Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .start            PROGBITS        00104000 0000c0 0003e0 00  AX  0   0  4
   [ 2] .text             PROGBITS        00104400 0004c0 0102b8 00 WAX  0   0 64
   [ 3] .init             PROGBITS        001146b8 010778 00000c 00  AX  0   0  4
   [ 4] .fini             PROGBITS        001146c4 010784 00000c 00  AX  0   0  4
   [ 5] .rodata           PROGBITS        001146d0 010790 001460 00   A  0   0  4
   [ 6] .ARM.exidx        ARM_EXIDX       00115b30 011bf0 000008 00  AL  2   0  4
   [ 7] .eh_frame         PROGBITS        00115b38 011bf8 000074 00   A  0   0  4
   [ 8] .init_array       INIT_ARRAY      00115bac 011c6c 000004 00  WA  0   0  4
   [ 9] .fini_array       FINI_ARRAY      00115bb0 011c70 000004 00  WA  0   0  4
   [10] .jcr              PROGBITS        00115bb4 011c74 000004 00  WA  0   0  4
   [11] .vector           NOBITS          00115bb8 011c78 001400 00  WA  0   0  1
   [12] .data             PROGBITS        00116fb8 011c78 0006e8 00  WA  0   0  8
   [13] .bss              NOBITS          001176a0 012360 002174 00  WA  0   0 32
   [14] .work             NOBITS          00119814 012360 0267ec 00  WA  0   0  1
   [15] .comment          PROGBITS        00000000 012360 000075 01  MS  0   0  1
   [16] .ARM.attributes   ARM_ATTRIBUTES  00000000 0123d5 000033 00      0   0  1
   [17] .shstrtab         STRTAB          00000000 012408 000090 00      0   0  1

So, it looks like the program + data + bss is around 86K, with 154K left for the stack and work space, right?

I was able to load and run the program on the Zedboard, so I will count this as a successful test.

The next task for me will be to set up a simple out-of tree C or C++ POSIX application.

Thanks again for all the help!

-Jeff