Rboot - rebased against latest master

[romanchyla]

Hi, as part of the review for OTA nodemcu/issues/1496 I rebased your code against the latest master. It compiles successfully, what I had to do:

• update Makefiles (include esptool2 repo checkout; and run the creation of libmain2.a)
• manually update spiffs.c

Could you please check my commit to see if there is anything wrong; especially the spiffs.c? I've left a comment marked 'QQQ'

Also, I'm seeing this warning:

../tools/esptool.py elf2image .output/eagle/debug/image/eagle.app.v6.out -o ../bin/
esptool.py v1.2-dev
WARNING: irom0 section offset is 0x00002010. ELF is probably linked for 'elf2image --version=2'  

Is it important?

I didn't yet flash the firmware so I don't really know if it works...

[romanchyla]

One additional question: the esptool2 - I'm not clear whether it could be replaced (or if the esptool.py; which is undergoing active development could be enhanced). Could you comment on that?

[djphoenix]

Is it important?

elf2image is not required in rBoot mode at all.

[romanchyla]

My apologies, I'm seeing it is not trivial to see the changes I had to make; my last commit is not important

the real question, really, is only the spiffs.c changes in this commit: 0a8a73f

[raburton]

I found it much easier to reapply the rBoot changes on top of the latest master, rather than merging all the new commits into that branch, but whichever way is easiest for you...
I think a lot of what esptool2 does can now be done by other tools, either esptool.py or elf2image, except one - they would not extract the stage 2.5 loader binary to hex and create the include file. I don't think they'd want to include this because it's very specific to the rBoot build process.

[djphoenix]

@raburton why not to use command-line tools like objcopy and then xxd? I actually believe there's no important things that can't be done with existing toolchain.

[romanchyla]

I'm sorry (still learning), what is 'stage 2.5'?

Is it as simple as extract and hexify? Or is it more involved (if simple, we can do it in many ways; actually esptool.py already has it; there is a proliferation of esptools, to add to my confusion; https://github.com/igrr/esptool-ck is another one)

[raburton]

There may be lots of other ways to do it, but when I wrote esptool2 there was no good way to generate roms from the compiled elf, it all involved lots of tools and badly written scripts. When I needed to extract a section to a header file I just added the functionality to the tool I was already using for rom building. It works on all platforms too, if you use unix commands will they be available on windows?

Standard boot:
Stage 1 = built in rom based bootloader
Stage 2 = user app

rBoot boot:
Stage 1 = built in rom based bootloader
Stage 2 = main rBoot
Stage 2.5 = tiny rBoot copy and launch code
Stage 3 = user app

As rBoot ultimately needs to load the user app into the same memory it is running from, it has to move its final steps (the actual copy and launch) out to a different area of memory. The tiny bit of code that does that is what I call stage 2.5

[djphoenix]

will they be available on windows?

Definitely no... but yes because firmware compilation on windows requires MinGW at least, or Cygwin in most cases. :)
And use of standard *nix commands is really simplier that fetch & compile additional tool. So I prefer to use Unix-way if it possible.

[ymxcc]

@romanchyla @raburton

I found a problem happened the PWM module that it would be dead code when running it.

Do you encountered that problem?

Thanks!

[djphoenix]

@ymxcc was found this. Change of interrupt type from NMI to FRC1 fixes that. Don't really understood why this happens...

[ymxcc]

@djphoenix Correct! I tried to change the interrupt type from NMI to FRC1, it works!

if (!platform_hw_timer_init(TIMER_OWNER, FRC1_SOURCE, FALSE)) {
PWM_DBG("WHY STOP HERE? \n");
return FALSE;
}

This problem was considering in my mind all the time in these days. Follow your idea, it works pretty well! Thanks so much.

Before, the original nodemcu firmware that I used on the RGB led worked very well whatever in NMI type or FRC1 type. It could be find the reason why just we need to read the code for NMI type deeply.

Anyway, thanks for @djphoenix