From b198c6351219b3ca23aa45235e80085b14cac161 Mon Sep 17 00:00:00 2001 From: Abdelatif Guettouche Date: Tue, 6 Apr 2021 23:32:51 +0200 Subject: [PATCH] boards/xtensa/esp32: Update some old information in README.txt files. Signed-off-by: Abdelatif Guettouche --- boards/xtensa/esp32/esp32-devkitc/README.txt | 20 ++++--------------- .../esp32/esp32-ethernet-kit/README.txt | 4 ---- .../xtensa/esp32/esp32-wrover-kit/README.txt | 1 - 3 files changed, 4 insertions(+), 21 deletions(-) diff --git a/boards/xtensa/esp32/esp32-devkitc/README.txt b/boards/xtensa/esp32/esp32-devkitc/README.txt index 82709c3c56..003de60ee4 100644 --- a/boards/xtensa/esp32/esp32-devkitc/README.txt +++ b/boards/xtensa/esp32/esp32-devkitc/README.txt @@ -619,13 +619,6 @@ OpenOCD for the ESP32 will be written. ROM bootloader expects to find an application (or second stage bootloader) image at offset 0x1000, so we are writing the binary there. - Clocking - -------- - Right now, the NuttX port depends on the bootloader to initialize hardware, - including basic (slow) clocking. If I had the clock configuration logic, - would I be able to run directly out of IRAM without a bootloader? That - might be a simpler bring-up. - Sample OpenOCD Debug Steps -------------------------- I did the initial bring-up using the IRAM configuration and OpenOCD. Here @@ -886,12 +879,7 @@ A new image "esp32_qemu_image.bin" will be created. It can be run as: Things to Do ============ - 1. There is no clock initialization logic in place. This depends on logic in - Espressif libraries. The board comes up using that basic 40 MHz crystal - for clocking. Getting to 80 MHz will require clocking initialization in - esp32_clockconfig.c. - - 2. I did not implement the lazy co-processor save logic supported by Xtensa. + 1. I did not implement the lazy co-processor save logic supported by Xtensa. That logic works like this: a. CPENABLE is set to zero on each context switch, disabling all co- @@ -905,14 +893,14 @@ Things to Do be saved and restored even if the co-processor was never used, and (2) tasks must explicitly enable and disable co-processors. - 3. Currently the Xtensa port copies register state save information from + 2. Currently the Xtensa port copies register state save information from the stack into the TCB. A more efficient alternative would be to just save a pointer to a register state save area in the TCB. This would add some complexity to signal handling and also also the up_initialstate(). But the performance improvement might be worth the effort. - 4. See SMP-related issues above + 3. See SMP-related issues above - 5. See OpenOCD for the ESP32 above + 4. See OpenOCD for the ESP32 above diff --git a/boards/xtensa/esp32/esp32-ethernet-kit/README.txt b/boards/xtensa/esp32/esp32-ethernet-kit/README.txt index 448b839e67..0a1a6031d5 100644 --- a/boards/xtensa/esp32/esp32-ethernet-kit/README.txt +++ b/boards/xtensa/esp32/esp32-ethernet-kit/README.txt @@ -63,10 +63,6 @@ Ethernet ESP32 GPIO PHY Chip GPIO IO5 <--> Reset_N -Espressif has an official Ethernet development board: - - https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html - Using QEMU: ========== diff --git a/boards/xtensa/esp32/esp32-wrover-kit/README.txt b/boards/xtensa/esp32/esp32-wrover-kit/README.txt index a61b9839b4..1f235d1b5b 100644 --- a/boards/xtensa/esp32/esp32-wrover-kit/README.txt +++ b/boards/xtensa/esp32/esp32-wrover-kit/README.txt @@ -99,4 +99,3 @@ External devices: ------ When using BMP180 (enabling CONFIG_SENSORS_BMP180), it's expected this device is wired to I2C0 bus. - The current bring-up routines doesn't allow BMP180 device to be used in I2C1 bus. \ No newline at end of file