Diversity of options is a longer-term tradeoff; it is more expensive in the short term, agreed, but it helps keep the industry from getting stuck in a rut. If you like, it keeps us from getting stuck in local minima, albeit at the cost of not getting to use local minima.
Not really, at least until end users are buying ARM machines. But honestly, I think this bit is overplayed. An extreme majority of modern developers writing software that runs on consumer computers are not writing assembly language, and most of them aren’t even writing code in languages that compile AOT to machine code. I’d argue most of the things people use nowadays run in the browser.
Desktop isn’t even the hot new thing anymore, mobile is (or, at least, was.) Ans as fate would have it, mobile platforms are dominated by ARM already. Many modern developers already deal with ARM as it is.
Going further down the rabbit hole, I’d argue that most applications aren’t even nearly CPU bound and would run just fine with emulation, and nobody will bat an eye. This isn’t really theoretical, considering there exists x86 emulation in ARM Windows 10.
And finally, most open source software already runs on many architectures, just look at how many architectures Debian supports.
It does increase load on developers, but not to a degree that would make the benefits to competition unworthy. I think a good amount of developers are capable enough to figure out how to cross compile.
Architectural splits are not new. Apple did it twice already with Mac, and while there’s no evidence of a third one on the horizon yet, it’s certainly not beyond them.
And hell, maybe in the future, developers largely won’t ship architecture-dependent binaries. It is yet to be seen what might happen with WebAssembly and similar technology.
> Not really, at least until end users are buying ARM machines
How do you address the problem caused by the combinatorial explosion of adding a whole new ISA to the OS*distribution combination of platforms that need to be targetted, tested for, and debugged?
It’s been largely solved, for Linux distributions. Many of them have supported a wide array of architectures for a long time.
This is a pretty theoretical problem and wreaks of slippery slope fallacy. How many CPU architectures have even come close to desktop usability in the past 10 years? Even prospect wise I basically only see ARM and RISC-V on the horizon. A combinatoric explosion is unlikely, very unlikely.
I already kind of went over this, but I’ll reiterate:
WebAssembly is a good example of a technology that has the potential to kill two birds with one stone and unify both architectures and OSes. Web browsers are Not the only environment WebAssembly runs in.
Folks writing software in .NET, Python, Java, JS already don’t have to worry about this. They already aren’t dealing with architectures, mostly.
A lot can be done with emulation when performance is not a primary concern. Windows 10 already has x86 emulation for ARM. On Linux Qemu user mode is pretty mature (and is already used for things like setting up ARM chroots on x86 boxes.)
And then you end up requiring a binary-only library, or can't upgrade with the whatever PCI-e device because no drivers and that's the end of the ARM adventure...
I write software that ports to numerous processors. It's a non-issue. Only issues I've ever seen are casts that break the C spec, and those are ugly anyway. Casts to unaligned boundaries can cause SIGBUS on ARM. Otherwise multiarch is only hard if you are doing SIMD.
If you are working in a higher level language it's a total non-issue. You will not notice.
Porting is not necessarily the issue. As Linus pointed out earlier in the year, platforms that aren't native to the developer generally have issues that fall through the cracks. I recommend you look up the series of posts that CloudFlare did when reviewing the Qualcomm server. There are many obvious optimizations that are just not done because currently all the ARM hardware is targeted at small embedded applications. I have run into many others since I started running benchmarks on the HoneyComb.
Because if we don’t have any architecture competition, innovation is limited to what can be done while remaining compatible with IBM PC DOS. There should be competition. The Intel-compatible monoculture is a bug, not a feature.
>Do we need 16-core PIC16 Mini ATX workstation too?
Now this is just garbage. I doubt you are really ignorant enough to believe modern ARM cores are effectively in the same class as PIC16.
But honestly, unless you have a vested interest in the failure of non-Intel-based architectures, then what do you care? Why the intellectual hostility? Why are we asking “why” instead of “why not?”
> Do we need 16-core PIC16 Mini ATX workstation too?
If it were usable for my workloads (running *nix, basically), I would absolutely love that. ...I admit, I'm struggling to think how to scale PIC up that much, and IIRC doesn't it use Harvard architecture? That'd be a struggle. But anyways, yes, if we could make it work then that would be beautiful.
How so ? Brandishing "diversity" as the epitome of progress is close to nonsensical.
My workstation requires 4 4k output, both HDMI 2,0 and display-port, and decent OpenGL & other hardware accelelation support. There is no way I'm ever going to get this working out of the box with a fancy architecture. Yes, I'm using proprietary binary-only software, but I my line of work involve CAD+CAM, not re-invent the wheel.
Even industrial system I'm working on right now will use standard off-the shelf part (read x86 or rasppi-like sbc) and STANDARD interfaces, because I don't want to lock myself with a vendor. If the main system crash, I can replace it within 12h with a crappy old system and limit downtime.
You don’t have to buy this new system. You may continue buying whatever hardware you already buy, effective immediately, indefinitely. I didn’t realize my Hacker News comments had power to prevent folks from doing that to begin with!
> Brandishing "diversity" as the epitome of progress is close to nonsensical.
Man, it really sounds like you have some things you might want to talk about with a therapist. I haven’t even used the word “diversity” that I can find.
All I’m suggesting is maybe an instruction set design that has cruft going back decades might actually not be the global maximum of ISA design, and that there might be real gains by trying to apply modern high-performance processor engineering to a different application ISA.
That’s it. The market gets to decide if another ISA will hit critical mass. This is not especially likely for the most part, but I definitely support the research.
I’m sorry for all of the snark but really, I am blown away at some of the responses this has garnered. I hope you all realize that this machines existence is not a threat to basically anyone.
> ... as long as everybody does cross-development, the platform won’t be all that stable. Or successful ... If you develop on x86, then you’re going to want to deploy on x86 ... It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over.
I'm also wondering how the BIOS/UEFI equivalent on these machines works--I really hate how the Raspberry Pi does it (boot partition on SD card contains all data).
The COM Express 7 module, has SPI-NOR for booting, a second SPI for UEFI secure variable storage, and eMMC for an embedded or recovery OS. Other than that you can boot your distro from eMMC, USB, Sata, or NVME.
Between the official boot firmware not being UEFI compatible and not being onboard it means you have to create a custom installation image and apply it to the disk rather than grabbing a generic installer and going. Also you need to do this for each bootable media you wish to create rather than once (and update each).
Philosophically, I actually like the RPi approach (ie. a simple image with device tree) a lot more than ACPI/UEFI. ACPI involves a whole super privileged virtual machine with byte code from god knows where, whereas device tree gives more or less complete control over to the kernel image (sure PSCI is a thing, but that's a lot more defined WRT boundaries to me than ACPI).
Basically an ACPI system is a lot easier to bootstrap because you don't need to support all of the little subcomponents of the board explicitly, but once you supprt devoce tree, you support the board in a much more complete and meaningful way, and it's truly your kernel running the show.
At work we just got an aarch64 box from a vendor that has a very x86-like UEFI setup. Right down to the "BIOS" setup screens. It was very familiar seeming, but I'd rather have something like coreboot.
Coreboot only handles low-level initialization, it will still need a higher level payload unless you're going to hardcode your kernel to the board for every update.
Now, coreboot+tianocore uefi for somewhat open firmware...
Apparently they are going for SBSA, which means it will have proper UEFI implementation, including possibly ACPI, so you will have normal UEFI experience.
Yeah, it has several coprocessors and operating modes below the operating system. But I don't see any docs on the openness of their firmware. And FWIW, any chip this complicated borderlibe requires a management Co processors as the main cores are way too power hungry for a lot of tasks, and need a lot of babysitting to initialize fully. The Cell processor in the PS3 is architecturally a SPI slave for instance.
Yeah, the term to search for is "configuration ring". It's the big shift register of most of the stuff you need to baby sit in order to bring up the Cell.
If you are looking for cheap open hardware, there are not that many options around. Last practical one was the Asus C201PA with Rockchip ARM. The only closed component was the wireless chip, and that's easy to fix with a little Atheros dongle.
I'd love to hear about other alternatives if you know any.
SolidRun CSA here. The SOC by itself will run with a fully OSS firmware, either u-boot or edk2. We are working on SBSA compliance and hope to have that ready for the production run of SOCs. While the entire device can be run with fully OSS firmware there will be some missing functionality. There are some configuration pieces for SERDES lanes that is handled by the microcode in the SOC. There is a binary firmware that is needed for the high speed networking. We are still discussing with NXP how this will evolve going forward.
For a management interface we have integrated what we call a micro-BMC. It is an STM MC, that is wired up to power up/down, thermals, and can reflash the SPI-NOR chip for recover and firmware updates out of band. This is a technology we are working on so the BMC can act more as an IoT gateway to handle many boards, vs each board needing to manage security individually. This chip is fully unlocked and open for developers to play around with.
Sounds like the pre-production board is for people who can't wait until a production board with mainline Linux support is available:
> The pre-production developer board is fitted with NXP LX2160A pre-production silicon which explains some of the limitations. [...] software features will be limited with the lack of SBSA compliance, UEFI and mainline Linux support. It will support Linux 4.14.x only.
BTW, would be nice if the production board had Coreboot support, whether or not it has UEFI by default.
In the comments, the company responds: "I have asked marketing and sales to update that copy. Those versions are target shipping software, which is actually bumped on the developer board as NXP has just released a 4.19 based BSP. These boards will be fully supported by all mainline support that progresses."
Coreboot isn't immediately on our radar. We have both u-boot and EDK2 running, although EDK2 needs more work.
Mainline support for the SOC is already making it into mainline and we can boot a mainline kernel with limited functionality. Getting anything into mainline is a process, but we hope to have everything supported by the end of the year.
If they manage to get SBSA support then they will need UEFI by default. Doesn't mean they couldn't use Coreboot as a first stage loader with an EDK2 payload for all the EFI bits.
Holy hell, they dropped the price on that thing pretty quick! I think you could originally only get the $700 price tag for Xavier via the "developer discount", which only applied to one unit.
As a word of note, though, the chips in the Tegra machines are, IME, extremely powerful -- but you're stuck with Linux 4 Tegra and Nvidia's Ubuntu-based distro. At least for the TX1 there was some success getting other distros working (without GPU) but I remember several people running into trouble with the TX2. That may or may not be a dealbreaker for some people (it's a sort of franken-Ubuntu and your only hope for problems are the Nvidia forums)
The Solid Run LX2K machine however should (eventually) run any standard AArch64 distro. They also have 16 cores and expandable SATA, as well as an open PCIe 4x slot on these boards, so you can install whatever GPU you like onto it. Not to mention you can plug in a bunch of RAM. You can even buy a slightly different variant of this board with a 100GigE cage on it, still under $1000 USD, which puts it in a very unique position vs any other I've seen.
I think the LX2K boards are (now, at this point in time!) a much better sell if you want an actual "arm workstation" as a developer. But the Xavier will be vastly superior if you want a lower power profile (mobile) or if you're doing something like DL inference.
You can install whatever GPU you like, but good luck getting aarch64 drivers for it. IMO franken-Ubuntu on Xavier is pretty close to stock, save for CUDA and a few Jetson-specific tools. Certainly close enough to be practical. And you get Pascal-grade CUDA and tensor cores on the Xavier, too. And PyTorch works as well.
Why would that be an issue? People already have Mesa and AMDGPU working fine on non-x86 architectures (people have demoed physical POWER, RISC-V and AArch64 machines, all with various Radeon GPUs and the newer AMDGPU stack) and the support gets better and better every release. But it already works fine.
Also, Franken-Ubuntu I suppose isn't really my complaint, though I still don't like it. It goes beyond that, though -- the Tegra boards have very custom design that means some things are a huge pain in the ass if you want to even remotely treat them like "normal" computers (for example, want to test that fancy driver you wrote on your AArch64 Tegra machine for that M.2 peripherial? well first you gotta reconfigure the BSP firmware to turn off the power rails to various subcomponents so you can reroute them to things like the M.2 E key slots in the TX2. Gotta disable that USB controller via BSP flash if you want a chip in there, etc etc). It also means I am basically stuck on older kernel versions which may mean features I want to use or develop with are basically off limits (eBPF enhancements, io_uring, etc.) I don't just want to test SIMD; I also need to test actual memory/disk/peripherials, etc. These constraints make perfect sense for Tegra devices -- they are still annoying, for me.
I'm not saying the Tegra machines are not nice, or they are not high quality. They absolutely are. If you are just writing code to give the CPUs some work to do, they are great! Flash the default BSP, plug in HDMI, run 'gcc'. They're the highest performing ARM machines for their power profile and size, IME. But the moment you treat them like an "ordinary" computer, all bets are off. These LX2K machines act substantially more like "ordinary" desktop computers, and IMO that's a significant benefit.
Now, if you want to do DL inference or GPU programming, I think CUDA is vastly better (for a number of technical reasons). And the Tegra machines would be a good choice! But if you're just writing ARM code and need a desktop, these machines seem perfectly sufficient and can host open source drivers just fine, and will be far more usable in a number of ways vs a Tegra machine.
(And also: Nvidia also released some press notes last month that they would be bringing the full CUDA stack to ARM for data-center computing, presumably, including the host driver. So it's possible you may be able to stick a Quadro into these things soon enough and use CUDA to your hearts content!)
If what you are doing only revolve around "writing code to give the CPUs some work to do", then a $30 Rasp-Pi will work just as good.
Also 99.999% of people want to "use" software, very often proprietary one, not re-invent the wheel. No matter what, this kind of product will be a niche, by an overwhelmingly large margin.
That I do agree with. I wanted to buy an ARM machine to do CI for one of my clients, and currently the only real option for that seems to be Cavium ThunderX. And pricing is way out there in the stratosphere for what you get. Instead I could see them deploying a few of these for a fraction of the cost.
The PCIe slot is actually 8x. Right now we are targeting AMD Polaris based GPUs for support, just because their power consumption fits well with this SOC. AMD just announced their PRO 3200, which is really a match made in heaven. I just wish they had include SR-IOV on that model so you could get VM acceleration as well.
As for Xavier it is a good platform, but you in many benchmarks the HoneyComb LX2K is way out in front. Then adding in the 10Gbps networking and storage.
Native development on ARM instead of cross-compling, for example. When you reach a certain point down the stack, the machine you develop for/on matters a lot more.
Whatever developers want to use it for. It has storage, highspeed networking, 16-cores all in a 32W TDP. We are excited to see what uses the community and our customers come up with for it.
Absolutely. The HoneyComb is targeted as a developer workstation / desktop. The ClearFog CX LX2K is the higher end board aimed at networking and edge compute applications. We are collaborating with most the major distributions making sure we will have the board fully supported as soon as possible.
63 comments
[ 3.1 ms ] story [ 135 ms ] threadDesktop isn’t even the hot new thing anymore, mobile is (or, at least, was.) Ans as fate would have it, mobile platforms are dominated by ARM already. Many modern developers already deal with ARM as it is.
Going further down the rabbit hole, I’d argue that most applications aren’t even nearly CPU bound and would run just fine with emulation, and nobody will bat an eye. This isn’t really theoretical, considering there exists x86 emulation in ARM Windows 10.
And finally, most open source software already runs on many architectures, just look at how many architectures Debian supports.
It does increase load on developers, but not to a degree that would make the benefits to competition unworthy. I think a good amount of developers are capable enough to figure out how to cross compile.
Architectural splits are not new. Apple did it twice already with Mac, and while there’s no evidence of a third one on the horizon yet, it’s certainly not beyond them.
And hell, maybe in the future, developers largely won’t ship architecture-dependent binaries. It is yet to be seen what might happen with WebAssembly and similar technology.
How do you address the problem caused by the combinatorial explosion of adding a whole new ISA to the OS*distribution combination of platforms that need to be targetted, tested for, and debugged?
This is a pretty theoretical problem and wreaks of slippery slope fallacy. How many CPU architectures have even come close to desktop usability in the past 10 years? Even prospect wise I basically only see ARM and RISC-V on the horizon. A combinatoric explosion is unlikely, very unlikely.
I already kind of went over this, but I’ll reiterate:
WebAssembly is a good example of a technology that has the potential to kill two birds with one stone and unify both architectures and OSes. Web browsers are Not the only environment WebAssembly runs in.
Folks writing software in .NET, Python, Java, JS already don’t have to worry about this. They already aren’t dealing with architectures, mostly.
A lot can be done with emulation when performance is not a primary concern. Windows 10 already has x86 emulation for ARM. On Linux Qemu user mode is pretty mature (and is already used for things like setting up ARM chroots on x86 boxes.)
If you are working in a higher level language it's a total non-issue. You will not notice.
>Do we need 16-core PIC16 Mini ATX workstation too?
Now this is just garbage. I doubt you are really ignorant enough to believe modern ARM cores are effectively in the same class as PIC16.
But honestly, unless you have a vested interest in the failure of non-Intel-based architectures, then what do you care? Why the intellectual hostility? Why are we asking “why” instead of “why not?”
I like ARM. I would buy this machine.
If it were usable for my workloads (running *nix, basically), I would absolutely love that. ...I admit, I'm struggling to think how to scale PIC up that much, and IIRC doesn't it use Harvard architecture? That'd be a struggle. But anyways, yes, if we could make it work then that would be beautiful.
Indeed it does. PIC32, on the other hand, doesn't.
My workstation requires 4 4k output, both HDMI 2,0 and display-port, and decent OpenGL & other hardware accelelation support. There is no way I'm ever going to get this working out of the box with a fancy architecture. Yes, I'm using proprietary binary-only software, but I my line of work involve CAD+CAM, not re-invent the wheel.
Even industrial system I'm working on right now will use standard off-the shelf part (read x86 or rasppi-like sbc) and STANDARD interfaces, because I don't want to lock myself with a vendor. If the main system crash, I can replace it within 12h with a crappy old system and limit downtime.
> Brandishing "diversity" as the epitome of progress is close to nonsensical.
Man, it really sounds like you have some things you might want to talk about with a therapist. I haven’t even used the word “diversity” that I can find.
All I’m suggesting is maybe an instruction set design that has cruft going back decades might actually not be the global maximum of ISA design, and that there might be real gains by trying to apply modern high-performance processor engineering to a different application ISA.
That’s it. The market gets to decide if another ISA will hit critical mass. This is not especially likely for the most part, but I definitely support the research.
I’m sorry for all of the snark but really, I am blown away at some of the responses this has garnered. I hope you all realize that this machines existence is not a threat to basically anyone.
> ... as long as everybody does cross-development, the platform won’t be all that stable. Or successful ... If you develop on x86, then you’re going to want to deploy on x86 ... It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over.
Basically an ACPI system is a lot easier to bootstrap because you don't need to support all of the little subcomponents of the board explicitly, but once you supprt devoce tree, you support the board in a much more complete and meaningful way, and it's truly your kernel running the show.
Now, coreboot+tianocore uefi for somewhat open firmware...
That's very interesting. Why did they build it like that? Do you have more information on this?
I'd love to hear about other alternatives if you know any.
For a management interface we have integrated what we call a micro-BMC. It is an STM MC, that is wired up to power up/down, thermals, and can reflash the SPI-NOR chip for recover and firmware updates out of band. This is a technology we are working on so the BMC can act more as an IoT gateway to handle many boards, vs each board needing to manage security individually. This chip is fully unlocked and open for developers to play around with.
> The pre-production developer board is fitted with NXP LX2160A pre-production silicon which explains some of the limitations. [...] software features will be limited with the lack of SBSA compliance, UEFI and mainline Linux support. It will support Linux 4.14.x only.
BTW, would be nice if the production board had Coreboot support, whether or not it has UEFI by default.
Mainline support for the SOC is already making it into mainline and we can boot a mainline kernel with limited functionality. Getting anything into mainline is a process, but we hope to have everything supported by the end of the year.
As a word of note, though, the chips in the Tegra machines are, IME, extremely powerful -- but you're stuck with Linux 4 Tegra and Nvidia's Ubuntu-based distro. At least for the TX1 there was some success getting other distros working (without GPU) but I remember several people running into trouble with the TX2. That may or may not be a dealbreaker for some people (it's a sort of franken-Ubuntu and your only hope for problems are the Nvidia forums)
The Solid Run LX2K machine however should (eventually) run any standard AArch64 distro. They also have 16 cores and expandable SATA, as well as an open PCIe 4x slot on these boards, so you can install whatever GPU you like onto it. Not to mention you can plug in a bunch of RAM. You can even buy a slightly different variant of this board with a 100GigE cage on it, still under $1000 USD, which puts it in a very unique position vs any other I've seen.
I think the LX2K boards are (now, at this point in time!) a much better sell if you want an actual "arm workstation" as a developer. But the Xavier will be vastly superior if you want a lower power profile (mobile) or if you're doing something like DL inference.
Also, Franken-Ubuntu I suppose isn't really my complaint, though I still don't like it. It goes beyond that, though -- the Tegra boards have very custom design that means some things are a huge pain in the ass if you want to even remotely treat them like "normal" computers (for example, want to test that fancy driver you wrote on your AArch64 Tegra machine for that M.2 peripherial? well first you gotta reconfigure the BSP firmware to turn off the power rails to various subcomponents so you can reroute them to things like the M.2 E key slots in the TX2. Gotta disable that USB controller via BSP flash if you want a chip in there, etc etc). It also means I am basically stuck on older kernel versions which may mean features I want to use or develop with are basically off limits (eBPF enhancements, io_uring, etc.) I don't just want to test SIMD; I also need to test actual memory/disk/peripherials, etc. These constraints make perfect sense for Tegra devices -- they are still annoying, for me.
I'm not saying the Tegra machines are not nice, or they are not high quality. They absolutely are. If you are just writing code to give the CPUs some work to do, they are great! Flash the default BSP, plug in HDMI, run 'gcc'. They're the highest performing ARM machines for their power profile and size, IME. But the moment you treat them like an "ordinary" computer, all bets are off. These LX2K machines act substantially more like "ordinary" desktop computers, and IMO that's a significant benefit.
Now, if you want to do DL inference or GPU programming, I think CUDA is vastly better (for a number of technical reasons). And the Tegra machines would be a good choice! But if you're just writing ARM code and need a desktop, these machines seem perfectly sufficient and can host open source drivers just fine, and will be far more usable in a number of ways vs a Tegra machine.
(And also: Nvidia also released some press notes last month that they would be bringing the full CUDA stack to ARM for data-center computing, presumably, including the host driver. So it's possible you may be able to stick a Quadro into these things soon enough and use CUDA to your hearts content!)
Also 99.999% of people want to "use" software, very often proprietary one, not re-invent the wheel. No matter what, this kind of product will be a niche, by an overwhelmingly large margin.
That I do agree with. I wanted to buy an ARM machine to do CI for one of my clients, and currently the only real option for that seems to be Cavium ThunderX. And pricing is way out there in the stratosphere for what you get. Instead I could see them deploying a few of these for a fraction of the cost.
As for Xavier it is a good platform, but you in many benchmarks the HoneyComb LX2K is way out in front. Then adding in the 10Gbps networking and storage.