There are a bunch of cases you might want some pins not exposed.
Eg.
* Reading say 8 bit data and outputting the top 5 bits, discarding the rest by not mapping those data pins to output pins
* Not using hsync/vsync because sync data is embedded within the data bits for more timing flexibility (eg. interlacing).
* Using the LCD module as a high speed parallel data output bus, with no need for sync/control pins.
Removing this validation makes these cases work.
Merges https://github.com/espressif/esp-idf/pull/13103
1. Fixed BLE 2M phy TX problem causing by phy_wifi_enable_set() on ESP32-C3 and ESP32-S3
2. Fixed BLE CCA bug on ESP32-C2
3. Fixed wifi boot bug at low temp on ESP32-C6
4. Fixed BLE and WIFI could not receive packets after entering light sleep for a long time on ESP32-C3, ESP32-S3, ESP32-C2 and ESP32-C6
For C6/H2/P4/C5, there is no SoC specific debug range. Instead the same
address range is part of CPU Subsystem range which contains debug mode
specific code and interrupt config registers (CLINT, PLIC etc.).
For now the PMP entry is provided with RWX permission for both machine
and user mode but we can save this entry and allow the access to only
machine mode for this range.
For P4/C5 case, this PMP entry can have RW permission as the debug mode
specific code is not present in this memory range.
Currently we silently ignore when the original component is not found
in a hope we can provide at least some meaningful hint. As it turned
out it's not true. Instead of providing misleading hint, just return
error. This adds several checks for situations, which should not happen,
but when they do it should be easier to identify the root cause of the
problem.
For example when hint module received malformed output with extra new
lines, e.g. caused by a bug in RunTool, it wrongly reported the original
component as source component.
This should also fix the tests on Windows.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently RunTool reads command's output with asyncio read, which
returns bytes. This is decoded into python's string and the output already
contains OS specific line endings, which on Windows is CRLF. Problem is
that the command output is saved by using python's text stream/file,
which replaces LF, native python's line ending, with OS specific line ending.
On Windows, and in this particular case, the CRLF from the command output is
translated into CRCRLF and saved in the commands output file. When this
file is read in again, e.g. for hint modules, the CRCRLF is replaced
with LFLF. Again the file is open as text file. Meaning a new emply line
is added.
Fix this by opening the output file with "newline=''", which prevents
this translation. We already have the OS specific line ending in the
command's output.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
