Topic: Replacing your own kernel is not recommended yet

Warning, don't follow the instructions on the wiki page http://wiki.chumby.com/mediawiki/index. … for_chumby on how to change/update your kernel version, they don't quite work properly, and you might end up with a chumby that is only in "special options" mode.

For some reason I don't think that the kernel source provided as a download is the one that is running in the latest versions of the chumby, based on the configuration and drivers listed, and hopefully someone will fix this soon...

Re: Replacing your own kernel is not recommended yet

You should be able to recover your primary partition by doing a USB update with the current software release from Special Options mode.

Not sure why you're having problems - the kernel code currently posted is for build 312 (software version 1.1), but it should still work.  I hope you weren't trying to use the Foo/Katamari code - that's for the alpha prototypes only.

I'm not sure why the 1.2 source isn't up yet.

Re: Replacing your own kernel is not recommended yet

Duane wrote:

You should be able to recover your primary partition by doing a USB update with the current software release from Special Options mode.

Yes, that was my mistake, sorry.

But the current kernel source code for download does not match up with what is in the chumby today (1.2) version, which is a bit confusing, and makes it very hard to replace with your own kernel and still have the rest of the system work properly.

Any word on when the source will be posted?  I think the license of it kind of requires it to be available smile

Re: Replacing your own kernel is not recommended yet

gregkh wrote:

Any word on when the source will be posted?  I think the license of it kind of requires it to be available smile

Yes, it does indeed - and I've been quite frequently bugging the responsible person (Hi Ken!) to post it.  If it doesn't show up very soon, I'll post it myself.

Re: Replacing your own kernel is not recommended yet

Ok, I've been able to successfully restore my chumby with the default kernel, so all is good that way.

But the instructions on the wiki are still incorrect, I am unable to create a bootable kernel with the source that is provided so far, hopefully the new source release will fix that.

Re: Replacing your own kernel is not recommended yet

OK - it turns out those instructions are missing a step. You need to pad the zImage file up to the next NAND block size of 512 bytes with 0xFFs, *then* zip it.  This is because the update code is doing raw NAND block writes and doesn't handle partial blocks.

Ken will update the instructions.

Re: Replacing your own kernel is not recommended yet

You will need to ensure that every partition that you wish to overwrite is 512 byte aligned.  You can use the following perl script to align the partitions before zipping them:

#!/usr/bin/perl
#
#  align.pl - aligns images to a 512 byte boundary
#
#  Copyright (c) Chumby Industries, 2007
#
#  align.pl is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  align.pl is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with align.pl; if not, write to the Free Software
#  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

my $filename = $ARGV[0] || die( "syntax: $0 <filename>\n" );
my $filesize = -s $filename;

if( $filesize % 512 )
{
        my $blocksNeeded = int( ( $filesize + 511 ) / 512 );
        print "filesize: $filesize\n";
        print "blocks needed: $blocksNeeded\n";
        my $padding = ( $blocksNeeded * 512 ) - $filesize;
        print "adding $padding bytes of 0xFF padding to $filename\n";

        open( F, ">>$filename" );
        binmode F;

        for( my $i = 0; $i < $padding; ++$i )
        {
                print F "\xff";
        }
        close( F );

        my $newFilesize = -s $filename;
        print "new filesize: $newFilesize\n";
}
else
{
        print "$filename is 512 byte aligned\n";
}

Re: Replacing your own kernel is not recommended yet

Ken wrote:
#!/usr/bin/perl
# (c) Copyright Chumby Industries 2006-2007
# All rights reserved

Hint, that's not a license for something that can be publically posted and used by others legally...

Care to repost this under a license so that we can use this script and/or the information provided in it?

Re: Replacing your own kernel is not recommended yet

Ken wrote:

You will need to ensure that every partition that you wish to overwrite is 512 byte aligned.  You can use the following perl script to align the partitions before zipping them:

But this isn't a "partition", it's just the kernel image file.  Is it treated like a partition for some reason?

10

Re: Replacing your own kernel is not recommended yet

gregkh wrote:
Ken wrote:

You will need to ensure that every partition that you wish to overwrite is 512 byte aligned.  You can use the following perl script to align the partitions before zipping them:

But this isn't a "partition", it's just the kernel image file.  Is it treated like a partition for some reason?

By "partition" I'm referring to an MTD partition, not a file system partition.

Here's a list of all of the chumby MTD partitions and their sizes:

chumby:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00100000 00004000 "Boot Loader"
mtd1: 00200000 00004000 "PSP"
mtd2: 00280000 00004000 "Kernel2"
mtd3: 00800000 00004000 "Root Disk2"
mtd4: 00300000 00004000 "Kernel1"
mtd5: 01600000 00004000 "Root Disk1"
mtd6: 01800000 00004000 "Cache"
mtd7: 00080000 00004000 "MSP"

Re: Replacing your own kernel is not recommended yet

Ken wrote:
gregkh wrote:
Ken wrote:

You will need to ensure that every partition that you wish to overwrite is 512 byte aligned.  You can use the following perl script to align the partitions before zipping them:

But this isn't a "partition", it's just the kernel image file.  Is it treated like a partition for some reason?

By "partition" I'm referring to an MTD partition, not a file system partition.

Ah, ok, that makes more sense.

After the legal issue with the above script is taken care of, I'll try this out and see how it works.

Re: Replacing your own kernel is not recommended yet

Thanks for changing the license of the file, I appreciate it.

