Minimum.exe Text Size Outliers
Christian Mauderer
oss at c-mauderer.de
Tue May 25 18:33:53 UTC 2021
Hello Joel,
On 25/05/2021 19:10, Joel Sherrill wrote:
> Thanks for the feedback. I did save all of the minimum.exe files as
> @CPU at -@BSP at -minimum.exe so they could be analysed. For exe, I did a
> size, the tail -5, and also looked for some symbols that are hints of
> dependency chains to things not needed. close(), atexit(), and
> rtems_libio_post_driver() being the ones I know of now. I also did a
> similar check for the bsp_fdt_blob since that does indicate a large area
> is being reserved.
>
> I agree that bsp_fdt_blob() is in "r" memory and being included in the
> text report. Not sure if that's right since you are implying it is
> copied into so I would have expected BSS.
Depends on the BSP: Some have it read only. Some have it read write. For
the BSPs that have it read only it can still be correct. Take Beagle or
i.MX7 as an example: These BSPs expect the following boot:
- U-Boot runs
- U-Boot reads the application from some storage like eMMC and loads it
into memory at the right location.
- U-Boot reads the FDT blob from some storage and loads it into the
memory somewhere without knowing where it should be.
- U-Boot puts the location of the FDT into one register and then starts
the RTEMS application.
- RTEMS does _very_ few basic initialization. Then it reads the register
and copies the FDT to wherever it expects it. I think it's even done
before other segments (like BSS) would be initialized. It's certainly
done before MMU is set up.
- The FDT is never changed after that.
So for BSPs that only run from RAM putting FDT into a "read only"
section is completely OK. It's not OK for BSPs that might run from real
read only storage like flash. If such a BSP would use that method, it
would be a bug.
>
> I thought Sebastian added a "malloc" for the BSP to use before the heap
> was initialized. But I don't remember the name. Am I remembering correctly?
I don't really know that malloc. But I doubt that it works that early.
Again: Copying the FDT is one of the first things that these BSPs do. If
you want to know the exact location: For ARM it's here:
https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325
So it's really basic setup before that. It's interrupt stack, switching
modes, setup stack pointer and then it's already copy FDT.
>
> It is promising that 24 of the BSPs do have the FDT blob. Getting that
> out of the .text section report would possibly drop about half of the
> BSPs' minimum below 64k. Plus I expect some like pc386 and
> motorola_powerpc are > 64k for good reasons not worth investigating.
Which of the BSPs are left on the list if you cross out the ones with
the FDT blob?
Best regards
Christian
>
> --joel
>
> On Tue, May 25, 2021 at 10:13 AM Christian MAUDERER
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> Hello Joel,
>
> I think we currently have very few BSPs with a linked in device tree
> blob. I know only of the new imxrt (which isn't in your list) and I
> think one Xilinx something BSP.
>
> For imx: I only have a build for some minimum based on 5 at hand right
> now. I have to re-build an up to date version to double check that. For
> this BSP there is 0x000069bc text size and 0x00040ebc rodata. So the
> rodata is the odd part.
>
> nm -S --size-sort
> ./build/b-imx7/arm-rtems5/c/imx7/testsuites/samples/minimum.exe |
> tail -5
>
> gives a
>
> 80205e40 000004e0 T memcpy
> 80203a00 0000078c T _IO_Vprintf
> 80300c2c 00000a00 B bsp_interrupt_handler_table
> 80301ac0 00001000 B _ISR_Stack_area_begin
> 80207080 00040000 r bsp_fdt_blob
>
> So yes: For some reason there is a big bsp_fdt_blob there even if none
> should be linked in. I had a look at that variable:
>
> https://git.rtems.org/rtems/tree/bsps/shared/start/bsp-fdt.c
> <https://git.rtems.org/rtems/tree/bsps/shared/start/bsp-fdt.c>
>
> U-Boot passes a FDT blob and the BSP copies it into that area that is
> reserved with a fixed size. Seems reasonable because we can't easily
> allocate memory when we copy the FDT. It's done during initialization
> and therefore there is no heap yet.
>
> If you still have the binaries: Maybe you can call the nm command like
> above for the other BSPs too so we can see what the biggest objects are?
>
> Best regards
>
> Christian
>
> Am 24.05.21 um 15:00 schrieb Joel Sherrill:
> > Hi
> >
> > I built all 187 BSPs overnight and saved minimum.exe. Although I
> think
> > 64K is still too much code, I am using that as an initial cutoff
> when
> > asking for some help in identifying why minimum.exe is surprisingly
> > large for some BSPs. 146 stayed under 64k which leaves 41 needing
> some
> > investigation or explanation. I suspect some might have a device
> tree
> > blob linked in. The surprising ones are the riscv, stmh7, beagle,
> and qoriq.
> >
> > Here is the list:
> >
> > 73680 504 34135552 34209736 209ffc8
> > minimum-exes/arm-nucleo-h743zi-minimum.exe
> > 73680 504 34135552 34209736 209ffc8
> > minimum-exes/arm-stm32h7-minimum.exe
> > 88509 452 268346424 268435385 fffffb9
> > minimum-exes/riscv-frdme310arty-minimum.exe
> > 88647 760 67019328 67108735 3ffff7f
> > minimum-exes/riscv-rv64imac_medany-minimum.exe
> > 88697 760 67019328 67108785 3ffffb1
> > minimum-exes/riscv-rv64imac-minimum.exe
> > 88947 760 67019072 67108779 3ffffab
> > minimum-exes/riscv-rv64imafdc-minimum.exe
> > 88955 760 67019072 67108787 3ffffb3
> > minimum-exes/riscv-rv64imafdc_medany-minimum.exe
> > 89279 452 67019064 67108795 3ffffbb
> > minimum-exes/riscv-rv32imac-minimum.exe
> > 89561 452 67018808 67108821 3ffffd5
> > minimum-exes/riscv-rv32imafc-minimum.exe
> > 89577 452 67018744 67108773 3ffffa5
> > minimum-exes/riscv-rv32imafdc-minimum.exe
> > 90267 452 67018040 67108759 3ffff97
> > minimum-exes/riscv-rv32iac-minimum.exe
> > 96523 760 67011520 67108803 3ffffc3
> > minimum-exes/riscv-rv64imafd_medany-minimum.exe
> > 96547 760 67011456 67108763 3ffff9b
> > minimum-exes/riscv-rv64imafd-minimum.exe
> > 97787 452 67010536 67108775 3ffffa7
> > minimum-exes/riscv-rv32im-minimum.exe
> > 98071 452 67010296 67108819 3ffffd3
> > minimum-exes/riscv-rv32imafd-minimum.exe
> > 99587 452 67008744 67108783 3ffffaf
> > minimum-exes/riscv-rv32i-minimum.exe
> > 100328 9148 24320 133796 20aa4
> minimum-exes/i386-pc386-minimum.exe
> > 103344 9436 24256 137036 2174c
> minimum-exes/i386-pcp4-minimum.exe
> > 108836 9148 24320 142304 22be0
> minimum-exes/i386-pc486-minimum.exe
> > 111956 9148 24320 145424 23810
> minimum-exes/i386-pc586-minimum.exe
> > 112148 9372 24256 145776 23970
> > minimum-exes/i386-pc586-sse-minimum.exe
> > 114612 9148 24320 148080 24270
> minimum-exes/i386-pc686-minimum.exe
> > 121013 19128 93696 233837 3916d
> > minimum-exes/powerpc-mvme5500-minimum.exe
> > 123765 22980 379760 526505 808a9
> > minimum-exes/powerpc-qemuprep-minimum.exe
> > 124253 22916 380484 527653 80d25
> > minimum-exes/powerpc-mvme2100-minimum.exe
> > 126669 23060 379760 529489 81451
> > minimum-exes/powerpc-qemuprep-altivec-minimum.exe
> > 129820 1024 11872 142716 22d7c
> minimum-exes/mips-malta-minimum.exe
> > 130673 24324 380496 535493 82bc5
> > minimum-exes/powerpc-mtx603e-minimum.exe
> > 130977 24380 380496 535853 82d2d
> > minimum-exes/powerpc-mcp750-minimum.exe
> > 131029 24240 380496 535765 82cd5
> > minimum-exes/powerpc-mvme2307-minimum.exe
> > 154493 23912 92876 271281 423b1
> > minimum-exes/powerpc-beatnik-minimum.exe
> > 168173 27216 25081 220470 35d36
> > minimum-exes/powerpc-mvme3100-minimum.exe
> > 289136 424 535532700 535822260 1fefffb4
> > minimum-exes/arm-imx7-minimum.exe
> > 312308 7964 66788536 67108808 3ffffc8
> > minimum-exes/powerpc-qoriq_core_1-minimum.exe
> > 312340 8036 33277808 33598184 200aae8
> > minimum-exes/powerpc-qoriq_core_0-minimum.exe
> > 312340 8036 519817056 520137432 1f00aad8
> > minimum-exes/powerpc-qoriq_e500-minimum.exe
> > 316944 8060 519816888 520141892 1f00bc44
> > minimum-exes/powerpc-qoriq_e6500_32-minimum.exe
> > 331076 1304 519814736 520147116 1f00d0ac
> > minimum-exes/powerpc-qoriq_e6500_64-minimum.exe
> >
> > Help in reducing and/or explaining is appreciated.
> >
> > --joel
> >
> >
> >
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> phone: +49-89-18 94 741 - 18
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> <https://embedded-brains.de/datenschutzerklaerung/>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
More information about the devel
mailing list