<marcan>
btw, we shouldn't need the tunables for this, right?
<marcan>
I'm thinking it's worth treating tunable application as a kboot thing, and keep m1n1 usage of dwc from doing that
<marcan>
(among other things, because I intend to boot darwin from m1n1, and I don't want to do anything unnecessary - same reason we don't bring up SMP by default until needed)
<marcan>
so like m1n1 can be logically divided into two stages, what it does for itself (which is along the lines of how iBoot would work), and what it does to boot a devicetree-land OS (which in this case involves all that kboot stuff, and also tunables)
<marcan>
I kind of want to make this dwc thing work for the hypervisor, because that will provide much better bandwidth for mmiotrace. though I'm also considering doing it a different way, where I keep a ring buffer in RAM and fetch it from darwin itself.
<marcan>
need to run some experiments...
<marcan>
but I have this vague idea that I want to make the proxy loop callable from exception handlers, and then we can write exception handlers in python - and then that also means we can have a hypervisor with hooks in python, a la that hilarious ps3 thing we did with the bootrom
<marcan>
just... throwing ideas out there
<marcan>
sven: ^
<marcan>
one very important feature of dwc is that it will be synchronous / has flow control - right now we don't have that with serial, which makes certain things unreliable
<marcan>
so a mmiotrace streaming (without blocking other than on usb buffers) over dwc would be a very nice setup
<sven>
marcan: yeah, no tunables required. it works just fine without
<sven>
the only thing it needs it the phy bringup
<marcan>
cool
<sven>
i bring up the clocks,dart,etc. of course but i can either shut these done again or just leave them as-is like iboot does
<marcan>
nah, let's leave things up. this might become a linux earlycon.
<marcan>
though if I get my way with the hypervisor, *that* might also just be a linux earlycon by default (I can implement ARM semihosting probably...)
<sven>
that reminds me.. i need to clean up this linux dart thingy i wrote. that+phy bringup in m1n1 is enough to make linux' usb serial gadget working
<marcan>
yeah, I'll be looking into that side next, once this progress report is done and I wrap up the v3 patch feedback
<marcan>
if we're quick we might be able to get in clock/power into the same merge window
<marcan>
and dart even
<sven>
oh, i have something very dumb and simple for clock/power as well.
<sven>
i'll have to do real work right now, but i can push the current WIP somewhere this evening
<marcan>
cool :)
vimal has quit [Ping timeout: 260 seconds]
mxw39 has quit [Quit: Konversation terminated!]
vimal has joined #asahi-dev
josiahmendes[m] has quit [Quit: Idle for 30+ days]
mofux[m] has quit [Quit: Idle for 30+ days]
mofux[m] has joined #asahi-dev
zkrx has quit [Ping timeout: 245 seconds]
zkrx has joined #asahi-dev
vimal has quit [Quit: Leaving]
jaalsa has quit [Quit: jaalsa]
jaalsa has joined #asahi-dev
odmir has joined #asahi-dev
lethalbit has quit [Read error: Connection reset by peer]
lethalbit has joined #asahi-dev
vimal has joined #asahi-dev
never_released has joined #asahi-dev
never_released has quit [Changing host]
Hetflik[m] has joined #asahi-dev
ldhacker[m] has quit [Quit: Idle for 30+ days]
zkrx has quit [Ping timeout: 245 seconds]
modwizcode has quit [Ping timeout: 246 seconds]
vimal has quit [Ping timeout: 246 seconds]
zkrx has joined #asahi-dev
modwizcode has joined #asahi-dev
<modwizcode>
marcan: does making m1n1 boot darwin imply adding mach-o loading to m1n1? (I can never track down the early boot files in the xnu source dump so I don't quite remember how much it needs)
<modwizcode>
Maybe you're just going to use your python script and flesh it out enough to load darwin?
vimal has joined #asahi-dev
<kettenis>
chainloading macho files already works
<modwizcode>
it does not if you do not load m1n1 correctly
<modwizcode>
er sorry
<modwizcode>
What I meant is that concatenated m1n1 + kernel does not work without loading it correctly
<modwizcode>
I care about that because faking a concatenated image by dynamically loading the -kernel and -initrd qemu parameters after m1n1 allows hassle free boot straight into the kernel
<svenpeter>
Iirc m1n1’s macho chain loading is somewhat limited to only chain loading another m1n1
<modwizcode>
Yeah it's very minimal, and all the logic is currently in the python script, if it was in C I would have just included it into qemu with appropriate licensing
<marcan>
modwizcode: it needs to be extended
<marcan>
the old dumb copy and jump thing is no more, now it does proper mach-o parsing
<modwizcode>
right
<marcan>
but two things are needed to make it work with darwin
<marcan>
well, three
<marcan>
1) it needs to support the mach-o stuff that darwin needs (there is some relocation stuff etc)
<marcan>
2) it needs to know how to move and re-create the bootargs structures and probably tweak some things in the ADT
<marcan>
3) it needs to do all this in a staging area, then run a trampoline that copies it all *on top* of where m1n1 used to be. this is required for the CPU0 reset vector stuff to work, though I bet if we don't do it we're fine as long as the system doesn't go into full sleep
<marcan>
I don't really care about 3, because my plan is to virtualize darwin anyway, and for that I'd hook the whole CPU spinup business anyway
<marcan>
and yeah, a priori I'm just going to do this in the python for now
<kettenis>
it happily loads my preloader-m1 + u-boot image
<marcan>
cute, never tried it
<marcan>
but yeah, no reason for that not to work
<kettenis>
which is cool since it will help me transition away from preloader-m1
<modwizcode>
yeah so I'm going to have to do something qemu side then to get what I want
<modwizcode>
what's the deal with #3 there? Where does the cpu0 reset vector point?
<marcan>
but one reason to do 3) is once we start caring about that sleep mode stuff, normal m1n1 chainloads will break it, which is bad for development
<marcan>
but I don't even know yet if we will *ever* care about that tbh
<marcan>
we'll see
<marcan>
the cpu0 RVBAR points to... the beginning of the page mach-o entrypoint is in.
<marcan>
seriously, that is how they implemented it.
<marcan>
it's a hideous hack.
<marcan>
and it is locked, so it's stuck there (all the other CPU ones are writable)
<modwizcode>
fun!
<modwizcode>
possibly dumb question but is it set to the physical address or the virtual address?
<marcan>
physical
<modwizcode>
has to be physical right?
<marcan>
everything is physical
<modwizcode>
yeah
<marcan>
the whole virtual thing with mach-os is all a lie
<j`ey>
marcan: thats set by iboot right? cpu0 RVBAR
<marcan>
yes
<marcan>
iBoot2
<marcan>
but basically, I'm not going to care about that until I prove to myself that there are *any* worthwhile power management gains to be had from mechanisms that require that
<modwizcode>
that's what I thought, but I figured that iBoot could temporarily init the MMU then shut it down...
<modwizcode>
You don't think full sleep is useful?
<marcan>
because we have retention sleep; it was definitely needed on older CPUs that couldn't powergate without starting there
<marcan>
but newer ones can
<modwizcode>
ah
<marcan>
I'm not convinced full system sleep is useful yet
<marcan>
fine-grained sleep might do all we care about
<marcan>
modern SoCs are really good at that
<marcan>
so, until I hook up a power meter to these things and get numbers out, I won't care
<marcan>
I don't even know if macos uses full sleep
<kettenis>
if even Intel can pull that off...
<marcan>
I guess we'll find out if we chainload it with rvbar pointing to the wrong thing and it all still works
<marcan>
:)
<modwizcode>
heh
<marcan>
but if we do need full sleep, that implies moving away from spin-tables to... something
<marcan>
which needs further talk about non-HVC non-SMC PSCI
<marcan>
so... not a priority right now
VinDuv has joined #asahi-dev
mxw39 has joined #asahi-dev
<marcan>
sven: by the way, we can put the type C port into serial mode from software too; that would let a pixel-style serial cable work ootb, no fancy PD stuff needed. I should implement that in m1n1 with some trivial i2c stuff...
aratuk has joined #asahi-dev
aratuk has quit [Remote host closed the connection]
KindTwo has joined #asahi-dev
KindOne has quit [Ping timeout: 272 seconds]
KindTwo is now known as KindOne
<sven>
marcan: hah, nice!
<sven>
that sounds useful :-)
<marcan>
I mean it's what macvdmtool does :)
<marcan>
but tbh at this point I'm more interested in the CDC ACM version
<sven>
yeah, yeah, getting there :P
choozy has joined #asahi-dev
aratuk has joined #asahi-dev
aratuk has quit [Ping timeout: 245 seconds]
amw has joined #asahi-dev
eta has quit [Ping timeout: 245 seconds]
artemist has quit [Ping timeout: 240 seconds]
VinDuv has quit [Quit: Leaving.]
eta has joined #asahi-dev
choozy has quit [Remote host closed the connection]