Linux Kernel 6.7.5 Kirkwood package and Debian rootfs

Hi Buttzy,
I have tried to follow your instructions but they are not specific enough for me to follow.
I have downloaded your script.
I don't have any other way to prep the disk so I commented back in the fdisk, tar extract and copy.
Now when I boot I get bad magic number.
I'd upload the script but dropbox is having issues at the moment.
My questions.
1. how should the disk be partitioned
2. where should I extract the file 'Debian-3.12.0-kirkwood-tld-3-rootfs-bodhi.tar.bz2'

cheers,
mark

mgazza Wrote:
-------------------------------------------------------
> Hi Buttzy,
> I have tried to follow your instructions but they
> are not specific enough for me to follow.
> I have downloaded your script.
> I don't have any other way to prep the disk so I
> commented back in the fdisk, tar extract and
> copy.
> Now when I boot I get bad magic number.
> I'd upload the script but dropbox is having issues
> at the moment.
> My questions.
> 1. how should the disk be partitioned
> 2. where should I extract the file
> 'Debian-3.12.0-kirkwood-tld-3-rootfs-bodhi.tar.bz2
> '
>
> cheers,
> mark
That reply was a bit hasty! I'm now running debian :D. I forgot to change the extract command in your script which I commented back in :)
Thanks! Mark.

If there's some place I can upload the instructions similar to how arch has point me in the right direction!

Hi bodhi,

thanks again for your effort to bring 3.12 mainline kernel to our kirkwood arm devices !!,
on NSA320 and iConnect everything is running smoothely, exept some minor quirks, please add

--- drivers/hwmon/Kconfig.orig	2014-01-09 20:35:23.000000000 +0100
+++ drivers/hwmon/Kconfig	2014-01-09 18:21:16.000000000 +0100
@@ -1555,7 +1555,7 @@
 
 config SENSORS_NSA3XX
 	tristate "ZyXEL NSA3xx fan speed and temperature sensors"
-	depends on (MACH_NSA310 || MACH_NSA320) && GENERIC_GPIO
+	depends on (MACH_NSA310 || MACH_NSA320) && GPIOLIB
 	help
 	  If you say yes here you get support for hardware monitoring
 	  for the ZyXEL NSA3XX Media Servers.

this patch, so the nsa3xx-hwmon module can be build for NSA320 and

CONFIG_SENSORS_NSA3XX=m

to your config, so lm-sensors is happy on the NSA320 and

CONFIG_SENSORS_LM63=m

to your config for the iConnect,

the triggers on NSA320 for the sata hdd1 and hdd2 leds are working with ide-disk1 or ide-disk2 set respectively,..
so the relevant lines in my rc.local look like this:

if [ -d /sys/class/leds/nsa320:orange:sys ]; then
   echo none > /sys/class/leds/nsa320:orange:sys/trigger
   if [ -d /sys/class/leds/nsa320:green:sys ]; then
      echo default-on  > /sys/class/leds/nsa320:green:sys/trigger
   fi
   if [ -d /sys/class/leds/nsa320:red:hdd1 ]; then
      echo ide-disk1  > /sys/class/leds/nsa320:red:hdd1/trigger
   fi
   if [ -d /sys/class/leds/nsa320:red:hdd2 ]; then
      echo ide-disk2  > /sys/class/leds/nsa320:red:hdd2/trigger
   fi
fi

the standard Marvell u-boot on the NSA320 permits also booting from both sata ports,
contrary to what is rumored in diverse threads in this and the Arch alarm forum, at least
the 1.21 bootrom in my NSA320 boxes together with the standard Marvell u-boot from Zyxel
is capable of booting from the second sata port, that is also where my test rootfs
and 3.12 kernel now resides on a sata ssd for testing,..

the problem which hindered me from testing this earlier was the need of some dvb-s2 drivers from
s2-liplianin-v39, which did not get upstream to mainline kernels and which don't compile well with newer kernel versions > 3.11,..