Re: Replacing your own kernel is not recommended yet

I follow the wiki instructions, and the generated zImage doesn't works:

My instructions are:

mkdir kernel
cd kernel
tar zxvf linux-2.6.16-chumby-1.0.tar.gz
cd linux-2.6.16
ARCH=arm BOARD=mx21ads CROSS_COMPILE=arm-linux- make oldconfig
ARCH=arm BOARD=mx21ads CROSS_COMPILE=arm-linux- make

(The file linux-2.6.16-chumby-1.0.tar.gz already has a .config file, this .config build a functional zImage.)

src/align_512 zImage  (512 byte aligned)
zip k1.bin.zip zImage

14 (edited by davelwang 2007-12-12 11:48:30)

Re: Replacing your own kernel is not recommended yet

Hi all,

After I updated the chumby kernel by using special options->install from usb disk, the device restarts in the special options mode, does that mean the kernel I flashed was broken?

Also, after chumby flashes the new kernel, it also seems to have trouble restarting, the screen hangs at the blue screen with the chumby eyes.  I had to power cycle the chumby, which then starts in special options.

p.s. I did pad the zImage out to 512 alignment

Thanks!

15

Re: Replacing your own kernel is not recommended yet

davelwang wrote:

Hi all,

After I updated the chumby kernel by using special options->install from usb disk, the device restarts in the special options mode, does that mean the kernel I flashed was broken?

Also, after chumby flashes the new kernel, it also seems to have trouble restarting, the screen hangs at the blue screen with the chumby eyes.  I had to power cycle the chumby, which then starts in special options.

p.s. I did pad the zImage out to 512 alignment

Thanks!

To boot into K1/RFS1 (normal mode), you can do one of the following:

    - boot into special options mode and press 'restart to normal operation'
    - press the screen once when you see the chumby "eyes" during the first few seconds of the boot sequence (this forces the bootloader to choose the K1 path immediately)
    - if you have access to a serial console in special options mode, execute: /usr/chumby/scripts/reboot_normal.sh (this can also be done from a debugchumby or userhook script on a USB drive)

Re: Replacing your own kernel is not recommended yet

Thank you for your answer Ken.

So the blue background with the chumby eyes is one of the earliest parts of the boot sequence.  However, after I selected "restart to normal operation" from the special options mode, chumby still hangs at the blue screen with chumby eyes stage.  So does this mean that the kernel I built is broken?

Dave

17

Re: Replacing your own kernel is not recommended yet

Yes, getting stuck on that screen is symptomatic of a broken kernel.  I'll take a look at the current kernel build instructions and see what might be going wrong.

Re: Replacing your own kernel is not recommended yet

Thank you.  I did muck with the kernel in that I set CONFIG_TUN=y, other than that I took the default configuration.  Is there a way for me to check which parts of the kernel am I missing?

Dave

19

Re: Replacing your own kernel is not recommended yet

davelwang wrote:

Thank you.  I did muck with the kernel in that I set CONFIG_TUN=y, other than that I took the default configuration.  Is there a way for me to check which parts of the kernel am I missing?

Dave

The default .config included in the http://files.chumby.com/source/ironforg … 1.2.tar.gz tarball should work without modification.

Re: Replacing your own kernel is not recommended yet

The .config that broke the kernel is very similar to the default .config in the tar file (by default, I am assuming you meant the .config residing in linux-2.6.16 after you untar the file).  The diff between the two is as follows, as you can see I just enabled CONFIG_TUN.  I will try building a kernel with the default .config and flash it and see if it works.

--- .config     2007-06-08 19:36:37.000000000 -0700
+++ /home/dwang/workspace/kernel/linux-2.6.16/.config   2007-12-12 05:32:32.000000000 -0800
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16
-# Mon May 21 07:33:23 2007
+# Wed Dec 12 05:32:32 2007
#
CONFIG_ARM=y
CONFIG_MMU=y
@@ -475,7 +475,7 @@
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
-# CONFIG_TUN is not set
+CONFIG_TUN=y

#

21

Re: Replacing your own kernel is not recommended yet

davelwang wrote:

The .config that broke the kernel is very similar to the default .config in the tar file (by default, I am assuming you meant the .config residing in linux-2.6.16 after you untar the file).  The diff between the two is as follows, as you can see I just enabled CONFIG_TUN.  I will try building a kernel with the default .config and flash it and see if it works.

Are you using the chumby-1.2 kernel tarball found in build396/linux-2.6.16-chumby-1.2.tar.gz?  The instructions on the wiki point to an earlier version of the chumby kernel (build312/linux-2.6.16-chumby-1.0.tar.gz). I will update the documentation on the wiki.

Re: Replacing your own kernel is not recommended yet

I see, so I should use the 1.2 tarball and mess around with the default .config file in there.  Let me give that a go and see how it works.  Thank you for being responsive!

23

Re: Replacing your own kernel is not recommended yet

I've posted (and tested) new instructions for building and installing the linux 2.6.16 kernel that ships with chumby firmware version 1.2 on the wiki - http://wiki.chumby.com/mediawiki/index. … 1.2_kernel

Re: Replacing your own kernel is not recommended yet

Hi Ken,

I followed the directions posted with the 1.2 chumby, with no kernel modifications, and the kernel still does not work.  Under special options I see that I have firmware version 396, I am not sure what else I can check to see what's hosing the boot up sequence, got any ideas?

Dave