Minimum.exe Text Size Outliers

[Christian MAUDERER]

Hello Joel,

Am 26.05.21 um 22:47 schrieb Joel Sherrill:
> Another minimum size report. If the text size after
> subtracting the FDT blob is below 64K, the BSP is not
> in the report. The adjusted size is reported.
> 
> It looks like some significant percentage of those over 64k
> are managing to pull in printf or something in the family. I
> wonder if we should ban printf() from BSPs and drivers in favor
> of printk?

I think it depends on the use case.

I'm not sure why a driver should print anything (except for errors where 
printk is most likely the better choice). But there might can be good 
reasons. And I wouldn't even guarantee that I didn't add some myself. So 
it will be a case by case decision.

Best regards

Christian

> 
> --joel
> 
> On Wed, May 26, 2021 at 1:14 PM Christian Mauderer <oss at c-mauderer.de 
> <mailto:oss at c-mauderer.de>> wrote:
> 
> 
> 
>     On 26/05/2021 19:23, Joel Sherrill wrote:
>      >
>      >
>      > On Wed, May 26, 2021 at 6:02 AM Sebastian Huber
>      > <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>      > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>      >
>      >     On 25/05/2021 20:33, Christian Mauderer wrote:
>      >      >
>      >      >>
>      >      >> 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
>     <https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325>
>      >   
>       <https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325 <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.
>      >
>      >     Yes, there is an early "malloc". This is _Memory_Allocate() using
>      >     _Memory_Get(). However, for the device tree copy this is not
>     early
>      >     enough. We don't know the device tree location provided by
>     the boot
>      >     loader. It could be somewhere in the memory area used by the
>      >     application. So, it is important to copy this very early into
>     a fixed
>      >     location. Also, the device tree may be used to get the size
>     of the
>      >     memory provided by _Memory_Get().
>      >
>      >
>      > I assume read-only is only from the perspective of higher level
>      > language code. Is it possible that being read-only it could be
>      > mapped to Flash?
> 
>     If the code is mapped to flash, the BSP is broken. I think there are
>     options for such a case so that the FDT is placed in another section.
>     Not sure whether any BSP is using them.
> 
>     This kind of copy should be only done on BSPs that run out of RAM. Like
>     I said earlier: Normally that's the case for BSPs that are loaded by
>     U-Boot.
> 
>      >
>      > For the purposes of minimum size analysis, I will subtract the
>      > size of the FDT block from the minimum .text size and if it
>      > is still over 64, flag it.
> 
>     Sounds reasonable.
> 
>     Best regards
> 
>     Christian
> 
>      >
>      > --joel
>      >
>      >
>      >     --
>      >     embedded brains GmbH
>      >     Herr Sebastian HUBER
>      >     Dornierstr. 4
>      >     82178 Puchheim
>      >     Germany
>      >     email: sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>      >     <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>
>      >     phone: +49-89-18 94 741 - 16
>      >     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/>
>      >     <https://embedded-brains.de/datenschutzerklaerung/
>     <https://embedded-brains.de/datenschutzerklaerung/>>
>      >
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: 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/