Corellium Posts Very Early Linux Port To Apple M1 Macs

[WorBlux]

Actually, they do make a profit on their hardware, if you compare what the equivalent sales price is of competitive offerings (at least when they were running x86 where it was easy to compare the BoM prices). The walled garden (only Apple hardware can officially run MacOS (yes, we all know about hackintoshes)) is a way to make sure you pay that premium if you wanted/needed to run MacOS.

Compared against other business class devices in the same physical from factor? Not really a huge difference even before considering screen quality. They certainly aren't losing money there it doesn't seem to be their main strategy.

[amxfonseca]

The basic M1 (excluding the GPU) is a fairly standard ARM64 core with mapping to manage power better and custom extensions including those needed to run x86_64 little endian instructions without having to do software flipping.

ARM architecture is bi-endian. And as far as I know, most of modern operative systems run it on little-endian mode, including iOS. So I don’t think there’s any special endieaness conversion that need to be done for the M1 to run x86_64 code.

[baryluk]

My thoughts too. Like pretty standard ARMv8.6-A, probably UEFI and ACPI?

It is not standard.

Not UEFI. No standard device tree format. No ACPI. No GIC. No SBST. A lot of custom silicon. Custom watchdog, custom interrupt controller, and few more.

Some stuff are standard, but not implemented in Linux for arm64. I.e. For example FIQ interrupt handlers. And many other quirks.

So, it is not trivial. Apparently not impossible and not too hard, but not trivial either. A month ago, nobody (including devs involved) knew if it will take a week or a year to make it work.

[Ladis]

It is a standard ARM instruction set. You don't care what is behind it (like you don't care about the black box behind x86 interface in Intel and AMD CPUs - unless you want low level optimizations). About the different BIOS, this is offen worked around by running a virtual machine, where you implement the required BIOS in your software and forward the CPU instructions to the real HW (means OS code and apps code run native). What's important is M1 loads the firmware blobs for all the chips (e.g. iGPU) before loading any OS (as I read somewhere). With that, most of the work will be the iGPU driver - but the iGPU itself will run fine, because the firmware is loaded (unlike NV GPUs where you miss e.g. reclocking). For many people even the first level of running the iGPU as a simple framebuffer video will be enough (at least at the beginning).

ARM architecture is bi-endian. And as far as I know, most of modern operative systems run it on little-endian mode, including iOS. So I don’t think there’s any special endieaness conversion that need to be done for the M1 to run x86_64 code.

M1 has a special switch to turn off the reordering of the load-store memory instructions. That simulates the strong memory model of x86. On a generic ARM (e.g. Windows 10 on ARM devices), you have to put a lot of memory barriers around parts of the code.

[azdaha]

Actually, they do make a profit on their hardware, if you compare what the equivalent sales price is of competitive offerings (at least when they were running x86 where it was easy to compare the BoM prices). The walled garden (only Apple hardware can officially run MacOS (yes, we all know about hackintoshes)) is a way to make sure you pay that premium if you wanted/needed to run MacOS.

Yeah, lots of profit from over-priced hardware (vs. production cost). Profits from the "walled garden" became more prominent after they started creating their own services; think, when they came out with apple maps.