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

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.

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 ), 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

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

Hi,

I have just found that some 3.0 kernels post 3.0.4 have been released, but they are not showing up in the "traditional" places. See for example https://lkml.org/lkml/2011/10/17/397 . This is also indicated as an essential upgrade.

I have used cbxbiker's configuration and patch files from the 3.0.4 kernel, and successfully built the 3.0.7 kernel for both the Sheevaplug and Dreamplug, It is currently running successfully running on both the types of plug.

Would it be possible to have an "official" cbxbiker build of the kernel?

Many thanks,
PQA

That's excellent, many thanks. I look forward to 3.0.4

It's really helpful to have the kernels built ready for downloading, but I've hit a bit of a stumbling block. I'm moving an application over from an Intel Fedora system to my Sheevaplug and Dreamplug, also using a Fedora rootfs, but the application uses the conntrack program. This program is built and included in the Fedora F13 ARM builds, but it needs kernel module nf_conntrack_netlink.ko. Would it be possible to include CONFIG_NF_CT_NETLINK=m in future kernel builds?

With many thanks for all your good work.

I'm slightly confused by this. I've just built the toolchain using the script, and it builds gcc ver 4.5.2.

Looking at the script, at line 267 the "if false; then" line stops the downloading of the vanilla gcc 4.5.2 a couple of lines below, but it also stops the downloading of Gcc-4.5.2-4.5.2.patch.xz at line 277.

At line 323 it attempts to apply the patch, which I can only presume failed (unfortunately I didn't redirect the output from the script  to a file and the script takes over 2 hours to run on my system so I haven't re-run it), and it carried on to build ver 4.5.2.

Since the message above says that it builds 4.5.3, should it be downloading and applying the 4.5.2 to 4.5.3 patch?

The only Marvell patches for u-boot that I can currently find on Marvell's web site are for version 3.4.23. Is there somewhere that the patches for earlier versions are kept, and can they be downloaded from there?

I have also noticed references to 3.4.24 and 3.4.25; are the patches for these versions available from somewhere (even if they aren't working properly)?