Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

XMC flash support - WIP#6725

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
devyte merged 21 commits intoesp8266:masterfromChocolateFrogsNuts:xmc_flash
Apr 23, 2020
Merged

Conversation

@ChocolateFrogsNuts
Copy link
Contributor

@ChocolateFrogsNutsChocolateFrogsNuts commentedNov 8, 2019•
edited
Loading

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 updatemay 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

OttoWinter reacted with thumbs up emoji
@devytedevyte modified the milestones:2.7.0,2.6.2Nov 19, 2019
@devytedevyte modified the milestones:2.6.2,2.7.0Nov 19, 2019
@devyte
Copy link
Collaborator

Waiting on eboot bits.

@ChocolateFrogsNuts
Copy link
ContributorAuthor

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
Copy link
Collaborator

@ChocolateFrogsNuts I did a manual code merge, but you'll need to rebuild and push the neweboot.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 statusMakefile:53: recipe for target 'eboot.elf' failedmake: *** [eboot.elf] Error 1

@earlephilhower
Copy link
Collaborator

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.cindex 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
Copy link
ContributorAuthor

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
Copy link
Collaborator

@ChocolateFrogsNuts What's the status with this one?

@ChocolateFrogsNuts
Copy link
ContributorAuthor

@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
Copy link
Collaborator

I think this requires a new eboot.elf?

@earlephilhower
Copy link
Collaborator

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 theifdefs 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
Copy link
ContributorAuthor

@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 theifdefs 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
Copy link
Collaborator

Great, thanks@ChocolateFrogsNuts . Can you build aneboot.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
Copy link
ContributorAuthor

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
Copy link
Collaborator

git submodule init andupdate maybe?

@ChocolateFrogsNuts
Copy link
ContributorAuthor

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

Copy link
Collaborator

@earlephilhowerearlephilhower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks!

@devytedevyte merged commit9b41d9a intoesp8266:masterApr 23, 2020
@devyte
Copy link
Collaborator

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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@earlephilhowerearlephilhowerearlephilhower approved these changes

@devytedevytedevyte approved these changes

Assignees

@devytedevyte

Projects

None yet

Milestone

2.7.0

Development

Successfully merging this pull request may close these issues.

3 participants

@ChocolateFrogsNuts@devyte@earlephilhower
[8]ページ先頭
©2009-2025 Movatter.jp