cnlohr / esp82xx

Useful ESP8266 C Environment
Other
288 stars 107 forks source link

[ webgui flashing ] #93

Open 0xd3d0c3d opened 5 years ago

0xd3d0c3d commented 5 years ago

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 ]

MFS_PAGE_OFFSET  = 532480

[ menuinterface.js ]

var mpfs_start_at = 532480; // 65536;
var flash_scratchpad_at = 655360; // 524288;

[ page.mpfs ]

make clean page.mpfs # 512 328704
wc -c page.mpfs # 329216 page.mpfs

[ flash ]

esptool.py -b 115200 --port /dev/ttyUSB0 write_flash --erase-all -fs 1MB -fm dout 0xfc000 esp82xx/toolchain/esp_nonos_sdk/bin/esp_init_data_default_v08.bin 0x00000 image.elf-0x00000.bin 0x10000 image.elf-0x10000.bin 532480 web/page.mpfs

[ reflash ]

[ dump ]

[ compare page.mpfs versus mpfs.bin extraction ]

[ visually compare the differences ]

[ switch visual modes ]

[ analyze differences ]

    >>> MPFS_FILE_SIZE=329216
    >>> offset1 = [ "0000e000", "57344" ]
    >>> hex(65536 * 1)
    '0x10000'
    >>> offset2 = [ "0001e000", "122880" ]
    >>> hex(65536 * 2)
    '0x20000'
    >>> offset3 = [ "0002e000", "188416" ]
    >>> hex(65536 * 3)
    '0x30000'
    >>> offset4 = [ "0003e000", "253952" ]
    >>> hex(65536 * 4)
    '0x40000'
    >>> offset5 = [ "0004e000", "319488" ]
    >>> hex(65536 * 5)
    '0x50000'
    >>> 57344 + 4096*2
    65536
    >>> 122880 + 4096*2
    131072
    >>> 188416 + 4096*2
    196608
    >>> 253952 + 4096*2
    262144
    >>> 319488 + 4096*2
    327680
    >>> hex(65536)
    '0x10000'
    >>> hex(131072)
    '0x20000'
    >>> hex(196608)
    '0x30000'
    >>> hex(262144)
    '0x40000'
    >>> hex(327680)
    '0x50000'

Screenshot from 2019-07-05 08-28-02 Screenshot from 2019-07-05 08-29-06

0xd3d0c3d commented 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);
}
con-f-use commented 5 years ago

care to make a pull request?

0xd3d0c3d commented 5 years ago

give me a few days and i'll rewrite it into the format you guys already had written.

con-f-use commented 5 years ago

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.

0xd3d0c3d commented 5 years ago

code

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

esp82xx/include/spi_memory_addrs.h

i changed #define USER_SETTINGS_SIZE 0x3000 to #define USER_SETTINGS_SIZE 0x1000

this gives back 8192 bytes, and evenly aligns things.

user.cfg

i changed MFS_PAGE_OFFSET = 532480 to MFS_PAGE_OFFSET = 524288

this compensates for the realignment in spi_memory_addrs.h

web/page/menuinterface.js

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$ 
0xd3d0c3d commented 5 years ago

here's the pull request, again thank you for this code. :) https://github.com/cnlohr/esp82xx/pull/94