ChanServ 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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
quarkyalice_ has joined #asahi
quarkyalice has quit [Remote host closed the connection]
quarkyalice_ has quit [Remote host closed the connection]
yuyichao has quit [Ping timeout: 480 seconds]
<amw>
sven: Just a note, dart/dev rev 6756bb246de5, very dangerous to run. It reliable corrupts my USB drive I use for rootfs
<amw>
Happens on first boot and so bad I have to wipe, remake the partition
<amw>
Good news is that the devel branch worked - two times in a row so far ...
<amw>
devel did corrupt USB drive after running about 10mins and then shutdown. Unrecoverable fail to recover on next boot
yuyichao has joined #asahi
<chadmed>
arnd: bit of a necro i know but re the thing about the spi drivers all being the same, convergent hardware design might actually be worth a long term research project. in biology, convergent evolution happens when multiple species evolve the same trait in response to a common environmental pressure
<chadmed>
in computer hardware design im all but certain that this has happened also due to the influence of ubiquitous software like linux, where you see hardware start to be designed around better support/ease of development for a particular software solution, rather than the software solution conforming to a set of hardware
<chadmed>
a good example of this (though not specifically convergent) would be the addition of specific SQL query acceleration logic to fujitsu's most recent SPARC chips, or the integration of FPUs to x86 SoCs in the 90s as more and more people were using the PC platform for multimedia tasks that required fast floating point arithmetic
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
quarkyalice has quit [Quit: Leaving]
quarkyalice has joined #asahi
<sven>
amw: uh.. so dart/devel wouldn't surprise me since that one has that 4k pagesize shenanigans
<sven>
j_ey: probably not, that was just a hack i tried
<sven>
amw: 4k pages or 16k pages? and is the iommu in DMA or in bypass mode?
<sorear>
question about the split iommu pagesize thing. Does AGX require the IOMMU to be configured per-process to control what memory each shader has access to, or is that handled somewhere else in the stack? (My relevant knowledge is limited to one AMD HSA slide deck a few years ago)
<sven>
apple loves IOMMU *so* much that they have at least four different ones
<sven>
AGX uses something called GART which we don't know much about yet
<sven>
but presumably it'll need some per-process mappings
<sorear>
so AGX doesn't need to be treated by DART as an "untrusted device" using the terminology of the thread, but only because AGX is out of scope for DART entirely?
<sven>
AGx wouldn't be untrusted anyway
<sven>
untrusted in the kernel means "external facing device that can act as a DMA master"
<sven>
i.e. thunderbolt
<sven>
(and we'll make the broadcom wifi untrusted too)
<sorear>
if user-provided shaders could tell it to access arbitrary memory in the device address space, and if DART was the only line of defense against that, it would quack a lot like an untrusted device (vfio/VM PCI passthrough being the other interesting case but that's much further down the road)
<sven>
ah, good point
<sven>
there's no DART but probably the same "issues" apply to GART
<sven>
but GART may not be part of the iommu in the end
<sven>
(please don't let it be part of that framework. i really don't want to also implement multiple iommu per bus support in there)
<amw>
sven: CONFIG_ARM64_PAGE_SHIFT=14 - don't know how to tell about iommu - is it DT setting?
<sven>
that's 16k, so should be fine
<ar>
isn't "GART" is what iommu for gpus used to be called ages ago (as in, gpus in agp slot era)? i find it funny they've reused the name, though it kinda makes sense
<chadmed>
yeah lmao the driver for it in linux is still called agpgart
<marcan>
chadmed: SPI hardware isn't all the same because linux, it's all the same because SPI is a stupid simple protocol and there is effectively one obvious way to do it
<j_ey>
all the same, but all subtly different
<marcan>
yes :)
<marcan>
if vendors were actually trying to help linux the worst thing they could do is exactly what they do, design an incompatible variant for no reason
<chadmed>
yeah perhaps an spi controller, being (relatively) simple and dumb, is a poor example of what i was trying to describe. of course, i dont for a second think that these companies are trying to "help" linux, but moreso just take advantage of the fact that these code paths exist and only add enough voodoo such that you still need _their_ driver, but that driver can be mostly copy-pasted or otherwise adapted from
<chadmed>
somewhere else
eichin has quit [Read error: Connection reset by peer]
eichin has joined #asahi
eric_engestrom has quit [Read error: Connection reset by peer]
steev has quit [Read error: No route to host]
eric_engestrom has joined #asahi
steev has joined #asahi
kettenis_ has joined #asahi
kettenis has quit [Read error: Connection reset by peer]
<chadmed>
i do not recall the last time i had a positive experience with a broadcom chip
<chadmed>
i think ive only ever had a good experience with their DSL chipsets since theyre more stable on long phone lines
<JTL>
marcan: Don't know if you got the memo, but GitHub now allows enabling "one time donations" for sponsorship
<tophevich[m]>
JTL: AFAIK they don't take a cut, right?
<amw>
Help appreciated on debugging why platform drivers are not called - I cherry-picked the corellium pinctrl/gpio/keyboard drivers got them compiling but they are never probed!
<j_ey>
amw: added to the dt too?
<amw>
I have appropriate looking device tree - must be something very fundamental
<j_ey>
amw: added the CONFIG_ options?
<JTL>
tophevich[m]: not sure
<j_ey>
oh nvm you got them compiling
<pipcet[m]>
amw: got a link to your DT somewhere?
<amw>
Didn't take corellium nvme stuff
<j_ey>
sorry nvm = nevermind
<j_ey>
amw: can you make a branch with your changes? I can look, I got this working yesterday, but cant share it immediately
<j_ey>
but ignoring the unused clocks makes that patch not needed
<amw>
Ok - I have to go now - but I'm not surprised my raw patches crash - at least the code is being run now....
<amw>
Thanks again - much happier now!
<j_ey>
amw: cool, but as pipcet[m] said.. that probably shouldnt be called. double check youre getting "clk: Not disabling unused clocks" in dmesg
<amw>
j_ey: The stack trace shows it's called from clk_disable_unused from do_one_initcall() - so it's not happy
<j_ey>
yeah, so that option isnt being set properly
<pipcet[m]>
does the m1n1 command line override the built-in one or add to it?
<pipcet[m]>
i.e. is CONFIG_CMDLINE_FROM_BOOTLOADER or CMDLINE_FORCE enabled?
<amw>
pipcet[m]: Good call! - That was it - it's now booting up...
<amw>
Ok - falling over trying to get an interrupt - but I was expecting something like that - didn't try to take that stuff
<j_ey>
amw: hm, which bits didnt you take?
<amw>
I was thinking trying to get polling working rather than work through all the interrupt stuff I'm not not familar with
<pipcet[m]>
amw: I had polling working at some point, but I don't remember which of the seventeen branches it's in :(
<amw>
Literally just the pinctrl + spi + keyboard .... - that plus ignorance and hope :-)
<j_ey>
amw: oh, do you mean failing to get an interrupt during probe?
<j_ey>
like the platform_get_irq stuff?
<amw>
j_ey: Yep - just ignored anything related to the interrupts....
<j_ey>
weird, that just worked for me
<pipcet[m]>
amw: ignored as in removed or ignored as in left it alone?
<amw>
pipcet[m]: As in just took the whole DT entry for those spi/keyboard with the IRQ but didn't take any code patches for the IRQs
<j_ey>
the irq code is in the patches you took
<j_ey>
unless you removed it
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Quit: Konversation terminated!]
<amw>
Didn't remove anything from the patches I took - didn't take b8ecd5924678 "SMP on Apple M1" or "Support for Apple Interrupt Controller (AIC)" but perhaps that's ok
<j_ey>
amw: yeah mainline has the aic already
<amw>
Ok - apple-gpio-pinctrl 23c100000.pinctrl: Apple GPIO must have at least one IRQ
<j_ey>
oh one sec
<j_ey>
you need interrupt-parent = <&aic>;
<j_ey>
amw: on both pinctrls and the spi3
<j_ey>
I think that fixes that
<pipcet[m]>
I'm confused-are you trying to poll the keyboard or get interrupts to work?
<amw>
j_ey: Hmm on the corellium they put the interrupt-parent in the keyboard section
<amw>
pipcet[m]: I'm just going shortest path at the moment (very long one it seems though :-()
<j_ey>
amw: yeah but you need one for pinctrls and spi3 too
<amw>
j_ey: now crashing SError in spi probe on the clk_enable - I might try commenting it out of the DT
<j_ey>
amw: do you see "clk: Not
<j_ey>
disabling unused clocks" in dmesg?
<amw>
j_ey: No - but I am passing that disable command line option via linux.py
<j_ey>
I dont think its working then
<j_ey>
in drivers/clk/clk.c try force it by writing: if (1 || clk_ignore_unused) {
<amw>
May be I point the spi3 DT entry to refclk24mhz: or something safer?
<j_ey>
try the above first
<j_ey>
or try the patch I posted a bit ago
<amw>
Nope - I think it is trying to enable it because it is used?
<j_ey>
Nope meaning, you tried hardcoding it to be true in clk.c and it still didnt work?
<amw>
That's correct
<j_ey>
I had a bunch of SErrors but they went away after I forced that option to be true
<j_ey>
hm
<amw>
ok - my fixed refclk stopped it crashing but it's now winging about IRQ index 0 not found...
<pipcet[m]>
amw: the MBP doesn't have physical function keys, just the touchbar, so I had to add those.
<amw>
Doesn't the touchbar require those nasty co-processor/mailbox thingies?
<pipcet[m]>
i wish
<pipcet[m]>
it's an SPI device that responds nonsensically until you complete a lengthy initialization sequence, when it sends lots of data that needs to be interpreted...
<amw>
Ahh - so long hours on the hypervisor...
<chadmed>
im disheartened that the rumours of them yeeting the touchbar turned out to be untrue
<j_ey>
amw: btw do you see a corrupt packet from the keyboard on boot? (in dmesg)
<pipcet[m]>
that's for input. For output there's a display controller behind its own dart, plus the phy driver
<amw>
j_ey: Yep - I get "applespi spi0.0: Received corrupted packet (invalid packet length 2357)"
<pipcet[m]>
I see that too, though usually it's a CRC error...
<j_ey>
same, wonder what that is about
<j_ey>
pipcet[m]: I get that exact message ^
<pipcet[m]>
[ 3.759822] applespi spi1.0: Received corrupted packet (crc mismatch)
<pipcet[m]>
amw: oh, any chance you could check your ADT first? I don't feel good about just writing to MMIO that I really have no reason to believe is there or does the same thing on MBA...
<j_ey>
Im Sure Its The Same(tm)
<amw>
Hmm there are exactly 4 of those corrupted packet messages in the keyboard driver : git grep "corrupted packet" drivers/input/keyboard/applespi.c
<amw>
pipcet[m]: What am I looking for - I have an adt.txt file extract via m1n1 adt.py script
<pipcet[m]>
I suspect the initial message is just the weird boot mode the keyboard is in. It also sends an interrupt when the first key is hit, even when there is no driver.
<pipcet[m]>
j_ey was right, it's the same (is it possible the macbook pro is really just an overpriced mba without function keys? ;-) )
<amw>
Do I need to change the interrupt-parent/AAPL,phandle ?
<pipcet[m]>
nah, we're not using the interrupts
<pipcet[m]>
just make sure you use the right dtb if you test.
<pipcet[m]>
(it's called t8103-j293, but it's just t8103-j274 plus the keyboard backlight)
<amw>
I need to enable PWM_APPLE_M1 and recompile ?
<pipcet[m]>
PWM_SYSFS too
<pipcet[m]>
(there's another patch which exposes the PWM as a brightness control for an LED, but that's just DT magic)
jelly-hme is now known as jelly
<amw>
pipcet[m]: I get applespi spi0.0: Error getting backlight level from EFI vars: -22
<pipcet[m]>
that's okay, that's the SPI keyboard backlight code in the applespi driver, for intel macs
<amw>
What am I suppose to do to enable it? A /sysfs entry ?
<pipcet[m]>
you should see a device in /sys/class/pwm; cd to /sys/class/pwm/pwmchip0; echo 0 > export; then a directory shows up with "enable", "duty_cycle" and so on. You can play with those (units in nanoseconds) :-)
<pipcet[m]>
though now I look at it, the missing clk gate might get you
<amw>
Hmm echo 1 > enable => Invalid argument
<pipcet[m]>
did you set duty cycle and period first? if the duty cycle is longer than the period the pwm code will fail to enable.
<j_ey>
amw: you could try apply that to remove the EFI vars err at some point
<amw>
Oh that wasn't so good : echo 100 > period gave SError and stack trace... no keyboard working ...
<pipcet[m]>
yeah, the clk gate. you can enable that in m1n1, I think.
<pipcet[m]>
no clock -> nothing decoding the MMIO address -> SErr
<amw>
ok - guess those clocks are important for something :-)
<pipcet[m]>
pmgr_adt_clocks_enable("arm-io/fpwm") in the shell, I think.
<pipcet[m]>
(that's part of the reason I'm trying to push the fpwm driver: it actually needs a clock and will do something visibly wrong if it's disabled while it's on)
<amw>
pipcet[m]: Can you enable it in a driver or something?
<pipcet[m]>
you can enable it with memtool if you know the address...
<pipcet[m]>
it's 0x23b7001e0 here, I think, though I'd enable the gate before and after that just to be sure.
<pipcet[m]>
that would be "memtool mw 0x23b7001d8 0xf 0xf 0xf", which I'm going to try here...
<amw>
ok - enabled clock and booted it back up and no crashes - so far - but no backliht that I can see?
<pipcet[m]>
what did you set the duty cycle to?
<amw>
I did echo 100 > period; echo 30 > duty_cycle; echo 1 > enable
<pipcet[m]>
er, it's nanoseconds, try 100000 and 30000?
<amw>
ok - yep that's working!
<pipcet[m]>
thank you very much, that's great. One last thing before I shut up; can you test a period of 1000000000 (that's a US billion) and a duty_cycle of half a US billion and see whether it flashes once per second, roughly?
<amw>
If you wanted to go really gaudy you could try updating the Asahi Wiki with that and see if it displays the flashing keyboard ...
<j_ey>
now make it do RGB :D
yuyichao has quit [Ping timeout: 480 seconds]
<pipcet[m]>
nope, displays the alt text. Maybe my browser doesn't understand your fancy new mp4s :-)
<pipcet[m]>
oh, btw, and this is a lot simpler, does the caps lock LED work? that gives us a grand total of two user-controllable LEDs!
<alyssa>
:P
floxf5[m] has joined #asahi
<alyssa>
pipcet[m]: once marcan and i bring up dcp that'll give another few million "LCDs" ;)
<alyssa>
*"LEDs"
<pipcet[m]>
in my day, that's all we needed to get a system up and running, but now you kids have fancy frame buffers and all that
<pipcet[m]>
all that graphics nonsen...hi, alyssa, how's the DCP work going?
<alyssa>
i have a full time job and it's not this
<sven>
amw: can you elaborate on that corruption? do you get any error messages? does this usb drive work with other machines? 'cause i've been using that branch for a while without issues so far
jeffmiw has joined #asahi
yuyichao has joined #asahi
chadmed has quit [Remote host closed the connection]