On 11/10/2020 11:00, Biju Das wrote:
Hi,
....
So, can you please double check that: memset(0x44040010, 0, 81840); is really the call that hangs your system?
Yes, This is called from console.S-->rcar_log_int-->memset
And that it really does because so it's being stuck in the last while loop?
After further investigation, not sure it is related to while loop or some kind of corruption?, since I don't have access to JTAG further debugging. Mostly some kind of corruption leading to crash.
The new code introduced, some increased code size, which is causing bl31 boot failure, when we call memset from console.S> Case 1) console.S -->rcar_log_int -->memset --> bl31 not booting. Case 2) If I comment, rcar_log_init from console.S --> bl31 boots fine. Case 3) If I comment, rcar_log_init from console.S and call rcar_log_init from bl31_early_platform_setup2 --> bl31 boots fine. Any thoughts?
So does it tip something over the edge? Can you compare the program headers in the ELF file to see if some grew bigger? $ readelf -l build/.../bl31/bl31.elf Compare a working with a non-working version. Also you might want to check the section headers (-S), to see if something sticks out.
Another things I stumbled upon the other day is stack size: If you overrun this (too many/too big local variables or too deep function call nesting), then BL31 silently hangs.
What is the memory map of your platform, and BL31 in particular? You run from DRAM, don't you? I see that most Renesas DTs in the kernel reserve the first 128MB as secure memory. Are there any other self-imposed limits, for instance, in BL31 in particular?
Another related thing to check is the number of page tables, that might be too tight for your code (although I think the build system would warn).
And can you make this RCAR_BL31_LOG_BASE region MT_NORMAL memory and see if the problem still persists?
Yes , still the problem persists. The current mapping "MT_DEVICE" is as per "Use of coherent memory in TF-A" section as mentioned in [1]. By changing the region as MT_NORMAL also didn't help , see the patch [2].
I see, thanks for trying this!
Cheers, Andre
Please share your opinion on this?
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/design... [2] diff --git a/include/lib/xlat_tables/xlat_tables_v2.h b/include/lib/xlat_tables/xlat_tables_v2.h index 359b9839a..c50727a42 100644 --- a/include/lib/xlat_tables/xlat_tables_v2.h +++ b/include/lib/xlat_tables/xlat_tables_v2.h @@ -86,6 +86,7 @@ #define MT_DEVICE U(0) #define MT_NON_CACHEABLE U(1) #define MT_MEMORY U(2) +#define MT_NORMAL U(4) /* Values up to 7 are reserved to add new memory types in the future */
#define MT_RO (U(0) << MT_PERM_SHIFT) diff --git a/plat/renesas/rcar/aarch64/platform_common.c b/plat/renesas/rcar/aarch64/platform_common.c index b0a88cb6b..744c79c98 100644 --- a/plat/renesas/rcar/aarch64/platform_common.c +++ b/plat/renesas/rcar/aarch64/platform_common.c @@ -64,7 +64,7 @@ const uint8_t version_of_renesas[VERSION_OF_RENESAS_MAXLEN]
#define MAP_ATFW_LOG MAP_REGION_FLAT(RCAR_BL31_LOG_BASE, \ RCAR_BL31_LOG_SIZE, \
MT_DEVICE | MT_RW | MT_SECURE)
MT_NORMAL | MT_RW | MT_SECURE)Sure, having no tail loop simplifies the algorithm, but is wrong. So what is the point here?
Agreed, I just want to give some pointers related to this issue, so that we can narrow down the issue. that's all.
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