andreiw

- You need to fix your flaccid dev community. Your forums have a terrible S/N ratio. IRC may be great and all, but I don't see any hard documentation behind any design discussions or development. I do see crazy shite like "can I run ReactOS on Playstation 2". The forums make your project seem dead, which it clearly isn't.

- You need to fix your flaccid dev community. It needs a larger presence. It needs to be tangible (who is doing what? who are the people? do you have conferences?)

- You need to fix your flaccid dev community. There is a bunch of really useless, out-of-date, confusing and out-right self-inconsistent information on building ROS, and the Git move didn't help (but kudos on the move, it is long overdue). I've tried 4-5 times to do something, but the directions I followed on Win, Ros or Linux all ended up breaking somewhere.

- You need to fix your attitude problems (or your forums). There are people asking reasonable questions, who get actively or passively aggressive answers. Not good.

- You need to fix your toolchain problems. This whole SEH thing is getting out of hand. Does Clang support SEH yet? It might - https://clang.llvm.org/docs/MSVCCompatibility.html. So maybe you need to bail on GCC, or maintain your own fork of it (yes, it's ridiculous that GCC still doesn't have SEH support, and the patents have long expired).

- You need to get a grip on x64 support. Your toolchain problems cannot be a gate (and you can clearly use MSVC for building... so...). IA32 support is great and all, but needs a back seat to x64.

- You need to get a grip on UEFI booting (note UEFI booting does not /necessarily/ mean you need improved ACPI support, in practice)

- SMP?

- Forget Xbox, NewWorld PowerMacs (those were BE anyway) and 32-bit Arm chips (which outside of the Pi are too varied and too few). Targeting 64-bit Arm chips does make sense, though, now that Microsoft has released a client build of Win 10 on laptops and an Arm server vendor demoed Windows Server at OCP'18 (http://www.opencompute.org/assets/Uploads/18150J-Ampere-PPT-...). You will need UEFI and reasonable ACPI support to support ARM64. You can target SBSA and SBBR compliant systems and this will give support for the entire server ecosystem (and qemu VMs, har har).

- You might wish to minkernel-ize ROS as well, so you can boot without a GUI.

- You might wish to update Wiki (and build a list of links to relevant pages) for active subprojects.

ReactOS is a usable Windows NT 6+ clone, with kernel ABI ( driver ) compat, that runs real software. What are you comparing it to, to be able to qualify the speed of its development?

Intel’s position amounts to cage rattling and vague insinuations that efficient execution of x86 code is impossible without hardware support. That’s nice, and their ham-fisted approach already hurt customer choice in the past (Transmeta and nVidia Denver, before the later implemented the Arm ISA) but the Windows on Arm solution is completely software and not coupled to any specific Arm chip implementation.

How about FX!32 or it’s latest AArch64 cousin seen on Windows 10?

Of the above, qemu can target x86 and run on anything, Virtual PC ran originally on PowerPC, and FX!32 ran on the Alpha

This is a 64-bit UEFI firmware for RPi3 that uses ATF for PSCI, and has USB, HDMI and SD card support. It has been successfully booting FreeBSD, SUSE Leap 42.3 and Ubuntu 18.04.

In case you don’t, please support gapless playback. It’s an obvious feature for concerts and live performances, and a lot of software (e.g. whatever Ubuntu uses) doesn’t handle it at all.

I always wanted to go the other way - being able to cast video into my head unit, like a phone. I read that MirrorLink is inherently VNC and USB networking. Does anyone have a MirrorLink «server» stack that can run on a board with OTG?

UART?

https://developer.arm.com/support/security-update

The Meltdown/Spectre class of attacks affect certain CPUs. Spectre is a microarchitectural attack on any CPU that does speculation and uses data caches, regardless of architecture.

Arguably, it has been handling Meltdown and Spectre in a much much more humble and transparent way. See https://developer.arm.com/support/security-update/compiler-s... for work they are doing with the compiler communities to address the Variant 1 both on current and future chips.

In many ways, spectre is one more kind of attack on code that doesn’t properly separate validating untrusted input from acting on that input, except unlike overruns and TOCTOU races, this is microarchitectural.

I’d go as far as saying Arm servers are compatible to x86 designs at a platform level (eg. how PCIe and config space are wired up, how caches and DMA work, NUMA, SMP, MSI(X), and so on....

That has been true only for the embedded and mobile space.

The server space is exactly being made open and compatible between SoCs (in the same way AMD and Intel machines are). Platform crud (i2c, gpio, i2c, clock trees and pinnmuxes) is hidden in firmware behind ACPI, PSCI and UEFI just like on x86. SBSA and SBBR specs mandate stringent compatibility requirements. Machine error handling is firmware-first. IO is basically PCIe now.

For an OS vendor or an IT guy these machines look almost exactly like an x86 box. And then they look the same between the Arm vendors too.

Does this mean Windows IoT 64-bit on Arm edge gateways? Is SBSA and SBBR mandatory?

How does this contrast with Google IoT Core on the Marvell A8040-based Clearoud (https://www.solid-run.com/clearcloud-cloud-iot-core/)?

RHEL requires 64k base page size, which AFAIK the RPi3 doesn’t support. You can run Fedora and CentOS, though.

https://www.solid-run.com/marvell-armada-family/armada-8040-... - $369. You can get it in a case too (https://www.solid-run.com/clearcloud-cloud-iot-core/)

https://www.phoenicselectronics.com will sell you a Gigabyte MT30-GS2 (Cavium ThunderX 32-core) 1U system for around $2k. If you want to provide your own ATX case - much less.

Gigabyte XGene-1 designs based on MP30-AR0 in 1U are literally $1k. http://www.nextwarehouse.com/item/?2465024_g10e

https://www.solid-run.com/marvell-armada-family/armada-8040-... - $369. You can get it in a case too (https://www.solid-run.com/clearcloud-cloud-iot-core/)

https://www.phoenicselectronics.com will sell you a Gigabyte MT30-GS2 (Cavium ThunderX 32-core) 1U system for around $2k. If you want to provide your own ATX case - much less.

Gigabyte XGene-1 designs based on MP30-AR0 in 1U are literally $1k. http://www.nextwarehouse.com/item/?2465024_g10e

Yep, ACPI support is evolving, but it’s a matter of time. Folks have figured finally that if it isn’t compliant with SBBR and SBSA, then there will be plenty of competitors who will be, absolving you of the headache of dead-end BSPs.

softiron.com for the OverDrive 1000.

https://www.solid-run.com/marvell-armada-family/armada-8040-... - $369

https://www.phoenicselectronics.com will sell you a Gigabyte MT30-GS2 (Cavium ThunderX 32-core) 1U system for around $2k. If you want to provide your own ATX case - much less.

ThunderX2 and Qualcomm Centriq (3rd gen arm server) systems have been recently announced (as in GA), but those will set you back quite a bit because they're not toys. But if you look at the 1st and 2nd gen systems, those are quite approachable.

We're now in the 3rd generation of Arm servers, all built to the same set of specifications with multiple vendor SoCs by tens of different OEM/ODMs - SBSA (Server Base System Architecture) and SBBR (Server Base Boot Requirements).

The goal of these specs was to make these servers as "boring" as possible, i.e. as similar to an x86 server so that neither OEM/ODMs nor IT guys have to be able to distinguish between supporting an Arm or an x86 servers.

This means that you will be able to boot the same binary OS distribution on every machine. There are no more BSPs like in the old 32-bit Arm world. This means that the OS does not need to know anything about clock domains, pin muxes, GPIOs or DVFS beyond the standard facilities exposed via ACPI. Like x86, machine error handling is firmware-first. PCIe works the same way as on x86. AP core boot up and power off is abstracted through the PSCI (Power State Control Interface). TrustZone is not available for OS use and is purely used to implement resident portions of firmware (RAS error handling, PSCI, SDEI).

For people asking why UEFI and why ACPI, the answer is very simple: because that's what 99% of all deployed servers use. Using something else is just a friction point for the OEMs, ODMs, IHVs and firmware vendors. It would also be a friction for anyone consuming these systems. Sometimes, you have to be the adult in the room and say that you don't need an "ideal" solution, but the existing solution will work. Plus, the UEFI+ACPI world only really works when you are able to make all systems look more or less the same, hiding all the nitty-gritty shitty bus accesses (I2C for power buttons, SPI for flash, GPIO etc) completely in the firmware, not for the OS to care about. The OpenPower ecosystem didn't see this at all, and they have an elegant firmware solution (hostboot + skiboot + petitboot), but... why bother? It's yet another way to boot, and it just makes their systems foreign to 99% of everyone making and using servers. The OpenPower booting was basically built for Google, but the reality of Google is very different from the realities of the world.