ESP8266 Community Forum

- Sun Sep 07, 2014 3:34 am #288 Just a guess but I think 512K and 2M are the only choices:

512K / 4K = 128
2048K / 16K = 128

So far the only options for page sizes are 4K and 16K -- multiply by 128 to get the max flash size.

- Sun Sep 07, 2014 3:36 am #290

We have on hands dump of 512K size. But then people said there can be bigger flash chip - and smaller, too.

I can't find the place listing the different Flash memory sizes.

Here's that place: viewtopic.php?f=5&t=9#p135

Are you sure there are some smaller sizes, or different than 512K and 2M?

Nope, not sure at all, that's just what people say.

- Sun Sep 07, 2014 5:50 am #292

It can be mask ROM, or OTP, or just flash ROM whose means of programming are yet to be discovered.

I think it is safe to assume that the boot ROM is indeed ROM. Flash memory is, afaik, somewhat tricky and/or expensive to integrate in an ASIC (usually a third party IP block that must be licensed and tailored to the relevant chip technology), which is why they chose to use an external, off-the-shelf part, just like the other folks did with the Parallax Propeller.
It wouldn't make sense to require an external flash chip if there were on-chip flash already.

1. All this information is based on the dumps provided by 3rd parties. They may be incorrect or erronuous.
2. kongo, provider of builtin ROM dump, reports that reading 0x40200000 and up returns zeroes (but then who are you to read my app? ever heard of vendor flash protection?)

Hey, thanks for the stab. I've heard of memory protection and commented on it much earlier in this thread, but I think it is highly unlikely that such a scheme is employed, judging from the other parts of this story (We're still loading unencrypted, unsigned application code from an external flash chip!)

3. Demo app from SDK was built and posted here, and sizes more than 32K, and thus won't fit into (provided by vendor) I-RAM size. But then it is surprisingly segfaults on execution.

The AT application firmware image is ~32074 bytes, including headers, and that is further divided into IRAM and DRAM. It looks like the IRAM at 0x40100000 is ~64KiB, but I have to verify that it does not wrap around.

The application firmware .text segment is linked and loaded at 0x40100000, .data and .rodata is loaded in DRAM at 0x3ffe8000. Writing to the 0x40200000/0x40240000 range through the bootloader makes it crash, probably due to a bus exception.
I feel pretty confident, because I managed to hack together an assembly routine that writes repeatedly to the UART, download it to RAM (at 0x40100000) through the bootloader and run it.
(Downloading wi07c.rom to RAM and running it does not seem to work yet, however. Perhaps it depends on some state that is affected by the boot mode)

I think I need a working toolchain (on linux) to do more interesting stuff

- Sun Sep 07, 2014 7:05 am #294

I think it is safe to assume that the boot ROM is indeed ROM.

Well, just trying to find explanation for tentative routine address mismatch spotted by Squonk - if it's mask ROM, it may incur extra cost to re-run crystal production to get out new ROM version.

1. All this information is based on the dumps provided by 3rd parties. They may be incorrect or erronuous.
2. kongo, provider of builtin ROM dump, reports that reading 0x40200000 and up returns zeroes (but then who are you to read my app? ever heard of vendor flash protection?)

Hey, thanks for the stab. I've heard of memory protection and commented on it much earlier in this thread, but I think it is highly unlikely that such a scheme is employed, judging from the other parts of this story (We're still loading unencrypted, unsigned application code from an external flash chip!)

Well, as long as you can report customers that their firmware is protected, nobody really cares how well it's protected, right? Anyway, again just trying to find an explanation for the behavior you see - but there's certainly code at 0x40240000, and that code comes from lib/*.a from SDK. (And I'd love to call Linux bloat for having so much code to implement WiFi, and tell that smart Chinese folks were able to fit everuything into 64K+32K, but could I go that far? - there must be more code to handle all the mess starting from WEP, and it must be possible to execute it somehow).

The AT application firmware image is ~32074 bytes, including headers, and that is further divided into IRAM and DRAM. It looks like the IRAM at 0x40100000 is ~64KiB, but I have to verify that it does not wrap around.

Yes, verifying I-RAM size would be much appreciated.

The application firmware .text segment is linked and loaded at 0x40100000, .data and .rodata is loaded in DRAM at 0x3ffe8000. Writing to the 0x40200000/0x40240000 range through the bootloader makes it crash, probably due to a bus exception.
I feel pretty confident, because I managed to hack together an assembly routine that writes repeatedly to the UART, download it to RAM (at 0x40100000) through the bootloader and run it.

Ok, so can you for example take wi07c.rom (if you didn't make your clean-room flash dump yet), find a ret.n there past 0x40000, and try to call it from your asm routine past 0x40240000 address and see if you get back, then call an instruction before ret.n which updates a reg and see if result is expected, etc?