<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 8, 2018 at 11:35 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/04/2018 04:30 PM, Gordan Bobic wrote:<br>
> Things required to "support" Pi3 aarch64 that aren't already in place in<br>
> core CentOS (or at least I haven't managed to find them):<br>
><br>
> 1) Pi3 firmware blobs<br>
> Trivially downloadable from<br>
> <a href="https://github.com/raspberrypi/firmware/tree/master/boot" rel="noreferrer" target="_blank">https://github.com/raspberrypi<wbr>/firmware/tree/master/boot</a><br>
<br>
I assume we include those in our armhfp kernel so this is not a problem<br>
for an official CentOS image.<br>
<br>
><br>
> 2) UEFI bootloader<br>
> There are two options, u-boot and Tianocore.<br>
> My current Pi3 aarch64 image works with u-boot that I grabbed from the<br>
> Fedora 26 image. <br>
> I'm currently trying to get it working with Tianocore from here:<br>
> <a href="https://github.com/andreiw/RaspberryPiPkg" rel="noreferrer" target="_blank">https://github.com/andreiw/Ras<wbr>pberryPiPkg</a><br>
> I _almost_ have it working (gets as far as booting grub, but grub then<br>
> doesn't manage to boot up the kernel, almost certainly a dtb issue<br>
> somewhere).<br>
<br>
We kind of need to be able to BUILD this, not just take it from<br>
something else an use it.  At least that is certainly preferable. I<br>
suppose we can just include it as a SOURCE for the SRPM, but that is not<br>
ideal.<br></blockquote><div><br></div><div>Yes, I built it from source, so that part won't be a problem.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 3) Kernel<br>
> I keep my own mainline kernel build for aarch64, loosely based on, IIRC,<br>
> 4.5.x that shipped with CentOS aarch64, but with some modifications. I<br>
> have a build that works on both my X-Gene and the Pi3. You can find it here:<br>
> <a href="http://ftp.redsleeve.org/pub/misc/kernel/aarch64/RPMS/" rel="noreferrer" target="_blank">http://ftp.redsleeve.org/pub/m<wbr>isc/kernel/aarch64/RPMS/</a><br>
> (Note: I only included Pi 3 SoC configuration as of 4.9.73).<br>
><br>
> So it's not exactly an insurmountable problem, it's just a case off<br>
> dropping a tarball of 5-6 files onto the /boot/efi FAT partition, having<br>
> the appropriate kernel installed in the image, and it should "just work".<br>
> I can have a working image with u-boot EFI as soon as I find half an<br>
> hour to spare.<br>
> The one with Tianocore EFI will take a little longer.<br>
><br>
<br>
Is there something about OUR generic CentOS 4.9.x kernel SRPM that does<br>
not work if compiled on aarch64:<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/altarc<wbr>h/7.4.1708/experimental/Source<wbr>/i386/Source/SPackages/</a><br>
<br>
That SRPM is what we use for i386/x86_64 and the generic armhfp kernel.<br>
If we need a new config file, we can likely figure that out.<br>
<br>
We would obviously need to add in whatever is necessary for the firmware<br>
blobs and the pi uboot config, etc.<br></blockquote><div><br></div><div><br></div><div>You will need to build it for aarch64 and add the support for the relevant SoCs and the hardware required to boot on them.</div><div>Other than that, no, there is no reason unless some of the added patches break something outside of the config being used (something that is not 0-risk in my experience).</div><div><br></div><div>Other than that the reason I build my own is because when it comes to kernels I am much more comfortable sticking to the LT mainline than a distro modified kernel.</div><div>I am happy to go into details of why this has been the case for a long time, but that really is something for another thread, and possibly better not a public one.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am not opposed to doing this if we can do it right .. which is that it<br>
is secure and reproducible to build and install via the RPMs (the<br>
kernel), which are produced completely produce automatically from the<br>
SRPM .. </blockquote><div><br></div><div>My kernels are build from SRPMs containing a plain upstream LT kernel with no extra patches.</div><div>So the method is sound. The only thing I can think of that could potentially break it is if a patch in the CentOS kernel breaks something for SoCs that aren't included in the existing kernel config.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>Yes, all of that is doable.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But, it is odd that the RPI foundation doesn't care enough to make that<br>
happen.<br></blockquote><div><br></div><div>OK, I just lost you there - what part of the above would you consider to be in their remit to do?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We might get some ideas from the SRPMS these guys do:<br>
<br>
<a href="https://www.linux.com/news/learn/intro-to-linux/first-64-bit-and-enterprise-os-comes-raspberry-pi-3" rel="noreferrer" target="_blank">https://www.linux.com/news/lea<wbr>rn/intro-to-linux/first-64-bit<wbr>-and-enterprise-os-comes-raspb<wbr>erry-pi-3</a><br></blockquote><div><br></div><div><br></div><div>I don't really see where the difficulty in any of this is. My intention has always been for the </div><div>final image to contain nothing in it that wasn't installed from an RPM - and as soon as I </div><div>have Tianocore working properly, I will produce it. If there is interest in the u-boot UEFI </div><div>based image, I believe that can already be done (depending on whether any minor changes </div><div>are required to the u-boot SRPMs from F26).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gordan</div></font></span></div></div></div>
</div><br></div>