nanopi_a64 def config produces too big image

[sergey-suloev]

The config item "CONFIG_CIR=y" must be removed

[smaeul]

This is likely an issue with your toolchain having missing/broken support for link-time optimization (LTO).

Here's an excerpt from build/scp/scp.map after building with nanopi_a64_defconfig on my machine. As you can see, there are 0x704 bytes available between the firmware and the SCPI memory region.

 .data.system_state
                0x00000000000130a6        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
                0x00000000000130a8                . = ALIGN (0x4)
 *fill*         0x00000000000130a7        0x1
                0x0000000000000001                ASSERT ((SIZEOF (.data) == 0xc), Changes to .data persist after an exception!)

.bss            0x00000000000130a8       0x54
                0x00000000000130a8                __bss_start = .
 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bss*)))
 .bss.__compound_literal.0.lto_priv.0
                0x00000000000130a8       0x14 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.pwrctl    0x00000000000130bc        0x4 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.rvba      0x00000000000130c0        0x4 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.scpi_state
                0x00000000000130c4       0x10 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.1
                0x00000000000130d4        0xc /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.10
                0x00000000000130e0        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.2
                0x00000000000130e1        0xf /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.3
                0x00000000000130f0        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.4
                0x00000000000130f1        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.5
                0x00000000000130f2        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.6
                0x00000000000130f3        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.7
                0x00000000000130f4        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.8
                0x00000000000130f5        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.0.lto_priv.9
                0x00000000000130f6        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.__compound_literal.1.lto_priv.0
                0x00000000000130f7        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.lead_cluster
                0x00000000000130f8        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
 .bss.lead_core
                0x00000000000130f9        0x1 /tmp/ccAfOPan.ltrans0.ltrans.o
                0x00000000000130fc                . = ALIGN (0x4)
 *fill*         0x00000000000130fa        0x2
                0x00000000000130fc                __bss_end = .
                0x00000000000130fc                __stack_start = .
                0x00000000000134fc                . = (. + 0x400)
                0x00000000000134fc                __stack_end = .
                0x0000000000000001                ASSERT ((. <= 0x13c00), Firmware overflows allocated memory area)
                0x0000000000000001                ASSERT ((. <= 0x13c00), Firmware overflows into SCPI shared memory)
                0x0000000000013c00                __scpi_mem = 0x13c00

For reference, my compiler is gcc version 11.1.0 (GCC) built with a fork of musl-cross-make.

[sergey-suloev]

I am using this compiler http://musl.cc/or1k-linux-musl-cross.tgz

[sergey-suloev]

The issue disappeared after downloading the latest version of http://musl.cc/or1k-linux-musl-cross.tgz