marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<marcan>
bloom: feel free to set +M if we get another attack
<amw>
Can update it some more and submit a pull request if your interested - it's quite small change
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
VinDuv has joined #asahi
<amw>
Question: Can I run linux under m1n1? The run_guest.py tool requires a Mach-O payload
<amw>
When I run the linux.py tool on Linux my USB devices appear to disappear? i.e. m1n1 dis-appears but I am using marcan/dart/dev branch which tries to use dwc3 USB driver ? - See https://paste.debian.net/1201729/
bgb_ has joined #asahi
<VinDuv>
I’m pretty sure the m1n1 USB devices will always disappear if you start Linux directly with linux.py; if Linux itselfs starts emulating a USB serial port it will reappear, but the transition won’t be seamless
<VinDuv>
You should be able to run Linux under the hypervisor though; for this I think you need to run m1n1 under the hypervisor, then start linux.py with the hypervised m1n1
<amw>
VinDuv: Ok - run_guest.py with m1n1.macho and then try linux.py?
<VinDuv>
yes, I was thinking about that, you should be able to run_guest a m1n1 with concatened payloads and the payload will run under HV
<VinDuv>
might be easier
bgb_ has quit [Ping timeout: 480 seconds]
<amw>
Hmm plain chainload.py boots up the kernel which boots up to init, but the script times out waiting for serial port to appear. I guess kernel is run at EL2 not under m1n1
<amw>
Hmm: Some success with original suggestion run_guest.py -S m1n1-payload.macho - I get a shell, kernel loaded, but all CPUs are started and I don't know where to jump to with kboot_boot?
<amw>
Oops I missed the start command - starts up the kernel ...
<VinDuv>
you should run a picocom on the secondary m1n1 USB device to see the boot logs
<marcan>
amw: do you have FileVault enabled?
<amw>
VinDuv: Yes that works (no CRs on linux console messages but initrd is good)!
<amw>
marcan: Don't think so. Never used FileVault as far as I know - presume it's a MacOS thingie
<marcan>
encryption
<marcan>
I believe the security model is that if you have FileVault enabled, you need to authenticate before being allowed to run your own code
<marcan>
unless they changed it in 11.4, which they might have
<amw>
Aaah - your referencing my original 1TR questions! - I would have to boot back to MacOS and work out how to check if FileVault is set up to answer
<marcan>
System Preferences > Security & Privacy > FileVault I believe
<marcan>
VinDuv: the problem with running m1n1/linux under the HV is there is no vUART input support yet; been meaning to add that...
<marcan>
amw: re run_guest.py, open up a picocom on the secondary USB CDC-ACM device
<marcan>
you should see m1n1 boot and at least linux earlycon output
<marcan>
but I expect the linux UART driver to really hate my lame vuart
<marcan>
(once it loads)
<marcan>
also, if the devicetree is instantiating the USB device that the HV is using, that will go very wrong; there is no logic in m1n1 to disable that in the devtree if it's missing in the ADT, maybe that should be added
<marcan>
at least I guess I should make the HV unmap that from the guest :-)
<amw>
See https://paste.debian.net/1201733/ to see the run_guest.py output ttyACM0 followed by the linux kernel console serial output on ttyACM1
<marcan>
kind of impressed it got to a shell, heh
<marcan>
no kernel debug args though I guess
<amw>
marcan: It's just a initrd that prints in a loop for ever till it locked up at 100?
<marcan>
I guess? I didn't write that initrd
<amw>
No it's some rubbish debug one I had from months back - just to prove I can run something (with out any input)
<amw>
Now I have linux under the HV I need a way to dump the registers and see where it is executing et cetera.
<marcan>
yup
<marcan>
I've wanted to add a concat thing to set kernel commandlines more easily, something like just 'cmdline:' + commandline + '\0' as a payload format
<amw>
It says all the CPUs are running.... Is that right?
<marcan>
but for now you can stick it directly in the devicetree
<marcan>
no, it shouldn't
<marcan>
FDT: CPU 1 is not alive, disabling... etc
<marcan>
only CPU 0 should be alive when running under the HV
<marcan>
unless you mean the beginning bit
<marcan>
the HV *does* start all CPUs
<marcan>
then only uses CPU0 except it puts the watchdog on CPU1 (or was it 7?)
<marcan>
so technically all CPUs are up but only CPU0 is usable
<amw>
The run_guest.py prints out "starting secondary CPUs..." and then 1 ...7 started...
<marcan>
yes
<marcan>
but the guest only sees CPU0
<marcan>
that's just because the m1n1 smp support is initialized with a one shot function that starts all CPUs
<marcan>
and the HV wants to use one of the secondaries for the watchdog
<amw>
ok - got me excited (and confused :-)
<marcan>
it shouldn't be too hard to make the HV support SMP
<marcan>
but I need spinlock primitives and some trivial emulation of the cpustart hardware :)
<amw>
Is there a command to read a register from the CPU0 ? I'm thinking the PC
<marcan>
from the shell? the shell runs on cpu0, you're in that context
<marcan>
hv.ctx.elr is the guest return address (i.e. next instruction to be executed after returning)
<marcan>
hv.ctx.regs[0] etc will give you the GPRs
<marcan>
you can get a backtrace with `bt`
<marcan>
I should add more proper debug-friendly commands, like a "show regs" thing :)
<marcan>
right now it only does that on exceptions
TheJollyRoger has quit [Remote host closed the connection]
<amw>
Wow! That stuff all works great
<marcan>
honestly it should just expose a gdb stub at some point, so you can just use standard tools to load symbols etc
TheJollyRoger has joined #asahi
<amw>
I'll try to map it by hand to symbols - it looks like it has the same stack trace all the time - halt loop?
<amw>
Woops just crashed my hv ... disassemble_at(0xffff8000102fdc3c, 8) -> it just rebooted...
<VinDuv>
this is definitely not the right way to do it, but if you set hv.sym_offset = hv.tba.virt_base = hv.macho.vmin = 0 and hv.pac_mask = 0xffff000000000000 I think you should get your symbols…
<VinDuv>
If I’m not mistaken your patch to addr() should not be needed now that you have symbols — if you revert it and hv._reloadme() it you should have a nicer output