Whenever a SPI flash operation is going to take place, it's
necessary to disable both the instruction and data cache. In order
to avoid the other CPU (if SMP is enabled) to retrieve data from
the SPI flash, it needs to be paused until the current SPI flash
operation finishes. All the code that "pauses" the other CPU (in
fact, the CPU spins until `up_cpu_resume` is called) needs to run
from the instruction RAM.
SAMv7 QSPI peripheral does not copy-in/out directly into/from
user provided buffer, but use a dedicated memory that is interfaces
using byte copy. The QSPI command buffer can point to memory with
any alignment
Signed-off-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Add a new field to record the global on the basis of mm_backtrace.
When using alloc, the field is incremented by 1,
so that the memory usage can be dumped within the range
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
armv8r and armv8a have different process affinity,
and sgi affinity needs to be able to adapt all of them.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Summary
For ARM64, it need to set IRQ type(EDGE or LEVEL). it's specific
for ARM64 PPI or SPI.
The change add arm64_gic_irq_trigger to set IRQ type
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Summary
add up_affinity_irq/up_trigger_irq/up_prioritize_irq for gicv3
these interface is necessary for some drivers
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Summary:
GICR_PWRR is a IMPLEMENTATION-DEFINED register for gc700/gc600, which
is following gic v3 and v4.
Please check GICR_PWRR define at TRM of GIC600/GIC700 for more detail
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
The compiler will optimize boot_early_memset to memset,
but memset in libc cannot be used before MMU is enabled.
Therefore, assembly language is used to implement the
initialization of bss to avoid this problem.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
When the MMU/MPU of core0 is enabled while those of other cores are not,
it is unsafe to operate the idle stack simultaneously. The idle stack
of other cores will be flushed by the contents in the cache of core0,
therefore it is necessary to initialize the idle stack and let each
core handle it on its own.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Some chips only have one core that supports secure in smp mode,
so need change EXC_RETURN to non-secure when switching to a core that
does not support secure.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Notify the compiler that the condition flag has changed to prevent the
compiler from optimizing and reordering instructions, which may cause exceptions.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
to avoid the infinite recusive dispatch:
*0 myhandler (signo=27, info=0xf3e38b9c, context=0x0) at ltp/testcases/open_posix_testsuite/conformance/interfaces/sigqueue/7-1.c:39
*1 0x58f1c39e in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:167
*2 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*3 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049334) at signal/sig_dispatch.c:115
*4 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049334) at signal/sig_dispatch.c:435
*5 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*6 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*7 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*8 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049304) at signal/sig_dispatch.c:115
*9 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049304) at signal/sig_dispatch.c:435
*10 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*11 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*12 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*13 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf40492d4) at signal/sig_dispatch.c:115
*14 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf40492d4) at signal/sig_dispatch.c:435
*15 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*16 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*17 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*18 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf40492a4) at signal/sig_dispatch.c:115
*19 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf40492a4) at signal/sig_dispatch.c:435
*20 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*21 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*22 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*23 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049274) at signal/sig_dispatch.c:115
*24 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049274) at signal/sig_dispatch.c:435
*25 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*26 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*27 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*28 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049244) at signal/sig_dispatch.c:115
*29 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049244) at signal/sig_dispatch.c:435
*30 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*31 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
ESP32 and ESP32-S3 should use the ROM-defined versions of the libc
in flat build and, when building the protected mode, in the kernel.
The ROM-defined version of the libc functions can't be used in the
userspace, however, because it isn't allowed to access the memory
region in flash directly from the userspace. That being said,
`LIBC_PREVENT_STRING_KERNEL` should be selected to avoid building
any implementation of the libc, being the ROM-defined versions
linked instead.
NuttX's software implemented version of the libc will be built in
the userspace. Also, the assembly-defined version of some of the
libc functions (`XTENSA_xxx`) may also be selected to be used in
the userspace.
if multiple threads are doing serial read/write at the same time,
the driver will only wake up one of the thread, which will cause
other threads fail to be woken up in time and cause blocking
Signed-off-by: chao an <anchao@xiaomi.com>
Make low/full speed devices work with EHCI while OHCI is disabled. A
high speed USB hub has to be plugged into the root hub. This change
will also allow the optional use of a full speed hub between the
high speed hub and the low/full speed device. A recursive mutex is
used to avoid deadlocks.
Move the mapping functionality from up_shmat/shmdt into two generic
mapping functions. This makes it possible to do other mappings besides
user shared memory area mappings.
During the serial reconfiguration from bootloader to the
NuttX a trash character "?" (Unicode replacement U+FFFD)
was printed in the screen.
This fix was discovered by Sylvio Alves from Espressif!
Instead of using Espressif's emulated NVS to save Wi-Fi data, use
`wapi`s wireless configure initialization mechanism for saving
Wi-Fi data. It 1) avoids creating a specific storage partition
just to save Wi-Fi data (ESP32-C3's storage partition is used
instead); 2) avoids initialization problems of the emulated NVS
when SMP is enabled (the Wi-Fi driver tries to initialize it before
the actual partition is initialized); and 3) enables reconnecting
using `wapi reconnect` command and connect the device automatically
on bringup if `CONFIG_NETUTILS_NETINIT` is selected.
Instead of using Espressif's emulated NVS to save Wi-Fi data, use
`wapi`s wireless configure initialization mechanism for saving
Wi-Fi data. It 1) avoids creating a specific storage partition
just to save Wi-Fi data (ESP32's storage partition is used
instead); 2) avoids initialization problems of the emulated NVS
when SMP is enabled (the Wi-Fi driver tries to initialize it before
the actual partition is initialized); and 3) enables reconnecting
using `wapi reconnect` command and connect the device automatically
on bringup if `CONFIG_NETUTILS_NETINIT` is selected.
Instead of using Espressif's emulated NVS to save Wi-Fi data, use
`wapi`s wireless configure initialization mechanism for saving
Wi-Fi data. It 1) avoids creating a specific storage partition
just to save Wi-Fi data (ESP32-S3's storage partition is used
instead); 2) avoids initialization problems of the emulated NVS
when SMP is enabled (the Wi-Fi driver tries to initialize it before
the actual partition is initialized); and 3) enables reconnecting
using `wapi reconnect` command and connect the device automatically
on bringup if `CONFIG_NETUTILS_NETINIT` is selected.
Devices connected to the same USB bus should have unique function addresses.
This was not true for root hubs with multiple ports. After this change,
enumeration is more reliable on the sama5d3-xplained board when both root hub
ports are used.
This change amounts to using one usbhost_devaddr_s object per root hub
instead of one per root hub port. For the majority of boards only one
root hub port is available so no change in behavior should be expected.
Currently only Port UART0 is supported for Allwinner A64. This PR adds support for all UART Ports: UART1 to UART4. (Except R-UART, which is a special low-power UART)
This is required for the upcoming LTE Modem Driver (Quectel EG25-G) for PINE64 PinePhone, which uses UART3. [(Details here)](https://lupyuen.github.io/articles/lte2)
The code was adapted from the NuttX UART Driver for Allwinner A1X: [`a1x_serial.c`](https://github.com/apache/nuttx/blob/master/arch/arm/src/a1x/a1x_serial.c)
`arch/arm64/src/a64/a64_serial.c`: Added ports UART1 to UART4, based on [`a1x_serial.c`](https://github.com/apache/nuttx/blob/master/arch/arm/src/a1x/a1x_serial.c)
`arch/arm64/src/a64/a64_serial.h`: Added IRQs for UART1 to UART4. Moved UART Base Addresses to `a64_memorymap.h`
`arch/arm64/src/a64/hardware/a64_memorymap.h`: Added UART Base Addresses for UART0 to UART4
`arch/arm64/src/a64/Kconfig`: Added UART1 to UART4 to Allwinner A64 Peripheral Selection menu
`boards/arm64/a64/pinephone/configs/lcd/defconfig`, `lvgl/defconfig`, `nsh/defconfig`, `sensor/defconfig`: Fixed `UART1_SERIAL_CONSOLE` to `UART0_SERIAL_CONSOLE`
This commit aims to enable the use of ROM functions on ESP32-S2.
This is done by creating the required syscall stubs table and adding the missing symbols to the linker script.
This commit aims to enable the use of ROM functions on ESP32.
This is done by creating the required syscall stubs table and adding the missing symbols to the linker script.
These series have the following GPIO ports:
- STM32F03X: A to D, and F
- STM32F05/07/09X: A to F
- STM32G0X: A to F
- STM32L0X: A to E, and H
Signed-off-by: Takumi Ando <t-ando@advaly.co.jp>
compile error log:
common/arm64_arch_timer.c: In function 'arm64_tick_max_delay':
common/arm64_arch_timer.c:178:12: error: conversion from 'long unsigned int' to 'clock_t' {aka 'unsigned int'} changes value from '18446744073709551615' to '4294967295' [-Werror=overflow]
178 | *ticks = UINT64_MAX;
| ^~~~~~~~~~
Signed-off-by: hujun5 <hujun5@xiaomi.com>
At present, the serial drivers qemu_serial.c and serial_pl011.c on the fvp-v8r and qemu platforms in arm64 are duplicated
and need to be merged. The plan is to place them under the drivers\serial directory to create a common code module,
so that both fvp-v8r and qemu can use the same code.
In the future, if new platforms use pl011 serial ports, they can also be directly reused
Signed-off-by: hujun5 <hujun5@xiaomi.com>
If the CONFIG_MMCSD_SDIOWAIT_WRCOMPLETE is enabled and the
card is found to be ready in the waitenable call. Then
we do not need a Watchdog nor to configure the pin for
IRQ to detect ready.
This was reported as an error, and it is not, it simply means
we do not have to wait.
Summary:
Keeping this option out of depend on any common serial.
Using the option, need to implement xxx_lowputc.S/c.
You can also logging the booting message through rewriting
fake arm64_lowputc with other debug method (eg semihosting,
ARM debug channel etc).
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
1. arm64/makefile: preprocess link script to make configure more flexibly
2. arm64/EXTRA_LIBS: link all staging library
Signed-off-by: chao an <anchao@xiaomi.com>
The following message is printed continuously and the nsh
shell is unusable on sama5d3-xplained.
"OHCI ERROR: Unhandled interrupts pending: 000001". This
happens when a keyboard is removed and reinserted on
port3 (lower port) while a bluetooth dongle is in port2.
- putreg32() is used the wrong way around (reg, val) instead of (val, reg)
- MPFS_SPI_FRAMESIZE is not a register, FSIZE is the name
- Clear all interrupts _before_ writing the FIFO, this prevents a race
condition where a short transmission completes before the interrupt is
enabled.
in SMP, signal processing cannot be nested, we use xcp.sigdeliver to identify whether there is currently a signal being processed, but this state does not match the actual situation
One possible scenario is that signal processing has already been completed, but an interrupt occurs, resulting in xcp.sigdeliver not being correctly set to NULL,
At this point, a new signal arrives, which can only be placed in the queue and cannot be processed immediately
Our solution is that signal processing and signal complete status are set in the same critical section, which can ensure status synchronization
Signed-off-by: hujun5 <hujun5@xiaomi.com>
In the interrupt context, we should first save the interrupt context and modify the interrupt register
to execute the signal processing program immediately after exiting the current interrupt
Signed-off-by: hujun5 <hujun5@xiaomi.com>
1. Get the value of sp from dump regs when an exception occurs,
to avoid getting the value of fp from up_getsp and causing
incomplete stack printing.
2. Determine which stack the value belongs to based on the value
of SP to avoid false reports of stack overflow
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Follow the change: https://github.com/apache/nuttx/pull/9151,
if MM_CUSTOMIZE_MANAGER is enabled, heap memory manager in host is used,
for example in sim:asan build.
malloc and related allocation APIs will fall back to host_realloc,
do not free memory of zero-length reallocation. So memory allocations
return valid pointer when request zero size in all sim build.
call stack:
malloc() (mm/umm_heap/umm_malloc.c)
mm_malloc() (arch/sim/src/sim/sim_heap.c)
mm_realloc() (arch/sim/src/sim/sim_heap.c)
host_realloc() (arch/sim/src/sim/posix/sim_hostmemory.c)
host_memalign() (arch/sim/src/sim/posix/sim_hostmemory.c)
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
The fast-unwind implementation of leak-sanitizer will obtain the
current stack top/bottom and frame address(Stack Pointer) for
backtrace calculation:
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13/libsanitizer/lsan/lsan.cpp#L39-L42
Since the scheduling mechanism of NuttX sim is coroutine
(setjmp/longjmp), if the Stack Pointer is switched, the fast-unwind
will unable to get the available address, so the memory leaks on the
system/application side that cannot be caught normally. This PR will
disable fast-unwind by default to avoid unwind failure.
Signed-off-by: chao an <anchao@xiaomi.com>
Add support to select WPA3-SAE while connecting to an AP. Please
note that STA mode sets a security threshold, i.e, it was able to
connect to a WPA3-SAE network prior to this change because it
connects to an equally or more secure network than the set
threshold. Considering this patch, the device is now able to
ignore WPA2-PSK APs when WPA3 is set.
Add support to select WPA3-SAE while connecting to an AP. Please
note that STA mode sets a security threshold, i.e, it was able to
connect to a WPA3-SAE network prior to this change because it
connects to an equally or more secure network than the set
threshold. Considering this patch, the device is now able to
ignore WPA2-PSK APs when WPA3 is set.
CURRENT_REGS may change during assert handling, so pass
in the 'regs' parameter at the entry point of _assert.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Unplugging a USB device from an OHCI root hub will cause
a deadlock if DRVR_EPFREE is called from sam_rhsc_bottomhalf. A
typical call chain looks like this: sam_rhsc_bottomhalf->
CLASS_DISCONNECTED->usbhost_destroy->DRVR_EPFREE. In this case
DRVR_EPFREE tries to lock a locked mutex. A recursive mutex
prevents this deadlock.
minidump will backtrace failure when use C code to save user context,
because the stack push operation in C code can disrupt the stack information.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
- Fix DMA addressing issues within litex_sendsetup/litex_recvsetup
- Extend with handling specific to eMMC commands during init & use.
- Cleanup of 4-bit BUS handling for SD and eMMC
- For eMMC, Send CMD0 during init as per JEDEC v4.41 for pre-idle
This commit adds deifiniton of get_timer_period() and adj_timer_period()
functions used by adjtime() interface.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Store the old environment in a local context so another temporary address
environment can be selected. This can happen especially when a process
is being loaded (the new process's mappings are temporarily instantiated)
and and interrupt occurs.
When l2cc is already in disable state, performing a disable operation
again will flush incorrect cache data to memory
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Invalidate operations at DDI0246H_l2c310_r3p3_trm:
If there is a stale entry in the L2 cache, the system enables the invalidation of
the L1 cache. But before the controller invalidates the L2 cache, it allocates a
line from the L2 cache to an L1 cache.
The robust code sequence for invalidation with a non-exclusive cache arrangement is:
1. InvalLevel2 Address ; forces the address out past level 2
2. CACHE SYNC ; Ensures completion of the L2 inval
3. InvalLevel1 Address ; This is broadcast within the cluster
4. DSB ; Ensure completion of the inval as far as Level 2.
This sequence ensures that, if there is an allocation to L1 after the L1 invalidation, the data
picked up is the new data and not stale data from the L2
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Summary:
- This commit applies the changes from imxrt
- See 3a4542f3c4
Impact:
- imx6 ethernet with d-cache
Testing:
- Tested with imx6_with_ar8031 (will be added later)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
ROM symbols provided by linker are placeholders for addresses
and not a pure addresses, so we need to read data pointed by
ROM symbols instead of using those as pure addresses.
Signed-off-by: Petro Karashchenko <petro.karashchenko@gmail.com>
If CONFIG_MM_CUSTOMIZE_MANAGER enabled on sim, malloc/mmap is bypassed to glibc, so the memory allocated without execution permisson.
For this case, CONFIG_ARCH_USE_TEXT_HEAP can be used.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
In smp when cpu0 calls up_cpu_resume to release the cpu1 lock, another locked cpu1 did not execute immediately,
and soon cpu0 called up_cpu_resume again, now cpu1 unable to respond to the interrupt at this time, resulting in a deadlock.
Our solution is to restore cpu1 execution from asynchronous to synchronous to ensure that cpu1 is restored.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Summary:
To reduce the count of FPU context switching will result at a
performance improve with system. it need to balance between
the using of FPU and counts of FPU trap
the PR submit a base method to see performance counts for
the FPU with NuttX procfs
Please read README.txt at chapter of FPU Support and Performance
for more information
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
minidump will backtrace failure when use C code to save user context,
because the stack push operation in C code can disrupt the stack information.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
minidump will backtrace failure when use C code to save user context,
because the stack push operation in C code can disrupt the stack information.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
1 Similar to Linux and zephyr, all implementations are in arm64_arch_timer.c
2 Arm64 tickless is turned off by default. If it needs to be turned on, you need to configure the switch CONFIG_SCHED_TICKLESS ON
3 The implementation strategy for tick/tickless is to use the timer inside the CPU and implement the timer driver based on the ARCH_TIMER framework.
4 We implemented tick_* Callback functions to adapt to the driven interface to avoid time format conversion overhead
5 In arm64_tick_cancel func，The remaining time that is not used, so this value can be ignored without reading the corresponding register to obtain the remaining cycles
6 Currently, tick/tickless can takes effect in SMP and non SMP mode, ostest can pass.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32L5_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L5_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L5_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32WB_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32WB_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32WB_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32L4_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L4_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L4_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
replace all GPIO_MODE_xxMHz with GPIO_MODE_2MHz provide GPIO_ADJUST_MODE
and add legacy pinmap
For the stm32F1 pinmaps should not have contained GPIO_MODE_50MHz settings
on all pins. Speed is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps that can have the GPIO_MODE_xxMHz set.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h, and use all the defconfigs with the legacy
pinmap and output the required changes that one needs to make to a board.h
file.
Eventually, CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.hf1
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32F7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32F7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32H7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32H7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32H7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
The text describes an issue related to the running task in code.
The running task is only used when calling the _assert function
to indicate the task that was running before an exception occurred.
However, the current code only updates the running task during
irq_dispatch, which is suitable for ARM-M architecture but not
for ARM-A or ARM-R architecture, because their context switches
are not done through irq handler. Therefore, if the following
process is followed, the value of the running task will be incorrect:
1. task1 is running, this_task()=task1
2. do_irq is executed, setting running task()=task1
3. task1 switches to task2
4. task2 is running and generates a data abort
5. In the data abort, the _assert function is called,
and the running task obtained is still task1, but
the actual task that generated the exception is task2.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
If this option is enabled, the working path of nuttx will be modified to the folder where the nuttx file is located.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
Over-drive can be forced to a given state by adding define to the
board.h configuration file:
#define STM32_VOS_OVERDRIVE 1 - force over-drive enabled,
#define STM32_VOS_OVERDRIVE 0 - force over-drive disabled,
#undef STM32_VOS_OVERDRIVE - autoselect over-drive by the default RCC logic
It seems that over-drive is not required for ULPI but it can be a workaround solution for boards with poor signal integration.
Higher core voltage means faster clock signal edges, which may be sufficient to synchronize the high-speed clock and data on poorly designed boards.
Over-drive can be forced to a given state by adding define to the
board.h configuration file:
#define STM32_VOS_OVERDRIVE 1 - force over-drive enabled,
#define STM32_VOS_OVERDRIVE 0 - force over-drive disabled,
#undef STM32_VOS_OVERDRIVE - autoselect over-drive by the default RCC logic
- Remove the temporary "saved" variable when temporarily changing MMU
mappings to access another process's memory. The fact that it has an
address environment is enough to make the choice
- Restore nxflat_addrenv_restore-macro. It was accidentally lost when
the address environment handling was re-factored.
The Inter-Processor Interrupt that pauses the other CPU generates
a level-1 interrupt which sets the PS.EXCM. This level-1 interrupt
is treated as an Exception and the bit PS.EXCM bit is automatically
reset on return from Exception. However, this is not the case here
because we are changing the execution to the signal trampoline.
Restoring the PS register with the PS.EXCM bit set would cause any
other exception to deviate execution to the DEC (double exception
vector), avoiding it to be treated correctly. According to the
xtensa ISA: "The process of taking an interrupt does not clear
the interrupt request. The process does set PS.EXCM to 1, which
disables level-1 interrupts in the interrupt handler. Typically,
the PS.EXCM is reset to 0 by the handler, after it has set up the
stack frame and masked the interrupt." Clean the saved PS.EXCM to
1) avoid an exception from being properly treated and 2) avoid
interrupts to be masked while delivering the signal.
In the previous implementation, PerformanceCounter would cause overflow
after running for a long time, This commit will separate the calculation
of the sec/ms part to avoid this issue, Reference:
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/clock.cc#L194-L217
Signed-off-by: chao an <anchao@xiaomi.com>
On a GICv2 implementation, setting GICC_CTLR.EOImode to 1 separates
the priority drop and interrupt deactivation operations.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
