<marcan>
there's CLWK which is presumably the wakeup alarm
<kettenis>
the j314 ADT mentions CLKM
<kettenis>
but the j293 ADT doesn't
<marcan>
oh, indeed
<marcan>
both have it though
<kettenis>
hmm, the layout of the RTC registersers is different
<marcan>
on the two machines?
<marcan>
there's the rtc and the scratchpad, as separate sections
<kettenis>
so a simple base wouldn't work
<marcan>
so that would be two reg blocks
<kettenis>
info-rtc = 5126 / 0x1406
<kettenis>
info-rtc_scrpad = 5137 / 0x1411
<kettenis>
and
<marcan>
yes
<marcan>
so it would be two reg spans
<kettenis>
ok, that would work
<marcan>
I think we're pretty much on the same page here; tomorrow I'll clean up the existing code and bindings and see how that goes?
<kettenis>
yup
<marcan>
cool
<kettenis>
theo has an m1 macbook air now
<kettenis>
so I have to be a little bit more careful with breaking stuff ;)
<marcan>
:)
<kettenis>
but I think I can transition to new bindings in this area without too much disruption
<kettenis>
(he's starting to look at suspend/resume, starting with creating a better way to hook that functionality up in a machine-independent way)
<kettenis>
(currently it is all ACPI-specific)
<marcan>
yeah... we need PSCI but without privilege mode changes for one... which is a whole bike shed to paint with the kernel folks too
<kettenis>
tying this to EFI would restrict the paint colors somewhat
<kettenis>
but I think you don't want to tie this to efi
<arnd>
marcan, kettenis: I don't have a reference, but when ardb said how he'd recommend doing it with EFI, it all seemed rather sensible to me
<marcan>
IIRC the story was that every other ARM platform uses PSCI
<arnd>
I meant implementing PSCI through a UEFI service
<marcan>
ah
<marcan>
that works except it means then this logic needs to be in u-boot, not m1n1, or we need yet another interface there
<marcan>
not that that would be a showstopper
<arnd>
there are apparently multiple ways that UEFI has for providing services to the OS, and ardb had a clear recommendation which one of those it should be, but I don't remember what that was
<kettenis>
and you'd lose the functionality if you booted straight from m1n1
<marcan>
yeah, though if this is just for sleep and CPU power control I think I can live with that
<marcan>
I expect users to use u-boot anyway
<marcan>
direct boot is more for testing
<kettenis>
having m1n1 scribble something into the device tree and making u-boot turn that into the appropriate EFI table shouldn't be too difficult
<marcan>
you mean like having the actual code live in m1n1?
<kettenis>
right
<marcan>
we could do that, yeah
<kettenis>
we just have to make sure the assumptions on things like the MMU state and interrupts match what ardb was thinking about for the UEFI interface
<marcan>
yeah
<marcan>
we don't need interrupts I think
<arnd>
I just asked ardb to join this channel, not sure if he's around.
<marcan>
m1n1 doesn't use them at all
<marcan>
and m1n1 can run with the MMU off or otherwise expects a 1:1 mapping of its code
<marcan>
but we could silo off a chunk of resident code that could have fewer requirements
<marcan>
then ultimately it'd just be something like passing a PSCI entrypoint and some description of reserved memory ranges to u-boot
<marcan>
and it could wrap it in EFI
<kettenis>
so EFI already provides a way to mark resident code in its memory map
<marcan>
right
shenki has joined #asahi-dev
<marcan>
tangentially, I was also thinking about m1n1 chainloads, and how we might need to shave a versioning yak there
<marcan>
because if we start chainloading m1n1 so that distro packages can update it, we also need to make sure distro packages don't *downgrade* it
<jannau>
you also need the mem layout to not crash as soon as something is loaded
<kettenis>
shall I pull those into my tree and submit them upstream as a series?
user982492 has joined #asahi-dev
<jannau>
I'm preparing to send a v2 of the mem layout patch and don't mind doing that
<kettenis>
ok, go ahead
<jannau>
feel free to add tested-by/on tags to all commits. I can reply on mailing list as well
<kettenis>
feel free to add my reviewed-by for both patches
___nick___ has quit []
___nick___ has joined #asahi-dev
milek7 has quit [Server closed connection]
milek7 has joined #asahi-dev
int16h has joined #asahi-dev
<tpw_rules>
kettenis: do you know what's happened to my efi timer patch? i am not real sure of the process
jeffmiw has joined #asahi-dev
<alyssa>
$ git format-patch main > /dev/null
<alyssa>
^ how to submit kernel patches
<kettenis>
twp_rules: a fiendly ping is probably overdue
___nick___ has quit [Ping timeout: 480 seconds]
<int16h>
Hello! I've just acquired a T6000/J314s so thought I'd see if I would poke around XD. I am, however, struggling to get a kernel to boot - the furthest it gets is: 'Preparing to run next stage at 0x1000dc00000...' before the proxyclient bailing and the log on the MBP screen clearing - I've applied the patches as described in the wiki::quickstart (and asahi.txt quickstart). Am I missing something? :D
<tpw_rules>
i hope you meant friendly. should i just reply to the last email in the thread, or resend the patch?
<tpw_rules>
int16h: that is a question more for #asahi
<int16h>
Ah, sorry - I didn't realise I was in this one!
<kettenis>
tpw_rules: just reply; sending a new one without changes tends to be frowned upon
<kettenis>
(and yes, friendly)
jbowen has quit [Ping timeout: 480 seconds]
psydroid has quit [Server closed connection]
psydroid has joined #asahi-dev
<jeffmiw>
marcan: trying to catch up here about spmi/rtc, I was planning to clean-up my patches with checkpatch.pl to get them ready to submit but not sure if it still makes sense if you have worked and rewritten a lot. let me know what makes sense to do knowing I may progress slowly because of limited time. thx