Request: full 2 MB SPI dump for WAMJHJ-8125MNG (RTL8373, W25Q16) - bricked by official firmware, need a matching image

[ThierryLC]

Hi all,

I’ve read through the WAMJHJ / dump discussion in this thread, but I’d like to request a dump that matches my exact board revision before attempting to write anything to the chip.

Background
I have the 8× 2.5G + 1× 10G SFP+ managed switch sold under the AMPCOM brand (same hardware as Horaco and others).
I flashed the vendor’s official firmware package:

• Switcher_Firmware_V1.9.zip
• Inner file: APK_V1.9_WAMJHJ-8125MNG_0104.bin

Flashing was done via the web UI. The process stalled at 25%, and the unit is now stuck in a boot loop:

• All port LEDs cycle green/orange approximately every 6 seconds
• No web UI on either the default IP or my configured IP

This looks like a classic corrupted firmware write. The vendor has since confirmed (in writing) that this firmware file was the wrong revision for my hardware, and the download link has now been removed.

Hardware details (from the board)

• SoC: Realtek RTL8373 (under the central heatsink)
• Board silkscreen: PCB-SWTG018AS-A-V2.0.1_19649
• SPI flash (U4): Winbond W25Q16JV
  • 16 Mbit / 2 MB
  • SOIC-8
  • JEDEC: EF 40 15

I have a CH341A with a SOIC8 clip, can read/write the chip, and have already saved a backup of the current (corrupted) contents.

What I’m looking for

1. A full 2 MB SPI dump from a working unit of the same revision (RTL8373 + W25Q16, 2 MB).
   I want to avoid writing a 4 MB image from a W25Q32-based variant.
2. Flash partition layout information, if available.
   I’m open to rewriting only the bootloader/firmware region and keeping my existing config if that’s the cleaner approach.
3. Clarification on per-unit data:
   • Is the MAC address (and serial number) stored in this SPI flash?
   • If yes, at which offset or partition approximately?
4. My plan would be to write a full donor dump and then correct the MAC, rather than risk conflicts on my LAN.

Giving back
Once I recover the unit, I’ll share:

• A clean 2 MB dump
• Chip details
• Hashes
• Notes on the vendor firmware and structure

So the next person who bricks one has a matching image to work from.

Thanks a lot for any help.

Thierry

 

[Shonk]

give a photo of the shell

 

[ThierryLC]

give a photo of the shell

 

[Shonk]

thats the newer hardware revision you flashed the old hardware revision firmware on it 1.9x is old hardware only
sorry my spi backup is 1.91 for the first hardware revision

 

[Shonk]

I have just checked i have this that i tried to force a newer firmware onto it at some point

chipset W25Q16JV - Horaco SWTGW218AS - SWTG018AS-A-V2.0.1 board.zip

roll the dice and give it a try there's no harm you have a spi backup

i just had a quick look at it in a hex editor its v200.1.16 firmware

#y#y RTL8373 V200.1.16 V1.0 # hengrui^e admin 0123456789ABCDEFabcdef %02bX:%02bX:%02bX:%02bX:%02bX:%02bX , %d %d-%d %s%d ,%s%d ,%d ,%d-%d %d.%d.%d.%d line %d,ret : %lx
%s():%d ret %lx

it came from here

https://forums.servethehome.com/index.php?threads/horaco-2-5gbe-managed-switch-8-x-2-5gbe-1-10gb-sfp.41571/post-483290

If you get that working you can update it to 200.2.4 then in the webui

https://www.horaconetworks.com/pages/firmware-and-manuals-for-horaco-products

 

[pigr8]

i have the same WAMJHJ-8125MNG but that firmware you posted belongs to a totally different pcb, based on SWTG118AS, as @Shonk said you have to flash a SWTG018AS.

since you have a ch341a it's an easy job and remember not to recalculate checksum or uuid, just flash the file proposed and update to the horaco one later.

 

[ThierryLC]

Thanks a lot, both of you — Shonk and pigr8. This is exactly what I needed.

@Shonk — one thing I want to be 100% sure of before I write (it's a one-shot):

in #4 you noted your backup was for the first hardware revision, but the file you attached in #5 is named for the SWTG018AS-A-V2.0.1 / W25Q16JV board, which is mine. Can you confirm the #5 zip is the dump for this newer SWTG018AS revision (not the SWTG118AS one)? Just double-checking before I flash.

@pigr8 — thanks for pinpointing that the V1.9 file is actually for the SWTG118AS PCB; that explains everything. You mentioned updating to the Horaco firmware afterwards — where can I get the current Horaco image for the SWTG018AS board? And to confirm your point: I write Shonk's 2 MB image as-is, no checksum/UUID recalculation, correct?

Here's my plan — tell me if I've got it right:

1. Read and keep a full backup of my current (corrupted) chip first.

2. Write the 2 MB donor image as-is.

3. Boot, then update to the current Horaco firmware via the web UI.

On the MAC: I understand the donor dump carries the original unit's MAC. Since I'll keep my own backup (which still has my real MAC), I can patch mine back in if needed — or is that unnecessary once I'm on the Horaco firmware?

I'll report back and post a verified clean dump + hashes + notes once it boots, so the next person has a matching image.

Really appreciate the quick help.

 

[Shonk]

Its not a oneshot you can always write the backup onto it to be right back where you are now

yes my backup is 1.91 from the old revision the one i provided you is someone elses backup
from your revision, that i tried to get working on an older revision it results in a boot loop so gave up
and restored my 1.91 backup

just write it with verify on to ensure its written correct the same with your backup back it up multiple times and check its crc32 is the same

with regards to where you can get the horaco update i already provided you with a link to the latest 200.2.4 web update
for you to use when you have it working again with 200.1.6

 

[ThierryLC]

Legend, thanks Shonk - that's really reassuring.

Got it on all counts:
- The image you shared is a donor backup from my revision (SWTG018AS), and your boot loop was from trying it on your older board - makes total sense, that's the revision mismatch doing its thing. Good to know it's the right one for me.
- And thanks for the peace of mind: since I'll keep my own backup, it's fully reversible if anything goes sideways.

On method, I'll do exactly that:
- Read my current (bricked) chip a few times and confirm the CRC32 matches across reads before I trust the backup, then write your image with Verify on.
- Since it's a donor dump, I'll factory-reset after flashing to clear its config (and I know it'll carry the donor MAC - fine on my single-switch LAN).

On the Horaco update: perfect - so it boots on 200.1.6, then I web-update to 200.2.4. I'll grab the 200.2.4 link you posted earlier in the thread (I'll shout if I can't spot it).

I'll report back and post my verified 2 MB dump + hashes once it's booting - that'll give the thread a confirmed-good image for this exact SWTG018AS revision (since yours is a donor you couldn't test on your own board, a confirmed boot should help the next person).

Really appreciate you digging this out for me.

Cheers!

 

[pigr8]

you can try this also SWTG118AS/dumps/SWTG018AS-A-v2.0.1 at main · up-n-atom/SWTG118AS should work.

for the mac you should retain yours iirc, at least everytime i flashed mines.

 

[ThierryLC]

Cheers pigr8, that's super helpful.

Nice — I didn't realise up-n-atom had a folder for this exact board. I'll pull the SWTG018AS-A-v2.0.1 dump and CRC32-compare it against the one Shonk shared;

two matching references from different sources is exactly the confidence I wanted before writing.

And good to hear on the MAC - that simplifies things, thanks. Makes sense if it's held in the SoC efuse rather than the SPI flash. I'll still double-check the switch shows my own MAC after flashing, but sounds like there's nothing to patch.

I'll keep a verified backup of my own chip first (belt and braces), then flash with verify on. Will report back once it's booting and post my results so this revision stays well documented.

Thanks both - great thread!

 

[Shonk]

You wont retain you mac its in the spi dump
get it going then worry about changing that later

 

[ThierryLC]

Thanks, good to know - so the MAC lives in the SPI dump, and I'll inherit the donor's MAC when I flash your image rather than keep my own. Understood.
Not an issue on my end: it's a single switch on my LAN (the donor isn't on my network), so no MAC clash. I'll follow your advice - get it booting first, then sort the MAC out afterwards.
Since I'll keep my own backup, I can locate my original MAC in it and patch it back into the image (or set it via the firmware) once it's alive.
Will report back when it's up.
Cheers!

 

[ThierryLC]

[SOLVED] It's alive - thanks @Shonk and @pigr8

Quick report back, since I promised one.

Result: the 2 MB image Shonk shared flashed cleanly (write + verify), the switch booted first try, no more boot loop. I did a factory reset afterwards and it's now reachable on 192.168.2.1 from an isolated laptop. Firmware reports 200.1.6.

The bit that may matter to the thread: as I understand it, that image was a donor dump you hadn't been able to test yourself (it boot-looped on your older-revision board). So this is a confirmation that it DOES boot correctly on a genuine SWTG018AS-A V2.0.1 / RTL8373 / W25Q16JV board. Anyone with this exact revision who bricks theirs can use it with confidence.

For the record, hardware details as flashed:
- Board silkscreen: PCB-SWTG018AS-A-V2.0.1_19649
- SoC: Realtek RTL8373 (+ RTL8224N)
- SPI flash: Winbond W25Q16JV, 2 MB, SOIC-8, JEDEC EF 40 15
- Image: 2 097 152 bytes, SHA-256
165e868dfd0f233396e8cc65ab5100c96b52f47d740fc1a9b1ec2f1f8f8798c9
(I also downloaded the copy from the up-n-atom repo that pigr8 linked and compared it byte-for-byte: identical to Shonk's file. Two independent sources, same image - that's what convinced me to write it.)

On the MAC: confirmed, I inherited the donor's MAC, as Shonk said - it's in the SPI dump, not in the SoC. No problem here (single switch on my LAN, donor isn't on it). I kept a backup of my own bricked chip, so I can patch my original MAC back in later if I ever care. "Get it going first" was the right call.

I originally offered to post my own clean dump. Honestly it would be pointless now: my chip holds Shonk's image, so a fresh dump is the same file. Happy to share anything else that's useful though - hashes, notes, or photos of the board.

One practical tip for anyone doing this with a cheap CH341A kit: the SOIC8 clip was by far the hardest part. Mine wouldn't grip the chip properly on the board - detection kept failing or returning garbage. What fixed it: unhooking the clip's spring so it stopped fighting me, and using a soldering "helping hands" / third hand to hold the clip perfectly still and square on the chip. Once it was mechanically stable, read/erase/write/verify all went through first time. If your clip won't detect, don't crank harder on it - stabilise it mechanically.

Next step is putting it into service (VLAN for an isolated torrent segment behind a VPN), but that's my own project, nothing more needed from the thread.

Thanks again, both of you - you turned a dead 60 EUR switch into a working managed switch in a couple of days.
Genuinely appreciated.

 

[pigr8]

On the MAC: confirmed, I inherited the donor's MAC, as Shonk said - it's in the SPI dump, not in the SoC. No problem here (single switch on my LAN, donor isn't on it). I kept a backup of my own bricked chip, so I can patch my original MAC back in later if I ever care. "Get it going first" was the right call.

#protip: after login to the webui you can go to http://ipaddress/ftdft.cgi and restore your original mac address