Gregory Nutt 5e285b8bc4 More NxWM build fixes

2014-09-20 16:47:00 -06:00

..

a1x

Add a sharable version of arm_virtpgaddr()

2014-09-16 16:49:44 -06:00

arm

ELF relocations. Some relocation types do not have a named symbol associated with them. The design did not account for that case

2014-09-09 16:52:51 -06:00

armv6-m

Move common/up_signal_dispatch.c to armv6-m, armv7-m, and armv7-a. The armv7-a version needs to be different to handle the case where we are dispatch kernel mode signals when running under a user mode group

2014-09-16 13:35:29 -06:00

armv7-a

Ooops... a file that I forgot to add yesterday

2014-09-17 09:52:07 -06:00

armv7-m

Move common/up_signal_dispatch.c to armv6-m, armv7-m, and armv7-a. The armv7-a version needs to be different to handle the case where we are dispatch kernel mode signals when running under a user mode group

2014-09-16 13:35:29 -06:00

c5471

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

calypso

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

common

More naming changes to get the stm3240g-eval/nxterm configuration building again

2014-09-20 15:53:28 -06:00

dm320

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

imx

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

kinetis

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

kl

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

lpc17xx

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

lpc31xx

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

lpc43xx

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

lpc214x

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

lpc2378

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

nuc1xx

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

sam34

Only SAM4 family has RTTDIS bit in the MR register. SourceForge bug #33 from Fabien Comte

2014-09-17 07:42:12 -06:00

sama5

More NxWM build fixes

2014-09-20 16:47:00 -06:00

samd

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

stm32

More naming changes to get the stm3240g-eval/nxterm configuration building again

2014-09-20 15:53:28 -06:00

str71x

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

tiva

There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.

2014-09-01 15:39:34 -06:00

.gitignore

…

Makefile

The 'make export' target needs to bundle up the user C startup file (crt0), not the kernel head object

2014-09-04 13:31:34 -06:00