<cyrozap>
firmware is in fact running and that the code was all loaded correctly. Based on this research, I have several suggestions for the kernel code:
<cyrozap>
4) As a safety check, after all the SRAM has been written to, the SRAM should be read back and compared with the firmware. Note that unlike when writing to SRAM, reading it back is done in 0x4000-byte/0x2000-word interleaved blocks instead of 0x8000-byte/0x4000-word blocks, and uses two dword registers (0x3018 and 0x301c) for that data instead of just one. And of course bit 6 in PCI config space
<cyrozap>
register 0xEF needs to be set to enable readback (set it before doing the readback, but after writing has finished).
<cyrozap>
5) Immediately after disabling SRAM write access (`asmedia_write_reg(hcd, 0x500e, 0);`), release the controller from reset with `asmedia_write_reg(hcd, 0x5042, 0);`. Then wait for the controller to initialize--it will reset itself once during this process in order to increase its clock speed from 78.125 MHz to 156.25 MHz, so don't try to talk to it before it's finished. Maybe add a delay of 10 ms or
<cyrozap>
100 ms or so (just a guess).
<cyrozap>
Hopefully these suggestions will help you fix the issues you were seeing with the firmware load process!
<cyrozap>
Also, a small note about the reliability of this process: I was also experimenting with the firmware loading process for an earlier host controller, the ASM1142, and as part of that wrote a small firmware that would simply read itself back to the host. I was very surprised to find that pretty much every time I uploaded firmware to that chip, about 50-60 bytes between 0x0E40 and 0x1090 would get
<cyrozap>
corrupted. More specifically, the highest bit of the highest byte in each affected 16-bit word would be flipped from either 0 to 1 or 1 to 0--all other bits were unaffected. I'm not sure if this is an issue with only this specific chip, and other ASM1142's are fine, or if it's a more widespread issue with this series of controllers (and maybe the ASM1042A as well, since it also supports the feature),
<cyrozap>
but regardless of that I think it serves as a good example of how incredibly janky this process is and why it's absolutely necessary to do so many checks at each step.
<cyrozap>
Like, you just can't assume this part of the hardware will always work properly. Since as you've already noted, it was probably originally intended as a debug interface.
r0ni has joined #asahi-dev
user982492 has joined #asahi-dev
tenkuu has joined #asahi-dev
tenkuu has quit []
tenkuu has joined #asahi-dev
ma2 has joined #asahi-dev
ma has quit [Ping timeout: 480 seconds]
tenkuu has quit [Read error: Connection reset by peer]
tenkuu has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]
tenkuu has quit [Read error: Connection reset by peer]
tenkuu has joined #asahi-dev
tenkuu has quit [Read error: Connection reset by peer]
tenkuu has joined #asahi-dev
<marcan>
cyrozap: The failures I saw were all in the reset step, so maybe just skipping that (and possibly adding the MMIO poke readback/check) is all we need?
<marcan>
but yeah, the Apple driver does a readback check I think
<marcan>
maybe we should too
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tenkuu_ has joined #asahi-dev
tenkuu_ has quit []
tenkuu has quit [Ping timeout: 480 seconds]
tenkuu has joined #asahi-dev
tenkuu has quit []
tenkuu has joined #asahi-dev
<marcan>
looks like cpufreq made it in \o/
<marcan>
I'll send out the DT changes tonight
<marcan>
sven: I'll write and send you the t600x DT patch for review if you don't beat me to it :)
grange_c has quit [Quit: Ping timeout (120 seconds)]
grange_c has joined #asahi-dev
hxliew has quit [Quit: WeeChat 3.5]
tenkuu has quit [Quit: WeeChat 3.7.1]
SSJ_GZ has joined #asahi-dev
steven has joined #asahi-dev
<sven>
I don’t have any t600x, I’ll happily review patches but I probably won’t write any :D
mps_ has joined #asahi-dev
mps has quit [Ping timeout: 480 seconds]
capta1nt0ad has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-dev
<j`ey>
marcan: \m/ re: cpufreq
bluetail4 has joined #asahi-dev
bluetail has quit [Ping timeout: 480 seconds]
bluetail4 is now known as bluetail
<kettenis_>
marcan maz: thanks
kettenis_ is now known as kettenis
leitao has joined #asahi-dev
<kettenis>
you folks thinking about OpenBSD is very much appreciated
<sven>
maybe we should start sabotaging openbsd efforts instead so that you don't keep beating us with support for almost everything :p
<povik>
or we can all switch to develop openbsd instead!
leitao has quit [Ping timeout: 480 seconds]
<kettenis>
hey, you guys have proper USB and DCP support now!
<kettenis>
I suddenly have a lot of catching up to do...
<sven>
i still expect openbsd to support that upstream before linux does ;)
<sven>
in usb news, i'm also reasonably sure that cd321x is actually more similar to TPS65988DK which also supports USB4 and, according to some public replies by TI employees, is not entirely compatible with the previous tps6598x chips. unfortunately the docs for that one are hidden behind NDAs :(
<_jannau_>
sven: I see the same data sheet / host interface TRM for tps65988 on https://www.ti.com/product/TPS65988 as for the other variants
<sven>
yeah, but if you read the problems people have with the DK variant specifically it very much sounds like the host interface changed
<sven>
there's also a different host interface datasheet for TPS65987DDH but that also doesn't match up
<_jannau_>
ah, ok
<sven>
but that one already has longer registers that do match up
<_jannau_>
I see TPS65987DDH and TPS65988DH Host Interface
<_jannau_>
Technical Reference Manual
<sven>
yeah, that one is already a bit newer/closer to the cd321x
<sven>
but it's still missing USB4 support
<sven>
and any questions relating to USB4 and/or the DK variant are stonewalled in that public forum with "just use the reference design or go to the secure site after signing some NDA"
<sven>
there was e.g. some question about how interrupts were missing/wrong on the DK. that sounds like they moved them around just like on the CD321x
weitcis has joined #asahi-dev
chadmed_ has joined #asahi-dev
<chadmed_>
Right Tweeter Speaker Volume range: (MilliBel(-9999999), MilliBel(0))
<chadmed_>
progress!
<chadmed_>
the alsa-lib rust bindings dont have the methods to change or get current values out of mixer controls hooked up though :/
<maz>
kettenis: no worries. for the few (and hopefully rare) cases where DT becomes a burden, we should consider alternatives...
chadmed_ has quit [Remote host closed the connection]
tim has joined #asahi-dev
tim is now known as Guest442
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
kujeger has joined #asahi-dev
goldsoultheory has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cyrozap>
marcan: No, you should definitely also add the checks for the SRAM address, both before and after writing the SRAM data. Otherwise, data might get written to the wrong address, or the write rate will otherwise just be too fast for the chip to handle. If it works without those checks, then I guess you can skip them, but I'd be worried about the process failing randomly for users. Without proper
<cyrozap>
documentation from the manufacturer, I'd be really wary of making any extra optimizations.
leitao has joined #asahi-dev
Guest442 has quit [Quit: Guest442]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
tobhe_ has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
blazra has quit [Ping timeout: 480 seconds]
weitcis has quit [Quit: Konversation terminated!]
amarioguy2 has joined #asahi-dev
<amarioguy2>
saw the cpufreq news \o/
<amarioguy2>
when SBSA compliance/ACPI transition /s
<amarioguy2>
(in seriousness - if ACPI support ever becomes/became a seriously considered thing, i'd be more than willing to work on it)
<amarioguy2>
i need acpi or at least some semblance of it for trying to boot [proprietary os] anyways lol
<amarioguy2>
i just thought that for now the "DT vs ACPI" talk would probably be best saved until after the asahi DTs approach anything resembling the term stable, don't want the project to suddenly run into issues with booting because of this kind of change or anything
leitao has joined #asahi-dev
tenkuu has joined #asahi-dev
tenkuu has quit []
tenkuu has joined #asahi-dev
<sven>
uh, why would we consider moving to acpi? that just makes no sense
<povik>
that's nightmare material :D
amarioguy2 has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
The main problem with acpi is aic, acpi standard has a enum of possible interrupt controllers and aic isnt one.
<sven>
that one of the problems. same thing with DART
<sven>
iirc acpi just assumes SMMU
amarioguy2 has joined #asahi-dev
dax has quit [Quit: dax]
amarioguy2 has quit [Ping timeout: 480 seconds]
tenkuu has quit [Ping timeout: 480 seconds]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ChaosPrincess>
i also was interested in maybe making those systems acpi compatible, and when i reached the interrupt controllers enum, i stopped reading, so there may be more problems
tenkuu has joined #asahi-dev
leitao has joined #asahi-dev
amarioguy2 has joined #asahi-dev
tenkuu has quit [Ping timeout: 480 seconds]
<dottedmag>
What's the motivation to make the system ACPI-compatible? Easier installation (probably not), anything else?
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
tenkuu has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
riker77 has quit [Quit: Quitting IRC - gone for good...]
<ChaosPrincess>
winders support
<Tramtrist>
good ol winders
<sven>
acpi really is the smallest problem even for that
riker77 has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
systwi_ has quit [Read error: Connection reset by peer]
systwi has joined #asahi-dev
amarioguy2 has joined #asahi-dev
scardracs has joined #asahi-dev
<amarioguy2>
re acpi - meant it more in a hypothetical sense like if it were to ever happen for whatever reason
<amarioguy2>
obviously i'm not saying that it should happen or even that it will lol
<amarioguy2>
chaosprincess: there *is* the CSRT table
<amarioguy2>
believe that table has an enum for irqchips
<amarioguy2>
again tho definitely no motivation to move away from DT atm so...
* amarioguy2
puts that idea on ice
lewurm`` has joined #asahi-dev
lewurm has quit [Ping timeout: 480 seconds]
<amarioguy2>
...side note i really need to stop bringing up ideas that are 99% certain to not ever happen moving forward...
<amarioguy2>
anyways my bad for bringing that up
systwi_ has joined #asahi-dev
tenkuu_ has joined #asahi-dev
systwi has quit [Ping timeout: 480 seconds]
lewurm`` has quit [Ping timeout: 480 seconds]
lewurm has joined #asahi-dev
tenkuu has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
<sven>
marcan: https://github.com/AsahiLinux/linux/commits/atcphc-20221130 should fix any conflicts once you rebase on torvald's tree with the dwc3 race and some of the tipd stuff fixed. the old role switch quirk and atcphy stuff won't apply cleanly anymore otherwise
leitao has joined #asahi-dev
lewurm has quit [Ping timeout: 480 seconds]
amarioguy2 has quit [Ping timeout: 480 seconds]
lewurm has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
<jannau>
sven: do you have an i2c/smbus tracer? I still have a hack directly integrated in hv.py but I can't remember if it was broken or not
<sven>
hm... i vaguely remember tracing it, so maybe that hack works?
<sven>
let me check if I have something else in my local tree
amarioguy2 has joined #asahi-dev
chengsun has joined #asahi-dev
<jannau>
it worked to some degree but I wouldn't rule out that got things slightly wrong
leitao has quit [Read error: Connection reset by peer]
<sven>
huh, does that exist?
<sven>
I just found that uncommited trace_tps.py
lewurm has quit [Read error: Connection reset by peer]
leitao has joined #asahi-dev
lewurm has joined #asahi-dev
<jannau>
no, untracked file my tree
<sven>
lol
<sven>
how many untracked tps tracer do we have :D
tenkuu has joined #asahi-dev
<povik>
(let me plug I2CRegMapTracer if you are going to write yet another one)
<jannau>
I count at least 3. I think hv/trace_tps6598x.py is written by me but I only a vague recollection of it. maybe author names in copyright notices are useful
<sven>
hrm, i think i tried that I2CRegMapTracer at some point but it wouldn't work correctly for the tps chip and I was too lazy to figure out why
<povik>
hah
<sven>
I think it actually was I2CRegMapDev
<sven>
couldn't immediately figure out what ADDRESSING means and then just did the raw transactions myself
tenkuu_ has quit [Ping timeout: 480 seconds]
<povik>
first number is the number of adress bytes in page register, second the number of address bytes sent with each transactions
<povik>
^ should probably be a comment somewhere
<sven>
what's a page register?
<povik>
the register that switches pages
tenkuu has quit [Quit: WeeChat 3.7.1]
<povik>
(if there's one)
<sven>
ah. I don't think tps has that
<povik>
you probably want zero there then
leitao has quit [Ping timeout: 480 seconds]
<jannau>
sven: missing m1n1.trace.i2c (and m1n1.hw.atc_dpxbar which looks unused)
<sven>
maybe we should just use povik's I2CRegMapTracer. that thing seems to have the best chance of working correctly ;)
tenkuu has joined #asahi-dev
<sven>
huh, do I have some stray commit in that tree somehow
<sven>
$ git diff --cached | wc -l
<sven>
1890
<sven>
uh oh
<amarioguy2>
sven: have fun dealing with the untracked stuff :D
<sven>
jannau: I think it's just easier to use I2CRegMapTracer tbh. this tree has still all my old very hacky dcpext tracing before I cleaned that up
<jannau>
sven: already started working on that
<sven>
nice!
<jannau>
as tracer_cd3217.py to contribute to the confusion
chengsun_ has joined #asahi-dev
<jannau>
or maybe avoid some
<sven>
:>
<sven>
just call it trace_hpm.py because no one ever uses that name. that way we'll get to write another tracer for it half a year from now! :P
chengsun has quit [Ping timeout: 480 seconds]
<amarioguy2>
sven: on a more serious note, the sep tracer i think should probably not go into tree until i decipher how AP side negotiates which "ipc"/communication protocol more in depth, as tracing 12.3 already had unknown SKS messages very early
<amarioguy2>
ventura is likely gonna have even more
<sven>
anything is fine for proxyclient/ tbh
<sven>
it's not shipped to end users
<povik>
yeah, better than the other approach of hamstering changes locally
<povik>
look how it worked out for sven!
<sven>
^-- :D
<amarioguy2>
fair - tho i do think i want to fix up the tracer still before i commit it to m1n1
* sven
is glad to make mistakers others can learn from!
<amarioguy2>
or well before you commit it, it was your tracer to start with
<sven>
uh. and i'll also pretend that typo is intentional
<sven>
just use co-developed-by or however it's called
<amarioguy2>
alright will do
<amarioguy2>
i'm sorry i'm taking a while on figuring stuff out btw life has been particularly unforgiving lately that hobby time is hard to come by
<sven>
heh, no need to apologize
<povik>
yeah, you have no obligation, work at it at your own convenience
<sven>
that's the advantage of not getting paid for any of this!
* povik
looks away
* amarioguy2
thanks irc for being supportive :)
<sven>
the other much bigger advantage is that you get to increase the release date of $x whenever people ask you about $x!
<povik>
that reminds me, when will sep be shipped, sven?
<sven>
:D
<sven>
after usb4/thunderbolt ofc
<sven>
and the estimate for that is already sometimes in 2025 or so
<sven>
-s
<amarioguy2>
let's not forget a new challenger, ANE :)