when client read and poll wait buffer from server side and server side may
poll notify more than one times, then rpmsgdev in client side will call
"rpmsgdev_poll_setup(priv, 0, false);" twice which will cause crash in
vela rpmsgdev_server.c
Signed-off-by: rongyichang <rongyichang@xiaomi.com>
the msg count is not changed while iov len is increased.
which may cause the buffer reply by server is bigger than
msg count
Signed-off-by: rongyichang <rongyichang@xiaomi.com>
Some armv7-m-based SoCs do not work with atomic instructions,
even though armv7-m supports them.
To avoid using atomic instructions generated by gcc,
CONFIG_LIBC_ARCH_ATOMIC is newly introduced with which
arch_atomic.c is linked explicitly.
However, the function names need to be changed to avoid
build errors, since the functions described in stdatomic.h
are gcc built-in and inlined when the code is compiled.
Signed-off-by: Takuya Miyasita <Takuya.Miyashita@sony.com>
This would avoid the undesirable intertactions with the serial driver
described in https://github.com/apache/nuttx/issues/14662.
Although I'm not entirely happy with this fix because it assumes
the particular implementations of up_putc/up_nputc and its association
to the serial devices, I haven't come up with better ideas for now.
An alternative is to place some serializations inside the target
specific serial (and/or whatever provides up_putc api) implementaitons.
But it isn't too attractive to put potentially complex logic into the
low-level machinaries, especially when we have a lot of similar copies
of it.
Another alternative is to deprecate up_putc. (at least for the purpose
of syslog.) But it seems at least some of users are relying on what
the current implementation provides heavily.
This commit also removes g_lowputs_lock because the critical section
would serve the purpose of the lock as well.
added shell script darwin_arm64.sh for macOS Apple Silicon
updated toolchains for macOS on Apple Silicon
- arm64
- aarch64
- xpack-riscv
- xtensa-esp32
Suppress the warning message "nuttx has a LOAD segment with RWX permissions" in case of RAM boot mode is selected.
RAM MODE: BOOT_RUNFROMEXTSRAM/BOOT_RUNFROMISRAM/BOOT_RUNFROMSDRAM/BOOT_COPYTORAM
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
with greenhills version older than 202354, the __attribute__((naked))
cannot handled by greenhills compiler, and will report warning:
"/home/guoshichao/work_profile/vela_os/vela_car_6/nuttx/arch/arm/src/armv7-m/arm_svcall.c", line 79: warning #1097-D:
unknown attribute "naked"
static void dispatch_syscall(void) naked_function;
^
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
when we build mbedtls in vela with ghs compiler, the mbedtls need to
access __ARM_ARCH and __ARM_FEATURE_DSP, and to construct the inline asm
code based on these two macros.
With ghs compiler, these two macros are not defined, and will be
evaluated as 0 by default, and thus will using to wrong inline asm code,
in order to handle this issue, we need to add conversion between the ghs
and gcc with __ARM_ARCH, __ARM_FEATURE_DSP
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
when build with greenhills_202354, the naked_function should only
contains the basic asm statements, so if the naked_function contains the
statements that using to accept params from C lang runtime, then build
error will reported:
error #101112: Only basic asm expressions are allowed for functions
with __attribute__((naked)): dispatch_syscall
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
reason:
when CONFIG_CLOCK_TIMEKEEPING=y, compiler error may report
In file included from /home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/sched.h:42,
from /home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/arch.h:89,
from boardctl.c:33:
/home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/irq.h:261:12: error: conflicting types for 'enter_critical_section'; have 'irqstate_t(void)' {aka 'long unsigned int(void)'}
261 | irqstate_t enter_critical_section(void) noinstrument_function;
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/wqueue.h:37,
from /home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/addrenv.h:39,
from /home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/sched.h:40:
/home/hujun5/downloads1/vela_sim/nuttx/include/nuttx/wdog.h:267:11: note: previous implicit declaration of 'enter_critical_section' with type 'int()'
267 | flags = enter_critical_section();
| ^~~~~~~~~~~~~~~~~~~~~~
hujun5@hujun5-OptiPlex-7070:~/downloads1/vela_sim/nuttx$ make -j12
sched/sched_processtimer.c: In function 'nxsched_process_timer':
sched/sched_processtimer.c:178:3: error: implicit declaration of function 'clock_update_wall_time' [-Werror=implicit-function-declaration]
178 | clock_update_wall_time();
Signed-off-by: hujun5 <hujun5@xiaomi.com>
`up_perf_init` defined in `nuttx/arch.h`, if CONFIG_ARCH_PERF_EVENTS enabled the compiler will raise a error:
```
board/esp32c3_boot.c:55:3: error: implicit declaration of function 'up_perf_init' [-Wimplicit-function-declaration]
55 | up_perf_init(NULL);
| ^~~~~~~~~~~~
board/esp32c3_boot.c:55:16: error: 'NULL' undeclared (first use in this function)
55 | up_perf_init(NULL);
| ^~~~
board/esp32c3_boot.c:28:1: note: 'NULL' is defined in header '<stddef.h>'; this is probably fixable by adding '#include <stddef.h>'
27 | #include <nuttx/board.h>
+++ |+#include <stddef.h>
28 |
board/esp32c3_boot.c:55:16: note: each undeclared identifier is reported only once for each function it appears in
55 | up_perf_init(NULL);
| ^~~~
make[1]: *** [/home/huang/Work/nx/nuttx/boards/Board.mk:83: esp32c3_boot.o] Error 1
```
Will report clang: error: invalid argument 'medium' to -mcmodel=
-mcmodel=large will both support clang and gcc.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
Improved
1. The pre-installed "picotool" should not depend on `PICO_SDK_PATH`
2. Perhaps we should compile "picotool" from `PICO_SDK_PATH` if it was not found in $PATH
Tests
1. The "picotool" is pre-installed or built from `PICO_SDK_PATH`
LD: nuttx
Generating: nuttx.uf2
Done.
2. `PICO_SDK_PATH` is specified but "picotool" is not installed
LD: nuttx
Building: picotool
Generating: nuttx.uf2
Done.
3. Neither "picotool" nor `PICO_SDK_PATH` are installed/specified
LD: nuttx
PICO_SDK_PATH/picotool must be specified/installed for flash boot
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
1. bin and kbin folders are dynamically generated
2. Context comes before depend, so the bin and kbin folders are created in the context construction phase. When the depend process comes, each library is downloaded, and a relative bin/xxx and kbin/xxx directory is created for each library to place files. This is to prevent duplicate file names.
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
Migrate pages:
* Delayed ACK and TCP Performance
* TCP Network Performance
* NxWM Threading
* Framebuffer Character Driver
From Confluence wiki to official wiki
1. Calling CLEAN on these folders did not have any effect
2. bin,kbin will be created during the context construction process
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
