• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1] 2 3 ... 5
Author Topic: 3.9.0+ Device-tree kernels  (Read 28503 times)
cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« on: April 30, 2013, 02:01:29 AM »

OK, well I've been converting to devicetree based kernels for arm.  This will allow me to properly support quite a few variations of the kirkwood and dove based devices, others as well (DeviceTree is awesome from a distribution standpoint).

UPDATE-KERNEL.sh will work with the kernel's starting at 3.9.0, for anything prior, continue to use the older scripts.

The UPDATE-KERNEL.sh is a work-in-progress, right now I know it works properly on SheevaPlug's and CuBox's.  Theoretically it will work for the other variations as well, feedback would be appreciated.

UPDATE-KERNEL.sh attempts to identify the device based on entries in the /proc filesystem.  In those cases where it id's the device correctly, all that is necessary is "sudo ./UPDATE-KERNEL.sh 3.9.0", for devices that aren't id'd correctly "sudo ./UPDATE-KERNEL.sh 3.9.0 device-type" should work.

The earliest version of UPDATE-KERNEL.sh, wasn't optimal (from a distribution standpoint), and I rewrote it to download the zImage and a corresponding .dtb file, that will be the version that you want.  You can grab it from http://www.xilka.com/sheeva/tmp/UPDATE-KERNEL.sh (the version in /sheeva should be OK after the web server caches have a chance to update).  Keep in mind that I haven't got auto detection setup properly for devices other than SheevaPlug, SheevaPlug-eSATA and CuBox.  After you have installed a device-tree kernel, from that point on the auto-detection should work reliably since I can use entries in /proc/device-tree.

Logged

bad_gui
Jr. Member
**

Karma: 0
Posts: 50


View Profile
« Reply #1 on: April 30, 2013, 06:56:54 PM »

I ran the new script on my Guruplug plus and it gabbed this:

kirkwood-sheevaplug-3.9.0.dtb

instead of this

kirkwood-guruplug-server-plus-3.9.0.dtb

I did a netinstall of Wheezy a while ago (Linux guruplug 3.2.0-4-kirkwood #1 Debian 3.2.41-2 armv5tel GNU/Linux)
so my /proc/device-tree is empty

My /proc/cpuinfo shows this

Code:
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1191.11
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell eSATA SheevaPlug Reference Board
Revision        : 0000
Serial          : 0000000000000000


Since the wrong .dtb file was downloaded, then the wrong uImage was created (if I understand this function correctly)

Code:
MkImage()
{
        cat $Platform-$KVer-zImage $Platform-$Device-$KVer.dtb > /tmp/zImage.$Device$$

        $MKIMAGE -A arm -O linux -C none  -T kernel -a 0x00008000 -e 0x00008000 \
                -n "Linux-$Platform-$Device-$KVer" \
                -d /tmp/zImage.$Device$$ \
                $Platform-$Device-$KVer-uImage

        rm /tmp/zImage.$Device$$
}
Logged

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #2 on: May 01, 2013, 02:06:06 AM »

Yes, that's correct it created a wrong uImage.  I think I need to rewrite it so that a second parameter will always override the assumed device.  That should take care of that.  I'm sure in the meantime you could patch the script to do that.
Logged

bad_gui
Jr. Member
**

Karma: 0
Posts: 50


View Profile
« Reply #3 on: May 01, 2013, 06:02:39 PM »

I deleted all downloaded files (including the new ones in /boot), edited the script to
define  AssumedDevice='guruplug-server-plus' and it ran without errors.  I copied the
new kirkwood-guruplug-server-plus-3.9.0-uImage to /boot/uImage
and rebooted but the system froze after booting kernel.

When I try a cold reboot I get this

Code:
Reset IDE: ide_preinit failed
** Bad partition 1 **
** Bad partition 1 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Here is the (relevant snip) boot command from printenv

bootcmd=setenv bootargs $(bootargs_console); run bootcmd_sata; bootm 0x00800000 0x01100000
bootcmd_sata=ide reset; ext2load ide 0:1 0x00800000 /uImage; ext2load ide 0:1 0x01100000 /uInitrd

Here is the content of /boot    It seems to me that the initrd.img is specific for kernel 3.2.0-4-kirkwood
and that is causing the problem?

Code:
drwxr-xr-x 2 root root   12288 Jan 23 21:33 lost+found
lrwxrwxrwx 1 root root      24 Jan 23 21:47 vmlinuz -> vmlinuz-3.2.0-4-kirkwood
lrwxrwxrwx 1 root root      27 Jan 23 21:47 initrd.img -> initrd.img-3.2.0-4-kirkwood
-rw-r--r-- 1 root root 1606512 Mar 27 15:40 vmlinuz-3.2.0-4-kirkwood
-rw-r--r-- 1 root root 1207425 Mar 27 15:41 System.map-3.2.0-4-kirkwood
-rw-r--r-- 1 root root  107503 Mar 27 15:41 config-3.2.0-4-kirkwood
-rw-r--r-- 1 root root 1606576 Apr  8 23:22 uImage.bak-kernel-3.2.04-kirkwood
-rw-r--r-- 1 root root 7360243 Apr  8 23:22 uInitrd.bak
-rw-r--r-- 1 root root 7439034 Apr 25 20:27 initrd.img-3.2.0-4-kirkwood
-rw-r--r-- 1 root root 1606576 Apr 25 20:27 uImage-kernel-3.2.04-kirkwood
-rw-r--r-- 1 root root 7439098 Apr 25 20:27 uInitrd
-rw-r--r-- 1 root root 1497556 Apr 30 21:52 kirkwood-3.9.0-System.map
-rw-r--r-- 1 root root 2455457 Apr 30 21:52 kirkwood-guruplug-server-plus-3.9.0-uImage
-rw-r--r-- 1 root root 1606576 May  1  2013 uImage
Logged

bad_gui
Jr. Member
**

Karma: 0
Posts: 50


View Profile
« Reply #4 on: May 02, 2013, 05:49:40 PM »

After reading more about uInitrd I realize that isn't the problem

I tried booting the new 3.9.0 kernel from a tftp server and got the same freeze


Code:
Marvell>> bootm 0x800000
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-kirkwood-guruplug-server-p
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2455393 Bytes = 2.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using machid 0xa76 from environment

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

This seems linke the problem described on the bottom of this page
 http://wiki.beyondlogic.org/index.php/GuruPlug_Building_Kernel

but the config file for 3.9.0
http://www.xilka.com/sheeva/3/3.9/3.9.0/release/1/kirkwood-3.9.0.config
shows that the relevant change was made for compatibility with old u-boot versions

Quote
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_PHYS_OFFSET=0x0


Anyone have any suggestions on how to troubleshoot this?
Logged

bad_gui
Jr. Member
**

Karma: 0
Posts: 50


View Profile
« Reply #5 on: May 03, 2013, 08:53:44 PM »

Perhaps this is the cause of the hang?

http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree

Quote
To use device tree on arm, both bootloader (U-Boot) and kernel should be compiled with the support of device tree.
U-Boot
Note    Note: The APF27/U-boot 2012.04.01 patch 3.6, APF28/U-Boot 2012.04.01 patch 1.5 and APF51/U-Boot 2012.04.01 patch 1.5 are already configured to support device tree.


To enable device tree on u-boot, it's quite simple:

    add "#define CONFIG_OF_LIBFDT" in the u-boot configuration file (include/configs/<board>.h).

My U-boot version is
Quote
U-Boot 2011.12 (Mar 11 2012 - 18:53:15)
which likely doesn't support device tree?

I am hesitant to change my U-boot since it works fine with my previous kernel but this seems to explain my problem?
Logged

Veda
Newbie
*

Karma: 0
Posts: 2


View Profile
« Reply #6 on: May 06, 2013, 11:52:24 AM »

Hi bad_guy,

same problem here. I've tried this U-boot:

http://people.debian.org/~tbm/u-boot/2012.04.01-2/sheevaplug/u-boot.kwb

and it didn't change anything. Don't know if there is a more recent version...

By the way, I own a standard SheevaPlug which I modified in order to add an e-sata port; I'm booting from an external e-sata hard drive using an initrd image created using the latest kernel.

Perhaps this is the cause of the hang?

http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree

Quote
To use device tree on arm, both bootloader (U-Boot) and kernel should be compiled with the support of device tree.
U-Boot
Note    Note: The APF27/U-boot 2012.04.01 patch 3.6, APF28/U-Boot 2012.04.01 patch 1.5 and APF51/U-Boot 2012.04.01 patch 1.5 are already configured to support device tree.


To enable device tree on u-boot, it's quite simple:

    add "#define CONFIG_OF_LIBFDT" in the u-boot configuration file (include/configs/<board>.h).

My U-boot version is
Quote
U-Boot 2011.12 (Mar 11 2012 - 18:53:15)
which likely doesn't support device tree?

I am hesitant to change my U-boot since it works fine with my previous kernel but this seems to explain my problem?
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #7 on: May 07, 2013, 05:09:17 PM »

I have an original (well, v2) SheevaPlug, with the original U-Boot on it.

I've running 3.9.0 with no problem (boot from SD card - all files other than /boot on an external USB drive).
Logged

Veda
Newbie
*

Karma: 0
Posts: 2


View Profile
« Reply #8 on: May 12, 2013, 01:01:37 PM »

Tried compiling u-boot-2013.04, after patching it with sata and sdio, and enabling #define CONFIG_OF_LIBFDT in include/configs/sheevaplug.h...

Still no go. Also tried with new kernel 3.9.1 and it didn't work.
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #9 on: May 13, 2013, 01:34:35 AM »

I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base.

So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels.
Logged

Tony Pemberton

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #10 on: May 13, 2013, 10:00:29 AM »

I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base.

So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels.

You're using the kernel's on e-SATA plugs and I'm using them on the original Sheevaplug (booting from SD), so it appears that they work on both.

When you say using the "same" kernel, do you mean the same uImage?  If so that would be the wrong thing to do.  The uImage is a merged common zImage with the appropriate .dtb appended.  The .dtb is what differentiates the different models (see UPDATE-KERNEL.sh).
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #11 on: May 14, 2013, 01:33:08 AM »

Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want.

Although I havn't checked yet, yes, I think my problem is  use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion.

Logged

Tony Pemberton

cbxbiker61
Global Moderator
Sr. Member
*****

Karma: 38
Posts: 497


View Profile
« Reply #12 on: May 14, 2013, 04:04:23 PM »

Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want.

Although I havn't checked yet, yes, I think my problem is  use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion.



I've just updated 3.9.2 to build sata_mv into the kernel, this should work fine for sheevaplug-esata boot from sata.  The main reason that I didn't build sata_mv into the kernel before was that the standard sheeva's were hanging on boot due to missing sata hardware.  That should no longer be the case with .dtb kernels.
Logged

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #13 on: May 15, 2013, 04:51:25 AM »

@cbxbiker Many thanks for that.  Smiley I'll have a tinker later when I get a couple of hours.

I had a look at your site and see there are many patches that I had not seen previously so there is some 'reading' I have to do. Keep up the good work!

I still need to get to grips with Device Trees for my own satisfaction (its the old geek in me I guess) and other embedded hardware I wish to develop.
Logged

Tony Pemberton

apemberton
Newbie
*

Karma: 1
Posts: 31


View Profile
« Reply #14 on: May 15, 2013, 10:38:12 AM »

Well I tried the precompiled 3.9.2 kernel on my compiler/test eSata Sheevaplug using the script but my system did not boot. It loaded the uImage but then failed to load. I am pretty sure that the problem is that I am using EXT4 on root (/dev/sda1) and by default, I see that EXT4 is not set up either as a module or builtin.

Therefore, I am starting to build a 3.9.2 kernel with Device Tree from scratch! Its edukayshun innit!
Logged

Tony Pemberton

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