DSM-G600, DNS-3xx and NSA-220 Hack Forum

I don't think mine changed during upgrade and I didn't repatch post-upgrade; but maybe I'm mistaken. I'd be very surprised if the patching steps are different; although the actual offsets easily could be (the first post describes how to discover the offsets).

-Jeff

jdoering wrote:

dd if=uboot.bin of=/dev/mtdblock4 bs=1 skip=5323 seek=5323 count=1 conv=notrunc
dd if=uboot.bin of=/dev/mtdblock4 bs=1 skip=3632 seek=3632 count=1 conv=notrunc

Hi jdoering,

is there a particular reason for which you didn't just:

dd if=uboot.bin of=/dev/mtdblock4

writing the whole file?

On my DNS323 with Debian Lenny installed as described here, on which I added a serial port, I'd need to get rid of the parameter

bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none

changing it with

bootargs=root=/dev/md0 console=ttyS0,115200 rootfstype=ext4

so I think I'd have to edit uboot.bin (the same dump of your /dev/mtdblock4) with ghex2 and then

dd if=uboot.bin of=/dev/mtdblock4

What do you think about?
In case something should go wrong, could it be enough to dd the original dump of /dev/mtdblock4 back again?
Thanks for answering.

jdoering wrote:

Given no JTAG setup; I wanted to minimize the overwriting of u-boot as much as possible. You're right that just doing the whole thing should have worked but I figured that it couldn't hurt to keep the modification surgical.

In your case my bias would be to do the same thing and only overwrite the data your changing. Your case looks a bit more complicated since the length of the data is changing. I'm expect it will be fine as long as the length is determined by a termination character and you have the extra space (and that the sequence is at the end so it doesn't shift anything else). But I'd definitely be careful and triple-check everything.

The problem with the strategy of dd'ing back the original /dev/mtdblock4 is that I assume if something goes wrong your machine won't boot into Linux anymore. If you kill u-boot it's game over without JTAG. If you just break Linux booting but not u-boot itself then you might be able to recover using the u-boot console and forcing a boot. But I'm definitely not experienced with that angle. RoganDawes can probably speak to that.

But overall; I'd start with the assumption that if something goes wrong you'll need JTAG to correct.

Sorry for the late response.

There should not be any real difference between making the changes to a copy of the u-boot mtd4, then dd'ing the whole thing back, vs making the changes directly to the specific bytes within mtd4.

Personally, my approach would be something like:

dd if=/dev/mtdblock4 of=/tmp/mtdblock4
cp /tmp/mtdblock4 /tmp/mtdblock4.bak
... make suitable changes to /tmp/mtdblock4
diff /dev/mtdblock4 /tmp/mtdblock4
... make sure the diffs are as expected.
dd if=/tmp/mtdblock4 of=/dev/mtdblock4
diff /dev/mtdblock4 /tmp/mtdblock4
... make sure there is no diff

before rebooting.

As jdoering says, though: If something goes wrong, without JTAG, you're screwed.

w.r.t modifying the command line arguments, you should be ok, I think. Just fill the extra space with bogus parameters.

i.e.

bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none

becomes

bootargs=root=/dev/md0 console=ttyS0,115200 rootfstype=ext4 x=xxxxx

with the "x=xxxxx" used to take up the extra space.

Last edit: Just make sure that your kernel can mount /dev/md0 without a ramdisk :-)

Last edited by RoganDawes (2010-10-04 17:57:04)

Hi everyone,
today I felt courageous enough so, after editing with ghex2 a copy of /dev/mtdblock4 according to my needs, I dared to:

# dd if=mtdblock4 of=/dev/mtdblock4
384+0 records in
384+0 records out
196608 bytes (197 kB) copied, 3.69964 s, 53.1 kB/s

Everything went fine, and after reboot u-boot was happily working with all my custom bootargs!
   
I'm sure I will never do that again!

I think the only safe way is to disassemble the data surrounding 1060A0E3 occurrences and see whether or not there are references to other memory configuration addresses nearby. In my example there was only one 1060A0E3 and it definitely was surrounded by other memory initialization instructions. I bet one of your occurrences will match the same pattern (hopefully not multiple of them).

Probably not the simple answer you were hoping for. BTW you didn't mention your firmware/U-Boot version - out of curiousity what is it?

-Jeff

HamRadio wrote:

I'd need to get rid of the parameter

Code:

bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none

changing it with

Code:

bootargs=root=/dev/md0 console=ttyS0,115200 rootfstype=ext4

Well, just wanted to let you know that it is possible to patch kernel source to ignore bootargs and set your own using CONFIG_CMDLINE
Here is an a example for 2.6.18 kernel. Look setup.c part only.
http://dns323.kood.org/downloads/people … base.patch

I already made an backup from the uboot using: "dd if=/dev/mtdblock4 of=uboot.bin"
and I found the  “01 00 ff 03” value at the right ofset:  0x14C8 and  "10 60 A0 E3" at the ofset of:  0xE30.

joering discribes that you need to patch these values: 
0x14C8 (decimal 5323)  3 -> 7
0xE30 (decimal 3632) 1 -> 2

What I understand from this is that the values need to be changed to : 
“01 00 ff 07” at  0x14CB
"20 60 A0 E3" at  0xE30

maybe someone can confirm if I'm right here?