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.
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>
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>
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.
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>
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>
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>
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.
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>
Summary:
- Support arm64 pmu api, Currently only the cycle counter function is supported.
- Using ARM64 PMU hardware capability to implement perf interface, modify all
perf interface related code.
- Support for pmu init under smp.
Signed-off-by: wangming9 <wangming9@xiaomi.com>
Otherwise, a request will never be transferred and there is no
information to the user that something is wrong.
For example, when using default values for TXFIFO in HS mode,
USBMSC will never work because the maximum request len is 512B
which is lower than the default TXFIFO size for IN EP.
Current Toolchain.defs set the compile flags directly, it's OK for
target specified gcc toolchain.
But some LLVM based toolchains (Rust/Zig etc) use single toolchain to handle all supported paltform.
In this patch, arch level Toolchain.defs export standard LLVM style arch flags, and let <Lang>.defs to map them into internal style,
This will simplify the intergration of non-c language.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
arm-none-eabi-gcc 12.2.0 gives the following warnings:
error: 'primask' is used uninitialized
error: 'primask' may be used uninitialized
We use Werror and the file is indirectly included in different
places. I suggest telling the compiler to ignore these warnings
since primask is initialized on the first assembly line.
This is the only problem I encountered so far when upgrading the compiler.
SPI transfers are dynamically determined to use DMA or not.
The flag to judge is removed in a previous simple refactoring commit.
Revert the logic and fix an issue that SPI transfer fails.
Choose a divider value that matches the description provided within
the same header file.
Include stddef.h to fix compiler errors because NULL is not defined.
Make logs print protocol, vid and pid consistently, (decimal hex hex).
This commit adds support for dead time delay to SAMv7 PWM driver. The
dead time can be used to delay an active PWM output at the begining
of the period. This can be used for H bridge control for example.
The values are to be set from the application level. It is required
to allow config option PWM_DEADTIME in order to support dead time delay.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Hardware flow control for serial requires the usage of DMAC channels
which is not yet supported for SAMv7 MCU. However the same config option
CONFIG_SERIAL_IFLOWCONTROL is also used for USB CDC/ACM flow control which
works well. Therefore the warning message should be raised only if
flow control is configured for USART driver and not for USB CDC/ACM.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
A list of breaking changes:
- SoftDevice libraries was renamed and libaries are now cmpatible with all platfroms with a given faimily.
- The random number generator was decoupled from the controller and must now be provided by the user.
We use arc4random_buf NuttX API for this.
- sdc_support_ API must be called before sdc_cfg_set()
- update public API terms to Bluetooth Core Specification v5.3 (mainly change slave/master to central/peripheral)
NuttX NRF52 configuration options properly updated.
- BLE features are supported only if the proper BLE role is selected
- sdc_hci_evt_get() and sdc_hci_data_get() have been replaced by sdc_hci_get()
This commit adds configurable fault protection to SAMv7 PWM driver.
The fault input can be used from peripherals as ADC or GPIO inputs.
Inputs from GPIO have configurable polarity (high or low). The PWM output
is automatically set to zero if fault input is active and restored
if fault input is not actived.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
- Add retry timeout to prevent inifinite loop
- Change the register operation of power control
- Add exclusive control by semaphore into some functions
- Add short delay until power control is reflected
This commit enhances ADC and PWM drivers with option to trigger ADC
conversion with events generated by PWM comparison units.
The generation of PWM events is handled by comparison units set up from
Kconfig option SAMV7_PWMx_TRIGn. ADC triggering from PWM can be selected
by AFECn_PWMTRIG option.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
SAMv7 PWM driver supports complementary PWM output if both pins (H and L)
are defined and configured. This commit adds a configuration option to
configure the complementary L pin.
The pin definition has to be provided by board level support.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Summary:
- I noticed that there are two kinds of descriptors for imxrt_enet.c
- The first one is the legacy descriptor and its size is 8bytes.
- The second one is the enhanced descriptor and its size is 32bytes.
- In both cases, we can not use a descriptor chain like stm32.
- Considering cache line alignment, the second one is perfect because
one descriptor fits the Cortex-M7 cache line which would fix networking
stability issues in d-cache write-back mode.
Impact:
- imxrt ethernet in d-cache write-back mode
Testing:
- Tested with ixmrt1060-evk:netnsh_dcache_wb (will be added later)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that CONFIG_IMXRT_ENET_ENHANCEDBD is not correctly
used though it is defined in Kconfig.
- This commit fixes this issue.
Impact:
- None
Testing:
- Tested with imxrt1060-evk:netnsh_dcache_wb (will be added later)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This reverts commit 62c15c03d3.
Fix warning: the choice symbol STM32_FLASH_CONFIG_G (defined at arch/arm/src/stm32/Kconfig:1275) is selected by the following symbols, but select/imply has no effect on choice symbols
- ARCH_CHIP_STM32F412ZG (defined at arch/arm/src/stm32/Kconfig:1014)
Generic drivers shoud not use architecture related config options like
CONFIG_SAMV7_PWM. This commit adds PWM pin overwrite under generic
configuration option CONFIG_PWM_OVERWRITE.
Now the overwrite can be used on other architectures as well or can be
completely disabled for SAMv7.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Commit d07792a caused a build error in sam_mcan.c file. This commit fixes
the build. The file now succesfully compiles and CAN works.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
When I checked how this register was set I discovered that 128 was not
accepted by the H7 but 64 was ok. Looking at the STM32Cube's HAL it
seems to be only 64 words long, however, the reference manual claims
otherwise.
I have opened a discussion on the ST community forum
https://community.st.com/s/question/0D73W000001nzqFSAQ
but unfortunately not received an answer yet.
In the meantime, I think, we should update this to what I found to be
working though.
Signed-off-by: Julian Oes <julian@oes.ch>
Current implementation supports the trigger generation only from timer
capture on period value. This is sufficient for PWM synchronization but
may not be enough for other purposes as ADC triggering for example.
This change adds an option to generate the trigger based on a duty
cycle value.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
The function call dac_txdone(&g_dac1dev) was not contained in ifdef
section. This was cousing compilation error if only DAC1 was configured
as the structure g_dac1dev is defined only if DAC0 is used.
This commit fixes the error and ensures the function is called only if
corresponding DAC is configured.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
In the lower half UART driver for Tiva architecture (TM4C12x), adding
the TIOCxBRK ioctl calls, which allow an application to transmit a BSD
compatible line BREAK. TIOCSBRK starts the BREAK and TIOCCBRK ends it.
This architecture supports BSD-style BREAK in hardware. We write to
the BRK bit (bit 0) of the UART Line Control register (UARTLCRH) to
start the BREAK, which begins after the UART finishes shifting out the
current character in progress, if any, including its stop bit(s), and
continues indefinitely until we write to the BRK bit again to stop the
BREAK.
* arch/arm/src/tiva/Kconfig
(config TIVA_UART_BREAKS): New. Appears as CONFIG_TIVA_UART_BREAKS
in code.
* arch/arm/src/tiva/common/tiva_serial.c
(struct up_dev_s): Add new field 'brk' to indicate line break in
progress when built with CONFIG_TIVA_UART_BREAKS.
(up_ioctl): Add cases for TIOCSBRK to turn BSD-compatible break on
unconditionally and TIOCCBRK to turn break off unconditionally.
(up_txint): Block enabling TX interrupt if line break in progress.
This is similar to the STM32F7 implementation.
* arch/arm/src/tiva/common/tiva_serial.c:
(up_ioctl): PR #8406 (commit 1edec0aaa1) added support for
configuring the serial port's CTS/RTS flow control at runtime using
termios when built with CONFIG_SERIAL_TERMIOS and either or both of
CONFIG_SERIAL_OFLOWCONTROL and CONFIG_SERIAL_IFLOWCONTROL. However,
a runtime sanity check left over from before prevented this from
working: When processing ioctl TCSETS, we would return -EINVAL if
one or both of CCTS_OFLOW and CRTS_IFLOW were requested, which was
not deserved if the requested features were in fact supported.
Fixing the sanity check so it depends on features actually
configured.
The function is not relevant any longer, remove it. Also remove
save_addrenv_t, the parameter taken by up_addrenv_restore.
Implement addrenv_select() / addrenv_restore() to handle the temporary
instantiation of address environments, e.g. when a process is being
created.
Detach the address environment handling from the group structure to the
tcb. This is preparation to fix rare cases where the system (MMU) is left
without a valid page directory, e.g. when a process exits.
ld: warning: boards/arm/rp2040/raspberrypi-pico-w/scripts/raspberrypi-pico-flash.ld contains output sections; did you forget -T?
Signed-off-by: chao an <anchao@xiaomi.com>
common/arm_backtrace_unwind.c: In function 'up_backtrace':
common/arm_backtrace_unwind.c:626:27:
warning: assignment to 'long unsigned int' from 'uint8_t (*)[]'\
{aka 'unsigned char (*)[]'} makes integer from pointer without a cast [-Wint-conversion]
626 | frame.stack_top = &g_intstacktop;
|
NuttX kernel should not use the syscall functions, especially after
enabling CONFIG_SCHED_INSTRUMENTATION_SYSCALL, all system functions
will be traced to backend, which will impact system performance.
Signed-off-by: chao an <anchao@xiaomi.com>
This is a follow-up to PR #6548, which added UART CTS/RTS support for
Tiva (TI TM4C12x) microcontrollers. This follow-up makes it possible,
when termios support is enabled with CONFIG_SERIAL_TERMIOS and CTS/RTS
support is enabled with CONFIG_SERIAL_OFLOWCONTROL and/or
CONFIG_SERIAL_IFLOWCONTROL, to query whether CTS/RTS are on/off at
runtime by utilizing ioctl TCGETS and to turn CTS/RTS on/off at runtime
by utilizing ioctl TCSETS.
* arch/arm/src/tiva/common/tiva_serial.c
(up_set_format): Because this function is called from ioctl TCSETS to
modify UART settings, and that IOCTL now respects CCTS_OFLOW and
CRTS_IFLOW, move setting/clearing of Tiva UART's CTL register's RTSEN
and CTSEN bits here...
(up_setup): ...from here.
(up_ioctl): For TCGETS, populate CCTS_OFLOW and CRTS_IFLOW bits as
appropriate. For TCSETS, populate priv's oflow and iflow from
supplied CCTS_OFLOW and CRTS_IFLOW bits.
Thanks to Petro Karashchenko for review and suggested fixes.
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
The lower-half serial driver for Tiva (TI TM4C12x) microcontrollers supports
termios, but Kconfig never enabled this support because we were missing the
ARCH_HAVE_SERIAL_TERMIOS configs. This is now enabled, allowing termios support
to be enabled with CONFIG_SERIAL_TERMIOS.
* arch/arm/src/tiva/Kconfig
(config TIVA_UART0 thru TIVA_UART7): Select ARCH_HAVE_SERIAL_TERMIOS.
When sending small number of bytes with larger CONFIG_USEC_PER_TICK
this function should return at least 1. Solve this by rounding
up the result.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This is preparation for moving address environments out of the group
structure into the tcb.
Why move ? Because the group is destroyed very early in the exit phase,
but the MMU mappings are needed until the context switch to the next
process is complete. Otherwise the MMU will lose its mappings and the
system will crash.
There were two issues with signal handling:
- With a kernel stack the "info" parameter was passed from kernel memory.
This is fixed by making a stack frame to the user stack and copying it
there.
- If the signal handler uses a system call, the kernel stack was completely
and unconditionally destroyed, resulting in a crash in the user application
There is also no need to check ustkptr, it is always NULL. Why ? Because
signal delivery is deferred when a system call is being executed.
This is unnecessary, the address environment is getting wiped anyway,
there is no need to remove the L1 references because they will get
wiped when the page directory is changed
When invalidate address is not aligned with cache line,
must align address and flush the cache line.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
The dual core STM32H747 / STM32H757 there is an additional option to
select SMPS rather than LDO as the power selection.
This commit adds this option to the STM32H747 config and the
stm32h7x7xx source.
Signed-off-by: Julian Oes <julian@oes.ch>
struct stm32_i2c_inst_s instance is allocated on every call to
stm32_i2cbus_initialize, and that instance is supposed to be deleted on every
call to stm32_i2cbus_uninitialize.
The "refs" counter just keeps track on when the last one is deleted, and
everything is unregisterd/disabled.
This reverts commit 8098c80338.
The dependency should be vice versa; the MM_SHM should depend on the
existence of the virtual memory range allocator.
Create a new CONFIG flag CONFIG_ARCH_VMA_MAPPING, which will define that
there is a virtual memory range allocator. Make MM_SHM select that flag
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
since mmap may exist in block_operations, but truncate may not,
moving mmap beforee truncate could make three struct more compatible
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
- Add mmap into file_operations and remove it from ioctl definitions.
- Add mm_map structure definitions to support future unmapping
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- Add truncate into file_operations
- Move truncate to be common for mountpt_operations and file_operations
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Flexcom working, DMA not looked at for SAMA5D2
Update sam_flexcom_spi.c
Update sam_flexcom_spi.h
Update sam_config.h
Update hardware/sam_flexcom_spi.h
pkarashchenko reviews
SAMA5 serial and flexcom serial corrections
The register definition comes from CMSIS
https: //github.com/ARM-software/CMSIS_5
commit id:10bf763a82318c0c852ff9ecc2d5cd8cebe7d761
file: Core/Include/pmu_armv8.h
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Registers S0-S15 (D0-D7, Q0-Q3) do not need to be preserved. They can be used for passing
arguments or returning results in standard procedure-call variants.
Registers D16-D31 (Q8-Q15), do not need to be preserved.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
l3/l4 stack will decouple the reference of d_buf gradually, Only legacy
devices still retain d_buf support, new net devices will use d_iob
Signed-off-by: chao an <anchao@xiaomi.com>
The following changes omit the arm version:
| commit d321080351
| Author: chao an <anchao@xiaomi.com>
| Date: Fri Dec 2 02:52:18 2022 +0800
|
| arm/cortex-[a|r]: generating assemble code in ARM states by default
|
| Signed-off-by: chao an <anchao@xiaomi.com>
Signed-off-by: chao an <anchao@xiaomi.com>
Fix build break on thumb2 mode:
opus/celt/arm/celt_pitch_xcorr_arm-gnu.S: Assembler messages:
opus/celt/arm/celt_pitch_xcorr_arm-gnu.S:146: Error: thumb conditional instruction should be in IT block -- `movle pc,lr'
Reference:
https://developer.arm.com/documentation/100067/0612/armclang-Command-line-Options/-mimplicit-it
In A32 code, the integrated assembler accepts all conditional instructions
without giving an error or warning. In T32 code, the integrated assembler
outputs an implicit IT block when there is a conditional instruction
without an enclosing IT block. The integrated assembler does not give an
error or warning about this.
Signed-off-by: chao an <anchao@xiaomi.com>
The option '-mthumb' is only valid for C source files and it is not passed to the assembler.
If 'thumb' is not considered in some assembly projects, the system will generate
'undefined instructions' when running incompatible instruction:
arm_undefinedinsn: Undefined instruction at 0x380cfc98
This assembly file should be compiled with .thumb but it doesn't:
380cfc90 <hobot_i8_i32_gemm_nn_m4_n8_neon>:
380cfc90: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
380cfc94: ed2d8b10 vpush {d8-d15}
380cfc98: e59d4064 ldr r4, [sp, #100] ; 0x64 <-- Undefined instruction
380cfc9c: e59d5068 ldr r5, [sp, #104] ; 0x68
380cfca0: e59d606c ldr r6, [sp, #108] ; 0x6c
380cfca4: e59d7070 ldr r7, [sp, #112] ; 0x70
380cfca8: e1a08120 lsr r8, r0, #2
380cfcac: e1a091a1 lsr r9, r1, #3
380cfcb0: e1a0a122 lsr sl, r2, #2
After enable thumb:
.syntax unified
.thumb
or
-Wa,-mthumb
.Lhobot_i8_i32_gemm_nn_m4_n8_neon:
38001100: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
38001104: ed2d 8b10 vpush {d8-d15}
38001108: 9c19 ldr r4, [sp, #100] ; 0x64
3800110a: 9d1a ldr r5, [sp, #104] ; 0x68
3800110c: 9e1b ldr r6, [sp, #108] ; 0x6c
3800110e: 9f1c ldr r7, [sp, #112] ; 0x70
38001110: ea4f 0890 mov.w r8, r0, lsr #2
38001114: ea4f 09d1 mov.w r9, r1, lsr #3
38001118: ea4f 0a92 mov.w sl, r2, lsr #2
This commit will enable the thumb option of the assembly file by default,
so that when compiling the assembly file, the machine code and the system will be in a consistent state.
----------------------------------------------------------------
https://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/ARM-Options.html
GCC Manual:
-mthumb
Generate code for the Thumb instruction set. The default is to use the 32-bit ARM
instruction set. This option automatically enables either 16-bit Thumb-1 or mixed 16/32-bit
Thumb-2 instructions based on the -mcpu=name and -march=name options.
** This option is not passed to the assembler. **
** If you want to force assembler files to be interpreted as Thumb code,
either add a `.thumb' directive to the source or pass the -mthumb option
directly to the assembler by prefixing it with -Wa. **
Signed-off-by: chao an <anchao@xiaomi.com>
arch/arm/src/sama5/Kconfig:819:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/arm/src/sama5/Kconfig:819: choice <choice> contains symbol SAMA5_FLEXCOM0_USART
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/arm/src/sama5/Kconfig:824: symbol SAMA5_FLEXCOM0_USART is part of choice SAMA5_FLEXCOM0_USART
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/arm/src/sama5/Kconfig:824: symbol SAMA5_FLEXCOM0_USART is part of choice <choice>
Signed-off-by: chao an <anchao@xiaomi.com>
SAMA5Dx ADC and TSD fixes
Ensures ADC and TSD work together. TSD now works on SAMA5D2 and should be OK, still, for other SAMA5D familiy members
Fix CI error
checkpatch error
Update arch/arm/src/sama5/sam_tsd.h
Squash commits to arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Update arch/arm/src/sama5/hardware/sam_adc.h
Squash commits to arch/arm/src/sama5/sam_tsd.c
Update arch/arm/src/sama5/sam_tsd.c
Update arch/arm/src/sama5/sam_tsd.c
Update arch/arm/src/sama5/sam_tsd.c
Update sam_tsd.c
Fixes after feedback from PR and additional testing
Update sam_tc.c
checkpatch.sh error was missed when fixing someone else's error...
feedback corrections missed
Co-Authored-By: Xiang Xiao <xiaoxiang781216@gmail.com>
Co-Authored-By: Petro Karashchenko <petro.karashchenko@gmail.com>
squashed everything after 248072e02C