so I took the pain and ported the relevant driver for my setup i.e dvb-usb-dw2102 to mainline 3.12.1, if anybody is interested in these patches, they will get published after some more testing in the vdr-portal forum in the next few days,..

perhaps I should also start a new thread in the u-boot section of this forum, because all my tests to get a newer u-boot
version running on my NSA320 boxes left me with sata ports disfunctional, as was also reported by at least one forum member in this thread, maybe these are some different specifications of DDR timings, or something else weird,..

what I tested was kwboot and kwuartboot (which all went fine because of the 1.21 bootrom) of davygravy's version 3 an 4
u-boot, I also compiled natively (on arm platform) Peter Schildmanns original version of NSA320 u-boot,.. always the same result,
usb booting of a wheezy rootfs was successfull, but booting from sata ports 1 or 2 not !!, ide reset always led to

NSA320> ide reset

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: Model: ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Firm: ?ÿ?ÿ?ÿ?ÿ Ser#: ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 524263.9 MB = 511.9 GB (1073692671 x 512)
IDE read: device 0 not ready
IDE read: device 0 not ready
  Device 1: Model: ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Firm: ?ÿ?ÿ?ÿ?ÿ Ser#: ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ
            Type: Removable Hard Disk
            Supports 48-bit addressing
            Capacity: 524263.9 MB = 511.9 GB (1073692671 x 512)
IDE read: device 1 not ready
IDE read: device 1 not ready

and that was it, always identical, maybe sata did not get powered up correctly, this message was alway the same,
the reported disk size was definitely wrong, and there was no change in this message, despite the fact if there was one, two or no disk sitting in the sata ports, but nevermind, everything is running now smoothely with standard Marvell u-boot, ....

best wishes pbg4



Edited 1 time(s). Last edit at 01/15/2014 02:15PM by pbg4.

Hi pgb4,

Thanks for your NSA320 contribution! I will incorporate your config changes and LED settings to the next kernel/rootfs release. It's good to know the ide1/2 trigger works on NSA320 also (some forum member needs that info).

Regarding the SATA error above. Yes, I think timing must be the cause, because with my new 2013.10 uBoot build, the Sandisk Readycache shows the same error, but all of other HDDs I've testbooted worked fine on GoFlex Home/Net. So my tentative conclusion is: there is different timing behavior for the Readycache. It must be a similar problem in NSA320 that you've seen, where Marvell uBoot incorporated some different timing parameters for this box, we have to look at the source code to find out.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've got the original sources pulled from ZyXEL for 310/320/325, so when we start in on that unified uboot tree, that should help greatly.

I'll have a look at those settings for the Arch kernel as well.

Alright, I checked and there is no issue with the ALARM patch and building nsa3xx-hwmon AFAICT

I can confirm that ide-disk* triggers work fine on my NSA320.
I'm using version 3.12.0-kirkwood-tld-1.

pbg4,

Do you have any experience with the gpio buttons using bodhi's kernel?

Włodek

Hi,

@racic

for the gpio events and bodhi's new 3.12 kernels you can use esekeyd which
works slightly better than the input-event-daemon (the other alternative), simply apt-get install esekeyd
and configure it,

you can test the events with evtest, which should give you something like

evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 116 (KEY_POWER)
    Event code 133 (KEY_COPY)
    Event code 408 (KEY_RESTART)
Properties:
Testing ... (interrupt to exit)
Event: time 1390139963.457824, type 1 (EV_KEY), code 133 (KEY_COPY), value 1
Event: time 1390139963.457824, -------------- SYN_REPORT ------------
Event: time 1390139964.627817, type 1 (EV_KEY), code 133 (KEY_COPY), value 0
Event: time 1390139964.627817, -------------- SYN_REPORT ------------
Event: time 1390139972.967857, type 1 (EV_KEY), code 133 (KEY_COPY), value 1
Event: time 1390139972.967857, -------------- SYN_REPORT ------------
Event: time 1390139974.237817, type 1 (EV_KEY), code 133 (KEY_COPY), value 0
Event: time 1390139974.237817, -------------- SYN_REPORT ------------

