[Gnuk-users] Answer to Will you support gnuk on STM32F4Discovery?

[Bastien ROUCARIES]

On Tue, Nov 8, 2016 at 12:25 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> On 11/08/2016 01:39 AM, Bastien ROUCARIES wrote:
>> I plan to port to olimex stm32f4 board and I plan to volontuer.
>>
>> Could you help me to port ?
>>
>> I think I should begin with Chopstx ?
>>
>> Could you give me some pointer ?
>
> For myself, I don't have strong interest porting Gnuk to a chip with
> Cortex-M4 like STM32F4.  It's a larger chip with more complexity,
> which means that the possibility of attacks will be increased.  (My
> interest is porting Gnuk to Cortex-M0plus.  That is: smaller chip with
> less complexity, importantly, which comes with a fixed number of
> cycles for MUL operation.)

I have interest in STM32F4 and it is free software
>
> IIRC, Kaz Kojima did some work for porting Chopstx to a chip with
> Cortex-M4 and another chip of Cortex-A9.  For the latter (multi
> cores), we once tried to merge, but the merge had not finished.  Only
> some parts were merged.  Meanwhile Chopstx introduced new API.  We
> need to resume porting work again (for multiple cores, or more portable
> Chopstx).

Do you have some pointer ?
>
> For Cortex-M4, the handling of FPU is the major issue.  I suggested
> Kaz that FPU registers are handled by a user application (if it's
> possible), not by Chopstx itself.  If use of FPU can be done by only
> a thread (like a device driver), it will be easier to manage.  If not,
> more stack space will be needed to save possible FPU registers' store.

Your approach is like the one in linux kernel. FPU is saved by thread
running FPU computation. Work like a charm with mutex for critical
code.

Bastien

> --
>
> _______________________________________________
> gnuk-users mailing list
> gnuk-users at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/gnuk-users