Hi Biju,

As you work with Renesas platforms, have you also seen

"Renesas rcar-gen3: cert_header_sa6 Compilation Issue"

which I reported on the mailing list on 10/12/2018 and is still not fixed?

tools\renesas\rcar_layout_create\sa6.c has


#include <stdint.h>


which causes compilation error on Yocto 3.13:


| aarch64-poky-linux-gcc -DRCAR_SA0_SIZE=1 -DRCAR_SA6_TYPE=0 -I../../include/lib/stdlib -D=AARCH64  -c -o sa6.o sa6.c
| In file included from sa6.c:7:0:
| /home/alexei/Work/Yocto_3.13_20181205/build/tmp/work/h3ulcb-poky-linux/arm-tf/2.0+gitAUTOINC+19b56cf4a2_556d7d9e3b-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
|  # include_next <stdint.h>
|                 ^~~~~~~~~~
| compilation terminated.
| <builtin>: recipe for target 'sa6.o' failed
| make[1]: *** [sa6.o] Error 1
| plat/renesas/rcar/platform.mk:403: recipe for target 'rcar_layout_tool' failed
| make: *** [rcar_layout_tool] Error 2
| ERROR: oe_runmake failed

There's no compilation error with gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf tool chain, because compiler
searches for <stdint.h> in
\gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\lib\gcc\aarch64-elf\8.2.1\include
finding "stdint.h" with
# include_next <stdint.h>
and then getting "stdint.h" from

gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\aarch64-elf\include folder.


Trusted Firmware-A Porting Guide reads that

"To avoid subtle toolchain behavioral dependencies, the header files provided

by the compiler are not used. The software is built with the ``-nostdinc`` flag
to ensure no headers are included from the toolchain inadvertently. ",

tools\renesas\rcar_layout_create\makefile has flags defined as:
CFLAGS += ${DEFINES}
CFLAGS += -I../../include/lib/stdlib

and adding "-nostdinc" flag will make gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf compilation fail because

../../include/lib/stdlib is a wrong path (taken from Renesas ARM-TF version 1.5 "tools\dummy_create\makefile") to

include\lib\libc\stdint.h for version ARM-TF version 2.0.


This issue can be fixed by changing CFLAGS to

CFLAGS += -nostdinc \
                    -I../../../include/lib/libc \
                    -I../../../include/lib/libc/aarch64

Regards.
Alexei.
From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of Biju Das via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 09 October 2020 08:12
To: Andre Przywara <Andre.Przywara@arm.com>; TF-A@lists.trustedfirmware.org <TF-A@lists.trustedfirmware.org>; Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>; Joanna Farley <Joanna.Farley@arm.com>
Cc: Marek Vasut <marek.vasut@gmail.com>; Chris Paterson <Chris.Paterson2@renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.
 
Hi Andre,

Thanks for the feedback.

> Subject: Re: commit 75fab6496e5fce9a11 ("libc: memset: improve
> performance by avoiding single byte writes") causing BL31 boot failure on
> Renesas RZ/G2 platforms.
>
> On 08/10/2020 20:05, Biju Das wrote:
>
> Hi,
>
> > I am porting Renesas RZ/G2M[1] platform to TF-A Master
> > branch(commitid: eeb77da646844) . Initially  faced a compilation error [2]
> which is fixed by using "#define" instead of "static const uint64_t".
>
> What is your exact fix? That compilation error sounds like a more serious
> issue, I am scratching my head how such a change would really fix things?

Looks like this issue is  related to toolchain, I was using aarch64-linux-gcc-7 on U-buntu 18.04 Host toolchain.
The compilation is error is fixed by the below changes.

#define BL31_RO_BASE BL_CODE_BASE
#define BL31_RO_LIMIT BL_CODE_END
#define BL31_COHERENT_RAM_BASE BL_COHERENT_RAM_BASE
#define BL31_COHERENT_RAM_LIMIT BL_COHERENT_RAM_END

The warning fix should not lead to compilation error with  the old toolchains.
It should be backward compatible to the old toolchains right? Please share your views.

> And do you see this with mainline? I tried:
Yes

> $ make bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls.git on origin/master
> and it built just fine.

Thanks for the hint, After using the toolchain[1], I got the same results as your's. it compiles successfully. So the issue is related to using older tool chains.
[1] https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

>
> > Then on target, found that BL31 is failed to boot[3], which is fixed
> > by reverting  the commit 75fab6496e5fce9a11
> > ("libc: memset: improve performance by avoiding single byte writes"),  see
> the logs [3].
>
> Mmmh, interesting. Can you build with "DEBUG=1" to get more output from
> BL31?

Sure Will do and provide feedback.

> I see some calls to memset() from code in drivers/renesas/rcar.
> Can you add some debug prints at the top of memset() to dump the
> parameters on each call? To see what breaks it?

OK.

> Are you using memset on some I/O memory, by any chance? And that
> doesn't support all access types, like 64-bit stores?

Will check and let you know.

Cheers,
Biju




Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
--
TF-A mailing list
TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a