On Mon, Jan 8, 2018 at 11:35 AM, Johnny Hughes johnny@centos.org wrote:
On 01/04/2018 04:30 PM, Gordan Bobic wrote:
Things required to "support" Pi3 aarch64 that aren't already in place in core CentOS (or at least I haven't managed to find them):
- Pi3 firmware blobs
Trivially downloadable from https://github.com/raspberrypi/firmware/tree/master/boot
I assume we include those in our armhfp kernel so this is not a problem for an official CentOS image.
- UEFI bootloader
There are two options, u-boot and Tianocore. My current Pi3 aarch64 image works with u-boot that I grabbed from the Fedora 26 image. I'm currently trying to get it working with Tianocore from here: https://github.com/andreiw/RaspberryPiPkg I _almost_ have it working (gets as far as booting grub, but grub then doesn't manage to boot up the kernel, almost certainly a dtb issue somewhere).
We kind of need to be able to BUILD this, not just take it from something else an use it. At least that is certainly preferable. I suppose we can just include it as a SOURCE for the SRPM, but that is not ideal.
Yes, I built it from source, so that part won't be a problem.
- Kernel
I keep my own mainline kernel build for aarch64, loosely based on, IIRC, 4.5.x that shipped with CentOS aarch64, but with some modifications. I have a build that works on both my X-Gene and the Pi3. You can find it
here:
http://ftp.redsleeve.org/pub/misc/kernel/aarch64/RPMS/ (Note: I only included Pi 3 SoC configuration as of 4.9.73).
So it's not exactly an insurmountable problem, it's just a case off dropping a tarball of 5-6 files onto the /boot/efi FAT partition, having the appropriate kernel installed in the image, and it should "just work". I can have a working image with u-boot EFI as soon as I find half an hour to spare. The one with Tianocore EFI will take a little longer.
Is there something about OUR generic CentOS 4.9.x kernel SRPM that does not work if compiled on aarch64:
http://vault.centos.org/altarch/7.4.1708/experimental/Source /i386/Source/SPackages/
That SRPM is what we use for i386/x86_64 and the generic armhfp kernel. If we need a new config file, we can likely figure that out.
We would obviously need to add in whatever is necessary for the firmware blobs and the pi uboot config, etc.
You will need to build it for aarch64 and add the support for the relevant SoCs and the hardware required to boot on them. 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).
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. 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.
I am not opposed to doing this if we can do it right .. which is that it is secure and reproducible to build and install via the RPMs (the kernel), which are produced completely produce automatically from the SRPM ..
My kernels are build from SRPMs containing a plain upstream LT kernel with no extra patches. 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.
AND for the image, it is completely buildable via a kickstart file or one of the normal tools and everything does not have to be hand added, etc. If we can make that happen, then I am happy for us to have an aarch64 build.
Yes, all of that is doable.
But, it is odd that the RPI foundation doesn't care enough to make that happen.
OK, I just lost you there - what part of the above would you consider to be in their remit to do?
We might get some ideas from the SRPMS these guys do:
https://www.linux.com/news/learn/intro-to-linux/first-64-bit -and-enterprise-os-comes-raspberry-pi-3
I don't really see where the difficulty in any of this is. My intention has always been for the final image to contain nothing in it that wasn't installed from an RPM - and as soon as I have Tianocore working properly, I will produce it. If there is interest in the u-boot UEFI based image, I believe that can already be done (depending on whether any minor changes are required to the u-boot SRPMs from F26).
Gordan
On 01/08/2018 06:06 AM, Gordan Bobic wrote:
On Mon, Jan 8, 2018 at 11:35 AM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 01/04/2018 04:30 PM, Gordan Bobic wrote: > Things required to "support" Pi3 aarch64 that aren't already in place in > core CentOS (or at least I haven't managed to find them): > > 1) Pi3 firmware blobs > Trivially downloadable from > https://github.com/raspberrypi/firmware/tree/master/boot <https://github.com/raspberrypi/firmware/tree/master/boot> I assume we include those in our armhfp kernel so this is not a problem for an official CentOS image. > > 2) UEFI bootloader > There are two options, u-boot and Tianocore. > My current Pi3 aarch64 image works with u-boot that I grabbed from the > Fedora 26 image. > I'm currently trying to get it working with Tianocore from here: > https://github.com/andreiw/RaspberryPiPkg <https://github.com/andreiw/RaspberryPiPkg> > I _almost_ have it working (gets as far as booting grub, but grub then > doesn't manage to boot up the kernel, almost certainly a dtb issue > somewhere). We kind of need to be able to BUILD this, not just take it from something else an use it. At least that is certainly preferable. I suppose we can just include it as a SOURCE for the SRPM, but that is not ideal.Yes, I built it from source, so that part won't be a problem.
Cool, sounds good
> > 3) Kernel > I keep my own mainline kernel build for aarch64, loosely based on, IIRC, > 4.5.x that shipped with CentOS aarch64, but with some modifications. I > have a build that works on both my X-Gene and the Pi3. You can find it here: > http://ftp.redsleeve.org/pub/misc/kernel/aarch64/RPMS/ <http://ftp.redsleeve.org/pub/misc/kernel/aarch64/RPMS/> > (Note: I only included Pi 3 SoC configuration as of 4.9.73). > > So it's not exactly an insurmountable problem, it's just a case off > dropping a tarball of 5-6 files onto the /boot/efi FAT partition, having > the appropriate kernel installed in the image, and it should "just work". > I can have a working image with u-boot EFI as soon as I find half an > hour to spare. > The one with Tianocore EFI will take a little longer. > Is there something about OUR generic CentOS 4.9.x kernel SRPM that does not work if compiled on aarch64: http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPackages/ <http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPackages/> That SRPM is what we use for i386/x86_64 and the generic armhfp kernel. If we need a new config file, we can likely figure that out. We would obviously need to add in whatever is necessary for the firmware blobs and the pi uboot config, etc.You will need to build it for aarch64 and add the support for the relevant SoCs and the hardware required to boot on them. 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).
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. 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.
I am not opposed to doing this if we can do it right .. which is that it is secure and reproducible to build and install via the RPMs (the kernel), which are produced completely produce automatically from the SRPM ..My kernels are build from SRPMs containing a plain upstream LT kernel with no extra patches. 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.
The only patches we have were from the Fedora 4.9.x kernel and we also follow the 4.9 LTS upstream kernel. If you could use this SRPM, it would make it easier to roll into CentOS later (if that is your intention):
http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPa...
AND for the image, it is completely buildable via a kickstart file or one of the normal tools and everything does not have to be hand added, etc. If we can make that happen, then I am happy for us to have an aarch64 build.Yes, all of that is doable.
But, it is odd that the RPI foundation doesn't care enough to make that happen.OK, I just lost you there - what part of the above would you consider to be in their remit to do?
They provide the default kernel sources for the rpi3 .. one would think they would provide 64 bit software for it. I have no issue with us doing it, obviously.
<snip>
On Mon, Jan 8, 2018 at 12:56 PM, Johnny Hughes johnny@centos.org wrote:
On 01/08/2018 06:06 AM, Gordan Bobic wrote:
On Mon, Jan 8, 2018 at 11:35 AM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 01/04/2018 04:30 PM, Gordan Bobic wrote:My kernels are build from SRPMs containing a plain upstream LT kernel with no extra patches. 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.
The only patches we have were from the Fedora 4.9.x kernel and we also follow the 4.9 LTS upstream kernel. If you could use this SRPM, it would make it easier to roll into CentOS later (if that is your intention):
http://vault.centos.org/altarch/7.4.1708/experimental/ Source/i386/Source/SPackages/
I can probably do that and destill it down to a difference in the kernel build config file. 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).
AND for the image, it is completely buildable via a kickstart file or one of the normal tools and everything does not have to behand
added, etc. If we can make that happen, then I am happy for us tohave
an aarch64 build.Yes, all of that is doable.
But, it is odd that the RPI foundation doesn't care enough to makethat
happen.OK, I just lost you there - what part of the above would you consider to be in their remit to do?
They provide the default kernel sources for the rpi3 .. one would think they would provide 64 bit software for it. I have no issue with us doing it, obviously.
AFAICT everything is in 4.9 mainline kernel, so I don't really see what else they could possibly do.
-
Gordan Bobic -
Johnny Hughes