esekeyd has its own init script and must only get configured after installation,

best wishes pbg4

Dear bodhi,

after spending hours with my NSA325 v1 I manged to install your rootfs and kernel to HDD. Thank you very much for your great work!!!!
My intention is to use the NSA325 as tvheadend backend with an USB attached dvb-s2 receiver.
Compiling tvheadend was straight forward, but it seems that there are no dvb-s/s2 modules available, so my Technotrend S2-4600 is not loaded nor found by tvheadend. I also tried to do an Debian 7.3 netinstall, but the machine-ID of the NSA325 is unsupported. My hope is now that you can provide the kernel-sources for the "Linux Kernel 3.12.0 Kirkwood package" so that I am able to compile the s2-liplianin stuff. I like Debian and the spin-offs most and don't want to change to ArchLinux.

Can you help me please?

Best regards,
Rick

Dear bodhi,,

after some research the kernel-headers for "linux-3.12.0-kirkwood-tld-5" shoud be suffcient to compile the dvb drivers.

Best regards,
Rick

@NSA325tvheadend
Bodhi is keeping up with my NSA325 patches and the added mach number (I have it registered with the ARM device registry), where as debian itself is likely not including the patch needed for the device. It is not a part of mainline.

@NSA325tvheadend,

The kernel-headers for linux-3.12.0-kirkwood-tld-5 is included in the tarball in the first post. Let me know if you want to include this config option in the next release, and so which config switches should be turned on.

Quote
bodhi
This tarball contains 4 files (the patch stays the same as in tld-3):

linux-image-3.12.0-kirkwood-tld-5_5.0_armel.deb
linux-headers-3.12.0-kirkwood-tld-5_5.0_armel.deb
config-3.12.0-kirkwood-tld-5
linux-3.12.0-tld-3-kirkwood.patch

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

hello. I have NSA310 and I have long time ago installed debian 3.5.1 from github peeter NSA310
some OT:
whoever comes to here by google, concerning bootloader:
1) if you can't load anything from USB in bootloader, like in

fatload usb 0 0x800000 uImage

then make use of empty temporary hdd and put builds there instead of USB, so that you can then copy files to NAND from there (on my NSA310, none of 5 usb keys didn't work)
2) if you have a feeling that you are doing everything right in bootloader, and everything starts but everything stops at the same point during instalation, try to use different terminal program, for instance putty. I wasted 5 days with terminal1.9b

that being said, what i really want is working usbserial (ftdi_sio.ko) and a new kernel is a plus
1) so, can i follow your procedure with dpkg, and then copy your uimage file to the NAND?
by loading it:

fatload usb 0 0x800000 vmlinuz-3.12.0-kirkwood-tld-5
nand erase 0x4640000 0x300000
nand write.e 0x800000 0x4640000 0x300000

or just copy uImage file to NAND (vmlinuz-3.12.0-kirkwood-tld-5) and then later, insmod ftdi_sio.ko file?
2) if I use dpkg, will it reset my settings (mysql, apache...)?

The vmlinuz file is not a uImage. It's a standard compressed kernel. I do not believe uBoot will process that correctly as-is. You need to create a proper uImage from it with mkimage. At least that's what I've done to use this kernel on three devices so far -- a Dockstar, a Pogo V4, and an NSA320, all of which boot from USB sticks.

Just so it's clear. I dpkg'ed installed the debs first, then ran the mkimage commands to generate new uImage and uInitrd files. (I always keep the old one for my previous kernel version, as a last resort so that I can manually boot them from the u-boot prompt if worse comes to worse.) They can reside on any device, in any partition type, that u-boot can understand. The worst case is you need to update the u-boot environment. I had a nasty stick that wouldn't boot on the Dockstar for a while so I was loading them from a ubifs formatted mtd3 partition as a work around because the stick was fine after the kernel loaded.

