Re: About interrupt processing

[Sebastian Huber]

On 24/05/2021 11:45, Richi Dubey wrote:
So, can someone please help me know what gets executed right after the 
interrupt is accepted by the CPU from the IRQ? Can someone point me to 
the source code - where the CPU possibly checks the value of heir and 
does a context switch?


This is done in the architecture-specific interrupt and context switch 
code, for example:


cpukit/score/cpu/arm/arm_exc_interrupt.S

cpukit/score/cpu/arm/cpu_asm.S

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About interrupt processing

[Richi Dubey]

Thank you.

On Tue, May 25, 2021 at 12:32 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 24/05/2021 11:45, Richi Dubey wrote:
> > So, can someone please help me know what gets executed right after the
> > interrupt is accepted by the CPU from the IRQ? Can someone point me to
> > the source code - where the CPU possibly checks the value of heir and
> > does a context switch?
>
> This is done in the architecture-specific interrupt and context switch
> code, for example:
>
> cpukit/score/cpu/arm/arm_exc_interrupt.S
>
> cpukit/score/cpu/arm/cpu_asm.S
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: 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/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS_VERSION on 5 branch

[Christian MAUDERER]

Hello,

if I build a BSP on the 5 branch, I still have the following defines in 
cpuopts.h:


#define RTEMS_VERSION "5.0.0"
#define __RTEMS_MAJOR__ 5
#define __RTEMS_MINOR__ 0
#define __RTEMS_REVISION__ 0

We are past 5.1. Is it an expected behavior that the 5 branch head still 
tells that it is a 5.0.0? Did I do something unexpected when compiling 
and everyone else gets a 5.1? Any pointers what would have to be fixed?


Best regards

Christian
--

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

RE: [PATCH v1 1/6] bsps/aarch64: Break out system registers

[Kinsey Moore]

Great, I'll substitute this for the partial one I've created.

Thanks,
Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Monday, May 24, 2021 23:51
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 1/6] bsps/aarch64: Break out system registers

Hello Kinsey,

I have a (hopefully) complete set of system register functions and 
defines generated by a script from the reference manual.  Maybe we can 
add this header to 
"cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h".

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

[Kinsey Moore]

There now exists a patch to fix the problem but, as best I can tell, it has not 
yet been incorporated into a binutils release:
 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eac4eb8ecb2626ef7711d8f6bee9e870ae435604

I'll update the comment to reference https://devel.rtems.org/ticket/4218

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Monday, May 24, 2021 23:55
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

On 24/05/2021 22:29, Kinsey Moore wrote:
> +# don't compile due to toolchain issues
> +spconfig01: exclude
> +spmisc01: exclude

Is this still the case?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Minimum.exe Text Size Outliers

[Christian MAUDERER]

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 0x69bc 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 04e0 T memcpy
80203a00 078c T _IO_Vprintf
80300c2c 0a00 B bsp_interrupt_handler_table
80301ac0 1000 B _ISR_Stack_area_begin
80207080 0004 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

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       fb9 
minimum-exes/riscv-frdme310arty-minimum.exe
   88647     760 67019328        67108735        37f 
minimum-exes/riscv-rv64imac_medany-minimum.exe
   88697     760 67019328        67108785        3b1 
minimum-exes/riscv-rv64imac-minimum.exe
   88947     760 67019072        67108779        3ab 
minimum-exes/riscv-rv64imafdc-minimum.exe
   88955     760 67019072        67108787        3b3 
minimum-exes/riscv-rv64imafdc_medany-minimum.exe
   89279     452 67019064        67108795        3bb 
minimum-exes/riscv-rv32imac-minimum.exe
   89561     452 67018808        67108821        3d5 
minimum-exes/riscv-rv32imafc-minimum.exe
   89577     452 67018744        67108773        3a5 
minimum-exes/riscv-rv32imafdc-minimum.exe
   90267     452 67018040        67108759        397 
minimum-exes/riscv-rv32iac-minimum.exe
   96523     760 67011520        67108803        3c3 
minimum-exes/riscv-rv64imafd_medany-minimum.exe
   96547     760 67011456        67108763        39b 
minimum-exes/riscv-rv64imafd-minimum.exe
   97787     452 67010536        67108775        3a7 
