DGS-1210-28MP Unbrick

If like do did something wrong, like me. Putting back it online can be interresting (but warranty will be lost)
My mistake was pushing back the backup.con file, wich is not a valid image (yes it's a non sense to make un unrestorable backup but that's a classical job protect :wink:)

UART Connexion / place

Do not forget, to unplug power and wait a moment... It could be your last mistake (370W POE+ is far over what you can resist :slight_smile: )
Serial connexion is near LED and button. You have 4 PIN named J12 (possibly something else).
---I am Not allowed to put images Yet---
Why did I solder the four wire? Just in case the first one is one of the supposed RX TX GND on my version, ingeneers makes jokes.

Putty parameter

COM Port: COM 7 (may vary)
Speed (Bauds): 115200
Type: Serial
Data/parity/Stop : 8N1(default ones)
Flow Control XON/XOFF (default ones)

OpenWRT ROM

Take the kernel version
OpenWrt Firmware Selector

Firmware push

Push Stock Firmware / Backup (ineffective)

In the OpenWRT doc you have a "default" command line, DON'T DO THAT... I did it and it does nots end up nicely :slight_smile: ...
It works on most case, but ours is different.

tftpboot 0x80000000 openwrt-xxx-generic-xxx-squashfs-factory.bin
erase 0x9f020000 +0x332004
cp.b 0x80000000 0x9f020000 0x332004

the cp.b line need some precisions:

  • the third param is the image length (you get it in the tftpboot return)
  • it takes a while (for me 6 hours :open_mouth: )

You can push a file and boot on it like this:

dhcp
setenv serverip 192.168.1.25
tftpboot 0x8f000000 DGS-1210-FX-SERIES-FX-6-20-B020.hex
bootm 0x8f000000

Details:

  • dhcp: to obtain an Ip from ypur DHCP (or use setenv ipaddr 192.168.1.1)
  • setenv serverip 192.168.1.25: Means where is your TFTP server (here a simple one: tftpd64)
  • tftpboot 0x8f000000 DGS-1210-FX-SERIES-FX-6-20-B020.hex: this push the file (in your tftpd) to your switch RAM at the specified adress
  • bootm 0x8f000000: boot on the specified adress

And.... it crashed.

I have tried all .hex file (old firmware file), all .con file (new firmware file and backup made with Dlink interface) that you can found on the link in ressources at the end.

Any idea would be higly appreciate :slight_smile:

Pushing a OpenWRT (effective)

As before, but with the correct OpenWRT kernel image version (take the one before the last one... we will perform a sysupgrade after)

dhcp
setenv serverip 192.168.1.66
tftpboot 0x8f000000 openwrt-23.05.2-realtek-rtl838x-d-link_dgs-1210-28mp-f-initramfs-kernel.bin
bootm 0x8f000000

After this, your OpenWRT does not fill really good and ask you a sysupgrade, but it boot.
You have to push last sys upgrade version.
And there it boot alone correctly (or near) on openWRT.

Questions

Arrived there, you probably wonder, but where is the question...

  • Does anyone knows how to flash a stock Firmware on this DGS-1210-28MP (or DGS-1210 * Fx rev)?

