marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
phiologe has joined #asahi-dev
PhilippvK has quit [Read error: Connection reset by peer]
_whitelogger has joined #asahi-dev
phiologe has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi-dev
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 276 seconds]
VinDuv has joined #asahi-dev
<sven> TTY> usb-dwc3@0x502280000: unhandled EP 00 event: XferComplete (0x01), buffer: 80 06 00 01 00 00 40 00 ......@.
<sven> :-)
VinDuv has quit [Quit: Leaving.]
<marcan> very nice :D
<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]
richbridger has quit [Quit: Leaving]
richbridger has joined #asahi-dev