[Buildroot] out of tree kernel patches question

[Buildroot] out of tree kernel patches question

[daggs]

Greetings,

when it comes to the odroidc2 support, there are 3 things that I'm concerned about:
1. gcc is limited to 4.9.x
2. old uboot (2005.11).
3. very old kernel (3.14.79).

#1 is needed because #2, currently upstream uboot support this board from 2007.05 but I've tried for months to get upstream uboot to work with the vendor's kernel without any luck.
unfortunately, the uboot mailing list isn't helpful at all (no one seems to care much),
this means that in order to solve issue #2, the kernel needs to be upgraded.
latest upstream kernel holds bask support for this board, the development is progressing. now assuming that I take patches existing in the kernel mailing list that adds missing support for features in the kernel to a point that the board can be used in a decent manner, what is the policy of adding out of the kernel patches to a board in buildroot?

Thanks,

Dagg.

[Buildroot] out of tree kernel patches question

[Thomas Petazzoni]

Hello,

On Fri, 17 Nov 2017 14:16:17 +0100, daggs wrote:

> when it comes to the odroidc2 support, there are 3 things that I'm concerned about:
> 1. gcc is limited to 4.9.x
> 2. old uboot (2005.11).
> 3. very old kernel (3.14.79).
> 
> #1 is needed because #2, currently upstream uboot support this board
> from 2007.05 but I've tried for months to get upstream uboot to work
> with the vendor's kernel without any luck. unfortunately, the uboot
> mailing list isn't helpful at all (no one seems to care much), this
> means that in order to solve issue #2, the kernel needs to be
> upgraded.

> latest upstream kernel holds bask support for this board, the
> development is progressing. now assuming that I take patches existing
> in the kernel mailing list that adds missing support for features in
> the kernel to a point that the board can be used in a decent manner,
> what is the policy of adding out of the kernel patches to a board in
> buildroot?

We are generally OK to integrate kernel patches if they are merged
upstream already, or seriously on their way upstream. Also, we can do
this only if the stack of patches is not several hundreds of patches.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] out of tree kernel patches question

[daggs]

Greetings Thomas,

> Sent: Friday, November 17, 2017 at 10:24 PM
> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: daggs <daggs@gmx.com>
> Cc: buildroot at buildroot.org
> Subject: Re: [Buildroot] out of tree kernel patches question
>
> Hello,
> 
> On Fri, 17 Nov 2017 14:16:17 +0100, daggs wrote:
> 
> > when it comes to the odroidc2 support, there are 3 things that I'm concerned about:
> > 1. gcc is limited to 4.9.x
> > 2. old uboot (2005.11).
> > 3. very old kernel (3.14.79).
> > 
> > #1 is needed because #2, currently upstream uboot support this board
> > from 2007.05 but I've tried for months to get upstream uboot to work
> > with the vendor's kernel without any luck. unfortunately, the uboot
> > mailing list isn't helpful at all (no one seems to care much), this
> > means that in order to solve issue #2, the kernel needs to be
> > upgraded.
> 
> > latest upstream kernel holds bask support for this board, the
> > development is progressing. now assuming that I take patches existing
> > in the kernel mailing list that adds missing support for features in
> > the kernel to a point that the board can be used in a decent manner,
> > what is the policy of adding out of the kernel patches to a board in
> > buildroot?
> 
> We are generally OK to integrate kernel patches if they are merged
> upstream already, or seriously on their way upstream. Also, we can do
> this only if the stack of patches is not several hundreds of patches.
> 
> Best regards,
> 
> Thomas

my main objective is to ditch the annoying gcc 4.9.x dependency, as said, most of the patches where submitted into the kernel's mailing list for review so I guess they can be refered as "seriously on their way upstream".

I've looked into the patches, there is one thing missing that is needed for some use case, there is no hw acceleration. the board supports 4k decoding (only via vendor's own player or kodi), the board doesn't have desktop effects acceleration as far as I know. beside that, I think that even the most latest stable kernel version + a handful of patches, this can work.
so I'd like to propose adding a new buildroot config named odroidc2-next which will support that along side the existing one.
with time, hopefully, the old one will be replaced by the new one.

any objections?

Dagg.

[Buildroot] out of tree kernel patches question

