(toppers-users 4469) Re: FMP Programming Model

[Daniel Sangorrin]

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
>
>