Well... repo link is on 1st post. Give it a try.
As for all the other models... this thread is specific to the DNS320 A1, so not sure why you posted all that.
I'll update the repo to latest release once I get a chance. And I'm not sure if I will try to pull-request this into main... it's a ton of work, and so far I count 2, maybe 2.5 users. Feel free to do it yourself - it's all packaged in one commit.
v24.10.5-r1 release posted to GitHub! Link on 1st post.
So far I have not needed to update patch offsets, which is probably a simple thing to do but a skill I don't have. Building on any 24.10.x version is straightforward if the preference is to use the official OpenWrt repo, as in:
git clone https://github.com/openwrt/openwrt && cd openwrt
git checkout -b 24.10.5 v24.10.5
git remote set-url origin https://github.com/APCCV/openwrt-dns320
git fetch
git cherry-pick e3b2ebf626320f8215e36b924d0b36016fb32df9
./scripts/feeds update -a
./scripts/feeds install -a
cp dns320-config.buildinfo .config
make defconfig
make V=s download
make V=s -j4
Next on my list... figure out if the environment can be easily extracted and checksummed so three flash operations from Alt-F should in theory install without having to disassemble... let's see
Process to flash without disassembly. Refer to https://github.com/APCCV/openwrt-dns320/releases/tag/v24.10.5-r1 for required files.
Full disclosure: I have tested this process much as I can. A lot of thought and checks have gone into it, but I no longer have Alt-F running on my NAS and I don't want to flash the u-boot back to stock to be able to fully test this. That said, I am extremely confident in this process or I would not have posted it.
DNS320-Ax ONLY.
There is a risk of bricking the device by following this process. Unbricking will require disassembly and use of a serial adapter to recover it. You've been warned. (Good news is that it is impossible to permanently brick this device.)
Prerequisites:
u-boot.kwb, env.bin and ubi.bin files copied over to the NAS and stored locallyProcess (summary):
u-boot.kwb, env.bin and ubi.bin files to their respective partitions, cross fingers and reboot by unplugging the device. Do not reboot until all flashing is complete.sysupgrade to the full sysupgrade image in release to ensure a flawless firmware image is installed (just in case Alt-F messed a block while trying to access old JFFS partitions).The new u-boot can flash an image from USB as a recovery mechanism. Process above is interactive and allows for some level of recovery. Flashing from USB is not interactive but is a failsafe reccovery option for faulty OpenWrt images. Details for this on next post.
Step by step installation instructions:
If the NAS is running stock firmware, install the Alt-F-1.0-DNS-320-rev-Ax.bin firmware in the v24.10.5-r1 release through the stock firmware upgrade UI. If the NAS is already running Alt-F, upgrade the firmware with that file. Refer to the Alt-F site for more information in either case. Boot into this firmware.
Transfer the u-boot.kwb, env.bin and ubi.bin files to the NAS. Any location works, any mechanism works. Files need to be accessible to a shell. A USB drive works, a folder on any hard disk will do too.
Stop and disable as many services as possible (file sharing, torrent server or client, media server, anything...) with the exception of secure shell (ssh) access. Next, the Alt-F folder that contains all installed packages should be disabled to remove the possibility of it damaging the new UBI partition during flash. For that, go to Packages->Alt-F, check the "Boot Disable" checkbox, hit Submit, then reboot. After reboot you will see a Warning message in the Status page saying that an Alt-F folder was detected but not used, as a file named NOAUFS was found on it.
Connect to the NAS as root via ssh. The web password is also the password for ssh, unless it was changed from ssh. If unknown, reset the web password and that will also reset the root password.
Confirm the required partitions were created:
[root@DNS-320-0174DB]# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 00500000 00020000 "ramdisk"
mtd3: 06600000 00020000 "image"
mtd4: 00a00000 00020000 "mini firmware"
mtd5: 00500000 00020000 "config"
mtd6: 07f00000 00020000 "ubi"
mtd7: 00020000 00020000 "env"
Check kernel log with dmesg | less and validate the kernel sees the partitions with appropriate sizes:
8 ofpart partitions found on MTD device orion_nand
Creating 8 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000600000 : "uImage"
0x000000600000-0x000000b00000 : "ramdisk"
0x000000b00000-0x000007100000 : "image"
0x000007100000-0x000007b00000 : "mini firmware"
0x000007b00000-0x000008000000 : "config"
0x000000100000-0x000008000000 : "ubi"
0x0000000e0000-0x000000100000 : "env"
cd to where the flash files are located.
Last opportunity for recovery - make a backup of the flash. Takes a minute can might avoid a brick if things start going the wrong way. To do so:
dd if=/dev/mtd0 of=uboot_mtd.bak
dd if=/dev/mtd1 of=kernel_mtd.bak
dd if=/dev/mtd2 of=initramfs_mtd.bak
dd if=/dev/mtd3 of=sqimage_mtd.bak
Point of no return. Once flashing of any partition starts, process must complete or device will be bricked. Any errors will require disassembly and a serial adapter. Do not reboot if something goes wrong. The backup files can be flashed back as a last ditch effort to avoid the brick.
First flash u-boot and environment:
root@DNS-320-0174DB]# flash_erase /dev/mtd0 0 0
Erasing 128 Kibyte @ e0000 -- 100 % complete
[root@DNS-320-0174DB]# nandwrite -p /dev/mtd0 u-boot.kwb
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
[root@DNS-320-0174DB]# nandwrite -p /dev/mtd7 env.bin
Writing data to block 0 at offset 0x0
[root@DNS-320-0174DB]#
If this fails...
A "read only" (or permission denied) on flash_erase means the NAS is not using the firmware provided in this release. No changes have been done, process can be started from the beginning by rebooting and flashing the appropriate firmware in this release.
If flash_erase or nandwrite for u-boot fail before reaching 100% (extremely rare), the device is probably bricked due to a defect in flash storage in a critical area. Attempt the command(s) again, just once more. If it works, continue, with writes.
If it doesn't, as a last hope for recovery, erase again and flash back the backup of the u-boot (nandwrite -p /dev/mtd0 u-uboot_mtd.bak) as far as it will go and reboot. The device might come back to Alt-F.
The device might be recovered through disassembly and using the kwboot tool. Links on 1st post contain some information about it.
If write for the environment fails but u-boot writes OK... continue with process. u-boot will boot with the default environment which should be OK. This will be fixed from OpenWrt.
Now flash the main UBI filesystem:
flash_erase /dev/mtd6 0 0
nandwrite -p /dev/mtd6 ubi.bin
This will take a minute or two to execute.
If that fails... revert everything and with luck NAS will be back to Alt-F.
Try erase and flash one more time, just once.
Recovering to Alt-F might be possible by flash_erase and nandwrite all four backups (including u-boot). Device can then reboot, hopefully into Alt-F. If device is bricked it can be most probably salvaged by disassembling and flashing OpenWrt via a serial adapter.
After the UBI file has been successfully flashed, unplug the device (do not reboot or do anything that could cause the running Alt-F OS to write to the filesystem). Plug in again, press power button. OpenWrt should boot. The NAS will reboot with the default OpenWrt IP address of 192.168.1.1/24. Congrats! NAS is on OpenWrt.
Final house keeping.
Update the MAC address in boot process.
kmod-mtd-rw*.ipk to the NAS.opkg install <file>. (Attempts to make this part of the image have failed so far).insmod mtd-rw i_want_a_brick=1fw_setenv ethaddr fc:75:16:01:04:bd (this is an example, adjust MAC to match sticker on bottom of NAS.Transfer the openwrt-24.10.5-kirkwood-generic-dlink_dns320-squashfs-sysupgrade.bin to the NAS and install it via the sysupgrade command to re-flash the UBI contents as a single partition (just in case), or use the GUI for firmware updates for it.
USB recovery...
This needs to be used responsibly, as leaving a USB plugged in the device with the right files will cause NAND to be flashed on every boot. The NAS won't last long if that happens, and impossible to estimate as there is no way to know how battered the NAND may be after so many years of dlink or alt-f use.
Release v24.10.5-r1 only. This has been baked into the default environment of u-boot, and is also configured in the env.bin file of that release.
To flash from USB, a formatted USB drive (any type) with a (preferably single) 1st partition formatted as ext4 is required.
A folder named dns320a-to-flash is needed at root level.
Inside that folder, an optional file named env-contents.bin will be flashed if present to the u-boot env.
Another optional file by the name ubi-filesystem.bin will be flashed if present to the UBI partition.
If both files are present, both partitions will be flashed.
/dns320a-to-flash
- env-contents.bin
- ubi-filesystem.bin
If no USB is present, or partition is not of ext4 type, or either/both files are not present, NAND will not be touched and device will boot normally. Only side effect is a 4s delay.
This will allow recovery from a bad environment, corrupt firmware installation, or failed install without disassembly (as long as u-boot was flashed OK).
This is what a UBI flash looks like in the console:
=> boot
resetting USB...
Bus ehci@50000: USB EHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
11010048 bytes read in 566 ms (18.6 MiB/s)
flashing ubi a80000 bytes...
NAND erase.part: device 0 offset 0x100000, size 0x7f00000
Erasing at 0x7fe0000 -- 100% complete.
OK
NAND write: device 0 offset 0x100000, size 0xa80000
11010048 bytes written: OK
ubi0: attaching mtd3
ubi0: scanning is finished
ubi0: volume 2 ("rootfs_data") re-sized from 9 to 910 LEBs
ubi0: attached mtd3 (name "ubi", size 127 MiB)
An env flash:
=> boot
resetting USB...
Bus ehci@50000: USB EHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
131072 bytes read in 13 ms (9.6 MiB/s)
flashing env 20000 bytes...
NAND erase.part: device 0 offset 0xe0000, size 0x20000
Erasing at 0xe0000 -- 100% complete.
OK
NAND write: device 0 offset 0xe0000, size 0x20000
131072 bytes written: OK
ubi0: attaching mtd3
ubi0: scanning is finished
ubi0: attached mtd3 (name "ubi", size 127 MiB)
And this is what it looks like when neither file is present:
> boot
resetting USB...
Bus ehci@50000: USB EHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
ubi0: attaching mtd3
ubi0: scanning is finished
ubi0: attached mtd3 (name "ubi", size 127 MiB)
Hi APCCV!
Just wanted to thank you for your amazing work on the DNS-320 OpenWrt port!
I had an old DNS-320 gathering dust after some unsuccessful Debian experiments. Your project gave it new life. Tonight I accidentally bricked it while trying to flash (erased the NAND completely!), but thanks to kwboot and your u-boot.kwb, I managed to recover it via serial console.
I successfully flashed env.bin, u-boot.kwb, and ubi.bin, and everything is working perfectly on v24.10.5-r1 !
Now I just need to configure my RAID1 setup and I'll have a fully functional NAS again.
Thank you so much for maintaining this project!
Awesome! And then there were four.
It's people like you that make me think of going through the hassle of PR-ing this into mainline. Thank you. I already have a 25.12.0-r3 image working, but it has a serious issue (not because of this work, but due to apk acting up on kirkwood devices). What I mean is that I'll keep updating this for a while, and if there is interest, sure, I'll try to mainline it.
What went wrong originally?
With the new u-boot and USB recovery, a simpler upgrade process might be something in the lines of:
Problem is u-boot can be picky with USB and some thumb drives out there can be really crappy.
Anyways... if you don't mind sharing what went wrong (and no worries - it happens) I can try make instructions cleaner or something.
Cheers!
Hi APCCV!
Thanks for the quick response! Really appreciate your work, and yes, mainlining this would be awesome for the community!
So about what happened - it was basically USB key confusion mixed with my limited u-boot experience. Your first post mentioned FAT32, but the commands used ext4load, so I went with FAT32 and fatload. I got a "No partition table" error when loading u-boot.kwb but proceeded anyway. Didn't catch any errors during flash, assumed it worked, ran nand erase... and wiped everything with nothing to replace it. Brick! 
Luckily I had serial console ready, so kwboot saved me. Loaded u-boot into RAM, then flashed env.bin, u-boot.kwb, and ubi.bin properly. That's when I hit the real USB issues - had to unplug/replug the key and retry almost every file load. Pretty sure it's the combo of crappy USB stick and the old DNS-320 USB controller acting up together.
For the docs, maybe clarify ext4 vs FAT32 upfront, and mention that loading files from USB can be unreliable on these devices - not sure if it's the USB controller, the stick itself, or some RAM issue, but people should verify filesize after each load and be ready to retry. Maybe include example outputs so users know what "success" looks like, something like 11010048 bytes read in 456 ms for a good load versus timeout errors or empty filesize. Would help catch issues before erasing the NAND.
Also, I put together a step-by-step recovery/installation guide documenting my experience - including what went wrong and expected outputs at each step. Made it with Claude AI's help. Feel free to use it if you think it's helpful: https://github.com/Freeflod/openwrt-dns320/blob/24.10.5/dns320-recovery-guide-en.md
That is a great writeup. Thank you.
I removed references to FAT32. Yes, that works with fatload and I flipflopped between both for a while. I prefer ext4fs because it requires consciously reformatting the USB drive instead of just picking whatever is around.
The recovery mechanism baked into u-boot requires ext4. Back again to the idea that the USB needs not be very normal or else some device will end up with that thing left plugged in and reflashing itself to a crisp.
If anything will get more people to try this out will be flashing without tear down. You were all set up to deal with anything. 
Thanks again for the writeup. Will reference the link on 1st post.