ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
chadmed has quit [Remote host closed the connection]
chrisl has joined #asahi-dev
nicolas17 has quit [Read error: Connection reset by peer]
nicolas17 has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
veen has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #asahi-dev
kraem has quit [Remote host closed the connection]
kraem has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
gladiac has quit [Read error: Connection reset by peer]
gladiac has joined #asahi-dev
chrisl has joined #asahi-dev
veen has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
emxl has joined #asahi-dev
<emxl>
kj1243: You asked 2 weeks ago if you could help develop for M3. I think it would be helpful if you got to work on whatever init code for your platform is missing in m1n1. You can build m1n1 for your platform, flash it to a new OS install (then enable the -v (for verbose) boot arg with nvram boot-args="-v") and see what breaks and what works.
<emxl>
If you dont get any output on your screen the culprit is probably a new version of the boot_args struct (if you have a recent macOS version). This moves mem_size_actual, breaking the mapping code and crashing m1n1 before it can initialize the screen console. I fixed this for me by increasing cmdline from 608 to 1024 bytes.
chrisl has quit [Ping timeout: 480 seconds]
emxl has quit [Remote host closed the connection]
<jannau>
oh, joy. changinging the platform_device.remove function pointer signature from returning int to void for ~20 drivers
<maz>
jannau: yeah, I had a fun time fixing those.
<maz>
I wish the author had provided a script...
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
ddxtanx_ has joined #asahi-dev
ddxtanx has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
pb17 has joined #asahi-dev
weitcis_ has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
weitcis has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
<nickchan>
for the BootArgs struct stuff because some very old firmwares like iBoot-2817 doesn't even have mem_size_actual I made some assumption and assumed the dram bottom to 0x800000000, then rounded things up to the nearest 256 MB
ddxtanx_ has quit [Quit: Konversation terminated!]
<nickchan>
there are some even older ones that have device tree issue that I have not gotten around to fixing yet...
ddxtanx_ has joined #asahi-dev
<nickchan>
luckily for the newest increase in boot cmdline length you should be able to get around with checking the revision field of the BootArgs struct
chrisl has quit [Ping timeout: 480 seconds]
<nickchan>
revision == 3 would mean boot cmdline length 1024
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
mkurz has joined #asahi-dev
veen has joined #asahi-dev
veen has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
<nickchan>
oh hell nah A10(X) MPIDR changes when with their p-state
<nickchan>
I am seriously considering to cause an immediate TAINT_CPU_OUT_OF_SPEC when I get around to the cpufreq stuff
<nickchan>
probably right at where aarch32 el0 is disabled
chrisl has joined #asahi-dev
casper31 has joined #asahi-dev
RoguePlanet has joined #asahi-dev
RoguePlanet has quit []
chrisl has quit [Ping timeout: 480 seconds]
<jannau>
I've pushed asahi-6.11-rc and rebased asahi-wip and the bits/* branches onto v6.11
<jannau>
very limited testing from my side (j493 only)
<nickchan>
though I am not super suer if a changing MPIDR warrents a taint
<nickchan>
probably should ensure that it always enter in E-mode in the loader since the device tree is like that...
<nickchan>
*super sure
<jannau>
kvm doesn't/didn't work across big and little cores to avoid changing MPIDR iirc
<nickchan>
A10 only has EL0 and EL1 so that's non issue
<maz>
it's not that KVM cares. it's luserspace responsibility to pin the threads to CPUs they care about.
<nickchan>
there's quite a bit of places in the kernel that uses mpidr though, id rather taint the kernel first to let people know about this cursed CPU
<nickchan>
probably should rename bad_aarch32_el0_fixup() to something more specific to a10 while doing this though
<nickchan>
apple_fusion_cursed_fixup()
<jannau>
my point was that either qemu or kvm actively tries to avoid the same situation for the guest kernel. I think the taint is justified
<nickchan>
so far this is in arch/arm64/kernel/cpufeature.c
<nickchan>
but now it looks like it maybe should end up in arch/arm64/kernel/cpu_errata.c...
<maz>
the problem is that you now have multiple MIDRs for the same part -- how do you select an erratum?
__nick__ has joined #asahi-dev
<maz>
and is it MIDR, not MPIDR? -- unless the affinity changes as well?
<nickchan>
maz: MIDR is not MPIDR
<nickchan>
there are two MIDR: one for A10/T2, another for A10X
<nickchan>
What changes is the MPIDR
pb17 has joined #asahi-dev
<maz>
so this effectively appears as CPU hotplug on/off with affinity change?
<nickchan>
maz: Correct
___nick___ has quit [Ping timeout: 480 seconds]
<maz>
then the cpufreq magic is going to be interesting, because I don't think there is much infrastructure for surprise-removal of CPUs.
<nickchan>
nothing seems to explode that horribly on the iPad 7 where I did get cpufreq to work, so maybe I can just taint the kernel during init and ignore it for now...
<maz>
what if another CPU sends an IPI to the one that goes down? or are *all* the CPUs switching at the same time?
<nickchan>
maz: All CPUs switches at the same time
<nickchan>
there is only one performance controller
___nick___ has joined #asahi-dev
<maz>
right, that makes it much simpler. you still have the same number of CPUs (half of what the HW has) in the various cpumasks,
<maz>
and as long as you don't need to refer to a MPIDR (no GIC, no problem), you should be OK.
<maz>
but this is still doggy as fsck.
__nick__ has quit [Ping timeout: 480 seconds]
<maz>
you may need a small hack in cpu_logical_map and co though.
mkurz has quit [Ping timeout: 480 seconds]
veen has joined #asahi-dev
chrisl has joined #asahi-dev
ellyq_ has joined #asahi-dev
veen has quit [Ping timeout: 480 seconds]
veen has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
casper31 has quit [Remote host closed the connection]
balrog_ has quit []
balrog has joined #asahi-dev
chadmed__ has quit [Quit: Konversation terminated!]