(toppers-users 4467) Re: FMP Programming Model

[Pieter Maene]

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