Notes on Linux 5.16 RC1 Deployment for Apple M1 Mac Mini

What works / doesn’t work?

  • 10G Ethernet: Works.
  • WiFi: Can’t find wireless card.
  • Audio: Neither HDMI nor onboard audio works.
  • USB Audio: Works. If you use Apple USB-C to 3.5mm dongle, connect your headphones / speakers to the dongle first before plugging the dongle into Mac Mini.
  • USB3: Degraded speed on type C ports – Operates at 300Mbit/s. Type A ports are fully functional.
  • Graphics: fbcon / kmscon works without issue. Can start GUI with llvmpipe and is in fact fast enough to run gnome.
  • Built-in NVME drive: Block device nodes exist. My system is not deployed on the internal SSD. Actual usuability and performance remain untested.

Devices and Software

  • A linux host where you build the kernel and the bootloader.
  • A M1 Mac Mini. Mine has 10Gbit ethernet.
  • A USB drive to serve as a makeshift root device.
  • A USB-something to USB-C 3.0 cable for sideloading kernel and initrd.
  • A USB keyboard hooked on the Mac Mini.


Build the kernel first. Make sure environment variable is set:

  • ARCH=arm64
  • CROSS_COMPILE= the path of the cross compiler tool chain.
  • INSTALL_MOD_PATH= /usr in the thumbdrive root file system.

Verify you have arch/arm64/boot/Image.gz, arch/arm64/boot/dts/apple/t8103-j274.dtb. Run make modules_install and make sure the kernel modules are correctly stored at <thumbdrive>/usr/lib/modules/<version-localversion>.

There’s no good way to generate an initrd without messing around with QEMU userspace emulation or going to another arm64 Linux machine. Since we are already in a chroot, you may configure root passwords, hostname / timezone and other stuff in there as well. See a random Stack Exchange post on how to do this.

Building m1n1 is very straight forward. Modify the first line in Makefile and set ARCH to ${CROSS_COMPILE}, then follow README at Find compiled m1n1.macho in build/.

Follow AsahiLinux Dev Quick Start to provision disk space from Mac OS, transfer m1n1.macho to 1TR and use kmutil to use m1n1 as a custom boot object, connect Mac Mini to build host with a USB cable.

Sideloading Kernel and Initrd

m1n1 has a bunch of python scripts to interact with a Mac running m1n1. When the Mac mini is connected to the Linux PC it should appear as a USB serial device, something like /dev/ttyACM0.

Set environment variable M1N1DEVICE to /dev/ttyACM0. Invoke proxyclient/tools/ to sideload a kernel like this:

python3 \
    -b 'root=/dev/sda1 rw earlycon console=tty0' \
    ${kernel_source}/arch/arm64/boot/Image.gz \
    ${kernel_source}/arch/arm64/boot/dts/apple/t8103-j274.dtb \

Bootable m1n1 + Kernel Payload

Use the following command to concatenate m1n1 and other stuff used to boot:

cat m1n1.macho \
    <(echo 'boot-args=root=/dev/sda1 rw earlycon console=tty0') \
    ${kernel_source}/arch/arm64/boot/Image.gz \
    ${kernel_source}/arch/arm64/boot/dts/apple/t8103-j274.dtb \
    /path/to/initramfs-5.16.0-rc1-cth-m1+.img \
> /tmp/m1n1+kernel.macho

The combined boot object can be used to boot directly into Linux without another PC.


Booting from iSCSI

At boot pass parameters root=UUID=XXXX ip=dhcp rd.iscsi.initiator=iqn.<host-iqn:identifier> netroot=iscsi:<server-ip>::::iqn.<server-iqn:target> instead of a normal root=/dev/XXX. Also make sure your dracut.conf includes appropriate modules:

add_dracutmodules+=" iscsi lvm "
# I am using LVM on iSCSI. Ignore if just using normal GPT
install_items+=" /usr/bin/lsusb /usr/bin/lspci /usr/bin/iperf3 "
# Add additional files as you wish

I have effectively included as many core system utilities as possible in case I need to operate on the root device before leaving initrd.

HDCP everywhere under Mac OS / 1TR

Due to lack of desk space and monitors, my Mac mini is hooked up to an HDMI capture card. If your capture card can’t terminate HDCP encryption, anything the Mac Mini displays when running Mac OS / 1TR will be unviewable over the capture device even when there are no “copyrighted” contents being displayed at all. (Dammit. Apple. Why?)

Once M1N1 loads, the capture card should report non-HDCP encrypted content. After Linux kernel taking over the framebuffer, HDMI capture will remain unencrypted and functional.

Domain expiry

Hash: SHA512

This message is to certify that access to my old domain name will
terminate on Jan 5, 2021 due to registration expiry. If you haven't updated
your references to the current, please do so ASAP.


New GPG key for new smartcard

Hash: SHA512

This message is to certify that my old RSA key


is still valid, but won't be used as often. A new ed25519 key pair with the
following fingerprint has been generated for my new Yubikey. This new key has
been signed with the original one.


The old key might be revoked in the future if I decide to repurpose my old
Yubikey. Please use the new key for future correspondence.


锈湖站 Rusty Lake Station

“裂车马上就要进站了 本次裂车终点站 菇岛 请乘客们在屏蔽门完全打开后 先下后上 依次登车 带小孩的乘客 请照看好您的小孩 以免发生危险”

上海 Minecraft 地铁
大图 16MB
大图(无屏蔽门) 16MB

站台标识参考(没有狗皮膏药的)上海地铁 1 号线,列车本体涂装基本参考五号线的旧车 05C01,加上了真车上没有的车厢连接通道。本图和我服务器的锈湖站并不相同。哪天心情好了就把以前的旧坑地铁 mod 拿出来重新做成这个样子好了(笑)

本篇出图其实一开始是放在 Pixiv 的,但是经 Homan 提醒,现在的 Pixiv 以不允许游客查看作品的方式逼迫用户注册或者登陆。今后的作品将不会再投稿到 Pixiv,我会在本站提供(足够)高清的出图。

Station signages and other visual elements are heavily based on the current design in Shanghai Metro system. The trains themselves are a reference to the 05C01 trains (now demoted to servicing the branch line only). Note that the Rusty Lake in this station is entirely different from the one currently in my Minecraft server (by Homan).

This work was originally published on Pixiv a while earlier. However, Pixiv is marking my work as “sensitive” out of no particular reason. According to yahoo chiebukuro, Pixiv is forcing users to sign in before they can view the work in the name of “sensitive content”. As a result, my future works will be posted on this personal website instead of Pixiv.

GPG Key Renewing – 2020

Hash: SHA512

Old Key Fingerprint: 336E9D9A9B80E1BEFFE4CBB994333B156BD49DC0
New Key Fingerprint: 3EA4556BFDA919931884606919F85E55F96644FC

This message is to certify that my old RSA key is expiring on Sep 18 2019. A new key pair with fingerprint above has been generated and will replace the expiring key soon. The new key will carry a signature from the original one.

Chai, Sept 5 2019


Photo Roll from Hokkaido

Former Ministry From Edo Era in Goryokaku
Lat N 41 47.813 Long E 140 45.430
Fireworks “Hanabi” at Toya Lake
Lat N 42 33.970 Long E 140 49.228
f/16 30” ISO 640
Sapporo Subway O-dori Station, Exit to West-3 Intersection
Lat N 43 03.648 Long 141 21.118
Hakodate Bay Night View from Hakodate Mountain Observatory
Lat N 41 45.562 Long E 140 42.278
f/10 10” ISO 100

A Note on SIT Tunnel at Home

This blog article records the progress of setting up IPv6 tunnel to Hurricane Electric at home where my ISP has no plan in sight to provide prefix-delegated IPv6 access over a PPPoE.

Shorthands and Assumptions in This Note

  • eth0 connects to the Internet via IPv4. This note shall also apply to encapsulated interfaces, e.g. vlan15@eth0, lte0 or pppoe0.
  • eth1 connects to local LAN. Similar as above, the process shall be the same when LAN side is a VLAN or bridge (or both).
  • tun0 denotes the sit tunnel interface created in this step.
  • A line beginning with # denotes comments in the configuration notes.

Setting up the Tunnel Interface on ER-X

If registered correctly on TunnelBroker, it should provide the following information:

  • Logical address at local endpoint, e.g. 2001:444:111:222::2/64
  • Logical address at remote endpoint, e.g. 2001:444:111:222::1/64
  • IPv4 address at remote endpoint where encapsulated traffic is sent, e.g., the HE tunneling endpoint in Paris.
  • A routable prefix for client side delegation, e.g. 2001:444:112:222::/64. This is usually different from the v6 addresses for the endpoint, and HE will show segments of the prefix in bold.

Now fill ER-X configuration nodes with corresponding information and default routing for IPv6:

            address: [Fill logical v6 address in CIDR at endpoint]
            description: [Give a name to this tun]
            encapsulation: sit
            local-ip: [Fill in IPv4 address at eth0]
            remote-ip: [Fill in IPv4 address at tunneling endpoint]
                next-hop-interface: tun0
            # This creates a default IPv6 routing table entry that
            # routes all non-link-local address to the tunnel.

At this point, one should be able to ping any IPv6 address from the ER-X. If this is working, continue to instruct the LAN interface to delegate the prefix

            dup-addr-detect-transmits: 1
            # Stateless SLAAC configuration might produce identical
            # IP addresses. This allow the network to detect whether
            # a stateless address already exists.
                # Set autoconf to allow stateless delegation by SLAAC
                    [Fill routable delegated prefix here]:
                        autonomous-flag: true
                        # Instructs computers on this network to auto
                        # discover DNS servers
                        on-link-flag: true
                        # Indicates that this prefix exists on the
                        # same Ethernet link, i.e. these addresses
                        # does not require routing

IPv6 enabled devices shall now receive globally unique IPv6 address assigned via SLAAC and prefix delegation.

Subsequent Steps

  • Confirm IPv6 assignment on LAN devices
$ ip addr
2: eno1:  mtu 1480 qdisc fq_codel state UP group default qlen 1000
     link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
     inet brd scope global dynamic noprefixroute eno1
        valid_lft 80444sec preferred_lft 80444sec
     inet6 2001:470:d:XXXX:XXXX:XXXX:XXXX:dfd3/64 scope global dynamic noprefixroute 
        valid_lft 2591976sec preferred_lft 86376sec
     inet6 fe80::be40:XXXX:XXXX:XXXX/64 scope link noprefixroute 
        valid_lft forever preferred_lft forever
  • Trace IPv6 connections to an IPv6 enabled website
$ traceroute -6 -n
 traceroute to (2606:4700:30::681c:1b16), 30 hops max, 80 byte packets
  1  2001:470:d:XXXX:XXXX:XXXX:XXXX:XXXX  0.415 ms  0.533 ms  0.624 ms
  2  2001:470:c:XXXX::1  185.353 ms *  203.802 ms
  3  2001:470:0:9d::1  178.603 ms  167.001 ms  189.255 ms
  4  2001:504:0:3:0:1:3335:1  196.520 ms  179.737 ms  196.117 ms
  5  2400:cb00:12:1024::6ca2:d61d  185.036 ms 2400:cb00:12:1024::6ca2:d614  175.573 ms 2400:cb00:12:1024::6ca2:d608  185.263 ms
  • It is advisable to setup network wide firewall on the router, as addresses can be reached by any other IPv6 connected devices from the Internet.

Further Notes

  • The sit tunnel shall also work if setup correctly on any other router or even a personal computer with public IPv4 address. I am unable to replicate the settings on a Linux router via raw commands as I do not own a linux machine with public IPv4 address.
  • I am not sure if the method would work if the local endpoint is behind NAT. This scenario will be experimented on after I return to campus.

“Certified” Androids?

The story begins with the moment I bought Cytus II on the very first day of its release from google play, expecting some real music gaming on my Surface Pro 3 running homebrew Android 7.1 (yes, that’s totally possible and it runs suprisingly fine with all hardware buttons and touchscreen working). However the game quits immediately and no logs are shown through the adb interface. I contacted Rayark for support and got reply like this:

Cytus II might only be compatible for native Android devices at the moment. Please also check if you have installed Xposed, firewalls, block ads, or any rooting software. If yes, these may effect the performance of the game. We’d like to suggest you to remove these software to ensure the game runs smoothly and properly.

(Probably) 3 weeks after the game’s release, I ended up playing Cytus II on my crammed 5′ mobile phone, not by choice though. Someone asked me, why I can’t buy a regular Android tablet or an iPad to do the same job. Well that could be an option if those people would donate in any means for a new one, and I really don’t think utilizing an existing hardware piece could cause any troubles for commercial devs and companies (Google: really?).

After some searches I reached conclusion that Cytus II has integrated an “compliance check” called SafetyNet and the underlying Compatibility Test Suite (CTS), a framework introduced by Google to verify if any android device falls into the category of “compatible”. Since Surface Pro 3 has never got an official Android release (it’s a Microsoft thing, of course) and the base android x86 is shipped with root and development mode on, there is probably no way that any CTS tests on Surface Pro 3 would pass any time sooner.

Just earlier this day, I saw the news that Google is attmpting to block Gapps from running on “uncertified” devices, where modding the android device or unlocking bootloader would void the “certified” status. There’s even a webpage letting people to “register” their Androids with their device identifier which is absolutely not working after I attempted to register my Surface only getting an unknown error.

I would not blame Rayark for their attempt to place a layer of piracy protection on such a nice game while hurting the ones who modded their devices properly exactly to play these games. My question is: If such a lockdown is so important that this system had been deployed to thousands of android software by now, why make android an open standard? Why not switch to the Apple production mode if a centralized control force seems so vital to the whole android community? Such blockage wouldn’t be easily tolerated if the so called “register uncertified devide page” is just a lie, and I believe there will be a solution to circumvent such unreasonable restrictions eventually. Before that, the vast population of “uncertified” androids and modders wouldn’t be so comfortable and I might really need to ask myself: Why I should spend 3 months porting an open source OS to a new device just to find nothing should works by design.

The Hot City?

When I told someone Chengdu is a hot city, I meant both food and the city itself. Hopefully, I finally remembered that I forgot procrastinated to post my photos I took when I travelled to Chengdu and stayed for a few days this winter. Still, these pictures are taken from my old Canon 50D DSLR and the mediocre lens.

Continue reading The Hot City?