anyone compile a custom kernel yet?

[Blazer]

Update: I used the mkimage binary from the devkit, and was able to successfully compile 2.6.30-rc1 using the cross-compiler on a CentOS 5.3 system.

Code:

Kernel: arch/arm/boot/Image is ready
  GZIP    arch/arm/boot/compressed/piggy.gz
  AS      arch/arm/boot/compressed/head.o
  CC      arch/arm/boot/compressed/misc.o
  AS      arch/arm/boot/compressed/piggy.o
  LD      arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-2.6.30-rc1-00002-g1758996
Created:      Wed Apr 15 11:44:36 2009
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    2083608 Bytes = 2034.77 kB = 1.99 MB
Load Address: 0x00008000
Entry Point:  0x00008000
  Image arch/arm/boot/uImage is ready

Now to hold my breath and write it to the plug and see if it boots. If it does I should have the cifs, NTFS, and uvcvideo support that I need

[KaiBo]

I've updated the wiki regarding that: http://plugcomputer.org/plugwiki/index.php/Compiling_Linux_Kernel_for_the_Plug_Computer#Troubleshooting

Thanks a lot for the fast response on this! However, the error stays the same. Is there an additional chip needed in the kernel-config?

On a sidenote (even though it might be obvious): Having the enviroment-variables set as described in the Troubleshooting-Chapter results in the original kernel not booting anymore.

[Raúl Porcel]

I've updated the wiki regarding that: http://plugcomputer.org/plugwiki/index.php/Compiling_Linux_Kernel_for_the_Plug_Computer#Troubleshooting

Thanks a lot for the fast response on this! However, the error stays the same. Is there an additional chip needed in the kernel-config?

On a sidenote (even though it might be obvious): Having the enviroment-variables set as described in the Troubleshooting-Chapter results in the original kernel not booting anymore.

Just make sure you used the kirkwood_defconfig. Also check this:

Code:

# grep CONFIG_MACH .config
CONFIG_MACH_DB88F6281_BP=y
CONFIG_MACH_RD88F6192_NAS=y
CONFIG_MACH_RD88F6281=y
CONFIG_MACH_SHEEVAPLUG=y
CONFIG_MACH_TS219=y

[Blazer]

Just thought I would point this out in case some don't make the connection, referring to the Booting the Kernel and Troubleshooting section of http://plugcomputer.org/plugwiki/index.php/Compiling_Linux_Kernel_for_the_Plug_Computer#Booting_the_kernel

Code:

Marvell>> setenv arcNumber 2097
Marvell>> setenv mainlineLinux yes
Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done

The "2097" is the decimal equivalent of the hex value "831", which is the machine id for the SheevaPlug:

Code:

Error: unrecognized/unsupported machine ID (r1 = 0x0000020f).

Available machine support:

ID (hex) NAME
00000690 Marvell DB-88F6281-BP Development Board
00000691 Marvell RD-88F6192-NAS Development Board
00000682 Marvell RD-88F6281 Reference Board
00000831 Marvell SheevaPlug Reference Board
0000085b QNAP TS-119/TS-219

Please check your kernel config and/or bootloader.

[Blazer]

Well I tried booting the new kernel and got the same error as the other fellow, even though I followed the instructions:

Code:

Marvell>>
Marvell>> printenv arcNumber
## Error: "arcNumber" not defined
Marvell>> setenv arcNumber 2097
Marvell>> setenv mainlineLinux yes
Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Marvell>> boot

NAND read: device 0 offset 0x100000, size 0x400000

Reading data from 0x4ff800 -- 100% complete.
 4194304 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.30-rc1-00002-g1758996
   Created:      2009-04-15  18:44:36 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2083608 Bytes =  2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x0000020f).

Available machine support:

ID (hex)        NAME
00000690        Marvell DB-88F6281-BP Development Board
00000691        Marvell RD-88F6192-NAS Development Board
00000692        Marvell RD-88F6281 Reference Board
00000831        Marvell SheevaPlug Reference Board
0000085b        QNAP TS-119/TS-219

Please check your kernel config and/or bootloader.

Any idea what I did wrong?

[Phoenix]

Well I tried booting the new kernel and got the same error as the other fellow, even though I followed the instructions:

Code:

snip

Error: unrecognized/unsupported machine ID (r1 = 0x0000020f).

Available machine support:

ID (hex)        NAME
00000690        Marvell DB-88F6281-BP Development Board
00000691        Marvell RD-88F6192-NAS Development Board
00000692        Marvell RD-88F6281 Reference Board
00000831        Marvell SheevaPlug Reference Board
0000085b        QNAP TS-119/TS-219

Please check your kernel config and/or bootloader.

Any idea what I did wrong?

I found that I had to set mainlineLinux to yes, then reset the plug and set arcNumber before that went away.

So try:

Code:

Marvell>>setenv mainlineLinux yes
Marvell>>reset
...
Marvell>>setenv arcNumber 2097

It was something along those lines, I figure that that environment variable is only looked at when uboot starts up.

In my case it resolved that error, but I ran into a couple more before getting the kernel to completely load.

1) The 2.6.30-rc1 kernel changes the nand_mtd of the bootargs to orion_nand

2) The kernel didn't seem to know what filesystem the root was

I fixed both these problems by changing my bootargs to

Code:

set bootargs 'console=ttyS0,115200 mtdparts=orion_nand:0x100000@0(uboot)ro,0x300000@0x100000(uImage)ro,0x1fc00000@0x400000(rootfs)rw root=/dev/mtdblock2 rootfstype=jffs2'

After that the kernel loaded up and

debian:~# uname -r
2.6.30-rc1

SUCCESS! 

I've yet to verify that the additional features I put in the kernel work, and interestingly I get a warning when I reboot the system:

