Open 0xd3d0c3d opened 5 years ago
i bypassed the issue with this code
function tohex8( c )
{
var hex = c.toString(16);
return hex.length == 1 ? "0" + hex : hex;
}
window.onload = function() {
document.querySelector('input').addEventListener('change', function() {
var reader2 = new FileReader();
reader2.onload = function() {
var arrayBuffer = this.result,
array = new Uint8Array(arrayBuffer),
binaryString = String.fromCharCode.apply(null, array);
var mpfs = 532480;
var sectors = Math.ceil(binaryString.length / 4096);
var si = 0;
var sector = mpfs / 4096;
for (si = 0; si <= sectors; si++) {
cmd = "FE" + sector;
console.log(cmd);
sector += 1;
QueueOperation(cmd);
}
var rotations = binaryString.length / 256;
var ri = 0;
var bi = 0;
var patch = "";
for (ri = 0; ri < rotations; ri++) {
patch="";
console.log("rotation: " + (ri+1) + "/" + rotations)
for (bi = 0; bi < 256; bi++) {
bp = ri * 256;
patch += tohex8(binaryString.charCodeAt(bp+bi)).toUpperCase();
}
cmd = "FX" + mpfs + "\t256\t" + patch;
QueueOperation(cmd);
mpfs += 256;
}
}
reader2.readAsArrayBuffer(this.files[0]);
}, false);
}
care to make a pull request?
give me a few days and i'll rewrite it into the format you guys already had written.
That would be great. If it helps, there is a CHIP
variable in user.cfg
that gets passed down to other makefiles and is either 8266
or 8285
.
the problem is the line
if( ( pushop.place % flash_blocksize ) == 0 && flashresponse[1] != 'B' )
{
QueueOperation( "FB" + ((pushop.place+pushop.base_address)/flash_blocksize), function( x, y ) { ContinueSystemFlash( x, y, pushop ); } );
}
this works fine for image.elf-0x00000.bin, or image.elf-0x10000.bin because they align to 65536 evenly.
0x00000 = 0, 0 / 65536 0x10000 = 65536, 65536 / 65536
no problem.
0x82000 = 532480 using 532480 does not divide evenly nor align properly
532480 / 65536 8.125
sending 'FB8.125' still works, but ideally it should be 'FB8', that .125 is equal to 8192 bytes.
so the order operations is as follows.
first pass.
pushop.place = 0 pushop.base_address = 532480 flash_blocksize = 65536
erase sector 8 or 8.125 in this case.
65536 8 = 524288
524288 + 65536 = 589824
from 524288 to 589824 are ff'd, which is fine here..
data from 0x0000 to 0xFFFF is written, 65536 blocks..
when the pushop.place = 65536 the next sector is erased, herein lies the problem
532480 + 65536 = 598016
we wrote bytes from 532480 to 598016 and relied on a counter to 65536,
because the alignment is wrong when we go to erase sector 9 we are clipping 8192 bytes.
65536 9 = 589824
598016 - 589824 = 8192
the data was actually written on the first pass, but it was erased on the second pass. ];>
i cheated and realigned things..
i changed
#define USER_SETTINGS_SIZE 0x3000
to
#define USER_SETTINGS_SIZE 0x1000
this gives back 8192 bytes, and evenly aligns things.
i changed
MFS_PAGE_OFFSET = 532480
to
MFS_PAGE_OFFSET = 524288
this compensates for the realignment in spi_memory_addrs.h
i changed
var mpfs_start_at = 65536;
var flash_scratchpad_at = 524288;
to
var mpfs_start_at = 524288;
var flash_scratchpad_at = 655360;
also
if( ( pushop.place % flash_blocksize ) == 0 && flashresponse[1] != 'B' )
{
QueueOperation( "FB" + ((pushop.place+pushop.base_address)/flash_blocksize), function( x, y ) { ContinueSystemFlash( x, y, pushop ); } );
}
to
if( ( pushop.place % flash_blocksize ) == 0 && flashresponse[1] != 'B' )
{
QueueOperation( "FB" + Math.floor((pushop.place+pushop.base_address)/flash_blocksize), function( x, y ) { ContinueSystemFlash( x, y, pushop ); } );
}
also
this keeps all the code written pretty much the same, it's updated to new esp82xx. you can flash
firmware bins via wabgui now no problem, you can flash page.mpfs via webgui no problem. if you
flash firmware bins via webgui it doesn't overwrite page.mpfs and vice versa. if i were to adjust
the code, the only difference would be to make a boolean on the pushop to differentiate in the
ContinueSystemFlash function to realize it's dealing with page.mpfs, and if so compensate for
the 8192 byte offset differntial when dividing. anyways, its your code but i saw something i could
fix.. thank you for you work.
dr1p@ansibomb:~/esp8266/decoded$ MPFS_ADDR=524288
dr1p@ansibomb:~/esp8266/decoded$ MPFS_SIZE=$(wc -c web/page.mpfs|cut -c1-7)
dr1p@ansibomb:~/esp8266/decoded$ esptool.py read_flash 0x00000 0x100000 dump.bin
esptool.py v1.2
Connecting...
Running Cesanta flasher stub...
Reading 1048576 @ 0x0... 1048576 (100 %)
Read 1048576 bytes at 0x0 in 102.1 seconds (82.2 kbit/s)...
dr1p@ansibomb:~/esp8266/decoded$ dd if=dump.bin of=mpfs.bin bs=1 skip=$MPFS_ADDR count=$MPFS_SIZE
111872+0 records in
111872+0 records out
111872 bytes (112 kB, 109 KiB) copied, 0.196634 s, 569 kB/s
dr1p@ansibomb:~/esp8266/decoded$ diff mpfs.bin web/page.mpfs
dr1p@ansibomb:~/esp8266/decoded$
here's the pull request, again thank you for this code. :) https://github.com/cnlohr/esp82xx/pull/94
new esp82xx flashing via webgui is nice, i had to make some changes a bit to work on 8285. i adjusted menuinterface.js to reflect 0x10000 rather than 0x40000 instances. i adjusted mpfs_start_at location because it is in different spot, you'll get file not found flashing page.mpfs otherwise. i also had to move the scratchpad location because if you flash bin pairs it will overwrite the page.mpfs and then you're left with no webgui unless you flash via esptool. this at least leaves the webgui ;p.. so firmware flashing is working gr8, even webgui flashing page.mpfs is great.. the issue is if you exceed 60k filesize. it will be missing data. every 65536 - 4096 x 2 will be 0xFF'd. :*[ i guess my question is without using esptool.py to flash page.mpfs, is there way around this boundary via webgui? is there a way to use a pointer system to the missing chunks if there is a boundary? im not 100% sure how to tackle this. i used a 390k page.mpfs as an example, the real page.mpfs size im using is 109k or 80k.. either are still above 60k.
esp8285 - 1048576
[ user.cfg ]
[ menuinterface.js ]
[ page.mpfs ]
[ flash ]
[ reflash ]
[ dump ]
[ compare page.mpfs versus mpfs.bin extraction ]
[ visually compare the differences ]
[ switch visual modes ]
[ analyze differences ]