Considering kernel code, it's reasonable to use `PANIC()` instead
of `assert(0)` to handle with situations that require abort. Unlike
`assert`, `PANIC()` doesn't dependent on `NDEBUG`.
ESP32-S3 has only one 2.4 GHz ISM band RF module, which is shared
by Bluetooth and Wi-Fi, so Bluetooth can’t receive or transmit data
while Wi-Fi is receiving or transmitting data and vice versa.
Under such circumstances, ESP32-S3 uses the time-division
multiplexing method to receive and transmit packets.
The low-level Wi-Fi driver registers two peripheral interrupts to
the same CPU interrupt. Although the registered ISR is the same for
both peripherals interrupt, it's needed to call `up_enable_irq` to
ensure that the interrupt matrix is being set accordingly.
Please note that the current implementation of the ESP32-S3's IRQ
driver - although allow us to set a callback for each IRQ, which
represents the peripherals interrupt - doesn't allow us to call
both callbacks when these IRQs refers to a same CPU interrupt.
`g_cpu0_intmap` (or `g_cpu1_intmap`) associates each CPU interrupt
to a single IRQ/peripheral and, then, when a CPU interrupt is
triggered, only the last registered IRQ's callback will be called.
This isn't a problem here because 1) the registered callback is the
same for both IRQ's (in fact, it considers the CPU interrupt) and
2) we know in advance which peripheral interrupts will be attached
to which CPU interrupt and, then, we can set them directly.
This prevents us from getting stuck while polling the different
network structures in `devif_poll_connections`. This is useful for
Wi-Fi/Bluetooth coexistence, specifically.
- Fix macro values from `arch/xtensa/include/esp32s3/irq.h`
- Remove references to unexisting edge-triggered CPU interrupts
- Add `esp32s3_getirq` to get IRQ based on core and the `cpuint`
RTC subsystem controls not only the RTC itself but functions that
use RTC-enabled features like Bluetooth and Wi-Fi. Initialization
must be performed during the system start-up.
Adding the CONFIG_ARCH_PERF_EVENTS configuration to enable
hardware performance counting，solve the problem that some platform
hardware counting support is not perfect, you can choose to use
software interface.
This is configured using CONFIG_ARCH_PERF_EVENTS, so weak_functions
are removed to prevent confusion
To use hardware performance counting, must:
1. Configure CONFIG_ARCH_PERF_EVENTS, default selection
2. Call up_perf_init for initialization
Signed-off-by: wangming9 <wangming9@xiaomi.com>
The naming of the clang configuration file has changed after version 14
This commit will enable the compatibility with clang-14/15/16/17
Signed-off-by: chao an <anchao@xiaomi.com>
Fix buffer overflow issue from PR #10128, since the sizeof
xcpt_reg_t is different on 32/64 bit platform.
Signed-off-by: chenxiaoyi <chenxiaoyi@xiaomi.com>
Summary
Qemu virt board can choice CPU core with boot parameter
and we need to add Konfig option for choice
the change do this
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Sumary
add hostfs support for arm64, it's a copy
from arm32.
Note:
it's not support for opendir and readdir, command
like ls will not work.
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
add set/get_power operation for sim_framebuffer to avoid assert
in fb_ioctl(cmd= FBIOSET_POWER/FBIOGET_POWER)
Signed-off-by: wangbowen6 <wangbowen6@xiaomi.com>
In armv8m the FPSCR[18:16] LTPSIZE field must be set to 0b100 for
"Tail predication not applied" as it's reset value.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
1. virtio devics/drivers match and probe/remote mechanism;
2. virtio mmio transport layer based on OpenAmp (Compatible with both
virtio mmio version 1 and 2);
3. virtio-serial driver based on new virtio framework;
4. virtio-rng driver based on new virtio framework;
5. virtio-net driver based on new virtio framework
(IOB Offload implementation);
6. virtio-blk driver based on new virtio framework;
7. Remove the old virtio mmio framework, the old framework only
support mmio transport layer, and the new framwork support
more transport layer and this commit has implemented all the
old virtio drivers;
8. Refresh the the qemu-arm64 and qemu-riscv virtio related
configs, and update its README.txt;
New virtio-net driver has better performance
Compared with previous virtio-mmio-net:
| | master/-c | master/-s | this/-c | this/-s |
| :--------------------: | :-------: | :-------: | :-----: | :-----: |
| qemu-armv8a:netnsh | 539Mbps | 524Mbps | 906Mbps | 715Mbps |
| qemu-armv8a:netnsh_smp | 401Mbps | 437Mbps | 583Mbps | 505Mbps |
| rv-virt:netnsh | 487Mbps | 512Mbps | 760Mbps | 634Mbps |
| rv-virt:netnsh_smp | 387Mbps | 455Mbps | 447Mbps | 502Mbps |
| rv-virt:netnsh64 | 602Mbps | 595Mbps | 881Mbps | 769Mbps |
| rv-virt:netnsh64_smp | 414Mbps | 515Mbps | 491Mbps | 525Mbps |
| rv-virt:knetnsh64 | 515Mbps | 457Mbps | 606Mbps | 540Mbps |
| rv-virt:knetnsh64_smp | 308Mbps | 389Mbps | 415Mbps | 474Mbps |
Note: Both CONFIG_IOB_NBUFFERS=64, using iperf command, all in Mbits/sec
Tested in QEMU 7.2.2
Signed-off-by: wangbowen6 <wangbowen6@xiaomi.com>
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
