<marcan>
honestly, I see myself implementing half these drivers in python/mini to begin with
<tpw_rules>
is that in between python and micropython?
<jn__>
i think it means running regular python on a workstation and sending memory/mmio peek/poke commands over a serial connection to mini running on the mac
<tpw_rules>
oh, i hadn't heard that mentioned before
<jn__>
marcan mentioned porting mini (which was previusly used for Wii work) to the M1 in the project introduction youtube stream, i think
tiagom has quit [Quit: tiagom]
<tpw_rules>
oh i found that, thank you
<marcan>
what jn__ said :)
<marcan>
though I'll probably use the serial version to write a USB driver, then s/serial/usb/
<jn__>
makes sense for performance
<marcan>
(for dwcusb values of usb)
<jn__>
hehe
<marcan>
it seems xHCI (usb host) is under PCIe, so that has a dependency I did not expect, which means linux won't be usable for anything until PCIe is done, so PCIe is now top priority once mini is up
<marcan>
corellium has a driver already, but I'm annoyed by the pokefests
<marcan>
though I think a lot of that is to initialize PHY stuff which is probably not used for xHCI since it's internal?
browzing has quit [Ping timeout: 246 seconds]
<marcan>
so I can probably get away with a lot less for xHCI
<marcan>
I hate PHY init
<marcan>
but this might be different on M1 so who knows
<marcan>
it'll be fun
<jn__>
where will iboot load our payload from?
<davidrysk[m]>
marcan: you gave me an idea, lemme grab the IORegistryExplorer :)
<davidrysk[m]>
there's a bunch of not so well known tools part of the "Additional Tools for Xcode" that are on the Apple More Downloads site.
<davidrysk[m]>
They are super-handy for things like this
jamadazi has quit [Ping timeout: 260 seconds]
<davidrysk[m]>
so there's an I2C connection to the USB, probably for control purposes
<davidrysk[m]>
but the USB itself is connected to arm-io
<marcan>
jn__: APFS
<marcan>
davidrysk[m]: if you mean the devicetree, I have a dump already :)
<marcan>
that's where I saw xhci hangs off of PCIe
<jn__>
i mean from which physical storage medium
<marcan>
internal ssd
<marcan>
iboot only loads stuff from internal ssd AIUI
<davidrysk[m]>
I think the device tree but it tends to be super-confusing
<davidrysk[m]>
I see that this gives away which firmware binaries the BRCM card requires
<marcan>
(bbl, irq)
<jn__>
is the SSD on a special bus, rather than pcie? (sorry if that's documented somewhere)
<marcan>
I believe it's internal
<marcan>
(the controller)
<marcan>
but I haven't checked that part of the devtree
<marcan>
("internal" means some internal fabric bus, but we don't care about those for our intents and purposes assuming they're transparent, which most are)
<jn__>
i see
<davidrysk[m]>
I have a USB drive plugged in and it appears at
<davidrysk[m]>
IOService:/AppleARMPE/arm-io@10F00000/AppleT810xIO/usb-drd0@82280000/AppleT8103USBXHCI@00000000/usb-drd0-port-hs@00100000/USB 3.0 FD@00100000/IOUSBHostInterface@0/IOUSBMassStorageInterfaceNub/IOUSBMassStorageDriverNub/IOUSBMassStorageDriver/IOSCSILogicalUnitNub@0/IOSCSIPeripheralDeviceType00/IOBlockStorageServices/IOBlockStorageDriver/PNY USB 3.0 FD Media
<marcan>
I get the feeling that's a lie
<marcan>
but it might not be
<davidrysk[m]>
I'm wondering if "usb-drd0" is a mapping to something else
<marcan>
drd means dual-role-device
<marcan>
but if you look at the hardware devtree, its only mention of xhci is behind pcie
<marcan>
so that might be a strangely "folded" device path
<balrog>
how do you access the hardware devtree?
<marcan>
where the drd controller (host/device) switch is in front of xhci in the path, but that obscures xhci's real IO
<marcan>
compatible (22): "pci-xhci-FL1100,t8103" suggests Apple licensed the Fresco Logic FL1100 which explains why it's PCIe
<marcan>
(that's a physical chip but there's no such chip on the board)
<marcan>
(it's also possible it's not Fresco Logic at all and that's just the original target of a driver and they're just reusing that compatible ID though; xHCI devices are intended to be compatible with each other)
<davidrysk[m]>
marcan: is that perchance the mac mini?
<marcan>
it is
<davidrysk[m]>
well that's why
<marcan>
?
<davidrysk[m]>
the 2x USB 3.0 ports are attached via PCIe
<davidrysk[m]>
the 2x TBT3/USBC ports are not
<davidrysk[m]>
I'm testing on a MBP
<marcan>
oh snap
<marcan>
well that makes sense then
<marcan>
so then we have two xhcis
<marcan>
the apple ones and the FL ones
<davidrysk[m]>
yep
<davidrysk[m]>
which matches the teardown iirc
<marcan>
I'd forgotten about the A ports
<marcan>
not sure if this is good or bad for me then
<marcan>
what's easier to get working, PCIe or the typec muxes? :D
<davidrysk[m]>
I mean, I wouldn't cry if they weren't supported initially
<davidrysk[m]>
what matters more, USB on the mini only, or USB on all the M1 machines? :)
<marcan>
well, the question is what's easiest to make work first
<davidrysk[m]>
well yeah
<marcan>
because if I have USB, I have I/O
<marcan>
which means I have storage, networking, mouse, keyboard, everything
<marcan>
and I need that to work
<davidrysk[m]>
I'm still poking at sshd. how much effort should I put into that?
<marcan>
so I want the path of least resistance first, regardless of how portable it is
<davidrysk[m]>
there's something with the sshd sandboxing mechanism that doesn't play nice with recovery
<marcan>
not much. I'm going to lift screen from macos (assuminig it's there) and do a netcat thing
<davidrysk[m]>
it forks and then sandboxes and then chroots
<davidrysk[m]>
macos does come with screen
<marcan>
not worth wasting more time on it then
<marcan>
er, sorry, not screen
<davidrysk[m]>
okay :)
<marcan>
script
<davidrysk[m]>
yeah, script is there too
<marcan>
should be fine then, good enough for what I want to do
<maximus64>
USB-C port probably just dwc usb core so there are driver for that already. Tricky part is initializing the USB PHY
<davidrysk[m]>
maximus64: do you have any evidence that indicates they might by dwc? While I think that's possible I think it's equally likely that apple did them in house
<davidrysk[m]>
nvm (see -re)
<maximus64>
I'm still waiting for my mb-air. I think marcan mention it is dwc :)
<marcan>
I think dwc is separate
<marcan>
not the regular usb device controller
<marcan>
not sure though
<marcan>
I'm going to make a documentation archive repo
<marcan>
that will be a gray copyright situation, but it's often necessary (in the spirit of GlasgowEmbedded/archive)
<marcan>
(if it gets DMCA'd it's not the end of the world, but it won't)
<davidrysk[m]>
"documentation archive" in what sense?
<Alex[m]17>
do these macs have widevine? aka can they watch netflix, hulu, etc? because i know that is still lacking on aarch64 linux
<davidrysk[m]>
note, TI has been dmca-happy lately
<marcan>
for datasheets?
<davidrysk[m]>
(or rather, their brand protection subcontractor)
<davidrysk[m]>
yes
<marcan>
huh
<marcan>
seriously
<davidrysk[m]>
yes
<davidrysk[m]>
seriously
<marcan>
well okay, scrap that idea then
<marcan>
I'll just mirror this stuff locally just in case then
<marcan>
remind me to never design in TI parts
<davidrysk[m]>
let me double check my references
<davidrysk[m]>
I was pretty sure it was TI...
<davidrysk[m]>
but something tells me I'm mistaken
<davidrysk[m]>
it WAS TI but those datasheets seem to have been put back
<marcan>
still, DMCAing a datasheet is an instant DQ from any future design from me, as far as I'm concerned
<marcan>
that's a big nopenopenopenopenope
<marcan>
I don't care what the lawyers think should happen on paper, if engineers can't share datasheets I can't work with you
<Shiz>
DMCAing datasheets sounds very NXP
<marcan>
I assume these were *public* datasheets?
<davidrysk[m]>
marcan: I sent more details via PM.
<marcan>
DMCAing "confidential" leaked datasheets I could understand
<marcan>
(still shit, but not the same)
<marcan>
davidrysk[m]: please do
<davidrysk[m]>
I did
<davidrysk[m]>
from IRC-side
<davidrysk[m]>
a little research turned up dozens of DMCAs from a brand protection firm working on behalf of them to google et al, apparently not really looking at the contents, just DMCAing anyone who posted stuff copyright TI
<Shiz>
fun
<davidrysk[m]>
I feel like if I dig further I'd find that's not limited to TI
<davidrysk[m]>
(of course now the TI calculator signing key mess comes to mind, even though that's a different division. lol)
<marcan>
yeah, that's still dumb but a different story
<mjg59>
Alex[m]17: There's widevine support on AArch64 Android
<Shiz>
yeah fwiw, i'm not aware of nxp dmca'ing public datasheets (might still happen)
<Shiz>
they just don't give you any datasheets on a bunch of stuff to begin with unless you NDA with them :p
tiagom has joined #asahi
tiagom has quit [Client Quit]
tiagom has joined #asahi
<marcan>
yeah, that's a different story
<marcan>
I mean I won't work with those vendors either, but at least you know upfront what you get
<davidrysk[m]>
I hate that practice
<davidrysk[m]>
but — yeah
<Alex[m]17>
what is the bootloader going to be? u-boot?
<Alex[m]17>
<mjg59 "Alex: There's widevine support o"> thanks.. still confused. im talking about linux, not android
KarboniteKream has joined #asahi
<marcan>
not decided yet. initially it will be a custom thing I cook up based on mini
<marcan>
whether it makes sense to switch to u-boot at some point or not, we will see
<marcan>
porting u-boot doesn't seem like worth the effort for initial bring-up
<marcan>
but it might for long-term bootloading
jkao[m] has joined #asahi
<artemist>
somebody could probably port tianocore eventually
<marcan>
u-boot makes sense when low level init an ATF and such are involved, but with the M1 being so custom (AIC...) and iBoot doing all the low level stuff for us, I don't feel like it'll buy us much a priori
<davidrysk[m]>
does the kernel have to live on the preboot/
<davidrysk[m]>
?*
<davidrysk[m]>
(which is APFS and already exists)
<mjg59>
Alex[m]17: Android is Linux for these purposes. There's really nothing magical about the CPU architecture here.
<davidrysk[m]>
that's all Widevine L3 though, right? (L2 and L1 require hardware DRM support)
<mjg59>
davidrysk[m]: Yeah, but then you're more into graphics driver design and the architecture of your TrustZone applets
<Alex[m]17>
i have a pinebook pro with 64 bit userspace, and i have to run chromium in a 32 bit contianer with a widevine ripped from ChromeOS to watch Netflix. i guess im wondering if M1 machines running 64 bit linux will also have this issue
<mjg59>
If there's no 64-bit Widevine L3 plugin for Linux Chrome, then yes
<mjg59>
L3 is independent of the hardware
<mjg59>
MacOS will probably have L1 support, but that won't get you much
<davidrysk[m]>
macOS probably does have L1 support, though if you're using Safari it uses the FairPlay CDM instead
<artemist>
Unless someone wants to reverse engineer the interface macOS uses to ATF and Apple didn't disable it
<davidrysk[m]>
ATF?
<artemist>
Wait, not ATF, that's just the reference
<artemist>
Arm Trusted Firmware, it runs in the TrustZone container
<Alex[m]17>
isnt it TF-A?
<davidrysk[m]>
if you mean to say TrustZone, Apple doesn't use it
<davidrysk[m]>
it simply does not exist on current Apple SOCs
<artemist>
Oh, fun
<davidrysk[m]>
xnu hints that some of their earlier SOCs had EL3 (which doesn't necessarily mean TZ), but then they dropped it
<artemist>
I forgot they used the SEP for everything
<rootspring[m]>
Is the SEP worse than trustzone for this project?
<tbodt>
android widevine is tightly coupled to the android media stack and not really relevant to chrome
<tbodt>
i'm fairly sure intel macos doesn't have widevine l1
<tbodt>
the l1 implementation in the intel ME is only wired up on windoww
<davidrysk[m]>
what CDM does intel macos use on chrome?
<Alex[m]17>
so we will still use iBoot as our bootloader for the time being? got it. too bad that we have to use something proprietary
<artemist>
How will the SSD show up to Linux? I'm guessing the flash controller is in the SoC but I can't find much info about it and ifixit stopped giving good teardown photos with chips labelled
<davidrysk[m]>
Alex: we will always have to use iBoot, this is not going to ever be a 100% open system
<rootspring[m]>
I don’t think u can replace Iboot, correct me if I’m wrong
<rootspring[m]>
Iboot is signed
<mjg59>
There's proprietary code in the boot ROM whatever
<marcan>
davidrysk[m]: the first stage needs to live on APFS, I intend for that to be a bootloader only and the real linux kernel can live on something else
<marcan>
probably FAT32 for the first version because fatfs is just so easy to run on anything and mini has it already
<artemist>
If you want secure boot you need a first-level loader in the bootrom. Most of the SoCs i've seen have that be propriatery
<rootspring[m]>
Wait, why does first stage have to be on apfs
<marcan>
because iBoot only understands APFS
<marcan>
so the first usable linux will probably look like a minimal APFS (or a full macos for dual boot) for the bootloader/mini, /boot on FAT32 (not unlike people who use the ESP as /boot, I do that on some systems), and ext4 or whatever for /
<rootspring[m]>
Will systemd boot be supported eventually
<marcan>
Alex[m]17: we cannot not use iBoot
<marcan>
the unsigned code handoff is from iBoot
<marcan>
you need to think of iBoot as the UEFI firmware on any random PC
<mjg59>
rootspring[m]: Whatever iboot chains to can certainly be taught to understand the systemd boot fragment format
<marcan>
it is what it is, effectively
<marcan>
and the "ESP" is APFS here
<mjg59>
rootspring[m]: But you're not running systemd-boot without UEFI
<marcan>
and the "recovery partition" is the UEFI setup
<marcan>
if you think of the mental map like that the whole model makes a lot more sense
<davidrysk[m]>
marcan: what is the minimal set of "items" needed to have a recovery partition?
<marcan>
let me write a wiki page about this
<marcan>
davidrysk[m]: it's signed, so you need the whole thing
<rootspring[m]>
Can iboot be taught to directly boot Linux
<davidrysk[m]>
I suppose one could start deleting volumes and seeing if recovery is still accessible
<marcan>
iBoot can boot a mach-o object file wrapped in img4 and whose hash is inserted into the local bootpolicy
<mjg59>
The only way you're going to get iboot to boot Linux is to have Linux look like an iboot payload
<marcan>
exactly
<marcan>
that could be whatever we want it to be, but the reasonable thing to do is make it be a first stage that hands off to something more controllable
<mjg59>
Which is what we do on UEFI systems - Linux can be built to look like a UEFI executable
<marcan>
since to update that first stage requires doing bootpolicy magic which requires being in recovery mode I believe
<mjg59>
But you're probably not going to have it be both simultaneously
<marcan>
so ideally we never change it
<Alex[m]17>
is there a makefs equivalent for APFS?
<marcan>
on macos, yes
<marcan>
I mean there's mkfs
<mjg59>
And yeah, it makes much more sense to have a simple first stage bootloader
<marcan>
anyway, again, think of recovery mode as your UEFI setup
<marcan>
recovery mode gives you a root shell
<marcan>
you can curl|sh and run whatever
<marcan>
as long as we can do the entire boot setup process in recovery mode, that will be the sanest installer environment
<marcan>
s/whatever/whatever scripts/
<marcan>
(we cannot run our own binary code in recovery mode, it's signed)
<rootspring[m]>
Wait, you can run curl in recovery mode? Why does it give me command not found on my hackintosh
aratuk has joined #asahi
<marcan>
maybe hackintosh recovery mode is different
<marcan>
:)
<rootspring[m]>
And vi in recovery sucks
<davidrysk[m]>
rootspring: lol it reminds me of solaris 9 vi
<davidrysk[m]>
fun times :)
<mjg59>
In UEFI land we have Shim as a simple first stage bootloader that changes rarely, and which then boots the actual bootloader
<artemist>
Does loading a binary as a shared library with dlopen bypass signing? I remember that it bypassed some controls a few years ago but they've probably fixed that
<mjg59>
So an equivalent model works well here
<davidrysk[m]>
artemist: they fixed that long ago
<rootspring[m]>
It’s not even funny how bad vi is in recovery
<artemist>
davidrysk[m]: good except bad for us
<Alex[m]17>
so we can currently boot linux in the form of a UEFI executable on M1, or thats just the first step on our road map
<rootspring[m]>
Does recovery mode have python
<artemist>
no Python, but it does have Perl
<davidrysk[m]>
okay that's interesting...
<davidrysk[m]>
I mounted the Recovery volume from macOS and it's EMPTY
<davidrysk[m]>
I think it's synthesized from Preboot
<rootspring[m]>
Wait, then why even have a recovery volume
<rootspring[m]>
If it’s synthesised from Preboot
<davidrysk[m]>
rootspring: for non-persistent data when running recovery
<davidrysk[m]>
it's possible that I'm missing something
<rootspring[m]>
Odd, intel Macs (or maybe just hackintoshes) have all sorts of files in recovery
<davidrysk[m]>
ahh, no, I'm looking in the wrong Recovery
<rootspring[m]>
Like hundreds of im4ms
<davidrysk[m]>
yeah, it's my error
<rootspring[m]>
BootKernelExtensions.kc.*
<davidrysk[m]>
you can't even mount the real recovery from macOS
<rootspring[m]>
I wonder what the trustcache stuff it
<rootspring[m]>
Does anyone know what these files even are
<davidrysk[m]>
marcan: starting out I'd probably just use the existing Preboot volume as the "system" partition for the bootloader
<mjg59>
Alex[m]17: Choices are basically: (1) kernel that looks like an iBoot payload (bad), (2) first stage bootloader that boots Linux directly, (3) first stage bootloader that presents a UEFI environment
<mjg59>
(3) makes it easier to work with existing distros, but puts a lot more complexity in
<Alex[m]17>
and 1st option is bad because we will have to package linux differently for M1
<mjg59>
And you'd need to boot into recovery every time you update the kernel
<davidrysk[m]>
does it have to be a UEFI environment, as opposed to a simpler bootloader like u-boot? though considering that iBoot does the hardware setup, that might not be needed
<davidrysk[m]>
and u-boot just loads the kernel directly
<davidrysk[m]>
marcan did say that EFI is not going to happen because of complexity and I basically agree with that
<mjg59>
davidrysk[m]: I think that's (2), although you could theoretically have a first stage bootloader that just chained into u-boot
browzing has joined #asahi
<mjg59>
But once you're in u-boot you can do UEFI - there's support for providing enough UEFI boot services in u-boot to launch Linux
<davidrysk[m]>
I ran an ARM based server for a while for my IRC bouncer and such but upgraded to an x86 box because there were no good options for an arm64 one with enough performance and storage capabilities for my needs
<davidrysk[m]>
that was well before Aarch64 was a thing even
<Alex[m]17>
i imagine that an asahi-ified mac mini could fulfill the job :)
<davidrysk[m]>
perhaps, though I'd need a TBT to 8x SATA system of some sort
<davidrysk[m]>
I found a nice 8-bay hotswappable chassis
<marcan>
we are not putting the kernel on APFS, that's for sure
<marcan>
anyway, I know my *first* shot will be me playing around with mini
<Alex[m]17>
thanks, marcan
<marcan>
whether I go straight to Linux at that point, or u-boot first, will depend on what I see when I investigate that boot protocol on ARM64
<marcan>
but Linux already supports crazy ARM64 machines (see: every Android phone), so I don't see why u-boot will buy me anything at *this* stage
<davidrysk[m]>
I am curious about how DFU finds iboot
<davidrysk[m]>
but that's out of scope :)
<marcan>
FWIW I think there is a SPI flash or something that contains device info and may contain an iBoot stage, but I'm unclear on the details
<davidrysk[m]>
there is a winbond chip in those teardowns
<marcan>
if they really did put APFS in ROM that will be a boon to exploiters, because there is no way in hell they didn't screw that up
<Alex[m]17>
i only mention u-boot because i dont want you having to re-invent the wheel when it comes to a bootloader, it seems to be the standard for booting arm64 SBCs and the like
<davidrysk[m]>
well at the beginnign there's this "Apple_APFS_ISC"
<rootspring[m]>
To prevent bricking, is it posibble to hide the Iboot partition from Linux
<davidrysk[m]>
but that is an APFS partition...
<rootspring[m]>
Like hide the whole apfs from Linux just to prevent dd fuck ups
<marcan>
Alex[m]17: I know, but the reason for reinventing the wheel with mini is not to write a full blown bootloader, but to have a veeery small test environment and remote RPC protocol for hardware investigation
<marcan>
and if after that all I need to do to boot linux is put it in RAM and call it with some params, that's easier than porting u-boot at that point
<marcan>
u-boot will be more useful if, say, we decide that we want a bootloder that has USB support
<marcan>
as in USB host
<marcan>
as I don't plan on adding *that* to mini
<marcan>
it's entirely possible that the chain will end up being mini - u-boot - linux
<marcan>
(I've seen longer things than that :p)
<rootspring[m]>
This sounds like the beginning of atmosphere tbh
<marcan>
mini may or may not gain the ability to boot from internal SSD, depending on the internal interface for that. if it's simple sure, if it's complicated then no.
<marcan>
anyway
<marcan>
this is all subject to change as we go
<davidrysk[m]>
iboot is supposed to be able to boot macOS from external USB but there were bugs
<davidrysk[m]>
people reported that TBT3 worked, USBA worked, USBC did not
<davidrysk[m]>
I didn't do any tests of my own
<marcan>
I hear that's a hack
<marcan>
and it's not real
<marcan>
apparently recovery mode copies stuff from external to ssd or something when you try to do that
<davidrysk[m]>
Apple has said that they intend that it works
<davidrysk[m]>
which means it's bugged
<marcan>
yes, but it's not iBoot booting from external USB
<marcan>
it's recovery mode copying stuff to the SSD so iBoot can boot it
<Alex[m]17>
we have a custom bootloader for the RK3399 that simply compresses a payload containing ATF, initramfs, kernel, and the dtb to a GPT partition with a special GUID which the bootloader is able to find, decompress and then boot.
<Necrosporus>
I have read the page about booting macOS, but it's not as detailed as I wanted it to be
tellowkrinkle[m] has joined #asahi
tellowkrinkle[m] is now known as TellowKrinkle[m]
<JTL>
I'd say it's a start.
bear24rw has joined #asahi
lanar has joined #asahi
bear24rw has quit [Ping timeout: 246 seconds]
lanar has quit [Remote host closed the connection]
<marcan>
rootspring[m]: that's okay, just don't consider officially sanctioned or anything. I don't have time to manage a subreddit tbh, so if you want to do that, go ahead
<marcan>
I would appreciate it if you keep the moderation standards in line with our CoC
<rootspring[m]>
I actually sent you a mod invite
<rootspring[m]>
Ok
<marcan>
I'll accept the invite but no promises I can actually spend any time there :)
<rootspring[m]>
Ok
<TheJollyRoger>
Nice!
* TheJollyRoger
waves hello.
<rootspring[m]>
Hi
<TheJollyRoger>
Maybe if news or updates get posted there I can read the news there!
<rootspring[m]>
I might make a bot that keeps posting the Asahi Linux commit history to a live chat maybe if that’s allowed by Reddit
<rootspring[m]>
That way, everyone knows the status
ohnx has joined #asahi
<TheJollyRoger>
Excellent!
<rootspring[m]>
I don’t know how feasible it would be though and it might take a while given that I’ve never used PRAW
bear24rw has joined #asahi
bear24rw has quit [Remote host closed the connection]
MuckiSG has joined #asahi
ephe_meral has joined #asahi
bear24rw has joined #asahi
plainbits has joined #asahi
jaXvi has joined #asahi
newmerck[m] has joined #asahi
vimal has joined #asahi
plainbits has quit [Quit: Go to sleep. Night!]
plainbits has joined #asahi
sirn has joined #asahi
bear24rw has quit [Remote host closed the connection]
jjanzic has quit [Read error: Connection reset by peer]
Pluggi is now known as amerseil
amerseil is now known as Pluggi
bear24rw has joined #asahi
raster has joined #asahi
<raster>
ohayou!
bear24rw has quit [Ping timeout: 264 seconds]
aat596[m] has joined #asahi
bernstei_ has joined #asahi
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #asahi
bernste__ has joined #asahi
<Necrosporus>
> So, you need to write some code which iBoot is going to load to a certain memory address and which will need to execute certain instructions to connect to UART and send debug output. Do you know yet which memory address it's going to be loaded to, what instructions do you need to send bytes via UART?
<Necrosporus>
And somebody said that loading non-apple code via iBoot is still not possible even after unlocking, right, marcan ?
<Necrosporus>
Until they release some util which tells iboot which file to load or smth
bernstei_ has quit [Ping timeout: 272 seconds]
<robinp>
Necrosporus: yeah kmutil and bputil - both in 11.2b but (aparently) don't work yet
<Shiz>
i need to upgrade my mac mini then
bernste__ has quit [Ping timeout: 272 seconds]
<Shiz>
softwareupdate(1) is very useful for updating over SSH :)
<marcan>
there is a kmutil feature missing
<marcan>
it should show up Real Soon Now I believe
<marcan>
as for UART, we know how the UART works and where it lives from the devicetree
<marcan>
it's a samsung UART
<marcan>
(because of Apple's Samsung SoC legacy)
<marcan>
but I actually intend for my first "I'm alive" test to be writing to the framebuffer
<marcan>
I think the macho files should have the load address, but either way I intend to write position-independent code
<Necrosporus>
What machno files?
<Shiz>
the mach-O files that iBoot loads
<Shiz>
yay softwareupdate -i -a && reboot seems to work
<Necrosporus>
marcan, do you know name and position of the first file iBoot loads?
<Necrosporus>
What if you simply rename the old file and put yours on its place?
<marcan>
that's not how it works
<marcan>
you need to sign a secureboot policy
<marcan>
it goes through the SEP
<Necrosporus>
Do you know how to tell the compiler (gcc?) to make mach-O files instead of elf or PE?
<Shiz>
a compiler targeting the macOS triple will do so by default
<Shiz>
it tells you rather directly why just replacing a file wouldn't work
<marcan>
(also I might just find/make an elf/blob to macho converter, because I don't feel like requiring a macho toolchain)
<mjg59>
Or you can use objcopy to transform them, but that's not going to work well in most cases
<marcan>
(I always make this kind of low level stuff as "jump to entrypoint" blobs anyway, so it will work wrapped up in any executable format for the most part)
<rootspring[m]>
marcan: that sounds like it could crash if there are certain things in the elf that can’t be done easily in macho etc etc
<mjg59>
(We use objcopy in the shim build process to transform an ELF object into a PE one)
<marcan>
I won't do those things
<Necrosporus>
What if you both sign the file and replace it?
<marcan>
the elf might as well be a raw binary file
<mjg59>
Yeah
<marcan>
you need to add the file's hash to the secureboot policy
<marcan>
you can't just sign it
<marcan>
the SEP signs the secureboot policy
<Necrosporus>
Shiz, I have experience of booting alternative kernel on Chromebook ARM, the kernel or u-boot has to be signed even with security off
<mjg59>
Once you're targeting a sufficiently low level it's easy enough to ensure that you can transform binaries
<marcan>
Necrosporus: which is a completely different security architecture
<marcan>
no offense but it's not terribly helpful to suggest random things because they happen to work on other platforms
<marcan>
this platform... isn't like any other platform
<Necrosporus>
marcan, where is secureboot policy stored? In iBoot config?
<marcan>
especially the kind used for kernels
<Shiz>
sure, you can do terrible things with ELF (speaking from experience), but it's a rather simple format
<marcan>
Necrosporus: yes, files in the preboot volume IIRC
<marcan>
but they are SEP-signed
<marcan>
and to sign that you need to invoke the SEP in 1TR
<Shiz>
1TR is sorta akin to asserting UEFI physical presence, for an analogue if you're more familiar with EFI terminology
<marcan>
there *may* be some horribly convoluted workaround to do that today... something along the lines of "copy python from macos, run it, use ctypes to invoke the correct methods"; not sure if W^X would prevent that from working
<Necrosporus>
I am not suggesting to do the same thing. I am just telling that I know how somewhat similar thing works. I'm not assuming that apple one is exactly same or anything
<marcan>
but, you know, we could just wait a week or two :-)
<Shiz>
apropos, is there a way to enroll in macOS betas from the commandline or am I going to have to boot up the projection CRT :(
<Necrosporus>
So, even after you have unlocked the bootloader you still need to make apple security processor (analogue of TPM) to sign it for you and you are missing the tool which works with the processor
<marcan>
yes
<marcan>
or rather that tool is missing the "please run my custom kernel" options
<marcan>
even though it's in the manpage
<Necrosporus>
Is the tool open source?
<davidrysk[m]>
Note that if you’re planning to do RE based on OS, the Apple betas are under a significantly more restrictive EULA
<davidrysk[m]>
So if you’re going to do OS RE, better to not run the betas
<Shiz>
can confirm that `sudo /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll PublicSeed` works, fwiw
<marcan>
I don't think so, but even if it were we wouldn't be able to build and run patched versions
<Shiz>
also good to know
<davidrysk[m]>
I believe the betas are still under NDA technically
<marcan>
davidrysk[m]: good poitn
<marcan>
*point
<davidrysk[m]>
I’d have to check the wording
<davidrysk[m]>
The entire release iOS SDK used to be under NDA, many people ignore it, devs got tired of it, revolted a bit, and Apple eventually removed it
<Shiz>
You agree not to decompile, reverse engineer, disassemble, decrypt, or otherwise attempt to derive the source code of any Apple Software (except as and only to the extent the foregoing restrictions are prohibited by applicable law, or to the extent as may be permitted by licensing terms governing use of open-sourced components included with any such Apple Software).
<Shiz>
and a sorta-NDA
<marcan>
that was in the regular EULA too IIRC
<Shiz>
You agree that the Pre-Release Software and any information concerning the Pre-Release Software (including its nature and existence, features, functionality, and screen shots), the Seeding Tools, and any other information disclosed by Apple to you in connection with the Beta Program will be considered and referred to in this Agreement as “Confidential Information.”
<Shiz>
Except as expressly permitted in this Section 6, you agree that you will not disclose, publish, or otherwise disseminate any Confidential Information to anyone other than individuals who are enrolled in the same individual seed as you, or as otherwise expressly permitted or agreed to in writing by Apple.
<rootspring[m]>
Not like anyone cares: hackintosh
<Necrosporus>
Co, can you post something like output of cgpt show / fdisk -l or whatever on apple M1 device SSD? I'm wondering how the stuff is arranged. And if there is some tool like apfs_list_volumes (or whatever) then its output too
<marcan>
also I think that's *intended* for, you know, non public betas
<marcan>
all the other seeds
<j`ey>
raster: hello!
<marcan>
seeing as literally anyone can get the public ones
<Shiz>
well, it doesn't say it's intended for other betas :)
<rootspring[m]>
I thought EULA is not legally binding
<Shiz>
but yeah
<Shiz>
rootspring[m]: EULAs can be binding, but they are not above the law
<Shiz>
if an EULA says you can't RE but legislation (like EU legislation) says you can, EULA can kick rocks
<jn__>
wow, existence of pre-release software is confidential, too
<rootspring[m]>
Beta Program seems to indicate public beta
<Shiz>
(note that I'm not saying EU legislation allows you to RE in all circumstances as IANAL, but it does in certain circumstances at least)
<rootspring[m]>
I mean, they are legit allowing custom kernels
<marcan>
ultimately the point is, I don't think apple *cares*
<Necrosporus>
but in practice it's still not possible
<Shiz>
that's the one 'm reading, jix
<raster>
j`ey: o/
<Shiz>
marcan: in general, yeah
<Necrosporus>
Apple is just trying to have some reason to sue somebody just in case maybe
<Shiz>
i mean, it makes sense to a degree
<Shiz>
especially for AppleSeed betas and other non-public ones
bent_ has quit [Ping timeout: 256 seconds]
<rootspring[m]>
0. Discussion Forums. As part of the Beta Program, you may have the ability to participate in discussion forums provided by Apple about the Pre-Release Software and other Confidential Information that Apple may make available to you. For purposes of such discussion forums, Apple is providing a limited exception to Section 6 by allowing you to discuss certain Apple Confidential Information received by you in connection
<rootspring[m]>
with a particular seed with other seed participants who are in the same seed as you in the Apple designated discussion forum for such seed, and only within this discussion forum. Except for the limited purpose of discussions with other seed participants within such forums, you acknowledge and agree that this Agreement does not grant you the right to copy, reproduce, publish, blog, disclose, transmit, or otherwise
<rootspring[m]>
disseminate any Apple Confidential Information
<rootspring[m]>
Wow
<jix>
are public betas distributed in a way that 5.(b) which excludes from confidentiality information that "is generally made available to the public by Apple," applies?
<rootspring[m]>
They legit state non apple discussion forums are against public beta eula
<Shiz>
i don't think so
<Shiz>
you need to enroll into the seed and accept the EULA
<Shiz>
it's a flimsy barrier, but it's a barrier that makes it technically nonpublic, probably
<rootspring[m]>
Wtf is the discussion forums thing about
<rootspring[m]>
Are u saying macrumors is against eula for sharing public beta info
<Shiz>
technically? probably yes
<Shiz>
does it matter in pracitce? probably no
<rootspring[m]>
Actually, their eula explicitly makes macrumors breaking the eula
<rootspring[m]>
Macrumors is not a forum provided by apple
<rootspring[m]>
And hence is not allowed by eula to share any public or Dev beta info
<rootspring[m]>
Even Reddit is breaking the eula
<rootspring[m]>
Wow
<rootspring[m]>
Is there a law that states that if no one follows a rule, then it doesn’t exist or smth like that
<rootspring[m]>
Given that even Reddit and macrumors is breaking apple eula, I really don’t think apple cares about Asahi Linux at all
<j`ey>
marcan: you added some info about the NOR/SecureROM, do you know if its expected that macOS updates can update iBoot?
plainbits has quit [Ping timeout: 272 seconds]
plainbits has joined #asahi
<raster>
rootspring[m]: they will eventually care if it stomps on any security obfuscation and breaks it .. thus maybe compromising macos security that relied on it. of course all hypothetical at this point.
awordnot has quit [Ping timeout: 264 seconds]
plainbits has quit [Quit: Go to sleep. Night!]
<mjg59>
raster: I'm not aware of any of Apple's security models that rely on obfuscation
<rootspring[m]>
This reminds me of magnethax tbh
<rootspring[m]>
Where any 3ds can be hacked using a magnet and a ds cart
<rootspring[m]>
Possibly due to an oversight by programmers/hardware developers, the 3DS checks to see if Start+Select+X is held down, and if the shell is closed.
<rootspring[m]>
If so, the 3DS will attempt to boot from an NDS cartridge from the bootrom (with bootrom access).
<rootspring[m]>
Hence, the purpose of the magnet is enable a state that the 3DS believes that the shell is closed.
<mjg59>
raster: And they haven't gone after the jailbreak community in any meaningful way, even when they're working on dev releases
<brentr123[m]>
Does anyone know if Marcan is streaming today?
<marcan>
not today
<raster>
it seems marcan knows if marcan is streaming or not... :)
<brentr123[m]>
To yesterday
<brentr123[m]>
Hm, you said that you were going
<mjg59>
Lightsword: In theory u-boot could be used to provide a UEFI environment
<brentr123[m]>
Hm
<Lightsword>
ah, so I guess uboot or something similar would be needed for running UEFI binaries on it then, is uboot what is still what is typically used to run UEFI binaries on arm based systems? little while back was trying to get that working on a raspberry pi 3
<mjg59>
But there's no inherent UEFI
<marcan>
I said I'd work on stuff today, not that I'd stream. I ended up too busy to stream
<Shiz>
Lightsword: the M1 doesn't use EFI
<marcan>
busy right now in fact :p
<Lightsword>
Shiz, sure, I'm talking about adding UEFI using uboot or something
<Shiz>
but any chainloader that could chainload tianocore could work
<Lightsword>
Shiz, does tianocore actually work on ARM?
<Shiz>
but as said before, anyone can do that once its figured out how to have something bootable by iBoot
<Shiz>
yes iirc
<Shiz>
i don't think asahi as a project will focus on EFI becaus well, why bother
<j`ey>
Shiz: yrrc, tiancore/edk2 works on arm64
<j`ey>
*yrc, whatever, silly joke
<Shiz>
thinking to write a mach-O stub for the kernel though for shits n giggles :)
<Lightsword>
Shiz, I guess the main reason for using EFI would be just to have the ability to use more traditional UEFI bootloaders like systemd-boot which have some nice userspace tooling/integrations.
<Shiz>
adding EFI is adding an enormous amount of complexity onto the boot pile
<j`ey>
Shiz: that would be fun
<Shiz>
like, EFI is *ridiculously* complex
<Shiz>
:p
<Lightsword>
I know some EFI firmware is but is that true even for something more minimal like uboot's implementation?
<mjg59>
If you're able to get to u-boot you can present a uefi layer
<Shiz>
figured they'd just chainload edk2 like coreboot would :)
<Lightsword>
I think it's not super common since most embedded ARM systems don't seem to have bootloaders with GPT support...which doesn't really prevent you from using GPT formatted disks but you have to add an additional MBR entry to the boot partition so that you can chain to something that does understand GPT
<marcan>
it's just basic arm32 scaffolding and an RPC framework
<marcan>
I'll port it to arm64
<Lightsword>
marcan, is that basically like a SPL but with a RPC framework?
<marcan>
something like that
<marcan>
it's actually what runs *with* linux on the wii
<marcan>
(on a different CPU)
<marcan>
but more importantly it's dumb and simple and I know how it works and it's trivial to copy-paste-hack into a new platform
<marcan>
which is just what I need for early bringup and experiments
<marcan>
whether it ends up used in the "final version" or whatever, I don't care
<marcan>
but it'll be the beginning
<marcan>
it's a testbench
<marcan>
the main purpose of the RPC thing is to allow experimenting from a PC, remotely, without rebooting, and to be robust enough to gracefully recover from simple faults
<marcan>
which easily makes testing and reverse engineering unknown hardware orders of magnitude faster
<marcan>
like, depending on how much it interacts with other kernel frameworks, I could see gpu bringup happening here first even (we'll see)
<marcan>
it tends to have a much faster test cycle than kernel modules, and be a lot less likely to crash and burn
<marcan>
and will boot faster than a kernel when it does crash and burn
<marcan>
so I might well end up with an entire M1 driver prototype folder full of python scripts that run on the host
<marcan>
and then write the real linux drivers off of that
<marcan>
(extra bonus: adds another layer between any binary reversing of macos, hence more distance for avoiding copyright infringement claims)
<j`ey>
so RPC is stuff like "read" 0x10000, write 0x10000, 0x5435
<j`ey>
?
<Lightsword>
yeah, SPL's do often do a lot of hardware initialization, although is that something iboot would probably be doing a lot of for the M1?
<marcan>
yes
<marcan>
also cache ops, upload, download, call function
<marcan>
I have a thing for compiling little asm blocks in python and running them
<marcan>
so I can run little code snippets
<marcan>
and of course I can trivially add useful special purpose functions
<marcan>
and yeah, thankfully I expect a lot of hw init to be handled by iBoot, but not everything
<eta>
basically the lisp development experience :p
<marcan>
except, you know, python :p
<marcan>
I even have malloc.py lying around somewhere
<Lightsword>
yeah, had to hack NAND bringup into a SPL...was a bit tricky
<Shiz>
the OpenFirmware development experience :eyes:
<marcan>
it's a heap implementation that keeps metadata on the python side, to be used by this stuff :p
<Shiz>
marcan: cursed
<eta>
that is indeed cursed
<Shiz>
none of you are free from sin
<marcan>
a lot of the wii hardware details, including bits that the official software never uses, were worked out this way
<marcan>
by me just trying random bits and seeing what they do
<marcan>
I have scripts somewhere for things like dumping whole register blocks and highlighting changes
<marcan>
so I can poke a register and watch what other registers change
<marcan>
it's all a scattered mess, so this will be a good chance to clean it up a bit too
<Shiz>
would you say it allowed you to
<marcan>
lots of old project based on this approach
<Shiz>
register the changes
<marcan>
/kick Shiz
<eta>
is mini the kernel bootmii ended up using?
<eta>
s/kernel/IOS kernel/
<marcan>
bootmii is mini minus the RPC stuff plus a hardcoded main() that loads a file from SD and runs it
<eta>
oh, nice
<marcan>
same codebase
<marcan>
literal symlinks out when we build bootmii
<marcan>
IOS has nothing to do with mini/bootmii, that's nintendo's code
<marcan>
some microkernel
<Shiz>
nintendo does seem to like microkernels :)
<marcan>
actually I think that was BroadOn?
<Shiz>
yea, IOS is BroadOn
<marcan>
I never quite figured out who did what parts of IOS
<marcan>
on the wii it run with linux for other reasons, and because it has two CPUs
<Lightsword>
ah, that's only on the wii?
<marcan>
originally on the wii linux didn't have direct hardware access, so the mini IPC framework is designed to be *extremely* fast and we were proxying all register reads/writes for stuff like USB on linux through that
<marcan>
then someone found a bit to flip to enable all those peripherals on the linux side
<marcan>
but mini is still used to launch linux from the other cpu and provide a couple other trivial services
<marcan>
none of this applies to M1
<Lightsword>
yeah, I think AMP is mostly used with zynq SOCFPGA's in cases where Linux doesn't have accurate enough timing
<Lightsword>
mostly for IO stuff I think
<eta>
marcan: was that the AHBPROT register?
<sven>
yes
plainbits has quit [Quit: Go to sleep. Night!]
hipboi[m] has joined #asahi
stylefish[m] has joined #asahi
AnonJah has joined #asahi
<AnonJah>
hi
AnonJah has quit [Read error: Connection reset by peer]
<artemist>
There's always the Wii U strategy of "have an actual kernel on PPC but still use that ridiculous ARM core for IO"
<eta>
or the PS4 strategy of "have your southbridge run BSD"
<artemist>
Didn't Wii IOS have a syscall for "zero memory address with the memory priveleges of the kernel"
<sven>
yes, that sys call was something like get_ios_configuration and that 0 meant retail instead of debug or something like that. but that's all off topic :)
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
<Shiz>
/usr/bin/bputil (architecture arm64e): /usr/lib/libbootpolicy.dylib (compatibility version 1.0.0, current version 76.40.19)
AnonJah has joined #asahi
<Shiz>
ls: /usr/lib/libbootpolicy.dylib: No such file or directory
<Shiz>
huh.
AnonJah has quit [Read error: Connection reset by peer]
<Shiz>
dyld seems to be loading it just fine, judging from DYLD_PRINT_LIBRARIES
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
<artemist>
How does the SSD show up to the main application processor? Will it show up as an NVMe controller connected to the PCIe root port?
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
AnonJah has joined #asahi
AnonJah has quit [Read error: Connection reset by peer]
modwizcode has joined #asahi
MuckiSG has quit [Read error: Connection reset by peer]
<davidrysk[m]>
there was a new dyld source code drop, but getting it to compile is a little bit of work
<Shiz>
yeah, am working on it already
<modwizcode>
why do they even do that anyway
<davidrysk[m]>
modwizcode: performance
<davidrysk[m]>
and probably ease of shipping updates/patches
<Shiz>
i have some doubts about performance
jamadazi has quit [Read error: Connection reset by peer]
jamadazi has joined #asahi
<modwizcode>
What's the current blocker on first code exec? Understanding the hardware? I read maybe the unsigned boot stuff wasn't actually deployed yet?
diz3y_ has joined #asahi
<j`ey>
modwizcode: the latter
<modwizcode>
Figured as much
diz3y has quit [Ping timeout: 256 seconds]
<thecake21[m]>
this fact worries me slightly. what if apple changes their mind and never actually deploys this.
<sven>
why would they? they've already spent a lot of engineering effort to make this even possible
<sven>
it probably just wasn't a blocker for the initial release and not 100% done at that point
<modwizcode>
I have a cynical view that they might partially view this as helpful with their attempts to shrug off anti-trust stuff
<rootspring[m]>
Can we somehow make our own bputil using the dylib
<Shiz>
no for multiple reasons
<Shiz>
at least, provided their security model holds up :)
<davidrysk[m]>
bputil is implemented, kmutil is not
<Necrosporus>
It seems that M1 can boot from external drive after all somehow
<roxfan>
AFAIK it needs to have boot files on internal drive
<Necrosporus>
marcan, have you tried to boot your macmini from external drive? Your article only covers booting from internal drive so far
<Alex[m]17>
<Necrosporus "marcan, have you tried to boot y"> +1, the ability to boot from an external drive is important to avoid bricking
ky0ko has joined #asahi
<Necrosporus>
I am wondering how it works, does bootROM load iBoot from external drive, or does it need iBoot and 1TR partition which somehow loads the kernel from external drive in something like kexec. The article I linked doesn't mention the layout of the boot drive, only the method how to make it with proprietary GUI tools
<Necrosporus>
NVRAM contents are listed in System Information under Software > Logs > NVRAM contents, and can still be edited using the nvram command in Terminal.
<Necrosporus>
I'm wondering what does it have in there? It seems to be something similar to u-boot env
<Necrosporus>
Target Disk Mode, to connect to another Mac
<Necrosporus>
Connect Macs using a USB, USB-C or Thunderbolt cable. On the Target, enter Recovery Mode and use the Share Disk command in the Utilities Menu.
<Necrosporus>
Also interesting mode. Does it make mac emulate USB storage? Or it's just network filesystem of some kind