<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 12:56 PM, Johnny Hughes <span dir="ltr"><<a href="mailto:johnny@centos.org" target="_blank">johnny@centos.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 01/08/2018 06:06 AM, Gordan Bobic wrote:<br>
> On Mon, Jan 8, 2018 at 11:35 AM, Johnny Hughes <<a href="mailto:johnny@centos.org">johnny@centos.org</a><br>
> <mailto:<a href="mailto:johnny@centos.org">johnny@centos.org</a>>> wrote:<br>
><br>
>     On 01/04/2018 04:30 PM, Gordan Bobic wrote:<br>> My kernels are build from SRPMs containing a plain upstream LT kernel<br>
> with no extra patches.<br>
> So the method is sound. The only thing I can think of that could<br>
> potentially break it is if a patch in the CentOS kernel breaks something<br>
> for SoCs that aren't included in the existing kernel config.<br>
><br>
><br>
<br>
The only patches we have were from the Fedora 4.9.x kernel and we also<br>
follow the 4.9 LTS upstream kernel.  If you could use this SRPM, it<br>
would make it easier to roll into CentOS later (if that is your intention):<br>
<br>
<a href="http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPackages/" rel="noreferrer" target="_blank">http://vault.centos.org/<wbr>altarch/7.4.1708/experimental/<wbr>Source/i386/Source/SPackages/</a><br><br></blockquote><div><br></div><div>I can probably do that and destill it down to a difference in the kernel build config file.</div><div>All I am saying is that the vanilla unpatched kernel works. Whether any distro patches will break with the required changes to the config - that remains to be seen (it wouldn't be the first time).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
>     AND for the image, it is completely buildable via a kickstart<br>
>     file or one of the normal tools and everything does not have to be hand<br>
>     added, etc.  If we can make that happen, then I am happy for us to have<br>
>     an aarch64 build.<br>
><br>
><br>
> Yes, all of that is doable.<br>
><br>
>  <br>
><br>
><br>
>     But, it is odd that the RPI foundation doesn't care enough to make that<br>
>     happen.<br>
><br>
><br>
> OK, I just lost you there - what part of the above would you consider to<br>
> be in their remit to do?<br>
><br>
>  <br>
<br>
They provide the default kernel sources for the rpi3 .. one would think<br>
they would provide 64 bit software for it.  I have no issue with us<br>
doing it, obviously.<br></blockquote><div><br></div><div><br></div><div>AFAICT everything is in 4.9 mainline kernel, so I don't really see what else they could possibly do.</div><div><br></div><div><br></div></div></div></div>