Since 2.1.0 zip release, the way of SDK distribution switched to git repo
with binary blobs and stuff. The repo isn't tagged properly for releases,
so above "git describe --tags" output is used.
This SDK version contains alleged fix for KRACK vulnerability.
Added quotation marks when setting PATH - without it compilation on
Cygwin, etc. may lead to an error. PATH on Windows can contain spaces e.g.
'C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common' which causes
problems.
Firmware built with SDK 2.0.0 can't be programmed to blank flash (will
lead to bootloop), so affected parties should be prepared to flash
esp_init_data_default.bin manually, or update their firmware to detect
blank flash and initialize default data automatically (what previous
versions of vendor SDK did themselves).
Checked that the only change is addition of "Espressif MIT" license
blurb to various header and source files. The libraries stay exactly
the same (and thus patch_16_08_09 is still needed).
Also specified dependency on $(VENDOR_SDK_DIR)/.dir.
While I was at it, made same changes to empty_user_rf_pre_init.c, even
though it doesn't seem to be built anymore, and removed the .o files in
clean-sdk target.
Suddenly introduced in SDK 1.5.4+patch/SDK 2.0.0, another callback most
users won't care about. Vendor's description is: "Set the target flash
sector to store RF_CAL parameters. The system parameter area (4 flash
sectors) has already been used, so the RF_CAL parameters will be stored
in the target sector set by user_rf_cal_sector_set." It's a mystery how
all the previous SDK version worked without a need to store this info
in flash (actually, that was one of the "selling points" of ESP8266,
setting it aside from all other chips which had RF calibration in flash),
and 2.0.0 suddenly decided to do it.
So, make this default user_rf_cal_sector_set() implementation return
flash_sectors - 5, so the last 20KB/5 sectors of flash should be
reserved for systems needs (vs 16KB/4 sectors in previous SDKs).
When building STANDALONE=y toolchain fails to build do to lwip library
failing to build. Lwip library file "liblwip_open.a" fails to build
because its looking for xtensa-lx106-elf-ar in wrong path. Proposed fix
is to pass the correct AR path to esp-open-lwip/Makefile.open as it was
done with CC path.
