Which 64 bit consumer-size board is the easiest to work with now?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
Any suggestions?
Many thanks, Nick
On 2016-09-18 09:46, Nick Hardiman wrote:
Which 64 bit consumer-size board is the easiest to work with now?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
Any suggestions?
AFAIK the only boards that will be officially supported will be ones that support UEFI. I'm sure many others will have images made available for them by the community.
Personally, I use a Gigabyte MP30-AR0 (Note: AR1 is the same board as the AR0 but with UEFI firmware. You can flash the firmware back and forth as you want, and you can chain load UEFI firmware from u-boot (that is what I do). You can put up to 128GB of RAM into that and with 8 rather performant cores you can probably run whatever you want to compartmentalize in containers (or VMs if you don't mind the performance hit that goes with it).
The only downside of the Gigabyte MP30 is that the board costs about £500 (not including RAM, it takes ECC DDR3 UDIMMs/RDIMMs).
Gordan
Is one allowed to post commercial links? Regards, Tony
On Sun, Sep 18, 2016 at 12:34 PM +0200, "Gordan Bobic" <gordan@redsleeve.orgmailto:gordan@redsleeve.org> wrote:
On 2016-09-18 09:46, Nick Hardiman wrote:
Which 64 bit consumer-size board is the easiest to work with now?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
Any suggestions?
AFAIK the only boards that will be officially supported will be ones that support UEFI. I'm sure many others will have images made available for them by the community.
Personally, I use a Gigabyte MP30-AR0 (Note: AR1 is the same board as the AR0 but with UEFI firmware. You can flash the firmware back and forth as you want, and you can chain load UEFI firmware from u-boot (that is what I do). You can put up to 128GB of RAM into that and with 8 rather performant cores you can probably run whatever you want to compartmentalize in containers (or VMs if you don't mind the performance hit that goes with it).
The only downside of the Gigabyte MP30 is that the board costs about £500 (not including RAM, it takes ECC DDR3 UDIMMs/RDIMMs).
Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 09/18/2016 05:47 AM, Tony Lees - Avantek wrote:
Is one allowed to post commercial links? Regards, Tony
In general, no we don't want ads or commercial links, however if it directly answers the OP's question, then yes.
On Sun, Sep 18, 2016 at 12:34 PM +0200, "Gordan Bobic" <gordan@redsleeve.org mailto:gordan@redsleeve.org> wrote:
On 2016-09-18 09:46, Nick Hardiman wrote:
Which 64 bit consumer-size board is the easiest to work with now?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
Any suggestions?
AFAIK the only boards that will be officially supported will be ones that support UEFI. I'm sure many others will have images made available for them by the community.
Personally, I use a Gigabyte MP30-AR0 (Note: AR1 is the same board as the AR0 but with UEFI firmware. You can flash the firmware back and forth as you want, and you can chain load UEFI firmware from u-boot (that is what I do). You can put up to 128GB of RAM into that and with 8 rather performant cores you can probably run whatever you want to compartmentalize in containers (or VMs if you don't mind the performance hit that goes with it).
The only downside of the Gigabyte MP30 is that the board costs about £500 (not including RAM, it takes ECC DDR3 UDIMMs/RDIMMs).
Gordan _______________________________________________ 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
In general, no we don't want ads or commercial links, however if it directly answers the OP's question, then yes.
Thanks. https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 Suffice to say that we have good knowledge of CentOS working on 64bit Cavium ThunderX and APM X-Gene if any help is required. Feel free to contact me off list if you prefer.
Regards, Tony Avantek Computer https://www.avantek.co.uk
On 09/18/2016 03:46 AM, Nick Hardiman wrote:
Which 64 bit consumer-size board is the easiest to work with now?
Most of the consumer boards have very odd idiosyncrasies that often mean trouble. For example the hikey works just fine with the uefi firmware, but the partitioning established by default means that the EFI boot partition is /boot, instead of the more common (standard) /boot/efi. Most of the other 64bit boards rely on uboot or other bootloaders that are problematic to support. The more recent uboots have a uefi emulation that we might be able to take advantage of *if* the boards support upstream uefi and not their own custom forks.
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level.
That's pretty much exactly why we've been sticking to requiring UEFI functionality for full support of the boards.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
The initial target is absolutely server and DC, as centos is traditionally quite popular in those markets. We build and test with Applied Micro, Cavium, and AMD's Seattle chipsets.
I do want to start looking at larger (god help me for using this term) IOT style devices or gateway devices, where we can provide the sort of life-cycle those devices typically lack. I covered a bit about the hikey earlier. I'm waiting to see when/if the cello arrives. In theory it will support CentOS right out of the box.
The other one I've had my eye on is the https://www.solid-run.com/product/armada-8040-networking-community-board/
I don't know if it will work ootb, but it supports uefi, and *seems* to have all the right supportable bits. When I get my hands on it, I'll let you know.
If you're interested in helping out with this, I would wholeheartedly encourage you to join the efforts.
On 2016-09-18 16:13, Jim Perrin wrote:
On 09/18/2016 03:46 AM, Nick Hardiman wrote:
Which 64 bit consumer-size board is the easiest to work with now?
Most of the consumer boards have very odd idiosyncrasies that often mean trouble. For example the hikey works just fine with the uefi firmware, but the partitioning established by default means that the EFI boot partition is /boot, instead of the more common (standard) /boot/efi. Most of the other 64bit boards rely on uboot or other bootloaders that are problematic to support. The more recent uboots have a uefi emulation that we might be able to take advantage of *if* the boards support upstream uefi and not their own custom forks.
Which is kind of ironic considering that nearly all ARM devices use u-boot. Unfortunately, most use a proprietary hack job of u-boot with no sources, and u-boot generally never gets updated, so even in this day and age many of those u-boots only understand FAT.
Even more ironically, UEFI by spec only supports FAT.
And with custom UEFI forks, it's u-boot all over again. :-(
Hi Jim,
On 18 Sep 2016, at 16:13, Jim Perrin jperrin@centos.org wrote: If you're interested in helping out with this, I would wholeheartedly encourage you to join the efforts.
Sorry to ask direct, I’m sure you have better things to do. I’ve been thinking about this, but I am not sure where to start.
What would you like to see? Is there someone who organizes things, or a wishlist perhaps?
Thanks, Nick
On 09/21/2016 02:50 AM, Nick Hardiman wrote:
Hi Jim,
On 18 Sep 2016, at 16:13, Jim Perrin jperrin@centos.org wrote: If you're interested in helping out with this, I would wholeheartedly encourage you to join the efforts.
Sorry to ask direct, I’m sure you have better things to do. I’ve been thinking about this, but I am not sure where to start.
This pretty much *is* what I do, it's not an inconvenience at all, so don't worry about asking.
What would you like to see? Is there someone who organizes things, or a wishlist perhaps?
So my focus is on the distro as a whole, and mostly aimed at the server side of things. However quite a number of folks are looking at the smaller boards (The odroid c2, the rpi3, the pine64, etc). While folks like Uli have been great at building out images with our userspace, they still mostly rely on the vendor kernels. Ideally I'd like to support those chipsets with the distro kernel, so if someone wanted to provide patches for enabling them that would be fantastic.
Beyond that, my wish list would also include a uboot that worked with the 'common' boards and contained the latest uefi emulation patches, and packages (or containers/Dockerfiles) for common arm or maker software.
Blogs, documentation, wiki help, etc is also welcome. I'm terrible at documenting things so that would help immensely.
Probably also worth noting that I don't pretend to have all the answers. How are you using this build? What would help you?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
* LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto) * Pine64 (Aarch64, ASIMD, CRC, Crypto) * ODROID-C2 (Aarch64, ASIMD, CRC) * Raspberry Pi-3 (Armhf (not even Aarch32))
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks. if you try to enable CRC with CFLAGS = -march=armv8-a+crc, then you get obscure crashes due to PCS incompatibility.
I the Pine64 is the best value because its less expensive than the comparable HiKey. HiKey runs around 1.2 Ghz, while Pine64 runs around 2.0 GHz.
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
* Mustang board (early ones lack CRC and Crypto) * Overdrive 1000 (AMD ARMv8 processor)
I recommend the server boards if you have the money. They are much faster than the dev-boards. I use Robert Nelson's Mustang for testing (he's kind enough to provide remote access).
I tried to purchase an Overdrive for testing three months ago. I was really looking forward to testing on the Overdrive. So were others like Andy Polyakov from OpenSSL. The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Jeff
On 2016-09-18 18:55, Jeffrey Walton wrote:
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Wait - what's aarch32?
On Sun, Sep 18, 2016 at 2:01 PM, Gordan Bobic gordan@redsleeve.org wrote:
On 2016-09-18 18:55, Jeffrey Walton wrote:
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Wait - what's aarch32?
32-bit execution state on 64-bit ARM processors. A32 instruction set, trust zones, supervisor mode, new ABI/procedure calling conventions (APCS), etc.
Frame pointers and layout are completely different. Also see https://community.arm.com/docs/DOC-8453 . I tired to do a post-mortem on the RPI3 after enabling ARMv8 for the CRC. It was an exercise in futility. Also see "Recover frame pointer for broken back trace?", http://stackoverflow.com/q/38798592 .
Jeff
Am 18.09.2016 um 19:55 schrieb Jeffrey Walton:
I would avoid the RPI3.
Full ACK.
I the Pine64 is the best value because its less expensive than the comparable HiKey. HiKey runs around 1.2 Ghz, while Pine64 runs around 2.0 GHz.
The Pine64 runs at 1.1 GHz only, most likely due to the fact that the CPU needs more cooling at higher frequencies and draws more power than provided by the micro USB power connector.
The ODROID-C2 is supposed to run at 2 GHz, but this is a different story. Mine runs stable at 1.75GHz. Compared to the Pine64, the C2 has some advantages, e.g. - eMMC support - 4 USB ports usable - integrated heatsink - barrel plug for power supply
Both devices are about to get mainline support for headless usage.
Cheers Uli
On 09/18/2016 10:15 PM, Uli Middelberg wrote:
Am 18.09.2016 um 19:55 schrieb Jeffrey Walton:
I would avoid the RPI3.
Full ACK.
I the Pine64 is the best value because its less expensive than the comparable HiKey. HiKey runs around 1.2 Ghz, while Pine64 runs around 2.0 GHz.
The Pine64 runs at 1.1 GHz only, most likely due to the fact that the CPU needs more cooling at higher frequencies and draws more power than provided by the micro USB power connector.
The ODROID-C2 is supposed to run at 2 GHz, but this is a different story. Mine runs stable at 1.75GHz. Compared to the Pine64, the C2 has some advantages, e.g.
- eMMC support
- 4 USB ports usable
- integrated heatsink
- barrel plug for power supply
Both devices are about to get mainline support for headless usage.
+1 for C2. it's a wonderful toy. i am eagerly waiting for a better centos support for it ( including multimedia ! )
The ODROID-C2 is supposed to run at 2 GHz, but this is a different story. Mine runs stable at 1.75GHz. Compared to the Pine64, the C2 has some advantages, e.g.
- eMMC support
- 4 USB ports usable
- integrated heatsink
- barrel plug for power supply
Information on the "supposed to run at 2 GHz" comment can be found here:
http://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appe...
Just an FYI.
Thanks, David
________________________________ From: arm-dev-bounces@centos.org arm-dev-bounces@centos.org on behalf of Manuel Wolfshant wolfy@nobugconsulting.ro Sent: Sunday, September 18, 2016 1:34 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
On 09/18/2016 10:15 PM, Uli Middelberg wrote:
Am 18.09.2016 um 19:55 schrieb Jeffrey Walton:
I would avoid the RPI3.
Full ACK.
I the Pine64 is the best value because its less expensive than the comparable HiKey. HiKey runs around 1.2 Ghz, while Pine64 runs around 2.0 GHz.
The Pine64 runs at 1.1 GHz only, most likely due to the fact that the CPU needs more cooling at higher frequencies and draws more power than provided by the micro USB power connector.
The ODROID-C2 is supposed to run at 2 GHz, but this is a different story. Mine runs stable at 1.75GHz. Compared to the Pine64, the C2 has some advantages, e.g.
- eMMC support
- 4 USB ports usable
- integrated heatsink
- barrel plug for power supply
Both devices are about to get mainline support for headless usage.
+1 for C2. it's a wonderful toy. i am eagerly waiting for a better centos support for it ( including multimedia ! ) _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 18 Sep 2016, at 18:55, Jeffrey Walton noloader@gmail.com wrote:
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Good summary, thanks.
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks.
That’s a shocker. I will strike the RPi from my list of possibles - seems a shame. I wonder how durable the others are.
What I want to do here is find out if these are useful for offloading simple services - maybe one per board. I don’t know the advantages of a set of small, physically discrete, devices running a set of services, and I’d like to find out. I know they’d be a trainwreck for a customer-facing dynamically generated website. But what about NTP? True randomness maybe? How would they handle generating Kerberos tickets, or providing service discovery? Does XEN slow them down to a crawl? Can they generate synthetic load, and monitor the results? No idea.
I may be barking up the wrong tree here. If UEFI is the way forward, I don’t imagine a distro-maintained kernel package will ever be supplied for any of these consumer-size boards. So there’s no avoiding u-boot tinkering, /boot/ copying or kernel compiling when dealing with consumer boards like these. Does that sound right?
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
- Mustang board (early ones lack CRC and Crypto)
- Overdrive 1000 (AMD ARMv8 processor)
I searched for the Gigabyte MP30-AR0 after Gordan described it. It’s not right for my pet project here, but I can see the appeal for the day job. And if this 32 core X-Gene3 appears, maybe that will be a lot of bang for your buck.
The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Sorry to hear that. Sounds like there are more of these bigger boards on the way - Lenovator Cello maybe?
I don’t know about Cavium, and AMD's Seattle chipsets.
Thanks for the help. I am enlightened. Nick
I was on the verge of buying a couple small SBCs back in September, to install CentOS on. But then I stopped to concentrate on my RHCE exam. Now I’m trying to pick up where I left off.
I remember Uli Middleburg said Odroid C2 was not far off having all device drivers in the mainline kernel.
How’s kernel support for the LeMaker HiKey? Have things moved on since Jim Perrin wrote these build instructions? https://people.centos.org/jperrin/hikey/ReadMe.txt https://people.centos.org/jperrin/hikey/ReadMe.txt
On 19 Sep 2016, at 18:25, Nick Hardiman nick@internetmachines.co.uk wrote:
On 18 Sep 2016, at 18:55, Jeffrey Walton noloader@gmail.com wrote:
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Good summary, thanks.
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks.
That’s a shocker. I will strike the RPi from my list of possibles - seems a shame. I wonder how durable the others are.
What I want to do here is find out if these are useful for offloading simple services - maybe one per board. I don’t know the advantages of a set of small, physically discrete, devices running a set of services, and I’d like to find out. I know they’d be a trainwreck for a customer-facing dynamically generated website. But what about NTP? True randomness maybe? How would they handle generating Kerberos tickets, or providing service discovery? Does XEN slow them down to a crawl? Can they generate synthetic load, and monitor the results? No idea.
I may be barking up the wrong tree here. If UEFI is the way forward, I don’t imagine a distro-maintained kernel package will ever be supplied for any of these consumer-size boards. So there’s no avoiding u-boot tinkering, /boot/ copying or kernel compiling when dealing with consumer boards like these. Does that sound right?
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
- Mustang board (early ones lack CRC and Crypto)
- Overdrive 1000 (AMD ARMv8 processor)
I searched for the Gigabyte MP30-AR0 after Gordan described it. It’s not right for my pet project here, but I can see the appeal for the day job. And if this 32 core X-Gene3 appears, maybe that will be a lot of bang for your buck.
The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Sorry to hear that. Sounds like there are more of these bigger boards on the way - Lenovator Cello maybe?
I don’t know about Cavium, and AMD's Seattle chipsets.
Thanks for the help. I am enlightened. Nick
I haven't put much futher effort/consideration into the hikey. I need to look at it again more closely to see how much they've managed to get into the upstream kernel, or what it would take to add support to the 4.5 based kernel coming in the 7.3.1611 build.
While I can't promise anything yet, we should also have a patchset coming that would enable 64bit support for the rpi3 for everything except graphics. The upstream graphics driver isn't as stable as I'd like so I'm looking at restricting that to console only for now.
On 12/04/2016 09:27 AM, Nick Hardiman wrote:
I was on the verge of buying a couple small SBCs back in September, to install CentOS on. But then I stopped to concentrate on my RHCE exam. Now I’m trying to pick up where I left off.
I remember Uli Middleburg said Odroid C2 was not far off having all device drivers in the mainline kernel.
How’s kernel support for the LeMaker HiKey? Have things moved on since Jim Perrin wrote these build instructions? https://people.centos.org/jperrin/hikey/ReadMe.txt
On 19 Sep 2016, at 18:25, Nick Hardiman <nick@internetmachines.co.uk mailto:nick@internetmachines.co.uk> wrote:
On 18 Sep 2016, at 18:55, Jeffrey Walton <noloader@gmail.com mailto:noloader@gmail.com> wrote:
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Good summary, thanks.
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks.
That’s a shocker. I will strike the RPi from my list of possibles - seems a shame. I wonder how durable the others are.
What I want to do here is find out if these are useful for offloading simple services - maybe one per board. I don’t know the advantages of a set of small, physically discrete, devices running a set of services, and I’d like to find out. I know they’d be a trainwreck for a customer-facing dynamically generated website. But what about NTP? True randomness maybe? How would they handle generating Kerberos tickets, or providing service discovery? Does XEN slow them down to a crawl? Can they generate synthetic load, and monitor the results? No idea.
I may be barking up the wrong tree here. If UEFI is the way forward, I don’t imagine a distro-maintained kernel package will ever be supplied for any of these consumer-size boards. So there’s no avoiding u-boot tinkering, /boot/ copying or kernel compiling when dealing with consumer boards like these. Does that sound right?
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
- Mustang board (early ones lack CRC and Crypto)
- Overdrive 1000 (AMD ARMv8 processor)
I searched for the Gigabyte MP30-AR0 after Gordan described it. It’s not right for my pet project here, but I can see the appeal for the day job. And if this 32 core X-Gene3 appears, maybe that will be a lot of bang for your buck.
The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Sorry to hear that. Sounds like there are more of these bigger boards on the way - Lenovator Cello maybe?
I don’t know about Cavium, and AMD's Seattle chipsets.
Thanks for the help. I am enlightened. Nick
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 5 Dec 2016, at 16:38, Jim Perrin jperrin@centos.org wrote:
I haven't put much futher effort/consideration into the hikey. I need to look at it again more closely to see how much they've managed to get into the upstream kernel, or what it would take to add support to the 4.5 based kernel coming in the 7.3.1611 build.
OK, thanks. I didn't get past sticking hi6220 in Google and randomly clicking on https://github.com/96boards-hikey/linux https://github.com/96boards-hikey/linux.
While I can't promise anything yet, we should also have a patchset coming that would enable 64bit support for the rpi3 for everything except graphics. The upstream graphics driver isn't as stable as I'd like so I'm looking at restricting that to console only for now.
I thought rpi3 was a non-starter because of missing firmware. Maybe I remembered that wrong. I’m not interested in graphics, so that is a possibility.
On 12/04/2016 09:27 AM, Nick Hardiman wrote:
I was on the verge of buying a couple small SBCs back in September, to install CentOS on. But then I stopped to concentrate on my RHCE exam. Now I’m trying to pick up where I left off.
I remember Uli Middleburg said Odroid C2 was not far off having all device drivers in the mainline kernel.
How’s kernel support for the LeMaker HiKey? Have things moved on since Jim Perrin wrote these build instructions? https://people.centos.org/jperrin/hikey/ReadMe.txt
On 19 Sep 2016, at 18:25, Nick Hardiman <nick@internetmachines.co.uk <mailto:nick@internetmachines.co.uk mailto:nick@internetmachines.co.uk>> wrote:
On 18 Sep 2016, at 18:55, Jeffrey Walton <noloader@gmail.com mailto:noloader@gmail.com <mailto:noloader@gmail.com mailto:noloader@gmail.com>> wrote:
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Good summary, thanks.
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks.
That’s a shocker. I will strike the RPi from my list of possibles - seems a shame. I wonder how durable the others are.
What I want to do here is find out if these are useful for offloading simple services - maybe one per board. I don’t know the advantages of a set of small, physically discrete, devices running a set of services, and I’d like to find out. I know they’d be a trainwreck for a customer-facing dynamically generated website. But what about NTP? True randomness maybe? How would they handle generating Kerberos tickets, or providing service discovery? Does XEN slow them down to a crawl? Can they generate synthetic load, and monitor the results? No idea.
I may be barking up the wrong tree here. If UEFI is the way forward, I don’t imagine a distro-maintained kernel package will ever be supplied for any of these consumer-size boards. So there’s no avoiding u-boot tinkering, /boot/ copying or kernel compiling when dealing with consumer boards like these. Does that sound right?
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
- Mustang board (early ones lack CRC and Crypto)
- Overdrive 1000 (AMD ARMv8 processor)
I searched for the Gigabyte MP30-AR0 after Gordan described it. It’s not right for my pet project here, but I can see the appeal for the day job. And if this 32 core X-Gene3 appears, maybe that will be a lot of bang for your buck.
The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Sorry to hear that. Sounds like there are more of these bigger boards on the way - Lenovator Cello maybe?
I don’t know about Cavium, and AMD's Seattle chipsets.
Thanks for the help. I am enlightened. Nick
Arm-dev mailing list Arm-dev@centos.org mailto:Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev https://lists.centos.org/mailman/listinfo/arm-dev
-- Jim Perrin The CentOS Project | http://www.centos.org http://www.centos.org/ twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ Arm-dev mailing list Arm-dev@centos.org mailto:Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev https://lists.centos.org/mailman/listinfo/arm-dev
Hi,
I previously build and packaged an aarch64 kernel for the C2 based on their kernel source on github. If there is interest in that, I could share that.
The building was a bit troublesome, as it did not work with the standard gcc in CentOS7. So I also rebuild a newer gcc from SCL.
Jacco
On Sunday, 04 December, 2016 15:27 CET, Nick Hardiman nick@internetmachines.co.uk wrote:
I was on the verge of buying a couple small SBCs back in September, to install CentOS on. But then I stopped to concentrate on my RHCE exam. Now I’m trying to pick up where I left off.
I remember Uli Middleburg said Odroid C2 was not far off having all device drivers in the mainline kernel.
How’s kernel support for the LeMaker HiKey? Have things moved on since Jim Perrin wrote these build instructions? https://people.centos.org/jperrin/hikey/ReadMe.txt https://people.centos.org/jperrin/hikey/ReadMe.txt
On 19 Sep 2016, at 18:25, Nick Hardiman nick@internetmachines.co.uk wrote:
On 18 Sep 2016, at 18:55, Jeffrey Walton noloader@gmail.com wrote:
There are four small ARMv8 dev-boards I am aware. I have all of them for testing software. They are:
- LeMaker HiKey (Aarch64, ASIMD, CRC, Crypto)
- Pine64 (Aarch64, ASIMD, CRC, Crypto)
- ODROID-C2 (Aarch64, ASIMD, CRC)
- Raspberry Pi-3 (Armhf (not even Aarch32))
Good summary, thanks.
I would avoid the RPI3. Its in a crummy configuration, and mine died after about 2 weeks.
That’s a shocker. I will strike the RPi from my list of possibles - seems a shame. I wonder how durable the others are.
What I want to do here is find out if these are useful for offloading simple services - maybe one per board. I don’t know the advantages of a set of small, physically discrete, devices running a set of services, and I’d like to find out. I know they’d be a trainwreck for a customer-facing dynamically generated website. But what about NTP? True randomness maybe? How would they handle generating Kerberos tickets, or providing service discovery? Does XEN slow them down to a crawl? Can they generate synthetic load, and monitor the results? No idea.
I may be barking up the wrong tree here. If UEFI is the way forward, I don’t imagine a distro-maintained kernel package will ever be supplied for any of these consumer-size boards. So there’s no avoiding u-boot tinkering, /boot/ copying or kernel compiling when dealing with consumer boards like these. Does that sound right?
At the higher end, there are two servers I am aware. I believe the Applied Micro X-gene is the Mustang board.
- Mustang board (early ones lack CRC and Crypto)
- Overdrive 1000 (AMD ARMv8 processor)
I searched for the Gigabyte MP30-AR0 after Gordan described it. It’s not right for my pet project here, but I can see the appeal for the day job. And if this 32 core X-Gene3 appears, maybe that will be a lot of bang for your buck.
The Overdrive never arrived (more correctly, it never shipped), and I'm trying to get a refund on the purchase.
Sorry to hear that. Sounds like there are more of these bigger boards on the way - Lenovator Cello maybe?
I don’t know about Cavium, and AMD's Seattle chipsets.
Thanks for the help. I am enlightened. Nick
Am 06.12.2016 um 10:15 schrieb Jacco Ligthart:
I previously build and packaged an aarch64 kernel for the C2 based on their kernel source on github. If there is interest in that, I could share that.
The building was a bit troublesome, as it did not work with the standard gcc in CentOS7. So I also rebuild a newer gcc from SCL.
This is really nasty. Is there an easy way the get a gcc5 compiler for CentOS? Instead of building the gcc from source I fire up an Ubuntu Docker Container each time ...
Cheers Uli
On 12/06/2016 06:46 AM, Uli Middelberg wrote:
Am 06.12.2016 um 10:15 schrieb Jacco Ligthart:
The building was a bit troublesome, as it did not work with the standard gcc in CentOS7. So I also rebuild a newer gcc from SCL.
This is really nasty. Is there an easy way the get a gcc5 compiler for CentOS? Instead of building the gcc from source I fire up an Ubuntu Docker Container each time ...
As I recall, 4.9.2 is required for the ODroid C2's kernel. CentOS 7 ships 4.8.5; 4.9.2 is in the devtoolset-3 Software Collection for CentOS 7 (RPM packaged for x86_64 but not aarch64). Is a gcc5 ok for building the Hardkernel kernel now? It wasn't the last time I looked.
I actually went through a more convoluted process to get my kernels; having a real kernel RPM for the C2 kernel would be fantastic. If devtoolset-3 was packaged for aarch64 this would be pretty easy.
On Tuesday, 06 December, 2016 15:13 CET, Lamar Owen lowen@pari.edu wrote:
On 12/06/2016 06:46 AM, Uli Middelberg wrote:
Am 06.12.2016 um 10:15 schrieb Jacco Ligthart:
The building was a bit troublesome, as it did not work with the standard gcc in CentOS7. So I also rebuild a newer gcc from SCL.
This is really nasty. Is there an easy way the get a gcc5 compiler for CentOS? Instead of building the gcc from source I fire up an Ubuntu Docker Container each time ...
As I recall, 4.9.2 is required for the ODroid C2's kernel. CentOS 7 ships 4.8.5; 4.9.2 is in the devtoolset-3 Software Collection for CentOS 7 (RPM packaged for x86_64 but not aarch64). Is a gcc5 ok for building the Hardkernel kernel now? It wasn't the last time I looked.
I actually went through a more convoluted process to get my kernels; having a real kernel RPM for the C2 kernel would be fantastic. If devtoolset-3 was packaged for aarch64 this would be pretty easy.
I indeed packaged (a part of) devtoolset-3
Jacco
Am 06.12.2016 um 15:13 schrieb Lamar Owen:
As I recall, 4.9.2 is required for the ODroid C2's kernel. CentOS 7 ships 4.8.5; 4.9.2 is in the devtoolset-3 Software Collection for CentOS 7 (RPM packaged for x86_64 but not aarch64). Is a gcc5 ok for building the Hardkernel kernel now? It wasn't the last time I looked.
Linux version 3.14.79-94 (root@a53_b1) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.1) ) #1 SMP PREEMPT Mon Nov 21 17:13:27 BRST 2016
HK is using gcc-5.4 for their official kernel.
I actually went through a more convoluted process to get my kernels; having a real kernel RPM for the C2 kernel would be fantastic.
I'll try to build one (using `make rpm-pkg`).
Cheers Uli
Am 06.12.2016 um 18:27 schrieb Uli Middelberg:
I'll try to build one (using `make rpm-pkg`).
I wasn't successful, one of the Makefiles needs some refactoring ("*** mixed implicit and static pattern rules. Stop")
I've build a tar archive containing the kernel image, modules, headers, etc.. You can install it via:
curl -sSL https://www.dropbox.com/s/96dw3mdzxv43cz9/linux-3.14.79-c2-00001-g2f55842-di... | sudo tar -C / --numeric-owner -xJpvf -
You will find the kernel image file and dtb in /boot/kernel.d/linux-3.14.79-c2-00001-g2f55842-dirty
I'll try the mainline kernel (still unstable at this time) next.
Cheers Uli
It is necessary to set UTS_MACHINE to aacrh64 to get rid off this bug.
This issue could be addressed by following patch: http://www.spinics.net/lists/arm-kernel/msg527466.html
WBR, Vadim ________________________________________ From: Arm-dev arm-dev-bounces@centos.org on behalf of Uli Middelberg uli@middelberg.de Sent: Thursday, December 8, 2016 12:34 To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
Am 06.12.2016 um 18:27 schrieb Uli Middelberg:
I'll try to build one (using `make rpm-pkg`).
I wasn't successful, one of the Makefiles needs some refactoring ("*** mixed implicit and static pattern rules. Stop")
I've build a tar archive containing the kernel image, modules, headers, etc.. You can install it via:
curl -sSL https://www.dropbox.com/s/96dw3mdzxv43cz9/linux-3.14.79-c2-00001-g2f55842-di... | sudo tar -C / --numeric-owner -xJpvf -
You will find the kernel image file and dtb in /boot/kernel.d/linux-3.14.79-c2-00001-g2f55842-dirty
I'll try the mainline kernel (still unstable at this time) next.
Cheers Uli
Am 12.12.2016 um 14:20 schrieb Lomovtsev, Vadim:
It is necessary to set UTS_MACHINE to aacrh64 to get rid off this bug.
This issue could be addressed by following patch: http://www.spinics.net/lists/arm-kernel/msg527466.html
The patch mentioned above doesn't fix the issue, unfortunately.
.../rpmbuild/BUILD/kernel-3.14.79_c2_g2e26288_dirty/scripts/Makefile.fwinst:45: *** mixed implicit and static pattern rules. Stop.
Cheers Uli
On 13-12-16 20:15, Uli Middelberg wrote:
Am 12.12.2016 um 14:20 schrieb Lomovtsev, Vadim:
It is necessary to set UTS_MACHINE to aacrh64 to get rid off this bug.
This issue could be addressed by following patch: http://www.spinics.net/lists/arm-kernel/msg527466.html
The patch mentioned above doesn't fix the issue, unfortunately.
.../rpmbuild/BUILD/kernel-3.14.79_c2_g2e26288_dirty/scripts/Makefile.fwinst:45: *** mixed implicit and static pattern rules. Stop.
Cheers Uli
Here is my SPEC file: https://github.com/redsleeve-linux/odroid/blob/master/odroidc2-kernel/SPECS/...
This works for me, (if you first make devtoolset-3 )
Jacco
I believe you're trying to build arm64 kernel rpm by make rpm-pkg command, correct? And I also faced similar issue some time ago with my kernel and was able to fix it setting properly UTS_MACHINE variable.
Could you give me a link or version to kernel sources to let me take a look github or any other ?
Vadim ________________________________________ From: Arm-dev arm-dev-bounces@centos.org on behalf of Uli Middelberg uli@middelberg.de Sent: Tuesday, December 13, 2016 10:15:48 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
Am 12.12.2016 um 14:20 schrieb Lomovtsev, Vadim:
It is necessary to set UTS_MACHINE to aacrh64 to get rid off this bug.
This issue could be addressed by following patch: http://www.spinics.net/lists/arm-kernel/msg527466.html
The patch mentioned above doesn't fix the issue, unfortunately.
.../rpmbuild/BUILD/kernel-3.14.79_c2_g2e26288_dirty/scripts/Makefile.fwinst:45: *** mixed implicit and static pattern rules. Stop.
Cheers Uli
Sorry, didn't get that it is about odroid.. my bad. However still interesting it fixing build failure.. How it could be build from kernel sources ? run CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rpm-pkg is enough ?
Vadim ________________________________________ From: Lomovtsev, Vadim Sent: Tuesday, December 13, 2016 22:29 To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
I believe you're trying to build arm64 kernel rpm by make rpm-pkg command, correct? And I also faced similar issue some time ago with my kernel and was able to fix it setting properly UTS_MACHINE variable.
Could you give me a link or version to kernel sources to let me take a look github or any other ?
Vadim ________________________________________ From: Arm-dev arm-dev-bounces@centos.org on behalf of Uli Middelberg uli@middelberg.de Sent: Tuesday, December 13, 2016 10:15:48 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
Am 12.12.2016 um 14:20 schrieb Lomovtsev, Vadim:
It is necessary to set UTS_MACHINE to aacrh64 to get rid off this bug.
This issue could be addressed by following patch: http://www.spinics.net/lists/arm-kernel/msg527466.html
The patch mentioned above doesn't fix the issue, unfortunately.
.../rpmbuild/BUILD/kernel-3.14.79_c2_g2e26288_dirty/scripts/Makefile.fwinst:45: *** mixed implicit and static pattern rules. Stop.
Cheers Uli
Am 13.12.2016 um 20:43 schrieb Lomovtsev, Vadim:
Sorry, didn't get that it is about odroid.. my bad. However still interesting it fixing build failure.. How it could be build from kernel sources ? run CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rpm-pkg is enough ?
I'm compiling he kernel on the C2 directly, so
make rpm-pkg
should do the job (just as make deb-pgk did, even without having applied the patch)
Cheers Uli
Hi Uli,
Short history and results of how I did this (not sure if I checkout right branch):
$ git checkout -b odroidc2-3.14.y uli-linux/odroidc2-3.14.y $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make odroidc2_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rpm-pkg
here I faced the same bug as you did "mixed implicit and static pattern" which has been addressed by following: $ git diff -u diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 18ea69f..067b6d3 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -25,10 +25,12 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS += -mbig-endian AS += -EB LD += -EB +UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian AS += -EL LD += -EL +UTS_MACHINE := aarch64 endif
comma = ,
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rpm-pkg [...] And fall into following (which is not new for me also): + cp Image.gz /home/vlomovtsev/rpmbuild/BUILDROOT/kernel-3.14.79_c2_00013_gdea3141_dirty-8.aarch64/boot/vmlinuz-3.14.79-c2-00013-gdea3141-dirty cp: cannot stat 'Image.gz': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.axFHeM (%install)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.axFHeM (%install) /home/vlomovtsev/repo/linux-thunderx-centos/scripts/package/Makefile:39: recipe for target 'rpm-pkg' failed make[1]: *** [rpm-pkg] Error 1 Makefile:1131: recipe for target 'rpm-pkg' failed make: *** [rpm-pkg] Error 2
This could be fixed by following (See patch: https://patchwork.codeaurora.org/patch/90165/):
$ git diff HEAD~1 diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 067b6d3..36bdd68 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -69,6 +69,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
boot := arch/arm64/boot
+image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE) + Image Image.gz: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
Than it fails once again due to local version postfix in the kernel version (cd wasn't able to find $RPM_BUILD_DIR/lib/modules/3.14.79-c2-00013-gdea3141-dirty folder). Disabling option CONFIG_LOCALVERSION_AUTO will fix that issue.
And eventually I was able to get rpms.
WBR, Vadim
Hi Vadim,
Am 14.12.2016 um 10:05 schrieb Lomovtsev, Vadim:
And eventually I was able to get rpms.
Tank you very much! I was able to get rpms as well (even with CONFIG_LOCALVERSION_AUTO enabled)
You can find them for download here: https://www.dropbox.com/sh/o8q8ttl97s1sqbp/AAAAx_SqbBR2hz3P5N4EOX98a?dl=0
This is the patch I've applied, I'll try to get it merged into the upstream repo.
Cheers Uli
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 18ea69f..36bdd68 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -25,10 +25,12 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS += -mbig-endian AS += -EB LD += -EB +UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian AS += -EL LD += -EL +UTS_MACHINE := aarch64 endif
comma = , @@ -67,6 +69,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
boot := arch/arm64/boot
+image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE) + Image Image.gz: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index f535a85..2564dfd 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -11,6 +11,8 @@ CFLAGS_REMOVE_ftrace.o = -pg CFLAGS_REMOVE_insn.o = -pg CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_setup.o = -DUTS_MACHINE='"$(UTS_MACHINE)"' + # Object file lists. arm64-obj-y := cputable.o debug-monitors.o entry.o irq.o fpsimd.o \ entry-fpsimd.o process.o ptrace.o setup.o signal.o \
Hi Uli,
The patch sets UTS_MACHINE for arm64 is in the mainline already (4.9 has it for sure). You may need to backport it onto your source tree. :)
However, second one (which adds image_name rule into Makefile) needs more work to be done for other architectures and mkspec/builddep scripts also. I plan get back to it after NY holydays.
WBR, Vadim ________________________________________ From: Arm-dev arm-dev-bounces@centos.org on behalf of Uli Middelberg uli@middelberg.de Sent: Thursday, December 15, 2016 6:26:23 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] supported 64bit hardware
Hi Vadim,
Am 14.12.2016 um 10:05 schrieb Lomovtsev, Vadim:
And eventually I was able to get rpms.
Tank you very much! I was able to get rpms as well (even with CONFIG_LOCALVERSION_AUTO enabled)
You can find them for download here: https://www.dropbox.com/sh/o8q8ttl97s1sqbp/AAAAx_SqbBR2hz3P5N4EOX98a?dl=0
This is the patch I've applied, I'll try to get it merged into the upstream repo.
Cheers Uli
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 18ea69f..36bdd68 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -25,10 +25,12 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS += -mbig-endian AS += -EB LD += -EB +UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian AS += -EL LD += -EL +UTS_MACHINE := aarch64 endif
comma = , @@ -67,6 +69,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
boot := arch/arm64/boot
+image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE) + Image Image.gz: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index f535a85..2564dfd 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -11,6 +11,8 @@ CFLAGS_REMOVE_ftrace.o = -pg CFLAGS_REMOVE_insn.o = -pg CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_setup.o = -DUTS_MACHINE='"$(UTS_MACHINE)"' + # Object file lists. arm64-obj-y := cputable.o debug-monitors.o entry.o irq.o fpsimd.o \ entry-fpsimd.o process.o ptrace.o setup.o signal.o \
On 13/12/16 20:53, Uli Middelberg wrote:
Am 13.12.2016 um 20:43 schrieb Lomovtsev, Vadim:
Sorry, didn't get that it is about odroid.. my bad. However still interesting it fixing build failure.. How it could be build from kernel sources ? run CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make rpm-pkg is enough ?
I'm compiling he kernel on the C2 directly, so
make rpm-pkg
should do the job (just as make deb-pgk did, even without having applied the patch)
Cheers Uli
Interesting, as someone was asking for odroidc2 armhfp image on irc (directly to me) (yeah, I know, "hijacking" the 64bit hardware) : does that kernel support being built for armv7 too the same way ? (and without any devtoolset pkg ?) If so, we can even consider building an image for it too (assuming that it's a sane and reproducible build)
Am 14.12.2016 um 19:31 schrieb Fabian Arrotin:
Interesting, as someone was asking for odroidc2 armhfp image on irc (directly to me) (yeah, I know, "hijacking" the 64bit hardware) : does that kernel support being built for armv7 too the same way ? (and without any devtoolset pkg ?) If so, we can even consider building an image for it too (assuming that it's a sane and reproducible build)
Some people prefer running a 32bit armhfp userland against the 64bit C2 aarch64 kernel, since some 64bit packages still suffer from performance / stability issues. Ubuntu and Debian support having packages from multiple architectures mixed up in one userland (multiarch), so its quite easy to run e.g. a 32bit Firefox browser within a 64bit xenial xerus. The kernel itself has to be 64bit, afaik.
At this time, the C2 kernel of choice is still a 3.14 vendor kernel from HK. Mainline boots up fine but crashes under some load.
How about providing a sbc/board agnostic CentOS userland (like Jim did for aarch64, see http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-rootfs-1606... I'd really appreciate it.
Cheers Uli
Am 13.12.2016 um 20:29 schrieb Lomovtsev, Vadim:
I believe you're trying to build arm64 kernel rpm by make rpm-pkg command, correct?
Yes, I do.
And I also faced similar issue some time ago with my kernel and was able to fix it setting properly UTS_MACHINE variable.
Could you give me a link or version to kernel sources to let me take a look github or any other ?
Thats very kind. I'm using my own copy of HK's kernel source repository https://github.com/aa64/linux/tree/odroidc2-3.14.y
I needed to rework the patch a little bit ... --- diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 18ea69f..e7a552e 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -25,10 +25,12 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS += -mbig-endian AS += -EB LD += -EB +UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian AS += -EL LD += -EL +UTS_MACHINE := aarch64_be endif
comma = , diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index f535a85..2564dfd 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -11,6 +11,8 @@ CFLAGS_REMOVE_ftrace.o = -pg CFLAGS_REMOVE_insn.o = -pg CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_setup.o = -DUTS_MACHINE='"$(UTS_MACHINE)"' + # Object file lists. arm64-obj-y := cputable.o debug-monitors.o entry.o irq.o fpsimd.o \ entry-fpsimd.o process.o ptrace.o setup.o signal.o \ diff --git a/scripts/package/builddeb b/scripts/package/builddeb index ae7e607..46973ea 100644 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -42,7 +42,7 @@ create_package() { debarch=hppa ;; mips*) debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG && echo el || true) ;; - arm64) + aarch64) debarch=arm64 ;; arm*) debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG && echo el || true) ;;
Am 04.12.2016 um 15:27 schrieb Nick Hardiman:
I remember Uli Middleburg said Odroid C2 was not far off having all device drivers in the mainline kernel.
It's still under development, you may follow this discussion here: http://forum.odroid.com/viewtopic.php?f=135&t=22717&start=100
Cheers Uli
-
Fabian Arrotin -
Gordan Bobic -
Jacco Ligthart -
Jeffrey Walton -
Jim Perrin -
Lamar Owen -
Lomovtsev, Vadim -
Manuel Wolfshant -
miniNodes Info -
Nick Hardiman -
Tony Lees - Avantek -
Uli Middelberg