/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.

I figure I'm missing something since its been a while since I built a kernel from source.

[Blazer]

Thanks for the tips, the orion_mtd thing was definitely a problem as was the rootfstype=jffs2.

I am now booted into the new kernel. It took around 4x longer to boot than the older kernel, it just sat there for awhile, I thought it was locked up at first.  I am also seeing these errors at boot:

Code:

* Activating swap...                                                    [ OK ]
FATAL: Could not load /lib/modules/2.6.30-rc1-00002-g1758996/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.30-rc1-00002-g1758996/modules.dep: No such file or directory
 * Starting early crypto disks...                                        [ OK ]
FATAL: Could not load /lib/modules/2.6.30-rc1-00002-g1758996/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.30-rc1-00002-g1758996/modules.dep: No such file or directory
 * Starting remaining crypto disks...                                    [ OK ]
 * Checking file systems...fsck 1.41.4 (27-Jan-2009)                     [ OK ]
 * Mounting local filesystems...                                         [fail]
 * Activating swapfile swap...                                           [ OK ]
 * Configuring network interfaces...                                     [ OK ]
 * Setting up console font and keymap...                                 [ OK ]
 * Starting system log daemon...                                         [ OK ]
 * Starting kernel log daemon...                                         [ OK ]
 * Starting OpenBSD Secure Shell server sshd                             [ OK ]
 * Starting periodic command scheduler crond                             [ OK ]
 fat: version magic '2.6.22.18 mod_unload ARMv5 ' should be '2.6.30-rc1-00002-g1758996 preempt mod_unload ARMv5 '
 insmod: error inserting '/boot/fat.ko': -1 Invalid module format

the fat.ko and vfat.ko that are in /boot are from the old kernel so I understand why they are not working. I checked the dirs of my cross-compile and found no .ko binaries to replace them with though.

*EDIT*

I found I had to go back to my source and do a:
make -j4 ARCH=arm CROSS_COMPILE=/root/tmp/arm-2008q3/bin/arm-none-eabi- modules

And now I have all the modules. I then did a:
make -j4 ARCH=arm CROSS_COMPILE=/root/tmp/arm-2008q3/bin/arm-none-eabi- modules_install

And on this installed all the modules and associated files in my CentOS server in /lib/modules:

# ls -l /lib/modules
total 5344
drwxr-xr-x 6 root root    4096 Mar  5 10:11 2.6.18-92.1.22.el5
drwxr-xr-x 6 root root    4096 Mar  5 07:58 2.6.18-92.el5
drwxr-xr-x 3 root root    4096 Apr 15 19:00 2.6.30-rc1-00002-g1758996

I then made a tar of the 2.6.30* dir and scp'd it to the plug and untared it in /lib/modules, and I think I'm good to go now.

I also commented out the loading of the fat and vfat modules in the /etc/rc.local, since I built them into the new kernel.

[KaiBo]

I found that I had to set mainlineLinux to yes, then reset the plug and set arcNumber before that went away.

I can confirm that. Having it done that way it works like a charm! 

[KaiBo]

So while booting the kernel and having it mount an ext2-root from my usb-stick works as it should, I cannot mount a rootfs from nand as the kernel says its lacking jffs2-support. However, jffs2 IS compiled into the kernel and listed under /proc/filesystems as supported. I can even mount my nand-root when booting completely from usb...

Any clue?


[edit]
Just noticed that on my Kernel jffs2 is not listed as a block device (nodev). Question is what to do to make it one... Never had to do so.

[Pandemonium]

To all those that have successfully compiled and booted a custom kernel, are there any additional tricks that I'd need to know?

After wrestling with the (rather poor) PDF documentation for a day, I got my custom kernel to compile using the toolchain and kernel sources Marvell supplies.  I throw the uImage and jffs2 image on a USB drive, flash both to the plug, and when I reboot I get Bad Magic Number.  I didn't resize my MTD1 because my custom kernel is smaller than the stock one, probably because I didn't compile audio support.

I toyed for a bit at making MTD1 bigger, but when I do that then I can't get it to mount rootfs when booting from USB to flash write the images to NAND.  I only played with that for a bit, though, because it seems like I shouldn't need a bigger MTD1, what with my uImage being smaller than the original.

Is there anything else I can try?

[tmk]

what command did you use for reflashing?

i had problems when i used the -p flag to nandwrite (i think it's that command anyways, the -p flag is definitely a problem)

-tmk

[Pandemonium]

I used:
# nandwrite –p /dev/mtd1 uImage.myimage.v01
# nandwrite –p /dev/mtd2 <filesystem>

I saw your previous comment about the -p switch and tried it without it on my second go around.  It gave me an error that said, in effect, that my image was not properly aligned to allow flashing without padding.  It wouldn't flash without -p.

[kilowatt]

nandwrite --help explains the options
  -p, --pad             pad to page size

You should use it to write the kernel so you pad the file out to the page size of the nand.

The file system .jff2 should already be padded so you should not use -p when you write the file system.

The -m option might help if you have a write failure by marking the flash block bad
  -m, --markbad         mark blocks bad if write fails

also you should run
flash_eraseall -j /dev/mtd(x)    (x) should be replaced with the appropriate partition number.

to clear the partition before you use nandwrite

[Pandemonium]

Thanks for the info.

I always do an eraseall before flashing.  In fact, I've reflashed my plug successfully around 20 times, but always using the stock kernel and either the stock root fs or my own fs.

So, I'm fairly well versed with the process, but using my custom kernel has stumped me.

[tmk]

Have you tried booting your kernel from tftp/network or otherwise, just to make sure it's supported?

I haven't yet flashed a kernel to the uboot space yet.

-tmk