Sming
Sming copied to clipboard
rBoot OTA and firmware filesystem
Hi all. New to Sming, I'm trying to enable OTA for a 1MB ESP8266 (ESP-03). Started from Basic_rBoot example, customized the HWCONFIG and set parameter for RBOOT_TWO_ROMS in component.mk.
Rom OTA is now working fine (to be honest I had to change Rom1 start address to 0x082000 as with 0x080000 the second rom was always corrupted), so I added the OTA update for an FWFS partition (next step is to create an Hybrid FileSystem).
As said, ROM OTA is working fine but, FWFS OTA get the partition corrupted and the mount fails. So, at first boot after flashing I stain this printout:
********************************************************
Hello
133698 Found 'fwfs0v1' at 0x0f0000, length 0x010000
133845 Trying to mount 'fwfs0v1' at 0x000f0000, length 0x00010000
139392 Firmware filesystem created
143280 mount() returned 0 (Success)
145690 File system initialised
148454 =FWFS=====================
155305 - 2842 index.html
155681 - 15568 bootstrap.css
157994 - 1769 wifi-sprites.png
161639 - 971 style.css
164674 - 6252 settings.html
168058 - 0 .lastModified
171441 - 30218 jquery.js
174477 - 0 config
177353 8 file(s) found
179424 ==========================
182564
Currently running rom 1.
185670 Type 'help' and press enter for instructions.
but after giving the OTA command, this is the result:
18866876 Updating fwfs partition 'fwfs0v1' at address 0x0f0000, size 0x010000
23713835 Firmware updated, rebooting to rom 1...
state: 5 -> 0 (0)
rm 0
pm close 7
del if0
usl
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 1104, room 16
tail 0
chksum 0xe3
load 0x3ffe8000, len 572, room 8
tail 4
chksum 0xeb
csum 0xeb
rBoot v1.4.2 - [email protected]
Flash Size: 8 Mbit
Flash Mode: DIO
Flash Speed: 40 MHz
Booting rom 1 at 82000, load addr c62d0.
system param error, use last saved param!
~?
oN?䒃? ~?c
?Nn?䛂?l?bl`r?o$
rn?`ph???N?|r??n|?
?lB?
?|s?$?o??N?
d ??r?l???
???235551
********************************************************
Hello
235778 Found 'fwfs0v1' at 0x0f0000, length 0x010000
235925 Trying to mount 'fwfs0v1' at 0x000f0000, length 0x00010000
241471 Firmware filesystem created
245167 [Partition] Invalid range, address: 0x00010074, size: 0x00000008
250896 mount() returned -17 (ReadFailure)
254681
Currently running rom 1.
257822 Type 'help' and press enter for instructions.
262596 SDK: v3.0.3(8427744)
265108 Free Heap: 50832
267276 CPU Frequency: 80 MHz
269876 System Chip ID: 3cb1b4
272571 SPI Flash ID: 1640ef
275101 SPI Flash Size: 0x400000
278025 ROM count: 2
279766 ROM 0: 0x008000
281850 ROM 1: 0x082000
283933 Booting from ROM 1
I post my source code, hwconfig file and component.mk if someone would like to help me.
Looks like things have got a little out of sync. Try make flashboot
to reset the rBoot config to defaults. (Note: rBoot is not partition-aware, it keeps its own configuration by addres.)
If you run make map
you should get this:
Device Start End Size Type SubType Name Filename
---------------- ---------- ---------- ---------- -------- -------- ---------------- ------------
spiFlash 0x00000000 0x00001fff 8K Boot Sector
spiFlash 0x00002000 0x00002fff 4K Partition Table
spiFlash 0x00003000 0x00003fff 4K data phy phy_init $(FLASH_INIT_DATA)
spiFlash 0x00004000 0x00007fff 16K data sysparam sys_param
spiFlash 0x00008000 0x0007ffff 480K app factory rom0 $(RBOOT_ROM_0_BIN)
spiFlash 0x00080000 0x000fffff 512K app ota_0 rom1 $(RBOOT_ROM_1_BIN)
Then in the Basic_rBoot
sample type info
:
SDK: v3.0.3(8427744)
Free Heap: 50568
CPU Frequency: 80 MHz
System Chip ID: 1c2666
SPI Flash ID: 1640c8
2487700 Count: 2
2487810 ROM 0: 0x00008000
2489617 ROM 1: 0x00080000
2491959 ROM 2: 0x00000000
2494297 GPIO ROM: 0
The ROM addresses must agree (i.e. ROM2 = 0x80000
). Note: I've modified Basic_rBoot
to print the addresses in Hex to make things clearer.
@mostorer Sorry, I didnt' really answer your question! The zip file you attached doesn't work for me, I get 'Not Found' error?
Something to look at is the [Partition] Invalid range, address: 0x00010074, size: 0x00000008
error, it's trying to read past the end of the partition (which is at offset 0x10000). That suggests a corrupted partition. You can check this by reading it out again and comparing with the source binary:
make readpart PART=fwfs0v1
The file gets written to out/Esp8266/debug/fwfs0v1.read.bin
so you can open this in a graphical hex editor alongside the source image for inspection. This should give some clue as to what's happening.
Looks like things have got a little out of sync. Try
make flashboot
to reset the rBoot config to defaults. (Note: rBoot is not partition-aware, it keeps its own configuration by addres.)If you run
make map
you should get this:Device Start End Size Type SubType Name Filename ---------------- ---------- ---------- ---------- -------- -------- ---------------- ------------ spiFlash 0x00000000 0x00001fff 8K Boot Sector spiFlash 0x00002000 0x00002fff 4K Partition Table spiFlash 0x00003000 0x00003fff 4K data phy phy_init $(FLASH_INIT_DATA) spiFlash 0x00004000 0x00007fff 16K data sysparam sys_param spiFlash 0x00008000 0x0007ffff 480K app factory rom0 $(RBOOT_ROM_0_BIN) spiFlash 0x00080000 0x000fffff 512K app ota_0 rom1 $(RBOOT_ROM_1_BIN)
Then in the
Basic_rBoot
sample typeinfo
:SDK: v3.0.3(8427744) Free Heap: 50568 CPU Frequency: 80 MHz System Chip ID: 1c2666 SPI Flash ID: 1640c8 2487700 Count: 2 2487810 ROM 0: 0x00008000 2489617 ROM 1: 0x00080000 2491959 ROM 2: 0x00000000 2494297 GPIO ROM: 0
The ROM addresses must agree (i.e.
ROM2 = 0x80000
). Note: I've modifiedBasic_rBoot
to print the addresses in Hex to make things clearer.
I have made what you suggested, so the make flashboot
, firstly in Basic_rBoot example. Now I have:
Basic_rBoot: Invoking 'map' for Esp8266 (debug) architecture
Partition map:
Device Start End Size Type SubType Name Filename
---------------- ---------- ---------- ---------- -------- -------- ---------------- ------------
spiFlash 0x00000000 0x00001fff 8K Boot Sector
spiFlash 0x00002000 0x00002fff 4K Partition Table
spiFlash 0x00003000 0x00003fff 4K data phy phy_init $(FLASH_INIT_DATA)
spiFlash 0x00004000 0x00007fff 16K data sysparam sys_param
spiFlash 0x00008000 0x0007ffff 480K app factory rom0 $(RBOOT_ROM_0_BIN)
spiFlash 0x00080000 0x000fffff 512K app ota_0 rom1 $(RBOOT_ROM_1_BIN)
and info
returns:
Currently running rom 0.
Type 'help' and press enter for instructions.
mode : null
3270416 SDK: v3.0.3(8427744)
3270513 Free Heap: 50632
3270597 CPU Frequency: 80 MHz
3270670 System Chip ID: 3cb1b4
3270767 SPI Flash ID: 1640ef
3272350 SPI Flash Size: 0x400000
3275394 ROM count: 2
3277180 ROM 0: 0x00008000
3279523 ROM 1: 0x00080000
3281865 ROM 2: 0x00000000
3284208 GPIO ROM: 0x00000000
3286814 Booting from ROM 0
So, exactly as expected. Then I made the same on my test project, including FWFS. This is partitions map:
myRboot: Invoking 'map' for Esp8266 (debug) architecture
Partition map:
Device Start End Size Type SubType Name Filename
---------------- ---------- ---------- ---------- -------- -------- ---------------- ------------
spiFlash 0x00000000 0x00001fff 8K Boot Sector
spiFlash 0x00002000 0x00002fff 4K Partition Table
spiFlash 0x00003000 0x00003fff 4K data phy phy_init $(FLASH_INIT_DATA)
spiFlash 0x00004000 0x00007fff 16K data sysparam sys_param
spiFlash 0x00008000 0x00075fff 440K app factory rom0 $(RBOOT_ROM_0_BIN)
spiFlash 0x00076000 0x0007ffff 40K data spiffs spiffsOvl $(SPIFF_BIN_OUT)
spiFlash 0x00080000 0x000effff 448K app ota_0 rom1 $(RBOOT_ROM_1_BIN)
spiFlash 0x000f0000 0x000fffff 64K data fwfs fwfs0v1 $(PROJECT_DIR)/out/fwfs_rom.bin
and info
command returns:
198564 SDK: v3.0.3(8427744)
201073 Free Heap: 50832
203242 CPU Frequency: 80 MHz
205840 System Chip ID: 3cb1b4
208538 SPI Flash ID: 1640ef
211080 SPI Flash Size: 0x400000
214035 ROM count: 2
215730 ROM 0: 0x008000
217815 ROM 1: 0x080000
219897 Booting from ROM 0
So, it seems first issue has been solved.
Something to look at is the
[Partition] Invalid range, address: 0x00010074, size: 0x00000008
error, it's trying to read past the end of the partition (which is at offset 0x10000). That suggests a corrupted partition. You can check this by reading it out again and comparing with the source binary:make readpart PART=fwfs0v1
The file gets written to
out/Esp8266/debug/fwfs0v1.read.bin
so you can open this in a graphical hex editor alongside the source image for inspection. This should give some clue as to what's happening.
Yes, it seems the fwfs partition got corrupted. The strange thing is that, before when rBoot seemed to be not in synch (ROM1 at 0x082000) once flashed the partition was readable and mountable. Now that the rBoot partition table is correct, the fwfs partition is not mountable from the beginning:
198564 SDK: v3.0.3(8427744)
201073 Free Heap: 50832
203242 CPU Frequency: 80 MHz
205840 System Chip ID: 3cb1b4
208538 SPI Flash ID: 1640ef
211080 SPI Flash Size: 0x400000
214035 ROM count: 2
215730 ROM 0: 0x008000
217815 ROM 1: 0x080000
219897 Booting from ROM 0
From the first boat after flashing, I obtain the error
171776 Found 'fwfs0v1' at 0x0f0000, length 0x010000
171954 Trying to mount 'fwfs0v1' at 0x000f0000, length 0x00010000
177462 Firmware filesystem created
181241 [Partition] Invalid range, address: 0x00010074, size: 0x00000008
186872 mount() returned -17 (ReadFailure)
Just to make a double check, I have run the following commands:
make config-clean
make flashing
make flash boot
make flash
make readpart PART=fwfs0v1
then cross checked the original fwfs with the one extracted with readpart
...
myuser@IT000001316200 myRboot % ls -alR out/ | grep fwfs
-rw-r--r-- 1 myuser staff 58008 9 Mar 23:31 fwfs_rom.bin
-rw-r--r-- 1 myuser staff 65536 9 Mar 23:32 fwfs0v1.read.bin
It seems there is something strange with the fwfs partition.
diff -y <(xxd out/Esp8266/debug/fwfs0v1.read.bin) <(xxd out/fwfs_rom.bin)
files are identical till address 0x00d000.
0000cff0: e338 8a2f f7fb 551a 40f0 b45a cc9c b598 .8./..U.@. 0000cff0: e338 8a2f f7fb 551a 40f0 b45a cc9c b598 .8./..U.@.
0000d000: ffff ffff ffff ffff ffff ffff ffff ffff .......... | 0000d000: f6f6 3a55 8ce6 3bde c505 c7a1 92c4 80ff ..:U..;...
0000d010: ffff ffff ffff ffff ffff ffff ffff ffff .......... | 0000d010: 7f67 d7da dcb6 7145 ff8a 88ba 0a50 2e69 .g....qE..
then the original file contains data, while the one obtained by readpart
is full of ffff
So, is the problem the fwfs flashing ? Is the partition misaligned or something like that ?
New test done, successfully.
I have modified the partition table to have both ROMs of equal size, enlarging the fwfs partition:
{ "name": "Two ROM with Hybrid FS in 1M standard", "comment": "Should work with any Esp8266 variant", "arch": "Esp8266", "partition_table_offset": "0x2000", "devices": { "spiFlash": { "type": "flash", "size": "1M", "mode": "dio", "speed": 40 } }, "partitions": { "phy_init": { "address": "0x003000", "size": "4K", "type": "data", "subtype": "phy", "filename": "$(FLASH_INIT_DATA)" }, "sys_param": { "address": "0x004000", "size": "16K", "type": "data", "subtype": "sysparam" }, "rom0": { "address": "0x008000", "size": "440K", "type": "app", "subtype": "factory", "filename": "$(RBOOT_ROM_0_BIN)" }, "spiffsOvl": { "address": "0x076000", "size": "40K", "type": "data", "subtype": "spiffs", "filename": "$(SPIFF_BIN_OUT)", "build": { "target": "spiffsgen", "files": "$(SPIFF_FILES)" } }, "rom1": { "address": "0x080000", "size": "440K", "type": "app", "subtype": "ota_0", "filename": "$(RBOOT_ROM_1_BIN)" }, "fwfs0v1": { "address": "0x0EE000", "size": "72K", "type": "data", "subtype": "fwfs", "filename": "$(PROJECT_DIR)/out/fwfs_rom.bin", "build": { "target": "fwfs-build", "config": "map/fsimage.ini" } } } }
Now the fwfs partition is always readable and mountable, even after an OTA update. ... but why I had to change the fwfs partition size to make the things work ?
@mostorer I have been unable to reproduce the issues you describe, but would really like to get to the bottom of this as it's clearly not an ideal first experience for you! If you'd like to push your project to a github repo. I'll take a closer look.
We need to make some improvements to rBoot (and RbootHttpUpdater) as they're not aware of the partition table. Critically, that means the rBoot configuration information and the partition table can get out of sync. very easily.
The default rBoot ROM addresses are hard-coded into the boot sector. If the partition table is updated then when make flashconfig
is run the bootloader will 'restore' them to invalid settings. Rebuilding and re-flashing the boot sector is the only current remedy.
@mostorer This may be part of your problem here but doesn't explain the odd FWFS partition behaviour.
@mostorer I have been unable to reproduce the issues you describe, but would really like to get to the bottom of this as it's clearly not an ideal first experience for you! If you'd like to push your project to a github repo. I'll take a closer look.
Sure. I will do that soon.
@mostorer I have been unable to reproduce the issues you describe, but would really like to get to the bottom of this as it's clearly not an ideal first experience for you! If you'd like to push your project to a github repo. I'll take a closer look.
Sure. I will do that soon.
here it is: https://github.com/mostorer/myRboot