XMC flash support - WIP

[ChocolateFrogsNuts]

XMC Flash output drive power support for the core.

WIP because there is a component for eboot that will be pushed here later, but it still has a few kinks to be worked out. The eboot component is only required / in play where an OTA update is being applied and the power fails during the eboot copy phase. Without it a power failure during the reboot after an OTA update may brick the esp until the firmware is reloaded via USB, but this is untested, and there is a good chance that the eboot copy will succeed when power is reapplied anyway.

This PR has no effect if your board does not have an XMC brand spi flash chip.

Third and final part of the solution to #6559

[devyte]

Waiting on eboot bits.

[ChocolateFrogsNuts]

Some work still required on the eboot part.
Specifically my re-implementation of spi_flash_get_id() from the SDK (which isn't available in eboot).
It turns out the flash ID which I was seeing in the SPI0W0 register was a leftover from a previous call to ESP.getFlashChipId() in my test environment.

[earlephilhower]

@ChocolateFrogsNuts I did a manual code merge, but you'll need to rebuild and push the new eboot.elf.

Right now it's ever-so-slightly beyond the 4K limit so we need to find a way to reduce the code size somehow:

earle@server:~/Arduino/hardware/esp8266com/esp8266/bootloaders/eboot$ make
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -std=gnu99 -Os -g -Wall -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mno-text-section-literals -ffunction-sections -fdata-sections -I../../tools/sdk/include -I../../tools/sdk/uzlib/src -DRUNTIME_BITS_TABLES   -c -o eboot.o eboot.c
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -std=gnu99 -Os -g -Wall -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mno-text-section-literals -ffunction-sections -fdata-sections -I../../tools/sdk/include -I../../tools/sdk/uzlib/src -DRUNTIME_BITS_TABLES   -c -o eboot_command.o eboot_command.c
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -std=gnu99 -Os -g -Wall -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mno-text-section-literals -ffunction-sections -fdata-sections -I../../tools/sdk/include -I../../tools/sdk/uzlib/src -DRUNTIME_BITS_TABLES -c -o tinflate.o ../../tools/sdk/uzlib/src/tinflate.c
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -std=gnu99 -Os -g -Wall -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mno-text-section-literals -ffunction-sections -fdata-sections -I../../tools/sdk/include -I../../tools/sdk/uzlib/src -DRUNTIME_BITS_TABLES -c -o tinfgzip.o ../../tools/sdk/uzlib/src/tinfgzip.c
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-ar cru eboot.a eboot.o eboot_command.o tinflate.o tinfgzip.o
../../tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -Teboot.ld -nostdlib -Wl,--no-check-sections -Wl,--gc-sections -umain -Wl,--start-group -Wl,--whole-archive eboot.a -Wl,--end-group -o eboot.elf
/home/earle/Arduino/hardware/esp8266com/esp8266/tools/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld:eboot.ld:159 cannot move location counter backwards (from 0000000040110040 to 000000004010fff8)
collect2: error: ld returned 1 exit status
Makefile:53: recipe for target 'eboot.elf' failed
make: *** [eboot.elf] Error 1

[earlephilhower]

If we drop some sanity checks in the eboot section handler, it all just barely fits. I don't think there is much reason to have the checks there if we're using our own elf2bin.py script and can guarantee anything we create is valid. If anything was uploaded that's invalid, well, that would kind of crash anyway I think.

diff --git a/bootloaders/eboot/eboot.c b/bootloaders/eboot/eboot.c
index 8d00ed0e..dc943808 100644
--- a/bootloaders/eboot/eboot.c
+++ b/bootloaders/eboot/eboot.c
@@ -60,7 +60,7 @@ int load_app_from_flash_raw(const uint32_t flash_addr)
         pos += sizeof(section_header);

         const uint32_t address = section_header.address;
-
+#if 0
         bool load = false;

         if (address < 0x40000000) {
@@ -79,7 +79,7 @@ int load_app_from_flash_raw(const uint32_t flash_addr)
             pos += section_header.size;
             continue;
         }
-
+#endif
         if (SPIRead(pos, (void*)address, section_header.size))
             return 3;

@@ -118,11 +118,13 @@ int copy_raw(const uint32_t src_addr,
              const uint32_t dst_addr,
              const uint32_t size)
 {
+#if 0
     // require regions to be aligned
     if ((src_addr & 0xfff) != 0 ||
         (dst_addr & 0xfff) != 0) {
         return 1;
     }
+#endif

     const uint32_t buffer_size = FLASH_SECTOR_SIZE;
     uint8_t buffer[buffer_size];

[ChocolateFrogsNuts]

I'll try to get back to this soon, but for now you could probably leave out the eboot bits if you need the space.

• they only come into play after a power fail during an OTA update
• they don't work yet anyway as I still need to fix my re-implementation of spi_flash_get_id()
  There has to be some little thing I missed when translating it from the SDK disassembly, but I haven't managed to find it yet.

[devyte]

@ChocolateFrogsNuts What's the status with this one?

[ChocolateFrogsNuts]

@ChocolateFrogsNuts What's the status with this one?

What's here works except for the case where the power is cycled during the eboot copy phase.
In that case it may or may not work in the same way it may or may not work with no XMC support at all (ie this update doesn't make it worse).

I haven't had a chance to get back to why my version of spi_flash_get_id() doesn't work :(

[devyte]

I think this requires a new eboot.elf?

[earlephilhower]

Yes, it will need a new eboot.elf added to the PR.

@ChocolateFrogsNuts , you've #define XMC_SUPPORT in the included eboot. Does the XMC stuff have any negative effects on other flash types? Maybe just remove the ifdefs in the eboot.c code ?

On my own noname D1 Mini clone it works fine, just tested it. It's not XMC (was working before) and works with this patch.

[ChocolateFrogsNuts]

@ChocolateFrogsNuts , you've #define XMC_SUPPORT in the included eboot. Does the XMC stuff have any negative effects on other flash types? Maybe just remove the ifdefs in the eboot.c code ?

It has no effect at all as long as the chip ID doesn't match XMC's. Should be no problem leaving it all in.

[earlephilhower]

Great, thanks @ChocolateFrogsNuts . Can you build an eboot.elf and add it to your PR? The current only changes the sources and doesn't have the new bootloader for use by the IDE.

If you can't regen the bootloader, we can still do it with a new PR, but it would be cleaner to have the bins and sources match in GIT.

[ChocolateFrogsNuts]

Merged master to my local copy, but now have an issue with a missing uzlib.h

Did it get missed in a commit elsewhere, or do I need to do something to bring uzlib into my copy?

[earlephilhower]

git submodule init and update maybe?

[ChocolateFrogsNuts]

Thanks, my lack of git usage is showing :)
That should have it up to date now.

[earlephilhower]

Thanks!

[devyte]

This has been merged as still WIP, because there is still one detail pending. As explained above, for XMC flash chips it is possible that if there is a power failure during the eboot copy process, the ESP could be bricked. That will be handled if/when needed in the future.