- 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 is a workaround commit to temporarily reduce the flash usage of
esp32c6 to avoid ci failure, Since I am not familiar with esptool,
and this issue cannot be reproduced in the local environment,
so I temporarily turn off related optimizations to save flash size.
esptool error log:
-----------------------------------------
| MKIMAGE: ESP32-C6 binary
| esptool.py --chip esp32c6 elf2image --flash_mode dio --flash_size "4MB" -o nuttx.bin nuttx
| esptool.py v4.5.1
| Creating esp32c6 image...
| Merged 1 ELF section
|
| A fatal error occurred: Segment loaded at 0x42010c08 lands in same 64KB flash mapping as segment loaded at 0x42010020. Can't generate binary. Suggest changing linker script or ELF to merge sections.
| make: *** [tools/Unix.mk:527: nuttx] Error 2
| make: Target 'all' not remade because of errors.
-----------------------------------------
Signed-off-by: chao an <anchao@xiaomi.com>
The length of the IROM and DROM segments should be related to the extent
of the address space, and not be limited to the capacity of the External
Flash device.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
* Remove the 'COEXISTENCE' suffix from Wi-Fi's STA + SoftAP mode.
Coexistence usually refers to Wi-Fi + BLE, instead of Wi-Fi's
operation mode;
* Remove commented debug code;
* Remove outdate function descriptions;
Initially supporting ESP32-C3 chip, to be followed by other RISC-V-based
chips from Espressif.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
There is currently a big problem in the address environment handling which
is that the address environment is released too soon when the process is
exiting. The current MMU mappings will always be the exiting process's, which means
the system needs them AT LEAST until the next context switch happens. If
the next thread is a kernel thread, the address environment is needed for
longer.
Kernel threads "lend" the address environment of the previous user process.
This is beneficial in two ways:
- The kernel processes do not need an allocated address environment
- When a context switch happens from user -> kernel or kernel -> kernel,
the TLB does not need to be flushed. This must be done only when
changing to a different user address environment.
Another issue is when a new process is created; the address environment
of the new process must be temporarily instantiated by up_addrenv_select().
However, the system scheduler does not know that the process has a different
address environment to its own and when / if a context restore happens, the
wrong MMU page directory is restored and the process will either crash or
do something horribly wrong.
The following changes are needed to fix the issues:
- Add mm_curr which is the current address environment of the process
- Add a reference counter to safeguard the address environment
- Whenever an address environment is mapped to MMU, its reference counter
is incremented
- Whenever and address environment is unmapped from MMU, its reference
counter is decremented, and tested. If no more references -> drop the
address environment and release the memory as well
- To limit the context switch delay, the address environment is freed in
a separate low priority clean-up thread (LPWORK)
- When a process temporarily instantiates another process's address
environment, the scheduler will now know of this and will restore the
correct mappings to MMU
Why is this not causing more noticeable issues ? The problem only happens
under the aforementioned special conditions, and if a context switch or
IRQ occurs during this time.
PWM driver for multiple peripherals supplied in gateware.
Only single channel frequency and duty cycle control is implemented. Pulse counting and multichannel features are not currently feasible.
Additions also include a new board configuration for arty-a7 which enables the PWM driver and example application.
MCUboot support is no longer behind EXPERIMENTAL for the following
chips:
- ESP32
- ESP32-S2
- ESP32-S3
- ESP32-C3
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
