DS412+ rebuild bios

[BangFR]

Hi,

I've found some helpfull information on this forum (thanks a lot for sharing them) and tried to rebuild the bios of my DS412+.

I desoldered the chip and read it with an EZ2023+ programmer.

The backup shows 1st part of the chip (till 2Mb) with some information (some part were blank 0xFF but mostly some code
and the second part empty (0xFF)

I extracted the bios_R2.rom from the pat file (bios_R2 because my board is released v1.4 so I assume it was this one) and flash the chip
so 1st part = bios_R2.rom
2nd part = empty (0xFF)

But before resoldering it, I'm trying to be sure it's ok and reading the topics I still have question

From this topic Bios rebuild

From this topic Rebuild a DS412+ from .pat file
Explain where put the .rom found in .pat the advise was to paste it at the 2nd part (from address 0x200000 to 0x3FFFFF) and empty the 1st part

On the backup of the bios, this is the reverse: 1st part with data, 2nd with none

So I wonder if I have to apply
1st part empty, 2nd bios.rom
OR 1st part backup, 2nd bios.rom
OR just used the bios sent by Electrixman to Vitaliy

Thanks in advance for Elextrixman, ragnarok and Vitaliy for the answer or anyone that know how to do this.
@ragnarok , @Vitaliy @Elextrixman

I took image provided by Elextrixman. It is 4MB file, where only first half is used, copied bios.rom tp this file from 0x200000. I upload this file to chip and guess what!!! I have beep, solid blue and flashing orange. Time to try assemble it

Same to you ;-)

And yes

• Let the first half from 0x0h - 0x1FFFFFh be 0xFFh filled, and
• Copy the content of bios.ROM from the .PAT archive to 0x200000h - 0x3FFFFFh

..resulting in a 4.194.304 bytes file, and burn that to the Winbond.

 

[ragnarok]

Hi,

I've found some helpfull information on this forum (thanks a lot for sharing them) and tried to rebuild the bios of my DS412+.

I desoldered the chip and read it with an EZ2023+ programmer.

