Dragonfly has quit [Remote host closed the connection]
PhilippvK has quit [Ping timeout: 480 seconds]
Skinny_Minny has joined #asahi-dev
Skinny_Minny has quit [Remote host closed the connection]
Baby_Bird has joined #asahi-dev
Baby_Bird has quit [Remote host closed the connection]
Carrot has joined #asahi-dev
Carrot has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 02:36:23)]
Cheeky has joined #asahi-dev
Cheeky has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 02:40:43)]
Bean has joined #asahi-dev
Bean_ has joined #asahi-dev
Bean_ has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:07:33)]
Bean has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:07:33)]
Dum_Dum has joined #asahi-dev
Dum_Dum has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:19:47)]
Lefty has joined #asahi-dev
Lefty has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:22:23)]
LaLa has joined #asahi-dev
LaLa has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:25:01)]
Gator has joined #asahi-dev
Gator has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:28:51)]
Diesel has joined #asahi-dev
Diesel has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:31:44)]
Double_Bubble has joined #asahi-dev
Double_Bubble has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:36:48)]
Chicken_Legs has joined #asahi-dev
Chicken_Legs has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:40:21)]
yuyichao_ has joined #asahi-dev
yuyichao_ has quit []
yuyichao_ has joined #asahi-dev
Pansy has joined #asahi-dev
Pansy has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:43:29)]
Turtle has joined #asahi-dev
Turtle has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:46:45)]
Bunny_Rabbit has joined #asahi-dev
Bunny_Rabbit has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:50:03)]
Swiss_Miss has joined #asahi-dev
Swiss_Miss has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:56:33)]
Swiss_Miss has joined #asahi-dev
Swiss_Miss has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 03:59:48)]
Mustache has joined #asahi-dev
Mustache has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 04:03:04)]
String_Bean has joined #asahi-dev
String_Bean has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-05-29 04:06:19)]
<bloom>
"You need at least 70GB for the stub partition"
<bloom>
I am not comfortable with this take me back to userspace
Lightsword has quit []
Lightsword has joined #asahi-dev
Lightsword has quit []
VinDuv has joined #asahi-dev
<marcan>
bloom: I hope we can make this all much saner in the future, but that's currently blocked on a) better understanding what we can do, and b) apple implementing things that are still broken properly
VinDuv has quit [Read error: Connection reset by peer]
thunfisch has quit [Quit: frrrp!]
<dhewg>
I usually break thinks unproperly
VinDuv has joined #asahi-dev
pcm720 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
pcm720 has joined #asahi-dev
pcm720 has quit []
thunfisch has joined #asahi-dev
thunfisch is now known as Guest70
thunfisch has joined #asahi-dev
Guest70 has quit [Ping timeout: 480 seconds]
thunfisch is now known as Guest72
thunfisch has joined #asahi-dev
Guest72 has quit [Ping timeout: 480 seconds]
thunfisch has quit [Ping timeout: 480 seconds]
<jannau>
45GB for the second mac os installation is not enough for installing mac os updates
<jn>
oh wow
<jn>
almost like one of those modern video games
<jannau>
something like 12GB free with nothing but the os installed
<marcan>
jannau: our guide says 70GB, you can't even install it fresh with 50 these days, it fails
<marcan>
the updater/installer is extremely inefficient
thunfisch has joined #asahi-dev
<jannau>
yes, that was intended as confirmation, that 70GB is a reasonable value
bps has quit [Ping timeout: 480 seconds]
<marcan>
OTOH, if all you care about is linux, that partition is useless once you have a user/password set up; you can mostly wipe it and shrink it
<marcan>
I already confirmed you can build up such a partition from scratch; the only choke point is getting credentials for kmutil/bputil
<marcan>
so we can easily implement our own updates; ideally from 1TR, so the flow would be that you update 1TR using the primary macos partition and then use some tooling we provide to update your blobs/iboot2/etc in the m1n1 partition
<marcan>
I wonder if we can get idevicerestore to do 1TR/NAND updates without breaking bootpolicy too badly; if we can then this would be convenient to keep firmware up to date for those who don't want macos
<marcan>
eventually we can probably implement SFR updates from linux, but that will probably take a while until it's safe enough to use
<jannau>
I don't want to get rid of it for now, I'm preparing to boot into it via m1n1/hv
<brentr123[m]>
i dont know if it is a error with building or with my macos version
<brentr123[m]>
or the script
roxfan2 has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
roxfan has quit [Read error: Connection reset by peer]
Fanfwe has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<brentr123[m]>
<bloom "but -- install XQuartz (there's "> should i post a screenshot of what I got on here? If it's broken on 11.2.3 then it might be broken on 11.4 also
<sven>
so you disconnect the usb hub, then connect it again and it works after that?
<bloom>
WTF why is macOS flashing blue and black
<jannau>
on the left usb-c port of a mac mini, right port is configured as "peripheral"
<bloom>
is this what injury looks like i was just trying to update i have SEP enabled and everything
Lightsword has joined #asahi-dev
<jannau>
sven: reconnecting the hub or single devices from the hub works
<sven>
weird
<sven>
the single devices from the hub is no surprise
roxfan2 is now known as roxfan
<sven>
but that reconfiguring the hub itself works is unexpected
<bloom>
oh, went away after a few minutes
<jannau>
with CONFIG_USB_DWC3_DUAL_ROLE=y
<bloom>
wat
<sven>
if i reconnect my yubikey (only usb c thing i have with me right now) it isn't recognized again
<bloom>
you don't have all your devices usb-c? :-p
<bloom>
I still remember the first time I got a Samsung Chromebook Plus (RK3399), specifically to install linux
<bloom>
and then I'm thinking "how to install Linux? You told me it had 2 usb ports. This has no usb ports"
<bloom>
an hour round trip to the Apple store and $20 later, ....
<jannau>
sven: with a usb-c device it's also broken for me. the hub is USB-A with a USB-C to USB-A adapter
<sven>
interesting
<bloom>
diskutil what is this madness
<bloom>
really looking forward to the shiny new intall flows :-p
<bloom>
I guess shrinking APFS will take a while
poljar has joined #asahi-dev
poljar has quit [Remote host closed the connection]
<jannau>
USB rootfs and network are working
<bloom>
nice!
<bloom>
"Macintosh HD"
<bloom>
this is out of date
<bloom>
should be "Macintosh 4k"
<sven>
:>
altwazar-M has joined #asahi-dev
altwazar-M has quit [Read error: Connection reset by peer]
bps has joined #asahi-dev
thunfisch is now known as Guest90
thunfisch has joined #asahi-dev
Guest90 has quit [Ping timeout: 480 seconds]
thunfisch is now known as Guest93
thunfisch has joined #asahi-dev
Guest93 has quit [Ping timeout: 480 seconds]
thunfisch is now known as Guest95
thunfisch has joined #asahi-dev
thunfisch has quit []
Guest95 has quit [Ping timeout: 480 seconds]
<bloom>
marcan: Dumb question but can you run 1TR in the hypervisor?
<bloom>
for poking at the different security model utils?
<bloom>
wait those are userspace you could dyld_preload from 1TR couldn't you heh
<balrog>
bloom: pretty sure that 1TR won't run from a user-signed-OS context
<balrog>
and pretty sure you can't dyld_preload in 1TR either
<marcan>
bloom: the tools work out side of 1TR, it's just the SEP will hate you for not being in that mode
<bloom>
fair
<marcan>
obviously you can't boot the HV in 1TR mode so that's kind of moot
<bloom>
AttributeError: 'super' object has no attribute '_reset_input_buffer'
* bloom
breathes
<marcan>
that again
<marcan>
pyserial version?
<bloom>
yep yep
<bloom>
AttributeError: 'super' object has no attribute '_reset_input_buffer'
<bloom>
er
<bloom>
"Have fun!" ha ha!
Mary8 has joined #asahi-dev
<yrlf>
at this point we could even add a "if not hasattr(serial.Serial, "_reset_input_buffer"): print("check your pyserial version")
<yrlf>
if I remember correctly this happened quite a few times already
<TheLink>
browser games brick breaker
<TheLink>
sorry
<TheLink>
(wrong keyboard)
<yrlf>
the classic incorrect focus oops
<VinDuv>
so older versions of pyserial don’t reset the input buffer on open?
<yrlf>
at least it wasn't your password
<yrlf>
VinDuv: they don't seem to have a function named "_reset_input_buffer"; maybe it's been factored out at some point
<j_ey>
oh, is it too new a pyserial?
<bloom>
and i can't reliably get usb
Mary has quit [Ping timeout: 480 seconds]
Mary8 is now known as Mary
<bloom>
that's a kernel bug on my laptop though
<marcan>
yrlf: fixed
<marcan>
should work with both versions now
<marcan>
bloom: you too?
<marcan>
someone else had that earlier
<bloom>
marcan: no this is a bug with my laptop's kernel
<bloom>
not just m1n1, any usb
<marcan>
well, someone else had m1n1 tickling a kernel bug :p
<yrlf>
from a quick git blame it seems the function was introduced in v3.5
<yrlf>
marcan: well that's a way to "fix" this, but it does work for now ^^
<kettenis>
marcan: me ;)
<marcan>
we don't actually use that method
<bloom>
kettenis: Rk3399 user?
<kettenis>
no, pserial 3.4 issues
<kettenis>
well, I have rk3399 boards as well
<marcan>
it used to be used for the linux tty stuff I think, but that got refactored to use vanilla serial.
<marcan>
it just gets instantiated before boot so no data is lost
<marcan>
so now all we care about is neutering that reset method
<kettenis>
I simply commented out the reset_input_buffer() method
<brentr123[m]>
Hey is there any way I can be a "tester", like if anyone here needs specific programs related to asahi or whatever tested
koorogi has quit [Remote host closed the connection]
DragoonAethis has quit [Quit: No Ping reply in 180 seconds.]
DragoonAethis has joined #asahi-dev
koorogi has joined #asahi-dev
_jannau_ has quit [Ping timeout: 480 seconds]
_jannau_ has joined #asahi-dev
<bloom>
In the mean time, let's poke the display driver from m1n1. This is fun!
* bloom
tries to understand ADT
<kettenis>
bloom: biggest gotcha is that 64-bit addresses/sizes are "little endian" instead of "big endian"
<bloom>
total noob question - why is there an 0x2.. prefix to all the registers that's missing in the ADT?
<kettenis>
ranges
<bloom>
?
<kettenis>
so the ranges property of onr of the toplevel nodes defines an address-space translation just like it does for normal device trees
<bloom>
ah
<kettenis>
the /arm-io node to be specefic
<kettenis>
our device tree doesn't do this because frankly it is just confusing
<bloom>
nod
<bloom>
thnaks
<kettenis>
ok, teaching the OpenBSD/arm64 installer about GPT partitions helped, but something went wrong as I ended up with 2G /home
<kettenis>
the presence of all those apple partitions seems to confuse the code that autosizes the partitions
<bloom>
I still can't figure out where this address is
<bloom>
0x230850000
<bloom>
the 2 goes away with the above thing to 0x30850000
<bloom>
but I can't find that in the ADT anywhere
<bloom>
and m1n1's adt lookup can't find it either
<bloom>
I /think/ it's supposed to be the first reg in disp0 but the size there is too small
<pipcet[m]>
bloom: the display controller? the Corellium source code uses 0x230850030 to set the pixel format
<bloom>
yeah
<bloom>
and there's a ton of display controller regs there beyond what corellium uses
<pipcet[m]>
indeed
<bloom>
ah ha
<pipcet[m]>
so many ways to blank your screen and force a reboot :-)
<bloom>
>>> read32(0x230850030)
<bloom>
>>> read32(0x230050030)
<bloom>
>>>
<bloom>
0x5220
<bloom>
0x5220
<bloom>
memory mirroring, then
<pipcet[m]>
I don't think so, try writing it
<bloom>
...nope. nothing
<bloom>
WTF intensifies
<bloom>
this is why i stick to userspace
<pipcet[m]>
(I set out to hunt the backlight controls, no luck so far)
<bloom>
can't help you there, I have a mini
<bloom>
this is very odd.
<bloom>
the register contents are mirrored but writes are not
<pipcet[m]>
I can blank the backlight at least :-)
<pipcet[m]>
maybe there are just two "surfaces", or "displays", or whatever?
<bloom>
actually, more interesting is that writes to 0x230050030 are ignored
<pipcet[m]>
any idea how to find the frame buffer once macos moves it?
<bloom>
i..e. if I write to 0x230850030 and read it back, it's read back as expected
<bloom>
can't be said of 0x230050030
<bloom>
similarly, if I write to 0x230850030, the value is indeed propagated to 0x230050030
<bloom>
so it's a read only mirror I guess? then why isn't that reflected in the adt
<jannau>
0x230850030 is not in any reg range of the adt as far m1n1 parses it
<pipcet[m]>
I'm no longer entirely sure, but I think the "read only mirror" had different values when I started m1n1 in parallel to macos
<bloom>
jannau: indeed
<pipcet[m]>
jannau: is there a part m1n1 doesn't parse? my parser also doesn't know about that range, which is why it was a bit weird to see it in the corellium code.
<pipcet[m]>
and obviously the display controller is there...
<bloom>
is it possible the adt is incomplete?
<milek7>
pipcet[m]: backlight controls would be in mmio or in separate chip controlled through eg. i2c?
<jannau>
at least when printed it looks like the parsing is not yet complete
<bloom>
milek7: i2c does seem likely
<pipcet[m]>
milek7: probably, yes.
<pipcet[m]>
milek7: there's a master power switch in the SMC but no PWM as far as I can tell.
<bloom>
proposal to rename "i2c" to "-c"
<pipcet[m]>
the weird thing is I haven't seen anything in my mmiotraces yet, so decided to wait for marcan's instead.
<pipcet[m]>
)bloom: I suspect the display stuff is indeed not fully reflected in the adt.
<pipcet[m]>
and I'm not sure how much of the shared memory region is really mmio in disguise.
<bloom>
heh
<jannau>
maybe the size of the first disp0 reg is just wrong. 0x230000000,0x3fc000 and then nothing until 0x231300000 for dart-disp0
<pipcet[m]>
jannau: my ADT also has an "#address-cels" property, so I suspect it wouldn't be the only typo
<bloom>
...does macOS use the ADT? :P
<bloom>
or is this whole file just copied fom an iphone and then they modified the M1 and nobody thought to update the ADT ;-p
<pipcet[m]>
I think it's our best bet, and it's quite accurate as far as I can tell.
<pipcet[m]>
"strings" also shows some strings that look like ADT keys for the macos kernel
<sven>
xnu is using the ADT for sure
<jannau>
yes, the ADT is used xnu. It is part of the boot process and iboot prepares it for the kernel
<bloom>
boring :-p
Glanzmann has quit [Quit: leaving]
<sven>
it wouldn't surprise me if xnu just ignores the size of regions, etc. though
<bloom>
nod
<sven>
there are also some nodes missing in the ADT. there's e.g. a DAPF (some address filter iommu thingy) directly after the sio dart
<sven>
but i don't think these are used by xnu
<bloom>
i just want to figure out how to get mini in 4k ;-p
<sven>
yes please!
<bloom>
:-p
<sven>
you asked for usb and i delivered. now it's your turn! :P
<bloom>
:-p
<pipcet[m]>
oh, iboot doesn't initialize to a decent resolution?
<bloom>
1080p
<pipcet[m]>
ugh
<bloom>
shh working on it
<bloom>
ah-ha! colour mask registers, fun!
<bloom>
for all your, uh, colour masking needs
<marcan>
pipcet[m]: the display controller is handled by a side core
<marcan>
so it's entirely likely that none of these registers are written by macos
<marcan>
and instead it all goes through a mailbox to the DCP
<bloom>
that would make sense
<bloom>
now go to sleep marcan
<sven>
:>
<pipcet[m]>
we'll find out :-)
<marcan>
sven: it's your fault, you didn't find me AFSR1_GL{1,2,12} and I was using the EL2 one for everything and stuff was exploding :'(
<jn>
one big apple and four small ones — reads like a variantion on the big/little penguins to show how many and which CPUs you have :)
<bloom>
jannau: :D
<bloom>
er
<bloom>
jn:
<bloom>
also lol no comments on the state of my desk
<sven>
that setup looks about as clean/messy as mine does :D
<kettenis>
much cleaner than mine ;)
<kettenis>
I have two arm boards, a breadboard, a breakoutboard and two usb-to-serial converters (one acting as a power supply) just to get serial out of the mini
* jn
read "state of my disk" and ended up a bit confused
<jn>
my desk is of course worse
<marcan>
by the way, the hypervisor vuart thing works well enough for xnu now, if anyone wants to try
<marcan>
it's enabled by default now
<marcan>
spits it out the second CDC ACM interface
<jn>
does the non-debug XNU kernel use the UART for log messages, too?
<bloom>
marcan: go the f*** to sleep
<marcan>
yes, if you ask it to, IIRC
<marcan>
bloom: I was taking a shower!
<bloom>
woah, TMI, no need to get all defensive ;P
<bloom>
(/s)
<marcan>
I already told bloom how to run the hv, so now she gets to teach everyone else; goodnight :p
<bloom>
dammit
<bloom>
c'mon where is this display hidden mickey bit
ayydavay[m] has joined #asahi-dev
<bloom>
>>> write32(0x230850000 + (14*4), (7<<2))
<bloom>
It's... Cyrillic?
<bloom>
:-p
<pipcet[m]>
right-to-left video? :-)
<bloom>
pipcet[m]: See, if it were right-to-left the whole screen would flip
<bloom>
not just one char at a time
<bloom>
in palce
<pipcet[m]>
oh, byte order then?
<bloom>
(change 7 to 0...7 for effects at different sizes)
<bloom>
"reverse every N pixels horizontally" or something
<bloom>
pipcet[m]: I do appreciate that you had mini up to try that :-p
<jn>
Oh, fun. i've had that kind of effect with linux on a PowerMac with an nvidia GPU
<bloom>
any idea why you'd want it? :-p
<j_ey>
bloom: can you take a pic?
<jn>
to look like a kewl hakker :P
<bloom>
jn: Assuredly you want write32(0x230850000 + (14*4), 0x1d)
<bloom>
:-p
<bloom>
j_ey: I did my moving photos from phone is too many steps
<bloom>
s/my/but/
<j_ey>
bloom: hehe no worries
<pipcet[m]>
bloom: beats me. If you want to see something really weird there is an MMIO range writes to which will temporarily "highlight" (make whiter) bits of the screen...
<bloom>
pipcet[m]: hehe
<bloom>
ultimately i'm more looking for things like texture tiling
<pipcet[m]>
(I know virtually nothing about modern graphics. I understand it's not just bitblitting anymore?)
<bloom>
Display controllers are still simple enough
<bloom>
It's 3D that's really out there
<bloom>
This is all just display
<Bastian[m]>
I know nothing of graphics/display stuff but the whitening of parts of the display might be related to https://prolost.com/blog/edr ? total guess though
<pipcet[m]>
oooh, that sounds likely
klltkr has joined #asahi-dev
<pipcet[m]>
bloom: now what I'd like to know is why macos gives me a pink screen of death just before it reboots when I do horrible things to it.
<bloom>
Bastian[m]: oh, interesting
<bloom>
pipcet[m]: heh
<bloom>
found the swizzle field
<bloom>
^register
<bloom>
this tells me the Corellium code is overcomplicated
<pipcet[m]>
wait, I thought they just did a single register write?
<bloom>
They setup the display controller to do fancy colourspace conversion stuff
<bloom>
which is very much not necessary if all you want is reordering channels
<pipcet[m]>
which version is that? The one I looked at only writes 0x5000 to 0x230850030
<bloom>
and then it writes a bunch of things to 0x230850178, 0x230850188, ...
<pipcet[m]>
you mean the code they dropped on january 20? :-)
<bloom>
Yes
<bloom>
oh, they did change that. ok.
<bloom>
There you go, then
<pipcet[m]>
thought I was missing something in the code, sorry :-)
VinDuv has quit [Quit: Leaving.]
<bloom>
regardless neither version of the code had the swizzle register, so still a win
ayydavay[m] is now known as davay[m]
<bloom>
I see code in m1n1 referring to an rgb565 framebuffer mode?
<pipcet[m]>
it's not immediate, there's intermediate states that shouldn't be there
klltkr has quit [Ping timeout: 480 seconds]
<bloom>
so many of these wegde the display controller ugh
<bloom>
thank marcan for reboot(1)
<pipcet[m]>
bloom: I don't have many notes because I was looking for something else but 0x230046330/0x230046328 seemed very weird to me. They're counters increasing at different rates, if I'm reading this correctly, at least on this machine.
<pipcet[m]>
(yeah, it's a large MMIO space...)
<bloom>
counter indeed..
<bloom>
dunno
<bloom>
use it as a timer? :-p
<bloom>
ah ha! ok what's happening here
<bloom>
compatible-device-fallback = iPad8,6
<bloom>
lololol
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
<bloom>
I think this /might/ be related to cursor planes, or overlay planes
<bloom>
well, I find the brightness field
<pipcet[m]>
what does it do?
<bloom>
changes the brightness
<bloom>
unrelated to backlight, this is an ext monitor on a mini
<bloom>
>>> write32(0x230850000 + (2*4), 0x1ff)
<bloom>
if you want to play with it, it's an 11-bit signed integer (i.e. values above 0x3ff make it darker)
<pipcet[m]>
weird, I would have expected two registers, one each for white level and black level
<bloom>
ok this is definitely some kind of overlay/cursor