CM4: Linking external (crypto) library

[Philipp Burch-2]

Hi everyone,

I'm on the way to add encryption and signature support to the
tiva_ethloader bootloader (see https://hb9etc.ch/hg/tiva_ethloader/). As
a start, I looked for a suitable crypto library to do the hard work,
which provides support for (symmetric) encryption and (asymmetric)
signature checking. As it is planned right now, there should be no need
for a random number generator on the device, so it really is only a
software thing.

I know that Ethernut already has some kind of crypto library included,
but haven't looked closely at it yet. In the configurator, I see that
AES is mentioned, but haven't seen anything that provides signature
checking (could be RSA-based, or even better some EC cryptography to get
away with shorter keys). Correct me, if I'm wrong. I'll happily use some
existing Ethernut code if it already includes what I need.

Anyway, as the topic suggests, I'm actually trying to get an external
lib included in my code, libsodium
(https://github.com/jedisct1/libsodium) to be exact. Compilation of the
library itself for the arm-none-eabi target is quite easy and gives me
the libsodium.a for inclusion.

Now, when trying to add the library to the bootloader, the linker coughs
because of multiple definitions of fflush() and also due to undefined
references to some underlying functions like _close() and _read():

------- 8< ------- 8< -------

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
In function `fflush':
fflush.c:(.text.fflush+0x0): multiple definition of `fflush'
/home/phip/phipsfiles/developing/ethernut/nutinstall-fpm_01b/libnutcrt.a(fflush.o):fflush.c:(.text.fflush+0x0):
first defined here
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:
section .ARM.exidx LMA [000000000001e0e0,000000000001e0e7] overlaps
section .data LMA [000000000001e0e0,000000000001f1d7]
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-closer.o):
In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-readr.o):
In function `_read_r':
readr.c:(.text._read_r+0x12): undefined reference to `_read'
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fstatr.o):
In function `_fstat_r':
fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-isattyr.o):
In function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-lseekr.o):
In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'

------- 8< ------- 8< -------

According to the paths, this is because the linker takes code from ARM's
standard library, instead of the one included in Ethernut.

Now the question: How can I find out what symbol triggers the inclusion
of the ARM standard library? And how can I fix this? I already tried
various compiler flags when compiling libsodium, also the ones that are
used when compiling the Ethernut libs or the bootloader itself, but
without luck, the errors stay the same.

I'd be glad for any hints!

Thanks and regards,
Philipp
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Philipp Burch-2]

Anyone?

Regards,
Philipp

On 08.02.19 14:54, Philipp Burch wrote:

> Hi everyone,
>
> I'm on the way to add encryption and signature support to the
> tiva_ethloader bootloader (see https://hb9etc.ch/hg/tiva_ethloader/). As
> a start, I looked for a suitable crypto library to do the hard work,
> which provides support for (symmetric) encryption and (asymmetric)
> signature checking. As it is planned right now, there should be no need
> for a random number generator on the device, so it really is only a
> software thing.
>
> I know that Ethernut already has some kind of crypto library included,
> but haven't looked closely at it yet. In the configurator, I see that
> AES is mentioned, but haven't seen anything that provides signature
> checking (could be RSA-based, or even better some EC cryptography to get
> away with shorter keys). Correct me, if I'm wrong. I'll happily use some
> existing Ethernut code if it already includes what I need.
>
> Anyway, as the topic suggests, I'm actually trying to get an external
> lib included in my code, libsodium
> (https://github.com/jedisct1/libsodium) to be exact. Compilation of the
> library itself for the arm-none-eabi target is quite easy and gives me
> the libsodium.a for inclusion.
>
> Now, when trying to add the library to the bootloader, the linker coughs
> because of multiple definitions of fflush() and also due to undefined
> references to some underlying functions like _close() and _read():
>
> ------- 8< ------- 8< -------
>
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
> In function `fflush':
> fflush.c:(.text.fflush+0x0): multiple definition of `fflush'
> /home/phip/phipsfiles/developing/ethernut/nutinstall-fpm_01b/libnutcrt.a(fflush.o):fflush.c:(.text.fflush+0x0):
> first defined here
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:
> section .ARM.exidx LMA [000000000001e0e0,000000000001e0e7] overlaps
> section .data LMA [000000000001e0e0,000000000001f1d7]
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-closer.o):
> In function `_close_r':
> closer.c:(.text._close_r+0xc): undefined reference to `_close'
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-readr.o):
> In function `_read_r':
> readr.c:(.text._read_r+0x12): undefined reference to `_read'
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fstatr.o):
> In function `_fstat_r':
> fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-isattyr.o):
> In function `_isatty_r':
> isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-lseekr.o):
> In function `_lseek_r':
> lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
>
> ------- 8< ------- 8< -------
>
> According to the paths, this is because the linker takes code from ARM's
> standard library, instead of the one included in Ethernut.
>
> Now the question: How can I find out what symbol triggers the inclusion
> of the ARM standard library? And how can I fix this? I already tried
> various compiler flags when compiling libsodium, also the ones that are
> used when compiling the Ethernut libs or the bootloader itself, but
> without luck, the errors stay the same.
>
> I'd be glad for any hints!
>
> Thanks and regards,
> Philipp
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

Philipp Burch writes:
> Anyone?
>
> Regards,
> Philipp
>
> On 08.02.19 14:54, Philipp Burch wrote:
> > Hi everyone,
> >
...

> > /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
> > In function `fflush':
Hallo Philip,

the exact command line of the offending programs could help. For cortexm, there are 4 gcc options in the tool qnutconf tree:

- GCC (no libc)
-  GCC debug (no libc)
- GCC newlib
- GCC nanolib.

Whta options did you try. As probably flash space is not that tight
for yout application, perhaps  with new- or nanolib.

Bye
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] ------- Fax. [phone] ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Matthias Ringwald-2]

Hi Philipp

I have no experience with libsodium or your actual linker issue.

When looking for a library for ECC, NaCl / libsodium seemed not suited for embedded (I guess I was wrong about that).
Then, I've tried mbedTLS. That worked for me but mbedTLS requires malloc. I created a minimal malloc implementation, just for mbedTLS, but it required more RAM that I've liked.

Finally, I came across micro-ecc (https://github.com/kmackay/micro-ecc). It's malloc-free and works well. Maybe it is suitable for your setup as well.

Best
 Matthias

> On 2 Mar 2019, at 17:35, Philipp Burch <[hidden email]> wrote:
>
> Anyone?
>
> Regards,
> Philipp
>
> On 08.02.19 14:54, Philipp Burch wrote:
>> Hi everyone,
>>
>> I'm on the way to add encryption and signature support to the
>> tiva_ethloader bootloader (see https://hb9etc.ch/hg/tiva_ethloader/). As
>> a start, I looked for a suitable crypto library to do the hard work,
>> which provides support for (symmetric) encryption and (asymmetric)
>> signature checking. As it is planned right now, there should be no need
>> for a random number generator on the device, so it really is only a
>> software thing.
>>
>> I know that Ethernut already has some kind of crypto library included,
>> but haven't looked closely at it yet. In the configurator, I see that
>> AES is mentioned, but haven't seen anything that provides signature
>> checking (could be RSA-based, or even better some EC cryptography to get
>> away with shorter keys). Correct me, if I'm wrong. I'll happily use some
>> existing Ethernut code if it already includes what I need.
>>
>> Anyway, as the topic suggests, I'm actually trying to get an external
>> lib included in my code, libsodium
>> (https://github.com/jedisct1/libsodium) to be exact. Compilation of the
>> library itself for the arm-none-eabi target is quite easy and gives me
>> the libsodium.a for inclusion.
>>
>> Now, when trying to add the library to the bootloader, the linker coughs
>> because of multiple definitions of fflush() and also due to undefined
>> references to some underlying functions like _close() and _read():
>>
>> ------- 8< ------- 8< -------
>>
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
>> In function `fflush':
>> fflush.c:(.text.fflush+0x0): multiple definition of `fflush'
>> /home/phip/phipsfiles/developing/ethernut/nutinstall-fpm_01b/libnutcrt.a(fflush.o):fflush.c:(.text.fflush+0x0):
>> first defined here
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:
>> section .ARM.exidx LMA [000000000001e0e0,000000000001e0e7] overlaps
>> section .data LMA [000000000001e0e0,000000000001f1d7]
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-closer.o):
>> In function `_close_r':
>> closer.c:(.text._close_r+0xc): undefined reference to `_close'
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-readr.o):
>> In function `_read_r':
>> readr.c:(.text._read_r+0x12): undefined reference to `_read'
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fstatr.o):
>> In function `_fstat_r':
>> fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-isattyr.o):
>> In function `_isatty_r':
>> isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-lseekr.o):
>> In function `_lseek_r':
>> lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
>>
>> ------- 8< ------- 8< -------
>>
>> According to the paths, this is because the linker takes code from ARM's
>> standard library, instead of the one included in Ethernut.
>>
>> Now the question: How can I find out what symbol triggers the inclusion
>> of the ARM standard library? And how can I fix this? I already tried
>> various compiler flags when compiling libsodium, also the ones that are
>> used when compiling the Ethernut libs or the bootloader itself, but
>> without luck, the errors stay the same.
>>
>> I'd be glad for any hints!
>>
>> Thanks and regards,
>> Philipp
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Philipp Burch-2]

Hi Uwe!

On 04.03.19 12:48, [hidden email] wrote:

> [...]
> ...
>
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
>>> In function `fflush':
> Hallo Philip,
>
> the exact command line of the offending programs could help. For cortexm, there are 4 gcc options in the tool qnutconf tree:
>
> - GCC (no libc)
> -  GCC debug (no libc)
> - GCC newlib
> - GCC nanolib.
>
> Whta options did you try. As probably flash space is not that tight
> for yout application, perhaps  with new- or nanolib.

The command line for compiler and linker is like this:

arm-none-eabi-gcc -c -I/.../ethernut/nutbld-fpm_01b/include
-I/.../ethernut/devnut_tiva/nut/include
-I/.../ethernut/devnut_tiva/nut/include/contrib  -DFPM_01B  -MD -MP
-mcpu=cortex-m4 -mthumb -D__CORTEX__ -mfloat-abi=hard -mfpu=fpv4-sp-d16
-ffunction-sections -fdata-sections -fomit-frame-pointer  -Os -Wall
-Wstrict-prototypes -Wa,-a=crc32crcgen.lst   -DBOOTLOADER_OFFSET=0x8000
-I../../libsodium/include -DREPOVERSION="\"4a34f184ec49 tip Thu Jan 31
14:33:37 2019 +0100\"" -o crc32crcgen.o crc32crcgen.c

arm-none-eabi-gcc main.o crc32crcgen.o -mcpu=cortex-m4 -mthumb
-D__CORTEX__ -mfloat-abi=hard -mfpu=fpv4-sp-d16 -nostartfiles
-L/.../ethernut/devnut_tiva/nut/arch/cm3/ldscripts
-Ttm4c1294ncpdt_flash.ld
-Wl,-Map=tiva_ethloader.map,--cref,--gc-sections
-L/.../ethernut/nutinstall-fpm_01b -Wl,--defsym=ccm_length=0
-Wl,--defsym=ram1_length=0 -Wl,--defsym=ram2_length=0 -Wl,--trace
-Wl,--defsym=flash0_size=0x8000 -L../../libsodium/lib -Wl,--start-group
/.../ethernut/nutinstall-fpm_01b/nutinit.o -lnutpro -lnutnet -lnutfs
-lnutos -lnutgorp -lnutcrt -lnutdev -lnutarch -lm -lsodium -lnutc
-Wl,--end-group -o tiva_ethloader.elf


I tried all library options, but with no change. In fact, I can't even
see a difference in the command lines. What are these settings supposed
to do? Except for the debug option of course, this works and causes an
increase in code size.

Thanks.

Bye,
Philipp
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Philipp Burch-2]

Hi Matthias,

thanks for the hint with micro-ecc. This could indeed work, at least it
seems to be easy to integrate from a toolchain point of view. Getting
the crypto stuff right on this lower level of abstraction will be
another story, though. But that should be doable, especially since we do
not need the absolute maximum amount of security. It should just make it
harder to simply disassemble a firmware update file.

Best regards,
Philipp

On 04.03.19 14:23, Matthias Ringwald wrote:

> Hi Philipp
>
> I have no experience with libsodium or your actual linker issue.
>
> When looking for a library for ECC, NaCl / libsodium seemed not suited for embedded (I guess I was wrong about that).
> Then, I've tried mbedTLS. That worked for me but mbedTLS requires malloc. I created a minimal malloc implementation, just for mbedTLS, but it required more RAM that I've liked.
>
> Finally, I came across micro-ecc (https://github.com/kmackay/micro-ecc). It's malloc-free and works well. Maybe it is suitable for your setup as well.
>
> Best
>  Matthias
>
>> On 2 Mar 2019, at 17:35, Philipp Burch <[hidden email]> wrote:
>>
>> Anyone?
>>
>> Regards,
>> Philipp
>>
>> On 08.02.19 14:54, Philipp Burch wrote:
>>> Hi everyone,
>>>
>>> I'm on the way to add encryption and signature support to the
>>> tiva_ethloader bootloader (see https://hb9etc.ch/hg/tiva_ethloader/). As
>>> a start, I looked for a suitable crypto library to do the hard work,
>>> which provides support for (symmetric) encryption and (asymmetric)
>>> signature checking. As it is planned right now, there should be no need
>>> for a random number generator on the device, so it really is only a
>>> software thing.
>>>
>>> I know that Ethernut already has some kind of crypto library included,
>>> but haven't looked closely at it yet. In the configurator, I see that
>>> AES is mentioned, but haven't seen anything that provides signature
>>> checking (could be RSA-based, or even better some EC cryptography to get
>>> away with shorter keys). Correct me, if I'm wrong. I'll happily use some
>>> existing Ethernut code if it already includes what I need.
>>>
>>> Anyway, as the topic suggests, I'm actually trying to get an external
>>> lib included in my code, libsodium
>>> (https://github.com/jedisct1/libsodium) to be exact. Compilation of the
>>> library itself for the arm-none-eabi target is quite easy and gives me
>>> the libsodium.a for inclusion.
>>>
>>> Now, when trying to add the library to the bootloader, the linker coughs
>>> because of multiple definitions of fflush() and also due to undefined
>>> references to some underlying functions like _close() and _read():
>>>
>>> ------- 8< ------- 8< -------
>>>
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
>>> In function `fflush':
>>> fflush.c:(.text.fflush+0x0): multiple definition of `fflush'
>>> /home/phip/phipsfiles/developing/ethernut/nutinstall-fpm_01b/libnutcrt.a(fflush.o):fflush.c:(.text.fflush+0x0):
>>> first defined here
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:
>>> section .ARM.exidx LMA [000000000001e0e0,000000000001e0e7] overlaps
>>> section .data LMA [000000000001e0e0,000000000001f1d7]
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-closer.o):
>>> In function `_close_r':
>>> closer.c:(.text._close_r+0xc): undefined reference to `_close'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-readr.o):
>>> In function `_read_r':
>>> readr.c:(.text._read_r+0x12): undefined reference to `_read'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fstatr.o):
>>> In function `_fstat_r':
>>> fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-isattyr.o):
>>> In function `_isatty_r':
>>> isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-lseekr.o):
>>> In function `_lseek_r':
>>> lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
>>>
>>> ------- 8< ------- 8< -------
>>>
>>> According to the paths, this is because the linker takes code from ARM's
>>> standard library, instead of the one included in Ethernut.
>>>
>>> Now the question: How can I find out what symbol triggers the inclusion
>>> of the ARM standard library? And how can I fix this? I already tried
>>> various compiler flags when compiling libsodium, also the ones that are
>>> used when compiling the Ethernut libs or the bootloader itself, but
>>> without luck, the errors stay the same.
>>>
>>> I'd be glad for any hints!
>>>
>>> Thanks and regards,
>>> Philipp
>>> _______________________________________________
>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