[Peter Korsgaard]

>>>>> "daggs" == daggs  <daggs@gmx.com> writes:

Hi,

 > so I'd like to propose adding a new buildroot config named
 > odroidc2-next which will support that along side the existing one.
 > with time, hopefully, the old one will be replaced by the new one.

 > any objections?

I don't think "next" really explains what this is about, what about
odroidc2_mainline_defconfig?

We have a number of other boards where it may be interesting to do so,
E.G. rpi, roseapplepi, ..

-- 
Bye, Peter Korsgaard

[Buildroot] out of tree kernel patches question

[daggs]

Greeting Peter,

>
> >>>>> "daggs" == daggs  <daggs@gmx.com> writes:
> 
> Hi,
> 
>  > so I'd like to propose adding a new buildroot config named
>  > odroidc2-next which will support that along side the existing one.
>  > with time, hopefully, the old one will be replaced by the new one.
> 
>  > any objections?
> 
> I don't think "next" really explains what this is about, what about
> odroidc2_mainline_defconfig?
> 
> We have a number of other boards where it may be interesting to do so,
> E.G. rpi, roseapplepi, ..
> 
> -- 
> Bye, Peter Korsgaard
> 

sounds great, I'll wait for Thomas's input on this and will advance from there.

Dagg.

[Buildroot] out of tree kernel patches question

[daggs]

Thomas,

> Sent: Saturday, November 18, 2017 at 2:10 PM
> From: daggs <daggs@gmx.com>
> To: "Peter Korsgaard" <peter@korsgaard.com>
> Cc: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, buildroot at buildroot.org
> Subject: Re: [Buildroot] out of tree kernel patches question
>
> Greeting Peter,
> 
> >
> > >>>>> "daggs" == daggs  <daggs@gmx.com> writes:
> > 
> > Hi,
> > 
> >  > so I'd like to propose adding a new buildroot config named
> >  > odroidc2-next which will support that along side the existing one.
> >  > with time, hopefully, the old one will be replaced by the new one.
> > 
> >  > any objections?
> > 
> > I don't think "next" really explains what this is about, what about
> > odroidc2_mainline_defconfig?
> > 
> > We have a number of other boards where it may be interesting to do so,
> > E.G. rpi, roseapplepi, ..
> > 
> > -- 
> > Bye, Peter Korsgaard
> > 
> 
> sounds great, I'll wait for Thomas's input on this and will advance from there.
> 
> Dagg.

any objections to this?

[Buildroot] out of tree kernel patches question

[Thomas Petazzoni]

Hello,

On Mon, 20 Nov 2017 21:34:17 +0100, daggs wrote:

> > >  > so I'd like to propose adding a new buildroot config named
> > >  > odroidc2-next which will support that along side the existing one.
> > >  > with time, hopefully, the old one will be replaced by the new one.  
> > >   
> > >  > any objections?  
> > > 
> > > I don't think "next" really explains what this is about, what about
> > > odroidc2_mainline_defconfig?
> > > 
> > > We have a number of other boards where it may be interesting to do so,
> > > E.G. rpi, roseapplepi, ..
> > > 
> > > -- 
> > > Bye, Peter Korsgaard
> > >   
> > 
> > sounds great, I'll wait for Thomas's input on this and will advance from there.
> > 
> > Dagg.  
> 
> any objections to this?

None at all. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] out of tree kernel patches question

[Peter Korsgaard]

>>>>> "daggs" == daggs  <daggs@gmx.com> writes:

 > Greetings,
 > when it comes to the odroidc2 support, there are 3 things that I'm concerned about:
 > 1. gcc is limited to 4.9.x
 > 2. old uboot (2005.11).
 > 3. very old kernel (3.14.79).

 > #1 is needed because #2, currently upstream uboot support this board
 > from 2007.05 but I've tried for months to get upstream uboot to work
 > with the vendor's kernel without any luck.
 > unfortunately, the uboot mailing list isn't helpful at all (no one seems to care much),
 > this means that in order to solve issue #2, the kernel needs to be upgraded.
 > latest upstream kernel holds bask support for this board, the
 > development is progressing. now assuming that I take patches existing
 > in the kernel mailing list that adds missing support for features in
 > the kernel to a point that the board can be used in a decent manner,
 > what is the policy of adding out of the kernel patches to a board in
 > buildroot?

