| .. |
|
a1x
|
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 |
|
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
|
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 |
|
armv7-a
|
Add logic to initialize the per-process user heap when each user process is started
|
2014-09-10 15:55:36 -06:00 |
|
armv7-m
|
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 |
|
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
|
Restructuring of build to allow use of use-space allocators by kernel logic in the kernel build.
|
2014-09-02 11:22:09 -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
|
SAM3X/Arduino Due: Fix typo in sam3x_periphclks.h; add SCLK definitions to board.h header file. From Fabien Comte
|
2014-09-08 06:14:59 -06:00 |
|
sama5
|
SAM3X/Arduino Due: Fix typo in sam3x_periphclks.h; add SCLK definitions to board.h header file. From Fabien Comte
|
2014-09-08 06:14:59 -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
|
Fix for UART7 and UART8 on STM32 clock enable from Aton
|
2014-09-11 10:27:40 -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 |
