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