marcan 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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
boardwalk has joined #asahi
boardwalk9 has joined #asahi
boardwalk has quit [Ping timeout: 480 seconds]
boardwalk9 is now known as boardwalk
tomtastic_ has joined #asahi
tomtastic has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
<bgb>
marcan: I'm using vdmtool with arduino, ttyUSB0 is the USB2Serial module, seems my FUSB302 board is broken
<bgb>
marcan: btw, I think it's possible to send cmd to arduino(with vdmtool) in python code. I want to write a simple Mac reboot cmd in python, and tried ser = serial.Serial("/dev/ttyACM0", 500000) ser.write(b"5AC8012,0105,80000000\n"), it didn't work. is there any difference from the Ardunio Terminal tool?
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
tomtastic_ has quit [Read error: Connection reset by peer]
<Glanzmann>
marcan: I would like to try your new installer, is the process documented somewhere? I only found the git repository with a stub readme.
Hotswap has joined #asahi
mort_ has joined #asahi
<bgb_>
jannau: works well, thanks.
<_jannau_>
bgb_: had had in the beginning also issues which led me to believe my fusb32 board was broken. I was wrong but I can't remember the details
<bgb_>
yeah, fails several time before working, do not know why
<marcan>
bgb_: mine is just
<marcan>
stty 500000 </dev/ch340
<marcan>
echo > /dev/ch340
<marcan>
echo 5AC8012,0105,80000000 > /dev/ch340
<j_ey>
whats ch340?
<j_ey>
oh the arduino?
<marcan>
just an alias for the serial converter in my arduino
<marcan>
Glanzmann: it isn't, but try curl -L mrcn.st/alxsh | sh
<marcan>
you need to have previously resized macos or otherwise made empty space or have a new APFS container
<bgb_>
marcan: ah, works well too, thanks :)
<bgb_>
weird thing is the python code begins to work too, seems the hw needs "warmup"...
___nick___ has quit []
<marcan>
bgb_: yes, I always open a terminal to the ch340 first so I can see the init output
<marcan>
the arduino resets on DTR or something like that
<marcan>
heh, an AC2 restore just failed halfway through with a USB dropout, just like I saw with idevicerestore a few times
<marcan>
looks like that's just flaky USB hardware in these things... :/
<marcan>
seems gadget mode in macos isn't quite as stable as it should be
<j_ey>
C-a C-t sends a DTR toggle in picocom, so you could try that twice, or C-a C-p once (that pulses DTR) to try reset the arduino
<marcan>
hm, seems Apple both fixed the role swap issue in 12.0, and also gimped it to USB2
<marcan>
11.6 restores in USB3 (10Gb/s), 12.0 always seems to go to 480Mb/s with the same cable
<marcan>
(even with a Linux host and idevicerestore)
<marcan>
that's sad, USB3 makes the restore more than 2x faster
<j_ey>
hopefully not an operation you have to do often
___nick___ has joined #asahi
<marcan>
it's not too bad though, ~5m USB3 ~10M USB2
<marcan>
*10m
<povik>
marcan: what do i need to know about m1's memory to write drivers?
<povik>
assume i have been writing drivers on microcontrollers
<povik>
so have been spared issues like cache coherence, write ordering
<marcan>
well... the good news is everything is cache coherent on the M1, as far as we know
<marcan>
then the other good news is you get to watch Will's talks!
<nsklaus_>
povik: i would like to ask (noob question) why a driver to handle memory is needed ? i mean, we've seen asahi already able to run up to desktop graphical session and all, how was that even possible if asahi on M1 didn't know how to handle available memory ?
<nsklaus_>
or maybe just a subset of available memory was being used at the moment ? meaning that most of the ram wasn't usable so far ?
<povik>
nsklaus_: no no, i am writing a driver for audio, not a "memory driver"
<nsklaus_>
aah ok it was a misunderstanding on my part then, thank for correcting
<j_ey>
but an audio driver has to write to memory
<povik>
but i am using memory and memory-mapped io, and i am wondering what assupmtions i can make about memory accesses and how they will be carried out
<povik>
nsklaus_: it's not a bad question at all
<nsklaus_>
i would have thought memory allocation even for drivers was handled by the kernel
<j_ey>
nsklaus_: it is!
<j_ey>
but this is about the instructions used to write to those areas of memory, and what *attributes* the kernel sets on that memory while mapping it
<marcan>
povik: thankfully for a "typical" driver you don't need to worry *too* much about this, other than standard locking/concurrency primitives
<nsklaus_>
j_ey: hmm i think i see the nuance now, thanks
<marcan>
the main thing is to use readl_relaxed/writel_relaxed *unless* you are doing something that needs to be ordered with respect to DMA
<marcan>
then you use readl/writel or dma_ barriers
<marcan>
so if you have a sequence of operations that is like "okay, stuff got written to RAM, now tell the device about it", then that needs a barrier or the first MMIO to tell the device about it needs to be a non-_relaxed
<kettenis>
nothing M1 specific there really
<marcan>
similarly, if you have "okay, the device wrote stuff to RAM and told us about it, so go read it", that needs a barrier or non-_relaxed
<marcan>
and yes, none of this is M1-specific, this basically goes for all architectures
<marcan>
certainly all ARMv8
gladiac is now known as Guest1113
gladiac has joined #asahi
<povik>
what about mmio read/writes wrt to each other? no funny business there?
<marcan>
nope, those are all ordered
<povik>
great
<maz>
similar requirements for ARMv7, only that most cores are too strongly ordered to show any difference.
<marcan>
however, the CPU does speculate, so don't assume any writes or reads actually happened in later non-memory code
<marcan>
this mostly only matters if you're dealing with timestamps
<marcan>
e.g. "write a register, get current time" might give you a time before the register actually got written without a barrier
<povik>
well but that is a mmio read/write reordered, no?
<marcan>
"get current time" is a CPU system register, not MMIO
<povik>
right
<povik>
i see.
<marcan>
M1-specific, make sure you use of_iomap to get your register ranges mapped
<marcan>
that will make sure the memory attributes are set up properly
<j_ey>
8.6 has those CPU sys regs but self-synchronising versions that dont need an ISB
<marcan>
j_ey: and Apple already has those as impdefs in M1 (we think)
<j_ey>
oh interesting
<maz>
j_ey: go forth and review the series dealing with that on the list! :D
Guest1113 has quit [Ping timeout: 480 seconds]
<maz>
(the 8.6 stuff, nothing M1 specific)
<marcan>
j_ey: see CNTPCT_ALIAS_EL0 CNTVCT_ALIAS_EL0 in apple_regs.json
<marcan>
we haven't validated the ordering semantics, but the only real reason for them to exist is a pre-standard version of that...
<povik>
what presents the cpu from speculatively reading a read-sensitive mmio register? an mmu attribute on that range?
<marcan>
yeah
<povik>
okay
<sven>
+1 on will's talk. they're great!
<sven>
+s
<marcan>
same thing that makes mmio ordered wrt itself
<marcan>
(as opposed to normal memory)
<marcan>
that too, if you have DMA descriptors in normal memory that need to have flags set in a given order (e.g. ownership flags) or things like that, that needs barriers too
<marcan>
since that isn't mmio
<marcan>
see memory-barriers.txt, that has some obvious examples
<j_ey>
maz: I did wonder why you added a nop, in the arch_timer_read funcs? or maybe I should ask on the list
<maz>
j_ey: because alternatives must use the same number of instructions.
<marcan>
povik: also M1-specific, since it's cache-coherent as I said, don't bother with uncached memory or any of that
<marcan>
that would just slow things down
<maz>
j_ey: so you go from isb+read to nop+read.
<j_ey>
maz: oh, I hadnt noticed that before
<povik>
marcan: noted
<kettenis>
so how does audio output work? is it I2S with a separate DMA controller?
<povik>
yes
<kettenis>
and a separate mixer/codec chip controlled over I2C?
<povik>
yes
<povik>
i assume there's something i would call mixer on the chip, before it's sent out over i2s
<povik>
but i don't understand that part yet
<j_ey>
povik: marcan said to use of_iomap, but youre probably going to use devm_platform_ioremap_resource to map the memory, which does the right thing too
<marcan>
yeah, both of those work
<povik>
i will do one better, i have devm_platform_get_and_ioremap_resource in code
<j_ey>
you need the resource separately?
<povik>
not as far as i know
chadmed has quit [Quit: Konversation terminated!]
<povik>
i guess i can drop the *get* part and it does the same
<j_ey>
yeah, devm_platform_ioremap_resource just calls devm_platform_get_and_ioremap_resource(dev, index, NULL)
<kettenis>
povik: typically there are multiple I2S channels on a SoC, but only one of those tends to be connected to the external codec
<povik>
on mini, there's one i2s channel connected to codec/speaker-amp driving the speaker, another channel connected to a codec driving the audio jack
<marcan>
on these machines I'd expect at least separate outputs for speaker, headphone jack, and possibly s/pdif if they're still doing that over those jacks
<marcan>
and then whatever they're doing with microphones, pretty sure these machines have at least two
<marcan>
there's also HDMI audio, which I assume is somehow internally routed into the display block
<maz>
probably something routed to hdmi as well.
<maz>
maybe even BT, unless that's just an analog routing.
<marcan>
nah, BT is all software
<marcan>
don't think I've ever seen that done in hardware on any laptop
<klange>
over in x86/pc land, hdmi audio is generally presented as an independent device; usually a separate pci function from the gpu that carries it
<povik>
there's something called mca/mca-switch standing between the audio dma and the i2s channels
<povik>
i expect it routes the channels and controls the i2s serialization
<povik>
btw anyone knows what mca might stand for?
<maz>
Multi Codec Adapter?
<maz>
(I hope it doesn't refer to the ancient IBM bus... :D)
<povik>
good guess, had to google if it's an established term
<povik>
seems not
<maz>
multi channel audio is probably a better name, actually.
<povik>
i like the first one better
<maz>
make up your own name, it will be debated to death on the list anyway.
<phire>
M could be multimedia
<dottedmag>
magnetic core amplifier, FWIW
<bgb_>
marcan: for smp-hypervisor, can i set cpus=8 ?
<j_ey>
bgb_: yes
<bgb_>
I always fail with AOP:ALSOPDriver..... then panic
<povik>
i have been happily running with no cpus=, which should effectively be the same, wonder if there's a difference
<bgb_>
povik: ah, boot 8 cores without cpus= :)
<povik>
there you go
<povik>
we should make a note of it in the wiki
<alyssa>
maz: "make sure you use of_iomap to get your register ranges mapped" ...or the devm all in one ;)
<alyssa>
oh j_ey already said
<povik>
yeah, we already discussed the nuances of this :)
<alyssa>
do I review code or show up to class on time hmm
chadmed has joined #asahi
<povik>
what's more interesting?
* povik
is learning for an exam in parallel, recommends showing up in class
<povik>
that's what i would recommend my past me
<chadmed>
skipping classes is great until its exam block and youre cramming 13 weeks of boring ass content 36 hours out from your massive 70% exam
<alyssa>
alas.
<alyssa>
ok, reviewed the series, onto class :-p
<chadmed>
all students here have a duty to keep each other honest
<povik>
those starting their exam block should be forced in contact with those starting their lectures
<psykose>
those are the same group, though
<psykose>
:p
<povik>
*nominally starting their lectures
<chadmed>
yeah just be responsible with your skipping i guess. i skipped a histology prac class last week thinking i had plenty of time until the exam, turns out its actually almost the end of the semester and that was our last chance to practice microtomy before we're assessed on the skill lmao
<chadmed>
dont let that be you
<marcan>
klange: I think here HDMI audio is integrated into the SoC audio stuff
<klange>
it would make a lot of sense if it was just another codec/pipe/port alongside everything else
<povik>
are there some public ADT dumps from the mba/pro?
<povik>
or could someone send me the parts having to do with admac/mca/codecs?
<sven>
fwiw, your wifi passphrases are in the ADT dump
<j_ey>
povik: theres a python script in m1n1/tools to dump the adt
<povik>
i thought the phandle refers to /arm-io/nco, saw no macos pokes to the region, and called it a day
<marcan>
ahh, now we know what the NCOs are for
<marcan>
I was wondering
<marcan>
so this is audio
<povik>
don't be so quick just yet
<povik>
i also know i need to poke a register which is listed as #113 in boot clocks
<povik>
from your script
<povik>
and that would check out to be mclk
<povik>
but then there's the name='NCOf' part which puzzles me
<povik>
so either it refers to /arm-io/nco, in which case the boot clock poke would be a coincidence, or it refers to the boot clock, but then why there's nco in the name
<povik>
or -- there's some connection between the boot clock index and device phandle in ADT
<povik>
(i don't know what those boot clocks are supposed to mean exactly)
<povik>
note i can switch between 48/96 ksps through this register
<marcan>
yeah, that's changing a clock mux
<povik>
sure, but to me it means that is the mclk clock
<marcan>
yes, it's likely the mclk input, and the two settings are switching between different (hardcoded, likely) dividers of NCO output
<marcan>
this is on the mini, and which mca?
<povik>
mini, /arm-io/mca3/mca3a
<marcan>
mclk-config also has the NCO index in the low bits
<marcan>
it's entirely possible 113 is a coincidence, and the clock offset is hardcoded somewhere
<povik>
meaning the phandle refers to /arm-io/nco ?
<marcan>
yes
<marcan>
it would be extremely weird if it didn't
<marcan>
and an NCO is exactly what I expect to be driving an audio block
<povik>
okay
<povik>
marcan: why is the list called boot clocks?
<povik>
(in dump_pmgr.py)
<marcan>
because (hopefully) it lists the clock config at boot
<marcan>
obviously some things can change
___nick___ has quit [Ping timeout: 480 seconds]
<marcan>
so the question is how does it know about that clock reg
<marcan>
and the answer might well be "it's hardcoded somewhere"
<povik>
not a tough sell
<nsklaus_>
i was looking at the wiki's tasks list here :https://github.com/AsahiLinux/docs/wiki/Tasks
<sven>
the CIO (thunderbolt crap) "reclock" (i doubt it's a clock) is just hardcoded in some kext fwiw
<marcan>
addr = 0x000000003B0400D4
<marcan>
size = 0x0000000000000018, Container:
<marcan>
there you go
<sven>
but ofc still listed in that pmgr devices array with all entries set to zero
<marcan>
mca-switch has a regblock pointing riiight into the clocks at the right place
<nsklaus_>
which is not updated much unfortunately, but, i was was wondering what are some of the big tasks to be done,
<povik>
marcan: of course, missed that
<nsklaus_>
i see : touchbar, touchpad, camera.. is there any other left ?
<marcan>
not sure why mca3 would be offset 1 in that though, probably referenced somewhere
<nsklaus_>
then i saw this: "Unified Memory Controller" one.. is that one done already ?
<j_ey>
nsklaus_: sound, touch id, emp etc
<sven>
nsklaus_: usb 3, thunderbolt, secure enclave, GPU are the big ones that come to my mind (in order of increasing complexity :D)
<sven>
oh, and nvme. but that's mostly getting the driver in a shape that allows reviews
<j_ey>
nvme is done(tm)
<nsklaus_>
j_ey: sound seems to be being worked on, with some success already
<marcan>
0x18 size though, so that's exactly 6 clocks, which matches up with 6 MCA clusters
<j_ey>
nsklaus_: yeah but that's just a Proof of concept, still some way to a driver
<marcan>
povik: you sure this was mca3 and not mca1?
<nsklaus_>
i understand gpu part need a lot more work, but for starters if it have wworking accelerated 2d, it's already nice
<marcan>
I guess this means I get to write a clocksel driver after all...
<povik>
marcan: no, got confused, it's mca1/mca1a driving the speaker in ADT
<marcan>
well that explains it then
<povik>
it does
<marcan>
6 consecutive clocks, one for each mca
<marcan>
:)
<nsklaus_>
j_ey: that part i do not understand, how come linux already work on M1 if the M1 memory is "unified memory" and linux doesn't know how to handle that and have no driver for it already ?
<j_ey>
nsklaus_: Im not sure what that TODO list was meant to suggest
<sven>
i think that's because that item doesn't make much sense
<nsklaus_>
sven: ah thanks for clarification :)
<marcan>
nsklaus_: accelerated 2D is not a thing
<marcan>
these GPUs are 3D only
<marcan>
"2D" acceleration is just 3D with no depth
<nsklaus_>
marcan: you mean the gpu on M1 use 3D function to display 2d too ?
<nsklaus_>
hmm i see
<marcan>
yes, 2D acceleration hasn't really been a thing in a while
<marcan>
and yes, that "unified memory controller" thing doesn't make any sense unless you mean stuff like the perf switching driver I have to write
<marcan>
as in "things we might have to deal with in the memory controller"
<marcan>
it doesn't mean memory doesn't work
<nsklaus_>
marcan: i might have been living under a rock for some time, that may explains things
<nsklaus_>
(about 2D acceleration)
<marcan>
povik: I'll put a clocksel driver on my list, having the audio driver poke that register directly is very ugly
<nsklaus_>
hmm, so in essence what we have for display driver in asahi at the moment, is a plain unaccelerated framebuffer, and no gpu driver , is that it ?
<kettenis>
correct
<nsklaus_>
kettenis: i see, thanks for acknowledgement
<j_ey>
nsklaus_: and alyssa is working on the display driver which is part of that stack
<marcan>
(and yet it's still faster than other ARM chips *with* acceleration...)
<kettenis>
and if your CPU is fast enough and GPU memory is cache coherent, that is good enough for a normal desktop environment
<j_ey>
marcan: even when running at 600mhz for the big cores :P
<nsklaus_>
i did follow alyssa xorg conference/talk, and the various progress made on that front too, i think things are progressing quickly and i'm very happy about that. and even using plain framebuffer for starters would be fine by me
<j_ey>
you dont even need her dcp driver for that, I think the simple-framebuffer works fine for a DE too?
<kettenis>
yes, you're just stuck at whatever resolution iBoot gave you
<kettenis>
which is fine on the laptops, but not on the mini with a 4K screen
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
<povik>
marcan: as i remeber it you can switch to 96 ksps through another register, this time in the mca range proper
<povik>
does that mean we still need a clocksel driver?
<povik>
seeing as we may need that clock mux in one fixed position only
<kettenis>
that'll certainly make things simpler
bgb_ has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
yuyichao_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<alyssa>
sven: SEP is harder than Thunderbolt?
<alyssa>
marcan: I might argue overlay planes count as a /very/ primitive form of 2D accel
<alyssa>
(Particularly on display controllers with writeback support. I don't think DCP does wb though.)
<alyssa>
kettenis: correct
<alyssa>
(You also get tearing.)
<sven>
alyssa: i think so. thunderbolt is mostly just reading some linux code to understand how the DT is supposed to look like and then it's just uncovering ATC PHY's magic tricks
<sven>
SEP is a bit more annoying because it has an ipc protocol over another ipc protocol :(
<sven>
it also at least needs APFS read support for something they call "gigalocker" (containing anti replay tokens and maybe more stuff)
<sven>
and then ofc it needs userland support so that you can store SSH keys or your nvme encryption keys
<sven>
i actually think most of SEP will be userland fwiw
<alyssa>
Delightful
<alyssa>
how much can we share with 'normal' TPMs?
<sven>
no idea, but chances are not much
bgb_ has joined #asahi
<alyssa>
:'(
<sorear>
can more be shared with userland SEP support on macOS for ssh etc?
<sven>
no, because that all talks to the SEPUserClient kext or however it's called
<marcan>
povik: if the clock mux never changes, we might not need a clocksel driver
<marcan>
but either way, I intend to spend tomorrow marathoning small kernel drivers (finally), so if I get to it, why not
bgb_ has quit [Ping timeout: 480 seconds]
FireFox317 has joined #asahi
<FireFox317>
marcan: on stream? :D
<FireFox317>
was lurking via the whitequark logs xd
<povik>
marcan: i will not stop you :)
<povik>
also, i lobby for a gpio driver
<povik>
(don't know what's the state of the art on that)
<j_ey>
gpio/pinctrl is on the list
<povik>
for review? great
<j_ey>
povik: i assume you need it for i2c/audio?
<povik>
yes, for toggling a reset pin, which probably isn't strictly necessary
<povik>
but it makes me sleep better at night
<alyssa>
povik: you also have M1 kernel nightmares?
<marcan>
FireFox317: yeah
<marcan>
povik: I spent some quality time with a multimeter on a call with j_ey the other day to figure out the gpio bits :)
<marcan>
(I used the UART TX pin as a guinea pig, since I could poke that externally)
<j_ey>
I got to watch marcan fiddle with a multimeter for a few hours
<marcan>
and a scope!
<sven>
oh, uart tx is also exposed as a gpio pin?
<marcan>
most jellybean IO pins are, yes
<marcan>
uart0 tx is at 0x23c100280
<sven>
interesting
<marcan>
which is actually in the adt!
<marcan>
function-tx = 102:GPIO(0xa0, 0x102)
<sven>
hah!
<marcan>
but yeah, it's not really gpio regs, it's pinctrl overall
<marcan>
it even has 16 (!) drive strengths to pick from
<marcan>
and a schmitt trigger input mode (with a really low hysteresis...)
<marcan>
and pull-ups/downs (two pull-up strengths to choose from)
<marcan>
and all that applies regardless of which of 4 peripheral modes you put it in (0=gpio, or 3 peripheral pin selects)
<marcan>
was fun to figure out all that :D
<marcan>
I wish we could get the "select" mappings somewhere for this kind of stuff though... pinselects for this, clockselects for those registers...
<marcan>
it's really hard to work that out by guesswork
<sven>
you mean what those three peripherals are for each pin?
<marcan>
yeah
<marcan>
peripheral.pin
<marcan>
we know e.g. at least some uarts can have rts/cts broken out
<marcan>
uart2:
<marcan>
function-rts = 102:GPIO(0x94, 0x2)
<marcan>
function-tx = 102:GPIO(0x92, 0x102)
<kettenis>
ah, so my guess that there actually are 4 functions for the pins was right?
<povik>
alyssa: not yet
<marcan>
kettenis: yeah, it's two bits
<marcan>
0 is just gpio
<marcan>
I actually thought it was 8 at first, then realized the next bit was actually part of pull config
<marcan>
I'd confused myself going too fast on that
<kettenis>
there are standard DT properties for pull up/down, drive strength and schmitt-trigger
<kettenis>
those should be used if we add support for this to the pinctrl driver
<marcan>
yeah
<kettenis>
only down side is that they require you to specify things in physical units
<kettenis>
so you might need to bring out that multimeter again if you didn't write things down ;)
<marcan>
though I didn't do all 16 drive strengths
<kettenis>
probably best to keep things simple for the initial pinctrl driver
<j_ey>
???
<j_ey>
kettenis: yeah, that's what I think too, since we havent needed any of these yet for i2c, spi, pcie etc
<kettenis>
probably because iBoot configures the pins already
<marcan>
yeah
<marcan>
(and clocks etc)
<j_ey>
I think it would be fun to write a m1n1 randomiser to just setup the hw in random states
<povik>
that sounds just needlessly cruel
<j_ey>
only cruel to us
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: you still need a DT binding for the pmgr stuff
<marcan>
you mean the doc?
<marcan>
I know
<marcan>
I'm going to wrap up all these jellybean drivers tomorrow if I can
<marcan>
cpufreq too
<marcan>
looks like I should have a relatively uninterrupted day :p
<kettenis>
yup, the doc (in the form of a schema)
<marcan>
yeah
<kettenis>
once that is sorted out, we should see if we can somehow get a more complete device tree
<marcan>
I think we should add these blocks piece by piece, but at least the deps we use right now, yeah
<kettenis>
things are diverging a bit, which is hurting some of the people who are not too familliar with device trees
<marcan>
yup
<marcan>
once these things are done, the next thing I want to do is do a merge branch to put all this in order
Orsira has quit [Read error: Connection reset by peer]
bgb_ has joined #asahi
jhweruyuw has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
kdrag0n[m] has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<alyssa>
marcan: Any idea in what ways a TV is "special" compared to a monitor? (Both over HDMI)
<alyssa>
not only did the DCP driver not work on a TV I tried briefly, the iBoot framebuffer didn't even come up (no Apple at boot)
<sven>
the iboot framebuffer at least worked on my tv over hdmi
<alyssa>
maybe this was an "extra special" tv then
<sven>
lovely
<maz>
kettenis: victory is yours! :D
<alyssa>
Wooooot!
<milek7>
tv might want YPbPr colors
<alyssa>
that "shouldn't" be AP visible but who knows with this cursed interface
bgb_ has joined #asahi
<alyssa>
/var/log/kern.log looks totally normal -- DCP booted, did a mode set to 4k ("Wait. That TV looked awfully low quality for 4K") ...
<kettenis>
maz: did the pcie binding go in as well? Only seeing the messages about the MSI controller YAMLfication bits
<sven>
he said just as the email confirming that arrived :)
<maz>
kettenis: everything.
<maz>
ok, maybe not the last one, but I'm happy to pick that one.
<j_ey>
the last one says "DART (IOMMU) references are left out at the moment and will be added once the appropriate bindings have been settled upon", they can be added now?
<sven>
yup
bgb_ has quit [Ping timeout: 480 seconds]
<sven>
they'd only be missing the power-domains, but those can be added later anyway
<maz>
I'll try and respin a pcie series tomorrow, including Mark's patch including the pcie node.
<sven>
i guess we should add the DART nodes to make it actually work. maybe kettenis can just add an additional commit or something for those
<sven>
or wasn't there already a commit to add those floating around somewhere?
<maz>
I have such a patch in my tree. I'll write a commit message and add it as well.
<alyssa>
Woop woop!
<sven>
looks like i2c and tipd will also make it into the next merge window. that should also give us working usb-c ports then
jhweruyuw has quit []
<sven>
so that should make the mini useful for some tasks already, and if someone writes a SPI driver we could also have a somewhat useable system on the macbooks then
<j_ey>
sven: patch 1/N for nvme will be in 5.15 too :p
<sven>
lol
<kettenis>
yeah, the dart stuff just didn't make it into the tree I was working from yet
<kettenis>
and the actual device tree changes have to go through marcan's tree anyway I believe
<kettenis>
one thing we should consider before doing that is to move the interrupt-parent to the root of the tree
<kettenis>
that way we don't have to repeat it in every device node
<sven>
sounds good to me
jbowen has quit [Ping timeout: 480 seconds]
Fruit has joined #asahi
<alyssa>
sven: realistically will people be using mainline on any m1 before, like, 6.x?
<alyssa>
(Pure mainline I mean, not mainline+patches)
jbowen has joined #asahi
<sven>
if we get dcp and nvme and usb3 into 5.17 i could see people using just that
<alyssa>
that
<alyssa>
's fair, yeah
<alyssa>
and also spi and cpufreq and reboot/wdt ...
<sven>
true
<alyssa>
though those should all be minor afaiu
<sven>
yeah. i think the biggest one is probably dcp
<alyssa>
honestly nvme and dcp are the only Scary ones for short term
<alyssa>
yeah
<alyssa>
(DCP is more code than NVMe but the NVMe code is errr scarier :-p)
<kettenis>
reboot/wdt is probably important ;)
<sven>
for nvme i just need to stop being lazy for a weekend and split that single "WIP: nvme" commit into smaller ones that can be reviewed
<j_ey>
as well as spi, they actual keyboard driver needs moifying to be OF aswell as ACPI
<sven>
nvme isn't _that_ scary fwiw. there are still a few parts where I'm not sure what's going on but I understand most of it now
<alyssa>
sven: nvme is inherently scary for eating data risk
<kettenis>
alyssa: not really
<sven>
ah, but that's the fun part: all the really scary things are handled by the nvme core
<eta>
mm, tasty data
<sven>
and the absolute worst case that has happened to be was losing maybe the last 5 minutes or so of modifications
<sven>
and that involved crashing ANS
<kettenis>
i've hacked on various disk drivers in OpenBSD over the years, and I don't think I've ever had code that ate any data
<sven>
s/be/me/
<kettenis>
mostly the issue was data not landing on the disk for various reasons ;)
<Glanzmann>
marcan: At lest I though so, but once I powered on the system again, it went to recovery because there was a problem. After executing the installer, poweroff, poweron it should show the m1n1 logo, shouldn't it?
<Glanzmann>
marcan: Btw. This was a mac mini, freshly erased and installed with macos, all updates applied.
<Glanzmann>
I freed up space using: diskutil apfs resizeContainer disk0s2 200GB
<Glanzmann>
This is 11.6.
yuyichao_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
marcan: If I boot to the Linux 'stub' my Eizo (HDMI connected) says going into powersafe and shows a black screen after a few seconds it shows the apple logo and boots into recovery.
<sven>
Glanzmann: the last line in that log you posted says "Press enter to continue.". have you done that?
<Glanzmann>
Yes, I did that, got the boot picker, selected linux stub, entered my password
<Glanzmann>
And the system rebooted or powered off.
<Glanzmann>
I'll now try to in 1tr, make the partition writable and update m1n1, maybe that resolves my issue. Keep you posted.
<sven>
hm... if you did this from outside recovery it should've printed something about running step2.sh from 1tr
<alyssa>
M1 is not happy with my usb ethernet apparently.
<kettenis>
wired ethernet not working for you?
<Glanzmann>
marcan / sven: I misse step 2, trying again from 1tr with the partitions deleted.
jbowen has joined #asahi
<alyssa>
kettenis: I need to be able to also connect to my board
<alyssa>
which I can't do over LAN because... remind me again? >_>
<Glanzmann>
marcan: install fails in 1tr because their is no xattr see above, so try again from macos with step2
<alyssa>
kettenis: the real issue of course is that the LAN is beyond broked.
<alyssa>
*borked
<kettenis>
you mean the bit outside of the mini?
<alyssa>
yes.
bgb_ has joined #asahi
povik has quit [Remote host closed the connection]
<Glanzmann>
sven: Thank you for the tip. Running the installer from macos but run step2.sh from 1tr did the trick.
povik has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
aleasto has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
kedde[m] has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
alyssa: I tried the steps you wrote me a few days ago. And I'm able to boot the kernel. But the last thing I see is the kernel boot output. Than it appears to switch modes my screen goes blank and python chokes on me: https://pbot.rmdir.de/T089FN2mccBtW9gaPNgyEA any ideas?
<Glanzmann>
I installed it fresh yesterday and applied all updates.
bgb_ has quit [Ping timeout: 480 seconds]
<alyssa>
oh... joy.
<alyssa>
I think I might be 11.4 here. ugh.
<alyssa>
this is why we hate DCP, kids.
<alyssa>
will need to check. ugh. 😢
<alyssa>
you can disable CONFIG_DRM_APPLE in the mean time for no DCP but.. yeah
<Glanzmann>
I try now and let you know how it went.
<Glanzmann>
alyssa: This worked. Got a login prompt from the rootfs from the USB.
* alyssa
nods
* alyssa
sighs at DCP
<alyssa>
marcan: Do we know how to detect DCP fw version at runtime?
<sven>
hm, i think the hash or something of the firmware is in the ADT if all else fails
bgb_ has joined #asahi
<alyssa>
sven: Awful :p
<sven>
ohhh. i have another idea! i'm sure you'll like it! :>
<alyssa>
nope, i won't
<sven>
you could trigger a recoverable crash to get the version from the crashlog!
<j_ey>
..
<alyssa>
sven: We know each so well ;-)
<sven>
you just never like my best idea :<
FireFox317 has quit [Quit: Page closed]
bgb_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
alyssa: I was able to 'cp -ax' the rootfs onto the nvme and boot from it. Thanks a lot. These are the steps I did roughly: https://ab34.de/u/asahi.txt
<alyssa>
Glanzmann: 👍
<j_ey>
`git checkout many-hacks`
<alyssa>
j_ey: look I don't do false advertising
<j_ey>
new branch: more-many-hacks
bgb_ has joined #asahi
<Glanzmann>
When installing packages the nvme appears to be slow, does someone know why that is?
<Glanzmann>
But with hdparm -tT I get 2 GB/s / 1 GB/s Memory appears way to slow for the machine. I think it should be around 20 GB/s at least this is the number I have in my head for runing the same test under macos.
<alyssa>
there are some power registers needed to upclock
<alyssa>
there's a python script in m1n1 you can run before boot
<Glanzmann>
I read that in the irc backlog. Will try that.
<Glanzmann>
alyssa: I tried to run 'startx' but the xserver did not start. Do you have any instructions on getting this to run. I'll paste the output soon.
<alyssa>
you want a DRM driver
<alyssa>
failing CONFIG_DRM_APPLE, there's a CONFIG_DRM_SIMPLEFB you can enable (grep for it..)
<Glanzmann>
alyssa: I assume you mean CONFIG_SYSFB_SIMPLEFB, correct?
<alyssa>
dont have kernel in front of me, am doing Panfrost right now
<alyssa>
why am I on IRC? that's a good question
* alyssa
closes window
bgb_ has quit [Ping timeout: 480 seconds]
<j_ey>
Glanzmann: CONFIG_DRM_SIMPLEDRM
<j_ey>
I think
jbowen has quit [Quit: leaving]
<Glanzmann>
j_ey: I see, found it. Thank you. Will try it.
bgb_ has joined #asahi
<Glanzmann>
j_ey: I set it, but now I don't have a console anylonger, however Linux has booted and I see the asahi logo in the middle of the screen. Probably I have disabled to much.
<j_ey>
Ive never tried it
<Glanzmann>
I see. Btw, after applying the pstates, nvme performance is improving a lot: https://pbot.rmdir.de/NDpwSeDyw7qGXfR79GClZA . Factor 13 for memory througput (fater than macos) and factor 3 from what I meassured before.
<Glanzmann>
So thanks for all the help, I'll try to get the framebuffer x running tomorrow and hit bed now. With the pstates installing packages also appears faster.
<alyssa>
wish you could just use DCP and have it Just Work
<kettenis>
alyssa: marcan's plan was to only support certain firmware releases
<alyssa>
I know
<alyssa>
that's long term, what's the short term?
<Glanzmann>
alyssa: I'll try once you have something ready for the new macos. Or I retry on a macbook air. There the update does not apply because 'it could customize the update for me' ...
<Glanzmann>
Oh and NVMe is very slow. single thread 4k random is 50 IOPS, 80 concurrent threads is 2000 IOPS.
<kettenis>
alyssa: you pick a version and tell everybody that's the only version that's guaranteed to work ;)