Re: [PATCH] Adding eth linker script section for arm bsp.

2014-09-02 Thread Sebastian Huber

Hello Federico,

since this just adds a linker command file variant, I would prefer to just add 
the linker command file without the BSP name.  You can then use -qnolinkcmds 
-T linkcmds.lpc1768_mbed_ahb_ram_eth to select this memory map.


On 01/09/14 15:21, Federico Casares wrote:

Attached the new version of this add.

Regards


On Fri, Aug 29, 2014 at 2:30 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de
mailto:sebastian.hu...@embedded-brains.de wrote:

Hello Federico,

you can do it like this:


http://git.rtems.org/rtems/__tree/c/src/lib/libbsp/arm/__altera-cyclone-v/startup/__linkcmds.altcycv_devkit

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/altera-cyclone-v/startup/linkcmds.altcycv_devkit

You can also use the INCLUDE directive to reduce the copy and paste.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-__brains.de
mailto:sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




--
http://www.tallertechnologies.com http://www.tallertechnologies.com
Casares, Federico
Sr. Software Engineer
Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina



--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: CMSIS?

2014-09-02 Thread Daniel Gutson
On Tue, Sep 2, 2014 at 11:51 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
 This is the license.

 The big problem I see first is the typical use only on our hardware
 and that in order to redistribute, we must ensure that it is only
 used on ARM hardware.

 This is a common restriction on vendor provided software and I
 honestly don't know how to address including anything which
 wants an open source project to ensure that anyone downloading
 only uses it on the appropriate hardware.

 We have seen similar licenses from at least four vendors.

 If someone is able to crack this nut and find a way to not incur
 liability for the RTEMS Project, I am open to ideas. But skeptical.