The backup shows 1st part of the chip (till 2Mb) with some information (some part were blank 0xFF but mostly some code
and the second part empty (0xFF)

I extracted the bios_R2.rom from the pat file (bios_R2 because my board is released v1.4 so I assume it was this one) and flash the chip
so 1st part = bios_R2.rom
2nd part = empty (0xFF)

But before resoldering it, I'm trying to be sure it's ok and reading the topics I still have question

From this topic Bios rebuild

From this topic Rebuild a DS412+ from .pat file
Explain where put the .rom found in .pat the advise was to paste it at the 2nd part (from address 0x200000 to 0x3FFFFF) and empty the 1st part

On the backup of the bios, this is the reverse: 1st part with data, 2nd with none

So I wonder if I have to apply
1st part empty, 2nd bios.rom
OR 1st part backup, 2nd bios.rom
OR just used the bios sent by Electrixman to Vitaliy

Thanks in advance for Elextrixman, ragnarok and Vitaliy for the answer or anyone that know how to do this.
@ragnarok , @Vitaliy @Elextrixman

From what I understand, Vitaliy used the file from Elextrixman and loaded the bios.ROM from the .PAT file on top of that to 0x200000h as I suggested. I think that worked for Vitaliy…

 

[BangFR]

Thanks a lot, I did some digging to understand the layout and it seems that without this 1st part it's difficult to get a working bios, but definitely, this seems to confirm that the bios.rom (found in .pat file) should be put at offset 0x200000

For this model, ther is two versions of bios:
1. bios.rom
2. bios_r2.rom

@Vitaliy hope you read this message to answer my questions, thanks in advance !

anyone know which one is linked to a specific released of the board ? (I got a v1.4 with corrupted bios, and a v1.3)

It's only a compilation of what I found but I could be wrong

Flash Chip Mapping (4 MB /​

• First Half (0x000000 to 0x1FFFFF — 2 MB): Hardware Initialization
  
  • Intel Flash Descriptor (First 4 KB): Starts with 5A A5 F0 0F. Defines the region map and hardware strapping parameters for the Intel NM10 Southbridge.
  • GbE Region: Configuration data for the Intel network controller.
  • ME (Management Engine) Region: Disabled by Synology on this specific model.
    
• Second Half (0x200000 to 0x3FFFFF — 2 MB): BIOS / UEFI Region
  
  • Contains the bios.rom file (found in .pat file)
  • Starts with the Synology capsule security header (78 E5 8C 8C...) followed by the standard UEFI structure (_FVH).
  • Ends with the Intel Reset Vector, the CPU's absolute entry point upon powering up.

Boot Sequence Chronology​

[ Power On ]
│
▼
1. Hardware Init ──► The Southbridge reads the first 4 KB (0x000000).
│ Zone: Intel Flash Descriptor
│ (If crash: System is completely dead; data lines remain silent)
▼
2. Boot Strapping ──► The CPU reads the very last 16 bytes (0x3FFFFF).
│ Zone: Reset Vector (End of BIOS Region)
│ (If crash: Brief pulse on the Flash chip pins, then nothing)
▼
3. Microcode Exec ──► The CPU executes the complete UEFI code base (0x200000).
│ Zone: BIOS / UEFI Region (bios_r2.rom)
│ (If crash: TTL serial port activates but freezes or outputs errors)
▼
4. OS Loading ──► The BIOS hands over control to the external storage (DOM).
Zone: Vendor Section (S/N, MAC) then boots DSM.

 

[BangFR]

as a donor for this part, any bios from DS1512+, DS1812+ or DS2413+ should work (same southbridge, same network chip)

 

[orefie]

hi,
The usual "2 MB / 2 MB split, BIOS at 0x200000" description doesn't match the real part. On my unit the chip is a
Micron N25Q032 (4 MB) on the ICH10R, and flashrom reads back like this:

Region │ Real range
───────────────────────────────
Flash Descriptor (5A A5 F0 0F) │ 0x000000–0x000FFF
────────────────────────────────
GbE │ 0x001000–0x010FFF
────────────────────────────────
ME (disabled by Synology) │ in descriptor
────────────────────────────────
BIOS / UEFI = bios.ROM │ 0x011000–0x210FFF
────────────────────────────────
Unreadable gap = P-Unit FW │ 0x211000–0x3FFFFF

So descriptor/GbE/BIOS all sit low; the top of the chip is the unreadable P-Unit region — the opposite of "BIOS in the
upper 2 MB." For a reflash, bios.ROM goes at 0x11000, not 0x200000.

A full-chip -w fails on that unreadable gap. Use a layout file limited to the BIOS region and write program-only
against current contents, or the 64 KB erase alignment will spill into the gap and wipe the descriptor + GbE.

Three quick fixes to the original:
1. 78 E5 8C 8C… is not a Synology capsule — it's the standard EFI FFSv2 volume GUID 8C8CE578-….
2. It runs bios.ROM, not bios_r2.rom — the .pat ships both for different PCB revs; diff your dump and pick the match
(wrong one = brick).
3. The reset vector is at CPU 0xFFFFFFF0 = top of the BIOS region (~chip 0x210FFF), not chip 0x3FFFFF.

TL;DR: BIOS at 0x11000, top of chip is unreadable P-Unit, preserve descriptor + GbE and flash the BIOS region only.
(BIOS: Tiano/Granite Well, Intel, 05/27/2011.)

 

[orefie]

Here's where I'm at.

Hardware: DS412+ (Atom D2700), SPI flash Micron N25Q032 (4MB SOIC-8, 3.3V).

What I did, in order:

1. flashrom (in-system, live while the NAS was booting) — dumps OK, but the region 0x211000–0x3FFFFF reads back as
00/unreadable. Per the flash descriptor it's unallocated (active regions = Descriptor + GbE + BIOS only), so the ICH
won't read it. I never got the real content of that "gap".
2. CH341A for a full dump — turned out the CH341A drives ~5V on MISO/MOSI even in "3.3V" mode, overstressing the 3.3V
chip. Right after that the NAS stopped booting: fan spins, blue LED blinks, serial totally mute (dies before UART init
— no POST banner at all).
3. Desoldered + read/reflashed on a T48 (hardware, off the ICH):
- Chip is alive (JEDEC 20 BA 16).
- desc + GbE + BIOS are byte-identical to my live flashrom dump (only runtime NVRAM differs); reset vector present
at 0x210FF0; the gap = all FF.
- Clean erase + write + verify of the reconstructed image → still mute. Multiple reconstruction/flash attempts (T48)
= NOK.

Two board revisions exist: the DSM 6.2.4 .pat ships two BIOS images with different descriptors/layouts:
- R1 (mine) = bios.ROM: BIOS at 0x11000–0x210FFF, reset vector at 0x210FF0, upper half unused (my live dump is
byte-identical to this one).
- R2 (Vitaliy's) = bios_r2.ROM: BIOS in the upper half at 0x200000 (that's how he recovered his board). An R2 image
will not boot an R1 board — different strapping.

My two remaining hypotheses:
- (a) the CH341A 5V killed the board (chip I/O and/or NM10), or
- (b) there's real data in the "gap" 0x211000–0x3FFFFF that I never managed to read (flashrom can't; by the time I
read it on the T48 it was already FF).

Ask: could an R1 owner (BIOS at 0x11000, reset vector 0x210FF0, bios.ROM variant) do a full 4MB hardware SPI dump
(T48/programmer, straight off the chip, not via flashrom/ICH) so I can compare the 0x211000–0x3FFFFF region? That
would tell me whether R1's upper half is genuinely empty — and rule (b) in or out. Thanks!

 

[orefie]

DS412+ — R1 vs R2: the difference is hardware, not the flash layout

Quick write-up after finally debricking my R1 board and rebuilding its BIOS. While I was at it, I dumped a real R2
board too and compared the two — and the short version is: the difference between R1 and R2 is a hardware/silicon-init
revision, not a different flash layout.

Both boards: Micron N25Q032 (4 MB), ICH10R, dumped in-system with flashrom (read-only).

Identical, byte-for-byte, on both revisions:
- Flash descriptor (0x0–0xFFF) and GbE region — 0 diff
- Same layout: BIOS at 0x11000–0x210FFF, reset vector at 0x210FF0, 0x200000 empty on both
- Same ICHSTRP0 (so the "descriptor bit1 = board rev" theory is wrong)

⟹ The popular "R2 puts the BIOS at 0x200000 / reset at 0x3FFFF0" is a myth — it came from flashing bios_r2.ROM at the
wrong offset. No real R2 board does that.

The only real difference — the BIOS build:

- bios.ROM = BLDK Allegro 0.2.15 = R1

- bios_r2.ROM = BLDK Allegro 0.3.7 = R2 (matches my R2 dump to 0.43% = NVRAM only)

Same layout, same offset, just a newer build. Decompiling both, ~90 modules are identical; R2 only refreshes some
PEI/DXE init modules and bumps the Cedarview microcode (0x030661: rev 0x0103 → 0x0108/0x010d). It's a silicon-init
update for the board revision, nothing structural.

Takeaway for recovery: you don't need a revision-specific offset. Recover from a known-good full 4 MB image, flashed
out-of-circuit on a socket/T48 — never in-circuit with a CH341A.

One important warning: flashing or a full raw dump does not work reliably with the chip soldered on the board.
In-circuit, the SPI bus is shared with the NM10 southbridge, so the best you get is a region-by-region read-only
flashrom pass (and even that can't read the unallocated gap). Any real write — and a proper full dump — means
desoldering the chip onto a socket/T48. Trying to do it in-circuit (especially with a CH341A) is how boards get
bricked.

Practical drop-in replacements available today (falling within these IDs or strict equivalents):
- Winbond W25Q32BV / W25Q32FV / W25Q32JV (EF 40 16) — the most common, recommended
- Macronix MX25L3206E (C2 20 16)
- Micron N25Q032A (20 BA 16) — the original
- SST25VF032B (BF 25 4A) — rarer nowadays

 

[orefie]

Bonus :

1 : Serial pins :
Board R1

Board R2

2: Bios mod

• Unlock F400:F400
• Rebuild
• Boot from USB3

WARNING — highly experimental, purely recreational (just to understand how it works). Bricking is more than
likely, and you'll need hardware (an SPI programmer + SOIC-8 clip or hot-air rework) to recover. I have neither the
time nor the desire to do maintenance on bricked devices. Do this entirely at your own risk.

DS412+ (Atom D2700 / Granite Well) — flash only the BIOS region, unlock the f400 boot-lock, boot from USB3

Chip is a 4 MB SPI (Micron N25Q032, or a W25Q32BV if you swapped it), ICH10R southbridge. Layout:

- 0x000000–0x000FFF Flash Descriptor · 0x001000–0x010FFF GbE · 0x011000–0x210FFF BIOS · 0x211000–0x3FFFFF = P-Unit
"gap".

The gap is unreadable through the ICH (flashrom → Transaction error). If you let flashrom do a full-chip erase, the
erase spills into that gap, wipes the descriptor + GbE, and you're bricked. So only ever touch the BIOS region.

For rebuilding the modified BIOS image , see my previous post.

1) Flash the BIOS region only (the safe recipe)

# layout: BIOS region only
printf "0x00011000:0x00210fff bios\n" > layout.txt

# back up the readable region first
flashrom -p internal -l layout.txt -i bios -r bios-region-backup.bin

# write ONLY the BIOS region, never reading/erasing the gap
flashrom -p internal -l layout.txt -i bios \
--flash-contents current-4mb.bin --noverify-all \
-w modified-4mb.bin

- --flash-contents current-4mb.bin = give flashrom the current chip content instead of reading it → it never touches
the gap.
- --noverify-all = verify the written region only.
- Add -c "W25Q32BV/W25Q32CV/W25Q32DV" (or your detected chip) if flashrom asks.
- A Verifying FAILED … byte count 0x1 at the 0x210fff boundary is an artifact — judge success by reading the region
back, not by that message.

2) Unlock the f400 boot-lock