minimum-exes/riscv-rv32im-minimum.exe
   98071     452 67010296        67108819        3d3 
minimum-exes/riscv-rv32imafd-minimum.exe
   99587     452 67008744        67108783        3af 
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        3c8 
minimum-exes/powerpc-qoriq_core_1-minimum.exe
  312340    8036 33277808        33598184        200aae8 
minimu

Re: Minimum.exe Text Size Outliers

[Joel Sherrill]

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.

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?

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.

--joel

On Tue, May 25, 2021 at 10:13 AM Christian MAUDERER <
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 0x69bc 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 04e0 T memcpy
> 80203a00 078c T _IO_Vprintf
> 80300c2c 0a00 B bsp_interrupt_handler_table
> 80301ac0 1000 B _ISR_Stack_area_begin
> 80207080 0004 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
>
> 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 3413555234209736209ffc8
> > minimum-exes/arm-nucleo-h743zi-minimum.exe
> >73680 504 3413555234209736209ffc8
> > minimum-exes/arm-stm32h7-minimum.exe
> >88509 452 268346424   268435385   fb9
> > minimum-exes/riscv-frdme310arty-minimum.exe
> >88647 760 670193286710873537f
> > minimum-exes/riscv-rv64imac_medany-minimum.exe
> >88697 760 67019328671087853b1
> > minimum-exes/riscv-rv64imac-minimum.exe
> >88947 760 67019072671087793ab
> > minimum-exes/riscv-rv64imafdc-minimum.exe
> >88955 760 67019072671087873b3
> > minimum-exes/riscv-rv64imafdc_medany-minimum.exe
> >89279 452 67019064671087953bb
> > minimum-exes/riscv-rv32imac-minimum.exe
> >89561 452 67018808671088213d5
> > minimum-exes/riscv-rv32imafc-minimum.exe
> >89577 452 67018744671087733a5
> > minimum-exes/riscv-rv32imafdc-minimum.exe
> >90267 452 6701804067108759397
> > minimum-exes/riscv-rv32iac-minimum.exe
> >96523 760 67011520671088033c3
> > minimum-exes/riscv-rv64imafd_medany-minimum.exe
> >96547 760 670114566710876339b
> > minimum-exes/riscv-rv64imafd-minimum.exe
> >97787 452 67010536671087753a7
> > minimum-exes/riscv-rv32im-minimum.exe
> >98071 452 67010296671088193d3
> > minimum-exes/riscv-rv32imafd-minimum.exe
> >99587 452 67008744671087833af
> > minimum-exes/riscv-rv32i-minimum.exe
> >   1003289148   24320  133796   20aa4
> minimum-exes/i386-pc386-minimum.exe
> >   1033449436   24256  137036   2174c
> minimum-exes/i386-pcp4-minimum.exe
> >   1088369148   24320  142304   22be0
> minimum-exes/i386-pc48

Re: [PATCH 0/2] covoar: Dispose of file info in ExecutableInfo

[Alex White]

ping :)


From: Alex White 
Sent: Friday, April 30, 2021 3:01 PM
To: devel@rtems.org 
Cc: Alex White 
Subject: [PATCH 0/2] covoar: Dispose of file info in ExecutableInfo

This patch set includes two patches that significantly lower the memory
usage of covoar. For a full coverage run of the leon3 BSP on my
machine, the peak memory usage falls from 9.6 GB down to 1.4 GB.

The cleanup of the ELF and DWARF info had previously been moved from
the ExecutableInfo class's constructor to its destructor. This was done
to ensure that ExecutableInfo::getSourceAndLine() could utilize the
DWARF info. A side effect of that change was increased memory usage.

These patches ensure that no ELF or DWARF objects are held by the
ExecutableInfo class after construction.

Alex White (2):
  covoar: Store only the file name in ExecutableInfo
  covoar: Store address-to-line info outside of DWARF

 rtemstoolkit/rld-dwarf.cpp   |   5 +
 rtemstoolkit/rld-dwarf.h |   5 +
 tester/covoar/AddressToLineMapper.cc | 105 +++
 tester/covoar/AddressToLineMapper.h  | 193 +++
 tester/covoar/ExecutableInfo.cc  |  85 ++--
 tester/covoar/ExecutableInfo.h   |  15 ++-
 tester/covoar/wscript|   1 +
 7 files changed, 358 insertions(+), 51 deletions(-)
 create mode 100644 tester/covoar/AddressToLineMapper.cc
 create mode 100644 tester/covoar/AddressToLineMapper.h

