Hi,
touche, im no expert either 
I have oh so many pieces of the puzzle, actually I have more pieces than the actual puzzle!
1/ Never assume anything, lol
2/ My device is bricked in that to an 'average' user it would be completely disfuntional
3/ The device is in recovery mode so obviously no DHCP works
FYI, I have a serial ttl console that I am using to access and recover the DM200
You are doing exactly what I was doing and that is making educated guesses. Unfortunately it will be me who totally bricks the device if I erase the wrong area of the RAM, hence the reason I was asking for assistance from someone who knew what they were doing, LOL
The erase command is not recognized in this version of uboot that is on this Netgear.
It seems to me that something has been broken in the snapshots, as other peeps have been successfully flashing there DM200's.
I have two here and both get bricked when flashing through the Netgear interface with a "bad magic number" error message.
Have to recover with tftp method...............
So as things stand, no expert is willing to provide any assistance
Hi again!
After flashing from the Netgear GUI the device goes into 'recovery mode'
Exact message below
** check the 1 image **
Verifying Checksum ... OK
** check the 2 image **
** Bad Magic Number ** 0xc5a65360 **
The router is in TFTP Server Firmware Recovery mode NOW!
Listening on Port : 69, IP Address: 192.168.5.1
Upgrade Mode (This part is flashing)
Thats as far as the boot process goes.
In this state the device will accept firmware pushed to it via tftp transfer.
Will post in next post the uboot commands that are available..............
uboot commands:
? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
chk_dniimg- check integrity of dni firmware image.
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
exit - exit script
false - do nothing, unsuccessfully
fw_recovery- fw_recovery - start tftp server to recovery dni firmware image.
go - start application at address 'addr'
help - print command description/usage
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
nmrp - nmrp - start nmrp mechanism to upgrade firmware-image or string-table.
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
set_hw_id- Set hw_id
set_mac - Set ethernet MAC address
set_model_id- Set model_id
set_parameters- Set <serial number>, <lan mac>, <wan mac>,
set_region- Set region number
set_serial- Set serial number
setenv - set environment variables
sf - SPI flash sub-system
show_hw_id- Show hw_id
show_mac- Show ethernet MAC addresses
show_model_id- Show model_id
show_parameters- Show hw_id, model_id, region number, serial number, MAC address.
show_region- Show <region number> on Board
show_serial- Show <serial number> on Board
showvar - print local hushshell variables
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true - do nothing, successfully
upgrade - upgrade - forward/backward copy memory to pre-defined flash location
version - print monitor versionCould 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!