Make Makefile less location-dependent, port to fixed SDK 0.9.3, use flashi instead of esptool simplifying build

[jaseg]

Hi, so here is a bunch of changes that were stacking up over here.

• The first commit (9357a82) is fixing the Makefile to be less position-depentdent by just asking the binutils for paths.
• The second commit adds a few headers for the drivers that were needed for building (I might try to remove these again in the future).
• The third commit (6fdaea6) includes fixes to build against the fixed version of espressif's SDK version 0.9.3 that can be found here: https://github.com/jaseg/espressif-esp8266-sdk . The main change there is the removal of the non-standard integer typedefs previously found in c_types.h.
• The fourth commit modifies the esp8266 makefile to just output an elf file that can later directly be passed to my modified version of upstream esptool.py and esptool-ck, dubbed flashi (since there are already enough esptools on this planet): https://github.com/jaseg/flashi

BTW, I successfully built this firmware against https://github.com/tommie/lx106-hal .

Best regards, jaseg

[igrr]

Hi, First of all, thank you for your updates. I have already cherry-picked the first commit (position-independent makefile) and the two commits related to SDK 0.9.3, on Monday. Thank you for those.

Regarding driver headers: I have not pulled them into the repository because there are some open questions regarding SDK license. The latest SDK comes with a GPL-like license, which has a requirement to license all derivative works under the same license (and I don't want to license all my code that way). I plan to split the code into two repositories: a platform-independent DCE part that will be licensed under BSD, and ESP8266-related part that can be licensed under Espressif's license. Then it will be ok to pull in any code from SDK. Or maybe Espressif will come with a better license in the next SDK release?

Regarding the fixes applied to the SDK. I prefer to keep changes to the SDK minimal in order to reduce the effort of "fixing" every new version. Currently there is a patch that should be applied to c_types.h in order to remove stuff that is already defined in standard headers (stdint.h and stdbool.h). I don't really care if they use typedefs like uint8 instead of uint8_t, as long as I can include their headers and use standard features at the same time. Additionally I don't see any merit in replacing bool with uint8_t, as bool is a valid C99 construct (through the way of preprocessor definitions). Please correct me if I'm wrong here.

As for the flash tool, i will happily replace esptool (the C one) with a single python program. Will try your version out today. But generating a flashable binary is (in my opinion) a welcome option in the makefile, as many users will ask for a .bin they can flash with existing tools. And, as I understand, binary can now be generated using your tool, right? We can probably make .elf the default target, and add an additional firmware target for cases when a binary is required.

[jaseg]

Regarding the SDK issue: Yeah, sorry, that was my perfectionism^^. I removed the bool-construct since it looked fishy to me concerning corner cases ("true" as a macro instead of a plain literal), but I found out that actually there already is a "stdbool.h" that defines that exact behavior.

As for firmware generation: I just added commands to build monolithic or split images from elf files to the tool. I hope this can at least make the dd magic in the target makefile unnecessary.

[igrr]

Could you please update the makefile to enable firmware generation (0x00000.bin, 0x40000.bin, and firmware.bin) with your tool? My comments regarding hard-coded section names and addresses can be taken into account later, I suppose.

[jaseg]

Done. The tool is now using all allocated sections in the elf image and is inferring the physical flash memory locations from the flash mapping's base address. That one is still hardcoded, but that is only because I have not seen different chips yet.