# Pastebin fkdFJbeJ yeah... we need PSCI but without privilege mode changes for one... which is a whole bike shed to paint with the kernel folks too 1:56 PM tying this to EFI would restrict the paint colors somewhat 1:56 PM but I think you don't want to tie this to efi 1:58 PM Arnd Bergmann 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 1:58 PM <•marcan> IIRC the story was that every other ARM platform uses PSCI 1:59 PM Arnd Bergmann I meant implementing PSCI through a UEFI service 1:59 PM <•marcan> ah 1:59 PM that works except it means then this logic needs to be in u-boot, not m1n1, or we need yet another interface there 2:00 PM not that that would be a showstopper 2:00 PM Arnd Bergmann 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 2:00 PM and you'd lose the functionality if you booted straight from m1n1 2:01 PM <•marcan> yeah, though if this is just for sleep and CPU power control I think I can live with that 2:01 PM I expect users to use u-boot anyway 2:02 PM direct boot is more for testing 2:02 PM having m1n1 scribble something into the device tree and making u-boot turn that into the appropriate EFI table shouldn't be too difficult 2:02 PM <•marcan> you mean like having the actual code live in m1n1? 2:02 PM right 2:02 PM <•marcan> we could do that, yeah 2:03 PM 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 2:04 PM <•marcan> yeah 2:04 PM we don't need interrupts I think 2:04 PM Arnd Bergmann I just asked ardb to join this channel, not sure if he's around. 2:04 PM <•marcan> m1n1 doesn't use them at all 2:04 PM and m1n1 can run with the MMU off or otherwise expects a 1:1 mapping of its code 2:05 PM but we could silo off a chunk of resident code that could have fewer requirements 2:05 PM then ultimately it'd just be something like passing a PSCI entrypoint and some description of reserved memory ranges to u-boot 2:05 PM and it could wrap it in EFI 2:07 PM so EFI already provides a way to mark resident code in its memory map 2:07 PM <•marcan> right 2:08 PM → shenki joined (~j@bilbo.ozlabs.org) 2:09 PM <•marcan> tangentially, I was also thinking about m1n1 chainloads, and how we might need to shave a versioning yak there 2:09 PM 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 2:09 PM Arnd Bergmann https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-psci 2:09 PM <•marcan> since for new machine support / old distros you definitely want whatever version is installed initially to stay until the distro catches up 2:09 PM ha 2:09 PM nice 2:10 PM arnd: thanks, I'll have a look at that 2:10 PM → null joined (~null@speculative.store) 2:10 PM <•marcan> well that certainly looks reasonable 2:10 PM Arnd Bergmann ardb says he has trouble joining oftc.net at the moment, but he's on libera.chat/#armlinux 2:12 PM <•marcan> kettenis: incidentally, I should be putting out a progress report soon, so if you want to write up a blurb on u-boot/openbsd... :) 2:12 PM let me see if I can join there 2:12 PM heh, yes, I need to write something up