Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
Has anybody build a custom kernel from either debian 2.6.26 or kernel.org 2.6.30-rcX ? My understanding, is that these both now have all the required patches for both the rev A1 and B1 323s, give or take the odd fan and sensor patch.
I've tried just about every way I can think of to build one, but when I copy it to the device it just freezes after the "Uncompressing Linux....... done, booting the kernel." message.
So far I've tried:
- cross compiling with a uclibc buildroot environment (my preferred method).
- building in a qemu-arm-versatile environment (based on the images here: http://people.debian.org/~aurel32/arm-versatile/).
- building on the 323 itself (cdebootstrap a system as per the old howto, nfs boot the 323, and build from there).
As for the machine id issue (526 / 1542), I've tried both hacking the mach-types, and the devio method from the debian installer (http://www.mail-archive.com/debian-bugs … 78921.html).
So I'm stumped. If anyone could provide a few pointers, including config files (kernel, buildroot, uclibc etc.) I'd be extremely grateful, not to mention more awake in the morning after actually getting some sleep!
On a slightly separate point, and purely out of interest, how does the devio magic work? All I can see is that it adds 8 bytes to the front of the zImage before adding the uboot header. How does this fix the machine type?
Cheers,
Barney
Offline
I have built kernel 2.6.28.4 along with a few patches for orion SoC using openembedded tool chain. I used uclibc-0.9.30.1 and I used ARM architecture as thumb gave me some trouble. That's how far I have got. What I now would need is some pointers on how to get this thing on the device. That is, how do I write something on flash? I reckon I need serial connection but is JTAG etc required?
-- kentsu
Offline
I didn't use JTAG at all, just a home made serial connection using a futurelec board as detailed here: http://dns323.kood.org/hardware:serial. From there, just use kermit to send the kernel to the machine, and boot it.
You don't even need to flash it - just copy it into ram and boot if from there. I've validated that this works by downloading the original kernel (mtd2) in this way and booting it from ram.
HTH
Offline
I've installed a 2.6.29.1 kernel on my rev B1. I've found it here http://blog.christophersmart.com/2009/0 … nt-page-1/
It runs fine. I can control the fan speed and monitor the temperature.
There's a little bug with sensors-detect, you need to don't probe some device if you don't want to have seg fault.
Offline
baarney wrote:
You don't even need to flash it - just copy it into ram and boot if from there. I've validated that this works by downloading the original kernel (mtd2) in this way and booting it from ram.
But the thing is I'd like to replace what's on flash. I am thinking of putting together a simple system that allows you to log on using ssh and that sits nicely on the flash. That's what I need pointers with. Also all steps for necessary precaution are welcome. I would like to have an option to flash original firmware back to flash should need arise.
-- kentsu
Last edited by kentsu (2009-04-22 10:01:09)
Offline
kentsu wrote:
But the thing is I'd like to replace what's on flash. I am thinking of putting together a simple system that allows you to log on using ssh and that sits nicely on the flash. That's what I need pointers with. Also all steps for necessary precaution are welcome. I would like to have an option to flash original firmware back to flash should need arise.
Yep - I get that - was just pointing out that when you're trying things out you don't need to burn it to the flash. That way if it doesn't work (which I have a lot!) then the previous one is still intact. Once you get your final version that works you can burn it to flash.
Once you've got your kernel, you can use mkimage to create a uboot image of it:
$ mkimage -A arm -O linux -T kernel -C none -a 0x008000 -e 0x008000 -n 'Custom Kernel' -d vmlinuz vmlinuz .uboot
Then upload it via the serial cable / kermit - details here: http://dns323.kood.org/dsmg600/howto:kernel_upload
marsupilamies wrote:
I've installed a 2.6.29.1 kernel on my rev B1. I've found it here http://blog.christophersmart.com/2009/0 … nt-page-1/
It runs fine. I can control the fan speed and monitor the temperature.
There's a little bug with sensors-detect, you need to don't probe some device if you don't want to have seg fault.
Thanks for that - I'll check it out. I've spent so much time on this lately though that I'd still be interested in how to build my own, just so I know where I was going wrong!
Cheers,
Offline
Well, still no joy.
I got the kernel package from http://people.debian.org/~tbm/orion/, unpacked it, and tried to make a uboot image:
kernel as is - didn't expect this to work as I assume machine type is wrong:
$ mkimage -A arm -O linux -T kernel -C none -e 0x00008000 -a 0x00008000 -n "Custom kernel" -d vmlinuz-2.6.29-1-orion5x vmlinuz-2.6.29-1-orion5x.uboot
with devio magic to fix machine type
$ devio > vmlinuz-2.6.29-1-orion5x.devio 'wl 0xe3a01c06,4' 'wl 0xe3811006,4'
$ cat vmlinuz-2.6.29-1-orion5x >> vmlinuz-2.6.29-1-orion5x.devio
$ mkimage -A arm -O linux -T kernel -C none -e 0x00008000 -a 0x00008000 -n "Custom kernel" -d vmlinuz-2.6.29-1-orion5x.devio vmlinuz-2.6.29-1-orion5x.devio.uboot
Neither worked when I loaded them on to the 323. Just to clarify, when I say didn't work, I mean that after the "Uncompressing Linux... done, booting the kernel." message, the system just freezes. It may be running, but I'm trying to get console messages and an initial terminal on the serial line, which is what happens when I boot the original mtd2 uimage.
Cheers,
Barney
Offline
Hi, I'm using the standard bootargs from the uboot image:
Marvell>> printenv
bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
...
Do you know what command line is built in to the original image? Is this combined with the bootargs, or used instead?
Cheers,
Offline
baarney wrote:
Do you know what command line is built in to the original image? Is this combined with the bootargs, or used instead?
Not sure, but 'cat /proc/cmdline' will tell you what was actually used. But since you have 'console=/dev/ttyS0', the command line may not be the problem (unless your kernel has no serial port driver).
Offline
Yep, cat /proc/cmdline from the original kernel gives:
root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
as per the uboot environment settings.
fonz wrote:
...the command line may not be the problem...
I think my main problem is I don't know where the problem is :-)
Building my own kernel consisted of:
1. Creating a cross-compile toolchain (using buildroot/uclibc).
2. Building a kernel (make orion5x_defconfig then make menuconfig to tweak a few settings)
3. Creating a uboot image of the kernel.
And there could be problems with any of the steps in this chain. I think my toolchain is ok, as I can build executables such as busybox, which run happily on the original kernel. Using Martin's vmlinuz-2.6.29-1-orion5x kernel, I should just have to do step 3.
My main focus at the moment, is the machine type, as I still don't fully understand that. My current understanding is that the d-link uboot loader passes 526 as the machine type, when a vanilla DNS-323 kernel is expecting 1542. So there are two ways to get around this: hack the arch/arm/tools/mach-types file to change the MACH_DNS323 entry to 526, or use the devio method. The devio method seems to be the better approach, so I've been trying this based on code from the new debian installer:
# Set machine id 1542 (0x0606)
devio > $(TEMP)/dns323/kernel 'wl 0xe3a01c06,4' 'wl 0xe3811006,4'
cat $(TEMP_KERNEL) >> $(TEMP)/dns323/kernel
mkimage -A arm -O linux -T kernel -C none -e 0x00008000 -a 0x00008000 -n "Debian kernel" -d $(TEMP)/dns323/kernel $(TEMP)/dns323/kernel.uboot
But I still don't understand exactly how this works, and how adding 8 bytes to the front of the file can fix the machine type discrepancy.
So I'm still hacking away, but if anyone has any thoughts on what I could try I'd be really grateful to hear them.
Cheers,
Offline
Ok, got this working now. The problem was the floating point emulation: the kernel was configured with NWFPE and buildroot was configured to use hardware floating point. My understanding from reading this article (http://linux-7110.sourceforge.net/howto … /x1114.htm) was that this should work, albeit not optimally, but apparently not.
So reconfiguring buildroot to use software floating point emulation solved the problem. Big thanks to the guys from buildroot for helping me track this down.
And if anyone else was wondering how the devio stuff worked, here's an explanation from Martin Michlmayr:
The boot loader on ARM machines puts the machine ID into a register
before running the Linux. The devio stuff puts some code in front of
the kernel that puts another machine ID into the register.
Cheers,
Offline
Hello,
I tried building a new kernel with latest patches from Erik Benada (GPIO, poweroff, LEDs), flashed it and got an error from uboot saying that CRC checksum is wrong. But when I do a calculation with an hexeditor it shows the same CRC-checksum (I already checked a working kernel from Martin Michmayr the same way it is okay, too). So for now I am stuck ... I don't know whats wrong!
Currently I am running a working 2.6.30-rc6(with patches from Erik Benada) from Martin Michlmayr with a little daemon working fine.
Balou
Offline
Hi Balou,
How big is your kernel?
My initial take on the maximum possible size was 1,536 KiB (1,572,864 bytes), based on this doco: ftp://ftp.dlink.com/GPL/DNS-321/Readme.txt
However, I had the same problem trying to flash a kernel which was only 1,530,032 bytes: when I just copied it onto the machine and booted it from ram it worked fine, but when I flashed it I got the CRC error. My current kernel is 1,474,888 bytes, which works fine.
HTH,
Barney
Last edited by baarney (2009-06-08 11:01:42)
Offline
Well, that might be my problem! I will check it today after work and give it a try...
Offline
Did you get it working? Every kernel 2.6.33.1> stops after uncompressing ...
Offline
Pages: 1