and update the related stuff in libs/libc/libc.csv
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Id695a7f07bf18a7b4e526297f9131c75ddb79d30
let toolchain decide the correct value base on the command line
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I342db6a88e4a161a322a8fea48a59e6ca7617ae6
Move global variable declaration out of include/nuttx/video/video.h and into the file where it is initialized. With some toolchains/environments, declaring globals in header files results in multiply defined symobl errors at link time. This corrects that build problem.
In the FLAT build if CONFIG_LIB_SYSCALL=y, then the function task_spawn() will be duplicated.: One version in libs/libc/spawn and one version in sched/task.
The version of task_spawn in lib/libc/spawn exists only if CONFIG_LIB_SYSCALL is selected. In that case, the one in sched/task/task_spawn.c should be static, at least in the FLAT build.
The version of task_spawn.c in libs/libc/spawn simply marshals the parameters into a structure and calls nx_task_spawn(). If CONFIG_LIB_SYSCALL is defined then nx_task_spawn() will un-marshal the data can call the real task spawn. This nonsense is only necessary because task_spawn has 8 parameters and the maximum number of parameters in a system call is only 6.
Without syscalls: Application should call directly in task_spawn() in sched/task/task_spawn.c and, hence, it must not be static
With syscalls: Application should call the marshalling task_spawn() in libs/libc/spawn/lib_task_spawn.c -> That will call the autogenerated nx_task_spawn() proxy -> And generate a system call -> The system call will the unmarshalling nx_task_spawn() in sched/task/task_spawn.c -> Which will, finally, call the real task_spawn().
The side-effect of making task_spawn() static is that it then cannot be used within the OS. But as far as I can tell, nothing in the OS itself currently uses task_spawn() so I think it is safe to make it conditionally static. But that only protects from duplicate symbols in the useless case mentioned above.
Reported by 권석근 <kwonsksj@gmail.com>:
I found a bug at "pty.c" during ssh server implementation.
When I turn on CONFIG_SERIAL_TERMIOS and OPOST|ONLCR on pty device
for nsh console's stdin/stdout (ssh shell service), I've got system crash.
Bugs at line 687 of pty.c, pty_write()
ntotal++;
when converting '\n' to '\r\n', pty_write() will return more than requested
(+1, for example) length. and this will break caller lib_fflush(), line 150
of lib_libfflush.c.
When she get (libfflush()) bytes_nwritten which is greater than nbuffer,
nbuffer goes to negative at line 150 and eventually destroys
*stream->fs_bufpos at line 163 of lib_libflush.c
Removing ntotal++; line 687 of pty.c will fix this bug.
BTW, nsh using ptm/pty as a ssh shell service works great with libssh +
mbedtls.
since the user may use math library from toolchain directly
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I67ccc4830403e3c15a84a8f9b1420d9a10894ddf
Only Make.defs files tht followed the same pattern as the ARM Make.defs were modified. This excludes some of the sim and renesas Make.defs files and all of the z80 Make.defs files.
Before any other Make logic can be used, we must immediately build the tools/incdir binary. It will be used as soon as Make.defs is included and will generate errors otherwise.
Remove the other locations in the tools/incdir binary was being build from tools/Makefile.unix and tools/Makefile.win
This is a change suggested by Xiao Xiang in an email thread. Some make variables with depend on forking and shell and running a script to get the value of the variable. Using := we can force the calculation to occur only once. This leads to a small but consistent improvement in build performance.
This change really applies to ALL Make.defs files but is applied only to one here so that it can be thoroughly verified and possbily leveraged to other Make.defs files in the future.
1. If config.c is compiled on any platform other than Cygwin, then the variable wintools is not used.
2. Add more debug output so we can see what is going on in the PR checks.
574b25 broke the internal DMA buffers usage that solved
the following problem: The DMA capable interface does
not know the buffers extent. It calulates it from size.
The user may need to transfer less than a cachline bytes,
but STILL have a DMA cabable buffer. The user is therefore
foreced to transfer more data then needed to "trick" the
DMA cabable function. This is a wast of bus bandwith and
may not work will all devices. The internal buffer, solve
this issue.
stm32h7:stm32_spi review changes
Added sugestion from jlaitine to support RX only.
The use of uint64_t primitive type in NFS structures forces the compiler to align data on an 8-byte boundary.
As a result of this, unwanted gaps being created, which causes NFS to fail. (e.g., nfs_read/initialize the request)
Using nfsuint64 instead of uint64_t fixes this issue.
Block and MTD drivers may be opened and managed as though they were character drivers. But this is really sleight of hand; there is a hidden character driver proxy that mediates the interface to the block and MTD drivers in this case.
fstat(), however, did not account for this. It would report the characteristics of the proxy character driver, not of the underlying block or MTD driver.
This change corrects that. fstat now checks if the character driver is such a proxy and, if so, reports the characteristics of the underlying block or MTD driver, not the proxy character driver.
This is a work in progress, and now only serves as
DMA enabled simplex RX-only mode bus controller
Signed-off-by: Jukka Laitinen <jukka.laitinen@intel.com>
Make it possible to enqueue and receive full buffers of data with
single call, to avoid call overhead when sending / receiving large amounts
of data.
Also make it possible for the slave device to leave received data in the
controller receive buffers and retrieve it from there by polling
Signed-off-by: Jukka Laitinen <jukka.laitinen@intel.com>
