<tpw_rules>
fortunately the system resets anyway because the watchdog gets initialized with its default 30 second timeout before the EFI function is called
<tpw_rules>
or rather, programmed with its default 30 second timeout at boot, then turned on during shutdown, possibly by systemd
yuyichao has joined #asahi-dev
<tpw_rules>
actually, this is probably u-boot's fault for claiming it can reset the board when it can't. setting CONFIG_EFI_HAVE_RUNTIME_RESET=n fixes the problem. presumably once the PSCI stuff y'all mention gets worked out it will work
<marcan>
tpw_rules: fun, I guess that will also work once we implement PSCI :p (but we'd have to teach u-boot about the new PSCI call method too)
<tpw_rules>
does anybody know how to get symbols for grub's efi binary? i'm trying to figure out why it hangs when booting a kernel
<tpw_rules>
for exactly 53.6 seconds (or 2**29 100ns units)
<tpw_rules>
marcan: did you have a chance to glance through the guide? i'm really hoping the asahi installer can handle all the partitioning in the future
<marcan>
not yet, but yes, I'll take care of the partitioning
<_jannau_>
amw: in prinicle sure. at the moment it will result in non working keyboard/trackpad due to changed defaults
<marcan>
the current installer is basically a PoC of the stub creation
<marcan>
which makes life much easier for developers, but it's missing all the boring bits around partitioning :)
<tpw_rules>
are you going to have to ship your own partitioner? even `diskutil` seems hopelessly broken
<marcan>
we need to use diskutil for APFS resizes and creating the EFI stub partition, since we need to mount the latter
<_jannau_>
amw: is there reason to clone the repo if you just want the config?
<amw>
_jannau_: ok - thanks it's just so succint summary for people to go to.
<marcan>
and I'm not aware of any "reload partition table" API or similar
<marcan>
a bunch of this stuff is gated by entitlements
<marcan>
(e.g. diskutil calls corestorage)
<tpw_rules>
i couldn't figure out how to make it set a partition to an efi system one
<amw>
_jannau_: I only clone it if I want to preserve an exact revision as there is so much re-basing going on
<marcan>
we do have raw disk access, can't remember if to the GPT though but I think so?
<tpw_rules>
or do you mean the macos stub partition
<marcan>
IIRC there is some way but I need to experiment
<marcan>
but yes, as long as we can write the GPT we can fix up the partition types
<maz>
j`ey: that's an SMC in a KVM guest (EC=0b111111).
<j`ey>
maz: and then we inject an undefined exception to el1, looking at kvm_handle_unknown_ec
<kettenis>
ok, disabling the PSCI_RESET code makes all the other PSCI code in u-boot go away
<kettenis>
so I pushed that change
<maz>
j`ey: yup, that's the only sensible thing to do.
<maz>
we have no idea what the guest wants to do anyway.
<kettenis>
tpw_rules: disable PSCI_RESET makes sure CONFIG_EFI_HAVE_RUNTIME_RESET isn't set, so this should make u-boot stop advertising EFI runtime reset support
Dcow_ has joined #asahi-dev
<maz>
j`ey: FWIW, SMC correctly UNDEFs at EL2 (there is nowhere else to report it anyway)
<Glanzmann>
amw: I also considered improving this steps to be able to install debian in less than 10 minutes (I also thought about doing a debian live system if you just want to try it and discard it afterwards), but probably that is not necessary because marcan will do the installer soon anyway.
blassphemy[m] has joined #asahi-dev
Glanzmann has quit [Quit: EOF]
aleasto has joined #asahi-dev
<marcan>
maz: that is a configurable cpu chicken bit
<marcan>
we can turn off that SMC behavior in m1n1
<marcan>
I'm not sure why they have it
<marcan>
it came along with the macOS chicken bits, since it uses it
<marcan>
change that to reg_clr, it should be compliant then
<maz>
marcan: I think they use it in hvf to emulate SMC, but that's just gross.
<marcan>
yeah, I suspected such
<maz>
I'd rather we turn that off by default, because the behaviour really isn't compliant with the architecture.
<maz>
and maybe leave that as an option for people who really want the taste the madness!
<maz>
to taste*
<marcan>
maz: done
<maz>
marcan: now you are forcing me to update the box... ;-)
<marcan>
you can always just chainload :p
<maz>
well, that's what I do already. just need to rebuild the test m1n1/u-boot bundle... once I have sorted the NV branch...
<marcan>
:)
bps2 has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<amw>
Glanzmann: Woops! Sorry - i just assumed the github was the author!
<marcan>
(for those not reading #asahi, pushed the wifi stuff to wifi/take1)
<amw>
Glanzmann: FWIW I got debian X working mostly following your steps. I had to install a particular set of packages to get X + mouse working - still can't get the touch pad to work though
<chadmed>
jannau was working on the touchpad. aiui applespi has issues with how this particular touchpad reports HID events, pressure etc
Dcow_ has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
<amw>
chadmed: Could see any newer touchpad patches in Jannau's github branches - presume it's still to be decoded
<j`ey>
amw: it should work, it's likely a config issue
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
phire has quit [Ping timeout: 480 seconds]
Dcow_ has joined #asahi-dev
Guest7760 is now known as svenpeter[m]
yuyichao has quit [Ping timeout: 480 seconds]
zsxh has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
Glanzmann has joined #asahi-dev
<Glanzmann>
amw: Perfect. Touchpad worked for me out of the box without doing anything. Jannau gave me some tips (added to asahi.txt) how to use the touchpad. When I'm back home I'll try wifi and also send you my package list. With that touchpad works out of the box. I used xorg (are using X or wayland)?
<Glanzmann>
amw: are you* using X or wayland? (kde and gnome os debian testing wayland - fvwm2 the window manager I use is for example xorg)
<Glanzmann>
amw: On which device you're trying the x config?
<marcan>
Glanzmann: if you aren't doing development, please move to #asahi
<Glanzmann>
sure.
Glanzmann has quit [Quit: EOF]
<maz>
marcan: gave the SMC trap change a go, works as expected. thanks!
<marcan>
great!
Glanzmann has joined #asahi-dev
Glanzmann has left #asahi-dev [#asahi-dev]
tpw_rules has quit [Ping timeout: 480 seconds]
tpw_rules has joined #asahi-dev
kit_ty_kate has joined #asahi-dev
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-dev
<kettenis>
marcan: any thoughts yet on the device tree bindings for the SMC GPIOs?
<marcan>
kettenis: I'm thinking smc would be a parent node with subnodes for individual features, then one of those would just be a standard gpio controller
<kettenis>
I currently use a "pwren-gpios" property on the PCIe host bridge port
<marcan>
ah, you mean on the other wis
<marcan>
*side
<marcan>
yes, I was wondering about that
<marcan>
maybe maz has an opinion there?
<marcan>
(or maybe there's something already?)
<marcan>
given this needs to come up before the root port does link training, since we don't do hotplug yet...
<kettenis>
there is a precedent for this for the hifive unmatched PCIe bridge
<kettenis>
on the SMC node, corellium has this ugly "gpio-13: 00800000" property
<kettenis>
that obviously needs some thought
<kettenis>
so some good RE-ing of how the "gP??" SMC key really works would not go amiss
<marcan>
~.
<marcan>
oops, that wasn't dead yet :)
<marcan>
kettenis: there's that really weird read behavior, yeah
<marcan>
and obviously corellium are not, er, something to reference for correctness :p
<marcan>
I'll poke around some more
<marcan>
robher: would be nice to hear your opinion on the general idea for the bindings before I start writing it that way
<marcan>
tl;dr one parent node that implements a key/value interface, then a bunch of child nodes each bound by a subdriver that implements a given feature (gpio, battery, hwmon, etc)
<marcan>
the parent node would not be a simple-bus derivative; the driver there would be in charge of probing child nodes
<marcan>
I think this makes sense because it lets us use the compatible mechanism to identify SMC features/quirks across devices (and makes it more reusable), and allows for obvious things like "the mac mini does not have a battery so does not instantiate that driver"
<marcan>
an alternative way would be to ditch all the explicit description in the DT and just have one monolithic driver attempt to autoprobe everything...
<marcan>
(which is what applesmc.c does on intel systems...)
<robher>
marcan: It's a judgement call. If the child devices have DT resources then it makes sense. But often it is just a node with only compatible just for convenience of instantiating (Linux) drivers.
<marcan>
some of them would provide DT services, e.g. gpio would be a gpio provider
<robher>
It's always easier to add nodes later.
<marcan>
I guess part of the question is whether we can autodetect ~everything or whether we're going to need DT props at some point
<marcan>
if we need to start specifying per-platform props it starts making sense to break it apart like that
<marcan>
I guess the general driver model would be the same in both cases, it mostly just changes how the subdrivers are instantiated, so it wouldn't be too hard to make the call a bit later
<kettenis>
the keys are discoverable
<marcan>
indeed
<tpw_rules>
kettenis: so it turns out u-boot's efi layer polls usb keyboards each time grub reads a sector to check if a new key is available. this leads to a 53 second delay when one is attached after selecting a boot option, unless you press a key
<marcan>
and also we can just read-probe
<kettenis>
tpw_rules: a know issue
<marcan>
we're definitely going to have a sysfs interface with all the keys for experiments/debug anyway
<marcan>
well, debugfs I guess
<tpw_rules>
kettenis: is there a link anywhere?
<kettenis>
there was a post on the mailing list somewhere this year
<j`ey>
marcan: how will the smc-gpio wifi enable get triggered?
<robher>
marcan: The mfd subsystem can handle doing things both ways.
<kettenis>
j`ey: probably the pcie host bridge driver will have to do that
<kettenis>
that's how u-boot currently handles it
yuyichao_ has joined #asahi-dev
<tpw_rules>
kettenis: i cannot find it
yuyichao has quit [Ping timeout: 480 seconds]
<kettenis>
yeah sorry, can't remember the details
<tpw_rules>
is this something you'd patch in your tree
<kettenis>
maybe
<kettenis>
but this does need to be fixed upstream
<kettenis>
the mail I remember was about a fix that got rejected
<tpw_rules>
yeah all the relevant functions in the upstream tree don't seem to have been touched
aleasto has quit [Remote host closed the connection]