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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
chadmed has quit [Remote host closed the connection]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
hexchain has quit [Quit: Goodbye!]
hexchain has joined #asahi
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
rkt has quit [Quit: rkt]
rkt has joined #asahi
chadmed has joined #asahi
chadmed has quit [Ping timeout: 480 seconds]
kajiryoji has quit [Ping timeout: 480 seconds]
kajiryoji has joined #asahi
<sven>
:D
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi
jacoxon has joined #asahi
aleasto has joined #asahi
rkt has quit [Quit: rkt]
rkt has joined #asahi
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
rkt has quit [Quit: rkt]
rkt has joined #asahi
darkapex has joined #asahi
darkapex1 has quit [Read error: Connection reset by peer]
rkt has quit [Quit: rkt]
rkt has joined #asahi
bps2 has quit [Ping timeout: 480 seconds]
FikretCanGrbz[m] has joined #asahi
FikretCanGrbz[m] is now known as cangurbuz[m]
<VinDuv>
ok, m1n1 seems to mostly work on the 14" MBP with UART_BASE changed and mmu, pmgr and usb removed :)
<sven>
Yeah, who needs a mmu or usb anyway :D
<sven>
Weird that the mmu fails though. Maybe just some new chicken bits though
<sven>
I remember how enabling mmu broke without those as well
<sven>
Usb probably fails because it can’t be powered on without pmgr
<VinDuv>
yeah, chickens.c doesn’t recognize the cpu model so it applies half of the chicken bits I think
<sven>
Hrm. Or maybe they changed something with SPRR/GXF but that would surprise me for this iteration
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
<VinDuv>
The MMU error: https://paste.debian.net/plainh/72286d9b (I also had a SError after but it was caused by the automatic reboot poking the wrong addresses for the WDT; WDT_BASE should be set to 0x2922b0000 in start.S)
<sven>
ah
<sven>
they probably moved the TZ registers
<sven>
you can just make mmu_unmap_carveouts return immediately
<sven>
though that error shouldn't matter all that much
<j_ey>
sven: pinctrl in -next btw :3
<sven>
nice!
<sven>
hm, looks like they also moved the RAM around
<j_ey>
what are the tz regs?
tom has joined #asahi
<sven>
the locked down memory region that SErrors if you try to read/write from it
<sven>
it's the only part of trustzone they use
<j_ey>
ah
<sven>
i actually think the registers might be the same
<sven>
it's just that RAM starts at 0x10_0000_0000 now
tom has quit []
hir0pro has joined #asahi
<j_ey>
and that bit of code doesnt read the ADT
<sven>
yeah
<j_ey>
lets not tell markan so he has something to do on monday :P
<sven>
:D
<VinDuv>
looks like it dies after printing “MMU: SCTLR_EL1: 30100180 -> 30901085”
<sven>
yeah, that turns on the MMU
<sven>
possibly because not enough RAM is mapped
<sven>
+it dies
<sven>
if RAM starts at 0x10_0000_0000 now we don't map that i think
<sorear>
.o( new channel for spoilers )
<sven>
or it just needs some of the chicken bits
<sven>
ah, no, i think the current code will create some wrong mappings
<sven>
so when it enables the MMU the page it's running from disappears
<j_ey>
been there
<sven>
and the exception handlers won't work because they're not mapped either :D
<j_ey>
also been there :P
<sven>
VinDuv: so as a quick hack you can probably replace 0x0800000000 with 0x1000000000 in memory.c
<sven>
and then maybe the REGION_RWX_EL0, etc. defines need to be changed as well so that they don't overlap
___nick___ has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi
rkt has quit [Quit: rkt]
hir0pro has quit [Quit: hir0pro]
<kettenis>
ah, so I'll need a new memory map for u-boot for these new machines
* sven
is just guessing fwiw
<sven>
i only have my "old" m1 here
<kettenis>
well, they've probably also moved around the pcie stuff
rkt has joined #asahi
hir0pro has joined #asahi
rkt has quit [Quit: rkt]
<VinDuv>
sven: changing the addresses did not seem to fix anything, but I’ve probably messed up something somewhere
<sven>
or it might actually need new chicken bits to work correctly
aleasto has quit [Read error: No route to host]
<sven>
anyway, i'm sure marcan will figure it out on monday :D
<VinDuv>
:-)
<sven>
we don't wanna steal all his fun doing remote debugging :)
<VinDuv>
and probably a bunch of refactoring to remove hardcoded addresses…
<sven>
s/0x0800000000/ram_start/ :P
<sven>
ohh... but true... there are also other hardcoded addresses in there
<sven>
hrm. i guess remove the early uart debug (unless we want some hack to identify the mmio range there), then get uart, ram_start and watchdog from the ADT
<kettenis>
probably useful to keep early uart as a debug option
<VinDuv>
hmm, there’s something else I don’t quite understand: it looks like m1n1’s proxy always opens the serial port at 115200 baud (unless M1N1DEVICE has a specified baudrate) and then switches both ends to 1500000
aleasto has joined #asahi
<VinDuv>
so if I close the shell and restart it, the proxy will be at 115200 and the target at 1500000 so it doesn’t work
<kettenis>
115200 is plenty for a serial console and 1500000 isn't supported by all usb serial dongles and more susceptible to line noise
<kettenis>
but 115200 is a bit slow for uploading a linux kernel
<VinDuv>
I don’t remember marcan having problems with it but I guess it’s because his serial adapter has auto baudrate
<sven>
doesn't the proxy code try both baudrates during setup?
<sven>
i always use two m1 macs and never had any issues
<VinDuv>
ah you’re right, I’ve missed that part of the code
<VinDuv>
In my case it’s the proxy.iodev_whoami() call in bootstrap_port which fails
<VinDuv>
I don’t really understand how that would work since it sends a proxy command before trying to adjust the baud rate?
<sven>
huh
<sven>
that's indeed weird
<sven>
hm, but reading that code it's fine if that one fails
<sven>
if you're using USB it doesn't matter because there's no baudrate and it'll never fail anyway
<sven>
and if you're using UART it'll try to adjust the baudrate if it failed
<VinDuv>
On my Mac the proxy.iodev_whoami raises m1n1.proxy.UartTimeout which is not caught
<sven>
hrm, now that i'm reading the code again it also confuses me :D
<sven>
so the iodev_whoami is meant to detect if you're connected via USB and to just skip baudrate adjustment then
<sven>
does just catching the UartTimeout fix that issue?
<sven>
(i just realized i haven't used the hw uart in a long time so maybe it's actually a bit broken right now)
<VinDuv>
It works but it’s a bit slow since it waits for the default timeout
<sven>
sounds like this might be a regression then
<VinDuv>
(I also had some issues with chainload timing out but it looks like it’s just because the MMU-less m1n1 is a bit too slow to finish starting…)
<sven>
i also get some timeouts sometimes after a reboot fwiw. but they haven't been very consistent and i haven't been able to figure out why they happen
<sven>
like once every 15-20 reboots or so chainload times out a few times before it works
<sven>
but anyway, i already like those new comments in that file!
<sven>
i'm not sure about the UartTimeout path but the rest looks good to me
<VinDuv>
I’m assuming iodev_whoami is simple enough so a timeout can only mean mismatched baudrate
<sven>
true
<sven>
and there's a iface.nop later anyway that will fail if there was any other problem
jacoxon has quit []
jacoxon has joined #asahi
aleasto has quit [Remote host closed the connection]