<div dir="ltr"><div>Another minimum size report. If the text size after <br></div><div>subtracting the FDT blob is below 64K, the BSP is not</div><div>in the report. The adjusted size is reported.</div><div><br></div><div>It looks like some significant percentage of those over 64k</div><div>are managing to pull in printf or something in the family. I</div><div>wonder if we should ban printf() from BSPs and drivers in favor</div><div>of printk?</div><div><br></div><div>--joel<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 26, 2021 at 1:14 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"><br>
<br>
On 26/05/2021 19:23, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Wed, May 26, 2021 at 6:02 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
> <br>
> On 25/05/2021 20:33, Christian Mauderer wrote:<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<br>
> remembering<br>
> >> correctly?<br>
> ><br>
> > I don't really know that malloc. But I doubt that it works that<br>
> early.<br>
> > Again: Copying the FDT is one of the first things that these BSPs<br>
> do. If<br>
> > you want to know the exact location: For ARM it's here:<br>
> ><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>
> <<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,<br>
> switching<br>
> > modes, setup stack pointer and then it's already copy FDT.<br>
> <br>
> Yes, there is an early "malloc". This is _Memory_Allocate() using<br>
> _Memory_Get(). However, for the device tree copy this is not early<br>
> enough. We don't know the device tree location provided by the boot<br>
> loader. It could be somewhere in the memory area used by the<br>
> application. So, it is important to copy this very early into a fixed<br>
> location. Also, the device tree may be used to get the size of the<br>
> memory provided by _Memory_Get().<br>
> <br>
> <br>
> I assume read-only is only from the perspective of higher level<br>
> language code. Is it possible that being read-only it could be<br>
> mapped to Flash?<br>
<br>
If the code is mapped to flash, the BSP is broken. I think there are <br>
options for such a case so that the FDT is placed in another section. <br>
Not sure whether any BSP is using them.<br>
<br>
This kind of copy should be only done on BSPs that run out of RAM. Like <br>
I said earlier: Normally that's the case for BSPs that are loaded by U-Boot.<br>
<br>
> <br>
> For the purposes of minimum size analysis, I will subtract the<br>
> size of the FDT block from the minimum .text size and if it<br>
> is still over 64, flag it.<br>
<br>
Sounds reasonable.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> --joel<br>
> <br>
> <br>
> -- <br>
> embedded brains GmbH<br>
> Herr Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
> phone: +49-89-18 94 741 - 16<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 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>
</blockquote></div>