Hi,
I recently made a request to community buildsys arm32 so that I can understand the build process and then try and do a do a build for an olimex olinuxino A20 board.
In addition, I've just received a Pine64 board and wouldn't mind trying to do a build for that too. Do I need to resubmit the request for buildsys - arm64 with the same keys?
Cheers Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/01/16 13:23, Nick Betteridge wrote:
Hi,
I recently made a request to community buildsys arm32 so that I can understand the build process and then try and do a do a build for an olimex olinuxino A20 board.
In addition, I've just received a Pine64 board and wouldn't mind trying to do a build for that too. Do I need to resubmit the request for buildsys - arm64 with the same keys?
Cheers Nick
Hi Nick,
The community buildsys arm32 (plague build-farm) is just composed of plague/mock builders. If you're interested in testing/supporting a specific board, the first thing to do would be to see if the board requires : - - specific firmware - - specific kernel - - specific uboot
If current uboot has support (image) for that board (http://mirror.centos.org/altarch/7/extras/armhfp/Packages/uboot-images-armv7...), then it's just a matter of using rbf (and so not on the plague build-farm) to test an image. Obviously I can do that , if being pointed to the uboot image to include for that image.
Also worth noting that my plan would be to reconfigure from scratch the current plague setup, as it currently runs on Fedora 21, so a need to migrate it to CentOS 7 userland, now that it exists. At the same time, I'd like to tie it with the newer auth backend (https://accounts.centos.org) instead of the (locally) generated certs.
For arm64, there is no community buildsys available
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/01/16 12:31, Fabian Arrotin wrote:
For arm64, there is no community buildsys available
Since we have an installer and images for Aarch64, the best thing to do there would be to trial that on the pine64 board, and take it from there. The 4.2 kernel should work, I dont know about the bootloader process, but with some luck its going to uefi by default (not asking for much are we ? )
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 06/01/16 12:34, Karanbir Singh wrote:
On 06/01/16 12:31, Fabian Arrotin wrote:
For arm64, there is no community buildsys available
Since we have an installer and images for Aarch64, the best thing to do there would be to trial that on the pine64 board, and take it from there. The 4.2 kernel should work, I dont know about the bootloader process, but with some luck its going to uefi by default (not asking for much are we ? )
Regards,
Thanks for this - I'll try and find some time this week to look at this more closely. I have the allwinner A64 sdk and have yet to go through the Pine64 github repo.
Cheers Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/01/16 13:31, Fabian Arrotin wrote:
On 06/01/16 13:23, Nick Betteridge wrote:
Hi,
I recently made a request to community buildsys arm32 so that I can understand the build process and then try and do a do a build for an olimex olinuxino A20 board.
In addition, I've just received a Pine64 board and wouldn't mind trying to do a build for that too. Do I need to resubmit the request for buildsys - arm64 with the same keys?
Cheers Nick
Hi Nick,
The community buildsys arm32 (plague build-farm) is just composed of plague/mock builders. If you're interested in testing/supporting a specific board, the first thing to do would be to see if the board requires : - specific firmware - specific kernel - specific uboot
If current uboot has support (image) for that board (http://mirror.centos.org/altarch/7/extras/armhfp/Packages/uboot-images-armv7...),
then it's just a matter of using rbf (and so not on the plague
build-farm) to test an image. Obviously I can do that , if being pointed to the uboot image to include for that image.
Just adding that it seems uboot image exist for that board, but I see multiple ones :
if you extract the content of that uboot-images-armv7-2015.10-4.el7.noarch.rpm, you'll see that it contains : |-- A20-Olimex-SOM-EVB | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime2 | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino_MICRO | `-- u-boot-sunxi-with-spl.bin
Just by looking at https://www.olimex.com/Products/OLinuXino/A20/open-source-hardware , I don't know which one you have. I can try to build multiple variants, but what you can do is the following too :
- - Follow the instruction to transfer a "generic" board (use the Cubietruck image) https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32?highlight=%28arm3... - - Once done, replace the uboot image with the one corresponding to your board : (be careful about destination device as mentioned above) dd if=$UBOOT of=$DISKIMAGE bs=1024 seek=8 conv=fsync,notrunc
- From that point, it would normally be ok (assuming that the uboot image is the correct one, of course.
If you don't feel confident, just give us the more details about your board, and I'll generate an image that I'll put on dev.centos.org for testing.
Cheers,
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
Thanks for this (too!).
The board I have is a A20-OLinuXino_MICRO. I really need to get to the bottom of the build process as I need to slip in xen at the beginning of the boot.
Thanks for suggesting the generic board approach - just what I needed.
If you have time to generate an image for the A20-OLinuXino_MICRO and put it on dev.centos.org then I'll pull it down and test it for you.
Cheers Nick
Hi Nick,
The community buildsys arm32 (plague build-farm) is just composed of plague/mock builders. If you're interested in testing/supporting a specific board, the first thing to do would be to see if the board requires : - specific firmware - specific kernel - specific uboot
If current uboot has support (image) for that board (http://mirror.centos.org/altarch/7/extras/armhfp/Packages/uboot-images-armv7...),
then it's just a matter of using rbf (and so not on the plague
build-farm) to test an image. Obviously I can do that , if being pointed to the uboot image to include for that image.
Just adding that it seems uboot image exist for that board, but I see multiple ones :
if you extract the content of that uboot-images-armv7-2015.10-4.el7.noarch.rpm, you'll see that it contains : |-- A20-Olimex-SOM-EVB | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime2 | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino_MICRO | `-- u-boot-sunxi-with-spl.bin
Just by looking at https://www.olimex.com/Products/OLinuXino/A20/open-source-hardware , I don't know which one you have. I can try to build multiple variants, but what you can do is the following too :
- Follow the instruction to transfer a "generic" board (use the
Cubietruck image) https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32?highlight=%28arm3...
- Once done, replace the uboot image with the one corresponding to
your board : (be careful about destination device as mentioned above) dd if=$UBOOT of=$DISKIMAGE bs=1024 seek=8 conv=fsync,notrunc
- From that point, it would normally be ok (assuming that the uboot
image is the correct one, of course.
If you don't feel confident, just give us the more details about your board, and I'll generate an image that I'll put on dev.centos.org for testing.
Cheers,
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
I can put up the uboot here for this board and you can use the Cubietruck image and overlay its uboot with the olinuXino uboot. It is already on my webserver, I only need to copy it to the server dir.
The uboots are the only difference between the images for the two boards.
I keep saying, that we can simplify installs for lots of boards with a general image and a script to install the proper uboot (and with BBB the MLO file). This is just going to get bigger rather than smaller....
On 01/06/2016 08:19 AM, Nick Betteridge wrote:
Thanks for this (too!).
The board I have is a A20-OLinuXino_MICRO. I really need to get to the bottom of the build process as I need to slip in xen at the beginning of the boot.
Thanks for suggesting the generic board approach - just what I needed.
If you have time to generate an image for the A20-OLinuXino_MICRO and put it on dev.centos.org then I'll pull it down and test it for you.
Cheers Nick
Hi Nick, The community buildsys arm32 (plague build-farm) is just composed of plague/mock builders. If you're interested in testing/supporting a specific board, the first thing to do would be to see if the board requires : - specific firmware - specific kernel - specific uboot If current uboot has support (image) for that board (http://mirror.centos.org/altarch/7/extras/armhfp/Packages/uboot-images-armv7...),
then it's just a matter of using rbf (and so not on the plague
build-farm) to test an image. Obviously I can do that , if being pointed to the uboot image to include for that image.
Just adding that it seems uboot image exist for that board, but I see multiple ones :
if you extract the content of that uboot-images-armv7-2015.10-4.el7.noarch.rpm, you'll see that it contains : |-- A20-Olimex-SOM-EVB | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino-Lime2 | `-- u-boot-sunxi-with-spl.bin |-- A20-OLinuXino_MICRO | `-- u-boot-sunxi-with-spl.bin
Just by looking at https://www.olimex.com/Products/OLinuXino/A20/open-source-hardware , I don't know which one you have. I can try to build multiple variants, but what you can do is the following too :
- Follow the instruction to transfer a "generic" board (use the
Cubietruck image) https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32?highlight=%28arm3...
- Once done, replace the uboot image with the one corresponding to
your board : (be careful about destination device as mentioned above) dd if=$UBOOT of=$DISKIMAGE bs=1024 seek=8 conv=fsync,notrunc
- From that point, it would normally be ok (assuming that the uboot
image is the correct one, of course.
If you don't feel confident, just give us the more details about your board, and I'll generate an image that I'll put on dev.centos.org for testing.
Cheers,
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Fabian Arrotin -
Karanbir Singh -
Nick Betteridge -
Robert Moskowitz