The 'A' flag in the Flg column of the readelf output, which ELF calls SHF_ALLOC, indicates a section that 'occupies memory during process execution'.
SHF_ALLOC : The section occupies memory during process execution. Some control sections do not reside in the memory image of an object file; this attribute is off for those sections.
http://refspecs.linuxbase.org/elf/elf.pdf
Typically this applies to both program and data memory, and in a 'normal' OS environment the OS loads the SHF_ALLOC sections to the indicated addresses (ignoring or using for other purposes the non-SHF_ALLOC sections as appropriate) and everything's ready to go.
In an embedded environment with ROM program memory, only SHF_ALLOC sections mapping to addresses in ROM need to be output.
(This question illustrates a case in which going by address alone without taking SHF_ALLOC into account is not enough.)
However:
Depending on how the linker produced the ELF file, initialised data sections may or may not require additional handling.
Ideally the linker produces two sections related to initialised data: one in RAM (the runtime data area), and one in ROM (the initialisation contents for the RAM data). Startup code references the addresses of these sections and copies the init data to the RAM area. In this case simply outputting SHF_ALLOC sections in the ROM address range will automatically produce correct results.
If the linker instead produces a single section as if for a normal OS, then when generating the ROM image the data section needs to be identified and emitted at an address in ROM (and the startup code needs to be able to find that address).
Most decent toolchains take the former approach if configured correctly, but I've certainly worked with the latter as well.
