user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grgy has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
<marcan>
err... the low 16 bits of the raw RTC time I read are always constant, and the RTC time returned by SMC is << 15, not <<16, and does have active low bits
<marcan>
I'm smelling another "corellium did it wrong and everyone copied them" here...
<marcan>
oh wait, on the m1pro & friends it always goes via SMC anyway. let's see about the mac mini..
<marcan>
ah, it does work on the mac mini/sera, interesting
<marcan>
and the LSB is always 0 so it's clearly <<15 either way
user982492 has joined #asahi-dev
<marcan>
so the fractional part of the RTC time is somewhere else on maverick... dumping registers now :/
<marcan>
and I can't find it, lovely
the_lanetly_052 has joined #asahi-dev
AstaraOS has joined #asahi-dev
* AstaraOS
hi all skraito here how are ya all ?
* AstaraOS
what you guys up to ?
* AstaraOS
hey mind to do some coding advise at channel #0dev , let me know if anyone interested , lets code together
<AstaraOS>
<AstaraOS> yeah actually i am trying to break tor
<AstaraOS>
<arma> ah ha, i see that you have spammed every channel. definitely the wrong place.
<AstaraOS>
<AstaraOS> anyway if i know all node
<AstaraOS>
<AstaraOS> whwat is it that this tor is super bitcha anyway ?
<AstaraOS>
<AstaraOS> i just need to block all node
<AstaraOS>
<AstaraOS> if you go with server less
<AstaraOS>
<AstaraOS> people can block too
<AstaraOS>
<AstaraOS> client -- > server ?
<AstaraOS>
<AstaraOS> that's why in my opinion tor is stupid
<AstaraOS>
<AstaraOS> i don't even need the node
<AstaraOS>
<AstaraOS> just first node
<AstaraOS>
<AstaraOS> and last node
<AstaraOS>
<AstaraOS> if you encrypt it between middle
<AstaraOS>
<AstaraOS> i would rather
<AstaraOS>
<AstaraOS> use proxy
<AstaraOS>
<arma> ok. off you go then. please do not clutter up #tor.
AstaraOS was banned on #asahi-dev by marcan [*!*@180.241.255.245]
AstaraOS was kicked from #asahi-dev by marcan [AstaraOS]
user982492 has quit [Remote host closed the connection]
user982492 has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052 has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
user982492 has quit []
<marcan>
kettenis/robher: I think I'm going to drop the idea of making the RTC forwards compatible and just use per-PMU compatibles and have the driver hardcode all the regs
<marcan>
I'm getting the feeling that Apple is moving towards doing this all in SMC anyway, given they're already outsourcing RTC reads to SMC for Maverick and apparently somehow the RTC pulls fractional seconds out of thin air
<marcan>
ha, I think SMC is faking that tick count
<marcan>
if I wait for the PMU second to roll over, then read SMC, the SMC is a few milliseconds *behind* in its count, still on the previous second
<marcan>
maybe it reads the PMU RTC on startup and then just free-runs off of some other clock in SMC?
<kettenis>
marcan: so what I found out is that the CLKM SMC key is present on the mini that I upgraded to 12.x but not there on the macbook pro that is still on 11.x
<kettenis>
which fits in with your theory that they're moving towards an SMC-based solution
<marcan>
now I almost want to just wait until 13.x and see if we can just put the RTC driver in SMC...
<kettenis>
regarding the shifts, I did quite a bit of experimentation and convinced myself the shifts in the OpenBSD driver are correct
<marcan>
the tick count is >>1 to get 32768Hz ticks
<marcan>
the offset is already in ticks
<marcan>
but on maverick, the tick count always ends in 000a (pre shift) for some reason
<marcan>
so only integer seconds are valid
<marcan>
however, the field still starts at the a (!)
<marcan>
which you can tell because if you start reading at the seconds offset, the time never updates
<marcan>
since the time is atomically loaded into the registers when you read the first byte
<kettenis>
so the maverick PMU doesn't provide the sub-second resolution the sera pmu does
<kettenis>
most RTCs only provide second resolution so I suppose we can live with that
<marcan>
kind of
<marcan>
the problem is the SMC is still providing sub-second resolution, and the offset also provides sub-second resolution
<marcan>
most RTCs will reset the sub-second counter when you write to them, but we can't emulate that behavior without knowing when the second rolls over, which is annoying
<marcan>
and who knows how SMC implements that sub-second counter
<marcan>
so while linux will do sub-second updates when syncing to NTP on most RTCs, we can't implement that sanely here without hooking up the PMU driver to SMC
<marcan>
but I guess for now this will have to do; if in 13.x they switch to a full SMC based solution we can just implement that and deprecate the PMU mechanism, and if they don't we can think of doing what macOS does and having the drivers talk to each other
<kettenis>
ntp will fix it quickly enough
<marcan>
sure
<kettenis>
these days having the correct time is important such that you can do DNSSEC to lookup the ntp server
<kettenis>
but that doesn't really need to be very accurate
<kettenis>
I suppose you ran macOS under the hypervisor to see what it does to set the clock?
<marcan>
kettenis: yeah, it always reads the clock from SMC then immediately writes the offset to the PMU
<kettenis>
so they use the running clock in the SMC now, but stull use the offset in the PMC
<kettenis>
s/PMC/PMU/
<marcan>
yeah
<marcan>
hence the rtc helper function thing in the ADT
<marcan>
the curious thing is how the SMC is synthesizing the sub-second precision
<marcan>
because if it's just free-running, it would fall out of sync with the real PMC clock, unless it continuously updates the PMC clock? but it's not writable as far as I can tell...
<marcan>
or maybe it has some magic way of reading it?
<kettenis>
I'm starting to suspect it is a different clock altogether
<marcan>
it has the same value though
<marcan>
at the seconds
<kettenis>
hmm
<marcan>
and always rolls over a seemingly consistent-ish fraction of a second prior
<marcan>
polling from m1n1 until the PMU rolls over, then reading SMC, I get: 001115b48005 (PMU) 001115b47fa8 (SMC)
<kettenis>
so maybe the way to solve this is to make the RTC a subnode of the SMC and reference the offset in the pmu through an nvmem-cells property
<marcan>
but then the RTC needs to do the alarm stuff too
<marcan>
which isn't quite nvmem
<marcan>
that said, there's a decent argument for doing that anyway, since we won't support alarms yet, and just hope 13.0 lets us do everything from SMC
<marcan>
and then I can also move the power sequencing stuff to SMC, that needs to poke at other PMU bits
<marcan>
it does kind of make sense to do it all in one driver under SMC and treat the PMU as dumb memory in this case
<kettenis>
yes, you'd have to have a separate RTC driver that handles the alarams
<marcan>
I'd be okay with saying no alarms in 12.x if 13.x comes around with everything doable from SMC
<marcan>
then we just never have a PMU RTC driver
<kettenis>
the sole reason for having alarm support is to be able to schedule a wakeup from suspend isn't it?
<marcan>
yeah
<marcan>
or from off
<marcan>
but we don't even have suspend yet :)
<marcan>
also looking at the nvmem stuff, that eliminates the entire question about how to represent this in the PMU binding since it just lets you define address ranges for cells
<marcan>
which means we can just treat the entire PMU as an nvmem device (a lot of it is), though I'd still make it an mfd so that if in the future we need to throw other things in there we can
<kettenis>
powerdown/shutdown could be done in the same way
<marcan>
exactly
<kettenis>
This should help making things future-proof
<kettenis>
the SMC keys are discoverable, so if at some point a key to read/write the offset appears the SMC RTC driver can just use that
<j`ey>
is it an offset from 1970?
<kettenis>
basically the clock uses some arbitrary epoch and the offset is used to turn that into an offset from 1970
<j`ey>
ah
<kettenis>
to set the clock, you just tweak the ffset
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
mtjzh has quit [Remote host closed the connection]
<marcan>
generic spmi-mfd-nvmem driver is done, going to write the SMC RTC driver now hooking into it
<marcan>
I also added a bunch more nvmem/flag details I could gather around from the ADT and the PMU driver
<marcan>
I'm going to make the reboot driver handle the boot failure stuff properly too, since otherwise something could complain or decide to go into recovery mode or something
<marcan>
there's one somewhat hacky thing in there, the RTC "nvmem" area actually covers the whole RTC including the counter, so you get the RTC included in the /nvmem file in sysfs if you cat it
<marcan>
but I figured splitting it up into even tinier bits to avoid that isn't really worth it
<marcan>
(this is also why I *am* splitting it into 3 at least; if you try to cover the entire 64K PMU space with one NVMEM block, you get the whole thing when you cat the file, and that's bound to cause trouble)
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
<kettenis>
I suppose we should avoid exposing regions that have side-effects
<kettenis>
I question the wisdom of exposing hardware like that through sysfs, but that's not going to help you ;)
<alyssa>
^^
<alyssa>
let's not have a repeat of the infamous UEFI linux systems where "rm ... /" would brick the machine ;P
mtjzh has quit [Remote host closed the connection]
<marcan>
*writing* to files in sysfs is a bit different from rm :p
<marcan>
but FWIW I've been messing with nvram a lot today and nothing weird happened
<marcan>
the RTC stuff shouldn't have any side effects when read
<marcan>
and writing to it won't brick anything; I tried :p
<marcan>
so I think we're pretty safe
<alyssa>
"I tried" 🍿
<kettenis>
marcan: what is pm_setting used for?
<marcan>
kettenis: I think that's the power on after AC loss flag, but I haven't tested it yet
alyssa has quit [Quit: leaving]
the_lanetly_052 has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
AstaraOS has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2022-02-13 21:35:21)]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
auwooo has joined #asahi-dev
* auwooo
greeting all , how are you all ? night morning afernoon all , i have setup base here for United Nations , incase you need me just go to channel #astara and leave me a message , i will see your president from there , tell me which country are you from ... .
auwooo has quit [Remote host closed the connection]