<bgb>
seems lines 637-664 give more detailed info.
<modwizcode>
Heh I didn't see that when I first looked at this file awhile back
<bgb>
not quite clear about the whole picture, but got more info to understand why using this address to get control of M1
<modwizcode>
Yeah I'm not suer if it honestly matters only marcan would know. As far as I know once iBoot kicks execution over to you, you're executing from a physical address and the virtual load address is nothing. I'm assuming that iBoot would relocate things using the virtual base address if you had any mach-o relocations, but that's now how M1N1 works (for good reason)
<modwizcode>
That makefile for xnu is insane though, they seem to specify everything via linker arguments instead of using a linker script for anything
<marcan>
bgb: it's the same as xnu, though I suspect "0" would work but I never tried it
<marcan>
(back when I was writing that mach-o header thing I started out making it similar to xnu to eliminate errors, since I had to get that much to work blind)
<marcan>
that address means nothing, for what it's worth
<marcan>
for us, anyway
<marcan>
it's just a hack because mach-o is a mildly brain-dead format that does not support the concept of physical addresses
<marcan>
it's not even the real virtual address of xnu any more, thanks to kASLR
<marcan>
so it's really a completely arbitrary number at this point, with no significance to anything whatsoever at runtime; I just don't know if iBoot has any restrictions on it
<marcan>
basically it just means all addresses in the mach-o format are relative to that number
<marcan>
and iBoot translates it to wherever the hell it wants in physical address space
anthonyo has joined #asahi-dev
anthonyo has quit [Client Quit]
_whitelogger has joined #asahi-dev
<bgb>
maran: I saw more about m1n1.ld, the m1n1 code itself is linked at 0, then you tell iBoot which loads the m1n1.macho: please load m1n1 to vmaddr and transfer
VinDuv has joined #asahi-dev
<bgb>
xnu kernel is linked at 0xFFFFFE0007004000 (according to xnu makefile...-Wl,-image_base,$(ARM64_LINK_ADDR)), so there is no reason to be wrong for m1n1 using this address
<bgb>
not sure if this is reasonable. anyway, nice approach to convert elf to macho!
<marcan>
bgb: vmaddr is not used for anything other than computing addresses
<marcan>
iBoot loads m1n1 to wherever it wants, in fact it's randomized in a 32MB window every boot due to kASLR
<marcan>
the only thing those vmaddrs are used for is internal to the mach-o format, and as a quirk, also as the base for some pointers passed from iBoot, but those are kASLR slid anyway so that base vmaddr isn't correct either, iBoot tells you the one it *actually* used
<marcan>
I'm actually not even sure if virt_base is based on that address...
maor26 has joined #asahi-dev
<bgb>
ok, I do notice the top_of_kernel_data of bootargs changes every time when transfered from iBoot
VinDuv has quit [Quit: Leaving.]
<marcan>
yes, so does the m1n1 base address and certain bits of virt_base
mellotron1[m] has quit [Quit: Idle for 30+ days]
jrmuizel[m] has quit [Quit: Idle for 30+ days]
jinen[m] has quit [Quit: Idle for 30+ days]
robinp_ has joined #asahi-dev
robinp has quit [Ping timeout: 258 seconds]
robinp_ is now known as robinp
<bgb>
so, that is why m1n1 startup code is written in PIC, and C files compiled with -fPIC.
<marcan>
yes
robinp_ has joined #asahi-dev
robinp has quit [Ping timeout: 240 seconds]
bgb has quit [Ping timeout: 264 seconds]
zkrx has quit [Ping timeout: 276 seconds]
bgb has joined #asahi-dev
zkrx has joined #asahi-dev
bgb has quit [Ping timeout: 240 seconds]
bgb has joined #asahi-dev
bgb has quit [Ping timeout: 246 seconds]
bgb has joined #asahi-dev
bgb has quit [Ping timeout: 272 seconds]
<bastilian>
After ordering a handful of USB-C cables, I did find one with SBU1/2 lines attached to my external hard drive. So I finally could play around with the serial console. :D so fun.
bgb has joined #asahi-dev
bgb has quit [Ping timeout: 265 seconds]
odmir_ has joined #asahi-dev
odmir has quit [Ping timeout: 258 seconds]
bgb has joined #asahi-dev
bgb has quit [Ping timeout: 246 seconds]
bgb has joined #asahi-dev
bgb has left #asahi-dev [#asahi-dev]
acelogic has quit [Ping timeout: 240 seconds]
bgb has joined #asahi-dev
<bgb>
marcan: can we disable HCR_EL2.E2H bit? I just wanted to clear this bit in m1n1_main, but failed
thestr4ng3r has quit [Read error: Connection reset by peer]