GR740-SMP BSP test results (gcc-7.2)

Daniel Hellstrom daniel at gaisler.com
Thu Sep 20 06:59:23 UTC 2018


Hello Sebastian,

On 2018-09-20 07:32, Sebastian Huber wrote:
> Hello Daniel,
>
> thanks for your status report. The RSB uses currently GCC 7.3.0 
> without patches and the Newlib commit 
> d13c84eb07e35984bf7a974cd786a6cdac29e6b9.
Thanks for the information, our toolchain was built using 
916ef5fb8865f72d0f5ad3f4f479adac44ea94b1. I will update newlib at least 
going forward.

>
> On 19/09/2018 14:46, Daniel Hellstrom wrote:
>> Hi,
>>
>> I just wanted to share the current test status for the GR740 I have 
>> today, using the todays master with some additional test fixes which 
>> I plan to submit shortly. The test have been run both on TSIM and 
>> hardware.
>>
>> Current test results for the RTEMS test-suite with GCC-7.2 toolchain 
>> for the GR740 quad-core LEON4 BSP in SMP driver manager configuration:
>>
>>
>>   #######################################################
>>   # RTEMS TESTSUITE FAILURE SUMMARY
>>   #
>>   # Result Test ExecRes ConsoleRes ExitCode1 ExitCode2
>>   # FAIL: minimum OK N/A 0 5
>
> Ok, known issue, the test has no output.
>
>>   # FAIL: spcpucounter01 OK FAIL 5 0
>
> This was a bug. It should be fixed with this commit:
>
> https://git.rtems.org/rtems/commit/?id=b3cf79b9c472ed8c219f8c9a9d8fb571671f3815 
>

Aah, I missed this, even looking at that line of code I could not see 
the typo. This fix will remove a warning too.

>
>>   # FAIL: spfatal07 FAIL N/A N/A N/A
>>   # FAIL: spinternalerror01 OK N/A -559038737 1611526157
>
> This is a known issue. Test exit before the device enumeration.
>
>>   # FAIL: sptimecounter01 OK N/A 5 0
>
> This is a known issue. Test exit before the device enumeration.
>
>>   #
>>   # SUMMARY
>>   #  Tests failing:    5
>>   #  Tests successful: 624
>>   #
>>   #######################################################
>>
>>
>> spfatal07 - problem with the test itself. 
>> CONFIGURE_INTERRUPT_STACK_SIZE is too small, the boot process fails 
>> before reaching the check. This is a new behavior since interrupt 
>> stack is also used by the CPU for initialization/boot process.
>
> Ok, thanks for the pointer. I changed the interrupt/initialization 
> stack machinery recently. I think that this internal error is 
> superfluous now or needs to be adjusted. This ticket is related to 
> this topic:
>
> https://devel.rtems.org/ticket/3480
>

Thanks for your comments, it is helpful.




More information about the devel mailing list