Why: This unit has 2 kernel slot, I would like have the hability to boot back on stock firmware because some function does not work: standart POE for example, I will made a topics on this, but I don't have finish testing some solution.

  • Does anyone has a the normal boot text (like the one below, but without any trouble (on stock or OpenWRT Rom)?

The idea is to get normal load adress' / Entry Point, and perhaps a flashable backup :slight_smile: I supposed they are 0xb4100000 and 0xb4e80000. But flashing Firmware on guessed addresses is not a good idea, I prefer to verify them before.

Ressources

Hex Firmware here:https://ftp.dlink.ru/pub/Switch/DGS-1210-28MP/Firmware/
Con Firmware here: https://support.dlink.com/resource/products/DGS-1210-SERIES/REVF/FIRMWARE/v6.30.016/
SRC Code sources: https://tsd.dlink.com.tw/

PS: excuse my english, I speak python usualy :slight_smile:

You can easily spot the pinout on this model: GND is the one hole that looks different, it has four spokes connected to the ground plane. Rx and Tx are the two with traces leading to them. And then you can just try which one is Rx and which one is Tx - I did that just yesterday.

Flow Control should be off.

The hex files contain a header that is read by the stock firmware for flashing. It cannot be booted, unless the image is modified. Basically, you will have to reverse the procedure that is used to create a stock-flashable factory image.

If you strip the first 0x40 bytes (that is the cameo header), it might or might not work - I never tried it, I just compared the factory image with the sysupgrade image. If you have serial access, flashing it via sysupgrade -f from OpenWrt would be the safest option (at least safer than flashing from U-Boot).

If there is a stock firmware in the second slot, you can just boot from it using U-Boot (OpenWrt never touches image2). The following is untested, but it should work:

setenv image /dev/mtdblock7
setenv bootcmd run addargs ; bootm 0xb4e80000
bootm

This is temporary, it will boot from the second slot just once without saving the new boot configuration. Run saveenv if you want it saved permanently.

What doesn't work about PoE? It's working fine on my mine if configured properly.

Your timing is a bit unfortunate: I put mine back into service just yesterday, after adding support for fan control. I can't disassemble it for quite some time now to test all of the above.

1 Like

Thanks, I just don't have a flashable stock firmware, all available on DLink websites does not boot.

I don't who if the second part has a stock rom any more, i perform a lot of flashing...
I tried to copy this memory part to TFTP:

tftpput 0xb4e80000 C56EAC 192.168.1.10:Stock.bin

but tftpput is unknown (too old U-boot)
C56EAC = 12 938 924, is the size of what "save a backup" gave me on stock rom

For POE I found the solution (most post I found, try editing /etc/config/poe whereas you have to use uci.
I was also doing my tests on lan1 to lan 4... which are not port 1-4 :slight_smile:

#!/bin/sh
# Scriptlet to populate /etc/config/poe based on available lanX port naming.
# Drawback: SFP ports are included too if they are named lanX.
# Source: https://forum.openwrt.org/t/bringing-support-for-realtek-poe-to-mainline-openwrt/127777/74


for _PORT in $(uci get network.lan_vlan.ports)
do
    uci add poe port
    uci set poe.@port[-1].enable='1'
    uci set poe.@port[-1].id="${_PORT/lan/}"
    uci set poe.@port[-1].name="$_PORT"
    uci set poe.@port[-1].poe_plus='1'
    uci set poe.@port[-1].priority='2'
done

uci commit poe
/etc/init.d/poe restart
ubus call poe info

(just to help other, if they need photos)
PIN places

Closeup

Some other picture (in case it could be usefull for someone):

When it does not start

When TFTP the file (to get the file size in hex)

Rom_Copy

Now Booting

As already mentioned, you have to strip the header, then it should work (untested).

No, you don't have to use UCI, just edit the file. UCI is just an interface to edit the files :wink:

Yes, that is known, expected and documented here.

Sorry my brain screwed up.
And twice time because I also tried 40 bytes (and 64, and 106 and 128... juste in case)

Based on this documentation .con file are "encrypted" and hex are not. I tried on both (con and hex)

  • DGS-1210-FX-SERIES-FX-6-20-B020.hex (last hex update file, before 6.30 in two part)
  • DGS-1210-FX-SERIES-FX-6-30-016-FIRST.hex (it's a two step update, first file hex, then a second .con)
  • MyBackup.con

The hex file look like this (the 1 is 64 bytes)

Code used to remove 64 bytes (I also tried manual editing in notepad++)

$RomFile = "C:\Users\Physa\Downloads\DLink\firmware.con"
$FlashableFile64 = "C:\Users\Physa\Downloads\DLink\FlashableFirmware64.con"
write-Host "Loading File: $RomFile"
$content = Get-Content -LiteralPath $RomFile -Encoding byte
write-Host "Strip 64 bytes"
$content = $content[64..($content.Length - 1)]
write-Host "Writing File: $FlashableFile64"
Set-Content -LiteralPath $FlashableFile64 -Value (([char[]]$content) -join "")

After having striped 64 bytes. I flashed by openwrt sysupgrade (and uboot).

they both gave me this strange output, and a brutal reboot

Well I have a running OpenWRT, it still great and has more functions than stock Firmware :slight_smile:

I do not have Windows, so I have no idea what you tried. Stripping the first 0x40 bytes on Linux is as simple as:

dd if=romfile.hex of=stripped.hex bs=64 skip=1

At least, it correctly detected the kernel image and load size, so it's not completely wrong.

yes that gave the same file hash.
And it aloso detect a correct kernel when I strip less than 64 (I tried 40). But more does not do that.

If I run binwalk on it (without 64 deleted) i get:

binwalk DGS-1210-FX-SERIES-FX-6-20-B020.hex

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
128           0x80            gzip compressed data, maximum compression, has original file name: "vmlinux_org.bin", from Unix, last modified: 2021-09-17 01:50:05
1035728       0xFCDD0         Squashfs filesystem, big endian, version 3.1, size: 10888208 bytes, 251 inodes, blocksize: 131072 bytes, created: 2021-09-17 02:02:26

but that not revelant for me...

Based on this:

binwalk DGS-1210-FX-SERIES-FX-6-30-016.hex
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
128           0x80            gzip compressed data, maximum compression, has original file name: "vmlinux_org.bin", from Unix, last modified: 2021-08-24 09:43:03

1035728       0xFCDD0         Squashfs filesystem, big endian, version 3.1, size: 11735745 bytes, 338 inodes, blocksize: 131072 bytes, created: 2021-08-24 09:47:36

I extracted the two file system with:

dd if=DGS-1210-FX-SERIES-FX-6-30-016.hex of=MTD7.hex bs=16 skip=8 count=64725
dd if=DGS-1210-FX-SERIES-FX-6-30-016.hex of=MTD9.hex bs=8 skip=129466
binwalk MTD7.hex
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             gzip compressed data, maximum compression, has original file name: "vmlinux_org.bin", from Unix, last modified: 2021-08-24 09:43:03
binwalk MTD9.hex
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Squashfs filesystem, big endian, version 3.1, size: 11735745 bytes, 338 inodes, blocksize: 131072 bytes, created: 2021-08-24 09:47:36

those file really look like MTD7 and MTD9. (size and function)

But how to push them in my switch mtd7 and mtd9...
They are not mounted in OpenWRT:

root@DGS-1210-28MP:~# mount
/dev/root on /rom type squashfs (ro,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock6 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)

root@DGS-1210-28MP:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00010000 "u-boot"
mtd1: 00040000 00010000 "u-boot-env"
mtd2: 00040000 00010000 "board-name"
mtd3: 00d80000 00010000 "firmware"
mtd4: 00320000 00010000 "kernel"
mtd5: 00a60000 00010000 "rootfs"
mtd6: 007b0000 00010000 "rootfs_data"
mtd7: 00180000 00010000 "kernel2"
mtd8: 00040000 00010000 "sysinfo"
mtd9: 00c00000 00010000 "rootfs2"
mtd10: 003c0000 00010000 "jffs2"

Can I run this ? it's quite brutal but i did not found another way

dd if=MTD7.hex | ssh root@192.168.1.251 "dd of=/dev/mtd7"
dd if=MTD9.hex | ssh root@192.168.1.251 "dd of=/dev/mtd9"

I'm sure there is a TFTP way.... but i could not find it

On a side note, you shouldn't have 4 wires connected to the PCB.

yes +3.3V is not usefull

Now it does not boot even if I follow this

u-boot># dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.1.129
u-boot># tftpboot 0x8f000000 192.168.1.66:openwrt-23.05.2-realtek-rtl838x-d-link_dgs-1210-28mp-f-initramfs-kernel.bin
Using rtl8380#0 device
TFTP from server 192.168.1.66; our IP address is 192.168.1.129
Filename 'openwrt-23.05.2-realtek-rtl838x-d-link_dgs-1210-28mp-f-initramfs-kernel.bin'.
Load address: 0x8f000000
Loading: Got ARP REPLY, mac addr (b4:b5:2f:b1:c2:fd), ip addr (192.168.1.66)
######################################Got ARP REPLY, mac addr (50:e0:85:ff:77:24), ip addr (169.254.207.184)
###########################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ########################################################
done
Bytes transferred = 6538940 (63c6bc hex)
u-boot># iminfo

## Checking Image at 8f000000 ...
   Legacy image found
   Image Name:   MIPS OpenWrt Linux-5.15.137
   Created:      2023-11-14  13:38:11 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    6538876 Bytes = 6.2 MB
   Load Address: 80100000
   Entry Point:  80100000
   Verifying Checksum ... OK
u-boot># printenv
BID=104
Board_Version=32
Boot_Version=1.00.010
Serial_Number=xxxxxxxxxxxxxxxxx
addargs=setenv bootargs console=$(console_device),$(baudrate) mem=$(memsize) noinitrd root=$(image) rw rootfstype=squashfs
baudrate=115200
boardmodel=RTL8382M_8218B_INTPHY_8218B_8214FC_DEMO
bootargs=console=ttyS0,115200 mem=122M noinitrd root=/dev/mtdblock4 rw rootfstype=squashfs
bootcmd=run addargs; bootm 0xb4e80000
bootdelay=1
bootstop=off
console_device=ttyS0
ethact=rtl8380#0
ethaddr=00:01:02:03:04:05
fileaddr=8F000000
filesize=63C6BC
gatewayip=192.168.1.254
hw_version=F1
image=/dev/mtdblock7
ipaddr=192.168.1.129
memsize=122M
netmask=255.255.255.0
poe_chip=BCM
serverip=192.168.1.66
stderr=serial
stdin=serial
stdout=serial

Environment size: 763/1020 bytes
u-boot># bootm

Loading Runtime Image .OS:...FAILED
read: 0x0d95d5e8, calculated: 0x0977eb05FS:...FAILED!!
os_ver = 0, fs_ver = 1.........(os_ver & fs_ver) = 0OS:...FAILED
FS:...FAILED!!
os_ver = 0, fs_ver = 1.........(os_ver & fs_ver) = 0OS/FS Version:...Failed
Force port28 link up 1G

I think there something bad in my SF memory, is there a way to perform a sysupgrade without OpenWRT, or to push image from FLASH to SF manualy?

Have you read the section on Debricking using D-Link Network Assistant? See here.

Yes I tested two version (the old mentioned and the last available) 2.0.2.4 4.0.0.21
None of them see my device, whereas I see it via arp -a (its mac and adress are there)
And TFTP works....

Base boot log here here and here

We can conclude that Flash is made like this:

Place MTD Size erasesize Name
0x00000000-0x00080000 mtd0 00080000 00010000 "u-boot"
0x00080000-0x000c0000 mtd1 00040000 00010000 "u-boot-env" (1)
0x000c0000-0x00100000 mtd2 00040000 00010000 "board-name"
0x00100000-0x00e80000
(encapsulated 4 and 5)
mtd3 00d80000 00010000 "firmware"
0x00100000-0x00280000 mtd4 00320000 00010000 "kernel"
0x00280000-0x00e80000 mtd5 00a60000 00010000 "rootfs"
0x005f0000-0x00d80000 mtd6 007b0000 00010000 "rootfs_data"
0x00e80000-0x01000000 mtd7 00180000 00010000 "kernel2"
0x01000000-0x01040000 mtd8 00040000 00010000 "sysinfo"
0x01040000-0x01c40000 mtd9 00c00000 00010000 "rootfs2"
0x01c40000-0x02000000 mtd10 003c0000 00010000 "jffs2"

So we can write RawMTD save directly to flash like this:

Firmware (mtd3 Firmware = mtd4 kernel + mtd5 Rootfs)

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd3.bin
sf update 0x8f00000 100000 d80000

OR

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd4.bin
sf update 0x8f00000 100000 0x320000
tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd5.bin
sf update 0x8f00000 280000 0xa60000

Firmware 2 ( mtd4 kernel2 + mtd5 Rootfs2)

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd7.bin
sf update 0x8f00000 0xe80000 0x00180000
tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd9.bin
sf update 0x8f00000 1040000 0x00c00000

And you want both firmware equal

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd3.bin
sf update 0x8f00000 0xe80000 0xd80000

MTD6 "rootfs_data"

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd6.bin
sf update 0x8f00000 5f0000 0x7b0000

MTD10 "jffs2"

tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd10.bin
sf update 0x8f00000 0x1c40000 0x003c0000

Why not MTD0 u-boot and MTD1 u-boot-env. I'am stuck in u-boot, I will not crash my last chance to save it :slight_smile:

Test

I tried to write on MTD3:

  • stock rom (without first 0x40 bytes)
  • openwrt (kernel, factory, sysupgrade)
  • my MTD3 Save

No thing boot correctly. strange...

So i write, read back an check...
I fact 'sf write' didn't write, that why I put update on the exemple before, we have to update... It' longer but it works

u-boot># tftpboot 0x8f00000 RawMTD/DGS-1210-28MP.mtd3.bin
Using rtl8380#0 device
TFTP from server 192.168.1.66; our IP address is 192.168.1.132
Filename 'RawMTD/DGS-1210-28MP.mtd3.bin'.
Load address: 0x8f00000
Loading: Got ARP REPLY, mac addr (b4:b5:2f:b1:c2:fd), ip addr (192.168.1.66)
#################################################################
         #######################################################
done
Bytes transferred = 14155776 (d80000 hex)
u-boot># iminfo 0x8f00000

## Checking Image at 08f00000 ...
   Legacy image found
   Image Name:   OpenWrt
   Created:      2024-03-22  22:09:42 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    3236735 Bytes = 3.1 MB
   Load Address: 80100000
   Entry Point:  80100000
   Verifying Checksum ... OK

u-boot># md 08f00000
08f00000: 27051956 ffffffff 65fe01a6 0031637f    '..V....e....1c.
08f00010: 80100000 80100000 bff89088 05050201    ................
08f00020: 4f70656e 57727400 00000000 43414d45    OpenWrt.....CAME
08f00030: 4f544147 00000001 000010c1 80905a19    OTAG..........Z.
08f00040: 1f8b0800 00000000 02ffec7d 7d7c1c57    ...........}}|.W
08f00050: 79eebbb3 b3d2da5e ac91b456 16478946    y......^...V.G.F
08f00060: d68cb4a9 05ac1d83 55d83693 95ec3821    ........U.6...8!
08f00070: 80933a25 5ff4ee95 e460d350 9c105a97    ..:%_....`.P..Z.
08f00080: 08b395e4 209a8d46 37b88d49 dcb29525    .... ..F7..I...%
08f00090: dbd0b5d6 b40ab86d 02c20e89 29d01af3    .......m....)...
08f000a0: 715d0860 12830d24 d4400a86 2899fb3c    q].`...$.@..(..<
08f000b0: f3618d15 d9847b6f ff28b57f bff59939    .a....{o.(.....9
08f000c0: 1feff779 cf7bce9c 73146f7c d51f49e8    ...y.{..s.o|..I.
08f000d0: 5fdba3ce 5129a4cd cac72559 d9275ab6    _...Q)....%Y.'Z.
08f000e0: b6b0450a 0533ab16 ee3006df 7a57e5d3    ..E..3...0..zW..
08f000f0: 6254fe5e 1a2b7f27 a9caa4e8 89d8fbef    bT.^.+.'........

u-boot># sf write 0x8f00000 0x100000 d80000
u-boot># sf read 0x8f00000 0x100000 d80000
u-boot># iminfo 0x8f00000

## Checking Image at 08f00000 ...
   Legacy image found
   Bad Header Checksum

u-boot># md 08f00000
08f00000: 27051956 138cde24 65520002 0021427c    '..V...$eR...!B|
08f00010: 80100000 80100000 a1009000 05050201    ................
08f00020: 4d404042 00427000 00000000 00404944    M@@B.Bp......@ID
08f00030: 45500105 00000000 00001000 00000000    EP..............
08f00040: 1f8b0800 00000000 02ffec7d 7d781c57    ...........}}x.W
08f00050: 79eebbb3 b3d2da16 84001002 12438946    y............C.F
08f00060: d6082089 05081902 01901481 00640820    .. ..........d.
08f00070: 00932225 5ff4ea91 e460d350 18001096    .."%_....`.P....
08f00080: 008085a4 00120402 37980008 d8220501    ........7...."..
08f00090: 12d0b5d6 b40aa025 00020a89 09c00871    .......%.......q
08f000a0: 01490040 10800000 00000804 0098c83c    .I.@...........<
08f000b0: f1608114 09800967 de289156 3e949119    .`.....g.(.V>...
08f000c0: 190fe771 494b4a8c 1010046c 50150920    ...qIKJ....lP..
08f000d0: 528ba1c2 40012044 88c22501 51010a06    R...@. D..%.Q...
08f000e0: a6a0400a 04020206 2e100086 5a5645c1    ..@.........ZVE.
08f000f0: 02002a5e 02091527 80402440 8898c007    ..*^...'.@$@....

u-boot># sf update 0x8f00000 0x100000 d80000
u-boot># sf read 0x8f00000 0x100000 d80000
u-boot># iminfo 0x8f00000

## Checking Image at 08f00000 ...
   Legacy image found
   Image Name:   OpenWrt
   Created:      2024-03-22  22:09:42 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    3236735 Bytes = 3.1 MB
   Load Address: 80100000
   Entry Point:  80100000
   Verifying Checksum ... OK


u-boot># md 08f00000
08f00000: 27051956 ffffffff 65fe01a6 0031637f    '..V....e....1c.
08f00010: 80100000 80100000 bff89088 05050201    ................
08f00020: 4f70656e 57727400 00000000 43414d45    OpenWrt.....CAME
08f00030: 4f544147 00000001 000010c1 80905a19    OTAG..........Z.
08f00040: 1f8b0800 00000000 02ffec7d 7d7c1c57    ...........}}|.W
08f00050: 79eebbb3 b3d2da5e ac91b456 16478946    y......^...V.G.F
08f00060: d68cb4a9 05ac1d83 55d83693 95ec3821    ........U.6...8!
08f00070: 80933a25 5ff4ee95 e460d350 9c105a97    ..:%_....`.P..Z.
08f00080: 08b395e4 209a8d46 37b88d49 dcb29525    .... ..F7..I...%
08f00090: dbd0b5d6 b40ab86d 02c20e89 29d01af3    .......m....)...
08f000a0: 715d0860 12830d24 d4400a86 2899fb3c    q].`...$.@..(..<
08f000b0: f3618d15 d9847b6f ff28b57f bff59939    .a....{o.(.....9
08f000c0: 1feff779 cf7bce9c 73146f7c d51f49e8    ...y.{..s.o|..I.
08f000d0: 5fdba3ce 5129a4cd cac72559 d9275ab6    _...Q)....%Y.'Z.
08f000e0: b6b0450a 0533ab16 ee3006df 7a57e5d3    ..E..3...0..zW..
08f000f0: 6254fe5e 1a2b7f27 a9caa4e8 89d8fbef    bT.^.+.'.......

To finish, you can push a stock image like this:
(do not forget to strip 64 = 0x40 bytes, and to adapt a62410 with the size returned by tftpboot)

tftpboot 0x8f00000 DGS-1210-FX-SERIES-FX-6-20-B020.hex
sf update 0x8f00000 0xe80000 0xa62410
reset

u-boot># iminfo

## Checking Image at b4100000 ...
   Legacy image found
   Image Name:   OpenWrt
   Created:      2024-03-22  22:09:42 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    3236735 Bytes = 3.1 MB
   Load Address: 80100000
   Entry Point:  80100000
   Verifying Checksum ... OK

u-boot># iminfo 0xb4e80000

## Checking Image at b4e80000 ...
   Legacy image found
   Image Name:
   Created:      2021-09-17   9:50:05 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1035509 Bytes = 1011.2 KB
   Load Address: 80000000
   Entry Point:  80262000
   Verifying Checksum ... OK

and folow baseline to chose on which you want to boot :slight_smile:

PS: it was a three days no sleep challenge...

2 Likes

thanks for your help, i details everything in case someone want to unbrisk by pushing mtd or directly to flash

Thanks for the detailed logs and progress report, hopefully it helps others in the future.

Great! I suppose that write requires a separate erase command beforehand while update issues that in the background.

yes that it, i was perfoming an erase before, but it was not long enough apparently :smiley:
Update is better, you have a "progression" shown