(toppers-users 4470) Re: FMP Programming Model

[Daniel Sangorrin]

Hi Pieter,

Sorry for the late reply.

I enabled exceptions on the RTOS's main task (ena_tex) as in the
sample/fmp/com/rtos/ and then I tried your application.

So far, I can't see any problem with your application code.

However, when the GPOS's application exits the main task receives an
exception. The exception is captured by main_task_tex_routine causing
the main task to restart. After that, COM is not able to restart by
itself.

Could you confirm this is the issue?
#modify your GPOS application so that it doesn't exit and check that
it works as expected.

Regards,
Daniel















On Thu, Dec 10, 2015 at 8:49 PM, Daniel Sangorrin
<daniel.sangorrin ＠ gmail.com> wrote:
> Thanks Pieter, I will take a look at it.
>
> Regards,
> Daniel
>
> On Thu, Dec 10, 2015 at 1:19 AM, Pieter Maene
> <pieter.maene ＠ esat.kuleuven.be> wrote:
>> Hi Daniel,
>>
>> I have attached the application where we run into the deinitialization
>> issue. Unfortunately, I wasn't able to reproduce the unregistered exception
>> issue. It does occur occasionally after running the same GPOS app multiple
>> times, but it does not reliably trigger it.
>>
>> Kind regards,
>>
>> Pieter
>>
>> On 12/07/2015 05:32 PM, Pieter Maene wrote:
>>>
>>> Hi Daniel,
>>>
>>> We are using SafeG v1.0.0, FMP v1.2.2 and Linux
>>> 3.6.0-digilent-13.01-00002-g06b3889-dirty (we compiled the current master of
>>> https://github.com/Digilent/linux-digilent.git). These are not the latest
>>> versions, but if I'm not mistaken, they were the last to include support for
>>> the ZedBoard? Are there any know issues with recent kernel versions of
>>> Linux?
>>>
>>> I will send you a simple application to reproduce the unregistered
>>> processor exception bug and one for the deinitialization issue in the coming
>>> days.
>>>
>>> In the meantime, we've also ran into another problem and were wondering
>>> whether you've also encountered it in the past. TrustZone currently blocks
>>> access from Linux to custom components in the Zynq's fabric which are
>>> connected to the AXI bus. Non-secure requests to the bus need to be enabled
>>> by writing to the SECURITY_FSSW_S0 and SECURITY_FSSW_S1 configuration
>>> registers, which are commented out in target.c. However, when we uncomment
>>> the writes to these registers, the processor just hangs. Similarly, reads
>>> from or writes to the custom component from FMP also hang. Do you know of a
>>> solution for this problem?
>>>
>>> Thank you in advance!
>>>
>>> Kind regards,
>>>
>>> Pieter
>>>
>>> On 2015-12-03 23:42, Daniel Sangorrin wrote:
>>>
>>>> Hi Pieter,
>>>>
>>>> Thanks for your mail.
>>>> Please could you tell me the exact versions of SafeG, FMP and Linux that
>>>> you are using?
>>>>
>>>> If possible send me a simple application that can reproduce the bug.
>>>>
>>>> Thanks,
>>>> Daniel
>>>> On Dec 4, 2015 3:50 AM, "Pieter Maene" <pieter.maene ＠ esat.kuleuven.be>
>>>> wrote:
>>>>
>>>> Dear Daniel,
>>>>
>>>> Thank you for your response.
>>>>
>>>> I have managed to stabilize the application by refactoring the parts of
>>>> my code that use the communication library. Most of the time, the
>>>> application now runs without problems, although the unregistered processor
>>>> exception is still triggered sometimes.
>>>>
>>>> Something else that I noticed, is that the dual OS communication
>>>> functions often fail with DUALOSCOM_NOINIT. Regularly calling dualoscom_init
>>>> fixes this, but do you know what could cause this?
>>>>
>>>> To enable the logtrace, I included the header files in the FMP
>>>> configuration file and enabled modified the Makefile to enable it. We are
>>>> developing for the ZedBoard.
>>>>
>>>> Kind regards,
>>>>
>>>> Pieter
>>>>
>>>> On 11/26/2015 10:15 AM, Daniel Sangorrin wrote:
>>>>
>>>> Hi Pieter,
>>>>
>>>> Sorry for my late response.
>>>>
>>>> Just from my memory, I think the exception handler table uses the
>>>> exception number as the index (please check the assembly code to confirm).
>>>> If that's correct the second entry (index 1) corresponds to the unsupported
>>>> instruction exception.
>>>>
>>>> However, you mention that the same code runs ok at an earlier phase. One
>>>> question to ask: could it be that the first time it runs in secure mode and
>>>> the second time in non-secure mode? Some instructions cannot be executed in
>>>> non-secure mode. Have you checked.it [1] on FMP without Safeg?
>>>>
>>>> About the logtrace, please let me know what you did and what target you
>>>> are using. Perhaps the UART is not correctly specified for that target.
>>>>
>>>> Regards,
>>>> Daniel
>>>> On Nov 17, 2015 10:32 PM, "Pieter Maene" <pieter.maene ＠ esat.kuleuven.be>
>>>> wrote:
>>>> Hi Daniel,
>>>>
>>>> The exception is triggered in a piece of code that is very
>>>> loop-intensive. However, the same piece of code runs without any problems
>>>> earlier during the program execution, so I don't think it's a problem with
>>>> unsupported instructions. I've also found out that the second entry from the
>>>> _kernel_prc1_exch_table is triggered, but it's not clear to me how I can
>>>> determine the exact type of exception.
>>>>
>>>> Finally, I was wondering whether there are any further instructions on
>>>> how to enable the logtrace functionality. I have found some documentation,
>>>> but couldn't get any output over UART.
>>>>
>>>> Thank you in advance!
>>>>
>>>> Kind regards,
>>>>
>>>> Pieter Maene
>>>>
>>>> On 11/07/2015 04:30 AM, Daniel Sangorrin wrote:
>>>> Hi Pieter,
>>>>
>>>> It's a bit hard to answer with so little information.
>>>> You should start by isolating the problem. For example:
>>>>
>>>> - Does the problem exist when running FMP alone, or only when FMP runs on
>>>> SafeG?
>>>> - What type of exception is it?
>>>> - Which part of the code is generating the exception?
>>>> - Are your functions using some instructions not supported by your
>>>> processor (in case of
>>>> an undefined instruction exception) ?
>>>> - Do they require some coprocessor (VFP, SIMD) that is not supported
>>>> by the SoC or by FMP itself?
>>>>
>>>> Regards,
>>>> Daniel
>>>>
>>>> On Sat, Nov 7, 2015 at 1:32 AM, Pieter Maene
>>>> <pieter.maene ＠ esat.kuleuven.be> wrote:
>>>> Hi,
>>>>
>>>> We are currently building a TrustZone application for a course at the
>>>> University of Leuven. We use SafeG, with FMP in the secure world and
>>>> Linux
>>>> as the untrusted OS. A signature module is running in the trusted world
>>>> and
>>>> can be invoked to sign a message sent by the untrusted OS. The
>>>> communication
>>>> between the OSs works perfectly, but when a complicated function is
>>>> invoked
>>>> (e.g. the signing operation or deriving the public/private keypair), the
>>>> CPU
>>>> crashes with an "unregistered exception".
>>>>
>>>> I think I am missing a key concept of programming for FMP, or maybe
>>>> misconfigured a setting for the kernel.
>>>> Do you have an idea of what might be going wrong?
>>>>
>>>> Thanks in advance!
>>>>
>>>> Kind regards,
>>>>
>>>> Pieter Maene
>>>
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://checked.it
>>
>>