Could you point out how I may do that, as if I can boot the image then I can try to flash the firmware from that boot environment!
Thanks
Hi,
Are you the same person who emailed me about this issue?
Digging around, I can see where the error you're getting is coming from. It looks like newer uboot configurations run chk_dniimg before booting, which assumes that there are three concatenated legacy uboot images.
The version that I have doesn't do this, but does still have the failing chk_dniimg command, which can be ran like:
VR9 # sf probe 3
8192 KiB W25Q64 at 0:3 is now current device
VR9 # sf read $loadaddr 0x30000 0x710000
VR9 # chk_dniimg $loadaddr
** check the 1 image **
Verifying Checksum ... OK
** check the 2 image **
** Bad Magic Number 0x61aabbb4 **
What a pain. If you just want to get it working, then you could try modifying CONFIG_BOOTCOMMAND in uboot to bypass this check. I don't know what risk this carries, however; it might be possible to lock yourself out doing this.
We should fix this in the image, but I'm not sure how, yet.
T
Hi!
Yes, that was me who emailed (cito)
You prefer I answer back via emails or keep this in the public support forum ?
Is this the correct way to modify the bootcmd parameters ?
setenv bootcmd sleep 1;nmrp;sf probe 0:3; sf read $loadaddr 0x30000 0x710000; fi
I am hoping its just a matter of removing the chk_dniimg construct from the bootcmd, here is the current bootcmd
setenv bootcmd sleep 1;nmrp;sf probe 0:3; sf read $loadaddr 0x30000 0x710000;if chk_dniimg $loadaddr; then bootm $loadaddr;else fw_recovery; fi
As you kindly pointed out the reason for the "Bad Magic Number" hopefully its just a matter of removing chk_dniimg construct from the bootcmd variable .......
OK, i can change the bootcmd (im not issuing a save!).
Have new error message once I initiate a simple 'bootm'
bootcmd=sleep 1;nmrp;sf probe 0:3;sf read $loadaddr 0x30000 0x710000; fi
Environment size: 3932/8188 bytes
VR9 # bootm
## Booting kernel from Legacy Image at 80100000 ...
Image Name: u-boot image
Created: 2016-03-03 5:08:00 UTC
Image Type: MIPS Linux Firmware (lzma compressed)
Data Size: 58240 Bytes = 56.9 KiB
Load Address: a0400000
Entry Point: a0400000
Verifying Checksum ... OK
Wrong Image Type for bootm command
ERROR: can't get kernel image!
Hopefully someone will point out to me what memory address allocation I should be pointing the bootm command to....
** edit **
Actually, the 'ammended' bootcmd is getting added at the very end of the environment variables, is this going to effect the bootm process as without the ammendement the bootcmd variable is right at the top of the environment variables list when we issue a 'printenv' command ???
You could try running these commands to see if it boots?
sf probe 0:3
sf read $loadaddr 0x30000 0x710000
bootm $loadaddr
Your bootcmd would need to contain something like this:
sleep 1;nmrp;sf probe 0:3;sf read $loadaddr 0x30000 0x710000;bootm $loadaddr
I'm not sure about the quoting rules, however. It looks like the command to test this would be just boot, but I can't test this.
Anyway, could you just wait for a few days while I try to work around this in the firmware? It would be good to have someone to test it so that I don't have to buy a third DM200...
T
Hi! Very much appreciate your continued assistance.
I have two DM200 that we can test with!
Will attempt the things you suggested and report back.
Great, that successfully booted to lede, have access to the filesystem via winscp
Now to get a permenant workaround 
OK, this worked for me as temporary fix so that device can be turned off/rebooted and not stop at the chk_dniimg function
Boot into serial environment, then
setenv bootcmd --> Press Enter
setenv bootcmd sleep 1\;nmrp\;sf probe 0:3\;sf read \$loadaddr 0x30000 0x710000\;bootm \$loadaddr --> Press Enter
saveenv --> Press Enter
Now on shutdown/reboot the device does not stop at the chk_dniimg as the check is removed from the bootcmd sequence
So at least for now we have a workaround
Would not be possible without tomn help! Much appreciated
I've attempted a fix here:
https://github.com/tomjnixon/lede-source/tree/fix-dm200-boot
If you could give it a try (with the original bootcmd) that would be helpfull. I think it should work (it passes the chk_dniimg on my device), but I don't have any real way of testing.
I've put some pre-compiled images here if that's easier:
Hi tomn,
I can confirm that after restoring the original bootcmd, restoring to the OEM firmware than flashing from the Netgear GUI interface the factory.img is working without triggering any errors.
I.e. the image boots OK
Though I was not able to install any packages with this image I imagine you created this just to test if it would boot correctly, which it does.
Thanks
Great, thanks for trying it out!
I don't see why installing packages wouldn't work. Is this just a compatibility issue between build environments?
What exactly is wrong with it? What did you try, and in what way didn't it work? Did this work on the snapshot image?
Hi tomn,
I loaded the firmware you created, connected the device to the Internet and ran 'opkg update', than when I tried to install any package for example 'opkg install luci' I got an error message.
Just to confirm I wasnt doing something incorrectly, I downloaded the latest snapshot from lede for the dm200 and did exactly the same procedure and I could install the luci package with no issues.
Thats when I assumed the image you created was gimped and hence asked the question.
Hey @tomn
I've used your patch for my DM200 builds with great success on the two devices I have. Could we get this merged into master?
Also, if it's of interest to you, there's issues with ADSL2+ Annex B, and likely Annex A too on kernel 4.14. Seems fine on 4.9
Sorry for the delay, I've been busy with other things.
Thanks for giving it a go; yeah, I'll submit it soon.
Interesting, but this doesn't surprise me; last time I tried this I struggled to make it run at all; perhaps some progress has been made...
The luci feed is just not enabled; you can uncomment it in /etc/opkg/distfeeds.conf. This is a configuration option, but I didn't change it. I'm not sure why it's disabled by default.
In general, if you get an error message, please post it! Just saying that you got an error message is not that helpful.
Ok, this should be fixed in the latest snapshot (after 8c88e23); thanks all!
Total n00b here, how easy is it to use these devices as PPPOE modems with OpenWRT?
I've just slapped the provided image on and can SSH to my devices (cheers!) just fine.
The problem I've been having is I was trying to use these modems (which aren't really modems, at least not out of the box) as PPPoE devices from FreeBSD / Pfsense. After a few hours of trying I realised they are operating in some funky bridge mode, where the credentials from the PC are simply ignored, as is the request to Multilink...
Anyway that's how I found my self here and all I'd like to know is the easiest / most straightforward way of getting several of these devices connected to pfsense or similar, bonding my lines together, pretty simple, huh?
Any pointers to forums etc. which may have a "spoon feed" guide would be very much appreciated.
Ta!
TH
Read up LEDE Installation Guide for HH5A, "9.8 Bridge mode for VDSL Connection" should apply with only minimal adaptions for your device.
Many thanks!
I must admit I'm truly amazed by this project. I've previously not been into open source router stuff because all I knew about was Tomato and that (at the time) didn't really like supporting modems at all...
This is all connecting back to our own network and Cisco LNS's, I'd be more than happy to donate any resources required, perhaps a few servers, some lines for research / dev. If there are any mods watching this thread
Not having much luck here, I'm just trying to use this as a modem, I've bridged the DSL and LAN ports but no go....