Optimized build for the D-Link DIR-860L

I am upgrading from r12255, will try without -n option but I am not confident it will make any difference. PS: just for fun I tried also to upgrade from recovery with factory bin file, but it is the same (no settings kept after reboot)

Might be because I have stripped out debug info. Needs more testing

You can use the script but you have to modify the board names. Newer build that I am on has a few fixes, uptime is over 2 days and I only have:

ERR: 352

Usage: /sbin/sysupgrade [<upgrade-option>...] <image file or URL>
       /sbin/sysupgrade [-q] [-i] [-c] [-u] [-o] [-k] <backup-command> <file>

        -f <config>  restore configuration from .tar.gz (file or url)
        -i           interactive mode
        -c           attempt to preserve all changed files in /etc/
        -o           attempt to preserve all changed files in /, except those
                     from packages but including changed confs.
        -u           skip from backup files that are equal to those in /rom
>>      -n           do not save configuration over reflash
        -p           do not attempt to restore the partition table after flash.
        -k           include in backup a list of current installed packages at
        -T | --test
                     Verify image and config .tar.gz but do not actually flash.
        -F | --force
                     Flash image even if image checks fail, this is dangerous!
        -q           less verbose
        -v           more verbose
        -h | --help  display this help

        -b | --create-backup <file>
                     create .tar.gz of files specified in sysupgrade.conf
                     then exit. Does not flash an image. If file is '-',
                     i.e. stdout, verbosity is set to 0 (i.e. quiet).
        -r | --restore-backup <file>
                     restore a .tar.gz created with sysupgrade -b
                     then exit. Does not flash an image. If file is '-',
                     the archive is read from stdin.
        -l | --list-backup
                     list the files that would be backed up when calling
                     sysupgrade -b. Does not create a backup file.

-n is kind of a weird flag. From the description is not entirely clear to me what it exactly does. Do other builds flash just fine, master and/or 19.07?

No luck with keeping the settings following a reboot either, I'm by no means an expert but it appears to be an issue with JFFS2.

Upon a new flash (or following "firstboot") the mounts are as follows:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.3M      8.3M         0 100% /rom
tmpfs                    59.6M    504.0K     59.1M   1% /tmp
tmpfs                    59.6M    112.0K     59.5M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock8            5.1M    296.0K      4.8M   6% /overlay
overlayfs:/overlay        5.1M    296.0K      4.8M   6% /

Following a reboot overlayfs gets mounted to tmpfs, as such:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.3M      8.3M         0 100% /rom
tmpfs                    59.6M    496.0K     59.1M   1% /tmp
tmpfs                    59.6M    116.0K     59.5M   0% /tmp/root
overlayfs:/tmp/root      59.6M    116.0K     59.5M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

I tried numerous flashing methods, including going back to stock and to openwrt from there (oddly enough going back to stock some previous stock settings such as SSID names had been retained).

I've been reading up but can't seem to find a definitive cause for this...

Could anyone more "enlightened" share their thoughts on this? :slight_smile:

1 Like

In case someone is interested about the dir-860l general's stability, this is a stock 19.07.1 installation that I am about to upgrade to 19.07.4:

root@OpenWrt:~# uptime
 08:56:47 up 200 days, 15:21,  load average: 0.04, 0.03, 0.00

I just happened to be catching up on this thread...

I have the same issue on ath79 and haven't found any mentions of it. On a freshly built image I see log entries saying it failed to mount /overlay and something about it using ramdisk instead (hence no configs are retained over a reboot).

Did you find anything since you wrote this?

@Bartvz you asked a question further back that indicates you might also have the issue, any idea where this was introduced? I haven't had time to work back and find the commit

I don't follow this thread that close as I don't have 860l anymore, however there is this in the 19.07.4 changelog:

Device support: images for some device became too big to support a persistent overlay, causing such devices to lose configuration after a reboot. If you experience this problem, please report the affected device in the forum and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image

1 Like

Thanks for the heads up, however I believe that 16Mb flash at this point in time should be sufficient, also it might be worth noting that dev/root has actually decreased from 8.8Mb in 12255 to 8.3 in the latest optimized build, whilst dev/mtdblock8 (overlays) has remained the same size - 5.1Mb.

