I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 26/07/16 22:08, Jeffrey Walton wrote:
I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
There is no ARMv8 support for the raspberry pi3 as far as I know, there are some efforts to try and get its bootloader (?) and display (?) which are 32bit only, mapped in - but most of those efforts seem to have stalled. My info might be a bit dated now, but I've not seen much change in that space since May this year.
The RaspberryPi foundation folks have publicly stated that while they wont stop community doing the engineering to get the work done to boot a 64bit distro, they are not going to support the effort themselves nor actually participate in anyway.
regards,
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On 07/26/2016 05:18 PM, Karanbir Singh wrote:
On 26/07/16 22:08, Jeffrey Walton wrote:
I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
There is no ARMv8 support for the raspberry pi3 as far as I know, there are some efforts to try and get its bootloader (?) and display (?) which are 32bit only, mapped in - but most of those efforts seem to have stalled. My info might be a bit dated now, but I've not seen much change in that space since May this year.
The RaspberryPi foundation folks have publicly stated that while they wont stop community doing the engineering to get the work done to boot a 64bit distro, they are not going to support the effort themselves nor actually participate in anyway.
It seems the community has gotten some work done to make this happen, however we won't be able to support it out of the box, because of the uefi requirement anaconda has. Our best hope of support on the rpi3 will be a disk image similar to the instructions written by Uli here -> https://github.com/umiddelb/aarch64/wiki/Install-CentOS-7-on-your-favourite-...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27/07/16 00:23, Jim Perrin wrote:
On 07/26/2016 05:18 PM, Karanbir Singh wrote:
On 26/07/16 22:08, Jeffrey Walton wrote:
I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
There is no ARMv8 support for the raspberry pi3 as far as I know, there are some efforts to try and get its bootloader (?) and display (?) which are 32bit only, mapped in - but most of those efforts seem to have stalled. My info might be a bit dated now, but I've not seen much change in that space since May this year.
The RaspberryPi foundation folks have publicly stated that while they wont stop community doing the engineering to get the work done to boot a 64bit distro, they are not going to support the effort themselves nor actually participate in anyway.
It seems the community has gotten some work done to make this happen,
Where is this work happening ? I cant seem to find any mention beyond 'the 32bit firmware cant boot a 64bit kernel, so there needs to be some magic in the kernel to switch, and noone is keen on doing that work' ( this is across many threads on the rpi site itself. Their own github issues seem to also be stalled with no real activity there.
however we won't be able to support it out of the box, because of the uefi requirement anaconda has. Our best hope of support on the rpi3 will be a disk image similar to the instructions written by Uli here ->
that should be fine, its how we ship the present rpi3 content, as a userland image that boots directly.
regards
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On 07/27/2016 06:43 AM, Karanbir Singh wrote:
On 27/07/16 00:23, Jim Perrin wrote:
On 07/26/2016 05:18 PM, Karanbir Singh wrote:
On 26/07/16 22:08, Jeffrey Walton wrote:
I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
There is no ARMv8 support for the raspberry pi3 as far as I know, there are some efforts to try and get its bootloader (?) and display (?) which are 32bit only, mapped in - but most of those efforts seem to have stalled. My info might be a bit dated now, but I've not seen much change in that space since May this year.
The RaspberryPi foundation folks have publicly stated that while they wont stop community doing the engineering to get the work done to boot a 64bit distro, they are not going to support the effort themselves nor actually participate in anyway.
It seems the community has gotten some work done to make this happen,
Where is this work happening ? I cant seem to find any mention beyond 'the 32bit firmware cant boot a 64bit kernel, so there needs to be some magic in the kernel to switch, and noone is keen on doing that work' ( this is across many threads on the rpi site itself. Their own github issues seem to also be stalled with no real activity there.
however we won't be able to support it out of the box, because of the uefi requirement anaconda has. Our best hope of support on the rpi3 will be a disk image similar to the instructions written by Uli here ->
that should be fine, its how we ship the present rpi3 content, as a userland image that boots directly.
The issue really is that the raspberry pi people do not produce a pi kernel or firmware in 64 bit at this time. They are not expected to do so officially either.
As KB said, we already use their (the pi project) kernel and firmware (rebuilt by us) and our userland. But they don't provide 64 bit versions.
On 07/27/2016 06:43 AM, Karanbir Singh wrote:
On 27/07/16 00:23, Jim Perrin wrote:
On 07/26/2016 05:18 PM, Karanbir Singh wrote:
On 26/07/16 22:08, Jeffrey Walton wrote:
I'm having trouble finding an Aarch64 image for a Raspberry Pi 3. The Raspberry Pi 3 was selected as a test device because its ARMv8.
Does Cent have any Aarch64 images for the Model 3?
There is no ARMv8 support for the raspberry pi3 as far as I know, there are some efforts to try and get its bootloader (?) and display (?) which are 32bit only, mapped in - but most of those efforts seem to have stalled. My info might be a bit dated now, but I've not seen much change in that space since May this year.
The RaspberryPi foundation folks have publicly stated that while they wont stop community doing the engineering to get the work done to boot a 64bit distro, they are not going to support the effort themselves nor actually participate in anyway.
It seems the community has gotten some work done to make this happen,
Where is this work happening ? I cant seem to find any mention beyond 'the 32bit firmware cant boot a 64bit kernel, so there needs to be some magic in the kernel to switch, and noone is keen on doing that work' ( this is across many threads on the rpi site itself. Their own github issues seem to also be stalled with no real activity there.
Some of it went into u-boot's upstream already -> http://lists.denx.de/pipermail/u-boot/2016-April/250315.html
And also kraxel has fedora arm64 images now -> https://www.kraxel.org/blog/2016/04/fedora-on-raspberry-pi-updates/
Apologies for top posting.
I've been using kraxel's AArch64 fedora 24 for a few weeks now and I really like it. Wifi just-works and it's nice and lightweight. One thing I have discovered is that the image seems to be built from the source rpm here:
https://www.kraxel.org/repos/qcom/kernel-main/kernel-main-4.6.4-1.src.rpm
(I needed source so I could build device-mapper and zfs modules).
best regards, Richard
----- Original Message ----- From: Jim Perrin jperrin@centos.org <snip>>
Where is this work happening ? I cant seem to find any mention beyond 'the 32bit firmware cant boot a 64bit kernel, so there needs to be some magic in the kernel to switch, and noone is keen on doing that work' ( this is across many threads on the rpi site itself. Their own github issues seem to also be stalled with no real activity there.
Some of it went into u-boot's upstream already -> http://lists.denx.de/pipermail/u-boot/2016-April/250315.html
And also kraxel has fedora arm64 images now -> https://www.kraxel.org/blog/2016/04/fedora-on-raspberry-pi-updates/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27/07/16 15:06, Jim Perrin wrote:
Some of it went into u-boot's upstream already -> http://lists.denx.de/pipermail/u-boot/2016-April/250315.html
cool!
And also kraxel has fedora arm64 images now -> https://www.kraxel.org/blog/2016/04/fedora-on-raspberry-pi-updates/
What
then do we need from there to get a CentOS userspace in as well ?
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On 07/27/2016 10:15 AM, Karanbir Singh wrote:
then do we need from there to get a CentOS userspace in as well ?
Unsure, but they're cheap so I ordered one this morning to play around and test. Hopefully it arrives before I start traveling next week.
Am 27.07.2016 um 17:51 schrieb Jim Perrin:
On 07/27/2016 10:15 AM, Karanbir Singh wrote:
then do we need from there to get a CentOS userspace in as well ?
Unsure, but they're cheap so I ordered one this morning to play around and test. Hopefully it arrives before I start traveling next week.
You may just pick this image here [1] and untar the CentOS userland [2] on top of it (3rd partition). If this boots up you may produce a 'clean' setup by removing everything except '/lib/modules' before untarring the CentOS userland once again.
[1] https://www.kraxel.org/repos/rpi2/images/arm64-rpi3-f24-mainline-20160623.ra... [2] https://www.dropbox.com/s/nt7m6qcv88va3xt/CentOS7-rootfs-aarch64.tar.xz?dl=0
Cheers Uli
On 07/27/2016 03:44 PM, Uli Middelberg wrote:
Am 27.07.2016 um 17:51 schrieb Jim Perrin:
On 07/27/2016 10:15 AM, Karanbir Singh wrote:
then do we need from there to get a CentOS userspace in as well ?
Unsure, but they're cheap so I ordered one this morning to play around and test. Hopefully it arrives before I start traveling next week.
You may just pick this image here [1] and untar the CentOS userland [2] on top of it (3rd partition). If this boots up you may produce a 'clean' setup by removing everything except '/lib/modules' before untarring the CentOS userland once again.
[1] https://www.kraxel.org/repos/rpi2/images/arm64-rpi3-f24-mainline-20160623.ra...
[2] https://www.dropbox.com/s/nt7m6qcv88va3xt/CentOS7-rootfs-aarch64.tar.xz?dl=0
I probably should have mentioned this to you sooner, but as of this pasth monthly build, we're pushing a rootfs tarball ( http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-rootfs-1606... ) as well. It includes the distro kernel, and a few other bits as well. Happy to work with you on fine-tuning this if you want.
Am 27.07.2016 um 23:14 schrieb Jim Perrin:
I probably should have mentioned this to you sooner, but as of this pasth monthly build, we're pushing a rootfs tarball ( http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-rootfs-1606... ) as well. It includes the distro kernel, and a few other bits as well. Happy to work with you on fine-tuning this if you want.
Sorry for the long delay ...
I've updated the wiki page [1] and the creation scripts [2] now in order to reflect this change. So far, I haven't found anything which needed to be changed. Do you think you would be able to provide a corresponding rootfs for armhfp with reasonable effort as well?
IMHO the distro kernel doesn't necessarily need to be included, may be adding the kernel config file would make sense (I still appreciate the idea of having is list of mandatory / optional kernel options in order to provide a best match legacy kernel for CentOS.)
Unfortunately I cannot use the board vendor supplied kernel package directly, so I still have to compile it from source and put it aside (e.g. to my dropbox account). If you have an automated Aarch64 build chain, you may consider to integrate the legacy kernel compilation as well (at least for Aarch64).
[1] https://github.com/umiddelb/aarch64/wiki/Install-CentOS-7-on-your-favourite-... [2] https://github.com/umiddelb/z2d/tree/master/odroid-c2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/09/16 17:15, Uli Middelberg wrote:
Unfortunately I cannot use the board vendor supplied kernel package directly,
why is that ?
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
Am 09.09.2016 um 18:31 schrieb Karanbir Singh:
On 09/09/16 17:15, Uli Middelberg wrote:
Unfortunately I cannot use the board vendor supplied kernel package directly,
why is that ?
I need to automate the following steps:
- download the Debian meta package 'linux-image-c2' which equals to wget http://deb.odroid.in/c2/pool/main/l/linux-image-c2/linux-image-c2_81-1_arm64...
- extract the dependency, at this time 'linux-image-3.14.77-81'
- fetch this package, e.g. wget http://deb.odroid.in/c2/pool/main/l/linux-source-3.14.77-81/linux-image-3.14...
- and extract the 'data.tar.xz' ar x linux-image-3.14.77-81_20160908_arm64.deb
the same applies to the kernel header files and the bootini package (which isn't marked as dependency, although there is a heavy correlation between the kernel image and the boot procedure, meaning the kernel might crash if boot.ini isn't up do date).
Of course I can ask Mauro (https://github.com/mdrjr) if he would be able to provide official rpm packages as well.
On Wed, Jul 27, 2016 at 11:51 AM, Jim Perrin jperrin@centos.org wrote:
On 07/27/2016 10:15 AM, Karanbir Singh wrote:
then do we need from there to get a CentOS userspace in as well ?
Unsure, but they're cheap so I ordered one this morning to play around and test. Hopefully it arrives before I start traveling next week.
Raspberry Pi provides an ARMv7 HF image, but the processor can consume ARMv8. GCC cannot create ARMv8 programs for it because its configured as armhf.
This program below compiles and executes successfully. It does not generate an "illegal instruction" like I thought would happen.
$ cat test.cc #include <arm_neon.h> int main(int argc, char* argv[]) { __asm__ __volatile__ ( ".code 32"
// CRC using word ".byte 0x1a, 0xc1, 0x58, 0x00;\n" // CRC using half word ".byte 0x1a, 0xc1, 0x54, 0x00;\n" // CRC using byte ".byte 0x1a, 0xc1, 0x50, 0x00;\n" // PMULL ".byte 0x0e, 0xe1, 0xe0, 0x00;\n" // PMULL2 ".byte 0x4e, 0xe1, 0xe0, 0x00;\n" // AES (aese) ".byte 0x4e, 0x28, 0x48, 0x20;\n" // AES (aesd) ".byte 0x4e, 0x28, 0x58, 0x20;\n" // SHA1 (sha1c) ".byte 0x5e, 0x02, 0x00, 0x20;\n" // SHA1 (sha1m) ".byte 0x5e, 0x02, 0x20, 0x20;\n" // SHA1 (sha1p) ".byte 0x5e, 0x02, 0x30, 0x20;\n" : : : "cc", "d0", "d1", "d2", "q0", "q1", "q2" );
return 0; }
$ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe $ ./test.exe $
Related, checkout this odd-ness:
$ gcc -g3 -O0 -march=armv8-a+crc test.cc -o test.exe < lots of error, requires NEON >
$ gcc -g3 -O0 -march=armv8-a+crc -mfpu=neon test.cc -o test.exe $
So, we can actually enable CRC extensions by using armv8-a+crc. But we can't enable other extensions:
$ gcc -g3 -O0 -march=armv8-a+crc+crypto -mfpu=neon test.cc -o test.exe gcc: error: unrecognized argument in option ‘-march=armv8-a+crc+crypto’
I'm trying to get some feedback on ARM options from the GCC folks at http://gcc.gnu.org/ml/gcc-help/2016-07/msg00067.html.
Jeff
This program below compiles and executes successfully. It does not generate an "illegal instruction" like I thought would happen.
$ cat test.cc #include <arm_neon.h> int main(int argc, char* argv[]) { __asm__ __volatile__ ( ".code 32"
// CRC using word ".byte 0x1a, 0xc1, 0x58, 0x00;\n" // CRC using half word ".byte 0x1a, 0xc1, 0x54, 0x00;\n" // CRC using byte ".byte 0x1a, 0xc1, 0x50, 0x00;\n" // PMULL ".byte 0x0e, 0xe1, 0xe0, 0x00;\n" // PMULL2 ".byte 0x4e, 0xe1, 0xe0, 0x00;\n" // AES (aese) ".byte 0x4e, 0x28, 0x48, 0x20;\n" // AES (aesd) ".byte 0x4e, 0x28, 0x58, 0x20;\n" // SHA1 (sha1c) ".byte 0x5e, 0x02, 0x00, 0x20;\n" // SHA1 (sha1m) ".byte 0x5e, 0x02, 0x20, 0x20;\n" // SHA1 (sha1p) ".byte 0x5e, 0x02, 0x30, 0x20;\n" : : : "cc", "d0", "d1", "d2", "q0", "q1", "q2" );return 0; }
$ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe $ ./test.exe $
All that silliness was not needed. All that was needed was:
gcc -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 ...
I can't believe I could not piece that together from the man pages.... (Thanks to the GCC and SO folks).
Jeff
-
Jeffrey Walton -
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Richard Henwood -
Uli Middelberg