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@-@b...@-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.maude...@embedded-brains.de
<mailto:christian.maude...@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@rtems.org <mailto:devel@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.maude...@embedded-brains.de
<mailto:christian.maude...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
