Please don't let this pull request drop! This works beautifully. It seriously breathes new life into DIR-825 B1 routers.
If you have one of these, please test it and comment on github.
1 Like
Hey Pilot,
Not sure if you got clear answer for your questions but in case you didn't, sharing my most recent experience:
- the u-boot recovery mechanism doesn't use the unknown partition. I soft bricked one of my routers when trying to remove the fat image and move the caldata back to where it belongs. Since it was a fat image, it is certain it was overwritten with data and no longer stock.
- the recovery page works great with the small C program on the DIR-825 page, provided ETH speed is lowered to 100MBit full duplex. I managed to restore a v18 firmware image (the latest that has a backup loader version) AND also restored a stock image I had around (yuck!). Both worked.
- The unknown image remained zeroed out after I restored v18 after restoring stock firmware. Could be that the v18 image erased it but it shouldn't have.
My guess is that D-Link left that space unused because their FW had some limitation on how far into the flash it could find the CALDATA, or they needed to limit the rootfs space to less than 4M. I seriously doubt space was unallocated for wear levelling as I don't think this thing is that sophisticated.
Hope that helps... and gets us closer to having this as part of the standard image.
I did some basic experiments with the unknown partition
I did have some bits of data located on both of my 2 units
from when I backed them up way back when
how ever I then erased one and after installing & updating the OEM firmware
it changed or initialised it on some way "not all blank"
how ever it was different to the data I had backed up from new
my guess is that maybe it's country specific ISP Data or something
how every I didn't notice anything missing but it's been so long sine
I used the oem firmware but it did run & look fine
I had to recover another router through the backup loader and I did not see any data to the "unknown" partition. This time I just used a standard v18 image.
@Lucky1, I have two suggestions to make to your patch:
- shorten the second concatenated partition to leave the original caldata backup in place, and create a partition for it. Great if it is still there (arguably for most people). No harm other than slightly less space if it was lost. Hopefully will make everyone less reluctant to accept the pull request.
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "u-boot";
reg = <0x000000 0x040000>;
read-only;
};
partition@40000 {
label = "config";
reg = <0x040000 0x010000>;
read-only;
};
fwconcat0: partition@50000 {
label = "fwconcat0";
reg = <0x050000 0x610000>;
};
partition@660000 {
label = "caldata";
reg = <0x660000 0x010000>;
read-only;
};
fwconcat1: partition@670000 {
label = "fwconcat1";
reg = <0x670000 0x180000>;
};
partition@7F0000 {
label = "calbkup";
reg = <0x7F0000 0x010000>;
read-only;
};
};
};
- extend the max size of image for imagemaker. It was refusing to build my standard camera image because it is too large for standard size. Change IMAGE_SIZE := 7680k in file:
define Device/dlink_dir-825-b1
SOC := ar7161
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DIR-825
DEVICE_VARIANT := B1
IMAGE_SIZE := 7680k
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | \
append-metadata | check-size
DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport \
kmod-leds-reset kmod-owl-loader
SUPPORTED_DEVICES += dir-825-b1
endef
TARGET_DEVICES += dlink_dir-825-b1
I've been using this in four routers with zero issues so far with sysupgrade or the backup loader.
This device still has some use, and it's running out of space. I can't advocate enough for this to be merged in before the standard image becomes to large and it gets dropped from automatic builds.
shorten the second concatenated partition to leave the original caldata backup in place
but there is no data there by default it's only a creation of the use of a BIG image to put it there
& if you do recover it's not written over until programs are added to use the room
a cold change the layout to make an MTD backup easier
but people should already have a backup of cal data as recommended when updating to the big image
extend the max size of image for imagemaker. It was refusing to build my standard camera image because it is too large for standard size. Change IMAGE_SIZE := 7680k in file:
the Up loadable image size limitations have not changed
they are still limited to fwcancat0 only
any bigger if allowed would write over the caldata
so there can not be any change to image size "at lest on that device model"
none of this is ideal it's all bandaids
splitting the device into another model with a big type image
with the cal data officially permanently moved
only then the image size could change
but there would be at lest
factory image old V18
intermediate model change image "BIG" that will move cal data & accept lager uploads
then the bigger image expecting new caldata location and a single large firmware partition
and then you will have recovery problems or make a specific V18 factually image for recovery only
any enthusiast can do this them self but I admit no convenient
my pull request was only in context of fixing/extending V21 "but must go through master"
as at the time I was expecting V22 kernel to be to big for upload from V18 & the device
to be removed
sadly with the current way openwrt pull requests go I have lost interest
as really pull request are to help others who can't do it
but as it seems to take so long its not worth bothering with
I recommend that you make a pull request your self
as you seam to still have enthusiasm for it
if it helps I'll even put mine 
Hiya,
Well... caldata-backup was there in the OEM layout, methinks. I can't tell if it had anything... fat images nuked the contents long ago. I agree it is useless, but I vaguely remember another post on forums where someone took offense that the ath79 port removed it. Regardless... not that important, really. Let's forget about it.
You are right. I already have a concat-ed image flashed, so flashing long images keep the caldata safe. But if I were to flash a V18 image and then flash a long image I'll nuke the caldata. Thank you for pointing that out. I might have learnt that the hard way.
I understand. That is unfortunate. I may have the enthusiasm but not the skill or time. Might do as you say, figure it out, and create a new pull request. A bit of a pity because even without the (I admit) not so great ideas above, the patch you have is really good and it's almost there. In best of theories it just needs 3 more people to test it & accept it.
I don't care if it makes it to v23... V22 still keeps this device as a target. My concern is that eventually kernel becomes to large and device is dropped. That might be unavoidable.
Thanks for getting this as far as you did. Cheers!
1 Like
Built an image. Works well. It is in repo below if that makes testing easier in bin folder.
1 Like