Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor II
5,989 Views

Newer Kernel on Edison (OpenWrt)

I have been spending some time trying to get a newer kernel running on the Edison and that has turned out to be a bit of a jungle. Ultimately, I want to get OpenWrt running on the module and in order to do that, kernel 3.18 (current mainstream) or 4.0 (next mainstream) kernels would be the preferred choice.

Googling a lot I found very little on this topic. By far the most encouraging was this blog post:

http://habrahabr.ru/post/254247/ Запускаем свежайшее ядро Linux на Intel Edison / Хабрахабр

Which unfortunately is in Russian (of which I understand absolutely nothing - but with a little help from Google Translate I got the gist of it).

I have now tried quite a number of different approaches. I have tried to follow the method outlined in the above blog post. I have tried a linux-4.0.1 kernel from kernel.org with the original Edison .config as a starting point or with the stdconfig outlined in the blogpost + lines added. I have also tried simply replacing the /boot/vmlinuz on a working edison rather than going through the elaborate process described in the blog. No matter what - the result is the same each and every time:

U-boot finds the kernel, loads it, identifies it and start running it - and then nothing. about a minute later (probably watchdog related) the device reboots.

My guess is that the kernel might actually run but I don't get the console output. By default, Edison is using ttyMFD2 for logging, but that require support in the kernel for the high speed UART in the Edison. The thing is - I would suspect that support IS actually there in kernel 4.0.1 (but that contradicts what the Russian is writing in the above).

I got the following in my .config:

CONFIG_SERIAL_MFD_HSU=y

CONFIG_SERIAL_MFD_HSU_CONSOLE=y

CONFIG_EARLY_PRINTK_INTEL_MID=y

Just for the hell of it I also tried:

CONFIG_SERIAL_EARLYCON=y

CONFIG_SERIAL_8250=y

CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y

CONFIG_SERIAL_8250_CONSOLE=y

CONFIG_SERIAL_8250_SYSRQ=y

CONFIG_SERIAL_8250_DMA=y

CONFIG_SERIAL_8250_PCI=y

CONFIG_SERIAL_8250_NR_UARTS=4

CONFIG_SERIAL_8250_RUNTIME_UARTS=4

I have tried to pass various arguments to the kernel:

console=ttyMFD2

