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.