Stock firmware only boots a USB device whose VID:PID is exactly f400:f400 (the dead Synology DOM). Anything else → you
drop to the EFI Shell with no fs. The check is in UsbBusDxe.efi: it compares idVendor/idProduct to 0xF400 and returns
EFI_NOT_FOUND otherwise. NOP the two conditional jumps (12 bytes):

┌──────────────────────────────┬────────────┐
│ Offset in UsbBusDxe.efi │ Before │ After │
├──────────────────────────────┼────────────┤
│ 0x2991 │ 0F 85 17 03 00 00 │ 90 90 90 90 90 90 │
├──────────────────────────────┼────────────┤
│ 0x299B │ 0F 85 0D 03 00 00 │ 90 90 90 90 90 90 │
└──────────────────────────────┴────────────┘

(Zero-risk alternative: just reprogram your USB adapter's VID:PID to f400:f400 and skip the flash entirely.)

3) Boot from USB3

Stock BIOS is EHCI-only — no XhciDxe, so USB3 controllers aren't driven at boot. Add the generic EDK2 XhciDxe (it
binds by PCI class 0C0330, so it drives the NEC µPD720200 without any VID:PID match):

1. Build XhciDxe X64 — link it against a real TimerLib (e.g. DxeAcpiTimerLib, ACPI PM-timer). The default TimerLibNull
asserts and skips all delays.
2. Insert into the DXE FV and reflash the BIOS region (§1).
3. After reboot it's auto-dispatched at POST. Point the boot order at your USB3 disk from Linux:

efibootmgr -v # find the entry for your USB3 disk
efibootmgr -o <usb3>,<fallback> # e.g. 0005,0001,0000
efibootmgr -t 5 # 5s timeout

Done — it boots straight off the USB3 disk. (You may see a harmless STALL_ERROR/Device Error line at cold POST — the
bridge isn't awake for the first bulk read; the firmware retries and boots normally.)

3) DS412+ with 4GB RAM — the "slow 1GB zone" and how to fix it

While I was in here, I finally took the time to understand why the NAS is sometimes slow with 4GB of RAM — and,
importantly, to confirm it's not an MRC (memory init) problem. The memory trains fine; the issue is what happens
after, once the system starts using a particular region of RAM.

The DS412+ ships with 2GB and is officially capped there, but the board physically accepts 4GB. The catch: with 4GB
installed, roughly 1GB of the address space is extremely slow (memory benchmarks in that region drop to a fraction of
normal DRAM speed).

Symptoms
- Very slow boot, and/or
- High/erratic CPU load

It can show up right at boot, or creep in over time as the system allocates into that region — which makes it look
like a random "my NAS got slow" problem rather than a memory issue.

Root cause
It's not a lottery or a bad stick. The slow region is the second GB of physical address space (0x40000000–0x7FFFFFFF).
It's deterministic — a side effect of how the Cedarview IMC swizzles/maps the memory — so it lands in the same place
every boot.

Fix
The only reliable workaround is to remap the RAM to exclude that zone rather than trying to speed it up. On a Linux
boot (Debian/OMV in my case) this is a one-line kernel command-line parameter:

memmap=1G$1G

This tells the kernel to reserve/skip the 1GB starting at the 1GB mark, so nothing is ever allocated into the slow
region. Boot times return to normal and the runtime CPU load disappears. You lose 1GB of usable RAM, but what's left
is full-speed — a good trade compared to an unusable-feeling system.

TL;DR: 4GB "works" on a DS412+, but the second GB is a slow trap. Exclude it with memmap=1G$1G and the slowness (boot
+ CPU) goes away.

I haven't tested it, but these tips should apply to the entire D2700 family.
Meaning the :
RS2414+
RS2414RP+
RS814+
RS814RP+
DS2413+
DS1813+
DS1513+
DS713+
RS812+
RS812RP+
DS1812+
DS1512+
DS412+


enjoy

Let's save the planet — recycle our old devices instead of throwing them away!