Huawei Kunpeng 920 is an Armv8 server SoC with up to 64 cores that can be found in the company’s TaiShan series servers.
But the company has now designed “Kunpeng Desktop Board” featuring the quad or octa-core version of Kunpeng 920 SoC, in order to create Arm-powered desktop computers.
Kunpeng Desktop Board (model D920S10) preliminary specifications:
- Processor – Kunpeng 920 processor with 4/8 cores at up to 2.6 GHz
- System Memory – 4x DDR4-2400 UDIMM slots for up to 64 GB RAM
- Storage – 6x SATA 3.0 hard drive interfaces, 2x M.2 SSD slots
- Connectivity – 2x LOM (LAN on Motherboard) NIC supporting Gigabit Ethernet network ports or optical ports
- USB – 4x USB 3.0 and 4x USB 2.0 ports
- Audio – Combo with 3x 3.5mm audio jacks
- Serial – DB9 connector
- Expansions – 1x PCIe 3.0 x16, 1x PCIe 3.0 x4, and 1x PCIe 3.0 x1 slots
LOM Network Ports - Misc – RTC
- Power Supply – 20-pin ATX connector
The board supports Linux desktop operating systems, and Huawei can provide reference designs for the chassis, heat dissipation solution, and power supply. The Kunpeng Desktop Board is said to be compatible with mainstream hardware such as memory, hard drives, and network interface cards, but somehow there’s no mention of graphics card support. I suppose some will work, as it would be hard to make a desktop PC without video output…
They also offer some metrics for performance, reliability and power efficiency with “56 Gbit/s high-speed SerDes (HSS) for 25% higher motherboard performance”, a “signal bit error rate (BER) lower than 10-12 for 15% fewer failures than the industry average” and an “Innovative Dynamic Energy Management Technology (DEMT) for over 15% better efficiency than the industry counterpart”. Those claims are rather meaningless, as I have no idea what they are comparing their motherboard to.
There may be a bit more information on the product page, but so far we don’t have any details about availability nor pricing. You can request pricing, but you’ll need to leave your contact details, and provides a project summary and your budget.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I’m always worried about mainline (hence longterm) support when it comes to unknown chips. It’s already a pain for well known ones…
This is alleviated by building towards the SBSA and SBBR spec. The hardware can use drivers that are already in mainline. There are some issues with how to express some hardware designs within these specs and SolidRun and NXP are actively working with arm to address them, not in a one off way, but in a way that can be used as a common solution for more boards. As for device-tree initial support for the HoneyComb was added in the 5.6 release. Initial patchsets for the LX2160a support are submitted to the tianocore mailing list for review to be included in edk2-platforms.
I’d love something like that so much, and can’t afford it even more probably. Why isn’t this mainstream yet? I just don’t get the X86 dominance. It are just very wasteful radiators. Trading of hundreds of watts for a few megahertz more. Doesn’t seem logic to me.
>I just don’t get the X86 dominance.
Are you going to pay a massive premium to save a few cents off of your electricity bill while hobbling yourself with a machine that’ll never quite work right just so you can say your machine runs 100% vegan instructions?
It is not just the power consumption of the board in the server its-self but the power consumption for all the air conditioning to keep cooling the tens/hundreds/thousands of servers in the machine room(s) at a good operating temperature. It is not just vegans who are concerned about climate change.
>It is not just the power consumption of the board in the server its-self
>It is not just vegans who are concerned about climate change.
The problem this sort of climate change thinking is that even if everyone stopped generating CO2 right now there would be very little real effect. Climate change would continue happening because of all of the CO2 that has been added to the atmosphere over the last century of industrial activity.
The CO2 saved by replacing all of your X86 machinery with vegan instruction processing yet totally unserviceable ARM machines that will probably be discontinued in 6 months will be little more than background noise.
All the SOCs we use are embedded spec. That means the minimum life span the board will be produced is 7 years.
Interesting. I don’t understand why they don’t use a socket in this case. Would make sense to replace the processor in case something is broken. Btw: What is the price for the board and when does it get mainline support?
Your question is very interesting because it raises the problem there is with ARM machines: they were always designed for embedded devices and as such it is required to implement functions for all of the SoC’s devices which vary from chip to chip. In the x86 world this problem doesn’t exist, you pick any x86 chip provided that it’s compatible with your socket, you plug it and everything magically works. The difference is that:
– in x86 world we actually don’t change the SoC components, just the cores and the memory controller.
– the other auxiliary components are enumerated by the board (PCI, ACPI, EFI etc) so there is no need to declare a new CPU+components device just so that it works.
Some x86 devices (atoms) are indeed SoCs but they’re embedding enumerable parts that are usually on board and already well supported/enumerated. So they work out of the box just as if you had a pluggable CPU.
The ARM world really needs to make progress in this direction before it can ever succeed in the server/workstation world. As long as an unknown vendor’s CPU will not be able to boot out of the box on a moderately up-to-date kernel, there is no hope for it to succeed. For the 3 years it takes to get the SoC properly supported, it is totally outdated. Who nowadays wants to buy a Thunder CPU for example ? Likely for the same price you get half the number of cores and 4 times the performance using a mid-end Xeon, and maybe double this with a Ryzen.
If there was an “official” basic setup for ARM like there is for x86 (i.e. basic memory controller setup, fixed addresses for the basic I/O, to allow any generic device to boot till the point it can enumerate what’s on board and load device-specific drivers), it would dramatically change the way things are.
Just like ARM managed to normalize instruction sets and extensions using their Cortex line (we don’t need to care as much about NEON/vfpv3-d16/idiv support etc nowadays), they should probably create a higher-level product family becoming a standard, which involves using this or that IP for UART, PCIe controller, memory controller, flash controller etc so that any vendor’s CPU can boot a generic kernel.
Getting vendors just to stick to a single UART IP and not rolling yet another broken 8250 clone would be a start.
Issue you talking about has been resolved long time ago for ARM-based server platforms, and recently for ARM-based laptops with ACPI, like my Lenovo Yoga C630 Yoga – you can boot upstream Linux 5.4 on this machine with ACPi alone. Of course for this to happen you have to boot kernel that have all necessary drivers in place, but that also the case for x86-based platforms as well.
ACPI there is basically fancy device tree. You still have totally undocumented magic doing the DRAM setup etc.
ACPI/DT/EFI/whatever don’t solve anything unfortunately because you still need to have the drivers available before they can use these descriptions. The wide diversity of IPs to do the same thing during early boot and the willingness all vendors have to reinvent everything and make sure they are incompatible with their competitors is what is hurting ARM a lot.
Do you realize that in the x86 world each evolution of storage since IDE 25 years ago remained backwards compatible with the previous generation, allowing you to by a fancy new motherboard, and boot in “legacy mode” if your OS didn’t yet have the drivers available ? Any UART remains usable in plain old 8250 mode. Graphic cards continue to support VGA mode and even the CGA mode with the text buffer mapped at 0xB800:0. And the keyboard controller is totally emulated by whatever chip you have on board but it continues to deliver scan codes at 0x60 and to raise IRQ1 when you press a key. This is what boosted this architecture over all competing ones. Users always seek the newest device and know it will work out of the box, even if not optimally at the beginning. Who wants to buy a device that will simply not work, or that will work but will never evolved ? That was the old world of the 80s where you could buy Amstrad, Sinclair, Thomson, AppleII and all such devices that needed to be fully replaced, throwing your programs and operating systems through the window upon each upgrade. All this old world died behind the upgradable and evolving PCs. ARM lives in parallel only because it’s installed in disposable consumer devices and has the benefit of power consumption in this performance range.
>the willingness all vendors have to reinvent everything
If only it was just “not invented here”. Vendors take literally the same IP for stupid things like the designware uart and intentionally break it by moving the registers or bit locations around. I can’t think of a single good reason to do that other than a poor attempt to hide that the IP is stolen.
This is split into two issues. The main specifications for Arm Server Ready do cover generic interfaces for most buses. Serial, UART, PCI, AHCI, XHCI, EHCI. Then for some hardware like networking you do need drivers, if you aren’t using a device that doesn’t already have drivers in Linux, Windows, BSD etc. It needs to be looked at like being able to boot Windows enough to then install the additional drivers you need for other components, but you can easily install them because they are expressed in a consistent manner via ACPI descriptors, and already setup in a sane way regarding clocks and regulators by the EFI firmware.
This is why we used the Com Express Type 7 form factor for the SOC. This is a standard SOC / CPU to board connector, so you can just replace the compute part of the board.
Wait, where’s the video output?
On one of the graphics cards you insert into any of the PCIe slots. Good luck with drivers!
AMD is the way to go. They are actively contributing to the OSS drivers in the kernel and mesa. Obviously no graphics company is going to release a graphics driver suite if there isn’t a platform for their cards. https://www.techradar.com/news/amd-looks-to-court-linux-gamers-by-making-its-gpu-driver-even-better