Could it be a JFFS2 configuration issue? (its odd that on first boot overlays get mounted fine, but in subsequent boots it defaults to ramdisk)

Just installed 19.07.4 over snapshot r12255 (bart's build) directly from Luci.
The setting backup didn't work, but once configured the settings by hand, they were kept after reboot.

Isn't 19.07.04 numerous buids/commits behind 12255, respectively older mt76 driver?

Yes, and older kernel as well.

1 Like

FWIW, custom build but OpenWrt SNAPSHOT, r14101-5d8fded26a runs fine (and saves settings) with a few custom patches (performance related).


Could you please point me towards where I can get it from?

Mind sharing these? Sounds interesting :slight_smile:


Nothing much, just enforcing -O2, MT (-mmt), no MIPS16 instructions and enforcing 24Kc optimization. If anything O2 should give the most impact but don't expect wonders.

https://github.com/diizzyy/openwrt/commit/585b52930c229b0511bfed46614718abb0c7c64c (just set it to -O2 to enforce it globally)

Might also be of interest in general


no way :frowning:
I updated without -n option but I am still losing settings after reboot on r14284

root@OpenWrt:/tmp# sysupgrade -v -F /tmp/openwrt-ramips-mt7621-dlink_dir-860l-b1
Device dir-860l-b1 not supported by this image
Supported devices: dlink,dir-860l-b1 dir-860l-b1 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA (early adopters with DSA already set up may just force-flash keeping existing config)
Image check failed but --force given - will update anyway!
Saving config files...
Commencing upgrade. Closing all shell sessions.
Connection to closed by remote host.
Connection to closed.

Your initial image is too old so not compatible. If you delete /etc/config/network before upgrade, you may keep other settings if lucky enough.

With big upgrade like this one, it's recommended to start configuration from scratch.

I didn't try to save settings during the update, I installed latest Bartz build (r14284) and reconfigured it from scratch.
The bug is that, even if reconfigured by scratch, at every boot the settings are lost.
I tried clean update from Luci, sysupgrade with different options, factory bin installed from D-Link recovery, double flash, hardware reset after flashing, but no way to keep the settings on reboot using optimized r14284.

But guys, I have also a good news.
Once installed latest snapshot (r14468), "the settings reset bug" has gone!
I didn't check the commits but the problem has been solved.

@Bartvz , checking discussions on openwrt archive I found https://forum.archive.openwrt.org/viewtopic.php?id=35323 , some benchmarks have better results with -O2 opt flag and 24Kc optimization. Would it be a good idea to insert them in next build?

1 Like

To me, and I could be wrong, it looks like something is wrong with the mountpoints. The strange thing is that not everyone's DIR860L is affected. Has anyone tried flashing my build from D-Link's recovery? (not relevant but breed bootloader on my MIR3G is seriously cool. It is easy to flash and switch between two firmware partitions :slight_smile:

So to answer my question, flashing from D-Link recocery does not work. Makes me wonder if there are some DIR860L's with different memory chips.

Os should give around thesame performance, only some potentially code breaking optimizations do not get used. Why no MIPS16 instructions though? From what I understand they should process quicker.
The CoDel hack is interesting how much better does it perform as compared to regular CoDel?
And, ofcourse the million dollar question is, is there also such a hack for CAKE, CoDel's successor?

Currently testing, r14465

1 Like

My builds uses the Os flag which should give around the same performance since only a couple of potentially code-breaking performance optimizations are not enabled as compared to O2. In addition my builds use the -march=1004k flag which should optimize code better than the -mtune flag.

1 Like

O2 is almost always faster than Os irregardless of platform at least using GCC. I did some a while back but you can find a lot of benchmarks showing the same general trend. MIPS16 pretty much always seems to degrade performance in favor of smaller binaries, 16Mb flash is large each for at least what I want to include. I haven't benchmarked the CoDeL hack so I cannot say however I try to avoid to derive from upstream if possible.

1 Like