• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: 3.1 new kernel available  (Read 5254 times)
cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« on: October 24, 2011, 02:01:18 PM »

3.1 is now available.

For everything besides Dreamplugs:
sudo ./README-PLUG-UPDATE.sh 3.1 --nandkernel (installs to nand)
or:
sudo ./README-PLUG-UPDATE.sh 3.1 --rootkernel (installs to /boot)

For Dreamplugs:
sudo ./README-DREAM-UPDATE.sh 3.1 (installs to /boot)

Kernel and modules are available from the following locations:

The mirror may not always be current.

http://www.plugapps.com/mirror/with-linux/
http://sheeva.with-linux.com/sheeva/

Features systemd, e-sata, dmcrypt, IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), UBIFS, usb-serial, uvcvideo, iptables, appletalk, bluetooth, v4l and ppp.

The kernel source is here, for those of you who need to compile custom modules.  The availability will be limited by my 2 Gig dropbox account limit, but I will keep the most recent versions available.

http://dl.dropbox.com/u/38673799/sheeva-3.1-KernelSource.tar.xz
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #1 on: October 24, 2011, 05:03:59 PM »

3.1 is now available.
Thanks - up and running on my SheevaPlug.
Quote
The mirror may not always be current.
Still hasn't updated since 2.6.38
Quote
The kernel source is here, for those of you who need to compile custom modules.
Isn't that just the stock 3.1 kernel from kernel.org + the patches form your links?  If so, a download from kernel.org + patches would be quicker, and save your download allowance.
PS: How does one build a single module, assuming I've got the source in place and applied your config?  "make <module_name>"?
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #2 on: October 24, 2011, 07:57:31 PM »

Quote
How does one build a single module, assuming I've got the source in place and applied your config?
Assuming you have also applied bikers patches

Code:
# # change to linux kernel source directory
# cd linux-$KVer
# make modules_prepare

# assuming you mean 3rd party modules, this bit may vary
# cd my-module-dir
# make CROSS_COMPILE= ARCH=arm INSTALLDIR=./ KERNELDIR=../../$KVer/linux-$KVer clean
# make CROSS_COMPILE= ARCH=arm INSTALLDIR=./ KERNELDIR=../../$KVer/linux-$KVer
Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #3 on: October 24, 2011, 08:02:31 PM »

Mr biker,
I can probably find about 10GB of storage for kernel replication.
Email me if you are interested.
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #4 on: October 25, 2011, 12:28:17 AM »

3.1 is now available.
Thanks - up and running on my SheevaPlug.
Quote
The mirror may not always be current.
Still hasn't updated since 2.6.38
Quote
The kernel source is here, for those of you who need to compile custom modules.
Isn't that just the stock 3.1 kernel from kernel.org + the patches form your links?  If so, a download from kernel.org + patches would be quicker, and save your download allowance.
PS: How does one build a single module, assuming I've got the source in place and applied your config?  "make <module_name>"?

With regards to the kernel source, if you're going to build the complete kernel, then starting with the source from kernel.org and then patching the source is the way to go.  The reason why I make the "built" kernel sources available is that the compile process creates header files that are missing with the pristine sources from kernel.org.  So for compiling an extra module or two, having the "built" sources is the way to go.
Logged

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #5 on: October 25, 2011, 12:40:06 AM »

Hi,

Last week I built and ran 3.1-rc10. During the building I found that some of the kernel config parameters had changed since the 3.0 series. The main ones that seemed to need to be changed in order to keep the same modules built were:

CONFIG_GPIO_BASIC_MMIO_CORE=m
CONFIG_GPIO_BASIC_MMIO=m

have gone, and are replaced by
CONFIG_GPIO_GENERIC=m
CONFIG_GPIO_GENERIC_PLATFORM=m

I think the following also needs to be added:
CONFG_LEDS_GPIO_PLATFORM=y

My reading of the code was that GPIO support would not be enabled unless the above changes were made.

I have also found that there are some issues with 0003-Initial-defconfig.patch for recent kernel. What is the best way of letting you have a patch for the changes I made?

PQA

Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #6 on: October 25, 2011, 05:45:50 AM »

Discovering the wonders of NFS on a Dreamplug.
This 3.1 kernel and wheezy fs, boots and runs fine off NFS
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #7 on: October 25, 2011, 10:29:10 AM »

Hi,

