In file included from nuttx/drivers/rpmsg/rpmsg_port_uart.c:27:
nuttx/drivers/rpmsg/rpmsg_port_uart.c: In function ‘rpmsg_port_uart_send_connect_req’:
nuttx/drivers/rpmsg/rpmsg_port_uart.c:219:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t’ {aka ‘long int’} [-Wformat=]
219 | rpmsgerr("Send connect request failed, ret=%d\n", ret);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| ssize_t {aka long int}
nuttx/drivers/rpmsg/rpmsg_port_uart.c:219:51: note: format string is defined here
219 | rpmsgerr("Send connect request failed, ret=%d\n", ret);
| ~^
| |
| int
| %ld
nuttx/drivers/rpmsg/rpmsg_port_uart.c: In function ‘rpmsg_port_uart_send_connect_ack’:
nuttx/drivers/rpmsg/rpmsg_port_uart.c:235:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t’ {aka ‘long int’} [-Wformat=]
235 | rpmsgerr("Send connect ack failed, ret=%d\n", ret);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| ssize_t {aka long int}
nuttx/drivers/rpmsg/rpmsg_port_uart.c:235:47: note: format string is defined here
235 | rpmsgerr("Send connect ack failed, ret=%d\n", ret);
| ~^
| |
| int
| %ld
Signed-off-by: chao an <anchao.archer@bytedance.com>
Corrections to CA training verify step. The original copied from HSS didn't
make sense in all aspects:
- The check is not per lane, so it should be out of the "for (lane_sel" loop.
- The check wasn't proper. The expected outcome is just a vector of increasing numbers
separated enough
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
After read training, check also that the eye is centered properly. Sometimes
after the training the width is long enough, but it is not centered.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Interrupts on MPFS platform are currently served on the hart, on
which the up_enable_irq was called.
Call to up_disable_irq may execute on different hart than on which
the up_enable_irq was executed. In this case the interrupt is not
disabled currently.
While there is nothing fancy (irq affinity control or such), an
easy way to fix this is to simply disable the irq on all harts.
This also changes the prototypes of mpfs_plic_get_iebase and
mpfs_plic_get_claimbase to get the hart id as an argument, in
order to accomplish this.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This adjusts `qemu-armv7a:knsh` with following changes:
- use smaller flash/memory so that `-m 1024` can be omitted.
- use ELF_EXECUTABLE for apps to allow easier app debugging.
- enable graceful shutdown from NSH command.
- enable more cases of ostest (e.g. vfork, pthread_exit etc).
Signed-off-by: Yanfeng Liu <p-liuyanfeng9@xiaomi.com>
Read/write special data like 0x2a2a2a2a will trigger this issue.
The current GDB implementation has this flaw. GDB processes the RLE
decoding before espaping the data, make it impossible to repeate special
characters.
The details can be seen in GDB source code remote.c
remote_target::read_frame function.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
Summary:
Please refer to https://github.com/rust-lang/rust/pull/135757
- Updated the supported platforms list in the Rust guide to reflect that ARMv7-A and AArch64 are ready
- Removed the "WIP" (Work In Progress) label from ARMv7-A and AArch64 in the supported platforms section
Impact:
- Provides accurate information to developers about the current state of Rust support for ARMv7-A and AArch64 platforms
- Aligns the documentation with the latest developments in the Rust ecosystem
- No functional changes to the codebase, only documentation updates
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
The load/compare and RMW to wait_count need protection. Using atomic
operations should resolve both issues.
NOTE:
The assumption that the user will call pthread_cond_signal /
pthread_cond_broadcast with the mutex given to pthread_cond_wait held is
simply not true. It MAY hold it, but it is not forced. Thus, using the
user space lock for protecting the wait counter as well is not valid!
The pthread_cond_signal() or pthread_cond_broadcast() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast().
[1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_signal.html
