ESP8266 Community Forum

- Tue May 12, 2015 3:08 am #17217 I did some work on my side, but it ain't working yet. I thought I'd write up what I have so far in case it helps someone else. No diff to share yet (my Makefile has diverged too far, I'll have to backport).

What I'm trying to do is:

- create a user1.bin and user2.bin as defined by espressif to allow the std boot_v1.2 from espressif to be used to switch between two 256KB images
- each image contains the code and the espfs
- optionally the espfs in each image is located at the end of the image and 4KB aligned so it can be updated in-place to allow for rapid dev&test of web pages
- add an http cgi to allow user1.bin or user2.bin to be uploaded followed by a reboot into the new version using the relatively new SDK OTA functions

I successfully managed to add the espfs data to the end of the irom0 text segment such that there is a single chunk to flash. The way I did it is as follows.

In the Makefile I create an elf .o file from the binary espfs image using objcopy:

Code: Select all        $(Q) cd html; find | ../espfs/mkespfsimage/mkespfsimage > ../build/espfs.img; cd ..
endif
        $(Q) cd build; $(OC) -I binary -O elf32-xtensa-le -B xtensa --rename-section .data=.espfs espfs.img espfs_img.o; cd ..


Where $(OC) is the xtensa objcopy binary.

I then added build/espfs_img.o to the list of required objects:

Code: Select allOBJ             := $(patsubst %.c,$(BUILD_BASE)/%.o,$(SRC)) build/espfs_img.o


In order to append this thing to the end of irom0 I modified the linker file eagle.app.v6.new.512.app1.ld by changing the irom0 definition near the end of the file:

Code: Select all  .irom0.text : ALIGN(4)
  {
    _irom0_text_start = ABSOLUTE(.);
    *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text)
    . = ALIGN (4096);
    *(.espfs)
    _irom0_text_end = ABSOLUTE(.);
  } >irom0_0_seg :irom0_0_phdr


What that does is to pull the .espfs section generated by the objcopy in as last piece of .irom0.text with an alignment of 4KB (the flash sector size). The purpose of putting this at the end with this alignment is to allow it to be updated (reflashed) without updating the code itself to allow for fast changes to the web pages. This may not be necessary, in which case the whole .espfs section game is unnecessary.

In the code I can get the address of the espfs start as follows:

Code: Select allextern void *_binary_espfs_img_start;
...
        os_printf("\nESPFS @0x%08x\n", (unsigned int)_binary_espfs_img_start);


Where I'm stuck now is at actually booting the user1.bin that I generate. I'm using the open-source esptool.py and I'm concluding that it can't generate the format required for user1.bin. The Espressif SDK's pretty horrible gen_appbin.py has a special boot_mode argument the equivalent of which esptool.py doesn't have. So I'll have to change my Makefile over. But right now it's time to stop for the day...

- Wed May 13, 2015 12:49 am #17286 Attached is a first patch that changes mostly the Makefile to produce a single flash blob instead of the current irom and a separate espfs. This limits the size and I've removed two of the cat images from the image (sorry). This patch is not particularly useful in itself but a first step for the OTA upgrade to produce a user1.bin and a user2.bin that the standard espressif OTA bootloader can work with. For me the smaller espfs size is OK (I'm not planning to serve-up images). For folks that need larger espfs perhaps using a module with more than 512KB is the best answer. Alternatively someone can implement the two-stage flashing scheme I described earlier. I hope to follow this patch soon with the next one which switches from the old-version flash format to the new one that the OTA stuff uses.
If this is going in the wrong direction lemme know so I don't waste my time backporting the changes to the mainline

You do not have the required permissions to view the files attached to this post.

- Wed May 13, 2015 2:53 am #17292 Attached is a second patch that produces a user1.bin and a user2.bin suitable for OTA flashing. I've tested that user1.bin works when flashed via serial. The Makefile assumes a 512KB flash like most of the esp8266 modules have. Also, I've used the boot_v1.3(b3) bootloader that is in the 1.0.0 SDK and I've used that SDK to compile against.

In order to try this thing out: flash the bootloader to 0x00000, flash blank.bin to 0x7E000, flash firmware/user1.bin to 0x01000.

Left to do (another day): add the http cgi to allow uploading of the next bin and call the espressif sdk functions to tell it which version to boot next.

NB: thanks to prozac for his OTA flash version, I copied and pasted stuff from his branch.

You do not have the required permissions to view the files attached to this post.

- Wed May 13, 2015 12:55 pm #17316 Another (small) patch: I backed-out the 4KB alignment of the espfs. Turns out that when gen_appbin.py creates the user1.bin/user2.bin images it puts irom first. That means that the espfs at the end of irom is followed by other stuff and can't simply be reflashed 'cause any size increase would clobber what comes afterwards.
I currently have one of the cat images (36KB) in the .bin and I'm 4KB away from filling the size available. I'll probably replace the image with a smaller one... Overall I'm thinking that the best way to proceed is probably to keep the current espfs in the main image and then to add a second espfs into the other flash partition and mount that somewhere in the URL tree. This way for apps that don't need much espfs it's a simple 1 partition deal whereas apps that need large cat pictures there's some extra work to update both partitions. If done right, after updating the first partition the critical functions can work correctly such that reflashing the other partition can happen after verifying that the first one works. Overall I expect that a year from now larger flash modules will be pretty std on the esp and this issue kind'a goes away.

You do not have the required permissions to view the files attached to this post.