Last week I built and ran 3.1-rc10. During the building I found that some of the kernel config parameters had changed since the 3.0 series. The main ones that seemed to need to be changed in order to keep the same modules built were:

I have also found that there are some issues with 0003-Initial-defconfig.patch for recent kernel. What is the best way of letting you have a patch for the changes I made?

PQA



Yes, I'm sure that the guruplug_defconfig could use an update (It doesn't come into play much in my build process).
Just "cp -p arch/arm/configs/guruplug_defconfig{,.orig}", then update the guruplug_defconfig.  Then run "diff -Naupr ./arch/arm/configs/guruplug_defconfig{.orig,}" from the kernel source root.  That should make a nice tidy patch that could just be added to the existing patches.  You should be able to attach that to your post in this forum.
Logged

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #8 on: November 03, 2011, 09:30:31 AM »

Hi,

I'm trying to build my own kernel (since I want to include a built-in module so it doesn't seem reasonable to ask for it to be included in the standard build), but I'm running into a slight problem.

The problem I am experiencing is that the kernel I build produces large numbers of error messages at boot time which I don't get from cxbiker's built kernels. The error messages are "Nov  3 13:19:42 asenath kernel: unwind: Unhandled instruction e0". In particular I seem to get a block of about 62 of these messages, then another block of 41, and then a block of 500. Once the system has completed booting I don't normally get any more of the messages. I have discovered,  though, that if I do an "ifdown eth0.52" or "ifdown eth1", then I get another batch of these messages (approx 70 of them). If I boot my uImage with cxbiker's modules, then I still get the error, and if I boot cxbiker's uImage with my modules, I don't get the error, so the problem would appear to lie in the uImage.

I have built a kernel without the additional modules that I need, so it is precisely the same as cxbiker's, i.e. I am using the downloaded dream-3.1.0-config file and have applied all the patches. I'm using cxbiker's toolchain build script from 20110821, and so have the toolchain from that. So, I am building the same kernel with the same configuration, the same patches, and the same toolchain, against vanilla kernel 3.1.0 sources.

