• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2 3 ... 34
1  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: March 24, 2014, 11:27:54 PM
I would like to update my GP+ kernel to the newest ones using the update script, but I don't know how to do it. Let me explain a bit more...

I'm running ArchLinux. Arch on GPs comes with a 3.1 kernel, but I am using 3.7.9 kernel downloaded from xilka. Until now I have been manually installing kernels from uboot via tftpboot/nand erase/nand write. So my GP+ reads the kernel from the NAND, and then the filesystem is mounted from the microSD card.

I was going to test manually updating to the latest 3.13 kernel, but now I see that not only the kernel image is needed, also the device tree must be flashed. And I don't know where do I need to flash it or how. So I think now it's time to do things the right way: updating the system using the update script instead of manually messing with uboot.

How can I do it? Do I need to format the internal flash in a special way and mount it? What boot command/params should I set it uboot? Is there a step by step tutorial anywhere?

Unfortunately I don't have a GP+ to test on, so here's how you probably want to proceed.

The kernel image is built with a device-tree backward compatibility mode,  If you look at the script you will see that it "merges" the zImage with the appropriate .dtb file.  When the zImage is loaded it looks for a .dtb that is appended to it's tail.  The .dtb describes the hardware and everything should work.

That merged zImage/.dtb can be in either system flash or on removable media (if your u-boot supports that).  If you look at the section that handles the original sheevaplug you should be able to duplicate that functionality for a GP+.

Please get back to me with patches if you decide to proceed with enhancing the UPDATE-KERNEL.sh script.

2  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: December 12, 2013, 11:08:06 PM
apemberton, it's great that your testing on a wide variety of systems!

I fixed the typo in UPDATE-KERNEL.sh, it may be a while before it makes it's way to the main web servers due to caching.

As far as the mvsdio interrupt warning, I'm seeing that on my sheevaplug and it hasn't caused any problems for me.  I'm sure that in due time someone will figure out what changed in the interrupt handling code and fix it.
3  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: October 09, 2013, 02:43:42 PM
cbxbiker61, at 1st thx for your work

now what about libertas_uap (uap8xxx.ko) module which needed for WiFi access point of guruplug server?
i can't find it in the modules for kirkwood images

I don't have a lot of time to look at this at the moment, but there is a "fresh" 3.2.51 kernel with that module.
4  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 27, 2013, 01:38:55 PM
ok, the latest xilka kirkwood kernels (3.11.2) are compiled with the serial console fix.
5  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: September 25, 2013, 11:31:40 AM
Yeah, you will be fine skipping that patch for kernel builds.

And yes, you must populate that armv* directory with "certain" files from your target machine's /usr/lib or /lib and /usr/include.  For the most part they really don't come into play with a kernel build, but some of the build process expects to find them.
6  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels 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.
7  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels 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
8  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: June 22, 2013, 12:09:51 PM
Tony, make sure your bootargs have bootdelay=3 and rootwait=3.  This fixes quite a few boot issues, and doesn't noticeably change the boot speed.

It is also possible that device tree hasn't been fully sorted on those devices.  There have been a LOT of commits in the device tree code lately, so thing should be getting better in the 3.10 and 3.11 kernels.
9  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: June 20, 2013, 04:23:23 PM
Current version 3.9.7.

Hey.  I've updated my kernel support script to handle sheevaplug/CuBox/Raspberry Pi.

The sheevaplug and CuBox kernel's are device-tree kernels.  They are built in a compatibility mode so they do not require a u-boot that has device-tree capability.

The Raspberry Pi kernel has been built with gps-gpio support so you can build an inexpensive stratum-1 timeserver.  More details about that in the README.txt.  I just finished building my stratum-1 server yesterday.

http://www.xilka.com/kernel/README.txt

http://www.xilka.com/kernel/UPDATE-KERNEL.sh
10  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels on: May 15, 2013, 07:00:43 PM
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!

I'm not sure what you're looking at...but it's not the config I'm using, which has always had EXT4 built-in.
11  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels 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.
12  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels 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).
13  Linux Stuff / Kernel / Re: 3.9.0+ Device-tree kernels 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.
14  Linux Stuff / Kernel / 3.9.0+ Device-tree kernels 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.

15  Linux Stuff / Kernel / Re: sheeva/dream 3.6.6 new kernel available on: April 30, 2013, 01:59:36 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.

Pages: [1] 2 3 ... 34