NetBSD/Evbarm on Apple Silicon(wiki.netbsd.org)
wiki.netbsd.org
NetBSD/Evbarm on Apple Silicon
https://wiki.netbsd.org/ports/evbarm/apple/
13 comments
Previous discussion here: https://news.ycombinator.com/item?id=28338749
Now I'm curious if Apple Silicon supports switching to big-endian mode. NetBSD has a evbarm-aarch64eb target for this on other Aarch64 boards.
Would make it probably the best performing BE machine that's available to normal folks.
Would make it probably the best performing BE machine that's available to normal folks.
Just curious, what is your specific interest in BE?
We used to, I feel, have higher quality software because it was tested out on a bunch of different platforms. One of the big things we've lost is testing for endianness related bugs, which sometimes catches other bugs too.
There's other categories that we catch less often now too, like assumptions about byte alignment, buffer sizes, and so on.
There's other categories that we catch less often now too, like assumptions about byte alignment, buffer sizes, and so on.
Cross-platform development is a lost art. It made you think about your program a lot more before you hit the keyboard.
The people at AtariSoft and Infocom were wizards in that regard. People today just lean on Electron or something similar.
Imagine releasing the same game, written in assembler, for Atari, Commodore, Intellivision, BBC, Apple, IBM, TI, TRS-80, and Coleco machines.
Infocom had it a little easier, as it only had to write parsers for each platform. But then, it also released its games for freaking PDP-11 machines at least into the end of the 80's.
The people at AtariSoft and Infocom were wizards in that regard. People today just lean on Electron or something similar.
Imagine releasing the same game, written in assembler, for Atari, Commodore, Intellivision, BBC, Apple, IBM, TI, TRS-80, and Coleco machines.
Infocom had it a little easier, as it only had to write parsers for each platform. But then, it also released its games for freaking PDP-11 machines at least into the end of the 80's.
>It made you think about your program a lot more before you hit the keyboard.
And as I have ranted about it for a whole decade, This was pushed by Google / Facebook or Silicon Valley. Thinking long and hard before you hit the keyboard are wrong in modern software development.
And as I have ranted about it for a whole decade, This was pushed by Google / Facebook or Silicon Valley. Thinking long and hard before you hit the keyboard are wrong in modern software development.
Yup. OpenBSD has pointed out a number of times the utility of the SPARC build platform to ferret out things like bad alignment assumptions.
Perhaps someone will modify RISC-V or some such to have variable alignment rules, switchable endianness, etc. as a debugging platform.
But there's a limit...I doubt we'll see, for example, anyone offering a ones compliment machine, even though it might reveal some interesting bugs.
Perhaps someone will modify RISC-V or some such to have variable alignment rules, switchable endianness, etc. as a debugging platform.
But there's a limit...I doubt we'll see, for example, anyone offering a ones compliment machine, even though it might reveal some interesting bugs.
The installation instructions here are so wonderfully straightforward. Unlike Linux, there isn't a single "pipe curl to shell" instruction in the bunch.
I just noticed that the Corellium instructions for installing Linux include doing just that from "downloads.corellium.info". Visiting http://corellium.info/ gives a GoDaddy parking page. That's a bit... janky.
I just noticed that the Corellium instructions for installing Linux include doing just that from "downloads.corellium.info". Visiting http://corellium.info/ gives a GoDaddy parking page. That's a bit... janky.
I assume you're comparing specifically to Linux on the same hardware? Because on x86, installing Linux is usually "flash this image to a USB stick, boot it, and click the 'next' button a lot"
Yeah linux on M1 has been challenging to get running, and installing it has been a tricky process, but it might get better soon since basic M1 support has been added to the linux kernel
Note that this method of installation takes a couple shortcuts regarding disk partitioning:
- It requires cannibalizing an existing macOS installation, replacing its kernel with the u-boot. Assuming you don’t want to replace your primary macOS installation, you’ll have to partition your disk and install another macOS, which takes a couple hours and wastes about 70GB of disk space.
- It can only boot from USB, since no Linux partition is set up. (This isn’t much of an issue right now because the M1 SSD controller has not yet been reverse-engineered, but it will be soon.)
The Asahi Linux project has a more detailed set of instructions for project developers to set up a debugging environment, following roughly the same steps. [0] However, they are in the process of replace this with a ‘curl | sh’-style install script [1] in order to simplify the process for end users. The install script will create and setup the boot partition itself instead of requiring a secondary macOS installation, so it will be much faster and not waste disk space. Doing this requires manually creating several disk partitions for the macOS bootloader, downloading a firmware image from Apple, and copying a bunch of firmware blobs into the right places across those partitions, so it’s not really suited for a manual install.
Note also that Corellium’s implementation was more of a proof-of-concept than something designed for long-term use. If you want to see “how Linux does things” you should be looking at the Asahi project, which is being upstreamed into mainline Linux and is already much further along in development than Corellium’s demo.
[0]: https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart...
[1]: https://github.com/AsahiLinux/asahi-installer
- It requires cannibalizing an existing macOS installation, replacing its kernel with the u-boot. Assuming you don’t want to replace your primary macOS installation, you’ll have to partition your disk and install another macOS, which takes a couple hours and wastes about 70GB of disk space.
- It can only boot from USB, since no Linux partition is set up. (This isn’t much of an issue right now because the M1 SSD controller has not yet been reverse-engineered, but it will be soon.)
The Asahi Linux project has a more detailed set of instructions for project developers to set up a debugging environment, following roughly the same steps. [0] However, they are in the process of replace this with a ‘curl | sh’-style install script [1] in order to simplify the process for end users. The install script will create and setup the boot partition itself instead of requiring a secondary macOS installation, so it will be much faster and not waste disk space. Doing this requires manually creating several disk partitions for the macOS bootloader, downloading a firmware image from Apple, and copying a bunch of firmware blobs into the right places across those partitions, so it’s not really suited for a manual install.
Note also that Corellium’s implementation was more of a proof-of-concept than something designed for long-term use. If you want to see “how Linux does things” you should be looking at the Asahi project, which is being upstreamed into mainline Linux and is already much further along in development than Corellium’s demo.
[0]: https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart...
[1]: https://github.com/AsahiLinux/asahi-installer
> because the M1 SSD controller has not yet been reverse-engineered
It has been. Supported in the Corellium tree today and in a tree somewhere for Asahi, on its way to mainline
It has been. Supported in the Corellium tree today and in a tree somewhere for Asahi, on its way to mainline
Have you seen Asahi’s documentation?
https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart