ESP8266 Community Forum

- Sun Dec 27, 2015 6:32 am #37217 Although it's yet not quite clear to me how this is all accomplished, it sounds very good, and I promise to be a good boy and read the whole thread (as I always tell others to do )

- Sun Dec 27, 2015 8:36 am #37223 So I've read the whole lot of it now (including all readme's). I am starting to get the idea, but I'm still quite unsure about some things.

The ideal situation would be to have an image that runs both with or without boot loader (for the default "customer"). I guess that's impossible, but I think it can be done with two linker scripts with different start offsets right?

I now make a "composite" image, it consists of first up to 32k of IRAM, then padding up to 64k and then the IROM section. That way it can be flashed in one go, using esptool's offset 0 (which is of course mapped to somewhere in the global memory map, I don't know where exactly from the top of my head). Can I still use such a construct, it's not completely clear to me.

My image is about 224k in size, which means it would fit twice in the "normal" 4M flash, but I am counting on a considerate growth in the future so it may become too large to fit. My approach is to replace all 4M flash chips with 32M flash chips, then I could "partition" it into four slots of 1Mbyte which would certainly be large enough and also could be linked to always the same address, right? When I would make such an "big flash" image, it can't be loaded with rboot in "normal" mode, right? So I would essentially require all "costumers" to switch to chips with larger flash or make several builds every time?

Last edited by eriksl on Sun Dec 27, 2015 11:20 am, edited 1 time in total.

- Sun Dec 27, 2015 9:58 am #37229 Another question: how about the configs.

The config struct of rboot, do I need to fill that somewhere or flash it explicitly?
The config of my own code, since I use flash sectors explicitly (no way to flash using direct rom writes I guess), my code should either find out what slot it's running in (how?) or use a shared location for all slots at slot #0 I guess?
The config of the sdk code (wlan) parameters, will the sdk code recognise 1M mode and write it at the appropriate location automaticall

I now have to area's at the end of the 256 Kb, starting with my own config, followed by the "official" location of the sdk config.

Can I make a "composite" image that includes boot loader + iram section + irom section?

How much iram does the boot loader require (after the image has been started)? I am very tight on iram, I have only 150 bytes spare nowadays, with very few possible optimisations left.

- Sun Dec 27, 2015 11:40 am #37240 I'm at work today and going away for a couple of days from this evening, but I'll try and answer as many of your questions as I can now so you have something to be getting on with.

The config struct of rboot, do I need to fill that somewhere or flash it explicitly?

Config block is stored in the second flash sector. A default config will be generated on first boot, or you can flash a custom one.

my code should either find out what slot it's running in (how?)

Look at the rboot-api.c file (and documentation) there is an api call for getting the currently selected rom slot.

or use a shared location for all slots at slot #0 I guess?

A choice, depending on if yu want shared config or config per rom.

The config of the sdk code (wlan) parameters, will the sdk code recognise 1M mode and write it at the appropriate location automatically

Sdk config is always written in the last 4 sectors of the flash (based on the flash size) and is independent of rom config.

Can I make a "composite" image that includes boot loader + iram section + irom section?

Yes. The rom images used by the boot loader are already combined (ram/rom) in a single file. You can append this to the rBoot binary, config (or blank) and appropriate padding between them to make a single image if you wish.

How much iram does the boot loader require (after the image has been started)? I am very tight on iram, I have only 150 bytes spare nowadays, with very few possible optimisations left.

rBoot uses absolutely zero iram, unlike the sdk bootloader which uses 144bytes.

The ideal situation would be to have an image that runs both with or without boot loader (for the default "customer"). I guess that's impossible, but I think it can be done with two linker scripts with different start offsets right?

Correct. But producing two images is just a matter of adding a second linker script and a couple of extra lines in the Makefile to link and build the rom a second time.

then I could "partition" it into four slots of 1Mbyte which would certainly be large enough and also could be linked to always the same address, right?

Correct, this would be my recommended layout. Although you probably only need to use two slots, so you can just define two (this is the default). So far I only know of one person using more than two rom slots.

When I would make such an "big flash" image, it can't be loaded with rboot in "normal" mode, right? So I would essentially require all "costumers" to switch to chips with larger flash or make several builds every time?

As long as a single image will still fit on the smallest device you intend to support your users can flash a correctly linked version to a non-rboot device over serial in the normal way. If you use a per-rom config area and use the rboot-api to determine which rom you are running you'd need to add a tiny bit of code to identify if you were running from rBoot or not. Or just #ifdef the code and rebuild separate from same source with different options. Nothing too complicated.