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 <o...@c-mauderer.de <mailto:o...@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.hu...@embedded-brains.de
    <mailto:sebastian.hu...@embedded-brains.de>
     > <mailto:sebastian.hu...@embedded-brains.de
    <mailto:sebastian.hu...@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.hu...@embedded-brains.de
    <mailto:sebastian.hu...@embedded-brains.de>
     >     <mailto:sebastian.hu...@embedded-brains.de
    <mailto:sebastian.hu...@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.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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to