I have done a comparison of the sizes of all the module files against sheeva-3.1-Modules.tar.xz, and with the exception of about 6 modules that include source file paths in them, the file sizes are identical. I have compared the downloaded map file against the map file I generate (unfortunately I have to do this for the sheeva kernel since cxbiker's distribution doesn't include the dream map file (HINT Smiley ), and the only cause of symbol values changing (apart from a different path name length to the source tree), is the difference between __start_unwind_index and __stop_unwind_index, which strikes me as though it could be relevant as it is a problem with unwind and that is the area of the problem I am experiencing. The difference between __start_unwind_idx and __stop_unwind_idx in cxbiker's build ix 0x1eb70, and the difference in my build is 0x01eb58, i.e. mine is 0x18 bytes shorter.

The __start_unwind_idx and _stop_unwind_idx symbols are generated from arch/arm/kernel/vmlinux.lds.S and quite frankly I haven't a clue what that bit of code is doing although it seems to be reserving space (*(.ARM.exidx*))
for a number of unwind_idx structs (see unwind_init function in arch/arm/kernel/unwind.c). As far as I can discover .ARM.exidx is part of the linker configuration.

I can see that cxbiker's build system is a 64bit system, whereas mine is a 32bit one, but that really shouldn't be relevant.

Is there anyone who can give me any help in resolving this problem. Is my assumption that the difference in size of unwind_idx is the cause of the problem? and if so, what is it that determines the size? I guess I could try extending the size of unwind_idx, if only I knew the syntax to do that, and see what happens, but that isn't really solving the problem.

PQA
Logged

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #9 on: November 03, 2011, 09:51:29 AM »

AS part of attempting to diagnose the problems with my kernel build (see previous post), I decided to download http://dl.dropbox.com/u/38673799/sheeva-3.1-KernelSource.tar.xz and compare that against my build tree. I did a file compare of all the files in the downloaded tar file against the equivalent files in my build tree, and found a small number of differences, and  I wonder if these files really shouldn't be in the tar file:

The following are binary executables, and certainly won't run on my 32bit system
./scripts/bin2c ./scripts/conmakehash ./scripts/mod/mk_elfconfig ./scripts/mod/modpost ./scripts/unifdef ./scripts/basic/fixdep ./scripts/kallsyms ./scripts/kconfig/conf

The next files aren't in my build tree, and have 0 size in cxbiker's:
./include/config/virtio.h ./include/config/virtio/ring.h ./include/config/virtio/balloon.h

./include/generated/compile.h seems to be specific to the host the kernel is build on, and ./scripts/mod/elfconfig.h depends on the build host architecture.


Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #10 on: November 03, 2011, 01:20:25 PM »

Here's the relevent bit from my build script that sets compile flags, etc.  Are you setting the ARCH variable when you compile?  Sounds to me like you're getting an invalid instruction built into the kernel.

Code:
function Make()
{
if (( $# < 1 )); then
echo "usage: Make target [MakeOptions]"
exit 1
fi
local target="$1"
local options='' ; (( $# < 2 )) || options="$2"

echo "Make [$target] [$options]"
local ub=/home/kelly/source/src/Sheeva/SheevaPlug_U-Boot
local lh=/home/kelly/source/src/Sheeva/LinuxHost
local rfs=$lh/rootfsv1.0
local ld=$rfs/lib
local uld=$rfs/usr/lib
local id=$rfs/usr/include
local cver=20110530
local cross=/home/kelly/source/src/Sheeva/x86_64-pc-linux-gnu-arm-none-eabi-$cver/bin/arm-none-eabi-

make $options HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm \
INSTALL_HDR_PATH=/tmp/TempHeadersInstall/usr \
INSTALL_MOD_PATH=/tmp/TempModulesInstall \
CFLAGS_KERNEL="-Os -pipe -Os -I$id --sysroot=$rfs/ -isysroot $rfs" \
CROSS_COMPILE=$cross \
LDFLAGS="-L$ld -L$uld --sysroot=$rfs/" \
PATH=:/usr/local/bin:/usr/bin:/bin:. \
$target
}

Logged

spinifex
Full Member
***

Karma: 8
Posts: 167



View Profile WWW
« Reply #11 on: November 03, 2011, 02:03:40 PM »

If it helps, I can download the kernel source (from kernel.org), apply bikers patches and dream.config, then build the kernel natively on a sheevaplug. The result is stable working dreamplug kernel.
That means your issue is either your toolchain setup or invocation.
Logged

UnaClocker
Full Member
***

Karma: 0
Posts: 131



View Profile WWW
« Reply #12 on: November 03, 2011, 07:59:21 PM »

I have an original SheevaPlug with Debian Lenny on it, at one point I updated it to one of cbx's kernels, 2.6.32.2, can I just update to 3.1 now without any drama - ie, just run the script and reboot?
Logged

SheevaPlug - 8gb class 4 SDHC primary drive, 4tb 3.5" media drive, Debian Wheezy, nginx, Samba, Shorewall

UnaClocker
Full Member
***

Karma: 0
Posts: 131



View Profile WWW
« Reply #13 on: November 03, 2011, 08:27:09 PM »

For the record, I ran the script, it updated without a single hickup. Thanks.
Logged

SheevaPlug - 8gb class 4 SDHC primary drive, 4tb 3.5" media drive, Debian Wheezy, nginx, Samba, Shorewall

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #14 on: November 07, 2011, 02:48:47 AM »

cbxbiker, spinfex,

Many thanks for your suggestions. As spinfex suggested, I built the kernel on the plug itself, and indeed that worked fine. I have now also built the 20110821 cross toolchain on a different i686 system, and that kernel is working too without the unhandled exceptions. The only difference that I can see is that the original build system has a much older native toolchain (based on gcc 4.4.4) and that the new system I have used is based on gcc 4.6.1 (more below). It makes me wonder if the cross toolchain built on the gcc 4.4.4 system is the problem. I'll find out tomorrow or soon after when I upgrade it to Fedora 16 (currently Fedora 12); the successful build was on Fedora 15.

In order to build the toolchain with gcc4.6.1 I had to make one or two patches to the toolchain in order for it to compile. The binutils patches are taken from the latest binutils source code, and the cloog patch is what the linker recommends since it appears that -lm is no longer included by default. The patch to BuildPlugToolChain-20110821.sh  is just to apply the binutils and cloog patches. So far as I can see, the patches should work for any system.

In case it helps anyone else building on Fedora, I found on Fedora 15 that the following non default packages needed to be installed in order to build the toolchain: libstdc++-static, texinfo-tex, texlive-utils.

Once again, many thanks for your help.

pqa

* toolchain-20110821.patches.tar.gz (1.53 KB - downloaded 101 times.)
Logged

Pages: [1]
Print
Jump to: