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)