--
2.27.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Minimum.exe Text Size Outliers

[Christian Mauderer]

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 
> 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 0x69bc 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 04e0 T memcpy
80203a00 078c T _IO_Vprintf
80300c2c 0a00 B bsp_interrupt_handler_table
80301ac0 1000 B _ISR_Stack_area_begin
80207080 0004 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


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-mi

Re: Minimum.exe Text Size Outliers

[Christian Mauderer]

Hello Joel,

missed the attachement. So if we leave out the ones with bsp_fdt_blob 
and the ones that you marked with "FOUND close()" that leaves the 
following ones (if I didn't miss any):


=== arm-nucleo-h743zi-minimum.exe =
=== arm-stm32h7-minimum.exe =
=== i386-pc386-minimum.exe =
=== i386-pc486-minimum.exe =
=== i386-pc586-minimum.exe =
=== i386-pc586-sse-minimum.exe =
=== i386-pc686-minimum.exe =
=== i386-pcp4-minimum.exe =
=== mips-malta-minimum.exe =

Already a quite short list where it's unclear why they are so big.

I assume the ones with close() need some work. But at least it's already 
at least a trace why they are so big.


Best regards

Christian


On 25/05/2021 20:33, Christian Mauderer wrote:

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 
> 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 0x69bc 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 04e0 T memcpy
    80203a00 078c T _IO_Vprintf
    80300c2c 0a00 B bsp_interrupt_handler_table
    80301ac0 1000 B _ISR_Stack_area_begin
    80207080 0004 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
    

    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 s

Re: Minimum.exe Text Size Outliers

[Joel Sherrill]

On Tue, May 25, 2021 at 1:57 PM Christian Mauderer 
wrote:

> Hello Joel,
>
> missed the attachement. So if we leave out the ones with bsp_fdt_blob
> and the ones that you marked with "FOUND close()" that leaves the
> following ones (if I didn't miss any):
>
> === arm-nucleo-h743zi-minimum.exe =
> === arm-stm32h7-minimum.exe =
> === i386-pc386-minimum.exe =
> === i386-pc486-minimum.exe =
> === i386-pc586-minimum.exe =
> === i386-pc586-sse-minimum.exe =
> === i386-pc686-minimum.exe =
> === i386-pcp4-minimum.exe =
> === mips-malta-minimum.exe =
>
> Already a quite short list where it's unclear why they are so big.
>
> I assume the ones with close() need some work. But at least it's already
> at least a trace why they are so big.
>

There may be other symbols that are not supposed to be there but
we haven't identified them yet.

New report attached. This one is a bit smarter. It does not include BSPs
with text < 65536 bytes or that have the FDT blob symbol. This leaves 18
BSPs.

It also checks for __wrap_printf. At least all the motorola_powerpc BSPs
reference that and _vfprintf() is 10K. That ignores what else might be
pulled
in as a side-effect.

One thing I decided to try was to see how much of
arm-nucleo-h743zi-minimum.exe
was HAL_ code. 7160 of 73680. Just scanning the symbols sorted by size,
this looks
like a combination of bulky BSP and HAL. I don't know this BSP well enough
to
see if something could be eliminated. Just a lot of arm and BSP symbols.

FWIW printk and _IO_Vprintf are about 4K on BSPs with 32-bit instructions.

--joel

But

>
> Best regards
>
> Christian
>
>
> On 25/05/2021 20:33, Christian Mauderer wrote:
> > 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
> >>  >> > wrote:
> >>
> >> Hello Joel,
> >>
> >> I think we currently have very few BSPs with a linked in device tree
> >> blob. I know o

Re: RTEMS_VERSION on 5 branch

[Chris Johns]

On 25/5/21 8:56 pm, Christian MAUDERER wrote:
> Hello,

Great question :)

> if I build a BSP on the 5 branch, I still have the following defines in 
> cpuopts.h:
> 
> #define RTEMS_VERSION "5.0.0"
> #define __RTEMS_MAJOR__ 5
> #define __RTEMS_MINOR__ 0
> #define __RTEMS_REVISION__ 0
> 
> We are past 5.1. Is it an expected behavior that the 5 branch head still tells
> that it is a 5.0.0? 

It is expected.

> Did I do something unexpected when compiling and everyone
> else gets a 5.1? 

You have not done anything wrong.

> Any pointers what would have to be fixed?

These settings indicate the build is from the release branch. If we updated
these values to reflect the next release we would then have a number of
differing tarballs in the wild with the same values, for example release
candidates that have different contents.

Consider the branch settings as "NOT-RELEASED". If you are deploying from a
release branch for internal or customer focused reasons add a VERSION file to
the top of the released sources. I know rtems-tools and the RSB support this but
I am not sure rtems.git waf does. I think it should and have it as part of the
release activities for RTEMS 6. A single VERSION file is easy to audit.

Note, there is a subtle corner case here. If you perform all your testing for a
release on a specific git hash and then perform a further commit to set the
"VERSION" for the release the git hash you tested and the hash you release are
not the same and there is ability to link one to the other. You also need a
further commit to move the branch past the release commit or you potentially
have the same information in more than one release testing tarball. The "release
commit" can be branched and this is problematic to manage. As a result the
branch defaults to "NOT-RELEASED" automatically on all commits it has and we add
a VERSION file to manage the version. The tarball checksum manages the integrity
of the files.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] covoar: Store only the file name in ExecutableInfo

