espressif / esp-thread-br

Espressif Thread Border Router SDK
Apache License 2.0
105 stars 23 forks source link

Documentation seems incomplete/RCP is missing required capabilities (TZ-1143) #96

Open elgerg opened 2 weeks ago

elgerg commented 2 weeks ago

Checklist

How often does this bug occurs?

always

Expected behavior

TBR to start and allow me to create a thread network

Actual behavior (suspected bug)

Reboot loop.

The reason I think the docs might be wrong is because here:

2.1.4. Build and Run the Thread Border Router Build and Flash the example to the host SoC.

idf.py -p ${PORT_TO_BR} flash monitor

There is no build step, so I added build before flash (maybe that was my issue?).

The other part that makes me think it might be incomplete is how does the built H2 binary get into the TBR firmware? It seems to be built in a different project then not referenced, I suspect that is what is causing my boot loop as the RCP hasnt had it's firmware updated.

Other things to mention is that the menuconfig stuff seems a little lacking in that you need to specify 12 IPv6 addresses per interface and the default is 8 and if you are using the Ethernet daughter board you must set auto connect on.

I think that there was one other issue but I cant remember what it was.

It would be useful if someone ran through the complete build steps (mine was done on a Raspberry Pi 5 if that matters?).

Thanks in advance!

Error logs or terminal output

Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x9 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375a75
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2810,len:0x178c
load:0x403c8700,len:0x4
load:0x403c8704,len:0xc10
load:0x403cb700,len:0x2dc0
entry 0x403c8904
I (26) boot: ESP-IDF v5.3.1-dirty 2nd stage bootloader
I (26) boot: compile time Sep 14 2024 12:56:36
I (26) boot: Multicore bootloader
I (27) boot: chip revision: v0.2
I (27) boot.esp32s3: Boot SPI Speed : 80MHz
I (27) boot.esp32s3: SPI Mode       : DIO
I (27) boot.esp32s3: SPI Flash Size : 4MB
I (27) boot: Enabling RNG early entropy source...
I (28) boot: Partition Table:
I (28) boot: ## Label            Usage          Type ST Offset   Length
I (28) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (29) boot:  1 otadata          OTA data         01 00 0000f000 00002000
I (29) boot:  2 phy_init         RF data          01 01 00011000 00001000
I (29) boot:  3 ota_0            OTA app          00 10 00020000 00190000
I (30) boot:  4 ota_1            OTA app          00 11 001b0000 00190000
I (30) boot:  5 web_storage      Unknown data     01 82 00340000 00019000
I (31) boot:  6 rcp_fw           Unknown data     01 82 00359000 000a0000
I (31) boot: End of partition table
I (31) esp_image: segment 0: paddr=00020020 vaddr=3c0d0020 size=52214h (336404) map
I (92) esp_image: segment 1: paddr=0007223c vaddr=3fc95a00 size=0384ch ( 14412) load
I (95) esp_image: segment 2: paddr=00075a90 vaddr=40374000 size=0a588h ( 42376) load
I (105) esp_image: segment 3: paddr=00080020 vaddr=42000020 size=c9cd0h (826576) map
I (254) esp_image: segment 4: paddr=00149cf8 vaddr=4037e588 size=073e0h ( 29664) load
I (268) boot: Loaded app from partition at offset 0x20000
I (268) boot: Disabling RNG early entropy source...
I (269) cpu_start: Multicore app
I (278) cpu_start: Pro cpu start user code
I (278) cpu_start: cpu freq: 160000000 Hz
I (278) app_init: Application information:
I (278) app_init: Project name:     esp_ot_br
I (279) app_init: App version:      v1.0-81-g2eab508
I (279) app_init: Compile time:     Sep 14 2024 13:02:08
I (279) app_init: ELF file SHA256:  e4e37f576...
I (279) app_init: ESP-IDF:          v5.3.1-dirty
I (279) efuse_init: Min chip rev:     v0.0
I (280) efuse_init: Max chip rev:     v0.99 
I (280) efuse_init: Chip rev:         v0.2
I (280) heap_init: Initializing. RAM available for dynamic allocation:
I (280) heap_init: At 3FCA68A0 len 00042E70 (267 KiB): RAM
I (281) heap_init: At 3FCE9710 len 00005724 (21 KiB): RAM
I (281) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (281) heap_init: At 600FE100 len 00001EE8 (7 KiB): RTCRAM
I (282) spi_flash: detected chip: gd
I (282) spi_flash: flash io: dio
W (283) spi_flash: Detected size(8192k) larger than the size in the binary image header(4096k). Using the size in the binary image header.
I (283) sleep: Configure to isolate all GPIO pins in sleep state
I (284) sleep: Enable automatic switching of GPIO sleep configuration
I (285) main_task: Started on CPU0
I (295) main_task: Calling app_main()
I (345) RCP_UPDATE: RCP: using update sequence 0
I (355) uart: ESP_INTR_FLAG_IRAM flag not set while CONFIG_UART_ISR_IN_IRAM is enabled, flag updated
I (355) OPENTHREAD: spinel UART interface initialization completed
I (355) main_task: Returned from app_main()
I(355) OPENTHREAD:[I] P-SpinelDrive-: co-processor reset: RESET_POWER_ON
E(355) OPENTHREAD:[C] P-SpinelDrive-: Software reset co-processor successfully
E(375) OPENTHREAD:[C] P-RadioSpinel-: RCP is missing required capabilities: 
E(375) OPENTHREAD:[C] Platform------: CheckRadioCapabilities() at radio_spinel.cpp:245: RadioSpinelIncompatible

abort() was called at PC 0x420075fe on core 0

Backtrace: 0x40375b36:0x3fcb31a0 0x4037c8f5:0x3fcb31c0 0x40383b0e:0x3fcb31e0 0x420075fe:0x3fcb3250 0x420b6fb9:0x3fcb3270 0x4206b9bd:0x3fcb3290 0x4206bdc8:0x3fcb32d0 0x4204b079:0x3fcb3300 0x4204ac1c:0x3fcb3350 0x420498c9:0x3fcb3380 0x420089b9:0x3fcb33b0

ELF file SHA256: e4e37f576

Steps to reproduce the behavior

Follow the instructions here: https://docs.espressif.com/projects/esp-thread-br/en/latest/dev-guide/build_and_run.html

Project release version

latest

System architecture

ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)

Operating system

Linux

Operating system version

Raspberry Pi OS

Shell

Bash

Additional context

No response

chshu commented 2 weeks ago

We have confirmed that the capabilities mismatch issue occurs when running an older RCP version with a newer host version. Could you please build both the Host and RCP from the same IDF version and try again? You need to flash the RCP firmware to H2 directly.

We are currently working on a solution to safely upgrade the RCP firmware when new capabilities are enabled.