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

sala wrote:

Serial console part of this kernel is very tricky and probably the hardest thing to get it working, but without it theres nothing. I have tried couple of times this myself, I did use loader.o and I did try to flash but after loading it by loader.o or uboot serial just dies.

I'm not quite sure that I understood you correctly: I shouldn't really hope for serial output after using loader.o or 2.6 kernel didn't produce any output on serial?

sala wrote:

First try to load just regular D-Link kernel with loader.o and make sure that you got it working and understand how it works.

I did. I also loaded both your and my own 2.4 kernel. And they work without a problem with /dev/sda3.

sala wrote:

Second, there is many other parts you need to patch for example to get serial console support, mtd support, all speeds at correct level and so on. I am no a kernel hacker but KuroBox patch is good example about these thing you need to do.

Yap, yap. But, KuroBox patch is more complicated because it has to add another platform. However, if you ignore that (and we already have support for SandPoint) you will see that KuroBox patch justadds driver for Ricoh 5C372 RTC. As far as mtd is concerned, I was hoping that CFI will do the work (as it does in 2.4 kernel), so we don't need static table.

But, first step would be to get kernel to recognize network card (or boot at all), so I'll wait for serial port first (hopefully next week if other things don't get in the way).

Last edited by dpavlin (2007-05-05 01:21:40)

Just to update this topic with progress so far:

I have now serial port, and don't have any problems with serial port output after booting new kernel with loader.o (if anyone is wondering :-)