[Chris Johns]

On 4/5/21 7:07 pm, Gedare Bloom wrote:
> On Fri, Apr 30, 2021 at 2:02 PM Alex White  wrote:
>>
>> This changes the ExecutableInfo class to only store the executable
>> file's name rather than an entire instance of rld::files::object. This
>> allows the rld::files::object to be cleaned up in the ExecutableInfo
>> constructor.
>>
>> Updates #4383
>> ---
>>  tester/covoar/ExecutableInfo.cc | 12 +---
>>  tester/covoar/ExecutableInfo.h  | 10 +-
>>  2 files changed, 10 insertions(+), 12 deletions(-)
>>
>> diff --git a/tester/covoar/ExecutableInfo.cc 
>> b/tester/covoar/ExecutableInfo.cc
>> index fc368ce..861e60d 100644
>> --- a/tester/covoar/ExecutableInfo.cc
>> +++ b/tester/covoar/ExecutableInfo.cc
>> @@ -21,7 +21,7 @@ namespace Coverage {
>>  const char* const theExecutableName,
>>  const char* const theLibraryName,
>>  bool  verbose
>> -) : executable(theExecutableName),
>> +) : fileName(theExecutableName),
>>  loadAddress(0)
>>{
>>  if (theLibraryName != nullptr)
>> @@ -34,6 +34,8 @@ namespace Coverage {
>>std::cerr << std::endl;
>>  }
>>
>> +rld::files::object executable(theExecutableName);
>> +
>>  executable.open();
>>  executable.begin();
>>  executable.load_symbols(symbols);
>> @@ -82,8 +84,6 @@ namespace Coverage {
>>}
>>  } catch (...) {
>>debug.end();
>> -  executable.end();
>> -  executable.close();
> 
> I may be missing something, but don't you still need to end() and close() it?
> 

The object is now local scope so the object destructs when control exits the
block and that should clean things up.

Chris

>>throw;
>>  }
>>
>> @@ -95,8 +95,6 @@ namespace Coverage {
>>ExecutableInfo::~ExecutableInfo()
>>{
>>  debug.end();
>> -executable.end();
>> -executable.close();
>>}
>>
>>void ExecutableInfo::dumpCoverageMaps( void ) {
>> @@ -132,9 +130,9 @@ namespace Coverage {
>>  return aCoverageMap;
>>}
>>
>> -  const std::string ExecutableInfo::getFileName ( void ) const
>> +  const std::string& ExecutableInfo::getFileName ( void ) const
>>{
>> -return executable.name().full();
>> +return fileName;
>>}
>>
>>const std::string ExecutableInfo::getLibraryName( void ) const
>> diff --git a/tester/covoar/ExecutableInfo.h b/tester/covoar/ExecutableInfo.h
>> index d5ccb19..5d5a595 100644
>> --- a/tester/covoar/ExecutableInfo.h
>> +++ b/tester/covoar/ExecutableInfo.h
>> @@ -77,7 +77,7 @@ namespace Coverage {
>>   *
>>   *  @return Returns the executable's file name
>>   */
>> -const std::string getFileName( void ) const;
>> +const std::string& getFileName( void ) const;
>>
>>  /*!
>>   *  This method returns the library name associated with the executable.
>> @@ -158,14 +158,14 @@ namespace Coverage {
>>  );
>>
>>  /*!
>> - *  The ELF executable.
>> + *  The DWARF data to the ELF executable.
>>   */
>> -rld::files::object executable;
>> +rld::dwarf::file debug;
>>
>>  /*!
>> - *  The DWARF data to the ELF executable.
>> + *  The executable's file name.
>>   */
>> -rld::dwarf::file debug;
>> +std::string fileName;
>>
>>  /*!
>>   *  The executable's symbol table.
>> --
>> 2.27.0
>>
>> ___
>> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] covoar: Store address-to-line info outside of DWARF

[Chris Johns]

On 1/5/21 8:01 am, Alex White wrote:
> This adds the AddressToLineMapper class and supporting classes to
> assume responsibility of tracking address-to-line information.
> 
> This allows the DWARF library to properly cleanup all of its resources
> and leads to significant memory savings.
> 
> Closes #4383
> ---
>  rtemstoolkit/rld-dwarf.cpp   |   5 +
>  rtemstoolkit/rld-dwarf.h |   5 +
>  tester/covoar/AddressToLineMapper.cc | 105 +++
>  tester/covoar/AddressToLineMapper.h  | 193 +++
>  tester/covoar/ExecutableInfo.cc  |  73 +-
>  tester/covoar/ExecutableInfo.h   |  11 +-
>  tester/covoar/wscript|   1 +
>  7 files changed, 351 insertions(+), 42 deletions(-)
>  create mode 100644 tester/covoar/AddressToLineMapper.cc
>  create mode 100644 tester/covoar/AddressToLineMapper.h
> 
> diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> index 2fce0e4..1eae50c 100644
> --- a/rtemstoolkit/rld-dwarf.cpp
> +++ b/rtemstoolkit/rld-dwarf.cpp
> @@ -1893,6 +1893,11 @@ namespace rld
>return false;
>  }
>  
> +const addresses& compilation_unit::get_addresses () const
> +{
> +  return addr_lines_;
> +}
> +
>  functions&
>  compilation_unit::get_functions ()
>  {
> diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> index 1210813..eadb50d 100644
> --- a/rtemstoolkit/rld-dwarf.h
> +++ b/rtemstoolkit/rld-dwarf.h
> @@ -707,6 +707,11 @@ namespace rld
> */
>unsigned int pc_high () const;
>  
> +  /**
> +   * The addresses associated with this compilation unit.
> +   */
> +  const addresses& get_addresses () const;
> +
>/**
> * Get the source and line for an address. If the address does not 
> match
> * false is returned the file is set to 'unknown' and the line is set 
> to
> diff --git a/tester/covoar/AddressToLineMapper.cc 
> b/tester/covoar/AddressToLineMapper.cc
> new file mode 100644
> index 000..1062fd7
> --- /dev/null
> +++ b/tester/covoar/AddressToLineMapper.cc
> @@ -0,0 +1,105 @@
> +/*! @file AddressToLineMapper.cc
> + *  @brief AddressToLineMapper Implementation
> + *
> + *  This file contains the implementation of the functionality
> + *  of the AddressToLineMapper class.
> + */
> +
> +#include "AddressToLineMapper.h"
> +
> +namespace Coverage {
> +
> +  uint64_t SourceLine::location() const
> +  {
> +return address;
> +  }
> +
> +  bool SourceLine::is_an_end_sequence() const
> +  {
> +return is_end_sequence;
> +  }
> +
> +  std::string SourceLine::path() const
> +  {
> +return *sourceIterator;
> +  }
> +
> +  uint64_t SourceLine::line() const
> +  {
> +return line_num;
> +  }
> +
> +  void AddressLineRange::addSourceLine(const rld::dwarf::address& address)
> +  {
> +auto insertResult = sourcePaths.insert(address.path());
> +
> +sourceLines.emplace_back(
> +  SourceLine (
> +address.location(),
> +insertResult.first,
> +address.line(),
> +address.is_an_end_sequence()
> +  )
> +);
> +  }
> +
> +  const SourceLine* AddressLineRange::getSourceLine(uint32_t address) const
> +  {
> +if (address < lowAddress || address > highAddress) {
> +  return nullptr;
> +}
> +
> +const SourceLine* last_line = nullptr;
> +for (const auto &line : sourceLines) {
> +  if (address <= line.location())
> +  {
> +if (address == line.location())
> +  last_line = &line;
> +break;
> +  }
> +  last_line = &line;
> +}
> +
> +return last_line;
> +  }
> +
> +  void AddressToLineMapper::getSource(
> +uint32_t address,
> +std::string& sourceFile,
> +int& sourceLine
> +  ) const {
> +sourceFile = "unknown";
> +sourceLine = -1;
> +
> +const SourceLine* match = nullptr;
> +for (const auto &range : addressLineRanges) {
> +  const SourceLine* potential_match = range.getSourceLine(address);
> +
> +  if (potential_match != nullptr) {
> +if (match == nullptr) {
> +  match = potential_match;
> +} else if (match->is_an_end_sequence() || 
> !potential_match->is_an_end_sequence()) {
> +  match = potential_match;
> +}
> +  }
> +}
> +
> +if (match != nullptr) {
> +  sourceFile = match->path();
> +  sourceLine = match->line();
> +}
> +  }
> +
> +  AddressLineRange& AddressToLineMapper::makeRange(
> +uint32_t low,
> +uint32_t high
> +  )
> +  {
> +addressLineRanges.emplace_back(
> +  AddressLineRange(low, high)
> +);
> +
> +return addressLineRanges.back();
> +  }
> +
> +}
> diff --git a/tester/covoar/AddressToLineMapper.h 
> b/tester/covoar/AddressToLineMapper.h
> new file mode 100644
> index 000..ee0a633
> --- /dev/null
> +++ b/tester/covoar/AddressToLineMapper.h
> @@ -0,0 +1,193 @@
> +/*! @file AddressToLineMapper.h
> + *  @brief AddressToLineMapper Specification
> + *
> + *  This file cont

Re: RTEMS_VERSION on 5 branch

[Christian MAUDERER]

Hello Chris,

thanks for the detailed response. Should we add a bit of that to the 
doxygen documentation of the rtems_version_* functions so that I don't 
ask it again because I have forgotten it in a year?


Best regards

Christian

Am 26.05.21 um 01:24 schrieb Chris Johns:

On 25/5/21 8:56 pm, Christian MAUDERER wrote:

Hello,


Great question :)


if I build a BSP on the 5 branch, I still have the following defines in 
cpuopts.h:

#define RTEMS_VERSION "5.0.0"
#define __RTEMS_MAJOR__ 5
#define __RTEMS_MINOR__ 0
#define __RTEMS_REVISION__ 0

We are past 5.1. Is it an expected behavior that the 5 branch head still tells
that it is a 5.0.0?


It is expected.


Did I do something unexpected when compiling and everyone
else gets a 5.1?


You have not done anything wrong.


Any pointers what would have to be fixed?


These settings indicate the build is from the release branch. If we updated
these values to reflect the next release we would then have a number of
differing tarballs in the wild with the same values, for example release
candidates that have different contents.

Consider the branch settings as "NOT-RELEASED". If you are deploying from a
release branch for internal or customer focused reasons add a VERSION file to
the top of the released sources. I know rtems-tools and the RSB support this but
I am not sure rtems.git waf does. I think it should and have it as part of the
release activities for RTEMS 6. A single VERSION file is easy to audit.

Note, there is a subtle corner case here. If you perform all your testing for a
release on a specific git hash and then perform a further commit to set the
"VERSION" for the release the git hash you tested and the hash you release are
not the same and there is ability to link one to the other. You also need a
further commit to move the branch past the release commit or you potentially
have the same information in more than one release testing tarball. The "release
commit" can be branched and this is problematic to manage. As a result the
branch defaults to "NOT-RELEASED" automatically on all commits it has and we add
a VERSION file to manage the version. The tarball checksum manages the integrity
of the files.

Chris



--

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