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