Assuming you built that module yourself, you could update your initrd, which again would need to be built into a uInitrd with mkimage, which would get loaded via the bootm command. But you shouldn't have to do that. Assuming the module is in the correct kernel tree, you should still be able to load it afterwards simply with modprobe.



Edited 2 time(s). Last edit at 01/20/2014 03:16PM by kraqh3d.

@kraqh3d, than you! It is all a lot clearer now, I think.
Here is what i will do: I will wait next kernel, 3.13 in hope to it include what "pbg4" sugested before

Then i will:
1) dpkg #load new kernel and hopefully copy .ko modules to HDD (very important)
2) mkimage #produce uImage file
3) then, in bootloader

setenv mainlineLinux yes
setenv arcNumber 4022       # IMPORTANT - what is the correct arcNumber? set as per Peeter's detailed instruction
saveenv
reset

and then put to NAND, using first fat partition (rembember, USB is not working at this point on some models).
I'm not sure if mem addresess need to be changed?
sda4 is my root partition, choose your own

fatload ide 0 0x800000 uImage.3.13

nand erase 0x4640000 0x300000
nand write.e 0x800000 0x4640000 0x300000

setenv bootargs 'console=ttyS0,115200 root=/dev/sda4'
setenv bootcmd 'nand read.e 0x2000000 0x04640000 0x400000; bootm 0x2000000'
saveenv
reset

If I may wish :) since I haven't try your kernel, don't know if you already have it, but
user PiotrGozdur suggested a patch for SATA Read/Write LED support. Green=read, Red=write. (never tried it, but sounds usefull)
and also, some input-event-daemon with settings like

[Global]
listen = /dev/input/event0
[Keys]
POWER  = shutdown -h now
COPY   = sync
OPTION = shutdown -r now

the "option" key is probably reset key behind

I hope this will not kill apache, cron, mysql and other stuff. :)
why is ftdi_sio.ko important? because it allows NAS to be connected with for example, Arduino devices over ttyUSB0 :)

I just checked and the ftdi_sio.ko module is present in 3.12.0-kirkwood-tld-5. You shouldn't need to anything more than dpkg install the debs which will put in the module somewhere in /lib/modules/3.12.0-kirkwood-tld-5/. You just have to modprobe or insmod load it.

I don't have an NSA310 but comparing with my NSA320, it looks like you're writing the uImage in the "kernel_2" mtd partition. Your size looks big enough. And that should be a good memory location to load the image into since my NSA320 boots from there using bootm 0x800000 0x1100000 for the uImage and uInitrd locations.

Using a uInitrd allows specifying the root using LABEL. Without a uInitrd you can still use UUID or PARTUUID (for a GPT disk) though. I would recommend using one of them instead of a raw device.

You're nand read though is reading a larger piece of flash which means you could get some cruft as you didn't erase beyond 0x300000. And again, my NSA320 is loading uImage into 0x800000. I would expect you would want to do the same. The best thing to do is really to test this without updating the environment from serial.

And updating your kernel should not have any impact on anything you currently have running. I'm not sure know why you would want to run apache on an arm box as there are other less demanding webservers. I'm running lighttpd. I admit I am running mysql though. I'd run something else but it's my central Xbmc database so its the only option.



Edited 4 time(s). Last edit at 01/20/2014 04:41PM by kraqh3d.

Hi bodhi,

well, yes you're totally right, I was blind, read to much the last days ;-)
I installed the headers with dpkg, no problem. But now a new one, when trying to "make" I'll get these:

make: *** /lib/modules/3.12.0-kirkwood-tld-5/build
File not found: /lib/modules/3.12.0-kirkwood-tld-5/build/.config
make[1]: *** [/lib/modules/3.12.0-kirkwood-tld-5/build/scripts/kconfig/conf] Error 2
make: *** [all] Error 2

Can you tell me what to do?

Best regards,
Rick

Hi bodhi,

next step. I copied the "config-3.12.0-kirkwood-tld-5" file to "/lib/modules/3.12.0-kirkwood-tld-5/build" and renamed it to ".config"
Now I get this:

***WARNING:*** You do not have the full kernel sources installed.
This does not prevent you from building the v4l-dvb tree if you have the
kernel headers, but the full kernel source may be required in order to use
make menuconfig / xconfig / qconfig.

and doing make this:

File not found: /lib/modules/3.12.0-kirkwood-tld-5/build/include/linux/netdevice.h
make: *** [all] Error 2

Best regards,
Rick

It's there. The sources are really installed to:
/usr/src/linux-headers-3.12.0-kirkwood-tld-5

And symlinked from here:
/lib/modules/3.12.0-kirkwood-tld-5/build/

But I see that header file via both paths:

root@debian:~# ls -l /usr/src/linux-headers-3.12.0-kirkwood-tld-5/include/linux/netdevice.h
-rw-r--r-- 1 root root 97369 Nov  3 15:41 /usr/src/linux-headers-3.12.0-kirkwood-tld-5/include/linux/netdevice.h

root@debian:~# ls -l /lib/modules/3.12.0-kirkwood-tld-5/build/include/linux/netdevice.h
-rw-r--r-- 1 root root 97369 Nov  3 15:41 /lib/modules/3.12.0-kirkwood-tld-5/build/include/linux/netdevice.h

Hi

you're great!!! "make config" was successful after linking "build" to "/usr/src/linux-headers-3.12.0-kirkwood-tld-5", now the next one:

Can't locate Proc/ProcessTable.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./scripts/rmmod.pl line 4.
BEGIN failed--compilation aborted at ./scripts/rmmod.pl line 4.

perl is installed!

It's not really fun...

Thanks a lot,
Rick

Hi kraqh3d,

Ok, fixed by "apt-get install libproc-processtable-perl" and the next one:

make -C /usr/src/s2-liplianin-v39/v4l
make[1]: Entering directory `/usr/src/s2-liplianin-v39/v4l'
creating symbolic links...
make -C firmware prep
make[2]: Entering directory `/usr/src/s2-liplianin-v39/v4l/firmware'
make[2]: Leaving directory `/usr/src/s2-liplianin-v39/v4l/firmware'
make -C firmware
make[2]: Entering directory `/usr/src/s2-liplianin-v39/v4l/firmware'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/usr/src/s2-liplianin-v39/v4l/firmware'
Kernel build directory is /lib/modules/3.12.0-kirkwood-tld-5/build
make -C ../linux apply_patches
make[2]: Entering directory `/usr/src/s2-liplianin-v39/linux'
Patches for 3.12.0-kirkwood-tld-5 already applied.
make[2]: Leaving directory `/usr/src/s2-liplianin-v39/linux'
make -C /lib/modules/3.12.0-kirkwood-tld-5/build SUBDIRS=/usr/src/s2-liplianin-v39/v4l modules
make[2]: Entering directory `/usr/src/linux-headers-3.12.0-kirkwood-tld-5'
Building modules, stage 2.
MODPOST 0 modules
make[2]: Leaving directory `/usr/src/linux-headers-3.12.0-kirkwood-tld-5'
./scripts/rmmod.pl check
found 0 modules
make[1]: Leaving directory `/usr/src/s2-liplianin-v39/v4l'

Best regards,
Rick

Dear all,

stopping hijacking this thread I opened a new topic for my issue.
Who I interested here you are:

http://forum.doozan.com/read.php?2,14846

Thank you very much for your help till now.
Best regards,
Rick

well... i have decided to try 3.12 even before 3.13 becomes available, and i have nsa310

first, i got an error here, stating that there is no some file...

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.12.0-kirkwood-tld-5 -d /boot/initrd.img-3.12.0-kirkwood-tld-5 /boot/uInitrd

but I have ignored it
then i also did not do

ln -s boot/vmlinuz-3.12.0-kirkwood-tld-5 vmlinuz
ln -s boot/initrd.img-3.12.0-kirkwood-tld-5 initrd.img

because initrd I did not have.
i just put it into NAND

fatload ide 0 0x800000 uimage
nand erase 0x4640000 0x300000
nand write.e 0x800000 0x4640000 0x300000
reset

nas will reset, starts to boot 3.12 kernel and gets stuck with:
VFS: Cannot open root device "sda4" od unknown-block(0,0)
Please append a correct "root=" boot option; here are the availabile partitions: Kernel panick - not syncng: VDS: Unable to mount root fs on unknown-block(0,0)

is it possible that root is ext4 and your kernel cant read from it? or what is the problem?
up untill now, NSA was running Peeter's kernel 3.5.1 with no problem.

nekitip,

I would not recommend flashing the kernel in NAND before you can boot with USB or SATA. And yes, unless the kernel uImage was built with all necessary modules (3.12.0-kirkwood-tld-5 was not), you do need uInitrd.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,

I'm running into an issue with tld5 on my NSA320. I really thought it was already running your kernel but it wasn't. I installed the debs and generated the uImage and uInitrd files but I never swapped them to boot. l keep more than set around. I was still booting davygravy's 3.3.3 kernel. I have a lot of video sitting on those hard drives and I can't "test" while the kids were watching :) "Daaaaad! What did you do?"

So I got around to it last night but I can't get it to boot up. It always dumps me into the initramfs sh. I have this kernel running on a Dockstar and on a PogoV4 (after some annoyance that I need to revisit) so I know its good. I know my uboot environment is good because the old kernel boots without any changes. I've been using root=LABEL=ROOTFS for the longest time on my devices. (Truly all the way back from when I posted the thread about using the label with squeeze.) And it works on the other two.

When I get dumped into the initramfs shell, I get a message that the root was not found. There's not much to check from the initramfs but I did validate that udev is populating the /dev/disk tree. I see /dev/disk/by-label/ROOTFS and /dev/disk/by-uuid/FOO. I did some testing where I kept "manually" booting using non-permanent environment changes. (Nekitip, never write to nand until after you test manually! You just needed to execute your bootm command after the fatload.)

I tested with root=UUID and that didn't work. I tested with root=UUID *without* uImage for giggles but I get a kernel panic. It was really late last night. I should've captured the panic output but I didn't. I can easily do it again late tonight though. I even tried using root=/dev/sda1 with and without uInitrd and it wouldn't boot. With it, I get dropped into the initramfs shell, without it I get a kernel panic. And all those root options work with the old 3.3.2 kernel with uInitrd. (I never tried that one without.)

Got any ideas? I've got no idea what else to check. If /dev/disk is populated then switch_root should work.

kraqh3d,

I had run into similar problem before (same behavior, but it could be a different problem). It's rare, but it seems the initrd creation could produce a messed up initrd. I would check the following:

- if you have flash-kernel installed, then apt-get remove it first before dpkg the new kernel. And then mkimage the uImage and uInitrd manually.
- if you did not have flash-kernel installed, then do initramfs -u to regenerate the initrd anyway before doing mkimage.

I supsect that the initrd image generation has some weird bug that would cause the rootfs to be wrong in some rare circumtances. For example, flash-kernel almost always causes this problem whenever we have a non-conventional kernel name (i.e. linux-3.12.0-kirkwood-tld-5, instead of the official naming convention linux-3.12.0-kirkwood). I think if you dig deeper while you were in the initramfs sh, it will show the wrong root in some "pre-boot" hook scripts (don't recall which one).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/23/2014 09:43AM by bodhi.

@kraqh3d, I know very little about linux, but logic suggest that if I had a running kernel before, and change uImage with another kernel uImage, and if I have not changed setenv, and everything starts and states that there is a problem with root, then it must be that the kernel is not able to read the disk. Is your root partition also ext4? It seems to me that the kernel may be missing filesystem access parts...

For about 5 hours now I'm trying to learn myself how to compile a kernel, and I have read about 10 different howto and it seems that every single one has its own way.
now i'm trying with youngest howto but it is also half-written.
For example - I think this is wrong in my envirement:

make menuconfig

it may be something like:

make menuconfig ARCH=arm

and also, I dont see how it will produce .deb file if it ever will, because it complains something about some undefined reference
I'm frustrated and can't believe that I cannot find some kernel_comple_GUI_one_click

@bodhi
I do not have flash-kernel installed. I removed that long ago because I didn't want a deb install to ever overwrite anything without me being aware. I'll regen the uInitrd tonight and give that a shot and report back tomorrow. Come to think of it, I should've done that last night. It was late and I wasn't thinking.

@nekitip
No. I've got an ext3 root. The reason to use an initrd is so that you don't have to have a lot of modules compiled directly into the kernel. If support for ext4 is not in the kernel, you'll need to use an initrd. Create a valid uInitrd (you may need to first generate a proper initrd with "update-initramfs -u") and place it on your fat partition, and give this a try:

fatload ide 0 0x800000 uimage
farload ide 0 0x1100000 uinitrd
setenv bootargs 'console=ttyS0,115200 root=/dev/sda4'
bootm 0x800000 0x1100000

This will load both into memory and boot them. If that's already your bootargs, then you don't have to do that part. I borrowed it from your earlier post. This is the way to test before writing to nand. Just load to memory and then boot from memory. After you know its good, then write to nand so the standard bootcmd works.

** edit **

Generating a new initrd worked.



Edited 1 time(s). Last edit at 01/24/2014 09:30AM by kraqh3d.

@kragh3d, isn't intrid just for booting from NAND? A way to make ramdisk from mem location for systems with low ROM?
So, I didnt know anything about kernel before and after I spent another 10h of my life, and after many of trial and error, i came to near success with this:
kernel 3.12, patch from bodhi, and Peeters config for 3.5.1, cross compile for arm, and copy locations to known position
this is result of total 20h of googleing and trial and error, hope it will save someone elses time

mkdir build
cd build
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.bz2
wget http://www.scintilla.utwente.nl/~petero/nsa310/config-good-3.5.1-nsa310
bzip2 -dc linux-3.12.tar.bz2 | tar -xf -
cd linux-3.12
patch -p1 < ../linux-3.12.0-tld-3-kirkwood.patch
cp ../config-good-3.5.1-nsa310 .config
make menuconfig ARCH=arm
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j3 uImage modules
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j3 uImage modules_install INSTALL_MOD_PATH=../copy/

uImage is in arch/arm/boot/uImage
modules in "copy" kernel folder needs to be copy to /lib/modules/3.12.0

the reason i had to do this is because bodhi's configuration couldn't access file sistem and thus, not been able to boot the system, so i had to include ext4, and also, in my case, i had to have ftdi_sio.ko. I have included them all in uImage.
I did not create .deb file since it would take me another few hours to figure out that.

it works by loading uimage as doing this in bootloader:

ide reset
fatload ide 0 0x800000 uimage-3.12
bootm 0x800000

however, to completely replace Peeters kernel, it must be loaded to NAND, since my bootload cant load from USB
however, i cannot do that. It complains that it is wrong CRC after reset, and bootloader stops.
I suspect that it might be something with memory addresses (too big kernel file?)
If, and only if it can not be done, then, is there a way to insert pause in bootloader after 'ide reset'?
because, then it might be possible to do this:

setenv bootcmd 'ide reset; (some sort of 2 sec pause) fatload ide 0 0x800000 uImage; bootm 0x800000'

however, now it is not doable. I suspect it is because hdd is taking time to reset, and bootloader tries to load.
Also, remember, I know almost nothing about all this.
Please comment!

Strange. I confirm that the bootloader is working if booting from disk. Don't know why it didn't before.
anyway, here is command for bootloader

setenv bootcmd 'ide reset; fatload ide 0 0x800000 /uimage-3.12; bootm 0x800000'

save all and reset
that is if loading from first partition on FAT disk.
ex2load instead of fatload, or usb start instead of HDD.

one question remains - how to load from NAND, that is - what are correct nand erase and write numbers if theese are wrong.
and also, what to do with compiled modules. to copy just .ko files, or all of the stuff.