• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2
1  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 25, 2013, 12:32:11 AM
cbxbiker, birdman, many thanks for the cross-compile info.

At the moment I'm going to go with trying to build a toolchain.

Cbxbiker - I have found a couple of problems with running the script:
1) http://www.xilka.com/xilka/source/patches/Gcc-4.8.2-arm-thumb2-CASE_VECTOR_SHORTEN_MODE.patch does not exist in http://www.xilka.com/xilka/source/patches
2) I get "ERROR 502: Bat Gateway." when I try to download http://www.xilka.com/xilka/source/patches/BinUtils-2.23.2-Add-supports-of-the-Marvell-PJ4-core.patch

Since the above patches don't look armv5te related, I have continued without them.

I found the following patch is also needed, to allow binutils to compile:

Finally, in section 034/059, there is a copy from ~/source/src/CrossArm/root/$Target/{lib,usr/lib,usr/include}/* into the $respin directory tree. I'm not clear what is copied, nor how the files there are constructed. For the time being, I have copied the whole of /lib, /usr/lib, /usr/include from the target system to ~/source/src/CrossArm/root/$Target/{lib,usr/lib,usr/include}, but that seems overkill, and may not be the right way to do it.

So, I now have a build toolchain, so I'll start trying to build some kernels, but it would be good to resolve the above points so I know I am building with something equivalent to what you are using.

2  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 20, 2013, 03:59:23 AM
Regarding the console problem, I have identified the following so far:

The Fedora 3.10.10 kernel with device tree, with the working console, reports the following in dmesg at boot time:
[   19.249385] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[   19.250677] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[   19.775383] console [ttyS0] enabled

The Cbxbiker 3.10.10 kernel reports:
[   12.563947] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
and then a few lines later:
[   12.691809] Warning: unable to open an initial console.

so it's clearly not finding the serial port.
The obvious difference here, other than not reporting the hardward, is that the Fedora kernel has interrupt sharing enabled.

Looking at the device trees, the main differences are:
clocks = <0x03, 0xn>          # throughout the device tree
phandle for core-clocks = 0x02
phandle for clock-gating-control = 0x03

clocks = <0x02, 0xn>
phandle for core-clocks = 0x03
phandle for clock-gating-control = 0x02

The clocks value is specified in the source file as &gate_clk, and I haven't found how the device tree compiler translates that to 0x02 or 0x03.
The phandle entries are generated by the DT compiler.

Also, Cbxbiker has applied the following patches:
Added cpus section
patched address of crypto engine
but neither of these would appear to affect the console.

There are lots of differences in the kernel configuration, but I've tried to pick out the ones relevant to the UART:
# CONFIG_SERIAL_8250_EXTENDED is not set

# CONFIG_SERIAL_8250_DETECT_IRQ is not set

Since the working console output is referencing MMIO, I have also had a look at the kernel config relating to that.



I'm guessing here, but I wonder if CONFIG_REGMAP_MMIO=y needs to be set for the serial port hardware to be found.

If someone can point me to a suitable cross-compiling toolchain for an Intel x86_64 host, I'm happy to try building some kernels to find out what change makes the difference.
3  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 18, 2013, 07:11:58 AM
Thanks for the update re read-only rootfs. After booting the rootfs is definitely mounted read-only, so it looks like my systemd scripts aren't running properly then when using the Cbxbiker kernels. I dig into this a bit more. It's probably due to Fedora using an initrd, and I am now suspecting that some scripts are run on that before switching to the permanent rootfs.
4  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 17, 2013, 04:43:49 PM
I am having one other problem with the Cbxbiker kernels, which I don't get with a Fedora kernel (my root filesystem is on sdb3).

Part way through the boot process, I get the following messages in the log:
[    9.821912] EXT3-fs (sdb3): error: couldn't mount because of unsupported optional features (240)
[    9.823149] EXT2-fs (sdb3): error: couldn't mount because of unsupported optional features (240)
[    9.840065] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[    9.840113] VFS: Mounted root (ext4 filesystem) readonly on device 8:19.

and I end up with the root filesystem mounted read only.

Can anyone give me some suggestions about what is causing this problem.

Many thanks.
5  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 17, 2013, 01:11:29 PM

The Fedora kernels are downloadable from http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=3547 . The fc18 series are the last ones being built for armv5tel. If  you click on a kernel you are interested in, there is an option to download the source RPM. Alternatively all the source files for the build, except the kernel itself, are available from http://pkgs.fedoraproject.org/cgit/kernel.git/log/?h=f18

6  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 17, 2013, 07:24:51 AM
apemberton, my Fedora 3.10.10 kernel IS a device tree kernel, booting a dreamplug device tree.

I have noticed that the device trees from Fedora are not the same as the device trees from Cbxbiker, so I will have a look at that and see if I can fathom if there is anything there.
7  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 16, 2013, 06:54:41 PM
I have just booted my Dreamplug on a 3.10.9 cbxbiker kernel, and also a 3.11.1 kernel, and like others I am not getting console output.

I have also attempted to boot a Fedora 3.10.10 kernel, and that IS prodicing console output. It won't bring the system up, however, since for some reason it is not loading orion-ehci.

So it would appear that it is probably not a kernel problem that is causing the lack of console output, but a build/configuration issue.
8  Linux Stuff / Kernel / Re: 3.1 new kernel available 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.

9  Linux Stuff / Kernel / Re: 3.1 new kernel available 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.

10  Linux Stuff / Kernel / Re: 3.1 new kernel available on: November 03, 2011, 09:30:31 AM

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.

11  Linux Stuff / Kernel / Re: 3.1 new kernel available on: October 25, 2011, 12:40:06 AM

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:


have gone, and are replaced by

I think the following also needs to be added:

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?


12  Linux Stuff / Kernel / 3.0.7 new kernel on: October 19, 2011, 07:28:52 AM

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,

13  Linux Stuff / Kernel / Re: 3.0.3 new kernel available on: August 21, 2011, 12:40:38 AM
That's excellent, many thanks. I look forward to 3.0.4 Smiley
14  Linux Stuff / Kernel / Re: 3.0.3 new kernel available on: August 20, 2011, 09:35:13 AM
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.
15  Linux Stuff / Kernel / Re: New toolchain build script available on: August 20, 2011, 09:17:34 AM
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?
Pages: [1] 2