ESP8266 Developer Zone

Re: Use all of the 512 kbyte of the 4M flash

2015-07-26T22:00:33+08:00

My code now does that too: start at 0x10000 and flash in one go, with the area between 0x00000-0x10000 padded to 0x10000 (depending on the size of the iram region) and then almost all of the flash can be used. I am not using the area between 0x8000 and 0x10000, it's only 32 kb, but when I need to, I will lower the start address to even 0x8000 and there will be no gaps left.

I also added some "tools" in the makefile to help "debugging" "section full" problems (iram or irom), that lists the symbols and their sizes sorted.

In the end it's all not that complex, it's just that it's documented nowhere...

https://github.com/eriksl/esp8266-universal-io-bridge

Statistics: Posted by eriksl — Sun Jul 26, 2015 10:00 pm

Re: Use all of the 512 kbyte of the 4M flash

2015-07-26T21:53:35+08:00

It most certainly does not have to be that way. In our code (http://tech.scargill.net - look up the "Home Control 2015" project) we use a bootloader provided by Richard Burton - and he's also a very helpful chap.. http://richard.burtons.org/2015/05/18/r ... r-esp8266/

To cut a long story short, our makefile - which exists largely because of Richard's help, loads our code and the SDK right down at the bottom of the 512k in one lump, the user variable storage FLASH area right at the top and so now even thought the project is very large there is a massive area of FLASH left in the basic ESP.

Here is an example: From the bottom up we blow code..

Writing at 0x00046400... (96 %)
Writing at 0x00046800... (97 %)
Writing at 0x00046c00... (97 %)
Writing at 0x00047000... (97 %)
Writing at 0x00047400... (98 %)
Writing at 0x00047800... (98 %)
Writing at 0x00047c00... (98 %)
Writing at 0x00048000... (99 %)
Writing at 0x00048400... (99 %)
Writing at 0x00048800... (100 %)
Erasing flash...

Then at the very top we store some WIFI info...

Writing at 0x00070000... (9 %)
Writing at 0x00070400... (18 %)
Writing at 0x00070800... (27 %)
Writing at 0x00070c00... (36 %)
Writing at 0x00071000... (45 %)
Writing at 0x00071400... (54 %)
Writing at 0x00071800... (63 %)
Writing at 0x00071c00... (72 %)
Writing at 0x00072000... (81 %)
Writing at 0x00072400... (90 %)
Writing at 0x00072800... (100 %)

As you can see from 48C00 to 7000 is still available... and I've already started to put arrays in Flash to get them out of the more sparse RAM.

Statistics: Posted by scargill — Sun Jul 26, 2015 9:53 pm

Re: Use all of the 512 kbyte of the 4M flash

2015-07-24T21:44:38+08:00

Almost correct (as far as I know now). I've had some help from the community and I've learned this:

Normally the code for iram is stored in the binary file that should be flashed to 0x00000 and ends up at the start of the SPI flash, and that will be copied to iram on system startup.

The code that will actually run from SPI flash is mostly loaded and flashed to 0x40000. It's a mystery to me why it is that way. 0x40000 is exactly halfway the normal (small, 512 Kb) SPI flash size, i.e. at the 256 Kb boundary. That means you have only 256 Kb left, minus the system NV area. I guess it has "something" to do with OTA updating.

I was under the impression that the address mapping would not be lineair and that the code from 0x40000 (irom) would end up just after the iram code. I was corrected by someone with a bit more experience in this area; it appears the mapping is actually competely linear and the irom code is written halfway the SPI flash.

That is why I couldn't get it to work earlier on, I made firmwares that were over 256 Kb in total, that were programmed from the 256 Kb (0x40000) on, so it would wrap around and overwrite the 0x00000 area.

So the solution appears to be: start the irom region at 0x10000 instead of 0x40000 and change the size accordingly, I believe it should be 0x6a000 then (that's a bit conservative, it might be a few Kb more). In theory it should be possible to start at 0x8000 (32 Kb) instead of 0x10000 (64 Kb), but I couldn't be bothered for the last 32 Kb's Maybe I'll try it when I really need those.

Statistics: Posted by eriksl — Fri Jul 24, 2015 9:44 pm

Re: Use all of the 512 kbyte of the 4M flash

2015-07-24T11:48:44+08:00

Hi,

I think you can do it by changing irom0_0_seg size.
Reserve several blocks for flash.bin, depends on its size e.g 0x4000. Then your irom0_0_seg max size can be:

Code:

512KB - 16KB (system param) - flash.bin size (e.g. 16Kb) = 0x78000

Code:

irom0_0_seg :                         org = 0x40204000, len = 0x78000

Beware of 'org = 0x40204000', you must account the space of flash.bin.

More info, refer to 99C-ESP8266__OTA_Upgrade__EN. Hope it helps.

Dat

Statistics: Posted by datltq — Fri Jul 24, 2015 11:48 am

Use all of the 512 kbyte of the 4M flash

2015-07-21T17:51:23+08:00

Hello,

Is it possible to use all of the 512 kbyte of the 4M flash? I am not going to do any OTA-updating, so I think it's a pity I can't use this part of the flash. When I flash firmwares beyond the 192 kbyte boundary, the code won't run.

Would it be possible to define an extra segment + section(s) in the linker script that maps to offset 0x40000 (256 k) and put some code there?

Something like this:

Code:

 MEMORY
 {
   dport0_0_seg :                        org = 0x3FF00000, len = 0x10
   dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
   iram1_0_seg :                         org = 0x40100000, len = 0x8000
   irom0_0_seg :                         org = 0x40240000, len = 0x3C000
+  irom0_1_seg:                          org = 0x40280000, len = 0x3c000
 }

PHDRS
{
    dport0_0_phdr PT_LOAD;
    dram0_0_phdr PT_LOAD;
    dram0_0_bss_phdr PT_LOAD;
    iram1_0_phdr PT_LOAD;
    irom0_0_phdr PT_LOAD;
+   irom0_1_phdr PT_LOAD;
}

Code:

   .irom0.text : ALIGN(4)
   {
     _irom0_text_start = ABSOLUTE(.);
     *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text)
     _irom0_text_end = ABSOLUTE(.);
   } >irom0_0_seg :irom0_0_phdr
+
+  .irom1.text : ALIGN(4)
+  {
+    _irom1_text_start = ABSOLUTE(.);
+    *(.irom1.text)
+    _irom1_text_end = ABSOLUTE(.);
+  } >irom0_1_seg :irom0_1_phdr

Thanks!

Statistics: Posted by eriksl — Tue Jul 21, 2015 5:51 pm