• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 2 [3] 4 5
Author Topic: 3.9.0+ Device-tree kernels  (Read 25329 times)
pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #30 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.
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #31 on: September 17, 2013, 02:02:46 AM »

PQA, is your Fedora 3.10.10 kernel a Device Tree kernel? If not, this should help confirm that the console issue is in the Device Tree rather than the kernel itself.

I had a little look at schematics for a Guruplug and some of the Kirkwood data sheet and some of the MPP pins have multiple functions set up depending on initialisation. I see that MPP8 is shared between a gpio control of RTS (Request To Send) for serial and SDA for i2c/smbus; MPP9 is shared between gpio CTS (Clear To Send) and SCK for i2C/smbus.

I have the feeling that when the hardware is activated by the Device Tree code, the setup is not performed correctly for UART0 and possibly for other hardware. I'm not particularly familiar with the Kirkwood architecture so poring over code and datasheets to tie up the devices and initialisation may take some time and I do have other things to do. I am convinced that the kernel itself (as opposed to Device tree) is OK and the problem is not a .config issue.

Logged

Tony Pemberton

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #32 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.
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #33 on: September 17, 2013, 12:23:52 PM »

Thanks for your info and update. I think you are on to it. Is there a link for the Fedora kernel DT source? More minds the better especially to aid my old, worn out grey cells! Tony.
Logged

Tony Pemberton

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #34 on: September 17, 2013, 01:11:29 PM »

Tony,

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

Quentin
Logged

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #35 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.
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #36 on: September 17, 2013, 06:20:12 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..
Are you sure it's an actual problem?
Mine does the same (it tries ext3, ext2, ext4 in that order, hence the error messages).
But shortly after mounting the root readonly (which is always does at start with) it then reports:
Quote
Sep 16 00:23:46 plug kernel: EXT4-fs (sda1): re-mounted. Opts: (null)
Sep 16 00:23:46 plug kernel: EXT4-fs (sda1): re-mounted. Opts: (null)
and it is then mounted read/write.
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #37 on: September 18, 2013, 02:07:23 AM »

I confirm that I find the same as Birdman on the disk thing. Also because my /etc/fstab requires it, my disks are unmounted, a fs check performed and then remounted. This is normal and a bit of a lifesaver as the i-node count get corrupted in service.
Logged

Tony Pemberton

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #38 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.
Logged

pqa
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #39 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:
Cbxbiker:
clocks = <0x03, 0xn>          # throughout the device tree
phandle for core-clocks = 0x02
phandle for clock-gating-control = 0x03

Fedora:
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:
Cbxbiker:
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_USB_SERIAL=m

Fedora:
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y

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

Cbxbiker:
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_VIRTIO_MMIO is not set

Fedora:
CONFIG_REGMAP_MMIO=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_TULIP_MMIO=y
CONFIG_VIA_RHINE_MMIO=y
CONFIG_MDIO_BUS_MUX_MMIOREG=m
CONFIG_RT2X00_LIB_MMIO=m
CONFIG_SPI_DW_MMIO=m
CONFIG_VIRTIO_MMIO=m

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.
« Last Edit: September 20, 2013, 04:02:44 AM by pqa » Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #40 on: September 20, 2013, 03:04:07 PM »

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.
I have the while thing set up for my Plug by using qemu in a VirtualBox host running Debian (which is all on my Linux Mint workstation, so I can run with multiple cores, and lots of memory, if I wish...).
That's quite simple to set-up.  (I have qemu setups there for my Raspberry Pi and Asus66 also..)
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #41 on: September 21, 2013, 08:05:06 AM »



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.


This is my latest script for building my cross-compilers.
When it finishes it will create CrossArm-* which you can extract
in the root directory...that will place the cross compiler in
/opt/cross/armv*.

http://www.xilka.com/xilka/source/BuildCrossArm-4.8-2013.09.sh
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #42 on: September 23, 2013, 02:47:32 PM »

Finally, after much swearing, cussing and almost losing the will to live, I have repaired my development Sheevaplug (new eSata disk drive) and am now in a position to start compiling a kernel natively. I will look at the above config elements tomorrow time permitting and see what is what. It really didn't help repairs with no console output. I also need to mirror disks so a SATA multiplexor to create a RAID array would be nice.

I think you are on the point of cracking the problem. Hopefully someone will confirm the cure!  Cheesy
Logged

Tony Pemberton

marcus11
Newbie
*

Karma: 0
Posts: 8


View Profile
« Reply #43 on: September 24, 2013, 01:55:36 AM »

This is my latest script for building my cross-compilers.
When it finishes it will create CrossArm-* which you can extract
in the root directory...that will place the cross compiler in
/opt/cross/armv*.

http://www.xilka.com/xilka/source/BuildCrossArm-4.8-2013.09.sh


It's not happy on Debian 7 x64:
Code:
--2013-09-24 18:53:40--  http://www.xilka.com/xilka/source/patches/Gcc-4.8.2-arm                                                                                                                                                              -thumb2-CASE_VECTOR_SHORTEN_MODE.patch
Resolving www.xilka.com (www.xilka.com)... 108.62.185.77
Connecting to www.xilka.com (www.xilka.com)|108.62.185.77|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-09-24 18:53:41 ERROR 404: Not Found.

There are a serious number of patches in that directory!!! Smiley
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #44 on: September 24, 2013, 04:16:45 PM »

It's not happy on Debian 7 x64:

I added the missing patch, not a terribly important patch for compiling the kernel.
Logged

Pages: 1 2 [3] 4 5
Print
Jump to: