9582cbe5b8
1. The 2nd bootloader always call `rom_spiflash_unlock()`, but never help to clear the WEL bit when exit. This may cause system unstability. This commit helps to clear WEL when flash configuration is done. **RISK:** When the app starts, it didn't have to clear the WEL before it actually write/erase. But now the very first write/erase operation should be done after a WEL clear. Though the risk is little (all the following write/erase also need to clear the WEL), we still have to test this carefully, especially for those functions used by the OTA. 2. The `rom_spiflash_unlock()` function in the patch of ESP32 may (1) trigger the QPI, (2) clear the QE or (3) fail to unlock the ISSI chips. Status register bitmap of ISSI chip and GD chip: | SR | ISSI | GD25LQ32C | | -- | ---- | --------- | | 0 | WIP | WIP | | 1 | WEL | WEL | | 2 | BP0 | BP0 | | 3 | BP1 | BP1 | | 4 | BP2 | BP2 | | 5 | BP3 | BP3 | | 6 | QE | BP4 | | 7 | SRWD | SRP0 | | 8 | | SRP1 | | 9 | | QE | | 10 | | SUS2 | | 11 | | LB1 | | 12 | | LB2 | | 13 | | LB3 | | 14 | | CMP | | 15 | | SUS1 | QE bit of other chips are at the bit 9 of the status register (i.e. bit 1 of SR2), which should be read by RDSR2 command. However, the RDSR2 (35H, Read Status 2) command for chip of other vendors happens to be the QIOEN (Enter QPI mode) command of ISSI chips. When the `rom_spiflash_unlock()` function trys to read SR2, it may trigger the QPI of ISSI chips. Moreover, when `rom_spiflash_unlock()` try to clear the BP4 bit in the status register, QE (bit 6) of ISSI chip may be cleared by accident. Or if the ISSI chip doesn't accept WRSR command with argument of two bytes (since it only have status register of one byte), it may fail to clear the other protect bits (BP0~BP3) as expected. This commit makes the `rom_spiflash_unlock()` check whether the vendor is issi. if so, `rom_spiflash_unlock()` only send RDSR to read the status register, send WRSR with only 1 byte argument, and also avoid clearing the QE bit (bit 6). 3. `rom_spiflash_unlock()` always send WRSR command to clear protection bits even when there is no protection bit active. And the execution of clearing status registers, which takes about 700us, will also happen even when there's no bits cleared. This commit skips the clearing of status register if there is no protection bits active. Also move the execute_flash_command to be a bootloader API; move implementation of spi_flash_wrap_set to the bootloader |
||
|---|---|---|
| .. | ||
| include | ||
| soc | ||
| src | ||
| test | ||
| CMakeLists.txt | ||
| component.mk | ||
| linker.lf | ||
| README.md | ||
soc
The soc component provides abstraction, hardware description and implementation for targets suppported by ESP-IDF. This is reflected in
the component's subdirectories:
soc/include- abstractionsoc/soc- descriptionsoc/src- implementation
soc/include
soc/include contains header files which provide a hardware-agnostic interface to the SoC. The interface consists of
function declarations and abstracted types that other, higher level components can make use of in order to have code portable to
all targets ESP-IDF supports.
The hal subdirectory contains an abstraction layer for interacting with/driving the hardware found in the SoC such as the peripherals
and 'core' hardware such as the CPU, MPU, caches, etc. It contains xxx_hal.h files for the function declarations and xxx_types.h for the abstracted types.
The abstraction design is actually two levels -- oftentimes xxx_hal.h includes a lower-level header from a
xxx_ll.h, which resides in the implementation, soc/src subdirectory. More on this abstraction design in the hal subdirectory's README.
The soc subdirectory contains other useful interface for SoC-level operations or concepts, such as the memory layout, spinlocks, etc.
soc/soc
The soc/soc subdirectory contains description of the underlying hardware:
- `xxx_reg.h` - defines registers related to the hardware
- `xxx_struct.h` - hardware description in C `struct`
- `xxx_channel.h` - definitions for hardware with multiple channels
- `xxx_caps.h` - features/capabilities of the hardware
- `xxx_pins.h` - pin definitions
- `xxx_periph.h/*.c` - includes all headers related to a peripheral; declaration and definition of IO mapping for that hardware
Since the hardware description is target-specific, there are subdirectories for each target containing copies of the files above. Furthermore, the files in this directory should be standalone, i.e. should not include files from outside directories.
soc/src
Provides the implementation of the hardware-agnostic interface in the abstraction. Target-specific subdirectories exist for wildly different implementations between targets; while code that are common/very similar might be placed in the top-level of soc/src, using some amount of conditional preprocessors. It is up to the developers' discretion on which strategy to use. Code usually reside in source files with same names to header files whose interfaces they implement, ex. xxx_hal.c for xxx_hal.h.
As mentioned previously, the lower-level abstraction header xxx_ll.h resides in this directory, since they contain hardware-specific details.
However, what these can do is provide some abstraction among implementations, so that more code can be moved to the common, non-target-specific subdirectories.
This can also contain target-specific extensions to the HAL headers. These target-specific HAL headers have the same name and include the abstraction layer HAL header via include_next. These extensions might add more function declarations or override some things using macro magic.