Fixes build error with -Werror:
shm/shmfs.c: In function 'shmfs_read':
shm/shmfs.c:122:33: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]
122 | memcpy(buffer, sho->paddr + startpos, nread);
| ^
shm/shmfs.c: In function 'shmfs_write':
shm/shmfs.c:166:25: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]
166 | memcpy(sho->paddr + startpos, buffer, nwritten);
| ^
cc1: all warnings being treated as errors
1 page might not be enough, if the task has a bigger stack. Best effort
is to allocate the default amount, however this won't work will all
tasks either.
Currently TX_FIFO_SIZE is not altered in mpfs_ep_set_fifo_size(),
but all paths (RX and TX) change MPFS_USB_RX_FIFO_SIZE only.
Fix the TX_FIFO_SIZE setup.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
Summary:
- I noticed that device discovery for virtio-mmio devices does not
work without bus=virtio-mmio-bus.x option. Without this option,
qemu assigns the virtio device into the virtio-mmio space
in reverse order automatically.
- To fix this issue, we must specify the correct numbers for the
target machines. (i.e. arm32/64->32, rv32/64->8)
Impact:
- None
Testing:
- Tested with qemu-7.2.4
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
TCP receive tested with different IOB_BUFSIZE:
| | 256B vs 1534B | 512B vs 1534B | 768B vs 1534B |
| :---------: | :-----------: | :-----------: | :-----------: |
| Non-SMP | ~85% | ~93% | ~96% |
| armv8a-SMP | ~66% | ~84% | ~92% |
| rv32/64-SMP | ~52% | ~72% | ~83% |
It seems we still get performance penalty on smaller IOBs, and may be
affected more under SMP mode. It may be caused by critical sections in
IOB operations.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Some driver like virtio-net can offload fragmented IOBs, so an interface
to support this feature is needed.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Previously, the CONFIG_NET_LL_GUARDSIZE is fixed to 32 (64-Bit) or
28 (32-Bit), it's a little bit tricky.
Now add support to any value greater than minimal size.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Because multiple dependencies behind the context are compiled in parallel,
if they have dependencies on each other, it will cause compilation errors
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
- Fix `ip6_map_ipv4addr` and `ip6_get_ipv4addr` macro to work under
different endianness.
- Use `iob_reserve` instead of `iob_trimhead` in `udp_datahandler`.
- Because we may set `sockaddr_in6` into IPv4 header, which causes
`offset` become negative. `iob_reserve` can hold this case while
`iob_trimhead` cannot.
- Select IPv4 domain in send case.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
If we apply `iob_reserve` on an IOB with `io_offset != 0`, the `head->io_pktlen` and `iob->io_len` will become wrong value, because we only need to trim `offset - iob->io_offset`.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Additional information here:
- no code logic change, just add type hint
- make the code easy to work with
- minor python3 requirement without any complex type feature
Signed-off-by: renweibo <renweibo@xiaomi.com>
When do poll operation and the tcp connection state is TCP_ALLOCATED, eventset(POLLERR|POLLHUP) is return, causing the libuv poll_multiple_handles to fail.
Verification: Use the libuv test case ` uv_run_tests poll_multiple_handles`.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
After sevaral resets of the chip after programming, rptun stops working correctly.
Simple test with RPMSG UART causes a lock:
on the netcore:
nsh>cat /dev/ttyproxy
on the appcore:
nsh>echo xxx > /dev/ttyproxy
The problem doesn't occur with NRF53_FLASH_PREFETCH=n
To determine whether a signal is real-time signal or standard signal, the POSIX standard https://www.man7.org/linux/man-pages/man7/signal.7.html defines a real-time signal between SIGRTMIN and SIGRTMAX , which can store multiple copies, otherwise only one can be retained.
Signed-off-by: xinhaiteng <xinhaiteng@xiaomi.com>
If we are running on a single CPU architecture, then we know interrupts
are disabled and there is no need to explicitly call enter_critical_section().
However, in the SMP case, enter_critical_section() is required prevent
multiple cpu to enter timer_start.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Tomáš Pilný