Maybe it makes more sense to do it the other way around? First move to
the mainline kernel and once that is done move to mainline u-boot as
well. I've used 4.13 with the vendor u-boot without problems.

The only issue I am aware of for moving to mainline u-boot was an issue
with HDMI output, as the driver assumed certain things were initialized
in the bootloader, which was true for the vendor one but not mainline -
But that is getting fixed:

https://lkml.org/lkml/2017/10/17/134

As for carrying patches in Buildroot - That is OK for me as long as they
are not huge and the patches are only temporary (E.G. patches have
already been submitted upstream and hopefully acked, but they just
haven't been merged yet).

-- 
Bye, Peter Korsgaard

[Buildroot] out of tree kernel patches question

[daggs]

Greetings Peter,

> 
>  > Greetings,
>  > when it comes to the odroidc2 support, there are 3 things that I'm concerned about:
>  > 1. gcc is limited to 4.9.x
>  > 2. old uboot (2005.11).
>  > 3. very old kernel (3.14.79).
> 
>  > #1 is needed because #2, currently upstream uboot support this board
>  > from 2007.05 but I've tried for months to get upstream uboot to work
>  > with the vendor's kernel without any luck.
>  > unfortunately, the uboot mailing list isn't helpful at all (no one seems to care much),
>  > this means that in order to solve issue #2, the kernel needs to be upgraded.
>  > latest upstream kernel holds bask support for this board, the
>  > development is progressing. now assuming that I take patches existing
>  > in the kernel mailing list that adds missing support for features in
>  > the kernel to a point that the board can be used in a decent manner,
>  > what is the policy of adding out of the kernel patches to a board in
>  > buildroot?
> 
> Maybe it makes more sense to do it the other way around? First move to
> the mainline kernel and once that is done move to mainline u-boot as
> well. I've used 4.13 with the vendor u-boot without problems.
> 
> The only issue I am aware of for moving to mainline u-boot was an issue
> with HDMI output, as the driver assumed certain things were initialized
> in the bootloader, which was true for the vendor one but not mainline -
> But that is getting fixed:
> 
> https://lkml.org/lkml/2017/10/17/134
> 
> As for carrying patches in Buildroot - That is OK for me as long as they
> are not huge and the patches are only temporary (E.G. patches have
> already been submitted upstream and hopefully acked, but they just
> haven't been merged yet).
> 

as I wrote to Thomas, the main reason for this question is to remove the gcc 4.9.x constraint.
without upgrading uboot, that cannot be dropped.
I was working on upgrading the uboot while keeping the vendor's kernel but the board won't boot.
afaics, uboot works, the issue is that the kernel doesn't gets loaded at all.

Dagg.

[Buildroot] out of tree kernel patches question

[Peter Korsgaard]

>>>>> "daggs" == daggs  <daggs@gmx.com> writes:

Hi,

 >> Maybe it makes more sense to do it the other way around? First move to
 >> the mainline kernel and once that is done move to mainline u-boot as
 >> well. I've used 4.13 with the vendor u-boot without problems.
 >> 
 >> The only issue I am aware of for moving to mainline u-boot was an issue
 >> with HDMI output, as the driver assumed certain things were initialized
 >> in the bootloader, which was true for the vendor one but not mainline -
 >> But that is getting fixed:
 >> 
 >> https://lkml.org/lkml/2017/10/17/134
 >> 
 >> As for carrying patches in Buildroot - That is OK for me as long as they
 >> are not huge and the patches are only temporary (E.G. patches have
 >> already been submitted upstream and hopefully acked, but they just
 >> haven't been merged yet).
 >> 

 > as I wrote to Thomas, the main reason for this question is to remove
 > the gcc 4.9.x constraint.  without upgrading uboot, that cannot be
 > dropped.  I was working on upgrading the uboot while keeping the
 > vendor's kernel but the board won't boot.  afaics, uboot works, the
 > issue is that the kernel doesn't gets loaded at all.

I get that, but preferably we want to use mainline u-boot AND kernel,
and if the combination of mainline-uboot + vendor-kernel doesn't work
then it makes more sense to do it the other way around.

-- 
Bye, Peter Korsgaard