Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Burning the bootloader #24

Closed
robertgregor opened this issue Mar 31, 2015 · 8 comments
Closed

Burning the bootloader #24

robertgregor opened this issue Mar 31, 2015 · 8 comments

Comments

@robertgregor
Copy link

Hello, this I have, when I tried tools - burn bootloader. I have windows 7 64.

@rogerclarkmelbourne
Copy link

I'm not sure if this is the issue, but have you selected esptool from the programmer menu ?

If this doesn't fix it, please post a full description, including any error messages.

Note you may need to go into the preferences and tick the verbose compile and verbose upload settings

@nerdralph
Copy link

There really isn't any point to the burn bootloader function. When you hold GPIO0 low during reset, it enters the ROM bootloader which can't be replaced. The upload button uses esptool to upload the sketch code to 0x0001000 and the espressif sdk lib to 0x0004000.
It would be nice if the burn bootloader function was used to flash the sdk libs, and then the upload would only have to flash the sketch, saving ~145KB on each upload.

@igrr
Copy link
Member

igrr commented Apr 1, 2015

It would be nice if the burn bootloader function was used to flash the sdk libs, and then the upload would only have to flash the sketch, saving ~145KB on each upload.

Indeed it would be! I have attempted to implement such a feature about a month ago. Unfortunately there doesn't seem to be an easy way to do that.
When you link the whole app together, linker determines the total amount of data that needs to go into rodata, data, and bss segments. It calculates things like _rodata_start, _rodata_end, and, most importantly, _heap_start.
_heap_start is referenced by Espressif startup code in libmain.a, because this is where heap is set up. So as you see it's not (easily) possible to flash the libraries and then add the app — because the libraries need to know how much data the app will use.

I guess we need to find a way to patch libmain.a so that it pulls these symbols from, say, some fixed address in flash, instead of using the value defined by the linker.

Any ideas?

@igrr
Copy link
Member

igrr commented Apr 1, 2015

I must add that this is also a much-needed feature for sketch uploads over WiFi!

@igrr igrr changed the title Error while burning bootloader: missing 'bootloader.tool' configuration parameter Burning the bootloader Apr 1, 2015
@rogerclarkmelbourne
Copy link

I'm not sure if anyone has got a build script that doesn't require the SDK and the "sketch" to be uploaded each time.

I think if @nerdralph has a Linux Makefile etc that does this, it would show if it was possible at all.

@robertgregor
Copy link
Author

Hello, my idea was, that when I will select the bootloader, the IDE will compile and load the latest SDK files. I have of course selected the esp tool.

@igrr
Copy link
Member

igrr commented Apr 1, 2015

We just need to find a way to separate libs from the rest of the application, see my comments above.

@igrr
Copy link
Member

igrr commented Apr 1, 2015

We don't use the second stage bootloader (boot.bin) at the moment. It doesn't matter what is currently flashed to the chip — it will be overwritten when you upload the sketch.

The SDK 1.0 support is already merged (#1), it is staged for the next release.

1.6.2 changed (and broke) many things, I want to wait a few more days before merging so that everything stabilizes a bit.

igrr pushed a commit that referenced this issue May 18, 2015
igrr pushed a commit that referenced this issue Oct 29, 2015
madpilot pushed a commit to madpilot/Arduino that referenced this issue Jul 15, 2017
Re-added the SNI extension.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants