Hi olga,

I am looking into your question and will get back to you as soon as possible (hopefully tomorrow in the AM).

Best Regards,

Kaleb

Hi cfarrin,

Unfortunately our JNI expert is out of the office this week.
I will try to find a solution for you in the meantime.

If I can not find a solution our expert will be back in the office Monday and I will alert him to your issue.

Regards,

Kaleb

Hi tlkuester,

The control file for turning on and off supported ciphers is wolfssl/wolfssl/wolfcrypt/settings.h for working with TI-RTOS you will want to add any new defines to the section

#ifdef TIRTOS

If your servers support Elliptic Variants of Ephemeral Diffie Hellman you should be able to communicate with ECDHE suites.
To enable these suites add the following to the TIRTOS section in settings.h:

#define HAVE_ECC

ECDHE suites are widely supported but I am unsure of the configuration used by your endpoints.

If that does not work could you can send us a list of ciphers supported by your endpoints and we can gladly recommend features to turn on.

Best Regards,

Kaleb

Hi lucadistefano, steffen.mueller4 and sungyun,

With the introduction of DWARF 4 .debug_info section on ubuntu can now grow extremely large.

Please add the following to your existing configure options:

./configure <existing_options> C_EXTRA_FLAGS="-fdebug-types-section"

This will put program specific debug information into it's own separate comdat section which allows the linker to remove duplicates and will greatly reduce the size of the debug and usually puts an end to the Memory Exhausted errors seen in ld.

To read more on this topic see: https://gcc.gnu.org/onlinedocs/gcc/Debu … tions.html

Best Regards,

Kaleb

Hi Mark,

config.h is only modified by ./autogen.sh which uses Makefile.am and various other files to generate ./configure script. You should never need to include this file... ever.

The output of the configure script is options.h only.

settings.h is for user to control which math libraries are used, whether to use fast or slow sha operations, and many other things to tweak how the crypto libraries work.
settings.h will allow you to increase or decrease performance and / or footprint size. One example would be "USE_SLOW_SHA" in settings.h will trade fast performance for small footprint (sha will take longer to run but take up less room on an embedded system).

<wolfssl_root>/wolfssl/options.h                 = configure script settings and output
<wolfssl_root>/wolfssl/wolfcrypt/settings.h  = more control over the crypto operations

Sincerest Regards,

Kaleb

Hi csg,

The configure option you are looking for is

--enable-sslv3

We recently disabled this by default as it is vulnerable and a client could potentially
force a server to downgrade to SSL v3 as long as the server supports it and then use
known attacks against that SSL v3 connection.

I would instead suggest updating your curl version if possible (unless their newer versions no longer support Big Endian Architecture).

According to this Stack Exchange question http://unix.stackexchange.com/questions … v3-in-curl the gentleman notes that older versions of curl expect SSLv3 while in newer versions, they (like us) have disabled ssl v3 by default.

Begin Quote from Stack Exchange user ub3rst4r:

End Quote

Regards,

Kaleb

Hi BKPatel,

Link time solution:
It appears if the errors do not occur at build time but rather at link time then perhaps the errors dealing with pvPortMalloc and vPortFree may be because the freeRTOS implementation is unknown to the linker. Where is the freeRTOS library installed and is it in the LD_LIBRARY_PATH? For example:

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib/freeRTOS"

Kind Regards,

Kaleb

Hi FHDNS,

Since upgrading xcode have you run:  xcode-select --install

Failing to do so often causes issues with mac command line linking and autoconf.

As a side note:
Unfortunately we over-write CFLAGS in our configure script. Instead use C_EXTRA_FLAGS="-DSOMETHING -DWHATEVER" etc and LD_FLAGS=" ..." etc.

Regards,

Kaleb

Hi BKPatel,

Here is what I have done so far:

Try:

arm-none-eabi-gcc --version

If it is not found do the following:

sudo apt-get install gcc-arm-none-eabi
sudo apt-get install libnewlib-arm-none-eabi

cd into wolfssl directory.
Edit

wolfssl/wolfcrypt/settings.h

by uncommenting

#define FREERTOS

and run the following:

./configure --host=arm-none-eabi C_EXTRA_FLAGS="-O3 -mthumb -mcpu=cortex-m4" LDFLAGS="-lc -lrdimon -specs=rdimon.specs" CC=arm-none-eabi-gcc-4.8.2 

