3 ms·

NetBSD/Evbarm on Apple Silicon

44 points by rodrigo975 5y ago

rjsw 5y ago
Previous discussion here: https://news.ycombinator.com/item?id=28338749 https://news.ycombinator.com/item?id=28338749
tyingq 5y ago
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.
- CyberRabbi 5y ago
  Just curious, what is your specific interest in BE?
  - tyingq 5y ago
    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.
    - kjs3 5y ago
      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.
    - reaperducer 5y ago
      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.
      - ksec 5y ago
        >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.
johnklos 5y ago
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/ http://corellium.info/ gives a GoDaddy parking page. That's a bit... janky.
- ArgyleSound 5y ago
  Have you seen Asahi’s documentation? https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
- NobodyNada 5y ago
  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#setup https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart... [1]: https://github.com/AsahiLinux/asahi-installer https://github.com/AsahiLinux/asahi-installer

44 points by rodrigo975 5y ago

rjsw 5y ago

Previous discussion here: https://news.ycombinator.com/item?id=28338749 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.

CyberRabbi 5y ago
Just curious, what is your specific interest in BE?
- tyingq 5y ago
  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.
  - kjs3 5y ago
    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.
  - reaperducer 5y ago
    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.
    - ksec 5y ago
      >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.

johnklos 5y ago

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/ http://corellium.info/ gives a GoDaddy parking page. That's a bit... janky.

ArgyleSound 5y ago
Have you seen Asahi’s documentation? https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
NobodyNada 5y ago
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#setup https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart... [1]: https://github.com/AsahiLinux/asahi-installer https://github.com/AsahiLinux/asahi-installer