Philipp Burch writes:
> Hi Uwe!
>
 
> I tried all library options, but with no change. In fact, I can't even
> see a difference in the command lines. What are these settings supposed
> to do? Except for the debug option of course, this works and causes an
> increase in code size.
>
Compiling some gpio example for Nucleo-Stm2l152re I get
12256: nolibc
13228: newlib
12224: nanolib

Perhaps some changes for using the different libraries are not fully
ported to your out-of-tree device. Search for "nano" in the diffs.

Newlib and nanolib come with arm-none-eabi and nolibc fully uses our
own libc implementation.

Bye

--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] ------- Fax. [phone] ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Philipp Burch-2]

Hi Uwe!

On 11.03.19 10:55, [hidden email] wrote:

> Philipp Burch writes:
>> Hi Uwe!
>>
>  
>> I tried all library options, but with no change. In fact, I can't even
>> see a difference in the command lines. What are these settings supposed
>> to do? Except for the debug option of course, this works and causes an
>> increase in code size.
>>
> Compiling some gpio example for Nucleo-Stm2l152re I get
> 12256: nolibc
> 13228: newlib
> 12224: nanolib
>
> Perhaps some changes for using the different libraries are not fully
> ported to your out-of-tree device. Search for "nano" in the diffs.
>
> Newlib and nanolib come with arm-none-eabi and nolibc fully uses our
> own libc implementation.

Ok, thanks. I will see what I can find as soon as the priority of this
task increases in a way so that I find time to actually do it :S

Regards,
Philipp
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion