| .. |
|
a1x
|
Move some share-able logic from sama5/sam_pgalloc.c to armv7-a/arm_physpgaddr.c
|
2014-09-16 13:29:43 -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
|
Fix a typo in system call when fetching parameter from the stack: regs[REG_PC]+4 is the address, not regs[REG_PC+4]
|
2014-09-15 10:55:10 -06:00 |
|
armv7-a
|
Move some share-able logic from sama5/sam_pgalloc.c to armv7-a/arm_physpgaddr.c
|
2014-09-16 13:29:43 -06:00 |
|
armv7-m
|
Fix a typo in system call when fetching parameter from the stack: regs[REG_PC]+4 is the address, not regs[REG_PC+4]
|
2014-09-15 10:55:10 -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
|
Move some share-able logic from sama5/sam_pgalloc.c to armv7-a/arm_physpgaddr.c
|
2014-09-16 13:29:43 -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
|
.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 |