(This assumes you are using cortex-m4, if the mcpu needs to be changed update it to your mcpu)

At this point you will need the project specific header files all in the relevant places. Which unfortunately I can not test as I don't have access to your project etc.

It is my hope that you can get it working from there. If you have any further questions please let us know.

Kind Regards,

Kaleb

Hi BKPatel,

I am back in the office now. While I can not recommend you use the toolchain I sent previously as it is on github and I'm not sure what the licensing issues may be with that, I can suggest that cross compilation will need to be something along these lines:

./configure --host=arm-none-eabi

I don't believe arm-linux is the correct host to specify from compilation with Tiva C. I will look into this a little more today and see if I can't come up with a compile host platform that is fully supported on linux and/or Unix.

Regards,

Kaleb

Hi BKPatel,

Your issue is clear to me now. What is the problem with TI-RTOS that makes you want to use FREE-RTOS. In researching your questions I have found many questions asked about building freeRTOS with TivaC, most of which have little or no response and all mention this is not a well-documented process. What are the end-goals for your project and are there any deadlines?

I ask because I am leaving for vacation tonight after work and will be out of the office until Sept. 14th. That is when I would begin tracking down a solution / building a toolchain to cross-compile. I know you had not gotten any response from the Texas Instruments support but I would have to point you back their way if you are pressed for time.

The best way to contact TI in this regards is to use http://e2e.ti.com/support/development_tools/ and search for old cases or ask about tool chains for compiling an external c library on linux for use in CCS.

In the recent past we did a build of our libraries with freeRTOS using the Rowley Crossworks compiler. Without looking into it much further my best guess is that it will require something along those lines, but it may be too early to say for sure.

I am aware that the TivaC is typically flashed with a .aem4f formatted library which is abstracted above binary so I'm not sure the current approach of attempting to output a binary library will work on the TivaC processor. I am not 100% on that however. I would need to contact TI and see what they have to say on the matter.
See: http://www.ti.com/lit/ug/spru523i/spru523i.pdf

The file extensions for pre-built libraries provided with the NDK include the following:

.aem4 For Cortex-M4 targets (ELF format, little endian, TI compiler)
.am4g For Cortex-M4 targets (ELF format, little endian, GNU compiler)
.arm4 For Cortex-M4 targets (ELF format, little endian, IAR compiler)
.aem4f For Cortex-M4F floating point targets (ELF format, little endian, TI compiler)
.am4fg For Cortex-M4F floating point targets (ELF format, little endian, GNU compiler)
.arm4f For Cortex-M4F floating point targets (ELF format, little endian, IAR compiler)

Thank You for contacting us. I hope you can resolve this quickly. Otherwise I look forward to supporting you upon my return.

Kind Regards,

Kaleb

Hi BKPatel,

For our curiousity here at wolfSSL could you give us some details about your project. What are the end goals of your project, how will it be used etc. We are always excited to hear how consumers are using our product!

I have a few questions pertaining to your post:

1. Is there a reason it has to be CyaSSL 3.0.0 and you can not upgrade to wolfSSL 3.3.3 or later?
    (wolfSSL 3.6.6 would be the most recent)
    I ask because while we have support for both, TI has quickly adopted our library with the name-changed to wolfSSL
    as of release wolfSSL 3.3.3
    TI has shifted their development efforts from CyaSSL to wolfSSL.

2. Are you developing in Code Composer Studio or some other IDE/Environment?
    If in CCS see the end of this response for possible solution.

3. Have you seen our quick-start Readme for TivaC and wolfSSL here:
    https://github.com/wolfSSL/wolfssl-exam … /README.md

4. Is there a reason you are trying to build a .lib instead of using the TivaC .aem4f format?

Possible solution if using CCS:

You can follow these steps from the quick-start guide on linking to the .aem4f library. That is the format expected by TivaC.

Right click on your project and select Properties (usually near the bottom)
Under Build -> ARM Linker -> File Search Path

In the browser window on the right under "Include library file or command file as input"
Click the add button and add this line "C:\wolfssl\tirtos\packages\ti\net\wolfssl\lib\wolfssl.aem4f"

In the browser window on the right under "Add dir to library search path"
Click the add button and add this line "C:\wolfssl\tirtos\packages\ti\net\wolfssl\lib"

Kind Regards,

Kaleb