Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ webgui flashing ] #93

Open
0xd3d0c3d opened this issue Jul 5, 2019 · 6 comments
Open

[ webgui flashing ] #93

0xd3d0c3d opened this issue Jul 5, 2019 · 6 comments
Labels

Comments

@0xd3d0c3d
Copy link
Contributor

0xd3d0c3d commented Jul 5, 2019

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 ]

  • new esp82xx uses 0x00000 0x10000 fw bins, so i adjusted all 0x40000 references to 0x10000
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 ]

  • from webgui flash this same page.mpfs then dump it for a difference

[ dump ]

  • extracting reflashed page.mpfs from dump
esptool.py read_flash 0x00000 0x100000 dump.bin
dd if=dump.bin of=mpfs.bin bs=1 skip=532480 count=329216

[ compare page.mpfs versus mpfs.bin extraction ]

  • diff mpfs.bin page.mpfs
  • Binary files mpfs.bin and page.mpfs differ

[ visually compare the differences ]

  • vimdiff mpfs.bin page.mpfs

[ switch visual modes ]

  • :%!hexdump -C
  • ctrl + l
  • :%!hexdump -C

[ 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
Copy link
Contributor Author

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

care to make a pull request?

@0xd3d0c3d
Copy link
Contributor Author

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

@con-f-use
Copy link
Collaborator

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
Copy link
Contributor Author

0xd3d0c3d commented Jul 8, 2019

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

  • all instances of 0x40000 in menuinterface.js should be replaced with 0x10000, pointless otherwise.

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
Copy link
Contributor Author

here's the pull request, again thank you for this code. :)
#94

@con-f-use con-f-use added the bug label Jul 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants