06:55 <ardb> oldgalileo: recent arm64 kernels will not remap the runtime services so the PC and LR should match the boot time placement of the DXE drivers

06:55 <ardb> pass `efi=novamap` to be sure but it should be the default

06:56 <ardb> the debug symbols are useful when running a DEBUG build of the firmware - it will allow single step debugging from the firmware into the EFI stub and back

07:00 <ardb> `efi_debug_table`contains just the path on the build machine to the vmlinux ELF binary, nothing more

07:49 <ardb> linusw__: could you forward me that initramfs?

07:49 <ardb> or geertu

07:49 <linusw__> ardb: yes but it WorksOnMyMachine(TM)

07:50 <ardb> i know

07:51 <linusw__> ardb: sent to your kernel.org address

07:51 <linusw__> ardb: BTW thanks for helping out!!

07:52 <ardb> linusw__: of course

13:43 <oldgalileo> ardb: thanks for the tip about the `efi=novamap`

13:43 <oldgalileo> I know this isn't an EFI group and if there's another place I should go please let me know so I don't clutter this channel

13:45 <oldgalileo> When EFI is booting and loads the Dxes, it prints messages about loading drivers at <address> + its entrypoint. It looks like those addresses might correspond with the PC and LR values I see in the kernel's crash report. I think that would make sense, but am I missing anything there?

13:46 <oldgalileo> This feels especially tempting because the issue I'm encountering is a crash related to invoking OP-TEE functions while at the same time calling functions from EFI

13:49 <oldgalileo> and the driver with a starting address that corresponds with the PC in the crash is MmCommunicationOptee (EFI logs say driver is loaded at 0x0025F120000 w/ entry point at 0x0025F136DC4. PC is at 0x0025F13547C)

14:36 <ardb> do you have access to the firmware build artifacts?

14:36 <ardb> oldgalileo: ^^^

14:37 <ardb> if do, you can objdump the associated .dll file (which is actually an ELF)

14:37 <ardb> and look at the code at 0x1547c

15:16 <oldgalileo> Yeah, that's exactly what I ended up doing! The hint about the `efi=novamap` was a game changer!

15:17 <oldgalileo> ardb: Can't thank you enough

15:19 <ardb> yw

15:44 <mwalle> linusw__: why is there output-high and output-low as properties in the pinctrl nodes? For static configurations? I'm looking into having one pin tied to a particular value when the kernel is started. There's also the gpio-hog, but that one will just be loaded without any connection to a peripheral. I'd need one pin being high when my spi flash is probed for example

16:32 <linusw__> mwalle: output-high and output-low can pertain to pins that are not GPIO but still needs to be e.g. grounded or tied high as part of s suspend state.

16:33 <linusw__> mwalle: if the pin is dedicated to flash control and not really GPIO then use output-high I'd say.

16:45 <mwalle> linusw__: I'd do so, but the pinctrl driver doesn't support output-X. And I'm not sure it will make sense to add it. For context, there is a FET on the flash CS# line, which can be disabled by a button to force SoC USB download mode, the said pin on the SoC is there to disabled this bevhavior and the button can be used as a normal button. Thus I'd just have that pinctrl node added to the spi

16:45 <mwalle> flash

16:52 <mwalle> linusw__: and yes, I've forgot about the standby feature, thanks

17:02 <oldgalileo> Does anyone know a good channel for EDKII questions?

17:23 <heat> devel@edk2.groups.io but expect slow responses

17:23 <heat> i don't think the tianocore irc is alive (although there is one with a handful of people)

19:29 <oldgalileo> I'm reading a bit about ARM SMC calls and generally how cross-world communication works. How do SMC calls work when there are potentially asynchronous calls being made?

19:30 <ukleinek> broonie: There is a sound hat for the raspberry pi that with the vendor kernel uses https://github.com/raspberrypi/linux/blob/rpi-6.6.y/sound/soc/bcm/rpi-wm8804-soundcard.c. Do I need something equivalent with mainline? I seem to recall that I could construct a soundcard with a generic driver an a more verbose description in the dtb. If you have a hint that would be great.

19:36 <mwalle> ukleinek: do you mean simple-audio-card or audio-graph-card?

19:51 <oldgalileo> I guess restating the question a bit simpler: can you make concurrent ARM SMC calls (or maybe even specifically OP-TEE)?

23:10 <broonie> ukleinek: if you want to do fiddly control of the clocks like that you’d need a driver, it’s not clear to me that the wm8904 driver can’t figure out its own clocks well enough.

23:11 <broonie> Shouldn’t even need a particularly verbose DT with the generic cards.

23:12 <broonie> You’d need to configure the GPIOs for the MCLK with some clock API GPIO provider.

23:21 <broonie> Like mwalle says you it’s mostly just doing what the generic cards doo