(toppers-users 4471) Re: FMP Programming Model

[Pieter Maene]

Hi Daniel,

That does indeed solve our problem. I didn't realize ena_tex enabled 
exceptions. I will keep you updated about our progress with accessing 
the Programmable Logic on the Zynq when TrustZone is enabled.

Thank you very much for your help!

Kind regards,

Pieter

On 12/16/2015 02:56 PM, Daniel Sangorrin wrote:
> 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
>>>
>>>