Funny, again we're thinking alike! Did that ... but no joy. Wondering now, do I need to "zero out" (0xFF) the unused portion of that 192kB. Hmmm. Will try that, as dd built me the file, flashed it, but still won't boot (i.e. no serial output at all).
Pulling my hair out again ... . OK, flashrom is a bit of a PITA - even to program a section, you have to have a full sized file. NP, here is what I did - yell if you see anything wrong!
dd if=/dev/zero bs=8M count=1 | tr "\000" "\377" > u-boot.full.bin
hexdump -C u-boot.full.bin
=> yep, file is 8M, all 0xFF
dd if=u-boot.bin of=u-boot.full.bin conv=notrunc
=> bootloader at the start of the file
flashrom -l rom.layout -i u-boot -w u-boot.full.bin -p linux_spi:dev=/dev/spidev0.0,spispeed=2000
So this has only the bootloader, but won't boot ... no serial, no LED's (normal sequence I mean), no ethernet. Wondering if it needs the u-boot-env or config perhaps?
So tried replacing u-boot (only) in the HooToo image => still no joy (and no serial, no LED's like expected, no ethernet). Dang it! And no luck finding a flash image for the RAVPower (like I have for the HooToo).
@arrmo I don't want to be "that guy" but I am anyway
do a full backup of flash for every device you work on. It can be done through LuCI on an initramfs.bin. I've done it over serial and TFTP on OEM image too.
BTW if you hate flashrom yet, feel free to install Adafruit Blinka and try my scripts. It should be an easy edit to get it working on RPi
OK, the RAVPower is back up and running ... sort of . I stumbled on to it, but it seems that during that "large" erase, something got broken. If I leave the flash programmer connected, then it will boot. It seems to me like the power supply went, and that gets provided by the flash programmer. So a bit of a fragile setup, but I will try to continue now. And FYI, the bootloader does seem to have a (subtle?) difference ... the address in the rows below is different in the two cases,
If you have some backup then you could flash it! Bootloader is there. How about Config and Factory OEM partitions? In case you don't have a WD-03 backup, then you could try from your HooToo TM-05 backup!
Did you try flashing kernel.bin and rootfs.bin through TFTP recovery from your PR?
Yep, exactly what I did! HooToo flash (from the vendor), and then replaced the bootloader. No joy, lots of errors (trying to boot OEM), like the following,
[ 19.576000] SQUASHFS error: Unable to read data cache entry [1c6b18]
[ 19.588000] SQUASHFS error: Unable to read page, block 1c6b18, size 9ae8
[ 19.604000] SQUASHFS error: Unable to read data cache entry [1c6b18]
[ 19.616000] SQUASHFS error: Unable to read page, block 1c6b18, size 9ae8
Yep, that was my next step - we're on the same page! LOL. But getting,
[ 0.736420] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 0.751398] Please append a correct "root=" boot option; here are the available partitions:
[ 0.768050] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.785388] Rebooting in 1 seconds..
And if I boot from initramfs, /proc/mtd is completely empty
For the concatenated firmware address you have to calculate the real address.
For example, the rootfs starts at 0x00000019910c inside firmware which starts at 0x000000200000 on the flash => are there anything interesting at 0x00000039910c on the flash?
[ 5.547840] spi spi0.0: force spi mode3
[ 5.556282] m25p80 spi0.0: unrecognized JEDEC id bytes: 90, 40, 3f
[ 5.568683] m25p80: probe of spi0.0 failed with error -2
Definitely some flash and power supply issues. I do see that powering off during erase (like I did) can have "undesirable side effects". Think I found that. Will keep trying though!
Does your (or @mpratt14's) flash programming tool detect the chip?
And what is it's JEDEC id bytes? OpenWrt reads it correctly?
If you are unable to set back the JEDEC id bytes to c8, 40, 17, then you could add a temporary patch like target/linux/ramips/patches-*/302-spi-nor-add-gd25q512.patch to add a gd25q64-arrmo named flash with the current id (0x90403f)!
To create the patch above, you could try the following:
build the image first
check build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux*/drivers/mtd/spi-nor/spi-nor.c for all the patches got applied
copy spi-nor.c to spi-nor-arrmo.c
add the new lines for chip support in your copy
diff -U8 spi-nor.c spi-nor-arrmo.c
create your 999-spi-nor-add-gd25q64-arrmo.patch file in target/linux/ramips/patches-*/ directories
Appreciate the pointers! The issue was (is) hardware related - seems the on board 3V supply is dead. Could be due to a lot of different things - board in and out of the case (pried open, had to fully remove the board to get the flash clip on - no room in the case, bad design! ), open board with wires everywhere, etc. But when I provide an external 3V supply, to the board - I seem to be back up and running ... and booting OpenWrt!
Let me see if I can get back to the changes now - fighting with git, and harmonizing / combining the dts files.
OK, code updated, common dtsi (almost the entire file!), built and tested on RAVPower WD-03, and also checked on the HooToo (given dts changes). All seems to be working. Commit here,
I do need to check the MAC addresses yet, that's the only non-common thing left I think. Anything else you can think of to do on this?
. OK, flashrom is a bit of a PITA - even to program a section, you have to have a full sized file. NP, here is what I did - yell if you see anything wrong!
. Thanks!
. I stumbled on to it, but it seems that during that "large" erase, something got broken. If I leave the flash programmer connected, then it will boot. It seems to me like the power supply went, and that gets provided by the flash programmer. So a bit of a fragile setup, but I will try to continue now. And FYI, the bootloader does seem to have a (subtle?) difference ... the address in the rows below is different in the two cases,
to