Gregory Nutt a9864bc100 Extend virtual/physical address conversions to include addresses in shared memory.		2014-09-23 16:03:08 -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	Extend virtual/physical address conversions to include addresses in shared memory.	2014-09-23 16:03:08 -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	.dSYM only needs to be in the same .gitignore files as .exe	2013-05-30 15:02:04 -06:00
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