console=ttyMFD1 (MFD0 appears to be bluetooth in the edison, so if that doesn't exist.....)

console=ttyMFD0

console=ttyS0

console=ttyS1

console=ttyS2

console=ttyS3

 

No luck - no go. Unfortunately the above blog offers no way I can identify to contact the blog author, but I can of course hope that he is following this forum and that his English is a bit better than my Russian.

 

Else - any ideas, hints or suggestions would be greatly appreciated. I am on Jabber/XMPP for chat if anybody is interested in working with me on this.

 

Lars Boegild Thomsen

Jabber/XMPP: mailto:lth@bright-things.com lth@bright-things.com

 

228 Replies
Highlighted
New Contributor II
123 Views

After 2 all nighters on this one I decided on a slightly different approach. The tricky part here is Intel's quite insane 150 k line single patch. That is _really_ hard to deal with. So I decided to do the following:

1. A few lines of awk that chop Intel's patch into - hold on to something - 475 different small patches nicely numbered.

2. Try to build OpenWrt around the 3.10.17 kernel using the standard Quilt + the above 475 patch files

And voila - that actually worked quite well. For a start I used the OpenWrt build root to create a kernel and threw that on the Edison as a replacement - and that worked fine and more important - I got console output so I can see what I am doing.

Next step now would be to get the rest of OpenWrt bundled around this kernel and make some flashable images, but that is a hell of a lot easier than the kernel stuff.

Finally, once this is up and running, I will probably work my way up in kernel versions. It should be quite easy to get up to the last 3.10 (it is what - .78 or thereabouts), but by taking small steps and tweaking/removing individual patches along the way - it should be reasonably easy to get up to a kernel version from this century.

Highlighted
New Contributor II
123 Views

After 2 all nighters on this one I decided on a slightly different approach. The tricky part here is Intel's quite insane 150 k line single patch. That is _really_ hard to deal with. So I decided to do the following:

1. A few lines of awk that chop Intel's patch into - hold on to something - 475 different small patches nicely numbered.

2. Try to build OpenWrt around the 3.10.17 kernel using the standard Quilt + the above 475 patch files

And voila - that actually worked quite well. For a start I used the OpenWrt build root to create a kernel and threw that on the Edison as a replacement - and that worked fine and more important - I got console output so I can see what I am doing.

Next step now would be to get the rest of OpenWrt bundled around this kernel and make some flashable images, but that is a hell of a lot easier than the kernel stuff.

Finally, once this is up and running, I will probably work my way up in kernel versions. It should be quite easy to get up to the last 3.10 (it is what - .78 or thereabouts), but by taking small steps and tweaking/removing individual patches along the way - it should be reasonably easy to get up to a kernel version from this century.

Highlighted
Novice
123 Views

I would certainly like to follow your progress with this. I am horribly confused as to how the Intel Edison BSP was ever allowed to be such a horrible mess!

I have not been able to figure out how to integrate these patches into any newer version of the kernel, I haven't been able to transplant the 3.10.17 kernel into any other useful distribution and Yocto makes me want to scream.

From what I can tell, these Intel patches are awfully lazy - rather than adding in new definitions/drivers into the kernel in a portable way, they are simply overwriting definitions for the Moorestown processors. Surely this means that these patches are therefore destructive, kernel version specific and can never be contributed upstream into the main Linux kernel repository?

In which case, if we can't bring this platform back up into the main Linux kernel with some decent device support, then what good is this platform to anyone?

Highlighted
Novice
123 Views

I would certainly like to follow your progress with this. I am horribly confused as to how the Intel Edison BSP was ever allowed to be such a horrible mess!

I have not been able to figure out how to integrate these patches into any newer version of the kernel, I haven't been able to transplant the 3.10.17 kernel into any other useful distribution and Yocto makes me want to scream.

From what I can tell, these Intel patches are awfully lazy - rather than adding in new definitions/drivers into the kernel in a portable way, they are simply overwriting definitions for the Moorestown processors. Surely this means that these patches are therefore destructive, kernel version specific and can never be contributed upstream into the main Linux kernel repository?

In which case, if we can't bring this platform back up into the main Linux kernel with some decent device support, then what good is this platform to anyone?

Highlighted
New Contributor II
123 Views

One of the main issues is that the patch contains a lot of stuff that is irrelevant for the Edison device and it is pretty hard to nail down exactly what is needed and what is not.

I have been changing directions a few times. As mentioned in an earlier message I initially tried to port all the patches to a newer kernel. I have admittedly turned a bit cold on that one, so I am back to the Russian guys approach. IF I could get a 4.0 kernel up and running on the Edison WITH console output then I'd be in business. Once I got the kernel starting and the console output so I can see what is happening, then it'd be a relatively simple matter to cherry pick the necessary patches/drivers from the old kernel and bring them up to date.

By using OpenWrt's Quilt approach to patching it becomes a lot more structured and manageable.

Unfortunately so far I have _still_ not managed to get console output on a 4.0 kernel but I have not given up completely yet.

//Lars...

0 Kudos
Highlighted
New Contributor II
123 Views

One of the main issues is that the patch contains a lot of stuff that is irrelevant for the Edison device and it is pretty hard to nail down exactly what is needed and what is not.

I have been changing directions a few times. As mentioned in an earlier message I initially tried to port all the patches to a newer kernel. I have admittedly turned a bit cold on that one, so I am back to the Russian guys approach. IF I could get a 4.0 kernel up and running on the Edison WITH console output then I'd be in business. Once I got the kernel starting and the console output so I can see what is happening, then it'd be a relatively simple matter to cherry pick the necessary patches/drivers from the old kernel and bring them up to date.

By using OpenWrt's Quilt approach to patching it becomes a lot more structured and manageable.

Unfortunately so far I have _still_ not managed to get console output on a 4.0 kernel but I have not given up completely yet.

//Lars...

0 Kudos
Highlighted
Novice
123 Views

Are you using an unpatched vanilla 4.0 kernel in the meantime? I notice that in the 4.0 branch there is some Intel MID support already, although it does not seem as comprehensive as that which is provided in Intel's patch and I have not yet had the opportunity to test it.

Have you managed to overcome the watchdog issue where the device reboots shortly after trying to boot new kernels?

0 Kudos
Highlighted
Novice
123 Views

Are you using an unpatched vanilla 4.0 kernel in the meantime? I notice that in the 4.0 branch there is some Intel MID support already, although it does not seem as comprehensive as that which is provided in Intel's patch and I have not yet had the opportunity to test it.

Have you managed to overcome the watchdog issue where the device reboots shortly after trying to boot new kernels?

0 Kudos
Highlighted
New Contributor II
123 Views

I am currently trying to figure out the difference between the 4.0 kernel and 4.1. I have managed to boot a vanilla 4.1 kernel and that seems to work quite nicely.

It is still a bit rough around the edges, but I am describing the progress of that one here:

https://edison.internet-share.com/wiki/Edison_Firmware_with_Stock_Kernel https://edison.internet-share.com/wiki/Edison_Firmware_with_Stock_Kernel

Status right now - with the 4.1-rc7 stock kernel:

CPU works fine

UARTS detected as 8250 device - console log works on those

USB sub system works fine

I am working on the nand flash right now.

0 Kudos
Highlighted
New Contributor II
123 Views

I am currently trying to figure out the difference between the 4.0 kernel and 4.1. I have managed to boot a vanilla 4.1 kernel and that seems to work quite nicely.

It is still a bit rough around the edges, but I am describing the progress of that one here:

https://edison.internet-share.com/wiki/Edison_Firmware_with_Stock_Kernel https://edison.internet-share.com/wiki/Edison_Firmware_with_Stock_Kernel

Status right now - with the 4.1-rc7 stock kernel:

CPU works fine

UARTS detected as 8250 device - console log works on those

USB sub system works fine

I am working on the nand flash right now.

0 Kudos
Highlighted
Novice
123 Views

Delighted to see that you are making progress. I will attempt later today to follow your guide and see if I can replicate your success.

I examined the source of some of the drivers/firmware loaders from the Intel patches for 802.11b/g/n and Bluetooth this morning, they look straight-forward enough to port. I may see if I can add these into the mix if they are not already working.

It may not be too difficult to backport these efforts into OpenWRT.

0 Kudos
Highlighted
Novice
123 Views

Delighted to see that you are making progress. I will attempt later today to follow your guide and see if I can replicate your success.

I examined the source of some of the drivers/firmware loaders from the Intel patches for 802.11b/g/n and Bluetooth this morning, they look straight-forward enough to port. I may see if I can add these into the mix if they are not already working.

It may not be too difficult to backport these efforts into OpenWRT.

0 Kudos
Highlighted
New Contributor II
123 Views

No, I don't think it will be too difficult at all. Right now I am attempting to see if I can get the 4.0 kernel going rather than the 4.1.rc7. The main reason for that is that OpenWrt is currently using 3.8 or 4.0. If I can't get the 4.0 kernel up and running with console output I will just build the OpenWrt using the 4.1 (which is possible - just require a bit more steps and maintenance).

0 Kudos
Highlighted
New Contributor II
123 Views

No, I don't think it will be too difficult at all. Right now I am attempting to see if I can get the 4.0 kernel going rather than the 4.1.rc7. The main reason for that is that OpenWrt is currently using 3.8 or 4.0. If I can't get the 4.0 kernel up and running with console output I will just build the OpenWrt using the 4.1 (which is possible - just require a bit more steps and maintenance).

0 Kudos
Highlighted
Novice
123 Views

I have built a linux-next kernel and an initrd to go with it based on yours and Andy's instructions, but unfortunately the kernel does not seem to start. It sits at "Starting kernel" for a few seconds, before rebooting itself. I am going to have a look over the build/defconfigs and see if anything stands out.

******* PSH loader *******

PCM page cache size = 192 KB

Cache Constraint = 0 Pages

Arming IPC driver ..

Adding page store pool ..

PagestoreAddr(IMR Start Address) = 0x04899000

pageStoreSize(IMR Size) = 0x00080000

*** Ready to receive application ***

U-Boot 2014.04 (Apr 29 2015 - 03:53:19)

Watchdog enabled

DRAM: 980.6 MiB

MMC: tangier_sdhci: 0

In: serial

Out: serial

Err: serial

Hit any key to stop autoboot: 0

boot > run bootcmd_edsboot

reading vmlinuz.efi

5781808 bytes read in 145 ms (38 MiB/s)

reading initrd

1650194 bytes read in 51 ms (30.9 MiB/s)

Valid Boot Flag

Setup Size = 0x00003e00

Magic signature found

Using boot protocol version 2.0d

Linux kernel version 4.1.0-rc6-next-20150605+ (linux@openwrt-buildroot) # 2 SMP Tue Jun 9 16:04:47 UTC 2015

Building boot_params at 0x00090000

Loading bzImage at address 00100000 (5765936 bytes)

Magic signature found

Initial RAM disk at linear address 0x00800000, size 8388608 bytes

Kernel command line: "console=tty1 console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0x800000,8M"

Starting kernel ...

0 Kudos
Highlighted
Novice
123 Views

I have built a linux-next kernel and an initrd to go with it based on yours and Andy's instructions, but unfortunately the kernel does not seem to start. It sits at "Starting kernel" for a few seconds, before rebooting itself. I am going to have a look over the build/defconfigs and see if anything stands out.

******* PSH loader *******

PCM page cache size = 192 KB

Cache Constraint = 0 Pages

Arming IPC driver ..

Adding page store pool ..

PagestoreAddr(IMR Start Address) = 0x04899000

pageStoreSize(IMR Size) = 0x00080000

*** Ready to receive application ***

U-Boot 2014.04 (Apr 29 2015 - 03:53:19)

Watchdog enabled

DRAM: 980.6 MiB

MMC: tangier_sdhci: 0

In: serial

Out: serial

Err: serial

Hit any key to stop autoboot: 0

boot > run bootcmd_edsboot

reading vmlinuz.efi

5781808 bytes read in 145 ms (38 MiB/s)

reading initrd

1650194 bytes read in 51 ms (30.9 MiB/s)

Valid Boot Flag

Setup Size = 0x00003e00

Magic signature found

Using boot protocol version 2.0d

Linux kernel version 4.1.0-rc6-next-20150605+ (linux@openwrt-buildroot) # 2 SMP Tue Jun 9 16:04:47 UTC 2015

Building boot_params at 0x00090000

Loading bzImage at address 00100000 (5765936 bytes)

Magic signature found

Initial RAM disk at linear address 0x00800000, size 8388608 bytes

Kernel command line: "console=tty1 console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0x800000,8M"

Starting kernel ...

0 Kudos
Highlighted
Novice
123 Views

To follow up on the above, the problem is with the latest bleeding edge of linux-next somewhere. When I checked out the v4.1-rc6 tag, mrproper'd and rebuilt, the new image has booted successfully!

0 Kudos
Highlighted
Novice
123 Views

To follow up on the above, the problem is with the latest bleeding edge of linux-next somewhere. When I checked out the v4.1-rc6 tag, mrproper'd and rebuilt, the new image has booted successfully!

0 Kudos
Highlighted
New Contributor II
123 Views

I managed both although (and I forgot to mention that on the wiki) I did have to checkout a linux-next that was a few days old, because the head failed building at all.

What is way more important is that I managed to get in email touch with Andy and he gave me some pointers exactly what needs to be pack ported to 4.0 to get that running too. It doesn't look too bad actually - I think it is possible.

0 Kudos