ESP8266 Community Forum

- Wed Aug 19, 2015 10:44 pm #26536 Glenn,

I think one of the things you are missing is that Sming and Spiffs doesn't take into consideration the offset for rboot of 0x2000. It assumes everything is placed at 0x00. All of the calculations for the offset are going to be off based on that. I don't know exactly how that offset works...I untwined it at one point on paper, but now can't find my notes. I do have a working example of all of this...however instead of cutting the 4MB flash in half and putting 2x1MB at slot 0 and 2, I used the 2MB settings and have my 2 fs in the first two slots. It was just easier, but shouldn't really matter too much.

Anyways, I'd be happy to send you a new zip of my project...I'm also gonna work on a pull request for Sming to allow a fixed location for the SPIFFS.

PiperPilot (curtis)

- Thu Aug 20, 2015 2:37 am #26542 I was going to write some instructions on how to double wrap this morning as previously mentioned, but looks like you're past that point now. And yes, os_printf is an sdk function and some or all of it resides in flash, so you can't call it before the flash is mapped (such as in the mapping function). ets_printf is in the base rom, so you can use that. So nearly there!

I've had a quick look at the code for spiffs and I was surprised to find that defined value in the makefile isn't used in the code, it's just for flashing the bin file to the device. I've looked at espfs previously and it passed the defined value from the makefile to the compiler so the code used it as the location for the fs. So we need to work out where this equivalent value is calculated in the code. Had a quick look (before work) and it appears that it does use spi read calls rather than accessing by memory mapping (which is good really, because it will allow you exceed the memory mapped area), but will require a check of the current rom slot and the addition of an offset to select between the two different spiffs. Anyway, not quite got to the bottom of how it finds the base location of the spiffs yet, if I get chance at work to look some more at work during the day I will do. As mentioned by piperpilot it might be a simple issue of not accounting for the 8k of rboot and config sector (either where it tries to read from, or where you try to flash to). First step is getting rom0 to work properly, then add in the conditional offset for use in rom1.

- Thu Aug 20, 2015 7:46 am #26561 Hey Richard,

OK...this explains why I'm having trouble accessing the right SPIFFS after I OTA Update...I just got that working yesterday and it seemed like it took two updates to see the updated web pages. I was gonna dig into that today, but your explanation of using SPI access instead of memory mapped makes sense.

The compiler does so of pass the location...it uses a constant that the Sming developers set in the linker:

Code: Select all_flash_code_end = ABSOLUTE(.);

Which is set in this block of code:

Code: Select all  .irom0.text : ALIGN(4)
  {
    _irom0_text_start = ABSOLUTE(.);
    *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text)
   out/build/app_app.a:*(.literal .text .literal.* .text.* .stub .gnu.warning .gnu.linkonce.literal.* .gnu.linkonce.t.*.literal .gnu.linkonce.t.*)
  *libsming.a:*(.literal .text .literal.* .text.* .stub .gnu.warning .gnu.linkonce.literal.* .gnu.linkonce.t.*.literal .gnu.linkonce.t.*)
    _irom0_text_end = ABSOLUTE(.);
/*   _flash_code_end = ABSOLUTE(.); */
   _flash_code_end = ABSOLUTE(0x44000);
  } >irom0_0_seg :irom0_0_phdr


You can see that In the above code, I commented out the standard line and set it to a fixed position so that I could move it around and not just put it at the end of my code + Offset.

_flash_code_end is used in "Sming/system/flashmem.c" in the routine "flashmem_get_first_free_block_address".

The above code is used in "spiffs_get_storage_config()" which is called from "spiffs_mount()" both in "Sming/Services/SpifFS/spiffs.c".

I have an open feature request to Sming which everyone thinks is a good idea to allow override of the default location check for the SPIFFs. My thought is that we could leave the original method of calculating the offset/location there, but check for the existence of some variable, either passed in from the makefile or defined in user code. If that is there, then on mount it would use it instead of going off and calculating it. This would allow us to put a check for the ROM slot and set the SPIFFs location based on that.

Anyways...hope this makes sense.

Glad to have another couple of sets of eyes on this...I've been making slow but steady progress for several weeks.

- Thu Aug 20, 2015 7:57 am #26562 Makes sense. I like the way it detects the end of the code, that's quite neat but a manual override would be handy. For your case you wouldn't need to set a manual position though - you could use the current mechanism, but edit the function that returns the offset to add 2mb to the address when the second rom is selected. The rboot-ota code includes a simple function to return the current rom slot so it'd just be a matter of using that to decide whether to add the 2mb or not. Or something more complex that takes the rom slot flash position and adds the rom length (calculated by the current method), that way you wouldn't need to hard code the 2mb in there or change it again if you altered your flash layout. It would work like it does now looking for the end of the code position, but offset the result by the actual rom position on the flash. Just got a couple of letters to dictate and I hope I'll be able to have a look at it (but at work so can't actually test anything out).