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

Unfortunately no one can be told what fun_plug is - you have to see it for yourself.

You are not logged in.

Announcement

#26 2008-11-06 18:42:49

anders55
New member
Registered: 2008-11-05
Posts: 3

Re: 128MB RAM Upgrade Details

wiki - http://dns323.kood.org/
Firmware 1.04 - U-Boot 1.7.3
Firmware 1.05 - U-Boot 1.7.3-5182

Offline

 

#27 2008-11-06 21:21:31

jdoering
Member
Registered: 2008-04-10
Posts: 95

Re: 128MB RAM Upgrade Details

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

Offline

 

#28 2009-09-16 17:01:17

mrbillions
Member
Registered: 2009-09-02
Posts: 16

Re: 128MB RAM Upgrade Details

that is way beyond me.....if anyone can do this upgrade in melbourne please email me....

Offline

 

#29 2010-09-20 20:52:14

HamRadio
Member
Registered: 2010-02-03
Posts: 12

Re: 128MB RAM Upgrade Details

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:

Code:

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

Code:

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

changing it with

Code:

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

Code:

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.

Offline

 

#30 2010-09-21 06:52:19

jdoering
Member
Registered: 2008-04-10
Posts: 95

Re: 128MB RAM Upgrade Details

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.

Offline

 

#31 2010-10-04 17:34:51

RoganDawes
Member
Registered: 2010-07-01
Posts: 44

Re: 128MB RAM Upgrade Details

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:

Code:

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)

Offline

 

#32 2010-10-05 12:32:02

HamRadio
Member
Registered: 2010-02-03
Posts: 12

Re: 128MB RAM Upgrade Details

Hi jdoering and RoganDawes, and thanks for your help.

RoganDawes wrote:

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

I'm considering if daring to make an attempt at modifying /dev/mtdblock4, or to build a jtag before...

RoganDawes wrote:

bootargs=root=/dev/md0 console=ttyS0,115200 rootfstype=ext4 x=xxxxx
with the "x=xxxxx" used to take up the extra space.

What about replacing the extra space with 0x00 (I've seen a lot of them into /dev/mtdblock4)?

RoganDawes wrote:

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

Why you say without a ramdisk?
My kernel is the standard 2.6.32-5-orion5x, which has raid and ext4 modules inside its initrd flashed on /dev/mtdblock3...

Offline

 

#33 2010-10-12 21:29:58

HamRadio
Member
Registered: 2010-02-03
Posts: 12

Re: 128MB RAM Upgrade Details

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

Code:

# 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!
smile   cool
I'm sure I will never do that again!big_smile

Offline

 

#34 2010-10-23 22:14:14

firemover
New member
Registered: 2010-10-23
Posts: 1

Re: 128MB RAM Upgrade Details

Hello!
After replacing the memory chips, and validate values of the U-BOOT to replace, I have a problem of finding the appropriate values.
If 03 00 01 FF in U-BOOT only once, then 10 60 A0 E3 four!
What better understand which of 10 60 A0 E3 must be changed?
I dont have JTAG  sad

Offline

 

#35 2010-10-24 20:25:31

jdoering
Member
Registered: 2008-04-10
Posts: 95

Re: 128MB RAM Upgrade Details

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

Offline

 

#36 2011-01-02 01:40:29

Roman-323
New member
Registered: 2011-01-02
Posts: 1

Re: 128MB RAM Upgrade Details

I install Debian (Kernel 2.6.32-2) on my DNS-323. Do I need patching U-Boot or no?

BTW... I know, that possible to use second USB from Marvell chip, but don't know how patching kernel config.. May be I need patching U-Boot also?

Last edited by Roman-323 (2011-01-02 02:01:10)

Offline

 

#37 2011-01-25 13:09:32

sala
Member / Site Admin
From: Estonia
Registered: 2006-07-28
Posts: 731
Website

Re: 128MB RAM Upgrade Details

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


DSM-G600 - NetBSD hdd-boot - 80GB Samsung SP0802N
NSA-220 - Gentoo armv5tel 20110121 hdd-boot - 2x 2TB WD WD20EADS

Offline

 

#38 2011-08-29 17:14:12

kirill
New member
Registered: 2008-10-07
Posts: 2

Re: 128MB RAM Upgrade Details

I've just upgraded memory on my DNS323.
Patching SDRAM0_BANK0_SIZE as described in the first post didn't help for me.
It seems to overwrite initial configuration with calculated value.

After studying the u-boot source, I've found two tables which hold SDRAM_CS0_SIZE value:

001d8a0: ffff ffff 0000 0000 0000 0000 0000 0004  ................
001d8b0: ffff ffff 0100 0000 0000 0010 0000 0000  ................
001d8c0: 0000 0010 ffff ffff 0000 0000 0000 0020  ...............
001d8d0: 0000 0000 0000 0010 ffff ffff 0000 0000  ................
001d8e0: 0000 0030 0000 0000 0000 0010 ffff ffff  ...0............

and

001d9c0: ffff ffff 0000 0000 0000 0000 0000 0004  ................
001d9d0: 0100 0000 0000 0010 0000 0000 0000 0010  ................
001d9e0: 0100 0000 0000 0020 0000 0000 0000 0010  ....... ........
001d9f0: 0100 0000 0000 0030 0000 0000 0000 0010  .......0........

0000 0004 in both tables is 0x40000000 = 64MB
I've replaced it with 0x80000000 and it worked.
SDRAM density config patched as described initially (same instruction  e3a06010).

uboot info:

** LOADER **
** MARVELL BOARD: RD-88F5181-POS-NAS LE

U-Boot 1.1.1 (Nov 13 2006 - 14:01:34) Marvell version: 1.4.2
DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB

Last edited by kirill (2011-08-29 17:16:17)

Offline

 

#39 2012-09-22 10:49:25

Keon91
Member
Registered: 2011-03-03
Posts: 24

Re: 128MB RAM Upgrade Details

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?

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2010 PunBB