[Arm-dev] supported 64bit hardware

[Jim Perrin]

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 at internetmachines.co.uk
>> <mailto:nick at internetmachines.co.uk>> wrote:
>>
>>
>>> On 18 Sep 2016, at 18:55, Jeffrey Walton <noloader at gmail.com
>>> <mailto:noloader at 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 at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
> 

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77