<sven>
hrm, macOS seems to use the flush command as well. I wonder why it isn’t slowed as much as Linux is
<sven>
anyway, nvme/dev should fix the error recovery stuff now
<marcan>
j`ey: ha
<marcan>
so about this wifi thing... I'm getting really annoyed :/
<j`ey>
:(
<j`ey>
sven: check the link too ^
<marcan>
it seems to crash in a few ways, and I ended up throwing a crashed memory image into ghidra to try to trace what happened, and I ended up with "ROM function called panic()" :/
<marcan>
(and I haven't dumped the ROM)
<marcan>
maybe I should do that...
<marcan>
but I get the feeling the ROM function that panicked is the one handling the AXI error
<marcan>
(since those strings aren't in the firmware)
<marcan>
... so now we're back at "weird random bus error with no clear cause"
<kettenis>
sven: the code in apple_nvme_reset_work() works to reset the thing?
<sven>
yes
<sven>
rtkit still needs to be alive and cleanly shut down though :(
<kettenis>
so the steps are: 1. shutdown rtkit, 2. clear coproc run bit, 3. assert reset
<sven>
yup
<sven>
you can also clear the bit before shutting down rtkit
<sven>
it seems to be more like “start cpu”
<kettenis>
ok, need to implement the reset functionality in u-boot then
<j`ey>
marcan: I have no ideas (apart from tracing macOS more, maybe some extra SMC/gpio / magic pokes), but I have faith you'll figure it out!
<marcan>
how on earth did someone get broadcom to GPL that?
<sven>
hah
<marcan>
some of that code is the same as the ROM
<marcan>
it also has the proper TCM size computation algorithm (which I'd already guessed but I wasn't sure about the block size flag, this clarifies it)
<kettenis>
is that essentially the android driver?
<marcan>
I guess?
egavinc has joined #asahi-dev
<sven>
alright, i think i'm mostly happy with nvme/dev now. there's still that weird flush slowdown but other than that i haven't been able to make it panic anymore
<tpw_rules>
is there new shutdown code?
<sven>
not really. since yesterday i've just fixed a few bugs w.r.t interactions with the linux nvme subsystem
<marcan>
heh, this has full register lists. handy.
<sven>
(plus the usual cleanup)
<marcan>
uint32axi_dbg_ctl; /* 0x1C4 */
<marcan>
uint32axi_dbg_data0; /* 0x1C8 */
<marcan>
uint32axi_dbg_data1; /* 0x1CC */
<marcan>
heh, can I issue arbitrary AXI transactions with this? that sounds handy :p
<marcan>
(or maybe it's just reading? no idea)
<sven>
aw.. so telling ANS what time it is also doesn't make the flushs go faster :D
<kettenis>
are the flushes slow as well under macOS?
<sven>
not 100% sure yet, but macOS at least uses flushs
<kettenis>
sven: that worked
<kettenis>
so I can do a shutdown + reset in u-boot and than reinitialize in openbsd
<kettenis>
that shuld make linux happy as well
<sven>
nice :)
<kettenis>
so it seems I can get away with not starting syslog and feeding crashlog and ioreport 0 as the address when they ask for a buffer
<kettenis>
that simplifies the u-boot code considerably
Dcow has joined #asahi-dev
<sven>
hrm, so i think macos just issues much less flush commands compared to linux
<sven>
marcan: alright, i think you can replace the old driver in asahi with what's in nvme/dev if that branch still works on t6k
<marcan>
:D
<sven>
(knowing my luck that one kernel panics for everyone else while it works just fine for me :D)
<tpw_rules>
kettenis: i had a couple other things i think need to be fixed in the rtkit code. this was my patch for that and the nvme shutdown stuff: https://pastebin.com/Vfn4Exw1
<kettenis>
I'll see if I missed some things
leah2 has quit [Remote host closed the connection]
leah2 has joined #asahi-dev
<sven>
so if that nvme driver works and the rtkit library also works for SMC I think everything should be ready to submit a RFC in January
<marcan>
I think I fixed wifi
<marcan>
apparently I needed to reset less, not more
<marcan>
but... I might know what causes this
<jn>
hmm, non-idempotent resets…
<marcan>
so resetting the D11 cores breaks it
<marcan>
and now I look at the reset function in that broadcom dump and
<marcan>
...
<marcan>
#ifdef UCM_CORRUPTION_WAR
<marcan>
what's this.
<j`ey>
o_O
<marcan>
this looks like a bug workaround...
<sven>
lol
<tpw_rules>
just to confirm, there are no objections to releasing a short guide on how to install nixos standalone with u-boot?
<kettenis>
tpw_rules: I would avoid documenting things that get out of date fast
<kettenis>
especially in a form that risks lingering on (like a blog)
<kettenis>
pushed a u-boot that resets nvme
<kettenis>
tests welcome...
<marcan>
ok, that workaround doesn't fix it
<marcan>
looks like I just have to not reset the wlan cores
egavinc has quit [Quit: Leaving]
<jannau>
I might not want to map KEY_SLEEP for now (at least in the HV)
<jannau>
bare metal as well
<jannau>
I guess we should find other ways to make sure we do not suspend for now
<marcan>
okay, I guess the ABI changed for something
<marcan>
looks like that android driver supports v2, yay
<tpw_rules>
kettenis: i tested your version out, and it looks like when rtkit starts again, it asks for a 0 length buffer on endpoint 1, which causes the linux kernel to try to allocate a 0 length dma buffer and get upset. not sure if that's the kernel's problem but rtkit asking for such a buffer seems suspicious
<tpw_rules>
(this is not using the nvme/dev branch)
<kettenis>
hard to see how that's a problem with u-boot
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kettenis>
unless the reset that's done is only partial
<sven>
the reset is unfortunately not a full reset :(
<tpw_rules>
i think that's what's happening. rtkit is somehow remembering that you sent it a 0 length buffer in u-boot and asking for that again next time
<tpw_rules>
now the kernel should probably have better parameter validation, but rtkit asking for 0 length buffers seems like it will easily create future problems
<jannau>
only user visible changes should be the correct mapping of the function keys hand hopefully a correct contry code for the keyboard
<jannau>
country code and vendor/product ID are read from keyboard's EC
<jannau>
kettenis: so there is hopefully no need to place anything in the device tree
<kettenis>
so you figured out where it comes from?
<jannau>
yes, not hard once I was able to trace macos' SPI communication
<jannau>
it has requests for device and interface information. sorry for the mess with magic numbers but the defines made harder to think how HID is mapped here
<jannau>
I still have no good understanding but the clearly wrong exisitng names were not helping
Dcow has joined #asahi-dev
<kettenis>
I'll see if I can make a bit more sense of that
<tpw_rules>
alright, i patched the kernel to handle the zero length buffer request and it seems that only happens on the crashlog endpoint. the syslog and ioreporting endpoints request the same length as before and seem to work properly, including shutdown. so maybe u-boot's behavior is valid and this case should be handled in apple_rtkit_common_rx_get_buffer. but i'm not sure what will happen if rtkit crashes now
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
added the escan v2 thing... now it wants a version bump for the pmkid_list too, sigh
<marcan>
I should get some sleep, I can wrap this up tomorrow
<marcan>
at least I got as far as listing all the SSIDs :p
Dcow has joined #asahi-dev
<marcan>
tpw_rules: I think you can supply a different size buffer from the request
<marcan>
so maybe linux should just do that
<marcan>
or maybe u-boot shouldn't use zero length buffers :p
<j`ey>
marcan: im not sure what youve been modifying, the linux driver right? not the firmware..
<marcan>
yes, the driver
<marcan>
adding support for new bits of ABI that are required by the 4387 firmware
<kettenis>
marcan: ah, wait, looks like I screwed something up when cleaning up that diff
<jannau>
I'm not convinced that 0xb0 is a real device. the 4 MSB could be something else
<unrelentingtech>
wow that's odd. they've had it on SPI since 2016 and now they moved it to a more "raw" interface for.. reasons?? even though the SPI-speaking microcontroller in the topcase basically stayed the same
<unrelentingtech>
that's in the same byte as "1 for keyboard, 2 for trackpad" so they kinda make sense as "virtual devices". 0xD0 where "d" is for "device info" and 0xB0 where "b" is for "backlight"
<unrelentingtech>
well, backlight does use the keyboard device on the outer message level
<jannau>
device 0 is called "Device Management". I would expect that to provide the device info
MajorBiscuit has quit [Quit: WeeChat 3.3]
___nick___ has quit [Ping timeout: 480 seconds]
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]