Fix "NNNN.a uses VFP register arguments" when building with GCC

[josesimoes]

Fixes compiler error "NNNN.a uses VFP register arguments" when building 4.4 using GCC.
This has been suggested by @Roceh in issue #335.
I've successfully build STM32F4DISCOVERY and MCBSTM32F400_NONET.
Tested STM32F4DISCOVERY on real hardware and it seems to work OK.
Couldn't test the MCBSTM32F400_NONET because I don't have that board.

[josesimoes]

Question: despite this fixing the issue, aren't we loosing something by using PLATFORM_EMULATED_FLOATINGPOINT? Shouldn't the root cause of the compiler error be corrected elsewhere so we don't have to revert to platform emulated mode?

[smaillet-ms]

The real root cause here is the need for the old legacy crypto libs. Due to the same policy issues that prevent release in source, rebuilding the binaries is a logistical nightmare. Ideally, the best long term solution is to eliminate the need for them. mBedTLS or some other such library should have all the necessary support to replace the limited bit of crypto support that is still used from those libraries. So I'd argue any effort for dealing with this should focus on solving the long term issue rather than another bandage.

[josesimoes]

@smaillet-ms Thank you Steve for looking into this.
I understand what you are saying.
Let me ask you this:

1. Noticed that there are no GCC folders under the crypto\lib install folder, only ADS, MDK, RVD. Any chance you could build the libs with GCC and provide those?
2. As an alternative to 1) is it possible to make a build with the appropriate settings so that GCC doesn't complaint about this and this patch isn't required?
3. Could you elaborate on the required changes to move to an alternative library (mBedTLS?)

[smaillet-ms]

1. There's a chance but it's a slim one - I don't say that jokingly, as I mentioned getting access to and building/modifying cryptographic code owned by Microsoft is a non-trivial task for those of us who don't work on that sort of thing all the time. The amount of effort to get that done is sadly, rather high.
2. Same answer as MCBSTM32F400 External FLASH and SSL support #1
3. The only thing left using the legacy Crypto libs is the bootloader and MFDeploy. So, what is needed is to re-implement the crypto lib APIs using an OSS implementation. That is build a NETMF adapter layer on top of a compatible OSS library such as mBed TLS. This gets us going with full OSS all the way through and, also sets the stage for replacing OpenSSL with the much leaner mBedTLS libraries. Thus I think any effort directed towards 1) or 2) would be a bit short sighted and largely a waste of time.

[josesimoes]

Hi Steve,

I didn't thought that you were joking or dismissing this matter. Rest assured about that! 😄
If that's not too much trouble I would say that - for the sake of the open source spirit - if you can give it another try it would be important to properly support GCC.

Understood about moving towards a better library and having decent cryptographic support in NETMF.
Correct me if I'm wrong but this has impact on having SLL and TLS working at the network level as well isn't it? If NETMF aims to be a serious player in networked scenarios, IoT and such supporting SLL/TLS should be a top priority.

This reminds me another open issue that was waiting the release of a new mBed version.
Any news on that? Is NETMF definitely moving towards mBed or not? What are the plans for the next release? Is all this going to be replaced by LLILUM?
I would love to know your roadmap and the plans for the future. Not only because I'm curious on where all this is going to, but because that's important when deciding if one should commit effort on something or not (such as the above about the OSS implementation).
Appreciate what you can share about all that. For sure this is of interest to the NETMF community as well. May I suggest a blog post about all the above to keep the community engaged?

[smaillet-ms]

Huh, we have SSL and TLS already supported via the OpenSSL library. As I said in 3) the only thing left using the old legacy crypto libs in question here is the boot loader and MFDeploy for checking digital signatures on firmware updates. That's it. Thus the plan to drop the closed source implementation of those libs with a new one based on the mBed TLS libraries. The secondary advantage of mBedTLS is the opportunity to replace the Bulky OpenSSL implementation we currently have.

As to the roadmap, our plan is that we intend for LLilum to be the next evolution of NETMF. Thus the bulk of our efforts are focused on that. THere will be some migration of current applications for NETMF but it's not going to be a case of throw it all away and start over. However, since Llilum isn't even at a Beta stage we need to keep NETMF going.

The mbed question is worthy of an entirely new topic of discussion. mBed 3.0 is a very different animal from previous releases and moving to that isn't going to be a simple effort as we'd still need to maintain support for the current code base.

[josesimoes]

Last time I tried I couldn't make a successful build with GCC of both MCBSTM32F400 (NETWORK) and STM32F4DISCOVERY with network and SSL enabled.
One of the issues was related with ENC28J60, hopefully that is corrected now with PR #310.
I'll give it another try.

Thanks for the update on the roadmap.

Regarding mBed: I'm not advocating that NETMF should follow or not follow that path. Was just asking what's the guidance/felling about that matter. I guess the answer to that is tight with the above. If the effort of going the mBed path is significant then it's probably better to switch NETMF to "maintenance mode" and just fix bugs so the efforts (both yours and the community) is focused in Llilum.
Let's have that discussion started!

[smaillet-ms]

GCC with networking isn't currently working. That requires altering the runtime startup code to support running the CMSIS-RTX kernel. Unfortunately that is a compiler/CRT specific thing and the work to do that with GCC+newlib hasn't been done yet.

[josesimoes]

That's what I thought. Any time frame to look into that? I would love to help but assembly is a bit out of my expertise... 😊

[josesimoes]

Is there a kind soul out there that is willing to look into that startup code to support running the CMSIS-RTX kernel so we can have networking with GCC?! Pleeeeaseeee........ 😢

[josesimoes]

@smaillet-ms did you have the opportunity to look into this? The fact that we need to force GCC to compile with emulated FP because of the crypto libs throws several warnings when building RTX.
In one of my attempts I've replaced the CMSIS package with the most recent version. It turns out that most (if not all) of those warning with RTX were now errors. Looking into the code leads me to think that the compilation with emulated FP is causing issues that might explain some of the problems we are facing with building the RTX version with GCC.
Please give it another try on providing the crypto libs compiled for GCC with proper FP support.
Thanks!

[josesimoes]

I found out that building TinyBooter and TinyCLR separately (cleaning the BuildOutput folder before each build) allows to overcome this issue.
Meaning that the TinyBooter gets compiled without the FP support to allow the crypto libs to be added.
On the next build the TinyCLR gets s compiled with FP support.

[smaillet-ms]

That's good info, thanks. I hate to leave things as a workaround but that's going to have to do on this one. The amount of effort and time to resolve it with a rebuild of the current cryptolibs is unfortunately rather high. I'd like to shift the focus to just replacing the cryptolibs with an equivalent library based on the mBed TLS libraries. We've got a short term workaround, so let's focus on resolving longer term story.