newbie here :) still no output on the serial ports on dumped firmware

[aguaviva]

This is awesome!

I got a DLINK wireless camera that recently DLINK decided to brick by turning off some cloud services. (https://support.dlink.com/resource/PRODUCTS/DCS-5030L/REVA/DCS-5030L_END_OF_SUPPORT_NOTICE.pdf) I am determined to bring back to life as it is a terrible thing to dispose something that works! :)

I dumped the 8MB SPI flash and I modified the source so it takes a 8MB spi_flash

+++ b/hw/mips/mt7628.c
@@ -146,7 +146,7 @@ static void mt7628_realize(DeviceState *dev, Error **errp)
     DeviceState *spi_flash;
     qemu_irq cs_line;
     if (dinfo) {
-        spi_flash = qdev_new("w25q128");
+        spi_flash = qdev_new("w25q64");
         qdev_prop_set_drive(spi_flash, "drive", blk_by_legacy_dinfo(dinfo));
         qdev_realize_and_unref(spi_flash, BUS(spi_bus->spi), &error_fatal);
         cs_line = qdev_get_gpio_in_named(spi_flash, SSI_GPIO_CS, 0);

and used it as you explain

./qemu/qemu-system-mipsel -M mt7628 \
                           -serial telnet:localhost:4000,server \
                           -serial telnet:localhost:4001,server \
                           -serial telnet:localhost:4002,server \
                           -drive if=mtd,file=flash_8M.bin,type=raw \
                           -usb

but I have been waiting 10 minutes or so for something to come out from the serial ports... How could I debug this?

just in case this is the output of binwalk

$ binwalk -Me camera.bin 

Scan Time:     2023-06-11 19:45:24
Target File:  ./camera.bin
MD5 Checksum:  338c1984011086f0ff89c42cd8ff6c85
Signatures:    411

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
82864         0x143B0         U-Boot version string, "U-Boot 1.1.3"
97088         0x17B40         HTML document header
97434         0x17C9A         HTML document footer
97444         0x17CA4         HTML document header
97636         0x17D64         HTML document footer
97804         0x17E0C         HTML document header
98497         0x180C1         HTML document footer
212333        0x33D6D         PEM certificate
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x734FFBB2, created: 2019-01-21 02:47:29, image size: 7734984 bytes, Data Address: 0x80000000, Entry Point: 0x8000C150, data CRC: 0xF23E7F4, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744        0x50040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 10523552 bytes

Thanks for this, I am having a lot of fun with it!

[aguaviva]

Hi, I am still trying and I feel I am very close :) do I need to compile bootrom and use it somehow?

[aguaviva]

Just documenting my steps in case this helps others...

I compiled bootrom (it was not easy to find a working compiler for it), I renamed it to mt7628.bootrom as it seems to be referenced this way by the source code, and I am hoping this way it will be picked up by qemu, still no luck.

[aguaviva]

Santa Madonna I made it work!!!

I ran it like this:

/home/raul/repos/qemu/build/qemu-system-mipsel -M mt7628 -nographic  -serial file:ser1.txt -serial file:ser2.txt                            -serial file:ser3.txt -drive if=mtd,file=camara.bin,format=raw  --trace "memory_region_ops_*"

Then noticed qemu was running the same instructions over and over, it is the damn calibration loop. I disassembled it and using hexedit I patched the jump with 0x00000000, I ran it again and then I got the u-boot output. Patching this was compulsory, otherwise it will never boot (as opposed to taking a long time as the author claimed)