<j_ey>
jannau: would be nice if you could try it out at some point. I seem to still get data from the tracpkad even after pressing capslock. (I dont have x11 or anything, but I put a pr_err in applespi_got_data and im at least getting prints when using the tracpkad)
<sven>
j_ey: it's a bit weird that the irq is started by setting REG_CONFIG_IE_TXEMPTY but never stopped. does that happen automatically?
<sven>
and do you know why you need to read and then write REG_STATUS? does that ack an irq or something?
<j_ey>
the packets from the keyboard/touchpad are 256 bytes, so we know theyre never going to be sent in one go..
<sven>
i dunno how this hardware works but SPI is probably slow i'd expect that at first you just fill the TX fifo, start the xfer and then wait for an interrupt
<sven>
and then in the interrupt probably first see if you can read from the RX fifo and then try to fill the TX fifo again
<sven>
and the xfer would be complete if you read from the RX fifo and don't have any more bytes to send
<j_ey>
this seems to match up what I learnt about SPI from watching one Ben Eater video about it lol
<sven>
:D
<j_ey>
so yes, ive had a 30min video primer on SPI, I have no idea what Im doing :-)
<sven>
:>
<j_ey>
there is this bit REG_STATUS_COMPL.. but I think because I disable the interrurpts.. it seems to be set at the start of every new transfer
<j_ey>
*because I disable the interrupts after I know the transfer is complete
<kettenis>
I've defenitely seen that bit get set when the transfer is complete
<kettenis>
but if you don't clear it, it will still be set at the start of the next transfer
<j_ey>
I think I can just ignore it, since Im keeping track of when the transfer is going to be cmplete anyway
<sven>
does it not keep firing the interrupt if you keep that bit enabled?
<sven>
oh, no
<sven>
because you write to STATUS anyway in the irq handler and just ack everything
<j_ey>
yeah
<j_ey>
i started to try write a spi.py.. but realised I didnt want to deal with getting the actual HID protocol right to properly get packets
<sven>
that's why i never wrote nvme.py :D
<j_ey>
:)
<sven>
though at this point it actually wouldn't have been that bad. for some reason i assumed that nvme was going to be much more complex than it actually is
<j_ey>
sven: how is the rewrite going?
<sven>
working on the rtkit part right now
<sven>
two more weeks of work and my xmas vacation starts. i should be able to just get it done then :-)
<j_ey>
nice!
<j_ey>
I have 3 more weeks left, although I guess it might get quite quiet
<jannau>
j_ey: I get "applespi spi0.0: Received corrupted packet (invalid message length 0 - expected 4294967286)" every second
<j_ey>
jannau: after the caps lock thing or?
<j_ey>
or just with my driver? :|
<jannau>
just with your driver. no working keyboard
<j_ey>
oh yikes
<jannau>
just with spi-apple-mc2 on top of my tree and the Makefile pointed to it
<jannau>
applespi.c is identical
<j_ey>
the only way I could think of figuring it out is to just slowly add back in some of the register that corellium set, that I didnt
<j_ey>
jannau: are you willing to try figure out whats missing, if not maybe marcan or someone else can help
<marcan>
if I'm allowed to just rewrite everything... :>
<j_ey>
sure!
<j_ey>
I just want to try get it upstream!
<j_ey>
(I mean, have any spi driver for it upstream)
<marcan>
spi seems to fit the "so simple figuring it out from scratch is probably easier than figuring out what corellium did wrong" bill so...
<j_ey>
marcan: also as long as you stream it :P
<marcan>
sure :)
<marcan>
and it might give me an excuse to disassemble that second Mini if I need to pull out the scope
<marcan>
and besides, I'm twiddling my thumbs waiting for the PMGR/DT stuff reviews anyway
<j_ey>
its 1am japan, you can probably do it before 3am
<marcan>
(at least in this context; in global context I just came back from band practice today, I promise I'm not *literally* wasting my time :p)
<j_ey>
lol sorry, I shouldn't encourage you
<marcan>
lol
<marcan>
I'm tired enough after 4h of playing that I don't think that would happen today :p
<j_ey>
nerdsnipe failed
<marcan>
ooh, speaking of PMGR reviews... robh email spotted :)
<j_ey>
overall it's pretty simple to have a basic SPI driver, you just need a to provide a transfer_one, and you return 0 from that if the transfer finished and 1 if there is more to send
<j_ey>
and in the irq hanlder once you sent everything you call spi_finalize_current_transfer
<marcan>
makes sense
<j_ey>
you also want master->use_gpio_descriptors = true;, so the core gets the cs from the DT for you
ethanr has joined #asahi-dev
<jannau>
j_ey: sure, do you a suspicion to what it might be? just to be sure, it should work with an unchanged dtb?
aleasto has joined #asahi-dev
<j_ey>
jannau: no I dont have any real suspicions.. but it seems like markan might take over, so Im just going to park it for now
ethanr_ has joined #asahi-dev
<sven>
my first bet is the rx/tx fifo handling
<sven>
it should really be fill N bytes to tx fifo, trigger xfer, read N bytes from rx fifo
<sven>
spi cannot receive without also transmitting something
<sven>
I don’t know what the hw does in this case
<j_ey>
jannau: you could try comment out the `apple_spimc_drain_rx` in apple_spimc_transfer_one
<sven>
bsd also doesn’t seem to use interrupts there and doing it that way might just work out
<kettenis>
it reads the fifo level register and the rx level should be 0 at the start of a transfer
<j_ey>
jannau: you could also try: writel_relaxed(0, spi->base + REG_CLKIDLE);, just before the writel_relaxed(REG_CLKCFG_ENABLE, spi->base + REG_CLKCFG);
<j_ey>
You'd also need "#define REG_CLKIDLE 0x38"
<sven>
or maybe first start with a driver that polls and only add interrupts later
<jannau>
commenting apple_spimc_drain_rx doesn't help, all adding all the register writes in _prepare/_clock except the draining doesn't fisx it either
<marcan>
I highly encourage everyone to work out how the hardware works first, over stumbling over drivers written by people who haven't done so :-)
<sven>
what bad does looks good fwiw. I’d start from there and get that working first
<sven>
also what marcan said
<sven>
*bsd instead of bad :D
<marcan>
remember, Corellium do VMs that run *one* OS; they don't need to understand how the hardware works, they just need to make that OS happy. you can get away with a ton of nonsense/misunderstandings when you only need to make one piece of code work.
<j_ey>
kettenis: im guessing the openbsd one hasnt been tested on pro/max?
<kettenis>
correct
<marcan>
it's been evident throughout this entire thing that they have never sat down and actually poked at any of this hardware to understand how it works; they just read macOS drivers
<j_ey>
sven: I do have an older version w/o interrupts, but what marcan says etc :P
<sven>
uh
<sven>
getting polling to work is literally the first step in understanding how the hw works
<marcan>
(this is also why getting a m1n1 driver up first is a very good idea)
<marcan>
(that entire thing is *designed* as a testing and understanding framework precisely for this purpose!)
<marcan>
you should be able to "single-step" through the hardware handling and observe the registers change and exactly what effect each action has (RegMonitor is your friend etc)
<marcan>
and yes, IRQ support should follow naturally from a polled implementation; the only thing that should need working out for IRQs to work is the flags/masks/whatever, everything else should come from an existing understanding of the hardware
<marcan>
the rest of the IRQ complexity is in the kernel/driver side to handle things properly asynchronously, not in hardware understanding
<kettenis>
FWIW, I spent quite some time poking at the hardware writing that driver
<marcan>
^^ good reason to use the BSD driver as a reference to write a new Linux one then :)
<marcan>
(which is what I plan to do with WiFi btw)
<kettenis>
my understanding of how it works is still incomplete, but heck of a lot better than whoever write the corellium driver ;)
<marcan>
there will always be gaps, but it's important to get the core concepts right or else the thing will fall apart even if it appears to work at first
<j_ey>
I mean, if someone wants to try the bsd driver on max/pro..
<marcan>
I would be very surprised if any of this changed on t6000
<marcan>
they all have the same compatible and I think this probably also dates to the dark ages of iPhones
<kettenis>
OpenBSD won't run on the M1 pro/max until I have a working u-boot and a driver for the new AIC version
<kettenis>
speaking about u-boot, its power domains framework is a bit dumb
<kettenis>
it is unaware of multiple devices depending on a power domain
<kettenis>
i'm considering to simply avoid turning off power domains in u-boot
<marcan>
as long as you don't create dependency issues, linux will power down everything that needs powering down anyway
<marcan>
and in general the default state is/should be things powered up (which is why driver probe functions are called after domains are powered up)
<marcan>
so it makes sense for a bootloader not to shut things down
<j_ey>
kettenis: how come you re-read AVAIL inside the rx loop, but not the tx one?
<marcan>
kettenis: is there much to do for u-boot on t6000? does it even use IRQs?
<marcan>
I imagine the DART/SART changes should be ~all it takes
<kettenis>
j_ey: I think I came to the conclusion that it would be pointless
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<marcan>
once I catch up on getting decent versions of all these kernel bits and pieces merged, I want to finally put together a shippable boot stack, and I definitely want it to work on t6000 :)
<kettenis>
marcan: I need to add a t6000-specific memory map
<marcan>
oh, is that hardcoded?
<kettenis>
yeah
<marcan>
aw, that's a shame
<kettenis>
but we can have multiple memory maps
<kettenis>
and we might actually be able to build one from the DT
<marcan>
that would be ideal
<kettenis>
there are also some hardcoded memory addresses in the u-boot environment
<kettenis>
I think those are only used for the legacy boot path
<marcan>
hm, like where to load raw kernels and such?
<kettenis>
yup
<marcan>
we could make m1n1 fill some of that stuff in if needed
<kettenis>
don't think that'll help
<kettenis>
I'm focussing on upstreaming the missing drivers first
<marcan>
sgtm, I imagine if I get to this point and you haven't gotten around to it yet, it shouldn't be a huge issue to take a crack at :)
Dcow has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
ethanr_ has quit [Quit: Leaving]
loki_val has quit [Ping timeout: 480 seconds]
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
ethanr has joined #asahi-dev
<ethanr>
Does the m1n1 bootloader work with btrfs?
ethanr has quit []
ethanr has joined #asahi-dev
<j_ey>
ethanr: m1n1 doesnt do any file system stuff