The 16-bit format group addresses will be stored,
but we don't store (or restore) the virtual label UUIDs,
i.e. after a power cycle the 16-bit group addresses
would be meaningless.
Creates macros for determining model message lengths based on opcode,
payload length and MIC size. Also adds macro wrapping
NET_BUF_SIMPLE_DEFINE to serve the most common use case.
Re-encrypts single-segment application messages when the network seqnum
has changed, to avoid encrypting messages with different seqnums in
network and transport. This operation is only required for unsegmented
messages, as segmented messages don't need to use the same seqnum in
network.
Reinstates the special adv data for friend messages to store the app key
index.
Stores friend queue packets unencrypted, removing any out-of-order
issues caused by seqnum allocation. Also moves as much of the metadata
storage as possible into the packet, allowing us to free up some bytes
of net_buf user data for friend packets.
newlib/assert: replace unlikely with likely to keep original assertion
newlib/assert: fix assert macro that uses likely
freertos/port: add the missing sdkconfig.h back
newlib/assert: assert macro back to a single line
esp_common/esp_compiler: renamed esp_macros file to a more specific one
esp_common/esp_compiler: removed CONTAINER_OF macro, it was a duplicate
components/freertos: placed likely macros around port and critical sections
component/freertos: placed likely macros on lists module
components/freertos: placed unlikely macros inside of assertion points, they likely wont fail
components/freertos: added likely macros on queue modules
FreeRTOS queues are one of most hot code path, because to queues itself tend to
be used a lot by the applications, besides that, queues are the basic primitive
to form both mutexes and semaphores, The focus here is to place likely
macros inside lowest level send and receive routines, since they're common
from all kobjects: semaphores, queues, mutexes and FR internals (like timer queue)
components/lwip: placed likely/unlikey on net-interfaces code
components/fatfs: added unlikely macros on disk drivers code
components/spiffs: added unlikely macros on low level fs driver
components/freertos: added likely/unlikely macros on timers and ticker
freertos/event_group: placed likely/unlikely macros on hot event group code paths
components/sdmmc: placed likely / unlikely macros on lower level path of sdmmc
components/bt: placed unlikely macros around bt HCI functions calling
components/lwip: added likely/unlikely macros on OS port code section
components/freertos: fix code style on tick handler
On Xtensa, backtrace can not recover the two most significant bits of
the address, as the window call size is encoded in these bits.
Because of this, __builtin_return_address modifies these MSBs to
match those of the callee, "fixing" the address. An unfortunate side
effect is that the zero return address, which usually terminates the
backtrace, gets converted to 0x40000000. While there is a valid
instruction at this address, its occurrence in the backtrace is
highly unlikely: this is the first instruction of WindowOverflow4
vector, and IDF apps switch VECBASE to an IRAM location very early at
startup.
Even if frame->exccause != PANIC_RSN_CACHEERR, it is possible that
the cache error interrupt status is set. For example, this may happen
due to an invalid cache access in the panic handler itself.
Check cache error interrupt status instead of frame->exccause to
decide whether to do CPU reset or digital reset.
Also remove unnecessary esp_dport_access_int_pause from
esp_cache_err_get_cpuid, since the panic handler already calls
esp_dport_access_int_abort on entry.
* Don't bother checking the chip revision if it looks like the partition
doesn't really contain an app
* Don't print the "info" level about the revision & min revision unless
we're in the bootloader (otherwise it gets printed at random times
during the OTA process)
