ESP8266 Community Forum

- Sat Sep 06, 2014 5:02 am #242 Squonk, I downloaded binutils-xtensa-linux-gnu-2.24-5.fc20.x86_64.rpm (google). And get a reasonable dump usng

xtensa-linux-gnu-objdump -b binary -mxtensa -D esp8266.bin

The issue, 3-byte opcodes don't mix well with "word" padding, so oftentimes disassembly starts from unpadded address. In either case, you can see something sane at 0x18a4 (ets_memset) - if you may sane redirecting this simple call to yet another function .

- Sat Sep 06, 2014 5:10 am #243

@kongo: you have been dumping the I-RAM instead of the I-ROM.

From the lx106 configuration file:

Code: Select allMemory Protection/MMU: Region Protection
  System RAM start address / size                               0x60000000 / 64M
  System ROM start address / size                               0x50000000 / 16M
Local Memory     
  Instruction RAM [0] start address / size                      0x40000000 / 1M [busy]
  Instruction RAM [1] start address / size                      0x40100000 / 1M [busy]
  Instruction ROM start address / size                          0x40200000 / 1M [busy]
  Data RAM [0] start address / size                             0x3ffc0000 / 256K [busy]
  Data RAM [1] start address / size                             0x3ff80000 / 256K [busy]
  Data ROM start address / size                                 0x3ff40000 / 256K [busy]
  XLMI start address / size                                     0x3ff00000 / 256K [busy]
Vector configuration     
  Reset Vector start address / size                             0x50000000 / 0x300
  Kernel (Stacked) Exception Vector start address / size        0x40000030 / 0x1c
  User (Program) Exception Vector start address / size          0x40000050 / 0x1c
  Double Exception Vector start address / size                  0x40000070 / 0x10
  Level 2 Interrupt Vector start address / size                 0x40000010 / 0xc
  Level 3 Interrupt Vector (NMI vector) start address / size    0x40000020 / 0xc

I wouldn't count on the sizes being correct (as in: actually implemented in hardware), though.
Edit: further reading of product briefs suggests that these memory sizes are actually possible.

Memory dumping at 0x40200000 - 0x40a00000 returns only zeros.

That gives us two options:
1) The dumped 64KiB is a RAM which acts as a patchable jump table. The IROM region is either protected from readout, or resides at another base address, however this will be easy to find as soon as the dump is disassembled. (But why would the bootloader string literals be copied to RAM?)
2) The dumped 64KiB is *the* ROM, despite the name in the configuration, and the IROM area is just an unused black hole.

I am inclined to believe in the second option. The CPU might be configured in one way, but it is then up to the ASIC designer to actually connect the RAM and ROM blocks (usually third party IP blocks, designed for that specific technology node), and that might leave room for some adjustments.

Edit: It seems that most of the complex code is stored in Flash/RAM anyway (liblwip.a, libnet80211.a, libphy.a, libssl.a, etc)

- Sat Sep 06, 2014 5:30 am #244

Squonk, I downloaded binutils-xtensa-linux-gnu-2.24-5.fc20.x86_64.rpm (google). And get a reasonable dump usng

xtensa-linux-gnu-objdump -b binary -mxtensa -D esp8266.bin

The issue, 3-byte opcodes don't mix well with "word" padding, so oftentimes disassembly starts from unpadded address. In either case, you can see something sane at 0x18a4 (ets_memset) - if you may sane redirecting this simple call to yet another function .

Even if xtensa is using 3-byte opcodes, it looks like all functions are aligned to long word boundaries: all addresses in ld ROM include file are ending in 0, 4, 8 or C.

BTW, it looks like upstream binutils 2.22 had some padding problems, that were corrected in Xtensa-supplied 2.20 binutils:
http://lists.linux-xtensa.org/pipermail ... 01272.html

Don't know about 2.24 though.

I will try with your binutils, although I am not on Fedora!

- Sat Sep 06, 2014 6:11 am #245

I will try with your binutils, although I am not on Fedora!

Neither me. I wanted to try Debian's alien, but ended up just extracting binaries from RPM's cpio and using those.