(toppers-users 4465) Re: FMP Programming Model

[Daniel Sangorrin]

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 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
>>>>
>>>
>>
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://www.toppers.jp/pipermail/users/attachments/20151204/c7dd7efa/attachment.html>