This is a follow-up to 366c8a5d94 (PR-15102).
* Documentation/guides/zerolatencyinterrupts.rst
(Title): Make title case consistent.
(Getting Back into the Game, Maskable Nested Interrupts): Clarify discussion
about priorities.
(Cortex-M3/4 Implementation): The first half of a sentence was deleted in
366c8a5d9 because the Kconfig that was described there no longer exists:
CONFIG_ARMV7M_USEBASEPRI. Write a new beginning for this sentence that
matches current implementation.
(Disabling the High Priority Interrupt): Change "cannot" to "must not be
allowed to" to improve clarity.
(Configuring High Priority Interrupts): Change "to NVIC" to "in NVIC" to
improve clarity.
This PR will still allow basic shell operations such as cd/ls/pwd to be used even when the environment is disabled.
Signed-off-by: chao an <anchao@lixiang.com>
when tcp retransmission only double conn->timer in Karn(tcp_timer.c L602), after retransmission in Jacobson
M is is now rtt test will become a negative value.
```
signed char m;
m = conn->rto - conn->timer; // M is now rtt test
/* This is taken directly from VJs original code in his paper */
m = m - (conn->sa >> 3);
conn->sa += m; //conn->sa is a negative value
if (m < 0)
{
m = -m;
}
m = m - (conn->sv >> 2);
conn->sv += m;
conn->rto = (conn->sa >> 3) + conn->sv; //rto
```
For example,we lost one ack packet, we will set conn->timer = 6 by backoff，conn->rto still 3.
After retransmission we will Do RTT estimation, then will get
```
conn->sa = 253
conn->rto = 46
```
Then if any packets lost it will wait for a long time before triggering a retransmission.
Test method.
We can reproduce this issue by adding drop ACK packets in tcp_input, and debug conn->rto after Jacobson.
Signed-off-by: meijian <meijian@xiaomi.com>
Add sem_wait fast operations, use atomic to ensure
atomicity of semcount operations, and do not depend
on critical section.
Test with robot:
before modify:
nxmutex_lock cost: 78 ns
nxmutex_unlock cost: 82 ns
after modify:
nxmutex_lock cost: 28 ns
nxmutex_unlock cost: 14 ns
Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
If the current platform does not require a large PATH_MAX size support and toolchain supports alloca(),
we could turn off this option to improve performance.
Signed-off-by: chao an <anchao@lixiang.com>
continue work of a68b00206b
| commit a68b00206b
| Author: hujun5 <hujun5@xiaomi.com>
| Date: Mon Dec 9 20:48:09 2024 +0800
|
| cxd56_rtc.c: use small lock in arch/arm/src/cxd56xx/cxd56_rtc.c
|
| reason:
| We hope to remove all instances of spin_lock_irqsave(NULL).
|
| Signed-off-by: hujun5 <hujun5@xiaomi.com>
Signed-off-by: chao an <anchao@lixiang.com>
Used STM32H7 spi driver as a base. The register set is nearly identical. All registers are named the same with the same offset. There are some bits within the registers that are different but are not referenced in stm32_spi.c. Therfore this driver may just work as is. I did modify the clock source selection for each SPI peripheral, but not much else. Differences in the registers were applied in hardware/stm32h5xxx_spi.h.
Added functionality to SPI to configure the SPI RCC clock.
Added SPI info to Kconfig, updated stm32_spi.c to select and set the RCC clock, and other minor updates.
Updated Pin Map for SPI, added CFG1_BPASS support
Fixed redefinition of GPIO_SPI6_SCK_2
Added SPI_MAX_KER_CK definition.
This definition was needed because the H50 chips allow a kernel clock of 250 MHz. However the datasheets for all other chips (H52, H53, H56, H57) have a max of 125 MHz.
Changed SPI Clock Source Configuration
Moved setting of SPIx clock sources to stm32h5xx_rcc.c. STM32_SPIx_FREQUENCY and STM32_RCC_CCIPR3_SPIxSEL are now defined in board.h. Added error checking in stm32_spi.c to make sure STM32_SPIx_FREQUENCY and STM32_RCC_CCIPR3_SPIxSEL are actually defined.
Style updates
Removed SPI Clock selection from Kconfig
Update arch/arm/src/stm32h5/stm32_spi.h
Co-authored-by: hartmannathan <59230071+hartmannathan@users.noreply.github.com>
Update arch/arm/src/stm32h5/Kconfig
Co-authored-by: hartmannathan <59230071+hartmannathan@users.noreply.github.com>
Update arch/arm/src/stm32h5/stm32_spi.h
Co-authored-by: hartmannathan <59230071+hartmannathan@users.noreply.github.com>
L2 needs to be zeroed to make the ECC happy. However, if there's
more than one bootloader in the chain, the cache doesn't need to
be wiped every time. One time is enough. Thus, make this optional
so that it's initialized only when really needed.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
There is a race condition when timeout and completion interrupts occur at the same time.
Fix this and simplify the eventwait code.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
The Open Group Base Specification IEEE Std 1003.1-2024 states that
> The <mqueue.h> header shall define O_RDONLY, O_WRONLY, O_RDWR,
> O_CREAT, O_EXCL, and O_NONBLOCK as described in <fcntl.h>.
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/mqueue.h.html
It also states that:
> The <mqueue.h> header shall define the struct timespec structure as described in <time.h>.
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/mqueue.h.html
The way the `mqueue.h` include file is defined right now violates the
standard, having potentially different code depending on the platform the
code is being compiled against - assuming a multi-arch POSIX environment.
The standard also states that:
> Inclusion of the <mqueue.h> header may make visible symbols defined
> in the headers <fcntl.h>, <signal.h>, and <time.h>.
So having those includes shouldn't be an issue.
reason:
svc call may trigger hardfault
Background
The origin of this issue is our desire to eliminate the function of storing
"regs" in g_current_regs and instead utilize (*running_task)->xcp.regs for storage.
The benefits of this approach include faster storage speed and
avoiding multiple accesses to g_current_regs during context switching,
thus ensuring that whether returning from an interrupt or an exception,
we consistently use this_task()->xcp.regs
Issue Encountered
However, when storing registers, we must ensure that (running_task)->xcp.regs is invalid
so that it can be safely overwritten.
According to the existing logic, the only scenario where (running_task)->xcp.regs
is valid is during restore_context. We must accurately identify this scenario.
Initially, we used the condition (running_task)==NULL for this purpose, but we deemed
this approach unsatisfactory as it did not align well with the actual logic.
(running_task) should not be NULL. Consequently, we adopted other arch-specific methods for judgment,
but due to special logic in some arch, the judgment was not accurate, leading to this issue.
Solution:
For armv6-m, we haven't found a more suitable solution, so we are sticking with (*running_task)==NULL.
For armv7-m/armv8-m, by removing support for primask, we can achieve accurate judgment.
PRIMASK is a design in armv6-m, that's why arm introduce BASEPRI from armv7-m.
It's wrong to provide this option for armv7-m/armv8-m arch.
Signed-off-by: hujun5 <hujun5@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>
CC: virtio/virtio-mmio.c virtio/virtio-mmio.c: In function 'virtio_mmio_config_virtqueue':
virtio/virtio-mmio.c:346:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
346 | addr = (uint64_t)kasan_reset_tag((FAR void *)vq->vq_ring.desc);
| ^
virtio/virtio-mmio.c:350:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
350 | addr = (uint64_t)kasan_reset_tag((FAR void *)vq->vq_ring.avail);
| ^
virtio/virtio-mmio.c:354:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
354 | addr = (uint64_t)kasan_reset_tag((FAR void *)vq->vq_ring.used)
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
The Kconfig of system/usbmsc has updated to support setting paths that bind to LUN at runtime.
More details: https://github.com/apache/nuttx-apps/pull/2876
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
This is continue work of https://github.com/apache/nuttx/pull/13726
We can utilize percpu storage to hold information about the
current running task. If we intend to implement this feature, we would
need to define two macros that help us manage this percpu information
effectively.
up_this_task: This macro is designed to read the contents of the percpu
register to retrieve information about the current
running task.This allows us to quickly access
task-specific data without having to disable interrupts,
access global variables and obtain the current cpu index.
up_update_task: This macro is responsible for updating the contents of
the percpu register.It is typically called during
initialization or when a context switch occurs to ensure
that the percpu register reflects the information of the
newly running task.
Signed-off-by: hujun5 <hujun5@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>
