Is it advisable to build my own kernel for the Chromebook? I glanced through the IRC chat from last week and saw a note about kernels.
On 02/27/2013 11:51 AM, Darryl L. Pierce wrote:
Is it advisable to build my own kernel for the Chromebook? I glanced through the IRC chat from last week and saw a note about kernels.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I built a local version of the kernel because I needed some additional options enabled in the kernel (kprobes and debuginfo) so I could test out systemtap on the chrome book. If the existing kernel works for you, why spend the time on building you own local kernel?
-Will
On Wed, Feb 27, 2013 at 11:21 AM, William Cohen wcohen@redhat.com wrote:
On 02/27/2013 11:51 AM, Darryl L. Pierce wrote:
Is it advisable to build my own kernel for the Chromebook? I glanced through the IRC chat from last week and saw a note about kernels.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I built a local version of the kernel because I needed some additional options enabled in the kernel (kprobes and debuginfo) so I could test out systemtap on the chrome book. If the existing kernel works for you, why spend the time on building you own local kernel?
-Will
Darryl,
I would advise you build your own kernel.
The upstream chromeos-3.4 contains many fixes, including the audio fix so you do not risk melting the speakers. I would also advise you enable audit_syscall. Enabling the PERF stuff is also a good idea.
William has a great kernel doc on his people page that goes over this stuff.
On 02/27/2013 01:52 PM, Jon wrote:
On Wed, Feb 27, 2013 at 11:21 AM, William Cohen <wcohen@redhat.com mailto:wcohen@redhat.com> wrote:
On 02/27/2013 11:51 AM, Darryl L. Pierce wrote: > Is it advisable to build my own kernel for the Chromebook? I glanced > through the IRC chat from last week and saw a note about kernels. > > > > _______________________________________________ > arm mailing list > arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/arm > I built a local version of the kernel because I needed some additional options enabled in the kernel (kprobes and debuginfo) so I could test out systemtap on the chrome book. If the existing kernel works for you, why spend the time on building you own local kernel? -Will
Darryl,
I would advise you build your own kernel.
The upstream chromeos-3.4 contains many fixes, including the audio fix so you do not risk melting the speakers. I would also advise you enable audit_syscall. Enabling the PERF stuff is also a good idea.
There have been a number of corrections and improvements in the git repo kernel, but the earlier comment was kind of the "if it ain't broke, don't fix it." It takes a little while to set things up and build the kernel and install it. Daryl, if you need help to set it up I can help you.
William has a great kernel doc on his people page that goes over this stuff.
http://people.redhat.com/wcohen/chromebook/chrome_kernel.txt
I wished that we had a srpm setup for the chromebook git kernel, then could point people at the koji build. However, need to have the uboot built for chromebook also need vboot-utils.
-Will
Regarding the exynos kernel srpm, i am working on that as time permits. Still not sure how to handle the install of the kernel from the rpm. I guess for now let the user manually sign & pack with vboot-utils. The location of the chromium boot partition is unpredictable. Maybe setup a file in /etc/sysconfig/ with parameters.
Vboot-utils should be accepted soon once my sponsor reviews the package BZ.
Agree with ain't broke don't fix. :-P On Feb 27, 2013 1:16 PM, "William Cohen" wcohen@redhat.com wrote:
On 02/27/2013 01:52 PM, Jon wrote:
On Wed, Feb 27, 2013 at 11:21 AM, William Cohen <wcohen@redhat.com<mailto:
wcohen@redhat.com>> wrote:
On 02/27/2013 11:51 AM, Darryl L. Pierce wrote: > Is it advisable to build my own kernel for the Chromebook? I
glanced
> through the IRC chat from last week and saw a note about kernels. > > > > _______________________________________________ > arm mailing list > arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/arm > I built a local version of the kernel because I needed some
additional options enabled in the kernel (kprobes and debuginfo) so I could test out systemtap on the chrome book. If the existing kernel works for you, why spend the time on building you own local kernel?
-Will
Darryl,
I would advise you build your own kernel.
The upstream chromeos-3.4 contains many fixes, including the audio fix
so you do not risk melting the speakers.
I would also advise you enable audit_syscall. Enabling the PERF stuff is also a good idea.
There have been a number of corrections and improvements in the git repo kernel, but the earlier comment was kind of the "if it ain't broke, don't fix it." It takes a little while to set things up and build the kernel and install it. Daryl, if you need help to set it up I can help you.
William has a great kernel doc on his people page that goes over this
stuff.
http://people.redhat.com/wcohen/chromebook/chrome_kernel.txt
I wished that we had a srpm setup for the chromebook git kernel, then could point people at the koji build. However, need to have the uboot built for chromebook also need vboot-utils.
-Will _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 02/27/2013 02:48 PM, Jon wrote:
Regarding the exynos kernel srpm, i am working on that as time permits. Still not sure how to handle the install of the kernel from the rpm. I guess for now let the user manually sign & pack with vboot-utils. The location of the chromium boot partition is unpredictable. Maybe setup a file in /etc/sysconfig/ with parameters.
The approach suggested at FUDcon2013 in Lawrence was have a version of uboot signed with vboot-utils and use that to boot up the actual kernel. uboot doesn't change nearly as fast as the kernel do and this will make the install process more like the other arm installations for the kernel.
Vboot-utils should be accepted soon once my sponsor reviews the package BZ.
I am looking forward to an official version of vboot-utils.
Agree with ain't broke don't fix. :-P
Yes, a finite amount of time and an infinite queue of things to do. Some things get pushed to the back of the queue. :)
-Will
On Feb 27, 2013 1:16 PM, "William Cohen" <wcohen@redhat.com mailto:wcohen@redhat.com> wrote:
On 02/27/2013 01:52 PM, Jon wrote: > > > On Wed, Feb 27, 2013 at 11:21 AM, William Cohen <wcohen@redhat.com <mailto:wcohen@redhat.com> <mailto:wcohen@redhat.com <mailto:wcohen@redhat.com>>> wrote: > > On 02/27/2013 11:51 AM, Darryl L. Pierce wrote: > > Is it advisable to build my own kernel for the Chromebook? I glanced > > through the IRC chat from last week and saw a note about kernels. > > > > > > > > _______________________________________________ > > arm mailing list > > arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> <mailto:arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org>> > > https://admin.fedoraproject.org/mailman/listinfo/arm > > > > I built a local version of the kernel because I needed some additional options enabled in the kernel (kprobes and debuginfo) so I could test out systemtap on the chrome book. If the existing kernel works for you, why spend the time on building you own local kernel? > > -Will > > > Darryl, > > I would advise you build your own kernel. > > The upstream chromeos-3.4 contains many fixes, including the audio fix so you do not risk melting the speakers. > I would also advise you enable audit_syscall. > Enabling the PERF stuff is also a good idea. There have been a number of corrections and improvements in the git repo kernel, but the earlier comment was kind of the "if it ain't broke, don't fix it." It takes a little while to set things up and build the kernel and install it. Daryl, if you need help to set it up I can help you. > > William has a great kernel doc on his people page that goes over this stuff. http://people.redhat.com/wcohen/chromebook/chrome_kernel.txt I wished that we had a srpm setup for the chromebook git kernel, then could point people at the koji build. However, need to have the uboot built for chromebook also need vboot-utils. -Will _______________________________________________ arm mailing list arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/arm
On 02/27/2013 01:52 PM, Jon wrote:
I would advise you build your own kernel.
The upstream chromeos-3.4 contains many fixes, including the audio fix so you do not risk melting the speakers. I would also advise you enable audit_syscall. Enabling the PERF stuff is also a good idea.
Jon,
So the setting CONFIG_AUDIT=y works with the chrome book kernel from their git repo? There were some fedora kernels where the audit stuff didn't work at all.
-Will
On Wed, Feb 27, 2013 at 3:31 PM, William Cohen wcohen@redhat.com wrote:
On 02/27/2013 01:52 PM, Jon wrote:
I would advise you build your own kernel.
The upstream chromeos-3.4 contains many fixes, including the audio fix
so you do not risk melting the speakers.
I would also advise you enable audit_syscall. Enabling the PERF stuff is also a good idea.
Jon,
So the setting CONFIG_AUDIT=y works with the chrome book kernel from their git repo? There were some fedora kernels where the audit stuff didn't work at all.
-Will
Yes it works.
CONFIG_AUDITSYSCALL=y is the option to enable, and depends on CONFIG_AUDIT. Fixes the policy kit bug, and perhaps some other mysteriously broken things.
-Jon
On 02/28/2013 08:49 AM, Jon wrote:
On Wed, Feb 27, 2013 at 3:31 PM, William Cohen <wcohen@redhat.com mailto:wcohen@redhat.com> wrote:
On 02/27/2013 01:52 PM, Jon wrote: > > I would advise you build your own kernel. > > The upstream chromeos-3.4 contains many fixes, including the audio fix so you do not risk melting the speakers. > I would also advise you enable audit_syscall. > Enabling the PERF stuff is also a good idea. Jon, So the setting CONFIG_AUDIT=y works with the chrome book kernel from their git repo? There were some fedora kernels where the audit stuff didn't work at all. -Will
Yes it works.
CONFIG_AUDITSYSCALL=y is the option to enable, and depends on CONFIG_AUDIT. Fixes the policy kit bug, and perhaps some other mysteriously broken things.
-Jon
Hi Jon,
Thanks for the information. I will give a kernel with the CONFIG_AUDITSySCALL=y a try on Friday.
-Will
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration. I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
I was hoping to get the kernel to configure to support multiple ARM processors, but it looks like some patches will be needed to allow the ARCH_EXYNOS to be selected with ARCH_MULTI. Right now it looks like they are exclusive. The ARCH_EXYNOS also selects NEED_MACH_MEMORY_H which looks like there might be some arch specific includes as a result.
-Will
On 08/22/2013 10:58 PM, William Cohen wrote:
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration. I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
I was hoping to get the kernel to configure to support multiple ARM processors, but it looks like some patches will be needed to allow the ARCH_EXYNOS to be selected with ARCH_MULTI. Right now it looks like they are exclusive. The ARCH_EXYNOS also selects NEED_MACH_MEMORY_H which looks like there might be some arch specific includes as a result.
-Will _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I did some more digging around this weekend to figure out why enabling LPAE on the 3.11-rcNN chromebook crashed. I found that the virtualopensystms kernel had the following patch:
https://github.com/virtualopensystems/linux-kvm-arm/commit/32682304c9935dd0a...
Applying this patch to the 3.11-rcNN kernel allow building a kernel with LPAE and KVM enabled.
-Will
On Mon, Sep 2, 2013 at 5:20 PM, William Cohen wcohen@redhat.com wrote:
On 08/22/2013 10:58 PM, William Cohen wrote:
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my
Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration.
I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
I was hoping to get the kernel to configure to support multiple ARM
processors, but it looks like some patches will be needed to allow the ARCH_EXYNOS to be selected with ARCH_MULTI. Right now it looks like they are exclusive. The ARCH_EXYNOS also selects NEED_MACH_MEMORY_H which looks like there might be some arch specific includes as a result.
-Will _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I did some more digging around this weekend to figure out why enabling LPAE on the 3.11-rcNN chromebook crashed. I found that the virtualopensystms kernel had the following patch:
https://github.com/virtualopensystems/linux-kvm-arm/commit/32682304c9935dd0a...
Applying this patch to the 3.11-rcNN kernel allow building a kernel with LPAE and KVM enabled.
It seems there's a different patchset going upstream
http://www.spinics.net/lists/arm-kernel/msg265896.html
And I think this is the entire patchset here
http://www.spinics.net/lists/arm-kernel/msg263631.html
Peter
On Thu, Aug 22, 2013 at 10:58:23PM -0400, William Cohen wrote:
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration. I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
How about sound?
On 09/03/2013 09:18 AM, Darryl L. Pierce wrote:
On Thu, Aug 22, 2013 at 10:58:23PM -0400, William Cohen wrote:
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration. I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
How about sound?
Hi Daryl
This kernel is not for general use. This information is more to help developers avoid the issues that I encountered when building a mainstream kernel to try performance tools on. There are a number of things not working with this kernel configuration/build:
-usb3 -sound -wireless
Right now the nv-uboot being used doesn't really allow for an initramfs, so a number of things that should be modules are being compiled into the kernel so that the machine boots up. I am hoping that in the near future there will be a nv-uboot that is closer to what fedora expects (allows ext4 and initramfs).
-Will
Thanks for the info William. Great work, as usual. =)
Regarding the loading an initrd, that is high on my priority list to solve. It might be a problem with the kernel, or u-boot... too early to say for sure.
Might be unrelated, but I think this is similar to what we are seeing with omap4. The 3.11 kernel is happy with 'bootm kernel - fdt', but sad with 'bootm kernel initrd fdt'. Could be a coincidence.
-Jon Disnard irc: masta fas: parasense
On Tue, Sep 3, 2013 at 8:38 AM, William Cohen wcohen@redhat.com wrote:
On 09/03/2013 09:18 AM, Darryl L. Pierce wrote:
On Thu, Aug 22, 2013 at 10:58:23PM -0400, William Cohen wrote:
I have moved to running the vanilla mainline linux-3.11-rcN kernel on my Samsung Chromebook. There are some notes on the steps that I used to get it running at:
http://people.redhat.com/wcohen/chromebook/booting-3.11kernel.txt
The config file is a bit different than the fc20 kernel configuration. I started from the "make exynos_defconfig" and working towards something that is closer to the fc20 configuration. There are a couple drawbacks with this configuration. The usb3 and wireless are not working in the configuration. Also cool things like KVM virtualization are not working.
How about sound?
Hi Daryl
This kernel is not for general use. This information is more to help developers avoid the issues that I encountered when building a mainstream kernel to try performance tools on. There are a number of things not working with this kernel configuration/build:
-usb3 -sound -wireless
Right now the nv-uboot being used doesn't really allow for an initramfs, so a number of things that should be modules are being compiled into the kernel so that the machine boots up. I am hoping that in the near future there will be a nv-uboot that is closer to what fedora expects (allows ext4 and initramfs).
-Will