Open vdanilchenko-schneider opened 6 years ago
I'd like to understand your needs and plans bit better. Might be worth a phone call. Mail me @ rlander@microsoft.com?
@richlander did the follow up happen? Anything to report back? Is this issue tracking anything actionable at this point?
Thanks for following up on this. We are still interested in NET CORE support for the ARM variant with 16 FPRs, so please keep us posted.
@vdanilchenko-schneider did the meeting happen between you and @richlander?
Not that I recall. We didn’t get any follow-up from that initial exchange.
Did you send the email to @richlander as he suggested above? https://github.com/dotnet/core/issues/1470#issuecomment-386122092
Yes, I did. I am attaching it here.
@richlander ping?
@richlander ping again ...
@richlander ping again again ...
I just responded.
Is there a.net core2.x version of Armel
Note that support for building a vfpv3-d16 version of coreclr was recently introduced with https://github.com/dotnet/runtime/pull/471. This is still not an officially supported scenario.
Hi,
Our Business Units widely use ARM based CPU to develop hardware solutions for automation and energy management.
We appreciate Microsoft’s decision to support native .Net Core deployment for linux-arm target. We have positive results of self-contained deployments for Cortex-A9 based devices. It’ll really speed up development-to-deployment-to-market process.
During one of our POC projects, we’ve identified that some of chips (e.q. RZ/N1D), extensively used by our BU, aren’t compatible with current linux-arm runtime and generate “Illegal Instruction” exception.
Further investigation revealed very simple but critical incompatibility: this chip’s FPU includes only 16 double-precision registers. Seems like simple change of cross-compiler option from vfpv3 to vfpv3-d16 [or vfpv4-d16] to generate runtime libraries should solve this problem.
An alternative solution would be to support linux-armel target, i.e. do not use Floating Point Unit at all, though the previously outlined solution would be preferable.
Would you please consider building and including runtime specific packages for linux-arm-VFPv4-d16 and/or linux-armel devices.