Also, as a first step toward 2.6 (which doesn't work out-of-the-tar) is to port all changes from D-Link (actually, MontaVista, it seems) kernel up to current 2.4 kernel. Idea was to get intimate knowledge about changes required to boot this particular board before moving to 2.6 kernel.

Diff generated between kernel versions isn't really useful, so I opted to use comments found within source and located Bing, Wilson, jackl and REXX are names which are mentioned in comments. After close inspection of all changes (vim -d rules!) I have 2.4.34.4 which boots up to the point where SCSI driver tries to read partition table (and times out).

Since my goal isn't really 2.4 kernel, I will now move to 2.6 kernel since I have some understanding how to init board and serial port.

sala wrote:

Nice work with 2.4.34.4 patch

I'm quite disappointed that it just doesn't work, but conversation with two local linux hackers didn't turn out any useful info (other than printk debugging). I suspect that interrupts aren't handled properly (serial port is mmaped, so it's not using irqs). I will have to talk to real kernel developer (CREDITS one :-) which is good friend of mine to track this one down.

Update: conventional wisdom of Linux hackers seens to suggest initrd, as a nice way to poke around bootable and somewhat broken kernel.

Last edited by dpavlin (2007-05-19 00:49:49)

Just a small update: I have documented all board-specific stuff that I can find in D-Link source and ported them (again) to current powerpc 2.6 tree (which supports KuroBox as is, for example, and I found another patch for device which is quite similar to DSM).

As of first compile, it doesn't work :-)

But, I still don't quite understand IRQ mappings on this device, and this will take a bit more of kernel reading to do. But, it's a really enjoyable experience.

For those of you who would like to help with exploration just a quick note that there is option called early serial console which is use like this: console=uart,mmio,0xfc004500,9600n8

I don't really know if this code is in 2.4 kernel, but my first priority is to get something out on serial port after I start 2.6 kernel. JTAG would help a lot, shame I didn't order development board with OpenMoko :-(

Any idea how to plug JTAG into DSM-G600? I'm not a hardware guy, so just looking at a board doesn't mean much to me.

Last edited by dpavlin (2007-09-02 16:12:13)

i am interested in porting a new (usable) uboot as this is what seems to be the limitation for any new kernel devel

I checked out dpavlins u-boot and uloader. I was able to compile u-boot.bin and uloader.o, but when i insmod it I get the following (and nothing like uboot - maybe im doing something wrong):

./uload.sh
Using /mnt/HD_a2/kurobox_uboot/ululoader module loaded
oauboot=/mnt/HD_a2/kurobox_uboot/u-boot.bin<--
dealloc_high_page c1498000 __pa: 01498000
r.loading /mnt/HD_a2/kurobox_uboot/u-boot.bin 115168 bytes
alloc_high_page c1047000 __pa: 01047000

alloc_high_page c1042000 __pa: 01042000
alloc_high_page c103a000 __pa: 0103a000
alloc_high_page c1039000 __pa: 01039000
alloc_high_page c1038000 __pa: 01038000
alloc_high_page c1037000 __pa: 01037000
alloc_high_page c1027000 __pa: 01027000
alloc_high_page c1026000 __pa: 01026000
alloc_high_page c1025000 __pa: 01025000
alloc_high_page c1024000 __pa: 01024000
alloc_high_page c1023000 __pa: 01023000
alloc_high_page c1022000 __pa: 01022000
alloc_high_page c101d000 __pa: 0101d000
alloc_high_page c101c000 __pa: 0101c000
alloc_high_page c101b000 __pa: 0101b000
alloc_high_page c101a000 __pa: 0101a000
alloc_high_page c1019000 __pa: 01019000
alloc_high_page c1018000 __pa: 01018000
alloc_high_page c1017000 __pa: 01017000
alloc_high_page c1016000 __pa: 01016000
alloc_high_page c1015000 __pa: 01015000
alloc_high_page c1014000 __pa: 01014000
alloc_high_page c1013000 __pa: 01013000
alloc_high_page c1012000 __pa: 01012000
alloc_high_page c1011000 __pa: 01011000
alloc_high_page c1010000 __pa: 01010000
alloc_high_page c100f000 __pa: 0100f000
alloc_high_page c100e000 __pa: 0100e000
alloc_high_page c100d000 __pa: 0100d000
loaded /mnt/HD_a2/kurobox_uboot/u-boot.bin
return code 0
BusyBox v1.00 (2007.01.28-20:15+0000) multi-call binary

Usage: init

#

apparently

init 6

doesnt do anything like a reset/reboot
i try reboot, but just get:

# reboot
The system is going down NOW !!
Sending SIGTERM to all processes.
Please stand by while rebooting the system.
¡(((((((((((hhhhhhhhhhh((((((¨è

and the box is dead. No serial console, no activity. I have to powercycle

Anybody (dpavlin) get uboot ram image to load via uloader.o and if so, how did you do it?

Thanks,
Jens

u-boot is equivalent to the BIOS on your PC.  The u-boot on the dsm-g600 is a very limited one, it only as a few functions enabled and no room in the flash for more.  While it is possible to compile a new u-boot, that u-boot would have to be written to flash, also possible.  But if the new u-boot has any problem that prevents it from running your dsm-g600 will be a brick with a blinking light.  The only way to recover at that point would be to use the JTAG interface which is not configured from the factory and I don't know anybody who has figured out how to enable it.

jens wrote:

Yes,
but in order to get there, we need to build a working u-boot first. Ideally it would have usb, net (tftp, bootp) support, etc and of course we have to get scsi support to boot from sda
...

Please correct me if any of this sounds wrong.

First you will need to repartition the flash as the current flash layout does not allow for ANY added features.  Changing the flash layout makes the new u-boot and order of magnitude harder to develop.  I give anybody trying this a 90% of creating at least one brick.

Effecyively you can not do u-boot development with out a way to reprogram the flash using J-tag.

You may need a new u-boot, but to get a new u-boot you will have to enable the j-tag interface.

I think the Kurobox has a working J-tag.  If somebody can figure out how to enable the j-tag on the DSM G600, I'm willing to give it a try, but it looks like d-link is getting ready to end-of-life this hardware so I don't know howmuch life there is left in it.

jens,

Good job on your JTAG hack.

Maybe you should try to get 2.4 working first.  Then perhaps, some of us might be able to jump in and add improvements.  I have a feeling 2.6 wouldn't be that easy of a job, but with your expertise I'm sure sooner or later you'll figure it out.

Just curious, what if you comment out the real-time clock code in the kernel and see if it boots faster, then come back to the real-time clock code and figure out why.

--
Quang

Great news. Sorry, for not responding sooner, but somehow I neglected my DSM-G600 and this forum, it seems :-)

Where is that patch available?

I guess my biggest issue is: which kernel arch do you build in? powerpc or ppc? what is the difference? I just picked up an Iomega Storcenter (which btw, is everything that the DLink could ever want to be - and they didnt skimp on the flash and ram) - the storcenter kernel is based on powerpc arch of kernel and uses the dts, whereas ppc does not?

I based my config off of make sandpoint_defconfig, and ARCH=ppc

Last edited by jens (2008-02-14 07:30:12)

qn1234 wrote:

Usually I use ARCH=powerpc for cross platform compiling.

As far as I know, Linux kernel is transitions from ppc architecture (where everything is hard-coded into sandpoint platform C files) to powerpc architecture where kernels are generic, and all initialization is done using dts database which is somewhat black art. My original efforts where to understand how to make dts variant for DSM-G600 (since kurobox uses that), but now that I saw how easy is it to build it with ppc arch, I might give up on that.

On related note, could jens share some of wisdom how to boot kernel like that? It seems that uloader doesn't want to boot it, but I do vaguely remember that uloader support needed changes in kernel code (load address if I'm not mistaken).

well sorry for the late response, but I did try porting storcenter dts (based in turn on kurobox) and associated files to match dsmg600, and powerpc build was good, but the kernel would never boot - well at least no serial console that i could see (
(will post dts, config, etc shortly....)

ppc arch may be the way to go here, but there is more hacking to be done on the platform specific files to get it to work with dsmg600...

As a side note, I really love this Iomega Storcenter (and I had pretty much dumped iomega after zip and jaz). Out of the box it is very functional, but ever being the hacker, i flashed openprotium fw on it and i'm rocking with the nice ipkg system.. lighttpd->fastcgi->php5->sqlite really rox as an embedded dev platform! I really cant forget the fact that it has 64mb ram /8mb flash... It's well worth it for a hackable low-power, small-footprint general purpose box...