Would this mean that an implementation from scratch would be the best choice?



 --joel

 

 END USER LICENCE AGREEMENT FOR THE CORTEX MICROCONTROLLER SOFTWARE
 INTERFACE STANDARD (CMSIS) SPECIFICATION AND SOFTWARE

 THIS END USER LICENCE AGREEMENT (LICENCE) IS A LEGAL AGREEMENT BETWEEN
 YOU (EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED
 (ARM) FOR THE USE OF THE CMSIS SPECIFICATION, EXAMPLE CODE, DSP
 LIBRARY SPECIFICATION AND DSP LIBRARY IMPLEMENTATION AS SUCH TERMS ARE
 DEFINED BELOW (COLLECTIVELY, THE ARM DELIVERABLES). ARM IS ONLY
 WILLING TO LICENSE THE ARM DELIVERABLES TO YOU ON CONDITION THAT YOU
 ACCEPT ALL OF THE TERMS IN THIS LICENCE. BY CLICKING I AGREE, OR BY
 INSTALLING OR OTHERWISE USING OR COPYING THE ARM DELIVERABLES YOU
 INDICATE THAT YOU AGREE TO BE BOUND BY ALL THE TERMS OF THIS LICENCE. IF
 YOU DO NOT AGREE TO THE TERMS OF THIS LICENCE, ARM IS UNWILLING TO
 LICENSE YOU TO USE THE ARM DELIVERABLES AND YOU MAY NOT INSTALL, USE OR
 COPY THE ARM DELIVERABLES.

 CMSIS Specification means any documentation and C programming language
 files defining the application programming interface, naming and coding
 conventions of the Cortex Microcontroller Software Interface Standard
 (CMSIS) as well as the System View Description (SVD) documentation and
 associated XML schema file. Notwithstanding the foregoing, CMSIS
 Specification shall not include (i) the implementation of other
 published specifications referenced in the CMSIS Specification; (ii) any
 enabling technologies that may be necessary to make or use any product
 or portion thereof that complies with the CMSIS Specification, but are
 not themselves expressly set forth in the CMSIS Specification (e.g.
 compiler front ends, code generators, back ends, libraries or other
 compiler, assembler or linker technologies; validation or debug software
 or hardware; applications, operating system or driver software; RISC
 architecture; processor microarchitecture); (iii) maskworks and physical
 layouts of integrated circuit designs; or (iv) RTL or other high level
 representations of integrated circuit designs.

 DSP Library Implementation means any C programming language source
 code implementing the functionality of the digital signal processor
 (DSP) algorithms and the application programming interface as defined in
 the DSP Library Specification. The DSP Library Implementation makes use
 of CMSIS application programming interface and therefore is targeted at
 Cortex-M class processors.

 DSP Library Specification means the DSP library documentation and C
 programming language file defining the application programming interface
 of the DSP Library Implementation. Notwithstanding the foregoing, DSP
 Library Specification shall not include (i) the implementation of other
 published specifications referenced in the DSP Library Specification;
 (ii) any enabling technologies that may be necessary to make or use any
 product or portion thereof that complies with the DSP Library
 Specification, but are not themselves expressly set forth in the DSP
 Library Specification (e.g. compiler front ends, code generators, back
 ends, libraries or other compiler, assembler or linker technologies;
 validation or debug software or hardware; applications, operating system
 or driver software; RISC architecture; processor microarchitecture);
 (iii) maskworks and physical layouts of integrated circuit designs; or
 (iv) RTL or other high level representations of integrated circuit designs.

 Example Code means any files in C, C++ or ARM assembly programming
 languages, associated project and configuration files that demonstrate
 the usage of the CMSIS Specification, the DSP Library Specification and
 the DSP Library Implementation, for microprocessors or device specific
 software applications that are for use with microprocessors.

 1. LICENCE GRANTS.

 1.1 ARM hereby grants to you, subject to the terms and conditions of
 this Licence, a non-exclusive, non-transferable licence, to;

 (i) use and copy the CMSIS Specification for the purpose of developing,
 having developed, manufacturing, having manufactured, offering to sell,
 selling, supplying or otherwise distributing products that comply with
 the CMSIS 

Re: CMSIS?

2014-09-02 Thread Joel Sherrill

On 9/2/2014 9:52 AM, Daniel Gutson wrote:
 On Tue, Sep 2, 2014 at 11:51 AM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 This is the license.

 The big problem I see first is the typical use only on our hardware
 and that in order to redistribute, we must ensure that it is only
 used on ARM hardware.

 This is a common restriction on vendor provided software and I
 honestly don't know how to address including anything which
 wants an open source project to ensure that anyone downloading
 only uses it on the appropriate hardware.

 We have seen similar licenses from at least four vendors.

 If someone is able to crack this nut and find a way to not incur
 liability for the RTEMS Project, I am open to ideas. But skeptical.
 Would this mean that an implementation from scratch would be the best choice?
Unfortunately, that's the solution we have always arrived at. If the
specification
itself doesn't have restrictions on implementations.

With that said, if there is an independent open source implementation
which is
portable, we have sometimes had luck in going that route. Even when it
required
asking for a license change.

DISCLAIMER: I have no idea what the specification says technically. I
looked at the
figure and the license. Seems useful enough for cross-platform ARM code.
And
if some of those features are appropriate, this would allow
cross-platform to
non-ARM targets. But that is clearly not in ARM's best interests for
their own
implementation.

--joel

 --joel

 

 END USER LICENCE AGREEMENT FOR THE CORTEX MICROCONTROLLER SOFTWARE
 INTERFACE STANDARD (CMSIS) SPECIFICATION AND SOFTWARE

 THIS END USER LICENCE AGREEMENT (LICENCE) IS A LEGAL AGREEMENT BETWEEN
 YOU (EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED
 (ARM) FOR THE USE OF THE CMSIS SPECIFICATION, EXAMPLE CODE, DSP
 LIBRARY SPECIFICATION AND DSP LIBRARY IMPLEMENTATION AS SUCH TERMS ARE
 DEFINED BELOW (COLLECTIVELY, THE ARM DELIVERABLES). ARM IS ONLY
 WILLING TO LICENSE THE ARM DELIVERABLES TO YOU ON CONDITION THAT YOU
 ACCEPT ALL OF THE TERMS IN THIS LICENCE. BY CLICKING I AGREE, OR BY
 INSTALLING OR OTHERWISE USING OR COPYING THE ARM DELIVERABLES YOU
 INDICATE THAT YOU AGREE TO BE BOUND BY ALL THE TERMS OF THIS LICENCE. IF
 YOU DO NOT AGREE TO THE TERMS OF THIS LICENCE, ARM IS UNWILLING TO
 LICENSE YOU TO USE THE ARM DELIVERABLES AND YOU MAY NOT INSTALL, USE OR
 COPY THE ARM DELIVERABLES.

 CMSIS Specification means any documentation and C programming language
 files defining the application programming interface, naming and coding
 conventions of the Cortex Microcontroller Software Interface Standard
 (CMSIS) as well as the System View Description (SVD) documentation and
 associated XML schema file. Notwithstanding the foregoing, CMSIS
 Specification shall not include (i) the implementation of other
 published specifications referenced in the CMSIS Specification; (ii) any
 enabling technologies that may be necessary to make or use any product
 or portion thereof that complies with the CMSIS Specification, but are
 not themselves expressly set forth in the CMSIS Specification (e.g.
 compiler front ends, code generators, back ends, libraries or other
 compiler, assembler or linker technologies; validation or debug software
 or hardware; applications, operating system or driver software; RISC
 architecture; processor microarchitecture); (iii) maskworks and physical
 layouts of integrated circuit designs; or (iv) RTL or other high level
 representations of integrated circuit designs.

 DSP Library Implementation means any C programming language source
 code implementing the functionality of the digital signal processor
 (DSP) algorithms and the application programming interface as defined in
 the DSP Library Specification. The DSP Library Implementation makes use
 of CMSIS application programming interface and therefore is targeted at
 Cortex-M class processors.

 DSP Library Specification means the DSP library documentation and C
 programming language file defining the application programming interface
 of the DSP Library Implementation. Notwithstanding the foregoing, DSP
 Library Specification shall not include (i) the implementation of other
 published specifications referenced in the DSP Library Specification;
 (ii) any enabling technologies that may be necessary to make or use any
 product or portion thereof that complies with the DSP Library
 Specification, but are not themselves expressly set forth in the DSP
 Library Specification (e.g. compiler front ends, code generators, back
 ends, libraries or other compiler, assembler or linker technologies;
 validation or debug software or hardware; applications, operating system
 or driver software; RISC architecture; processor microarchitecture);
 (iii) maskworks and physical layouts of integrated circuit designs; or
 (iv) RTL or other high level representations of integrated circuit designs.

 Example Code means any 

Warnings on Head

2014-09-02 Thread Joel Sherrill
Hi

Doing some greps and mangling on the build logs from every BSP, I
discovered we have ~2350 unique warnings output by gcc.

- ~1250 of these only occur once.
- ~1900 occur less than 5 times.
- ~2270 occur less than 10 times.

These are almost certainly in BSP specific code built for variants.
My hope is that folks take a few minutes, remove warnings from
the BSP they are using and submit a patch.

That leaves about 100 warning lines that are reported in over
ten BSP builds.

At the high end, we have a handful that show up on over 100 BSP
variants. My hope is that we can eliminate these, then focus on the
next set which impact over 50 BSP variants.   I can post the full
list if someone wants to tackle a class of warnings like unused
variables, missing prototypes, etc. 

Here are the warnings which occur more than 100 times:

200 c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4: warning:
format '%lc' expects argument of type 'wint_t', but argument 4 has type
'wchar_t' [-Wformat=]
180 c/src/../../cpukit/posix/src/mprotect.c:34:5: warning: no
previous prototype for 'mprotect' [-Wmissing-prototypes]
180 c/src/../../cpukit/libmisc/shell/main_cp.c:108:1: warning:
'rtems_shell_cp_exit' defined but not used [-Wunused-function]
180 c/src/../../cpukit/libfs/src/rfs/rtems-rfs-inode.c:346:11:
warning: variable 'rrc' set but not used [-Wunused-but-set-variable]
178 c/src/../../cpukit/posix/src/keyrundestructors.c:70:11: warning:
assignment discards 'const' qualifier from pointer target type [enabled
by default]
178 c/src/../../cpukit/posix/src/keygetspecific.c:55:18: warning:
assignment discards 'const' qualifier from pointer target type [enabled
by default]
178 c/src/../../cpukit/libfs/src/rfs/rtems-rfs-rtems.c:524:19:
warning: assignment makes integer from pointer without a cast [enabled
by default]
178 c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:104:15:
warning: assignment discards 'const' qualifier from pointer target type
[enabled by default]
130 c/src/../../testsuites/sptests/spintr_err01/init.c:23:21:
warning: unused variable 'status' [-Wunused-variable]

I don't know how we have 200. There are 182 BSP log files.

Help definitely appreciated. Hopefully we can all pitch in
and reduce warnings.

Thanks.

-- 
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


tms570 and networking

2014-09-02 Thread Joel Sherrill
Hi

The tms570 has what appears to be a partial set of Makefile.am
entries for a network driver but none is present so the BSP fails
to build when networking is enabled. It appears to be missing
the line which would specify a source file anyway.

I have commented out the section locally. Should I delete it
until a network driver is submitted?

-- 
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: compile rtems source code error

2014-09-02 Thread Chris Johns

On 3/09/2014 12:05 pm, 贾超 wrote:

tools: sparc-rtems4.11.
host: x86_64ubuntu.

When I compile the source code in the sparc-rtems4.11 target, always
appear the following error.

../../../sis/lib/include/rtems/rtems_bsdnet_internal.h:54:7: note:
expected 'void *' but argument is of type 'volatile struct
dwmac_desc_ext_erx *'
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
'dwmac_desc_enh_destroy_tx_desc':
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:3:
warning: implicit declaration of function '__DEVOLATILE'
[-Wimplicit-function-declaration]
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:3:
warning: nested extern declaration of '__DEVOLATILE' [-Wnested-externs]
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:34:
error: expected expression before 'void'
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
'dwmac_desc_enh_release_tx_bufs':
../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850:29:
error: expected expression before 'void'.

what cause this error?



Your tool set. A change in newlib related to this patch fixes the issue ...

https://sourceware.org/ml/newlib/2013/msg00250.html

Sebastian's email provides a solution 

http://lists.rtems.org/pipermail/devel/2014-March/006265.html


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] or1k: Implement context validate and context volatile clobber functions.

2014-09-02 Thread Chris Johns

On 3/09/2014 12:21 am, Joel Sherrill wrote:

  cpukit/score/cpu/or1k/preinstall.am|6 +-


Did this patch happen before my fix to the preinstall went in ?

I am seeing an issue with this one.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel