bear24rw has quit [Read error: Connection reset by peer]
bear24rw_ has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
modwizcode has quit [Quit: Later]
stormclad has joined #asahi-re
stormclad has quit [Remote host closed the connection]
stormclad has joined #asahi-re
* rwhitby
now has an M1 mac mini ...
<jn__>
\o/
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
* rwhitby
notes the System Information Thunderbolt Firmware Version is 0.0, whereas on Intel MBP it's 55.3
aratuk has quit [Read error: Connection reset by peer]
aratuk has joined #asahi-re
<rwhitby>
Looking at the back of the M1 Mini, TBT Bus 0 is the left-hand port (closest to ethernet) and TBT Bus 1 is the right-hand port (closest to HDMI).
aratuk has quit [Read error: Connection reset by peer]
aratuk has joined #asahi-re
<rwhitby>
M1 does indeed do USB4: nter USB packet (USB 4.0) | 4 bytes (00 E0 67 26)
aratuk has quit [Read error: Connection reset by peer]
<rwhitby>
USB Product ID0x7408
<rwhitby>
BCD Device20.7.7
aratuk has joined #asahi-re
<rwhitby>
Specification RevisionVersion 3.0
<rwhitby>
USB Highest SpeedUSB4 Gen3
<rwhitby>
And it does support a USB4 Goshen Ridge Hub
<rwhitby>
Including DP Alt Mode on all 3 downstream ports on the USB4 hub.
krbtgt has quit [Quit: leaving]
krbtgt has joined #asahi-re
stormclad has quit [Ping timeout: 264 seconds]
stormclad has joined #asahi-re
<davidrysk[m]>
rwhitby: yep, they advertise USB4 but not TBT4, because it doesn't support all the requirements of TBT4
<rwhitby>
Well, TBT4 is just an Intel trademark which is identical technically to a fully-optioned USB4.
stormclad has quit [Ping timeout: 260 seconds]
roxfan has quit [Remote host closed the connection]
aratuk has quit [Ping timeout: 246 seconds]
roxfan has joined #asahi-re
aratuk has joined #asahi-re
aratuk_ has joined #asahi-re
aratuk_ has quit [Read error: Connection reset by peer]
aratuk__ has joined #asahi-re
aratuk__ has quit [Read error: Connection reset by peer]
<artemist>
How does the kernel get the device tree? Does iBoot pass a pointer to it in a register?
stormclad has quit [Ping timeout: 240 seconds]
<Shiz>
artemist: I'm a bit unclear about that part of the boot proces as well; my guess rn is that the locations are hardcoded by the stage before iboot and loaded into mem
<roxfan>
on iphone devicetree was in a separate file which was decompressed and passed to the kernel as a blob IIRC
<artemist>
If the Linux devicetrees and apple device trees are not binary compatible (or I need to change the compatible strings to fit Linux requirements) I wonder if it would be useful for me to write a converter
<davidrysk[m]>
j313ap is the macbook air, t485ap is the dtk
<Shiz>
if you want to get the devicetree yourself without having access to an m1 cpu, its in the ipsw file :)
<artemist>
Yeah, I'll try playing with that this weekend
<artemist>
Looking at marcan's dump... this is a mess
<marcan>
the devicetree will be way too different for converters to be useful
<marcan>
the formats are different, but even if they were the same, the way devices are implemented is different
<marcan>
they are both descended from the same concept, and the overall structure is quite similar
<marcan>
but there is no hope of making them "compatible"
<marcan>
instead, what will have to happen is we maintain parallel device tree images for all supported mac boards, and then if any dynamic stuff needs to be carried over, our bootloader will take care of translating only those bits
<marcan>
I did this for PS3, where I would pull some info from the hypervisor database and into the devicetree
<artemist>
That makes sense
<marcan>
keep in mind that with includes and overlays and such, this is all very nicely maintainable in linux
<artemist>
I was thinking that could be useful to make the bootloader compatible with all devices, then I realized you could just read "model" in the root and just read a device tree off the FS
<Shiz>
is the concept they're descending from concrete or abstract? :p
<artemist>
Weren't device trees an OpenFirmware thing?
<artemist>
Okay, yeah, now I get why apple used them...
<marcan>
yeah the bootloader should support all devices of course, it can just embed all devicetree blobs or read them from storage, depending on dependencies/etc
<marcan>
ideally we want to make this quite universal/transparent for users
<davidrysk[m]>
an ioregistry dump from macOS might be useful as it is populated with dynamic as well as static information
<marcan>
yup, I have one of those too
<davidrysk[m]>
ah nice
<davidrysk[m]>
among other things it tells you what brcm firmware blobs you need
<artemist>
Funny how the device tree has several references to 10 gigabit ethernet and the AQ107 10 gigabit ethernet controller
<marcan>
isn't there a 10gbe m1 mac mini coming or something?
<davidrysk[m]>
there's a 10GbE model of the mac mini that's apparently available to datacenters or something
<marcan>
I thought I read that somewhere
<marcan>
ah, that's what it was
<artemist>
Yeah, somone leaked that there would be one
* JTL
wonders if AWS wants it
<artemist>
Putting PCIe devices in the device tree feels weird to me
<JTL>
:P
<artemist>
Though I guess it makes sense if some of them are connected over both PCIe and i2c
aead has joined #asahi-re
<artemist>
I wonder if anything useful is in nvram (in a SPI NOR connected to SPI1)
<artemist>
Decide whether to play a boot chime?
<davidrysk[m]>
it would be nice for someone to dump the NOR
<davidrysk[m]>
but it probably just has the second stage iBoot
<davidrysk[m]>
(all of the bootloaders are iBoot — the first (ROM), second (NOR), and third (preboot partion) stage), just different "flavors"
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #asahi-re
Tokamak has quit [Ping timeout: 246 seconds]
<artemist>
Does DFU happen in the first stage loader? Bricking something by messing up the NOR is not my idea of fun
<marcan>
DFU happens in the boot ROM. however, the NOR includes critical factory data, so if you wipe it, only apple can fix that (they'd still use DFU, but special software and tools to basically redo part of the manufacturing process)
<artemist>
Mean
<marcan>
like, serial numbers and such
<marcan>
I mean, this is the case for most devices
<marcan>
but there is no reason for us to ever touch NOR
<marcan>
(we might not even be able to at all)
<marcan>
however, if we can read it, I'll add that to our installer etc so that people can keep a backup
<marcan>
you'd have to take the thing apart and use a hardware flasher though
<marcan>
I doubt apple left a way for us to flash NOR via DFU (since it's all codesigned)
<davidrysk[m]>
it's interesting that the OS has a partition called FactoryData
<marcan>
I believe that's copied from NOR or such
<davidrysk[m]>
sorry, not OS, but one of the partitions in the Apple_APFS_ISC
<marcan>
maybe I should just dd /dev/zero on the mini and prove DFU works... :p
<artemist>
I have some probing tools designed for working with small packages on PCBs
<artemist>
I just don't own a mac mini
<marcan>
davidrysk[m]: I think apple calls them SecureROM, iBoot1, iBoot2 or something like that, but yes they're all the same codebase
<davidrysk[m]>
Yeah, my question would be whether it copies everything from the NOR
<marcan>
we might end end up with a boot chain along the lines of SecureROM -> iBoot1 -> iBoot2 -> mini -> U-Boot -> Linux :^)
<davidrysk[m]>
SecureROM -> LLB -> iBoot
<marcan>
wonder if any embedded systems have more stages than that
<davidrysk[m]>
but apparently they got rid of LLB in the A10
<davidrysk[m]>
which means SecureROM loads iBoot directly? huh
<davidrysk[m]>
then what's in the NOR
<Shiz>
./preboot/System/Volumes/Preboot/00000000-0000-0000-0000-000000000000/boot/<x>/System/Library/Caches/com.apple.factorydata: broken symbolic link to /mnt6/FactoryData/System/Library/Caches/com.apple.factorydata
<Shiz>
/mnt6 :)
<JTL>
what does adding u-boot in the chain do for you?
<davidrysk[m]>
UEFI support among other things
<marcan>
possibly external media boot, if we want to enable that
Tokamak has joined #asahi-re
<marcan>
I won't use U-Boot initially
<Shiz>
JTL: give you a bunch of ways to boot other kernels
<JTL>
fair
<marcan>
Shiz: ha
<marcan>
davidrysk[m]: iBoot is in the NOR
<artemist>
IIRC there are some NICs that flat out use Linux in their option ROM
<marcan>
(the first stage)
<artemist>
If you want boot options then mini either needs to parse extlinux.conf (a complete pain) or you need u-boot
<Shiz>
so iBoot.img4 seems encrypted or at least not immediately readable
aratuk has joined #asahi-re
aratuk_ has quit [Ping timeout: 272 seconds]
aratuk has quit [Remote host closed the connection]
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 264 seconds]
_whitelogger has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Ping timeout: 260 seconds]
Necrosporus_ has joined #asahi-re
Necrosporus is now known as Guest90598
Necrosporus_ is now known as Necrosporus
Guest90598 has quit [Killed (card.freenode.net (Nickname regained by services))]
bear24rw has joined #asahi-re
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Ping timeout: 265 seconds]
maor26 has joined #asahi-re
marcan changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | Keep things on topic | GitHub: https://alx.sh/g | Logs: https://alx.sh/l/asahi-re
marcan changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | RE policy: https://alx.sh/re | GitHub: https://alx.sh/g | Logs: https://alx.sh/l/asahi-re
<brinly>
is there any .kexts that are high priority to make notes @marcan ?
<marcan>
not at the moment, first thing I'm going to look at is the kernel itself just to make sure I understand the entrypoint, and after that I want to get the mini thing up and running so we can dump registers/etc
<marcan>
it's worth not throwing things into a disassembler until we *know* we need to
konstater has joined #asahi-re
GrumbleTurtle has joined #asahi-re
<brinly>
heh, will check back at end of January and see how it’s going :)
<marcan>
:)
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 240 seconds]
<Necrosporus>
marcan, is posting say NOR dump illegal?
<marcan>
obviously, it would contain iBoot
ronyrus[m] has joined #asahi-re
<davidrysk[m]>
I find it more useful to e.g. run `strings` on things at this point
aratuk has joined #asahi-re
brinly has quit [Quit: Connection closed for inactivity]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aead has joined #asahi-re
aead has quit [Changing host]
stormclad has joined #asahi-re
<davidrysk[m]>
huh, looking more closely at xnu src it does seem that they used EL3 for the xnu monitor in the older chips, and then did CTRR and later KTRR to eliminate the need for EL3
<davidrysk[m]>
xnu-7195.50.7.100.1/osfmk/arm64/machine_routines_asm.s has a monitor_call() function, but the monitor-side code seems to have been removed from the xnu src
stormclad has quit [Ping timeout: 256 seconds]
<Shiz>
did we have a confirmation on what CTRR stood for?
<Shiz>
davidrysk[m]: re:string, libbootpolicy.dylib is *extremely* verbose
<Shiz>
almost like it was compiled in debug mode :p
<davidrysk[m]>
Shiz: can you put your fixed-up dyld_shared_cache extractor somewhere?
<davidrysk[m]>
I was gonna fix it up myself but I'd rather not duplicate work, hah
<Shiz>
yeah, but beware it's just as much as a hackjob as the one it's replacing
<Shiz>
:p
<davidrysk[m]>
yeah idc
<Shiz>
one sec
<marcan>
Shiz: Configurable Text Readonly Region
<Shiz>
ah, configurable
* Shiz
updates the boot page
<marcan>
or maybe not
<marcan>
I might have made that up :D
<marcan>
ah I didn't
<marcan>
it's in man bputil
<Shiz>
haha
<davidrysk[m]>
I was reading about Memory Protection Keys for Userspace for x86_64 some time ago and it seems horrible compared to what Apple is doing
<davidrysk[m]>
> This post tries to detail the mechanism used in Apple’s A10 chips and later to prevent modification of an iOS kernel at runtime.
<davidrysk[m]>
> Older chips attempt to do this via a monitor program loaded in EL3, which is inherently flawed and bypassable though as detailed in “Tick Tock” by xerub.
<davidrysk[m]>
(which isn't what we're doing here)
<Shiz>
:)
<modwizcode>
Does apple actually intend kext dev to continue?
<davidrysk[m]>
modwizcode: they wrote a fair amount of documentation for it
<davidrysk[m]>
I expect to see it for a few specific use cases: primarily filesystems and stuff that requires maximum performance
<modwizcode>
For recent stuff?
<Shiz>
so that function seems to add a linked manifest called "fuos"
<davidrysk[m]>
though I do hope they implement a proper FUSE layer in macOS 12
<Shiz>
which seems to match with sven's earlier recall that fuos means fully untrusted OS
<modwizcode>
I wouldn't be surprised if they added a FUSE like layer, they've definitely tried to move most of the driver stuff into userspace
karthek has joined #asahi-re
karthek has quit [Remote host closed the connection]
<davidrysk[m]>
it makes lots of sense to move as much of the driver stuff as possible to userspace
<davidrysk[m]>
and since Apple controls the hardware down to the architecture level now, they can modify the hardware design as needed to avoid the typical problems with microkernels
<davidrysk[m]>
I kinda want to see them move their own drivers into userspace as much as possible too, in order to reduce kernel attack surface
<davidrysk[m]>
that said, there still are uses for kernel/kext programming
<modwizcode>
Yeah I doubt they can get rid of them entirely with something like a Mac Pro line around that supports more than just USB addons
<modwizcode>
I guess thunderbolt might expose stuff too
<davidrysk[m]>
they're heavily leveraging IOMMUs to reduce the exposure that Thunderbolt and PCIe would otherwise cause
<davidrysk[m]>
but in some cases you still need maximum performance
<Shiz>
so it seems that "kcOS" may refer to a custom kernel cache (but still macOS)
<Shiz>
while "fuOS" may refer to a fully custom OS
<Shiz>
the boot policy has optional linked manifests for each of those
<Shiz>
and an extra field for the img4 hash of either of them
<Shiz>
updated glossary
<Shiz>
speculating that if coih and/or a linked auxk/fuos manifest exists, it will go through loading that instead of nsih
bear24rw has joined #asahi-re
aratuk has joined #asahi-re
aratuk has quit [Ping timeout: 260 seconds]
bear24rw has quit [Remote host closed the connection]
DarthCloud has quit [Read error: Connection reset by peer]
DarthCloud has joined #asahi-re
klaus has joined #asahi-re
aratuk has joined #asahi-re
stormclad has joined #asahi-re
aratuk has quit [Ping timeout: 240 seconds]
stormclad has quit [Ping timeout: 260 seconds]
HoneyTubes has joined #asahi-re
maor26 has quit [Ping timeout: 260 seconds]
HoneyTubes has quit [Remote host closed the connection]