Forums - Build System / Memory Map

Hi,

we are just evaluating the QCA4020 for usage in one of our upcoming products. We use the Silex and the Qualcomm development boards for that purpose, our IDE is Eclipse. Even though the demo applications build with our setup, I tried to better understand the build system and the run-time environment of the QCA4020, because not all seems to be documented. Maybe someone can confirm my understanding and answer the questions below.

I understand that the RAM is separated into several sections for the different operating modes (MOM,SOM,FOM) and that code and data will be placed in such sections based on tags that are assigned to the objects in the file app.config (at least for the application part). Based on this file and other placement information Python scripts will create the linker script file for linking.
Looking at the memory map described in the linker script file, I see some gaps. Can somebody explain what these gaps are used for?
For example:

0x10000000-0x10001600
0x10002000-0x10002F00
0x10010000-0x10013400

Also I have the impression that comments/documentation is not up-to-date with the linker script template file.

In case our use of the module will not utilize the SOM and MOM operation modes, will it be possible to allocate this RAM space dedicated to SOM/MOM mode to the FOM mode?

I tried the makefile to build the demos and it seems that the makefile is not fully correct with respect to dependency checking. Make will awlays build all objects regardless if they were touched or not. It seems to be related to an issue in the makefile comparing source and object files at the wrong file location.
Overall I think that the build system is quite slow, especially due to the python script that generates the linker script. I understand that each and every object file needs to be scanned to place the content to the configured sections. Anyway, if someone wants to speed things up a bit, I recommend pypy.org, which makes this process faster, just to mention.

The final output of the build seems to be an executable ELF file which is directly flashed to the external FLASH. Just for my understanding, because I have never used an executable ELF before:
Does that mean that the bootloader will have a sort of an ELF loader included that loads the RAM sections at the right locations in RAM and execute the FLASH part directly from the ELF file?

If the above is true, that means that the code size is basically the size of the ELF file plus WiFi/BT firmware plus filesystem content. For the simple helloWorld demo this seems to be roughly 650kByte, which seems to be a lot.
Is there any way to further reduce the size of a build by removing SW parts that will not be used? Or is all of this done by the linker and the number above is already the minimum size possible?

Sorry for the long post, but maybe it helps also others to better understand the insights.

Thanks and best regards

Andreas