Topic: Silvermoon kernel recompile.

I was having a look at doing a recompile of the bb8's kernel that is provided on the files.chumby page and ran into a missing header issue. I am assuming that the missing declarations would all be from the regs-timer.h that I am unable to locate, but I could be wrong. I checked through the headers provided with the silvermoon toolchain and the cross-compiler ( GCC 4.3.2 ) provided through the wiki to no avail. There are some S3C-specific headers, but the "S3C_TCMPB"-named macros seem more generic than the ones specifying the chipset under "arm/plat-s3c" and such. This is being compiled on a BB8 device with the native toolchain. Any help regarding this would be appreciated.

drivers/char/chumby_regs.c:54:33: error: asm/arch/regs-timer.h: No such file or directory
drivers/char/chumby_regs.c:444: warning: initialization from incompatible pointer type
drivers/char/chumby_regs.c: In function 's3c_regs_proc_output':
drivers/char/chumby_regs.c:479: error: 'S3CREG_VERSION' undeclared (first use in this function)
(...snip...)
drivers/char/chumby_regs.c: In function 'adjust_brightness':
drivers/char/chumby_regs.c:863: error: implicit declaration of function 'S3C_TCMPB'
drivers/char/chumby_regs.c: In function 'initial_brightness':
drivers/char/chumby_regs.c:869: error: implicit declaration of function 's3c6400_timer_setup'
(...etc...)

Re: Silvermoon kernel recompile.

Hmmm, it shouldn't be doing anything with "s3c", since that would seem to be for the Samsung S3C6410 part in Stormwind, not the Marvell PXA168 part in Silvermoon.

Hopefully, ChumbyLurker will chime in with the real scoop.

Re: Silvermoon kernel recompile.

I believe that file was an early attempt at gaining visibility into the device.  Early versions of the device were based on the part Duane mentioned, and the kernel devs wrote a kernel module called chumby_regs to peek and poke at the device's registers.  It looks like that file was kept for some reason when we moved to the Armada 100 (aka PXA168) processor, though it shouldn't be used as it doesn't compile.

I use regutil to gain visibility into the device's workings, so I haven't fiddled with chumby_regs.c at all.

You should be able to pull the device's .config out of /proc/config.gz on the device, which should have that config option disabled.

4 (edited by devOut 2010-08-05 17:37:17)

Re: Silvermoon kernel recompile.

I kind of had a feeling that it I had a kernel option out of place. With the description in the Kconfig for that file regarding GPIO it seemed like it would have been under one of the other board's branches in the config tree if it wasn't something supported under the Aspenite branch. Lesson-learned on my part!

Thanks for the replys.

5 (edited by jronald 2010-08-22 16:26:59)

Re: Silvermoon kernel recompile.

First I want to say that I think that the Chumby One and the InfoCast are great products for us hacker/maker types. 

With the information in the Wiki and and the tidbit here regarding the proper config file being in /proc/config.gz  of the device, I was able to successfully cross compile the Linux kernel.  I assumed that I next needed to replace /boot/vmlinuz with the new zImage on partitions 2 and 3 which I did and was able to successful boot using the new kernel. 

chumby-17-f1-56:/boot # uname -a
Linux chumby-17-f1-56 2.6.28-M2.1.8.12 #1 Wed Aug 18 22:46:57 EDT 2010 armv5tejl GNU/Linux

I now have two questions:
1) Like the chumby one, is there an align script that should be run on the kernel image?
2) What is the preferred method for installing a new kernel?  Does doing an update from USB like the chumby one work?

Regards,
- Jim