AMD Announces Its First 64-bit ARM Server CPU

[znby]

Unless I'm missing something, only thing I'm not liking about this is that they are using UEFI on ARM... don't Microsoft disallow UEFI secure boot to be disabled?

For x86 systems they require that users have the option to turn it off, on ARM tablets its forced to stay on. This is only to be certified as ready for Windows 8, for Linux servers, this doesn't count.

[Nille]

ARM is very slow at heavy tasks. Also, what about software compatibility?

Look at the Intel CPUs, Atom vs i7. Its not a Problem to Design a ARM CPU for heavy Numbercrunching.

[DrYak]

ARM is very slow at heavy tasks. Also, what about software compatibility?

Software compatibility: what compatibility problems are you referring to?

This hardware platform targets servers, and runs on Linux.
It's the enterprise-grade equivalent of all the small home fileservers running an embed linux on ARM or on MIPS.

On Linux, supporting a new CPU platform is mostly only a recompile away, due to most source being available.
Other distributions too have supported various flavors of ARM (OpenSuse has been shown running on ARM netbooks, Debian has an ARM spin too, etc.)
The only thing that won't run as-is on it are binary-only software, which nowadays is mostly Flash. And nobody in their right ming needs flash on a file server.

So 99% of linux software already runs on this platform (Once Fedora's compile farm finishes compiling it :-) ), for the 1% of the remaining (very probably: some proprietary network filesystem stuff, like some cluster filesystems which are used in enterprise settings, but weren't used in small home contexts before, and which are binary-only distributed): support will come very soon.

On Linux, switching CPU architecture is almost trivial.

What has Microsoft to do with it? Microsoft doesn't has a OS for Server ARM SoCs and the manufacturer has to choose the UEFI Settings. If a manufacturer that the SoC for Windows RT then he has do lock Secureboot to a Microsoft Only key.

And given the HW specs, AMD are absolutely NOT targeting the tablet/netbook market. So Windows RT is definitely not a target.
(Also, I don't know if microsoft has 64bits variant of their Windows for ARM. So it might not even been possible to deploy Windows on this even if you wanted to.
Compare with the linux situation above: that's the open-source vs. binary-only difference for you).


I personally think that this is a very interesting hardware platform, one that I would definitely like to investigate for future low-power server.

[chithanh]

The CPU itself appears to be very interesting. What is totally lacking from the announcement is whether it has any (OpenCL) compute capabilities on its own, besides the Open CS Common Slot.

The developer board has some upsides (yay for dual 10GbE) and some downsides (boo for UEFI).

However I think that UEFI is some kind of economic necessity if AMD wants some form of Windows on that platform in the future. For a Linux only board, Coreboot (like on the ARM Chromebooks) or Open Firmware (like on the OLPC XO-1.75 and XO-4) would have been better IMO. I do hope that the platform is open enough so that Coreboot support can come in the future.

[Nille]

And given the HW specs, AMD are absolutely NOT targeting the tablet/netbook market. So Windows RT is definitely not a target.

Right not the Tablet or Netbook Markt, but you can Build more with a ARM CPU.

(Also, I don't know if microsoft has 64bits variant of their Windows for ARM. So it might not even been possible to deploy Windows on this even if you wanted to.

I don't doubt thats a ARM 64bit is a big problem for Microsoft and i astound if Microsoft don't has a internal Build for it.

Compare with the linux situation above: that's the open-source vs. binary-only difference for you).

GNU/Linux has not a problem with CPU Architectures, right, but with a stable Platform or for a stable package deployment. None of the Distros ship older Library Releases for a compatibility with older releases. On the Server or Workstations its mostly not a big deal because you has administrator for that and they can spend there time with it. In the private marked its kills all benefits from the GNU/Linux.

[chithanh]

I don't doubt thats a ARM 64bit is a big problem for Microsoft and i astound if Microsoft don't has a internal Build for it.

I think it is a big problem for Microsoft. When AMD launched AMD64, they waited for Microsoft to become ready with the XP 64-bit edition. Now nobody waits for Microsoft, they have to catch up.

Microsoft certainly has internal development for arm64 going on, but nothing public. No MS compiler outputs arm64 code, no Microsoft virtualization supports arm64 guests, not a single arm64 executable, not even a specification for arm64 PE format.

Windows RT supports three different ARM platforms (OMAP, Snapdragon, Tegra), that is all. Microsoft was unable to even economically justify porting to more platforms like Exynos, MediaTek or Allwinner. Porting to arm64 is a much more challenging.

GNU/Linux has not a problem with CPU Architectures, right, but with a stable Platform or for a stable package deployment. None of the Distros ship older Library Releases for a compatibility with older releases. On the Server or Workstations its mostly not a big deal because you has administrator for that and they can spend there time with it. In the private marked its kills all benefits from the GNU/Linux.

That applies only to people who want to transfer the Windows method of downloading and installing precompiled software from random places on the Internet to Linux distros.

[Nille]

I think it is a big problem for Microsoft. When AMD launched AMD64, they waited for Microsoft to become ready with the XP 64-bit edition. Now nobody waits for Microsoft, they have to catch up.

Who waited? I have buy my first AMD64 CPU before Microsoft Release there Windows x64. By the way, Windows x64 is not only a a 64bit version of Windows. You also has the full 32bit Compatibility. Even on GNU/Linux its still a mess with 32bit and 64bit Packages. Multiarch came many years after the first AMD64 Linux Version.

Windows RT supports three different ARM platforms (OMAP, Snapdragon, Tegra), that is all. Microsoft was unable to even economically justify porting to more platforms like Exynos, MediaTek or Allwinner.

Because thats are SoCs and not only CPUs. The Environments are different and you can not even replace the Software for a Allwinner A10 with the Software from a A12. And the manufacturer release there SoC most for a special Software environment and nothing more. Try to r un on a MediaTek mt8125 a GNU/Linux and notonly a Android 4.2.X/4.3.X. Or on a Allwinner A13.

Porting to arm64 is a much more challenging.

Why? Windows RT is from the Software side not a big difference compared to the x86 Build. If there Compiler support it, its not fair away. The question is the why the should do it.

That applies only to people who want to transfer the Windows method of downloading and installing precompiled software from random places on the Internet to Linux distros.

No, that also is a problem if you use FOSS but don't want to make each upgrade cycle (eg. a Ubuntu 7.04 runs very well on my old Laptop but each later versions runs horrible but i was forced to upgrade to an uglier gnu/linux). As an example. At the end of 2009 there was a new Mumble Version (1.2) They changed the Protocol and i have to Upgrade for 1 App my hole System (there was no release for the 08.04 LTS because of missing qt4). For my Distribution there was no updates Packages. You see same behaver currently with Ubuntu 12.04 LTS. Try to get a new Mesa version, Gimp or Blender .... and Canonical what to support this platform till 2017.

So if i want to use a old or a new application i have to upgrade or downgrade the system or i have to compile it myself. The last way is for the users the worst case. the most ppl don't want to tinker and most times its not possible if you has a long dependency list. Look where Linux is successful and where not and you get an answer. The most successful End-user Linux is probably Android and the user don't mess with dependency's or OS Version.

[GraysonPeddie]

I have a question, though. If I want to go with a new motherboard and have AMD ARM CPU, will my Hauppauge HVR-1250 TV tuner only work with x86 processors or can it work with AMD's ARM CPU? I'm curious because I'm wondering if MythTV could be compiled for ARM architecture.

Not that I'd be switching to ARM CPU with a new motherboard, since I'll still be staying with x86 for a while. ARM in a server is very new and young.

[s_j_newbury]

Who waited? I have buy my first AMD64 CPU before Microsoft Release there Windows x64. By the way, Windows x64 is not only a a 64bit version of Windows. You also has the full 32bit Compatibility. Even on GNU/Linux its still a mess with 32bit and 64bit Packages. Multiarch came many years after the first AMD64 Linux Version.

Multilib/Multiarch works fine on Linux, and has done at least since the beginning of the amd64 port. The only real issues have been lack of a standardized approach as to where to keep the abi-specific libs: lib/lib32/lib64 etc

Because thats are SoCs and not only CPUs. The Environments are different and you can not even replace the Software for a Allwinner A10 with the Software from a A12. And the manufacturer release there SoC most for a special Software environment and nothing more. Try to r un on a MediaTek mt8125 a GNU/Linux and notonly a Android 4.2.X/4.3.X. Or on a Allwinner A13.

"GNU/Linux" works fine on all those SoCs, I'm not sure what you're suggesting here.

Why? Windows RT is from the Software side not a big difference compared to the x86 Build. If there Compiler support it, its not fair away. The question is the why the should do it.



No, that also is a problem if you use FOSS but don't want to make each upgrade cycle (eg. a Ubuntu 7.04 runs very well on my old Laptop but each later versions runs horrible but i was forced to upgrade to an uglier gnu/linux). As an example. At the end of 2009 there was a new Mumble Version (1.2) They changed the Protocol and i have to Upgrade for 1 App my hole System (there was no release for the 08.04 LTS because of missing qt4). For my Distribution there was no updates Packages. You see same behaver currently with Ubuntu 12.04 LTS. Try to get a new Mesa version, Gimp or Blender .... and Canonical what to support this platform till 2017.

These are problems YOU have because your expectations of Ubuntu don't match the reality. That's one of the main reasons why there are many different distributions, maybe there's something out that that would suit you better?

So if i want to use a old or a new application i have to upgrade or downgrade the system or i have to compile it myself. The last way is for the users the worst case. the most ppl don't want to tinker and most times its not possible if you has a long dependency list. Look where Linux is successful and where not and you get an answer. The most successful End-user Linux is probably Android and the user don't mess with dependency's or OS Version.

I'm sorry, but if you want to use the same base system forever, you will be limited in what binaries you can run going forwards, unless you provide a runtime for it. Otherwise, most people will expect that they have to upgrade their OS distribution if they want to run software built for something newer, in which case they don't have to worry about dependencies at all since the package manager will take care of them. This isn't really any different to the situation for Windows or OSX, you can't just expect new Windows software to work on XP, which is a battle Microsoft has been fighting for a while since expectations seem to be different: http://www.infoworld.com/t/microsoft...eadline-235035

[Nille]

Multilib/Multiarch works fine on Linux, and has done at least since the beginning of the amd64 port. The only real issues have been lack of a standardized approach as to where to keep the abi-specific libs: lib/lib32/lib64 etc

Or short not available. i remember the ugly ia32 packages.

"GNU/Linux" works fine on all those SoCs, I'm not sure what you're suggesting here.

Where can i get the Image for the A13?

These are problems YOU have because your expectations of Ubuntu don't match the reality. That's one of the main reasons why there are many different distributions, maybe there's something out that that would suit you better?

I can reproduce the same problems on Fedora oder Suse. But i understand Ubuntu is Bad .....

I'm sorry, but if you want to use the same base system forever, you will be limited in what binaries you can run going forwards, unless you provide a runtime for it.

Not for forever but more as 5 Years without trouble would be fine. MacOS has no Problem with that an Microsoft too. A 13 years Old XP can run without problems new Software.

Otherwise, most people will expect that they have to upgrade their OS distribution if they want to run software built for something newer, in which case they don't have to worry about dependencies at all since the package manager will take care of them.

A Upgrade is not the Big Deal in most cases. But its a Problem if i have to do is all 6-12 Month and dont have the option to run a Package because the new Version miss a feature or the Protokoll has changed.

This isn't really any different to the situation for Windows or OSX, you can't just expect new Windows software to work on XP, which is a battle Microsoft has been fighting for a while since expectations seem to be different: http://www.infoworld.com/t/microsoft...eadline-235035

If the Software claim to run under XP then i can expect it. And i don't demand 10 years or more but the current situation make GNU/Linux unusable for the manufacturer to Build Products that compete against Windows or MacOS.
I have a Mac with max OSX 10.6 and can use current Software without Trouble and this OS version is from 2009.