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